17 December 2014

Jean-Baptiste Hétier (djib)

"dmesg -w", vos messages système sous les yeux à tout moment

J'ai découvert au hasard dans la page de manuel de dmesg qu'il existait désormais une option -w (au moins à partir de Debian Jessie) qui permet d'afficher les messages du kernel dès qu'ils sont disponibles. C'est pratique pour suivre les logs système sans avoir à jouer avec tail.

17 December, 2014 06:06PM par djib

16 December 2014

Carl Chenet

Suivre les stats de son site web en Ruby On Rails avec Piwik

Suivez-moi aussi sur Identi.ca  ou Twitter  ou Diaspora*diaspora-banner

Après avoir lancé Le Journal du Pirate, le Hacker News francophone, j’avais évidemment besoin de suivre la fréquentation du site. J’avais utilisé AWStats sur un précédent projet et je voulais tenter d’utiliser un logiciel de comception un peu plus récente cette fois-ci.

awstats-logo

Piwik semblait convenir parfaitement. Multi-sites, Interface graphique moderne, des bons échos dans la communauté, je me suis donc naturellement dirigé vers cette solution. Piwik se présente comme une application web avec une base de données MySQL derrière.

piwik_app

Pour les gens intéressés, le site officiel propose une démo très sympa permettant de voir tout de suite les points forts de Piwik.

piwik

Le Journal du Pirate est quant à lui une application Ruby On Rails. Or Piwik requiert l’ajout d’un javascript sur les pages que l’on veut surveiller. Ce qui peut s’avérer délicat à réaliser lorsque que l’on maîtrise mal RoR.

La documentation officielle suivante explique très bien la marche à suivre. Ajouter une gem Ruby à son Gemfile, relancer bundle puis quelques éléments de configuration dans le fichier config/piwik.yml et le tout a marché directement.

rails

Je suis très content du résultat. Niveau interface graphique c’est très agréable et Piwik propose un très grand nombre de métriques associées aux différents sites web supervisés. J’en ai profité pour lui faire surveiller ce blog et le site web de MyTux, ma société d’infogérance de serveurs Debian.

Et vous ? Quel est votre ressenti après avoir utilisé quelques temps Piwik ? Des difficultés à le mettre en place avec RoR ? N’hésitez pas à réagir dans les commentaires de ce billet.


16 December, 2014 11:00PM par Carl Chenet

Tuxicoman

Mini guide MySQL

Je mets ici mon anti-sèche pour mes besoins basiques de MySQL, à savoir gérer des sites  WordPress, Owncloud, Piwik, etc…

Prise en main

Un super utilisateur nommé « debian-sys-maint » est créé par Debian pour administrer MySQL. Son mot de passe se trouve dans le fichier /etc/mysql/debian.cnf
# cat /etc/mysql/debian.cnf

On peut se connecter à MySQL avec l’une des solutions suivantes :

  • Mot de passe interactif :
    $ mysql -u debian-sys-maint -p
  • Mot de passe en chargeant le mot de passe directement depuis le fichier:
    # mysql --defaults-file=/etc/mysql/debian.cnf
  • Mot de passe avec le mot de passe dans la ligne de commande (déconseillé, le mot de passe se trouvant alors dans l’historique):
    $ mysqldump --user=debian-sys-maint --password=MOTDEPASSE

Vous devriez avoir l’invite de commande MySQL:
mysql>

Pour quitter MySQL à tout moment:
mysql> exit

On va maintenant pouvoir lancer des commandes, chaque commande se termine par le caractère ‘;‘, ne l’oubliez pas.

Pour lister toutes les bases de données présentes:
mysql> SHOW databases;

Pour lister tous les utilisateurs:
mysql> SELECT User,Host FROM mysql.user;

Procédure pour installer un nouveau site web facilement

Souvent, il vous arrivera pour installer un nouveau service (WordPress, Owncloud, Piwik, etc…) de devoir créer une nouvelle base de données et un nouvel utilisateur ayant tous les droits sur celle ci. Voyons comment faire ca.

Comme nous allons créer un nouvel utilisateur et son mot de passe, je vous invite générer un bon de mot de passe en suivant ce guide avant de commencer.

Ensuite, un fois connecté à MySQL :

Créez un nouvel utilisateur en utilisant le mot de passe généré:
mysql> CREATE USER 'piwik_user'@'localhost' IDENTIFIED BY 'mot_de_passe_complique';

Créez une nouvelle base de donnée:
mysql> CREATE DATABASE piwik_database;

Donnez les permissions à l’utilsateur sur la base de données:
mysql> GRANT ALL ON piwik_database.* TO 'piwik_user'@'localhost';

Appliquez les privilèges:
mysql> FLUSH PRIVILEGES;

Fini !
mysql> exit;

Et voila, vous êtes bon. C’était pas si dur :-)

Sauvegarde et restauration

Une chose super indispensable à savoir aussi, sauvegarder sa base de donnée. Car on ne peut pas récupérer les données sans que MySQL tourne. Donc il faut penser à bien faire ses sauvegardes tant que MySQL fonctionne.

$ mysqldump --user=debian-sys-maint --password=MOTDEPASSE piwik_database > ~/mysql-piwik_database-backup.sql

Pour restaurer:

$ mysqldump --user=debian-sys-maint --password=MOTDEPASSE piwik_database < ~/mysql-piwik_database-backup.sql

Si vous réimportez la base de données dans un MySQL vierge (ex: résintallation de PC), il faut aussi penser à re-créer les utilisateurs (cf guide ci-dessus) :
$ mysql --user=debian-sys-maint --password=MOTDEPASSE
mysql> CREATE USER 'piwik_user'@'localhost' IDENTIFIED BY 'mot_de_passe_complique';
mysql> GRANT ALL ON piwik_database.* TO 'piwik_user'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> exit;

J'aime(2)Ferme-la !(0)

16 December, 2014 07:38AM par Tuxicoman

15 December 2014

Tuxicoman

Mettre à jour le plugin Flash sous Debian

J’ai récemment eu un petit problème avec Flash, Youtube m’avertissant que le plugin Flash n’était pas à jour !

Vous pouvez vérifier que vous avez la dernière version :
# update-flashplugin-nonfree --status
Flash Player version installed on this system : 11.2.202.406
Flash Player version available on upstream site: 11.2.202.425

En effet, une nouvelle version de Flash est disponible et fixe des problèmes de sécurité dont notamment le CVE-2014-9163 déjà en cours d’exploitation en décembre.

Vous pouvez mettre à jour par cette commande en root:
# update-flashplugin-nonfree --install

Il faudrait vraiment que le plugin Flash se mette à jour tout seul sous Debian à chaque nouvelle version d’Adobe !

J'aime(2)Ferme-la !(2)

15 December, 2014 07:58AM par Tuxicoman

14 December 2014

Raphaël Hertzog

Mes activités libres en novembre 2014

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

ce sont dix-huit de heures de travail sur Debian LTS qui ont été financées ce mois-ci (14 heures allouées par Freexian et 4 heures non consommées du mois dernier). Voici ce qui a été accompli :

  • Tri de vulnérabilités CVE: j’ai poussé 19 commits vers le suiveur de sécurité. J’ai également essayé d’encourager certains mainteneurs à fournir des mises à jour pour des paquets qui ne sont pas utilisés par les sponsors actuels de Debian LTS, et qui ne sont donc pas sur notre liste de priorités;
  • DLA 87 : mise à jour de dbus corrigeant 3 vulnérabilités CVE;
  • DLA 93: mise à jour de libgcrypt11 corrigeant 1 vulnérabilité CVE;
  • DLA 96: mise à jour de sécurité de openjdk-6 corrigeant 21 vulnérabilités CVE;
  • J’ai travaillé à la préparation d’une mise à jour de sécurité pour linux. Elle n’est pas encore publiée.

Mettre à jour le paquet source de linux nous a pris une bonne moitié du temps alloué. Nous avons opté pour une mise à jour du noyau vers la version amont 2.6.32.64. J’ai intégré les patchs amont et j’ai identifié environ 130 patchs que nous devions désactiver (car ils étaient déjà intégrés par l’amont). J’ai ensuite mis à jour notre patch openvz pour l’appliquer par-dessus le nouveau noyau. Cela a demandé un peu de travail manuel pour résoudre les conflits et il y a même des cas pour lesquels je ne suis pas sûr d’avoir pris la bonne décision. Je n’ai pas pu trouver un arbre git de l’amont openvz pour cette version de noyau afin de contre-vérifier.

A la place, j’ai demandé à Ben Hutchings de revoir mon patch. Il m’a répondu qu’il ne s’était pas porté volontaire pour travailler sur la version LTS, mais qu’il était disposé à y contribuer de manière rémunérée. En conséquence et en tant que coordinateur de l’offre Freexian, je lui ai proposé de rejoindre l’équipe des contributeurs LTS rémunérés, afin de s’occuper du noyau. Ce qu’il a accepté.

Ainsi, nous serons capable si tout va bien d’en finir avec cet envoi au cours de la première semaine de décembre. Nous n’avons pas eu d’uploads du noyau dans Squeeze depuis juillet dernier, aussi savoir que nous avons maintenant quelqu’un de capable pour traiter ça en priorité est une bonne chose.

Distro Tracker

Aucun nouveau développement ce mois-ci de ce côté. J’ai passé du temps à la place à importer les nouvelles de l’ancien historique de sorte à ce que lorsque vous recherchez d’anciens paquets vous obteniez des résultats plutôt qu’une erreur 404. Vous pouvez par exemple essayer avec python2.1.

Une autre chose faite ce mois-ci fut de marquer certains bogues avec le tag « newcomer », nouvellement créé. Ce sont des bogues faciles à traiter, et qui sont donc parfaits pour les nouveaux contributeurs souhaitant se lancer : la liste est ici.

A vous de jouer maintenant ! ;-)

DEP-14: Structure recommandée pour les dépôts Git utilisés pour le packaging Debian

J’ai ébauché la version initiale d’un document appelé Structure recommandée pour les dépôts Git utilisés pour le packaging Debian, et l’ai soumis pour discussion sur debian-devel.

La discussion fut intéressante et constructive (oui, c’est encore possible au sein de Debian !). J’ai une pile d’améliorations dans ma copie locale et j’ai besoin de prendre encore en compte quelques retours avant de soumettre un brouillon mis à jour. Ce n’est pas une révolution mais c’est un grand pas vers une standardisation des conventions de nommage pour les tags et les branches.

Systemd, le comité technique et nos listes de diffusion

En bon vétéran, je prête beaucoup d’attention à la gouvernance de Debian et il est ennuyeux de voir à quel point le débat autour de systemd fait resurgir certains de nos anciens démons, et combien il tend l’atmosphère sur nos listes de diffusion.

Nous pouvons être en désaccord sur beaucoup de choses, mais nous devons respecter les opinions de chacun et sommes ici pour travailler ensemble à des solutions utilisables par tout le monde. J’ai donc écrit aux personnes ayant franchi la ligne jaune pour les inviter à mieux se comporter. Et je suis content de voir les responsables des listes nous supporter en bannissant les personnes lorsque c’est justifié. Je crois que nous devons continuer dans cette direction et j’ai partagé une idée (sur un fil de discussion Debian privé qui n’aurait jamais du exister, tout comme le trafic sur cette liste) que je formaliserai et partagerai sur debian-project@l.d.o le moment venu (c’est chose faite ici).

