31/10/2014

Emile "iMil" Heitor 's home >> Mounting UFS2 read/write on Linux

Par : iMil
Tags:
Blogroll
Debian
Linux
NetBSD
UFS2

I recently had the need to mount an UFS2 (NetBSD) partition under GNU/Linux, and while this is surprising, a standard Linux distro, Debian in my case, is not able to mount it in read/write mode.

I came across this project https://github.com/DanielO/fuse-ufs2 which has basic UFS2 read/write support. It is not very stable, I made it crash a couple of times while using vim on the mounted partition, but it does support simple operations like cp, rm and such.

Here’s how to build and use it under Debian Wheezy:

apt-get install build-essential fuse libfuse-dev autoconf automake libtool git libbsd-dev e2fslibs-dev 
git clone https://github.com/DanielO/fuse-ufs2
cd fuse-ufs2
./autogen.sh
./configure
vim fuse-ufs/do_fillstatbuf.c

Comment out the __st_ino. Do the same operation for fuse-ufs/op_readdir.c

make
make install
fuse-ufs /dev/xvda3 /mnt -o rw

Replace xvda3 with the actual partition you need to mount.
You can now access your UFS2 partition :)

The post Mounting UFS2 read/write on Linux appeared first on Emile "iMil" Heitor 's home.


13/10/2014

Olivier's Blog >> ipfw improvement on FreeBSD -current

Tags:
BSDRP
FreeBSD
english
Few days ago Alexander V. Chernikov posted on the FreeBSD -net mailing list an "HEADS UP: Merging projects/ipfw to HEAD" with lot's of promises:
I'm not an expert of ipfw(8), but I would check the impact of this improved-ipfw on forwarding performance. By "performance" I mean how this code impact the throughput (in term of packet-per-second) of my FreeBSD firewall (I didn't bench all the parameters requiered by RFC3511).
Once the code was committed as r272840 on -head, I've generated a new nanobsd(8) image on my 10gigabit bench lab… and here are the results:


More than 100K pps of differences! Now I dream of an ipfw_sync equivalent to pf_sync(4).
And here are the ministat output for statistician extremists.
Regarding ipfw in stateless mode:


