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


22/09/2014

GCU-Squad! >> PostgreSQL FDW + Docker

Par : pinpin
Tags:
Irc
docker
fdw
multicorn
postgresql
python

Rajouter une interface SQL au-dessus de n’importe quel jeu de données/API, c’était déjà bien. En faire une interface au dessus de l’API Docker, c’est encore plus fort.

http://notes.pault.ag/dockerfdw/ proposé par Seb sur #GCU@freenode


22/09/2014

code. grind. sleep. >> Confiner PostgreSQL avec SELinux

Tags:

J'avais déjà expérimenté un peu avec SELinux il y a deux ans sans aller trop loin, parce que j'entendais souvent la phrase "Si on veut de la sécurité, il faut SELinux" et surtout à cause de l'arrivée de l'extension sepgsql dans les modules contrib de PostgreSQL. Ça avait donné une conf pour le Fosdem où finalement, j'ai plus parlé des privilèges classiques que de SELinux.

Suite à une demande au ${BOULOT}, je me suis replongé dedans, et les choses ont peu évolué. Dans la majorité des recherches que j'ai pu faire, SELinux reste tout de même un truc qui se met en travers la route, c'est-à-dire, qu'il y a toujours plus de résultats sur comment le désactiver plutôt que configurer les choses correctement. Ensuite, certains proposent de faire aveuglement confiance à setroubleshoot et audit2allow pour faire taire la bête. Enfin, j'ai dû trouver une page ou deux après en deux semaines à temps plein sur le sujet qui parlent de comment confiner un utilisateur dans le but d'implémenter ce que promet SELinux et que toutes les entreprises demandent : le RBAC, Role Based Access Control, ou comment donner le moins de droits possibles aux sous-traitants qui hébergent les serveurs.

Cette fois ci, je suis allé plus loin. Déjà, je suis parti sur une installation de CentOS 6, la famille de distribution RHEL/CentOS/Fedora semble être la plus en avance par rapport à SELinux : à peu près tous les services/daemons fournis dans l'install sont confinés par SELinux. Les utilisateurs ne le sont pas au login, il n'y a donc aucune configuration de RBAC. On verra peut-être ça plus tard, j'ai pas encore obtenu de résultat satisfaisant sur ce sujet, et il vaut mieux expliquer comment confiner correctement PostgreSQL avant de passer aux roles. Tout simplement, parce qu'il est très simple de casser ce confinement avec la configuration par défaut de RHEL, grâce à pg_ctl. Enfin, l'installation des paquets du PGDG n'est pas confinée par défaut, il manque les file contexts adaptés aux chemins particuliers de ces paquets, prévu pour faire cohabiter plusieurs versions majeures ; ce qui ne correspond pas ce qu'à prévu Red Hat pour PostgreSQL.

Après cette longue introduction, mais avant de commencer, il faut savoir administrer un minumum SELinux : si vous ne savez pas qu'il existe des options -Z, ce que sont les contexts, les types et les domaines, mieux vaut d'abord se documenter, par exemple chez Red Hat.

Voici donc les file contexts à ajouter dans un fichier module.te pour confiner l'installation PostgreSQL du PGDG :

/etc/rc\.d/init\.d/(se)?postgresql(-.*)?    --  gen_context(system_u:object_r:postgresql_initrc_exec_t,s0)
/usr/pgsql-[0-9]+\.[0-9]+/bin/initdb        --  gen_context(system_u:object_r:postgresql_exec_t,s0)
/usr/pgsql-[0-9]+\.[0-9]+/bin/pg_ctl        --  gen_context(system_u:object_r:postgresql_initrc_exec_t,s0)
/usr/pgsql-[0-9]+\.[0-9]+/bin/postgres      --  gen_context(system_u:object_r:postgresql_exec_t,s0)
/usr/pgsql-[0-9]+.[0-9]+/share/locale(/.*)?     gen_context(system_u:object_r:locale_t,s0)
/usr/pgsql-[0-9]+.[0-9]+/share/man(/.*)?        gen_context(system_u:object_r:man_t,s0)

Tout d'abord, pour l'init script et pg_ctl, on utilise le type postgresql_initrc_exec_t, c'est ce qui permet de lancer PostgreSQL dans le domaine confiné postgresql_t au boot, via l'init script, et manuellement. La méthode la plus propre est de toujours utiliser l'init script, idéalement par l'intermédiaire de run_init pour démarrer, arrêter ou redémarrer le postmaster. On évite alors de laisser trainer des choses dans /var/{run,lock}.

Les programmes postgres et initdb doivent avoir le type postgresql_exec_t car ils exécutent le serveur PostgreSQL ; cela doit se faire dans le domaine postgresql_t.

Enfin, on a placé les labels corrects sur les fichiers de traduction et les pages de man, pour faire plus propre. Ce code source de module SELinux alors doit être compilé et chargé.

Cette configuration est reprise dans le module SELinux disponible sur github. On peut aussi l'ajouter manuellement avec semanage :

semanage fcontext -a -t postgresql_initrc_exec_t '/etc/rc\.d/init\.d/(se)?postgresql(-.*)?'
semanage fcontext -a -t postgresql_exec_t '/usr/pgsql-[0-9]+\.[0-9]+/bin/initdb'
semanage fcontext -a -t postgresql_initrc_exec_t '/usr/pgsql-[0-9]+\.[0-9]+/bin/pg_ctl'
semanage fcontext -a -t postgresql_exec_t '/usr/pgsql-[0-9]+\.[0-9]+/bin/postgres'
semanage fcontext -a -t locale_t '/usr/pgsql-[0-9]+.[0-9]+/share/locale(/.*)?'
semanage fcontext -a -t man_t '/usr/pgsql-[0-9]+.[0-9]+/share/man(/.*)?'

Il existe un certain nombre de booleans pour la configuration des droits SELinux de PostgreSQL, le plus important concerne rsync, souvent nécessaire pour faire des base backups. Il s'agit de postgresql_can_rsync, pour l'activer :

semanage boolean -m --on postgresql_can_rsync

Si on lance l'instance sur un port TCP différent de 5432, il faut l'autoriser dans la configuration locale de SELinux :

semanage port -a -t postgresql_port_t -p tcp <port>

Enfin, il ne faut pas oublier d'appliquer les contexts aux fichiers soit avec restorecon, un relabel complet au reboot ou chcon.


18/09/2014

Le Projet NetBSD, en Français >> Alerte de sécurité

Par : sadirux
Tags:
NetBSD
Securité
current

C’est avec « un peu » de retard que nous vous annonçons la publication de 4 alertes de sécurité :

Si vos systèmes sont vulnérables, n’oubliez pas de les mettre à jour. Les instructions détaillées et les liens sont dans chacun des bulletins de sécurité.