Au même moment, nous avons eu une autre discussion concernant la gouvernance de Debian, avec l’idée qu’il fallait imposer une rotation des membres du comité technique. J’ai été heureux de voir que nous voterons bientôt à ce sujet. Je pense que c’est une bonne chose d’un point de vue général, même si trois de ses membres viennent juste d’en démissionner.

Travaux divers

J’ai parrainé un upload de galette et de trois de ses extensions. J’ai passé en revue jitsi-videobridge et jitsi-meet sur mentors.debian.net.

J’ai également créé quelques rapports de bogues :

  • n°768256 : au sujet d’icônes vim disproportionnées dans les menus contextuels GNOME;
  • n°768540 : cdebootstrap : échoue à lancer d’anciennes versions lorsque dpkg ne supporte pas data.tar.xz;
  • n°770011 : lynx -dump lors d’une mauvaise conversion de &#x2026.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in November 2014 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

14 December, 2014 08:31PM par Raphaël Hertzog

10 December 2014

Olivier Berger (perso)

Réparé les hauts-parleurs d'un portable HP dv6000 en échangeant deux nappes internes

Les hauts-parleurs internes du portable HP de mes parents, un dv6000, ne marchaient plus : plus de son sans devoir mettre des enceintes ou un casque :-(

En fait, il semble que ce soit un problème classique, qui semble causé par des nappes de connexion internes deffectueuses.

La réparation n'est pas trop compliquée, si on achète une nappe de remplacement, mais on peut aussi trouver un contournement.

J'ai réussi à échanger les deux nappes qui connectent la carte mère à la partie qui contient les boutons et les hauts-parleurs, au dessus du clavier, et même si maintenant, les boutons de cette rangée supérieure ne marchent plus, ce n'est pas trop grave, car le son est revenu.

Pour voir une vidéo (en anglais) qui explique comment faire, voir : Hp Pavilion Dv6000 power button and speaker fix!

Content d'avoir récupéré le son :-)

10 December, 2014 10:10PM par obergix

09 December 2014

Debian France

Debian France au Capitole du Libre

Debian France au Capitole du Libre

Le samedi 15 novembre, l'association Debian France a tenu un stand au Capitole du Libre, l'événement du Libre à Toulouse. Ceci a permis de créer un certain nombre de contacts prometteurs, et de confirmer que Debian est une référence reconnue pour ses valeurs. Nous remercions l'association Toulibre pour son accueil et son très bel événement!

09 December, 2014 04:06PM

08 December 2014

Carl Chenet

Site comme Hacker News en français : Le Journal Du Pirate

Suivez-moi aussi sur Identi.ca  ou Twitter  ou Diaspora*diaspora-banner

Avant tout l’adresse du site : Le Journal Du Pirate https://infos.mytux.fr

Un site web comme Hacker News mais francophone propulsé par un Logiciel Libre, je trouve que ça manquait à la communauté francophone.

ycombinator-logo

C’est maintenant chose faite avec un site dérivé du moteur de Lobste.rs. Les sources sont disponibles sur ce GitHub.

github-logo

L’inscription fonctionne par cooptation pour limiter les articles indésirables.

Un petit commentaire avec votre e-mail dans le champ des e-mails et je vous fais parvenir une invitation, qui vous permet à votre tour d’inviter autant de personnes que vous le souhaitez.

Vous pouvez aussi réclamer une invitation depuis le site. L’un des utilisateurs courants vous enverra alors une invitation.

Et tous les commentaires sont les bienvenues bien sûr ;)


08 December, 2014 11:00PM par Carl Chenet

29 November 2014

Philippe Latu

Comment effacer les fichiers de configuration inutiles ?

Sur les systèmes Debian GNU/Linux, les outils de gestion de paquets peuvent préserver les fichiers de configuration lors de la suppression d'un paquet. L'idée est que l'administrateur du système puisse retrouver une configuration personnalisée si le paquet supprimé était réinstallé par la suite.

Cependant, ces fichiers de configuration peuvent s'accumuler dans le temps et finir par générer des problèmes lors des migrations d'une version stable à l'autre. Ici, il faut insister sur le facteur temps. Retrouver des fichiers vieux de plus de dix ans n'est pas rare sur certains serveurs comme ceux utilisés pour l'hébergement des boîtes aux lettres de courrier électroniques. Les migrations matérielles d'une machine à l'autre se font depuis longtemps à l'aide de rsync et les systèmes de fichiers suivent. Il est donc utile de «faire le ménage» dans les fichiers de configuration de paquets trop anciens. Voici comment faire.

La version basée sur dpkg est connue de longue date :

# dpkg --purge $(dpkg -l | grep ^rc | cut -d ' ' -f 3 | tr '\n' ' ')

Il existe maintenant une version plus moderne basée sur aptitude :

# aptitude purge ~c

Contrairement à ce que j'avais indiqué dans une première version de ce billet, l'utilisation d'aptitude apporte une simplification considérable. Merci à JCD !.

Si vous avez une proposition de syntaxe encore plus optimisée pour le même traitement, je suis preneur !

29 November, 2014 03:41PM par Philippe Latu

17 November 2014

Raphaël Hertzog

Mes activités libres en octobre 2014

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Travail d’empaquetage

Avec l’approche du gel effectif de Jessie, je me suis occupé d’empaqueter quelques nouvelles versions amont que je voulais voir incluses. J’ai commencé avec zim 0.62, ayant fait l’impasse sur la version 0.61 pour cause de régressions assez ennuyeuses. Et puisque j’avais deux rapports de bogues à transmettre, j’ai saisi cette opportunité pour discuter avec l’auteur amont et lui demander s’il avait des correctifs importants à inclure pour Jessie. Ce qui eut pour résultat l’envoi d’une autre mise à jour avec trois commits attentivement choisis depuis le dépôt Bazaar amont. J’ai également parrainé un rétroportage dans les dépôts wheezy-backports de cette nouvelle version.

J’ai poussé deux nouvelles versions correctives de Publican (4.2.3 et 4.2.6), mais j’ai du y inclure une solution de contournement pour un bogue que j’ai reporté plus tôt concernant docbook-xml (n°763598 : le catalogue XML ne permet pas à libxml2/xmllint d’identifier une copie locale de certains fichiers), et cela paraissait peu probable que cela soit correctement corrigé pour Jessie.

Last but not least, j’ai poussé la première révision mineure de Django 1.7 – également dénommée version 1.7.1 – vers unstable, et j’ai demandé aux responsables de la publication de s’assurer de son passage vers testing avant le gel effectif de Jessie. C’est important dans la mesure où plus nous sommes proches de l’amont, plus il est facile d’appliquer les correctifs de sécurité durant tout le cycle de vie de Jessie (qui je l’espère sera de 5 ans, grâce à Debian LTS !). J’ai également publié un rétroportage de python-django 1.7 vers les dépôts wheezy-backports.

J’ai enfin parrainé la publication d’un correctif de galette (0.7.8+dfsg-1), résolvant un bogue critique pour la publication, de sorte à ce que galette retourne dans testing (il en avait été enlevé du fait de ce bogue précisément).

Debian LTS

Vous pouvez prendre connaissance du travail rémunéré que j’ai effectué pour Debian LTS via le bulletin dédié. J’ai également consacré un certain temps à échanger avec les consultants Debian au sujet de nouvelles sociétés que nous pourrions contacter. De nouveaux sponsors sont attendus grâce à cette démarche, mais étant donné le très grand nombre de personnes que cela représente, j’en attendais plus. J’ai profité de cette opportunité pour rapporter toutes les entrées erronées (comme par exemple les rejets d’emails ou les URL mortes) au mainteneur de ladite page Web.

Distro Tracker

Seuls 30 commits ont été effectués ce mois-ci, avec presque aucune contribution extérieure. Je suis un petit peu peiné de cet état de fait dans la mesure où contribuer à ce projet n’est pas très compliqué, et que nous disposons d’une pelleté de bogues faciles à traiter pour vous mettre le pied à l’étrier.

Ceci étant dit je suis toujours content du travail accompli. La plupart des modifications ont été effectuées pour Kali, mais elles seront profitables à toutes les distributions dérivées : il est maintenant possible d’ajouter des dépôts externes dans le suiveur mais de ne pas les afficher dans la liste des versions disponibles, et de ne pas générer automatiquement de nouvelles à propos de ces dépôts. Une nouvelle application « dérivé » est maintenant disponible : elle n’en est qu’à ses balbutiements mais peut d’ores et déjà apporter une comparaison utile entre un dérivé et son parent. Vous pouvez la voir à l’oeuvre sur la page du suiveur Kali : http://pkg.kali.org/derivative/. Merci à Offensive Security pour avoir sponsorisé ce travail !

Dans la mesure où j’ai poussé Django 1.7 vers les dépôts wheezy-backports, toutes les instances de suiveurs de distribution que je gère ont été mis à jour avec cette version de Django, et j’ai opté pour rendre cette version obligatoire. Cela a permis de mettre en place la nouvelle fonctionnalité « migrations Django » pour gérer les futures mises à jour de schémas de base de données (j’ai volontairement évité tout changement de schéma jusqu’à aujourd’hui afin d’éviter les problèmes induits par le passage des migratinos gérées par South vers celles gérées par Django).

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in October 2014 contribuée par Weierstrass01.

Un commentaire | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

17 November, 2014 09:12AM par Raphaël Hertzog

16 November 2014

Vincent Bernat

Préparer des règles Netfilter dans un espace de nommage réseau

Souvent, les règles d’un pare-feu sont mises en place à l’aide d’un script faisant appel aux commandes iptables et ip6tables. Cela permet notamment d’utiliser des variables et des boucles. Il y a cependant trois inconvénients majeurs à cette méthode :

  1. Pendant toute la durée du script, le pare-feu est temporairement incomplet : les nouvelles connexions peuvent ne pas être autorisées à s’établir ou, inversement, le pare-feu peut autoriser des flux qui ne devraient pas l’être. Les règles de NAT nécessaires au bon fonctionnement du routeur peuvent également être absentes.

  2. Si une erreur survient, le pare-feu reste dans un état intermédiaire. Il est alors nécessaire de s’assurer que les règles autorisant l’accès à distance soient placées très tôt pour garder la main. Un système de retour automatique à la précédente version est également nécessaire pour corriger la situation rapidement.

  3. Construire de nombreuses règles peut être très lent. Chaque appel à ip{,6}tables va rapatrier l’ensemble des règles du noyau, ajouter la règle voulue et renvoyer le tout au noyau.

Avec iptables-restore

Une façon classique de résoudre ces trois aspects et de construire un fichier de règles qui sera lu par iptables-restore et ip6tables-restore1. Ces outils envoient en une seule passe les règles au noyau qui les applique de manière atomique. Habituellement, un tel fichier est construit par ip{,6}tables-save mais un script peut également faire l’affaire.

La syntaxe comprise par ip{,6}tables-restore est similaire à celle de ip{,6}tables. Cependant, chaque table dispose de son propre bloc et les chaînes doivent être déclarées différemment. Voyons un exemple :