x 272685.ipfw-stateless
+ 273009.ipfw-stateless
+----------------------------------------------------------------------+
|x      x     x    x                                  + + +      +    +|
|   |______A__M___|                                                    |
|                                                     |___M__A_____|   |
+----------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5       1585928       1619817       1608891     1604564.2     12728.878
+   5       1683246       1712607       1690405     1695508.6      12250.89
Difference at 95.0% confidence
        90944.4 +/- 18219.1
        5.66786% +/- 1.13546%
        (Student's t, pooled s = 12492.2)

And regarding ipfw in statefull mode:


x 272685.ipfw-statefull
+ 273009.ipfw-statefull
+----------------------------------------------------------------------+
|xx    x   x    x                       ++   +    +                   +|
||_____A______|                                                        |
|                                    |_______M___A____________|        |
+----------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5       1390415       1433678       1407058     1408663.4     18451.472
+   5       1502719       1589778       1517320     1529871.8     35404.181
Difference at 95.0% confidence
        121208 +/- 41172.4
        8.6045% +/- 2.9228%
        (Student's t, pooled s = 28230.4)


06/10/2014

Mon chti blog >> BSDFrance et opensmtpd

Tags:
bsdfrance
opensmtpd

J'ai déjà fait référence dans un précédent billet à la configuration d'une liste privée. Pour ceux qui voudraient un peu plus de détail, voici la version de bsdfrance, l'association qui oeuvre pour la promotion des BSD dans les pays francophones.

 1  listen on bce1
 2  listen on lo2
 3
 4  table bsdfrance.fr         "/etc/mail/bsdfrance.fr"
 5  table asso_@@_bsdfrance.fr "/etc/mail/asso_@@_bsdfrance.fr"
 6  table spammers             "/etc/mail/spammers"
 7  table restrict             { asso_@@_bsdfrance.fr }
 8  table to_restrict          { president_@@_bsdfrance.fr, tresorier_@@_bsdfrance.fr, secretaire_@@_bsdfrance.fr }
 9
10  max-message-size 1M
11
12  reject from any   sender <spammers>
13  accept from any   sender <asso_@@_bsdfrance.fr> for domain "bsdfrance.fr" recipient <restrict> alias <bsdfrance.fr>
14  accept from local sender <to_restrict>          for domain "bsdfrance.fr" recipient <restrict> alias <bsdfrance.fr>
15  reject from any                                 for domain "bsdfrance.fr" recipient <restrict>
16  accept from any                                 for domain "bsdfrance.fr"                      alias <bsdfrance.fr>
17  accept for any relay
nom_de_l_alias: :include:/chemin/vers/un/fichier

L'alias asso est définit comme suit:

asso: :include:/etc/mail/asso_@@_bsdfrance.fr

Merci à toute l'équipe d'opensmtpd pour ce fantastique serveur de courriel.

Ps: afin de ne pas polluer le serveur de courriel de bsdfrance.fr, tous les caractères @ ont été remplacés par _@@_.


30/09/2014

Le Projet NetBSD, en Français >> pkgsrc 2014Q3 en approche

Par : sadirux
Tags:
NetBSD

Alistair Crooks nous annonces sur pkgsrc-users que la sortie de pkgsrc 2014Q3 initialement prévue ce jour est repoussée à mercredi, ce décalage est lié en partie aux conséquences de la faille de sécurité shellshock.

Encore un peu de patience !


29/09/2014

Le Projet NetBSD, en Français >> Pkgsrc, nouveaux paquets S39

Par : sadirux
Tags:
NetBSDfr
current
pkgsrc

Pour la semaine du 22 au 28 septembre, seul un paquet a rejoint l’arbre pkgsrc CURRENT :

En cas de dysfonctionnement, n’hésitez pas à soumettre un « Problem Report »


29/09/2014

Le Projet NetBSD, en Français >> NetBSD sur Raspberry Pi

Par : sadirux
Tags:
Conf
NetBSD
RaspberryPi
current

Frédéric Cambus nous propose à travers son blog un tutoriel en anglais afin d’installer NetBSD sur Raspberry Pi. L’auteur nous montre comment :

Et pour terminer, l’auteur propose également quelques paquets pré-compilés.

Pour les plus aventureux, Le dernier build se trouve à cette adresse.


25/09/2014

Le Blog Maniatux - BSD >> mkjl : Créez facilement des jails FreeBSD - Debian GNU/kFreeBSD - ArchBSD sous FreeBSD.

Par : Xavier
Tags:

Je développe un petit script sans prétentions qui permet de créer facilement des jails de type FreeBSD, Debian GNU/kFreeBSD et ArchBSD sur un hôte FreeBSD. Il est écrit en sh mais ne concurrence pas ezjail ou vmrc. En revanche il fait gagner pas mal de temps si votre besoin est de déployer facilement des jails autres que FreeBSD.

Pré requis

Il vous faudra installer les paquets suivants (à partir de pkgng ou des ports) :

Et pour faire tourner les jails Debian, il vous faudra charger les modules fdescfs et linprocfs.

Installation des pré requis

Installation des paquets :

# pkg update && pkg install git perl5 debootstrap rsync pacman

Charger les modules pour Debian :

# kldload fdescfs
# kldload linprocfs

Ou, de manière persistente :

# echo fdescfs_load="YES" >> /boot/loader.conf
# echo linprocfs_load="YES" >> /boot/loader.conf

Récupération de mkjl.sh

Avec git :

# git clone https://github.com/src386/mkjl

Sans git :

Simplement avec l'archive compressée :

fetch --no-verify-peer https://github.com/src386/mkjl/archive/master.zip
unzip master.zip

Utilisation

Utilisez la syntaxe suivante :

# ./mkjl.sh $name $template

Exemple, pour une jail de type ArchBSD nommée www :

# ./mkjl.sh www t_archbsd

Ensuite il ne vous reste qu'à éditer /etc/jail.conf pour déclarer vos jails. Un fichier jail.conf.example est fourni mais vous pouvez également vous aider de cet article..

Templates disponibles

Consulter le README.md

Liens


25/09/2014

Weblog de Natacha >> Come on, Mark!

Par : Natacha Kerensikova
Tags:
Geek

Ceux d'entre vous qui suivent l'actualité geek ont probablement entendu parler de Standard Markdown Common Markdown CommonMark, qui a l'ambition d'unifier et de standardiser Markdown.

Ceux qui me suivent depuis longtemps se souviennent peut-être de la catastrophe libupskirt, et pour les autres il suffit de savoir que j'ai écrit une bibliothèque C qui parse Markdown avec différents jeux d'extensions, et qui supporte différents formats de sortie. Il s'agit de libsoldout.

Même si libsoldout remplit parfaitement mes besoins, l'arrivée d'un format prétenduement unificateur pose la question de le supporter aussi, à côté.

Malheureusement, la réponse est que c'est la merde.

Les gens qui ont fait CommonMark avaient manifestement en tête une certaine architecture de parser, et ça a visiblement « fuit » dans la spécification du langage. Et évidemment, cette architecture n'est pas du tout la même que celle de libsoldout.

Pour faire simple, le cœur de libsoldout est un parser dit inline, c'est-à-dire qu'il considère l'entrée comme un flux infini de caractères qu'il traite petits bouts par petits bouts, voire caractère par caractère.

Ainsi, lorsque libsoldout rencontre un caractère actif, il détermine immédiatement son sens avant de traiter le suivant.

Par exemple, dans foo *bar baz* moo, lorsque la première étoile est rencontrée, il détermine immédiatement s'il s'agit d'une emphase valide, avant de s'occuper de l'intérieur.

Or dans l'exemple n°239 de la spécification, aux deux tiers du document, ils introduisent magiquement la notion de précédence entre les éléments span, de sorte que dans foo *bar `baz* moo`, la deuxième étoile doit faire partie du fragment de code délimité par `, plutôt que servir de fin à l'emphase.

À moins de faire des contorsions peu évidentes et fragiles, il n'est pas possible d'introduire une précédence dans ce type de parser, vu que le sort de chaque caractère doit être réglé avant de passer à la suite. Il faudrait décloisonner les éléments (i.e. que l'emphase soit capable de déterminer qu'un fragment de code lui boufferait son étoile), ou introduire la possibilité de défaire un élément (i.e. que la première étoile commence une tentative d'emphase, qui puisse éventuellement échouer si la suite ne lui fournit pas d'étoile finale comme dans cet exemple).

Évidemment, ce n'est qu'un exemple, mais CommonMark contient des tonnes de cas similaires : la précédence (encore une fois) des fenced code blocks sur les déclarations de références, certains échappements, etc.

Bref, malgré toute la flexibilité construite dans libsoldout, ajouter le support de CommonMark demanderait beaucoup d'efforts, peut-être plus qu'écrire un nouveau parser, pour un résultat plus fragile.

De plus, le gens de CommonMark fournissent généreusement une bibliothèque en C, alors que la raison d'être de libsoldout, c'était l'absence de bibliothèque dans un langage compilé. J'ai donc très envie d'envoyer les gens qui veulent du CommonMark vers l'implémentation officielle.

Une partie de moi me dit que c'est une mauvaise idée, parce que ça va marginaliser encore plus libsoldout, au point de lui faire perdre toute pertinence. Une autre me dit qu'elle est déjà au minimum et n'a plus rien à perdre.

Chers lecteurs, connaîtriez-vous des utilisateurs de libsoldout ? Que pensent-ils de CommonMark et d'un éventuel support dans libsoldout ?


24/09/2014

Le Projet NetBSD, en Français >> Pkgsrc, nouveaux paquets S38

Par : sadirux
Tags:
NetBSD
current
pkgsrc

Pour la semaine du 15 au 21 septembre, deux nouveaux paquets ont rejoint l’arbre pkgsrc CURRENT :

Bonne compilation !


22/09/2014

GCU-Squad! >> monitore tes containers lxc a peu de frais avec collectd

Par : pinpin
Tags:
Irc
ansible
collectd
lxc

tout con, mais y’a tellement d’infos dans /sys qu’on a du mal à trouver celle qui nous interesse.. et la paf en 3 coups de cuillère a pot de parsing, on ajoute les containers LXC aux sources possibles de monitoring a collectd, avec un coup d’ansible parce qu’on est des loutres

https://www.iweb-hosting.co.uk/blog/collecting-lxc-container-resource-usage-using-ansible-collectd.html proposé par gaston sur #GCU@freenode