$ iptables -P FORWARD DROP
$ iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
$ iptables -N SSH
$ iptables -A SSH -p tcp --dport ssh -j ACCEPT
$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A OUTPUT -o lo -j ACCEPT
$ iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables -A FORWARD -j SSH
$ iptables-save
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:SSH - [0:0]
-A INPUT -i lo -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j SSH
-A OUTPUT -o lo -j ACCEPT
-A SSH -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT

La table nat et la table filter disposent chacune de leur bloc. La chaîne SSH est déclarée en haut du bloc de la table filter avec les autres chaînes par défaut.

Voici un script qui détourne les commandes ip{,6}tables afin de construire un tel fichier (en s’appuyant massivement sur Zsh2) :

#!/bin/zsh
set -e

work=$(mktemp -d)
trap "rm -rf $work" EXIT

# ➊ Redefine ip{,6}tables
iptables() {
    # Intercept -t
    local table="filter"
    [[ -n ${@[(r)-t]} ]] && {
        # Which table?
        local index=${(k)@[(r)-t]}
        table=${@[(( index + 1 ))]}
        argv=( $argv[1,(( $index - 1 ))] $argv[(( $index + 2 )),$#] )
    }
    [[ -n ${@[(r)-N]} ]] && {
        # New user chain
        local index=${(k)@[(r)-N]}
        local chain=${@[(( index + 1 ))]}
        print ":${chain} -" >> ${work}/${0}-${table}-userchains
        return
    }
    [[ -n ${@[(r)-P]} ]] && {
        # Policy for a builtin chain
        local index=${(k)@[(r)-P]}
        local chain=${@[(( index + 1 ))]}
        local policy=${@[(( index + 2 ))]}
        print ":${chain} ${policy}" >> ${work}/${0}-${table}-policy
        return
    }
    # iptables-restore only handle double quotes
    echo ${${(q-)@}//\'/\"} >> ${work}/${0}-${table}-rules #'
}
functions[ip6tables]=${functions[iptables]}

# ➋ Build the final ruleset that can be parsed by ip{,6}tables-restore
save() {
    for table (${work}/${1}-*-rules(:t:s/-rules//)) {
        print "*${${table}#${1}-}"
        [ ! -f ${work}/${table}-policy ] || cat ${work}/${table}-policy
        [ ! -f ${work}/${table}-userchains || cat ${work}/${table}-userchains
        cat ${work}/${table}-rules
        print "COMMIT"
    }
}

# ➌ Execute rule files
for rule in $(run-parts --list --regex '^[.a-zA-Z0-9_-]+$' ${0%/*}/rules); do
    . $rule
done

# ➍ Execute rule files
ret=0
save iptables  | iptables-restore  || ret=$?
save ip6tables | ip6tables-restore || ret=$?
exit $ret

En ➊, une nouvelle fonction iptables() est définie et masque la commande du même nom. Elle tente de localiser le paramètre -t pour savoir quelle table est concernée par la règle. Si le paramètre est présent, la table est mémorisée dans la variable $iptables et le paramètre est retiré de la liste des arguments. La défintion d’une nouvelle chaîne avec -N ou la mise en place d’une politique par défaut avec -P sont également gérés.

En ➋, la fonction save() va émettre les règles qui seront lues par ip{,6}tables-restore. En ➌, les règles de l’utilisateur sont exécutées. Chaque commande ip{,6}tables appelle en réalité la fonction précédemment définie. Si aucune erreur n’est survenue, en ➍, les commandes ip{,6}tables-restore sont invoquées.

Cette méthode est parfaitement fonctionnelle3. Toutefois, la méthode suivante est bien plus élégante.

Avec un espace de nommage

Une approche hybride est de construire les règles avec ip{,6}tables dans un espace de nommage réseau (network namespace) puis de les sauver avec ip{,6}tables-save et enfin de les appliquer dans l’espace de nommage principal avec ip{,6}tables-restore.

#!/bin/zsh
set -e

alias main='/bin/true ||'
[ -n $iptables ] || {
    # ➊ Execute ourself in a dedicated network namespace
    iptables=1 unshare --net -- \
        $0 4> >(iptables-restore) 6> >(ip6tables-restore)
    # ➋ In main namespace, disable iptables/ip6tables commands
    alias iptables=/bin/true
    alias ip6tables=/bin/true
    alias main='/bin/false ||'
}

# ➌ In both namespaces, execute rule files
for rule in $(run-parts --list --regex '^[.a-zA-Z0-9_-]+$' ${0%/*}/rules); do
    . $rule
done

# ➍ In test namespace, save the rules
[ -z $iptables ] || {
    iptables-save >&4
    ip6tables-save >&6
}

En ➊, le script est réexécuté dans un nouvel espace de nommage réseau. Celui-ci dispose de ces propres règles de pare-feu qui peuvent être modifiées sans altérer celles de l’espace de nommage principal. La variable $ipatbles est utilisée pour déterminer quel est l’espace de nommage courant. Dans le nouvel espace de nommage, les fichiers de règles sont exécutés (➌). Ceux-ci contiennent l’appel aux commandes ip{,6}tables. Si une erreur survient, nous n’allons pas plus loin grâce à l’utilisation de set -e. Sinon, en ➍, les règles sont sauvegardées avec ip{,6}tables-save et envoyées dans l’espace de nommage principal en utilisant les descripteurs de fichier dédiés à cet effet.

L’exécution dans l’espace de nommage principal continue en ➊. Les résultats de ip{,6}tables-save sont envoyées à ip{,6}tables-restore. À ce point, le pare-feu est presque fonctionnel. Les fichiers de règles sont toutefois rejoués (➌) mais les commandes ip{,6}tables sont neutralisées (➋) de façon à ce que les éventuelles autres commandes, comme par exemple l’activation du routage IP, soient exécutées.

Le nouvel espace de nommage ne dispose pas du même environnement que l’espace de nommage principal. Notamment, il ne contient pas d’interfaces réseau. Il n’est donc pas possible de consulter ou de configurer des adresses IP. Lorsque des commandes ne peuvent être exécutées que dans l’espace de nommage principal, il est nécessaire de les préfixer par main :

main ip addr add 192.168.15.1/24 dev lan-guest

Jetez un coup d’œil à un exemple complet sur GitHub.


  1. iptables-apply est un autre outil pratique. Il applique un fichier de règles et revient automatiquement en arrière si l’utilisateur ne confirme pas le changement dans un laps de temps donné. 

  2. Zsh contient des primitives assez puissantes pour manipuler les tableaux. De plus, il ne nécessite pas d’utiliser les guillemets autour de chaque variable pour éviter leur découpage lorsqu’elles contiennent des espaces. Cela rend le script bien plus robuste. 

  3. S’il fallait pinailler, il y a trois petits problèmes. Primo, lorsqu’une erreur survient, il peut être difficile de savoir quelle partie du script l’a provoquée car on ne dispose que de la ligne dans le fichier de règles qui a été généré. Deuzio, une table peut être utilisée avant d’être définie ce qui peut faire passer inaperçu certaines erreurs dues à un copier/coller. Tertio, l’application de la partie IPv4 peut réussir alors que la partie IPv6 a échoué ou vice-versa. Ces problèmes n’existent pas avec la deuxième méthode. 

16 November, 2014 03:28PM par Vincent Bernat

Intel Wireless 7260 comme point d'accès

Mon routeur personnel contient une carte wifi carte Intel Dual-Band Wireless-AC 7260 afin de servir de point d’accès. Cette carte supporte les normes 802.11ac (en 5 GHz) et 802.11n (à la fois en 5 GHz et en 2.4 GHz). Bien qu’elle ait bonne réputation en mode client, ce n’est pas vraiment le choix idéal pour un point d’accès.

$ lspci -k -nn -d 8086:08b1
03:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev 73)
        Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4070]
        Kernel driver in use: iwlwifi

En bref : optez plutôt pour une carte Atheros.

Limitations

Tout d’abord, une carte dite « double bande » ne peut utiliser qu’une seule bande de fréquences à la fois car elle ne dispose généralement que d’une seule radio. Quasiment toutes les cartes wifi ont cette limitation. Pour construire un point d’accès supportant les deux bandes à la fois, deux cartes sont nécessaires.

5 GHz

Il est impossible de mettre en place un point d’accès 5 GHz avec cette carte. Le microcode embarqué ne le permet pas. Cela peut se vérifier avec la commande iw :

$ iw reg get
country CH: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 20), (N/A)
        (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS
        (5490 - 5710 @ 80), (N/A, 27), (0 ms), DFS
        (57240 - 65880 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
$ iw list
Wiphy phy0
[...]
        Band 2:
                Capabilities: 0x11e2
                        HT20/HT40
                        Static SM Power Save
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                Frequencies:
                        * 5180 MHz [36] (20.0 dBm) (no IR)
                        * 5200 MHz [40] (20.0 dBm) (no IR)
                        * 5220 MHz [44] (20.0 dBm) (no IR)
                        * 5240 MHz [48] (20.0 dBm) (no IR)
                        * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 192 sec)
                          DFS CAC time: 60000 ms
                        * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 192 sec)
                          DFS CAC time: 60000 ms
[...]

Alors que la bande des 5 GHz est autorisée par le CRDA (le composant logiciel qui indique le domaine de réglementation actuel), toutes les fréquences sont marquées en no IR. Voici l’explication de ce drapeau:

Le drapeau no-ir permet d’interdire toute possibilité d’initier une transmission radio, y compris l’envoi de sondes (beacons). Ainsi, les interfaces AP/IBSS/Mesh/GO ne peuvent initier une communication sur ces canaux tant que le drapeau est présent.

SSID multiples

Cette carte ne peut publier qu’un seul SSID. La possibilité d’en émettre plusieurs est intéressante pour pouvoir proposer un réseau public (routé à travers Tor), un réseau invité pour les personnes de passage et un réseau privé. La commande iw confirme cette limitation :

$ iw list
        valid interface combinations:
                 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
                   total <= 3, #channels <= 1

À titre de comparaison, voici ce que la même commande renvoie pour une carte Atheros capable de publier 8 SSID simultanément :

$ iw list
        valid interface combinations:
                 * #{ managed, WDS, P2P-client } <= 2048, #{ IBSS, AP, mesg point, P2P-GO } <= 8,
                   total <= 2048, #channels <= 1

Configuration en point d’accès

Nonobstant ces limitations, la carte fonctionne correctement en point d’accès. Voici la configuration que j’utilise avec hostapd :

interface=wlan-guest
driver=nl80211

# Radio
ssid=XXXXXXXXX
hw_mode=g
channel=11

# 802.11n
wmm_enabled=1
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40][DSSS_CCK-40][DSSS_CCK-40]

# WPA
auth_algs=1
wpa=2
wpa_passphrase=XXXXXXXXXXXXXXX
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

L’utilisation du canal 11 impose de se limiter au 802.11n HT40-. La page de Wikipedia sur le 802.11n contient un tableau permettant de savoir si on peut utiliser HT40-, HT40+ ou les deux.

16 November, 2014 03:27PM par Vincent Bernat

19 October 2014

Jean-Baptiste Hétier (djib)

MoveFromExif : déplacer des images selon leurs infos EXIF

Déplacer des images en fonction des données Exif MoveFromExif est un petit script Ruby que j'ai développé pour déplacer des images selon les données EXIF. Plus précisément il place les photos dans des dossiers arborescents année/mois/jour, mais en l'adaptant légèrement vous pouvez triez vos photos par appareil photo, par objectif, ou par toute autre donnée Exif.

Je diffuse MoveFromExif sous licence libre (GPLv3) afin que vous puissiez justement l'adapter à vos besoins.
Suivez ce lien pour télécharger la dernière version de MoveFromExif.

Évidemment, puisque le script déplace des photos d'un dossier à un autre, je vous recommande très fortement de faire une sauvegarde de vos images et de faire vos premiers essais sur de petits échantillons.

Installation sous Debian GNU/Linux

Sous Debian (et probablement les autres distributions dérivées), lancez les commandes suivantes en tant que root

apt-get install ruby rubygems libimage-exiftool-perl
gem install mini_exiftool

Téléchargez ensuite la dernière version de MoveFromExif et déplacez ensuite automatiquement vos photos avec la commande

./movefromexif.rb /dossier/source /dossier/destination

Installation sous Windows

L'installation sous Windows est un peu plus longue :

  • Téléchargez MoveFromExif ;
  • Téléchargez et installez RubyInstaller ;
  • Téléchargez et dézippez ExifTool dans le répertoire de Exif2CSV (ou un répertoire de votre PATH) ;
  • Renommez exiftool(-k).exe en exiftool.exe ;
  • Lancez cmd.exe et exécutez gem install mini_exiftool. (Vous aurez peut-être besoin de spécifier le chemin complet vers gem.exe, par exemple C:\Ruby186\bin\gem.exe install mini_exiftool)

Vous pourrez ensuite déplacer automatiquement vos photos avec la commande :

./movefromexif.rb C:/dossier/source C:/dossier/destination

De nouveau, en fonction de votre PATH vous aurez peut-êre besoin de spécifier le chemin complet vers ruby.exe, par exemple : C:\Ruby186\bin\ruby.exe movefromexif.rb C:/dossier/source C:/dossier/destination.

Ensuite

N'hésitez pas à vous emparer du script ou à me faire remonter des idées. Personnellement ce script me sert moins depuis que je suis passé sur Shotwell pour la gestion de ma bibliothèque, mais j'en ai encore parfois l'utilité pour de gros tris.

19 October, 2014 09:42PM par djib

24 September 2014

Debian France

Debian France reconnu comme Debian Trusted Organization

Debian France reconnu comme Debian Trusted Organization

Grâce à la refonte des statuts de l'association, Debian France est maintenant reconnue officiellement comme étant une Trusted Organization. Ainsi, l'association Debian France est habilitée à recevoir des fonds au nom de Debian et procéder à des dépenses pour le projet.

L'annonce a été réalisée par Lucas Nussbaum, Debian Project Leader.

24 September, 2014 07:14AM

12 September 2014

Stéphane Blondon

Key Signing Assistant (concept)

Dans les allées de la DebConf14, j’ai discuté avec Franklin de l’intérêt pour un développeur d’utiliser son téléphone portable lors d’une key signing party.

Les schémas sont un brouillon d’une utilisation possible du téléphone. L’objectif n’est pas de remplacer la rencontre réelle ou la validation mais juste d’aider à l’échange et validation des clefs.

Actuellement, ce n’est qu’un concept ; rien n’est implémenté.

Le principe général est d’utiliser le téléphone comme un terminal pour l’échange et la validation. Les données partent et reviennent sur la station de travail du développeur par l’intermédiaire d’un serveur web.

  • Le téléphone portable considéré doit être un smartphone ;
  • La seule autorisation à donner pour le téléphone est l’accès à internet ;
  • On considère que les échanges réseau sont fait en https. Je ne pense pas que ce soit indispensable mais il n’y a aucune raison de s’en priver.

Avant la key signing party

Le développeur dispose d’un téléphone sur lequel l’application est installée.
Le processus pour installer ses propres informations est le suivant :

Avant la key signing party

Pendant la key signing party

Le processus est à reproduire pour chaque participant.

Pendant la key signing party

Après la key signing party

Une fois rentré chez lui, le développeur récupère l’ensemble de ses validations sur sa machine de travail :

Après la key signing party

Qu’en pensez-vous ?

Source des schémas

Schémas réalisés avec Inkscape, à partir d’icônes Tango et Gnome-Tango.
Les fichiers svg et png sont disponibles dans le répertoire http://stephane.yaal.fr/ksa/.


12 September, 2014 07:18AM par ascendances

10 September 2014

Olivier Berger (pro)

Le MOOC Bases de données relationnelles est lancé

Nous venons de lancer la première édition du MOOC sur les bases de données relationnelles de Télécom SudParis. Au programme, de la théorie (algèbre relationnelle), de la pratique (dans SQLite dans les navigateurs basés sur WebKit, et plus tard dans PostgreSQL dans une box Vagrant basée sur Debian (voir post précédent)), des contenus et logiciels libres (autant que possible) et pas mal de rush pour finaliser tout ça dans le Moodle.

On débute avec plus de 800 inscrits à la fin du premier jour (y compris les 180 étudiants ingénieurs de 2ème année de Télécom SudParis, qui suivront le cours présentiel en parallèle du MOOC, et collaboreront avec les apprenants externes pour les travaux personnels).

Il est toujours possible de s’inscrire : le gros du travail commence en semaine 2 (qui commence lundi 15/09 à 00h00 heure de Paris).

10 September, 2014 07:53PM par Olivier Berger

20 August 2014

Aurélien Jarno

MIPS Creator CI20

I have received two MIPS Creator CI20 boards, thanks to Imagination Technologies. It’s a small MIPS32 development board:

mips-ci20

As you can see it comes in a nice packaging with a world-compatible power adapter. It uses a Ingenic JZ4780 SoC with a dual core MIPS32 CPU running at 1.2GHz with a PowerVR SGX540 GPU. The board is fitted with 1GB of RAM, 8GB of NOR flash, HDMI output, USB 2.0 ports, Ethernet + Wi-Fi + BlueTooth, SD card slot, IR receiver, expansion headers and more. The schematics are available. The Linux kernel and the U-Boot bootloader sources are also available.

Powering this board with a USB keyboard, a USB mouse and a HDMI display, it boots off the internal flash on a Debian Wheezy up to the XFCE environment. Besides the kernel, the Wi-Fi + Bluetooth firmware, and very few configuration changes, it runs a vanilla Debian. Unfortunately I haven’t found time to play more with it yet, but it looks already quite promising.

The board has not been formally announced yet, so I do not know when it will become available, nor the price, but if you are interested I’ll bring it to DebConf14. Don’t hesitate to ask me if you want to look at it or play with it.

20 August, 2014 08:52PM par aurel32

Olivier Berger (pro)

Building a lab VM based on Debian for a MOOC, using Vagrant + VirtualBox

We’ve been busy setting up a Virtual Machine (VM) image to be used by participants of a MOOC that’s opening in early september on Relational Databases at Telecom SudParis.

We’ve chosen to use Vagrant and VirtualBox which are used to build, distribute and run the box, providing scriptability (reproducibility) and making it portable on most operating systems.

The VM itself contains a Debian (jessie) minimal system which runs (in the background) PostgreSQL, Apache + mod_php, phpPgAdmin, and a few applications of our own to play with example databases already populated in PostgreSQL.

As the MOOC’s language will be french, we expect the box to be used mostly on machines with azerty keyboards. This and other context elements led us to add some customizations (locale, APT mirror) in provisioning scripts run during the box creation.

At the moment, we generate 2 variants of the box, one for 32 bits kernel (i686) and one for 64 bits kernel (amd64) which (once compressed) represent betw. 300 and 350 Mb.

The resulting boxes are uploaded to a self-hosting site, and distributed through vagrantcloud. Once the VM are created in VirtualBox, the typical VMDK drives file is around 1.3Gb.

We use our own Debian base boxes containing a minimal Debian jessie/testing, instead of relying on someone else’s, and recreate them using (the development branch version of) bootsrap-vz. This ensure we can put more trust in the content as it’s a native Debian package installation without MITM intervention.

The VM are meant to be run headless for the moment, keeping their size to the minimum, even though we also provide a script to install and configure a desktop environment based on XFCE4.

The applications are either used through vagrant ssh, for instance for SQL command-line in psql, or in the Web browser, for our own Web based SQL exerciser, or phpPgAdmin (see a demo screencast (in french, w/ english subtitles)), which can then be used even off-line by the participants, which also means this requires no servers availability for our IT staff.
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/sXZ3KGK5TCU?rel=0" width="420"></iframe>

The MOOC includes a section on PHP + SQL programming, whose exercises can be performed using a shared sub-folder of /vagrant/ which allows editing on the host with the favourite native editor/IDE, while running PHP inside the VM’s Apache + mod_php.

The sources of our environment are available as free software, if you’re interested to replicate a similar environment for another project.

As we’re still polishing the environment before the MOOC opening (on september 10th), I’m not mentioning the box URLs but they shouldn’t be too hard to find if you’re investigating (refering to the fusionforge project’s web site).

We don’t know yet how suitable this environment will be for learning SQL and database design and programming, and if Vagrant will bring more difficulties than benefits. Still we hope that the participants will find this practical, allowing them to work on the lab / exercises whenever and wherever they chose, removing the pain of installing and configuring a RDBMS on their machines, or the need to be connected to a cloud or to our overloaded servers. Of course, one limitation will be the requirements on the host machines, that will need to be reasonably modern, in order to run a virtualized Linux system. Another is access to high bandwidth for downloading the boxes, but this is kind of a requirement already for downloading/watching the videos of the MOOC classes ;-)

Big thanks go to our intern Stéphane Germain, who joined us this summer to work on this virtualized environment.

20 August, 2014 01:59PM par Olivier Berger

18 August 2014

Benoit Peccatte

Apache FTP like

Niveau :      
Résumé : alias / /%{username}

Aujourd'hui je voudrais faire un serveur web qui se comporterait comme un serveur FTP ou SFTP. Lorsqu'un utilisateur unix se connecte à un serveur FTP avec un login et un mot de passe, il lui est présenté un contenu qui lui est propre (son $HOME par exemple).

Comment faire l'équivalent avec apache ?

Dit autrement, je voudrais que les 2 commandes suivantes renvoient un contenu différent :

$ wget http://userA@www.monserveur.com/ # répertoire A
$ wget http://userB@www.monserveur.com/ # répertoire B

Pour cela il faut jouer avec les RewriteRules, mais c'est plus balaise que ça en a l'air.

Premièrement il faut une authentification. J'ai choisi ldap, mais prenez la méthode que vous préférez : http://httpd.apache.org/docs/2.2/mo... tout ce qui commence par mod_authn est valable. Voici comment on la met en place :

<Location />
        AuthType basic
        AuthName "My server"
        AuthBasicProvider ldap
        AuthLDAPURL ldap://serveur.ldap.com/dc=domaine,dc=com?uid?sub
        AuthLDAPBindDN cn=user,ou=technical,dc=domaine,dc=com
        AuthLDAPBindPassword password
        Require valid-user
</Location>

Ensuite on joue avec RewriteRule, les variables s'appellent sous la forme %{ENV:VARIABLE}

# utilisez %{ENV:USER_AUTH} pour ceux qui n'ont pas choisi l'authent LDAP
RewriteRule ^(.*) /%{ENV:AUTHENTICATE_uid}/$1

Mais ça ne marche pas. Tout d'abord on apprend qu'il faut mettre les règles dans le Location sinon les variables d'authentification ne sont pas disponibles. Ensuite on a oublié d'activer le rewrite engine. Et enfin dans un location (ou un directory) on ne matche plus la request uri mais le chemin créé à partir de cette uri. Cela qui une fois corrigé nous donne quelque chose comme ça :

<Location />
        RewriteEngine On
        # le résultat sera automatiquement préfixé par le DocumentRoot si on ne le fait pas nous même
        # notez l'absence du / initial dans le pattern ...
        RewriteRule ^var/www/html/(.*) /%{ENV:AUTHENTICATE_uid}/$1 
</Location>

Mais ça ne marche toujours pas. En effet, le rewrite engine d'apache est réentrant, quelle que soit la modification et quel que soit le flag utilisé, si une url est modifiée, apache fait une redirection interne et relance toute la machinerie (dont les redirections). Pour les petits malins, non [L] n'est pas fait pour ça, par contre la doc évoque un [END] qui aurait cette fonctionnalité mais je ne l'ai pas trouvé.

Il nous faut donc un moyen de détecter qu'une url a déjà été transformée par une RewriteRule. Malheureusement les variables (comme %{ENV:AUTHENTICATE_uid}) ne sont valables que dans la partie gauche de RewriteCond ou dans la partie droite de RewriteRule ce qui nous limite sévèrement. On ne peut pas matcher le chemin en pour détecter qu'il contient le répertoire de l'utilisateur. De plus on ne peut pas utiliser une autre racine, apache ajouterait automatiquement le DocumentRoot en cours.

J'ai essayé en utilisant des variables d'environnement temporaire (avec [E=VAR:VALUE]), mais le rewrite engine l'évalue trop tard et ne détecte pas la nouvelle valeur de la variable modifiée par lui-même.

Ma solution est donc de mettre en place un unique répertoire contenant les utilisateurs avec un nom improbable car il ne pourra pas être utilisé comme nom de répertoire dans les répertoires utilisateurs. Et d'utiliser ce nom de répertoire comme marqueur d'url déjà traitée. Ce qui nous donne :

        # mon répertoire s'appelle ____data____
        RewriteRule ^var/www/html/(?!____data____/)(.*) /____data____/%{ENV:AUTHENTICATE_uid}/$1

C'est bien joli, mais ça n'empercherait pas un utilisateur d'aller voir dans le répertorie de son voisin. En effet, ce ne sont que des rewrite rules, pas des droits d'accès. Puisqu'on ne peut pas utiliser les noms de répertoire utilisateur dans les require pour le matcher avec les nom d'utilisateur (on se mordrait la queue (et ça fait mal (au dos))). Il nous faut donc le garantir d'une autre façon, en forçant tout utilisateur a n'accéder qu'à son répertoire avec une autre règle.

        # ce qu'on veut c'est éviter l'utilisateur qui voudrait bypasser la première règle avec un http://www.monserveur.com/____data____/userX
        RewriteRule ^var/www/html/____data____/.*?/(.*) /var/www/html/____data____/%{ENV:AUTHENTICATE_uid}/$1
        # et on voudrait ausst éviter que l'utilisateur puisse scanner la racine
        RewriteRule ^var/www/html/____data____/?$ /var/www/html/____data____/%{ENV:AUTHENTICATE_uid}/

Notez l'ajout de /var/www/html dans les chaines de remplacement, c'est pour éviter qu'apache pense qu'on a modifié le chemin si on n'a rien changé.

Et c'est gagné, on a enfin trouvé !

Je vous laisse donc profiter du résultat :
Edit : la version finale minimise l'appel aux règles, prend en compte les chemins qui se terminent par / et les tentatives d'accès à des répertoires non autorisés.

<Location />
        AuthType basic
        AuthName "My server"
        AuthBasicProvider ldap
        AuthLDAPURL ldap://serveur.ldap.com/dc=domaine,dc=com?uid?sub
        AuthLDAPBindDN cn=user,ou=technical,dc=domaine,dc=com
        AuthLDAPBindPassword password
        Require valid-user

        # make http behave like ftp
        RewriteEngine On
        # create home dir var
        RewriteRule .* - [E=USER_ROOT:/var/www/html/____data____/%{ENV:AUTHENTICATE_homeDirectory}]
        RewriteCond %{ENV:USER_ROOT} !-d
        RewriteRule .* - [E=USER_ROOT:/var/www/html/forbidden]

        # redirection vers les repertpoires utilisateur
        RewriteCond %{REQUEST_FILENAME} !^/var/www/html/____data____
        RewriteRule ^var/www/html/(.*) %{ENV:USER_ROOT}/$1 [L,DPI]

        # impossibilite de lire la racine
        RewriteCond %{REQUEST_FILENAME} ^/var/www/html/____data____/?$
        RewriteRule .* %{ENV:USER_ROOT} [L,DPI]

        # impossibilite de lire le repertoire d'un autre
        RewriteCond %{ENV:AUTHENTICATE_homeDirectory}|%{REQUEST_FILENAME} !^(.*?)\|/var/www/html/____data____/\1
        RewriteRule ^var/www/html/____data____/?[^/]*/?(.*) %{ENV:USER_ROOT}/$1 [L,DPI]
</Location>

<Directory /var/www/html/forbidden>
        deny from all
</Directory>

Note : et pour ceux qui voudraient vraiment faire du FTP avec apache il y a mod_ftp.

Tags:, , ,

18 August, 2014 04:34PM par peck

15 August 2014

Aurélien Jarno

Intel about to disable TSX instructions?

Last time I changed my desktop computer I bought a CPU from the Intel Haswell family, the one available on the market at that time. I carefully selected the CPU to make sure it supports as many instructions extensions as possible in this family (Intel likes segmentation, even high-end CPUs like the Core i7-4770k do not support all possible instructions). I ended-up choosing the Core i7-4771 as it supports the “Transactional Synchronization Extensions” (Intel TSX) instructions, which provide transactional memory support. Support for it has been recently added in the GNU libc, and has been activated in Debian. By choosing this CPU, I wanted to be sure that I can debug this support in case of bug report, like for example in bug#751147.

Recently some computing websites started to mention that the TSX instructions have bugs on Xeon E3 v3 family (and likely on Core i7-4771 as they share the same silicon and stepping), quoting this Intel document. Indeed one can read on page 49:

HSW136. Software Using Intel TSX May Result in Unpredictable System Behavior

Problem: Under a complex set of internal timing conditions and system events, software using the Intel TSX (Transactional Synchronization Extensions) instructions may result in unpredictable system behavior.
Implication: This erratum may result in unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.

And later on page 51:

Due to Erratum HSw136, TSX instructions are disabled and are only supported for software development. See your Intel representative for details.

The same websites tell that Intel is going to disable the TSX instructions via a microcode update. I hope it won’t be the case and that they are going to be able to find a microcode fix. Otherwise it would mean I will have to upgrade my desktop computer earlier than expected. It’s a bit expensive to upgrade it every year and that’s a the reason why I skipped the Ivy Bridge generation which didn’t bring a lot from the instructions point of view. Alternatively I can also skip microcode and BIOS updates, in the hope I won’t need another fix from them at some point.

15 August, 2014 04:02PM par aurel32

13 August 2014

Benoit Peccatte

J’ai pété

... désolé

Niveau :      

Résumé : gdisk /dev/sda

Le format GPT

Guid partition table est un format de partitionnement de disque.

Il ne faut pas confondre un format de partitionnement avec le formatage d'une partition avec système de fichier. Il y a de nombreux formats de système de fichier : ext4, swap, xfs ... Mais il n'existe que peu de format de partitionnement, les plus connus étant :

  • MBR : format utilisé par les premiers PC sous DOS et encore en usage sur la beaucoup de vos machines
  • disklabel : utilisé sur solaris et BSD
  • GPT : apparu récemment (il y a environ 15 ans) pour les besoins de l'itanium

Ce format a pour but de palier les différents problèmes de son prédécesseur direct le MBR :

  • stockage de la table en double et checksum du contenu : la table étant une structure très importante, on peut enfin se dire qu'on ne la perdra plus
  • stockage des offset en LBA sur 64 bits : on arrête de parler de CHS obsolètes depuis longtemps et on espère pouvoir tenir assez longtemps la croissance des tailles de disques : 9 milliards de téra octets avec des secteurs de 512 octets
  • on dépasse donc la limite des 2To supportés par le format MBR, si vous avez un disque de plus de 2Tio il est a peu près certain qu'il a déjà du GPT
  • tous les identifiants sont des UUID : garantis uniques, on peut en créer autant qu'on veut (2^128) et il y en a partout
  • la table fait au minimum 16kio : on n'a plus de question de table primaire/logique/étendue et on peut stocker au moins 128 partitions sans se poser de question
  • accessoirement on peut stocker des noms de partition directement dans la table

Attention, on stocke des adresses de secteur (LBA comme en MBR depuis un certain temps) et non d'octets, et la taille d'un secteur peut varier d'un disque à l'autre, il faut faire attention à ne pas copier les tables GPT trop littéralement.

GPT est indiqué comme nécessaire pour le support du boot sur EFI, bien qu'il soit théoriquement possible de faire sans.

Partitionner en GPT

Pour partitionner en GPT vous avez le choix entre deux familles d'outil :

  • parted et gparted
  • gdisk, sgdisk et cgdisk (remplaçants de la famille fdisk)

Le moins dangereux est de ne partitionner que vos nouveaux disques en GPT, mais il y a moyen de refaire la table de partition d'anciens disques s'il y a suffisament de place pour stocker la table GPT (16kio en début et en fin de disque plus le MBR). Si l'espace est disponible, c'est simple, il vous suffit de reporter les adresses de début et de fin de chaque partition du MBR vers le GPT.

Choix des partitions

Tout d'abord je vous recommande d'aligner vos partition sur 1Mio, le minimum recommandé étant de 4kio. Le minimum de 4ko s'explique par le fait que de plus en plus de disques ont des secteurs de 4ko, et si vos écritures ne sont pas alignées sur 4kio vous allez voir vos performances dégringoler.

Il faut ajouter que de plus en plus de disques sont des SSD. Les SSD ont des pages sur lesquelles il est aussi intéressant de se caler et elles peuvent aller jusqu'à 1Mio.

Donc ne vous posez plus la question et prenez la valeur par défaut de l'outil qui aligne sur le Mio.

  1. Si vous avez un boot sur EFI, vous devez faire une partition EFI (type ESP), ne soyez pas radin, mettez-y au moins 100Mo
  2. Si vous avez un boot sur un BIOS d'origine, il est conseillé de faire une partition de type bios. Certaines personnes indiquent que celle-ci est indispensable car GPT ne laisse pas de place caché pour le bootloader. C'est faux puisqu'il suffit d'aligner les partitions pour faire apparaître de la place. Mais puisqu'on en en est à faire des trucs propres, profitez-en pour faire ce qui aurait du être fait depuis très longtemps et faites de la place pour stocker un bon grub2 avec tous ses modules (1Mo)
  3. Si vous voulez permettre l'hibernation de votre machine (ou si vous avez peu de ram) n'oubliez pas d'inclure une partition de swap.
  4. Pensez à séparer système et données sur deux partitions différentes. La partition de données est naturellement /home pour une particulier, mais sur un serveur c'est plus flou : /var /srv /home sont des répertoire de données.

Compatibilité MBR

Dans la notion de MBR (un unique secteur de 512 octets) il faut différencier le code et la table des partitions.

Si vous utilisez un BIOS classique, le code du MBR restera le même (grub/lilo/boot windows ...).

Si vous utilisez EFI, le code du MBR peut être vide (ce que fait en général gdisk), mais il peut être intéressant de mettre un code fonctionnel avec un avertissement.

La table des partitions du MBR doit elle être protégée pour éviter à un outil d'édition de cette table de tenter d'y faire des modifications et d'effacer vos précieuses données. C'est pour cela qu'on y inscrit un "protective MBR" qui indique que le disque est entièrement utilisé par une partition unique de type GPT.

Tags:, , ,

13 August, 2014 09:29PM par peck

15 July 2014

Stéphane Blondon

DebConf sur la planète

Cette année, la conférence Debian annuelle aura lieu à Portland, aux États-Unis. Comme l’année dernière, j’y participerai. :)

Participation à la conférence Debian

Cette conférence sera la quinzième du nom. Voici une carte des différentes DebConf (passées en rouge, la prochaine en blanc et celle de l’année prochaine en jaune).

debconf14_planet

Jusqu’ici les conférences ont eu lieu alternativement en Europe et en Amérique (du Nord, centrale ou du Sud). Ce sera aussi le cas en 2015 puisque la conférence aura lieu en Allemagne à Heidelberg.

Réalisation de la carte

La carte diffère légèrement de celle réalisée l’année dernière (pour DebConf13) grâce quelques changements de configuration d’xplanet.

Commande utilisée

xplanet -transpng debconf14_planet.png -geometry 1024x512 -projection peters -config debconf14_planet.conf -num_times 1

Deux paramètres ont été modifiés :

  • La carte utilise une projection de Peters plutôt qu’une projection de Mercator. Pour cela, il suffit de remplacer -projection mercator par -projection peters.
  • Avec cette projection, la taille de la Terre n’est pas la même et la zone vide est rempli par défaut par un ciel étoilé. Il est aussi possible de choisir une couleur unie ou sa propre image de fond. Remplacer le paramètre -output par -transpng pour définir le fichier de sortie permet d’avoir un fond transparent.

Fichier debconf14_planet.conf

[earth]
shade=100
marker_file=coords.txt
marker_fontsize=15
map=night.jpg

L’ajout de map permet de définir l’image à utiliser à la place de l’image par défaut. Ici, on obtient une image de la Terre de nuit (qui provient de /usr/share/xplanet/images/night.jpg).

Fichier coords.txt

+44.80 +0.58 "0&1" #Bordeaux, France
+43.65 -79.38 "2" #Toronto, Canada
+59.92 +10.75 "3" #Oslo, Norway
-29.99 -51.22 "4" #Porto Alegre, Brazil
+60.22 +24.66 "5" #Espoo, Finland
+18.91 -98.97 "6" #Oaxtepec, Mexico
+55.96 -3.19 "7" #Edinburgh, Scotland
-37.96 -57.59 "8" #Mar del Plata, Argentina
+39.60 -6.08 "9" #Extremadura, Spain
+40.74 -74.00 "10" #New York City, USA
+44.78 +17.21 "11" #Banja Luka, Republika Srpska, Bosnia and Herzegovina
+12.14 -86.25 "12" #Managua, Nicaragua
+46.87 +6.75 "13" #Le Camp, Vaumarcus, Switzerland
+45.53 -122.67 "14" color=white #Portland, Oregon, USA
+49.24 +8.42 "15" color=yellow #Heidelberg, Germany

Le fichier a simplement été mis à jour (ajout d’Heidelberg, décalage des couleurs).

À bientôt !


15 July, 2014 08:56PM par ascendances

16 June 2014

Christophe Nowicki

Déploiement “en masse” de noyau Linux personnalisé et durci à l’aide de Puppet

200px-Pax_tux

Comme tout barbu qui se respecte, j’aime avoir un noyau Linux, dont la configuration correspond parfaitement au matériel et à l’utilisation d’une machine.

Pour cela j’ai développé un module Puppet qui permet de déployer des noyaux Linux personnalisés et durcis.

Problématique

Compiler et personnaliser la configuration du noyau d’une seule machine est une tâche qui nécessite :

  • une bonne connaissance des options du noyau ;
  • connaissance du matériel et des drivers correspondants ;
  • du temps ;

Il y a de cela une dizaines d’année il était fréquent de compiler une version personnalisée du noyau Linux, mais aujourd’hui le noyau fourni par une distribution GNU/Linux, contient une grande quantité de pilotes et couvre la plupart des besoins.

Il n’y a pas de différence de performance entre un pilote de périphériques compiler en “dur” dans le noyau et charger en modules.

Les seules raisons de compiler un noyau personnalisé sont :

  • la vitesse de démarrage ;
  • et la sécurité.

C’est ce dernier point qui m’a poussé à mettre en place un système de compilation de noyau Linux automatisé.

Module Puppet

Le module Puppet dispose des fonctionnalités suivantes :

  • installation et décompression des sources du noyau dans /usr/src ;
  • application du patch grsecurity ;
  • écriture d’un fichier de configuration personnalisé ;
  • re-compilation du noyau et création d’un paquet pour la distribution Debian GNU/Linux ;
  • compilation en cas de changement de la configuration ;
  • TODO : installation du paquet et reboot sur le nouveau noyau à l’aide de kexec ;

Gestion de la configuration du noyau

D’après le LKDDb (Linux Kernel Driver DataBase), il y a plus de 19 000 options différentes dans un noyau Linux.

L’approche classique pour la gestion d’un tel nombre d’options est l’utilisation d’un tableur Excel ;-)

Mais la plupart des utilisateurs conservent les fichiers de configuration directement sur le système de fichier ou dans un logiciel de gestion de version.

Mais cette approche ne me satisfait pas, j’ai donc opté pour l’utilisation d’une base de données hiérarchique : Hiera

Structure hiérarchique

La structure adoptée est la suivante :

# /etc/puppet/hiera.yaml
---
:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hiera/
:logger: puppet
:hierarchy:
  - "fqdn/%{::fqdn}"
  - "boardproductname/%{::boardproductname}"
  - "hardwaremodel/%{::hardwaremodel}"
  - common

common.yaml

Contient la configuration commune à toutes les machines et la “négation” des options, ce qui évite à make-kdpkg de choisir une option par défaut :

# /etc/puppet/hiera/common.yaml
---
linux-grsec::kernel::config:
    CONFIG_CGROUP_DEBUG: n
    CONFIG_CGROUP_FREEZER: n
    CONFIG_CGROUP_DEVICE: n
    CONFIG_CPUSETS: n
    CONFIG_PROC_PID_CPUSET: n
    CONFIG_CGROUP_CPUACCT: n
    CONFIG_RESOURCE_COUNTERS: n
    CONFIG_MEMCG: n
    CONFIG_CGROUP_HUGETLB: n
    CONFIG_CGROUP_PERF: n
    CONFIG_CGROUP_SCHED: n
    CONFIG_FAIR_GROUP_SCHED: n
    CONFIG_CFS_BANDWIDTH: n
    CONFIG_RT_GROUP_SCHED: n
    CONFIG_BLK_CGROUP: n
    CONFIG_CHECKPOINT_RESTORE: n    
    CONFIG_GRKERNSEC: y
    CONFIG_GRKERNSEC_CONFIG_AUTO: n
    CONFIG_GRKERNSEC_CONFIG_CUSTOM: y
    CONFIG_PAX: y
...

Répertoires hardwaremodel et boardproductname

Le répertoire hardwaremodel contiens la définition d’un architecture :

/etc/puppet/hiera/hardwaremodel/
├── i586.yaml
├── i686.yaml
└── x86_64.yaml

Comme par exemple l’architecture x86_64:

# /etc/puppet/hiera/hardwaremodel/x86_64.yaml
---
linux-grsec::kernel::config: 
    CONFIG_64BIT: y
    CONFIG_X86_64: y
    CONFIG_OUTPUT_FORMAT: '"elf64-x86-64"'
    CONFIG_ARCH_DEFCONFIG: '"arch/x86/configs/x86_64_defconfig"'

Le répertoire boardproductname contient la définition des pilote de périphériques pour une machine :

/etc/puppet/hiera/boardproductname/
├── beagleboneblack.yaml
├── C7Q67.yaml
├── D33217GKE.yaml
├── DN2800MT.yaml
├── net5501.yaml
├── net6501.yaml
├── raspberrypi.yaml
├── wandboard.yaml
├── X7SPA-HF.yaml
├── X9SCL.yaml
└── Z68MA-D2H-B3.yaml

Par exemple, pour un net5501 de Soekris Inc. :

# /etc/puppet/hiera/boardproductname/net5501.yaml
---
linux-grsec::kernel::config:
    CONFIG_SMP: n
    CONFIG_X86_64_SMP: n
    CONFIG_X86_32_SMP: n
    CONFIG_RCU_FANOUT: 32
    CONFIG_MGEODE_LX: y
    CONFIG_X86_GENERIC: n
    CONFIG_GENERIC_CPU: n
    CONFIG_NET_VENDOR_VIA: y
    CONFIG_VIA_RHINE: y
    CONFIG_VIA_RHINE_MMIO: y
    CONFIG_HW_RANDOM_GEODE: y
    CONFIG_FB_GEODE: y
    CONFIG_CRYPTO_DEV_GEODE: y
    CONFIG_CRC_T10DIF: y
    CONFIG_ATA_GENERIC: y
    CONFIG_PATA_CS5536: y
    CONFIG_CS5535_MFGPT: y
    CONFIG_SENSORS_PC87360: y
    CONFIG_I2C: y
    CONFIG_SCx200_ACB: y
    CONFIG_LEDS_NET5501: y

Répertoire fqdn

Le répertoire fqdn contient les options spécifique à une machine et à ses fonctionnalités (ici une gateway VPN avec StrongSwan et l’IPS Suricata ) :

# /etc/puppet/hiera/fqdn/foo.bar.yaml
---
linux-grsec::kernel::config:
# StrongSwan
    CONFIG_XFRM_USER: y
    CONFIG_NET_KEY: y
    CONFIG_NET_KEY_MIGRATE: n
    CONFIG_IP_ADVANCED_ROUTER: y
    CONFIG_IP_MULTIPLE_TABLES: y
    CONFIG_INET_AH: y
    CONFIG_INET_ESP: y
    CONFIG_INET_IPCOMP: y
    CONFIG_INET_XFRM_MODE_TRANSPORT: y
    CONFIG_INET_XFRM_MODE_TUNNEL: y
    CONFIG_INET_XFRM_MODE_BEET: y
    CONFIG_NET_IPVTI: n
    CONFIG_IPV6: y
    CONFIG_INET6_AH: y
    CONFIG_INET6_ESP: y
    CONFIG_INET6_IPCOMP: y
    CONFIG_INET6_XFRM_MODE_TRANSPORT: y
    CONFIG_INET6_XFRM_MODE_TUNNEL: y
    CONFIG_INET6_XFRM_MODE_BEET: y
    CONFIG_IPV6_MULTIPLE_TABLES: y
    CONFIG_IPV6_SUBTREES: n
    CONFIG_NETFILTER: y
    CONFIG_NETFILTER_XTABLES: y
    CONFIG_NETFILTER_XT_MATCH_POLICY: y
# Suricata
    CONFIG_NETFILTER_ADVANCED: y
    CONFIG_BRIDGE_NETFILTER: n
    CONFIG_NETFILTER_NETLINK_QUEUE: y
    CONFIG_NETFILTER_NETLINK_ACCT: y
    CONFIG_NETFILTER_XT_TARGET_NFQUEUE: y
...

Configuration finale

$ hiera -h  linux-grsec::kernel::config ::hardwaremodel i586 ::boardproductname net5501 ::fqdn foo.bar
{"CONFIG_NETFILTER_XT_MATCH_STATISTIC"=>"n",
 "CONFIG_BLK_DEV_RSXX"=>"n",
 "CONFIG_USB_CATC"=>"n",
 "CONFIG_MMU"=>"y",
 "CONFIG_GPIO_BCM_KONA"=>"n",
 "CONFIG_CHELSIO_T4VF"=>"n",
 "CONFIG_SERIAL_CORE"=>"y",
 "CONFIG_DM_MIRROR"=>"y",
 "CONFIG_IO_DELAY_TYPE_NONE"=>3,
 "CONFIG_MMC_TEST"=>"n",
...

Exemple d’utilisation

# puppet agent -t
...
info: Applying configuration version '1402952642'
notice: /Stage[main]/Linux-grsec::Kernel/File[/usr/src/foo.config]/ensure: created
info: /Stage[main]/Linux-grsec::Kernel/File[/usr/src/foo.config]: Scheduling refresh of Exec[make-kpkg]
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/linux-3.14.4.tar.xz]/ensure: defined content as '{md5}c7c565d14833550faa39ef8279272182'
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/grsecurity-3.0-3.14.4-201405141623.patch]/ensure: defined content as '{md5}e88a81b0c222d14e228dc29dd76a875a'
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/grsecurity-3.0-3.14.4-201405141623.patch.sig]/ensure: defined content as '{md5}737b22b6e8cae0d4398ba3f68acaf1e1'
notice: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4/grsecurity]/returns: executed successfully
info: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4/grsecurity]: Scheduling refresh of Exec[make-kpkg]
notice: /Stage[main]/Linux-grsec::Install/Exec[/usr/src/linux-3.14.4]/returns: executed successfully
notice: /Stage[main]/Linux-grsec::Install/File[/usr/src/linux-3.14.4/.config]/ensure: created
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: exec make kpkg_version=12.036+nmu3 -f /usr/share/kernel-package/ruleset/minimal.mk debian APPEND_TO_VERSION=-foo  INITRD=YES 
...
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: cp -pf debian/control.dist          debian/control
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: make[2]: Leaving directory `/usr/src/linux-3.14.4'
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]/returns: make[1]: Leaving directory `/usr/src/linux-3.14.4'
notice: /Stage[main]/Linux-grsec::Install/Exec[make-kpkg]: Triggered 'refresh' from 2 events
notice: Finished catalog run in 179.65 seconds
..
# dpkg -i linux-*.deb

Conclusion

Ce système me permet de déployer des noyaux GRSec sur la petite dizaine de machines de mon réseau local.

Cette méthode ne convient pas au domaine de l’embarqué, (rasberrypi, beaglebone black, wandboard, etc… ) car l’espace disque et la puissance de calcul nécessaire ne sont pas disponible sur ce type de machine.

Références

16 June, 2014 09:33PM par cscm

02 June 2014

Philippe Latu

Génération automatisée de clé pour SSH sur un commutateur Cisco

Pour qui à l'habitude de l'arborescence des systèmes Unix, la gestion du système de fichiers de l'IOS de Cisco est pour le moins «singulière». Ce billet illustre les mésaventures rencontrées dans la gestion des configuration des commutateurs 2960 et 3560.

Au départ, mon objectif est de rendre systématique l'utilisation de SSH pour l'accès à l'interface de configuration (CLI) des commutateurs des salles de travaux pratiques. Dans ce but, j'ai créé des patrons de fichiers de configuration dans lesquels figurait la commande de génération de clé. Une fois le commutateur relancé, la première tentative de connexion échoue. Mauvaise surprise !

Voyons si la génération de clés RSA peut être déclenchée automatiquement.

Tout d'abord, les choses qui fâchent

Comme annoncé, tout débute par une grosse déconvenue :

$ ssh admin@sw09-213.infra.stri
ssh: connect to host sw09-213.infra.stri port 22: Connection refused

En redémarrant le commutateur avec le cordon console connecté et l'outil minicom lancé, on relève le message suivant :

% Rsa keys can't be generated by the startup configuration

Après moultes recherches, notamment sur Cisco Technical Support Forum, l'argument qui explique ce comportement s'appuie sur le fait que la génération de clé est une opération unique effectuée lors du déploiement d'un équipement. Le premier message d'erreur ci-dessus est dû au fait que la clé n'a pas été générée et/ou sauvegardée. Or, dans un contexte de travaux pratiques, les configurations sont constamment effacées et réécrites. Nous sommes donc amenés à la question du lieu de stockage de clé.

Au niveau CCNA on apprend que, sur un commutateur, tout est stocké en mémoire flash. Nous devons donc observer le contenu de cette mémoire flash parallèlement aux opérations sur les clés.

sw09-213#sh flash: 

Directory of flash:/

    2  -rwx       10227  May 30 2014 11:26:18 +02:00  recovery-confg
    3  -rwx         556   Mar 1 1993 01:00:39 +01:00  vlan.dat
    4  -rwx    11792247  May 27 2014 22:34:31 +02:00  c2960-lanbasek9-mz.150-2.SE6.bin
    5  -rwx        3096  May 30 2014 11:46:43 +02:00  multiple-fs
    6  -rwx           5  May 30 2014 11:46:43 +02:00  private-config.text
    7  -rwx       16165  May 30 2014 11:46:43 +02:00  config.text

32514048 bytes total (20688896 bytes free)

Les deux fichiers de configuration sont marqués en couleur dans la copie d'écran ci-dessus.

  • Le fichier config.text contient la configuration du commutateur utilisée lors d'un redémarrage.
  • Le fichier private-config.text ne contient pas grand chose pour l'instant ; vu sa taille.

Allons-y pour la génération de clé. J'avais publié un billet «façon antisèche» sur cette question il y a quelques temps déjà : Compte utilisateur local & accès SSH sur un équipement Cisco. On reprend la démarche après avoir vérifié qu'aucune clé n'est déjà présente dans la configuration courante.

sw09-213#sh crypto key mypubkey all
sw09-213#
sw09-213#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw09-213(config)#crypto key generate rsa label SSH-KEY modulus 4096
The name for the keys will be: SSH-KEY

% The key modulus size is 4096 bits
% Generating 4096 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 504 seconds)

000023: May 30 14:54:30.551 MET: %SSH-5-ENABLED: SSH 2.0 has been enabled

On remarque que le service SSH s'est activé immédiatement après la création de clé. On peut aussi visualiser le résultat de l'opération en rappelant la commande sh crypto key mypubkey all.

Si on réinitialise le commutateur maintenant, tout le travail de génération de clé sera perdu sachant qu'aucune sauvegarde n'a encore été effectuée. C'est là que la bizarrerie commence. La seule commande de sauvegarde dont nous disposons est la suivante :

sw09-213#copy run start
Building configuration...
[OK]
sw09-213#sh flash: | incl config
    7  -rwx        6820  May 30 2014 15:00:54 +02:00  private-config.text
    8  -rwx       16165  May 30 2014 15:00:54 +02:00  config.text

Alors que le fichier config.text n'a pas changé de taille, le fichier private-config.text est passé de 5 à 6820 octets. Notre clé est stockée dans ce dernier fichier. La commande copy running-config startup-config copie les clés dans la mémoire flash: en plus de la configuration courante du système.

L'effacement fonctionne comme la copie. La commande erase startup-config efface les deux fichiers private-config.text et config.text. Au redémarrage suivant, le commutateur a perdu sa configuration et son jeu de clés RSA. Malheureusement, il semble qu'il soit impossible de préserver une copie de sauvegarde du fichier private-config.text. Seul le fichier config.text peut être recopié en mémoire flash.

Une fois que les manipulations sont terminées, l'utilisation de la commande erase startup-config est recommandée dans tous les supports de travaux pratiques des curriculums Cisco. Il semble donc que nous soyons dans l'impasse.

Kron à la rescousse

Fort heureusement, nous pouvons contourner la difficulté grâce au service de planification des tâches baptisé kron. Bien entendu, ce service est loin d'offrir les possibilités d'un cron Unix. Sur les modèles de commutateurs 2960, il est seulement possible d'exécuter des commandes dites globales. Il n'est pas possible d'entrer directement dans le terminal de configuration.

Cependant, il est possible de charger un fichier contenant une suite de commandes de configuration via TFTP ou d'autres protocoles comme FTP ou HTTP. Les commandes contenues dans le fichier sont exécutées directement si la destination du transfert est le niveau d'exécution courant : system:/running-config.

Voici une copie de la partie intéressante du patron de configuration d'un commutateur.

!~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!~~~~~~~~~      kron
!
file prompt quiet
!
kron occurrence crypto-key in 3 oneshot
 policy-list crypto-key
!
kron occurrence backup-startup in 30 oneshot
 policy-list backup-startup
!
kron policy-list crypto-key
 cli copy tftp://cooper/crypto-key-confg running-config
!
kron policy-list backup-startup
 cli delete /force flash:recovery-confg
 cli copy startup-config flash:recovery-confg
 cli copy running-config startup-config
!
end

On relève deux suites d'instructions.

  • La première phase baptisée crypto-key est exécutée un seule fois 3 minutes après l'initialisation du commutateur. C'est ce «script» qui sert à provoquer la génération de clé.

    $ cat /srv/tftp/crypto-key-confg 
    ! Génération de clés RSA pour SSH
    crypto key generate rsa label SSH-KEY modulus 4096
    !
    end
  • La seconde phase baptisée backup-startup est aussi exécutée une seule fois au bout de 30 minutes après l'initialisation. Son but est de sauvegarder le jeu de clés RSA.

Attention ! Le choix des temps avant exécution des commandes n'est pas anodin. Il faut être sûr que le lien montant est actif et que le serveur TFTP est joignable avant de lancer un téléchargement. On tient compte notamment, du temps de convergence du protocole Spanning Tree.

Au final, on obtient les informations suivantes dans les journaux système. Le jeu de clés a bien été généré et il est enfin possible d'accéder au commutateur via SSH.

000020: Jun  2 18:58:36.092 MET: %SSH-5-ENABLED: SSH 2.0 has been enabled
000021: Jun  2 18:58:43.004 MET: %SYS-5-CONFIG_I: Configured from tftp://cooper/crypto-key-confg by admin on console

Cette méthode fonctionne aussi sur les commutateurs Cisco de la gamme supérieure comme les 3560 ou 3750.

Pour conclure, j'espère que ce billet pourra servir à quelques administrateurs d'équipements réseau et leur fera économiser un peu de temps pour faire des choses plus intéressantes. Avec ce genre de «Hack à 2€cts» nous sommes encore bien loin du Software Defined Network.

02 June, 2014 08:49PM par Philippe Latu

16 April 2014

Tanguy Ortolo

Signing party au salon Solutions Linux le 20 mai 2014

En ces temps troublés, il est important de sécuriser nos échanges d'information — en chiffrant — ainsi que la distribution de logiciels — en signant les publications.

À cette fin, le salon Solutions Linux, Libres et Open Source sera l'occasion d'une signing party PGP, le 20 mai 2014 à 18h près du stand Debian France. Cette signing party est ouverte à tous les visiteurs et exposants du salon.

Pour faciliter les échanges d'empreintes de clefs en cas d'affluence, il est possible que nous utilisions une liste officielle de participants selon le protocole de Zimmermann-Sassaman. Pour préparer cela, il est demandé aux participants de me contacter en m'envoyant leur clef publique. Selon la méthode de signing party retenue, je publierai ultérieurement des instructions plus précises.

16 April, 2014 06:45PM par Tanguy

15 April 2014

Florent Gallaire

Lucas 2.0

Lucas Nussbaum vient d’être réélu Debian Project Leader.

Comme on peut le constater sur ce graphe, il a obtenu 47 voix de plus que Neil McGovern :

Une analyse plus précise des votes permet d’en calculer une représentation plus “classique” du point de vue des habitudes électorales, et donc plus compréhensible pour la majorité des gens :

Lucas Nussbaum : 56,5%
Neil McGovern : 43,5%

C’est bien une large victoire de Lucas, mais aussi une défaite très honorable pour Neil, qui se positionne donc comme un prétendant sérieux à la victoire l’année prochaine.

flattr this!

15 April, 2014 04:36PM par fgallaire

11 April 2014

Roland Mas

Une page de publicité

Allez, c'est vendredi, c'est permis, je vais m'autoriser deux petites annonces.

Premièrement : rappelez-vous Minami Taiko, ce groupe de tambours japonais du sud de la France. Bon, nous on est des amateurs, mais il se trouve qu'on fait venir, pour le festival Escale à Sète, un vrai groupe de taikos du Japon et tout. Ils s'appellent SEN, et ils vont faire quelques animations musicales dans Sète du 18 au 21 avril. Et avant de repartir dans leur lointain Cipango, ils feront un vrai concert à Montpellier, le mardi 22 avril au soir, sur le campus de l'INRA/Supagro. Et devinez qui fait la première partie ? Minami Taiko, voilà qui ! Donc si vous voulez découvrir le taiko ou voir quelques amateurs suivis d'un vrai groupe, faites donc un tour sur le site de Minami Taiko. À noter qu'il y a aussi un atelier d'initiation le même jour si ça vous intéresse.

Deuxièmement : je suis fier de vous présenter un petit site web que c'est moi qui l'ai fait avec mes petits doigts délicats. Ça s'appelle Chacun sa part, et ça sert à faire des comptes entre amis, genre quand on part en vacances ensemble, ou qu'on fait régulièrement des dépenses partagées dans un groupe de gens. Pour éviter des comptes d'apothicaire à chaque restau, chaque tournée au bar, chaque passage en caisse, on saisit la dépense sur le site, on dit qui a payé et qui a participé, et le site calcule automatiquement les soldes de chacun et propose des suggestions de remboursements pour rééquilibrer les comptes. Y'a un système d'invitations pour que chacun puisse consulter l'état du groupe et saisir des dépenses, des QR-codes pour faciliter la vie aux utilisateurs de smartphone, et même si ça n'a pas encore été testé à grande échelle ça a été validé par une poignée de testeurs dans différentes configurations. Allez-y, c'est cadeau. Chacun sa part. Point com.

11 April, 2014 08:06AM

04 April 2014

Florent Gallaire

Quel DPL pour 2014 ?

Le temps passe vite, et cela fait déjà presque un an que Lucas Nussbaum a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 3 et le 9 mars à la suite du traditionnel appel à candidatures.

Dès le 13 février, anticipant quelque peu sur le calendrier, Lucas avait exprimé le souhait de se représenter :

As it has been done by other DPLs in the past, I think that it makes sense for the DPL to announce his/her plans way before the next DPL election.

So, let’s do that now: I will run for reelection.

Après ses précédentes tentatives infructueuses de 2004, 2012 et 2013, Gergely Nagy s’était représenté, mais il a finalement dû se résoudre à retirer sa candidature :

Due to unexpected events, my plans and life got turned upside down (for the better) in the past few days, and because of that, I have to scale down a number of things. Unfortunately, running for DPL is one such thing.[...] Therefore, after a lot of thought, I’m withdrawing from the Debian Project Leader elections of 2014.

Le seul concurrent de Lucas est donc finalement Neil McGovern. Le plus important est bien sûr de lire les programmes de chacun des candidats :

Les presque mille développeurs Debian sont libres de faire leur choix depuis le 31 mars et jusqu’au 13 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

flattr this!

04 April, 2014 12:21AM par fgallaire

28 March 2014

Tanguy Ortolo

Payez en liquide (et autres mesures de protection de la vie privée)

TL;DR¹ : les banques cherchent à exploiter les données de paiement par carte bancaire, il est donc temps de revenir au bon vieux liquide, intraçable et anonyme.

Développement d'une possibilité de surveillance généralisée

Notre vie privée s'érode petit à petit, tandis que s'instaure une possibilité de surveillance généralisée. C'est particulièrement visible avec le développement des systèmes de traitement automatique ces dernières décennies, mais ce mouvement est en réalité plus ancien :

Développement d'une possibilité de surveillance généralisée

Notre vie privée s'érode petit à petit, tandis que s'instaure une possibilité de surveillance généralisée. C'est particulièrement visible avec le développement des systèmes de traitement automatique ces dernières décennies, mais ce mouvement est en réalité plus ancien :

  • Dans l'Antiquité, puis au Moyen-Âge, l'État ne connaissait pas d'une façon générale l'identité de ses ressortissants ni de ses habitants, à moins d'effectuer de coûteux recensements.
  • Puis, je ne sais quand, un premier fichage systématique a eu lieu, de sorte que nous sommes connus par l'État dès notre naissance.
  • Un jour, il est devenu indispensable en pratique d'utiliser les services de banques, qui connaissent et disposent des pleins pouvoirs sur l'essentiel de notre patrimoine financier.
  • Depuis l'introduction de la carte bancaire, les banquiers savent pour la plupart de leurs clients où ils se déplacent et où et quand ils effectuent leurs achats.
  • Depuis l'introduction de la vente à distance, notamment par Internet, ces fournisseurs savent exactement ce que chacun de leurs clients leur achètent. Il en est de même pour le commerce local avec les cartes de fidélités, qui ont été créées pour cela.
  • Avec les téléphones portables, les opérateurs connaissent, à la cellule GSM près, les déplacements de tous leurs clients.
  • Avec l'introduction des titres de transport nominatifs tels que les cartes Navigo ou Vélib' à Paris, les régies de transport en commun connaissent avec une précision de l'ordre de la centaine de mètres tous les déplacements d'une grande partie des habitants de ces villes.

En quelques siècles, nous sommes donc passés d'une situation où, sorti du cercle des voisins, des amis et de la famille, chacun était inconnu et ses actions anonymes, à une situation où nous sommes connus et fichés dès notre naissance, et où des entreprises privées connaissent très précisément nos déplacements et nos achats, sans parler de nos communications. Chose plus inquiétante, on s'habitue peu à peu à ce qui paraissait scandaleux il y a quelques dizaines d'années et qui l'est pourtant toujours autant.

Dernières nouvelles : l'exploitation des données d'utilisation des cartes bancaires

Cartes de crédit

Il est souvent objecté que ces entreprises n'exploitent pas ces données. C'est parfois vrai, mais l'expérience montre que lorsqu'il y a une possibilité qu'un abus soit commis, cela arrive tôt ou tard². Face au risque d'exploitation des données d'utilisation des cartes bancaires, on suppose ainsi que ces données n'intéressent pas les banquiers. Sauf que : en fait si.

Limiter l'exploitation de nos données personnelles

Au niveau personnel, il est possible de limiter l'exploitation de données nous concernant, simplement en évitant de les fournir au départ. Comme souvent, il s'agit d'un compromis entre la vie privée parfaite et la fonctionnalité complète. Ainsi, voici une liste de propositions qui permettent de limiter la casse en restant à un niveau de contrainte raisonnable :

  • Payer en liquide : cela implique d'effectuer des retraits de montants plus élevés au distributeur le plus proche de chez soi, d'avoir sur soi un peu plus de liquide et d'en stocker une petite réserve de liquide chez soi. À la rigueur, payer par chèque, les banques enregistrant bien moins d'informations qu'avec les cartes bancaires.
  • Préférer les magasins locaux à la vente à distance. En plus ça coûte moins cher en transport, et par conséquent ça pollue moins.
  • Se déplacer de façon anonyme : si on doit utiliser une carte de transport, prendre la version anonyme, qui existe grâce à la contrainte de la CNIL sur les régies de transport.
  • Éteindre son téléphone mobile pendant les déplacements : il n'est certainement pas pratique de l'éteindre tout le temps, mais puisqu'il est de toute façon interdit de téléphoner en voiture ou à vélo, et que c'est très peu pratique en bus ou en métro, autant ne pas révéler notre position pendant les transports. Même chose pendant les promenades, randonnées ou sorties en général : si on ne s'attend pas à être appelé ou à devoir appeler quelqu'un, autant éteindre le téléphone, en plus ça économise de l'énergie.

Notes

  1. Too long; didn't read, soit trop long, pas lu. C'est un résumé pour décideurs pressés.
  2. Voyez par exemple le cas des verrous numériques sur les livres, qui permettent aux vendeurs de désactiver à distance la lecture d'un livre acheté par un lecteur. Bah, de toute façon ils ne le feront jamais, tu t'inquiètes pour rien. Ah, ben en fait si, Amazon l'a fait. 743.

28 March, 2014 01:36PM par Tanguy

11 March 2014

Rodolphe Quiédeville

Debian, PG9.3, Osmosis et Nominatim

Même en se basant sur des références en terme de stabilité il peut arriver que certains combos soient fatals à votre production. C'est ce qui m'est arrivé récemment pour un serveur Nominatim installé pourtant sur une Debian Wheezy, osmosis est utilisé pour la mise à jour continue de la base Nominatim et m'a fait des misères que je m'en vais vous conter.

En parallèle de la version de PostgreSQL 9.1 standard Debian j'ai installé sur la machine une 9.3 en provenance du dépôt Debian de la communauté PG (le support dfe JSON dans PG 9.3 c'est awesome), jusque là tout va bien. Seulement à l'upgrade suivant le paquet libpostgis-java est passé en version 2.1.1-5.pgdg70+1 (celle-ci étant disponible sur le dépôt PG) ; malheureusement cette version est incompatible avec osmosis packagé chez Debian qui nécessite la version 1.5.3 de cette librairie, et là c'est le drâme !

Donc si au lancement d'osmosis vous rencontrez l'erreur :

java.io.FileNotFoundException: /usr/share/java/postgis.jar

Alors que le sus-dit fichier est bien présent, et que vous commencez à dire du mal des backtraces java, il existe un solution simple et efficace, downgrader la version de libpostgis-java en quelques commandes :

dpkg --remove osmosis
apt-get install libpostgis-java=1.5.3-2 osmosis

Sans oublier un pinning pour éviter la future mise à jour du paquet.

11 March, 2014 08:07AM par Rodolphe Quiédeville