16 July 2014

Tuxicoman

L’accélération 3D des cartes ATI radeon 7xxx avec le driver libre arrive dans Debian

Aujourd’hui, une mise à jour de xserver-xorg-core est arrivée dans Debian Testing.

Celle-ci active GLAMOR et par conséquence le support de l’accélération 3D pour les cartes ATI Southern Island (ATI Radeon 7750 et plus) dans les drivers libres radeon !

C’est donc avec une certaine joie que j’ai pu voir Blender, HoN, The Witcher2, Dota 2 enfin fonctionner sans le driver propriétaire Catalyst qui traine de vieux bugs. Ma carte étant de 2012, il était temps !

Ca fonctionne « out of the box ». Il n’y a pas de fichier de config à renseigner. Pour vérifier, lancez cette commande : $ glxinfo | grep OpenGL

Vous devriez voir ceci :

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
OpenGL ES profile extensions:

Seul hic, certains logiciels tels que Steam et HoN embarquent leur propres librairies GCC et là ca ne marche pas du premier coup. Vous verrez apparaître un message du style :

Error: OpenGL GLX context is not using direct rendering, which may cause performance problems.

Pour régler cela il faut supprimer les vieilles librairies libgcc et libstdc++ embarquées avec HoN ou Steam, ce qui forcera l’utilisation des librairies de votre système Debian à la place :

$ locate -e libgcc | grep « steam\|HoN » | xargs rm
$ locate -e libstdc++ | grep « steam\|HoN » | xargs rm

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

16 July, 2014 09:51PM par Tuxicoman

Raphaël Hertzog

Spotify migre 5000 serveurs de Debian à Ubuntu

Ou une raison de plus prouvant qu’il est important que Debian LTS soit un succès. L’année dernière nous avions eu la nouvelle que Dreamhost passait à Ubuntu parce qu’ils pouvaient maintenir une version stable de Ubuntu plus longtemps que la version stable de Debian (et ceci bien que Ubuntu n’assure que le support des logiciels dans la section principale, ce qui exclue un grand nombre de logiciels populaires).

Spotify Logo

Il y a quelques jours, nous apprenions que Spotify avait pris une décision similaire:

Il y a quelques temps, nous avons décidé de migrer vers Ubuntu pour nos serveurs de backend. Les principales raisons de ce changement étaient le cycle de publication prévisible et le support à long terme (cette décision prédate l’annonce que Debian s’engageait également à offrir un support à long terme). Avec la sortie de Ubuntu 14.04 LTS nous sommes maintenant en train de migrer nos ~5000 serveurs vers cette distribution.

Il s’agit d’un preuve supplémentaire, s’il en était besoin, que nous devons fournir un support à long terme des versions stables de Debian si nous voulons rester un choix pertinent dans les grands déploiements.

Mais la tâche est ingrate et il est difficile de trouver des volontaires pour l’assumer. C’est pourquoi je suis persuadé que la meilleure des solutions est de convaincre les entreprises de contribuer financièrement à Debian LTS.

Nous avons déjà convaincu une poignée de sociétés et juillet est le premier mois où des contributeurs payés ont rejoint l’effort Debian LTS pour une participation modeste de 21 heures de travail (suivez Thorsten Alteholz et Holger Levsen sur debian-lts et debian-lts-announce). Mais nous devons encore multiplier ce chiffre par 5 ou 6 au moins pour assurer un travail correct de maintenance de Debian 6.

C’est pourquoi je vous invite à télécharger le formulaire de souscription et à avoir une discussion avec votre encadrement. C’est le moment de convaincre votre entreprise de rejoindre cette initiative. N’hésitez pas à prendre contact si vous avez des questions ou si vous préférez que je contacte un représentant de votre entreprise. Merci !

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

16 July, 2014 08:57AM par Raphaël Hertzog

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. :) 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). Jusqu’ici les conférences ont eu lieu alternativement en Europe et […]

15 July, 2014 08:56PM par ascendances

13 July 2014

Raphaël Hertzog

Mes activités libre en juin 2014

Voici le récapitulatif mensuel de toutes mes activités gravitant autour du logiciel libre. Si vous faites partie des personnes ayant fait un don pour soutenir mon travail (168,17 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Debian LTS

Après avoir mis en place l’infrastructure permettant aux entreprises de contribuer financièrement à Debian LTS, j’ai passé pas mal de temps à ébaucher l’annonce du lancement de Debian LTS (sur une suggestion de Moritz Mühlenhoff, qui m’a fait remarquer qu’aucune communication n’avait encore été faite en ce sens).

Je suis plutôt content des résultats, car nous avons réussi à faire mention d’une offre commerciale sans déclencher une levée de boucliers de la part de la communauté. Cette offre est (à mon sens, ce qui est nécessairement subjectif) clairement dans l’intérêt de Debian, mais dans la mesure où l’argent ne lui revient pas nous avons pris des précautions supplémentaires : lorsque j’étais en contact avec les chargés de presse, j’ai systématiquement inclus le Chef de projet Debian dans la discussion et ses retours ont été d’une grande aide dans l’amélioration de l’annonce. Il a également officiellement approuvé le communiqué de presse, afin de conforter les chargés de presse dans leur décision de publier le communiqué.

Lucas m’a également poussé à demander le retour de la communauté vis-à-vis de cette ébauche de communiqué, ce que j’ai fait. La discussion a été constructive et le brouillon n’en a été qu’encore plus abouti.

La nouvelle a été largement relayée, le revers de la médaille étant que l’appel à contribuer n’a quasiment pas retenu l’attention de la presse. Même Linux Weekly News a fait l’impasse !

Du côté de Freexian, nous venons juste de passer la barre des 10% d’un « équivalent temps plein » (financé par 6 entreprises), et nous sommes en contact avec plusieurs autres sociétés. Nous sommes toutefois encore loin de notre but et nous devons rechercher activement d’autres soutiens. Connaissez-vous des entreprises qui font encore tourner des serveurs sous Debian 6 ? Si oui, je vous serai gré de m’en faire savoir un peu plus (nom + url + contact si possible) en m’écrivant à deblts@freexian.com, de sorte à ce que je puisse prendre contact et les inviter à participer au projet.

Distro Tracker

Dans la continuation du concours Debian France, j’ai continué à travailler avec Joseph Herlant et Christophe Siraut sur de multiples améliorations de distro tracker. Ce afin de préparer son déploiement sur tracker.debian.org (que je viens tout juste d’annoncer \o/).

Debian France

Le concours Debian France étant fini, j’ai expédié les récompenses. Cinq livres ont donc été envoyés à :

Travaux Debian divers

J’ai déclaré sql-ledger orphelin et réalisé un dernier envoi (d’une nouvelle version amon) pour changer son mainteneur en Debian QA.

Après avoir été ennuyé plusieurs fois par dch estropiant mon nom dans les journaux de modification, j’ai soumis le rapport n°750855, qui a été rapidement corrigé.

J’ai désactivé un patch défectueux de quilt, afin de corriger un bogue critique pour la publication : n°751109

J’ai soumis le rapport n°751771 lorsque j’ai découvert une dépendance incorrecte vers ruby-uglifier, tandis que je travaillais à l’empaquetage pour Kali Linux.

J’ai testé de nouvelles versions de ruby-libv8 sur armel/armhf à la demande de l’auteur amont. Je lui ai remonté des erreurs de compilation (cf. le ticket github).

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 June 2014 contribuée par Weierstrass01.

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

13 July, 2014 12:18PM par Raphaël Hertzog

27 June 2014

Debian France

Debian France soutient April et l'AFUL

Debian France soutient April et l'AFUL

Debian France vient d'adhérer à l'AFUL afin de soutenir ses actions. L'AFUL, association des utilisateurs francophones de logiciel libre, s'assure de la promotion du logiciel libre mais porte aussi des actions en justice contre la vente liée.

Debian France partage les objectifs de l'AFUL dans ses efforts de la diffusion du logiciel libre.

En parallèle, Debian France a renouvelé son adhésion à April.

27 June, 2014 04:13AM

Debian LTS

Debian LTS

Le projet Debian vient d'annoncer la mise en place d'un support à long terme de Debian 6 et recherche des solutions pour pérenniser cette initiative et l'étendre aux prochaines versions (Debian 7 « Wheezy » et Debian 8 « Jessie »)

Dans le cadre de ce programme, quelques développeurs Debian se sont organisés pour que les entreprises puissent facilement apporter leur pierre à l'édifice en souscrivant à un offre de service dédiée de la société Freexian.

Utilisateurs de Debian dans un cadre professionnel, Debian France vous encourage à soutenir cette initiative.

Plus d'informations

27 June, 2014 04:13AM

18 June 2014

Aurélien Jarno

Debian is switching (back) to GLIBC

Five years ago Debian and most derivatives switched from the standard GNU C Library (GLIBC) to the Embedded GLIBC (EGLIBC). Debian is now about to take the reverse way switching back to GLIBC, as EGLIBC is now a dead project, the last release being the 2.19 one. At the time of writing the glibc package has been uploaded to experimental and sits in the NEW queue.

EGLIBC is dead for a good reason: the GLIBC development has changed a lot in the recent years, due to two major events: Ulrich Drepper leaving Red Hat and the GLIBC development, and the GLIBC steering committe self-dissolving. This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory. Before we used to have two sets of architectures, the main ones in the glibc repository with architectures like x86, SuperH or SPARC, and the secondary ones in the glibc-ports repository with architectures like ARM or MIPS. As you can see the separation was quite arbitrary, and often leaded to missing changes on the secondary architectures. We also got real stable branches, with regular fixes.

The most important EGLIBC features have been merged to GLIBC, including for example the use of non-bash but POSIX shell, or the renaming of reserved keywords. The notable exception is the support for configurable components, which we originally planned to use for Debian-Installer, by building a smaller flavor using -Os and without NIS and RPC support. At the end we never worked on that, and it seems that the hardware targeted by Debian has grown faster than the GLIBC size, so that is not really a big loss. At the end, we ended up with only 5 missing patches from the EGLIBC tree:

The package names are unchanged (except the source package and the binary package containing the sources) so the transition is fully transparent for the users.

I would like to thank all the CodeSourcery employees who worked on EGLIBC, with a special thank to Joseph Myers who spent countless hours to merge the most important EGLIBC changes back to GLIBC, and sent regular emails about the merge status. I would also like to thanks all the people on the GLIBC side that made the change to happen, and all persons participating in the GLIBC development.

18 June, 2014 08:04PM par aurel32

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.</para>

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 07:49PM par Philippe Latu

31 May 2014

Tuxicoman

FSlint, supprimer efficacement les doublons sur votre disque dur

fslint  permet de détecter les fichiers en double sur son disque dur et propose une interface pratique pour supprimer ceux qui vous font perdre le plus d’espace de stockage.

Normalement, il devrait être dans les dépots de votre distribution.

C’est une alternative à fdupes présenté récemment par « La vache libre ».

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

31 May, 2014 11:02PM par Tuxicoman

05 May 2014

Vincent Bernat

Dashkiosk: gestion d'écrans pour tableaux de bord

Dashkiosk est une solution permettant de gérer de manière centralisée l’affichage de tableaux de bord sur plusieurs écrans. Il comprend quatre parties :

  1. Une partie serveur va piloter les écrans en leur envoyant les URL à afficher. Une interface web permet de configurer des groupes de tableaux de bord et de les associer à un ensemble d’écrans.

  2. Un récepteur tourne sur chaque écran dans un navigateur web. Au démarrage, il contacte le serveur et attend l’URL à afficher.

  3. Une application Android fournit un navigateur en plein écran pour faire tourner le récepteur.

  4. Une application Chromecast joue le même rôle mais pour les clefs Google Chromecast. Le serveur est capable de piloter ces dernières à l’aide de nodecastor, une réimplementation de l’API de pilotage.

La vidéo ci-dessous démontre les capacités de Dashkiosk en quelques minutes. Elle est aussi disponible au format Ogg Theora.

<iframe frameborder="0" height="270" src="http://www.dailymotion.com/embed/video/x1sy4x7" width="480"></iframe>

05 May, 2014 06:39PM par Vincent Bernat

03 May 2014

Philippe Latu

Autoconfiguration IPv6 stateless et multicast DNS

En voyant les difficultés rencontrées par les étudiants dans la mise en œuvre du protocole IPv6, je me suis décidé à rédiger un nouvel article sur l'autoconfiguration IPv6. L'objectif de ce document est de poser les bases de l'argumentation en faveur des communications sans suivi d'état (stateless) et de rassembler les éléments nécessaires à la mise en route d'une maquette de projet. Les communications IPv6 ne sont pas la finalité, elles constituent juste la première étape avant de passer aux services de la couche application. Il est terriblement frustrant de constater que cette première étape constitue trop souvent un mur infranchissable. Mon espoir est que le fait d'avoir compilé en un seul article des ressources disséminées sur le Net permettra d'arriver plus vite à un fonctionnement correct et fera avancer la compréhension de l'utilisation d'IPv6. Il est de coutume de dire que l'adoption du protocole IPv6 est freinée par le fait qu'elle nécessite la coopération de tous les acteurs ; des développeurs jusqu'aux opérateurs réseau. Le développement de l'Internet des objets pourrait bien être, enfin, le nouvel usage déterminant dans cette adoption.

L'interconnexion réseau type utilisée pour illustrer le propos rassemble les briques de base : un tunnel d'accès au réseau public, des routeurs et deux VLANs. Par commodité, j'ai utilisé des instances de machines virtuelles et Open vSwitch, mais ce n'est pas une obligation.

Maquette autoconfiguration IPv6

IPv6 n'est pas le seul écueil dans le déroulement des enseignements. Dire que le service DNS est une pièce critique et essentielle est un lieu commun. Mais, quand on arrive à conclure qu'une application ne marche pas et à rester bloqué devant la fenêtre vide de WireShark parce que le fichier /etc/resolv.conf est vide, on est «en droit de s'inquiéter». Que faire pour dépasser ce genre de blocage ?

Sachant que la mise en œuvre d'une infrastructure DNS au début de chaque séance de travaux pratiques est irréaliste, le service multicast DNS (mDNS), qui est sans infrastructure, est une solution très intéressante. Lorsque j'ai rédigé le document Initiation au développement C sur les sockets IPv4 & IPv6, j'ai inclus une infrastructure DNS complète. C'est certainement beaucoup trop lourd à utiliser en séance. La situation s'est reproduite dans le billet NIS, NFSv4, autofs5 & dual stack IPv4 + IPv6 ; même si dans ce dernier cas, le cocktail de tous les services à utiliser était long à installer en tout état de cause.

Dans la section Multicast DNS, j'essaie de montrer que même avec une résolution DNS classique «mal en point», il est toujours possible d'utiliser des noms d'hôtes et peut être d'éviter de conclure sur le mauvais fonctionnement d'une application qui n'a en réalité aucun problème ! Ceci dit, pour être tout à fait honnête, je n'ai fait que déplacer le problème du fichier /etc/resolv.conf au fichier /etc/nsswitch.conf ...

En bonus, il est possible de «propager» les enregistrements mDNS d'un domaine de diffusion à l'autre grâce à la fonction reflector du démon avahi.

Pour conclure ce billet, encore trop long, l'autoconfiguration IPv6 associée au service mDNS constitue une solution d'interconnexion réseau éphémère qui mérite que l'on s'y attarde. Son usage dépasse largement le cadre des enseignements.

03 May, 2014 03:25PM par Philippe Latu

27 April 2014

Vincent Bernat

Dépôts APT locaux en entreprise

Distribuer de manière efficace des logiciels sur l’ensemble d’une plateforme peut être ardu. Chaque distribution fournit un gestionnaire de paquets qui est généralement bien adapté à cette tâche. Dans le cas de Debian ou d’une distribution dérivée, il s’agit d’APT.

Certains logiciels ne sont pas présent dans les dépôts officiels ou peuvent être disponibles dans une version trop ancienne. La mise en place d’un dépôt local permet de contourner cet écueil.

Ce qui est présenté ici a été mis en place pour Dailymotion et a été fortement inspiré du travail de Raphaël Pinson chez Orange.

Configuration des dépôts locaux

Les dépôts à mettre en place peuvent se classer dans trois catégories :

  1. Les miroirs de distributions. Ils permettent d’économiser de la bande passante, d’obtenir un meilleur débit et un accès permanent même lorsque l’accès à Internet est perturbé.

  2. Les dépôts maisons pour vos propres paquets avec la possibilité de passer par une zone de test pour valider les paquets sur quelques machines avant de les pousser en production.

  3. Les miroirs pour les dépôts non officiels, tels que des PPA Ubuntu. Pour éviter tout changement inattendu, de tels dépôts sont aussi dôtés d’une zone de test et d’une zone de production.

Avant de continuer, il est important de s’accorder sur la terminologie à employer. Examinons une ligne issue de mon /etc/apt/sources.list:

deb http://ftp.debian.org/debian/ unstable main contrib non-free

Dans cet exemple, http://ftp.debian.org/debian/ est un dépôt et unstable est une distribution. Une distribution est divisée en un certain nombre de composants. Nous en avons ici trois : main, contrib et non-free.

La mise en place des différents dépôts se fera avec le logiciel reprepro. Ce n’est pas la seule solution disponible mais il est à la fois plutôt versatile et simple à mettre en place. reprepro ne gère qu’un seul dépôt. Le premier choix à effectuer est donc de savoir comment répartir les paquets dans les dépôts, les distributions et les composants.

Voici quelques billes pour choisir :

  • Un dépôt ne peut pas contenir deux paquets identiques (même nom, même version, même architecture).
  • À l’intérieur d’un composant, il n’est possible d’avoir qu’une seule version d’un paquet.
  • Habituellement, une distribution est un sous-ensemble des versions tandis qu’un composant est un sous-ensemble des paquets. Par exemple, dans Debian, la distribution unstable permet d’obtenir des paquets dans des versions très récentes tandis que le composant main permet de se limiter aux paquets respectant la DFSG.

En partant sur plusieurs dépôts, il faudra gérer plusieurs instances de reprepro et la copie entre deux instances se fait manuellement. À Dailymotion, nous sommes partis sur un seul dépôt, mais il aurait été possible de partir sur trois dépôts :

  • un pour les miroirs de distributions,
  • un pour les paquets maisons,
  • un pour les miroirs de dépôts tiers.

Voici ce que nous allons mettre en place :

Local APT repository

Mise en place

La première étape est de créer un utilisateur pour travailler sur les dépôts :

$ adduser --system --disabled-password --disabled-login \
>         --home /srv/packages \
>         --group reprepro

Toutes les opérations qui suivent doivent utiliser exclusivement cet utilisateur. Chaque dépôt aura son propre répertoire dans lequel on trouvera les sous-répertoires suivants :

  • conf/ qui contient les fichiers de configuration,
  • gpg/ qui contient les fichiers permettant de signer et authentifier les dépôts avec GPG1,
  • logs/ qui contient les journaux,
  • www/ qui contient les fichiers du dépôt à rendre visible par un quelconque server web.

Voici le contenu de conf/options :

outdir +b/www
logdir +b/logs
gnupghome +b/gpg

Créons la clef GPG pour signer le dépôt :

$ GNUPGHOME=gpg gpg --gen-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 10y
Key expires at mer. 08 nov. 2023 22:30:58 CET
Is this correct? (y/N) y

Real name: Dailymotion Archive Automatic Signing Key
Email address: the-it-operations@dailymotion.com
Comment: 
[...]

Un mot de passe vide permet à reprepro de tourner sans intervention de l’utilisateur (notamment pour les mises à jour nocturnes). La clef publique devra être distribuée pour permettre à APT de vérifier les signatures de l’archive. Une façon commode de faire est de la placer dans un paquet.

Miroir local d’une distribution officielle

Commençons par mettre en place un miroir pour Ubuntu Precise. Nous avons besoin de faire deux choses :

  1. Configurer une nouvelle distribution dans le fichier conf/distributions.
  2. Configurer les sources dans le fichier conf/updates.

Ajoutons ce bloc dans conf/distributions:

# Ubuntu Precise
Origin: Ubuntu
Label: Ubuntu
Suite: precise
Version: 12.04
Codename: precise
Architectures: i386 amd64
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Description: Ubuntu Precise 12.04 (with updates and security)
Contents: .gz .bz2
UDebIndices: Packages Release . .gz
Tracking: minimal
Update: - ubuntu-precise ubuntu-precise-updates ubuntu-precise-security
SignWith: yes

Il définit la distribution precise dans notre dépôt. Elle contient quatre composants : main, restricted, universe et multiverse (comme la distribution présente dans les dépôts officiels).

La ligne Update commence par un tiret. Cela signifie que reprepro va marquer tous les paquets comme à effacer avant d’appliquer les mises à jour indiquées. Les paquets supprimés de la distribution officielle ne seront donc pas conservés dans notre miroir. Dans conf/updates, nous définissons les sources :

# Ubuntu Precise
Name: ubuntu-precise
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise
Components: main main multiverse restricted universe
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

# Ubuntu Precise Updates
Name: ubuntu-precise-updates
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise-updates
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

# Ubuntu Precise Security
Name: ubuntu-precise-security
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise-security
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

Les lignes VerifyRelease indiquent les empreintes des clefs GPG à utiliser pour vérifier la signature des dépôts distants. Il faut importer la clef en question dans l’anneau local :

$ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg \
>     --export 437D05B5 | GNUPGHOME=gpg gpg --import

Un autre point important est le fait que nous avons fusionné trois distributions (precise, precise-updates et precise-security) dans une seule distribution (precise) dans notre dépôt local. Cela peut provoquer des difficultés avec les outils, tels que le Debian Installer2, qui s’attendent à trouver les trois distributions classiques.

Il est ensuite possible de lancer reprepro pour mettre à jour le miroir :

$ reprepro update

Cela prend un certain temps la première fois. reprepro n’est pas la solution la plus efficace pour mettre en place un miroir, mais sa prise en main est simple et il est particulièrement fiable.

Dépôt maison

Passons au dépôt pour les paquets maisons. Pour chaque distribution officielle (telle que precise), nous mettons en place deux distributions :

  • precise-staging contient les paquets en cours de test.
  • precise-prod contient les paquets testés issus de precise-staging.

Dans cette organisation, les paquets sont introduits dans precise-staging où ils peuvent être testés sur quelques serveurs avant d’être copiés dans precise-prod pour être disponible sur l’ensemble de la plateforme. La déclaration dans conf/distributions se fait ainsi :

# Dailymotion Precise packages (staging)
Origin: Dailymotion # ➌
Label: dm-staging   # ➌
Suite: precise-staging
Codename: precise-staging
Architectures: i386 amd64 source
Components: main role/dns role/database role/web # ➊
Description: Dailymotion Precise staging repository
Contents: .gz .bz2
Tracking: keep
SignWith: yes
NotAutomatic: yes # ➋
Log: packages.dm-precise-staging.log
 --type=dsc email-changes

# Dailymotion Precise packages (prod)
Origin: Dailymotion # ➌
Label: dm-prod      # ➌
Suite: precise-prod
Codename: precise-prod
Architectures: i386 amd64 source
Components: main role/dns role/database role/web # ➊
Description: Dailymotion Precise prod repository
Contents: .gz .bz2
Tracking: keep
SignWith: yes
Log: packages.dm-precise-prod.log

Notez d’abord l’utilisation de plusieurs composants (en ➊) :

  • main contiendra les paquets génériques. Un paquet placé dans main doit pouvoir être utilisé sur n’importe quel serveur.
  • role/* sont des composants dédiés à un sous-ensemble de la plateforme. Par exemple, dans role/dns, on trouvera des versions modifiées de BIND.

La distribution de test utilise le drapeau NotAutomatic (en ➋) qui indique au gestionnaire de paquets de ne pas installer ces paquets à moins d’une requête expresse de l’utilisateur. Juste au-dessous, quand un nouveau fichier dsc est reçu, le script email-changes est exécuté. Il doit se trouver dans le répertoire conf/.

Les lignes Origin et Label (en ➌) sont particulièrement importants car elles seront utilisées pour déterminer la politique d’installation des paquets. Prenons ce fichier /etc/apt/sources.list :

# Ubuntu packages
deb http://packages.dm.gg/dailymotion precise main restricted universe multiverse

# Dailymotion packages
deb http://packages.dm.gg/dailymotion precise-prod    main role/dns
deb http://packages.dm.gg/dailymotion precise-staging main role/dns

Tous les serveurs peuvent utiliser la distribution precise-staging. Il est essentiel de ne pas installer par erreur des paquets de cette distribution. Le drapeau NotAutomatic est une première sécurité. Nous y ajoutons ce fichier /etc/apt/preferences :

Explanation: Dailymotion packages of a specific component should be more preferred
Package: *
Pin: release o=Dailymotion, l=dm-prod, c=role/*
Pin-Priority: 950

Explanation: Dailymotion packages should be preferred
Package: *
Pin: release o=Dailymotion, l=dm-prod
Pin-Priority: 900

Explanation: staging should never be preferred
Package: *
Pin: release o=Dailymotion, l=dm-staging
Pin-Priority: -100

Par défaut, les paquets ont une priorité de 500. En utilisant une priorité de -100 pour les paquets en provenance de la distribution de test, nous nous assurons qu’ils ne peuvent pas être installés du tout. C’est une contrainte plus forte que l’utilisation de NotAutomatic qui place la priorité à 1. Nous favorisons les paquets se trouvant dans le dépôt maison par rapport aux paquets officiels en leur affectant une priorité de 900 (voire 950 pour les paquets qui se trouvent dans un composant type rôle).

La section “How APT Interprets Priorities” de la page de manuel apt_preferences(5) donne plus de détails. Il faut garder en tête que les versions ne sont utilisées qu’à priorité égale. La commande apt-cache policy permet de vérifier que tout fonctionne comme attendu :

$ apt-cache policy php5-memcache
  Installed: 3.0.8-1~precise2~dm1
  Candidate: 3.0.8-1~precise2~dm1
  Version table:
 *** 3.0.8-1~precise2~dm1 0
        950 http://packages.dm.gg/dailymotion/ precise-prod/role/web amd64 Packages
        100 /var/lib/dpkg/status
     3.0.8-1~precise1~dm4 0
        900 http://packages.dm.gg/dailymotion/ precise-prod/main amd64 Packages
       -100 http://packages.dm.gg/dailymotion/ precise-staging/main amd64 Packages
     3.0.6-1 0
        500 http://packages.dm.gg/dailymotion/ precise/universe amd64 Packages

Pour installer un paquet en provenance de la distribution de test, il suffit d’invoquer apt-get avec l’option -t precise-staging qui augmente la priorité de cette distribution à 990.

Une fois le paquet testé sur quelques serveurs, il est possible de le copier vers la distribution de production :

$ reprepro -C main copysrc precise-prod precise-staging wackadoodle

Miroir local de dépôts tiers.

Parfois, plutôt que de reconstruire un paquet, il est préférable de le prendre directement sur un dépôt tiers. Un exemple courant est les dépôts mis en place par les constructeurs. Comme pour la mise en place d’un miroir d’une distribution officielle, il y a deux étapes : définition de la distribution et déclaration des sources.

Chaque miroir va se trouver dans les mêmes distributions que nos paquets maisons mais ils iront dans un composant dédié. Cela nous permet d’utiliser la même organisation que pour les paquets locaux : ils apparaîtront dans la distribution de test avant d’être manuellement copiés, après validation, dans la distribution de production.

La première étape consiste à àjouter le composant et la ligne Update appropriée dans le fichier conf/distributions :

Origin: Dailymotion
Label: dm-staging
Suite: precise-staging
Components: main role/dns role/database role/web vendor/hp
Update: hp
# [...]

Origin: Dailymotion
Label: dm-prod
Suite: precise-prod
Components: main role/dns role/database role/web vendor/hp
# [...]

Le composant vendor/hp a été ajouté aux deux distributions mais seule la distribution de test a une ligne Update. La distribution de production obtiendra les paquets par copie manuelle.

La source des paquets est déclarée dans le fichier conf/updates :

# HP repository
Name: hp
Method: http://downloads.linux.hp.com/SDR/downloads/ManagementComponentPack/
Suite: precise/current
Components: non-free>vendor/hp
Architectures: i386 amd64
VerifyRelease: 2689B887
GetInRelease: no

N’oubliez pas de rajouter la clef GPG correspondante dans l’anneau local. À noter une fonctionnalité particulièrement intéressante de reprepro qui permet de copier le composant non-free dans le composant vendor/hp.

Construction des paquets Debian

La configuration de reprepro est désormais terminée. Comment construire les paquets à placer dans la distribution de test ?

Selon le temps que vous souhaitez accorder à cette activité, il y a plusieurs possibilités :

  1. Construire un paquet source en ajoutant un répertoire debian/. C’est la façon classique. Il est possible de partir de zéro ou de prendre un paquet existant dans une distribution plus récente ou un rétroportage d’un dépôt non officiel.

  2. Utiliser un outil qui va créer un paquet binaire à partir d’un répertoire, tel que fpm. Un tel outil va minimiser le boulot à effectuer pour construire un paquet et peut même empaqueter automatiquement certains types de logiciels.

Il n’y a pas de solution universelle. La première approche est plus chronophage mais dispose des avantages suivants :

  • Les sources restent disponibles dans le dépôt. Si vous avez besoin de reconstruire un paquet en urgence pour corriger un problème, il n’est pas nécessaire de partir a la recherche des sources qui peuvent être temporairement indisponibles. Bien sûr, cela n’est valable que pour les paquets qui ne téléchargent pas les dépendances depuis Internet.

  • La recette de construction est conservée3 dans le dépôt. Si quelqu’un active telle option et reconstruit le paquet, cette option ne sera perdue lorsqu’un autre personne reconstruira le paquet. Ces changements sont documentés dans le fichier debian/changelog. De plus, un système de gestion des versions peut être utilisé pour garder une trace précise des changements liés à l’empaquetage.

  • Le paquet obtenu peut ensuite être proposé à l’inclusion dans Debian. Cela rendra service à de nombreuses autres personnes.

Compilation

pbuilder est utilisé pour la compilation automatique des paquets4. Sa mise en place est relativement simple. Voici le fichier pbuilderrc utilisé :

DISTRIBUTION=$DIST
NAME="$DIST-$ARCH"
MIRRORSITE=http://packages.dm.gg/dailymotion
COMPONENTS=("main" "restricted" "universe" "multiverse")
OTHERMIRROR="deb http://packages.dm.gg/dailymotion ${DIST}-staging main"
HOOKDIR=/etc/pbuilder/hooks.d
BASE=/var/cache/pbuilder/dailymotion
BASETGZ=$BASE/$NAME/base.tgz
BUILDRESULT=$BASE/$NAME/results/
APTCACHE=$BASE/$NAME/aptcache/
DEBBUILDOPTS="-sa"
KEYRING="/usr/share/keyrings/dailymotion-archive.keyring.gpg"
DEBOOTSTRAPOPTS=("--arch" "$ARCH" "--variant=buildd" "${DEBOOTSTRAPOPTS[@]}" "--keyring=$KEYRING")
APTKEYRINGS=("$KEYRING")
EXTRAPACKAGES=("dailymotion-archive-keyring")

pbuilder doit être invoqué avec les variables d’environnement DIST, ARCH et (optionnellement) ROLE. La mise en place de chaque environnement s’effectue ainsi :

for ARCH in i386 amd64; do
  for DIST in precise; do
    export ARCH
    export DIST
    pbuilder --create
  done
done

Concernant les rôles, un crochet de type D permet d’ajouter les sources appropriées avant la compilation :

#!/bin/bash
[ -z "$ROLE" ] || {
  cat >> /etc/apt/sources.list <<EOF
deb http://packages.dm.gg/dailymotion ${DIST}-staging role/${ROLE}
EOF
}

apt-get update

Un crochet de type E permet de s’assurer que les paquets de la distribution de test sont prioritairement utilisés pour la construction :

#!/bin/bash

cat > /etc/apt/preferences <<EOF
Explanation: Dailymotion packages are of higher priority
Package: *
Pin: release o=Dailymotion
Pin-Priority: 900
EOF

Enfin, un crochet de type C permet d’obtenir un shell en cas d’erreur, ce qui est pratique pour corriger un problème :

#!/bin/bash
apt-get install -y --force-yes vim less
cd /tmp/buildd/*/debian/..
/bin/bash < /dev/tty > /dev/tty 2> /dev/tty

Une compilation peut ensuite être lancée avec la commande :

$ ARCH=amd64 DIST=precise ROLE=web pbuilder \
>         --build somepackage.dsc

Numérotation des versions

Afin d’éviter des règles trop complexes pour les versions, tout paquet est traité comme étant un rétroportage. Le schéma utilisé est le suivant : X-Y~preciseZ+dmW.

  • X est la version amont5.

  • Y est la version Debian. S’il n’y a pas de version Debian, mettre 0.

  • Z est la version du backport dans Ubuntu. S’il n’existe pas, mettre 0.

  • W est notre version du paquet. Il est incrémenté à chaque changement dans le paquet. C’est le seul numéro que nous contrôlons. Tous les autres dépendent d’une entité en amont.

Supposons que l’on désire rétroporter le paquet wackadoodle. Il est disponible dans une Ubuntu plus récente en version 1.4-3. La première version du paquet aura pour version 1.4-3~precise0+dm1. Après un changement dans le fichier debian/rules, nous obtenons la version 1.4-3~precise0+dm2. En amont, une version 1.5 devient disponible. Elle n’est disponible ni dans Ubuntu, ni dans Debian. Le numéro de version du paquet sera alors 1.5-0~precise0+dm1.

Quelques semaines plus tard, le paquet arrive chez Ubuntu dans la version 1.5-3ubuntu1. Vous y appliquez des changements pour obtenir la version 1.5-3ubuntu1~precise0+dm1.

Une convention compatible avec les pratiques de Debian concernant les rétroportages est : X-Y~bpo70+Z~dm+W.

Envoi

Pour intégrer un paquet dans le dépôt, les étapes classiques sont les suivantes :

  1. Le paquet source est placé dans un répertoire incoming/.
  2. reprepro remarque le paquet source, vérifie sa validité (signature, distribution) et le place dans l’archive.
  3. Le système de compilation remarque un nouveau paquet source à construire et lance la compilation de celui-ci.
  4. Une fois les paquets binaires construits, ils sont également placés dans le répertoire incoming/.
  5. reprepro détecte les paquets binaires et les intègre dans l’archive.

Cette façon de faire a le désavantage d’être difficile à suivre pour l’utilisateur. Une alternative est de concevoir un script de construction exécutant chaque tâche de manière synchrone et permettant ainsi à l’utilisateur de suivre son terminal le bon déroulement des opérations. Ce script s’occupe également d’inclure les paquets finaux dans l’archive :

$ reprepro -C main include precise-staging \
>      wackadoodle_1.4-3~precise0+dm4_amd64.changes

Voilà !


  1. Le répertoire gpg/ peut être partagé par plusieurs dépôts. 

  2. Il est possible d’apprendre à l’installeur Debian de travailler avec un tel dépôt en utilisant un fichier de configuration approprié

  3. fpm-cookery est un outil particulièrement pratique pour fpm, dans la même veine que Homebrew ou que l’arbre de ports des BSD. Il peut être utilisé dans une optique similaire. 

  4. sbuild est une alternative qui est aussi l’outil utilisé officiellement par Ubuntu et Debian. Historiquement, pbuilder était plus orienté vers les besoins des développeurs. 

  5. Pour un extrait de dépôt Git, le numéro de version amont utilisé ressemble à 1.4-git20130905+1-ae42dc1 ce qui correspond à un extrait situé après la version 1.4 (utiliser 0.0 s’il n’y a jamais eu de publication) à la date donnée. Le chiffre qui suit la date peut être incrémenté si plusieurs extraits sont utilisés dans la même journée. Enfin, le condensat à la fin permet de récupérer l’extrait exact. 

27 April, 2014 01:43PM par Vincent Bernat

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

24 February 2014

Benoit Peccatte

Passer une auditions

Niveau :      
Résumé :

Aucun tag pour cet article.

24 February, 2014 11:37AM par peck

16 February 2014

Aurélien Jarno

On configure systems

I will never understand the point of using autotools, cmake or whatever configure system, when later the code uses an hardcoded list of architectures to determine the size of a pointer… Unfortunately for porters this pattern is quite common.

Update: As people keep asking, the way to check for the size of a given type is explained in the autoconf manual. To check for the size of the pointer, the following entry has to be added to configure.ac:

AC_CHECK_SIZEOF(void *)

On a 64-bit system, this will lead to the following entry in config.h:

/* The size of `void *', as computed by sizeof. */
#define SIZEOF_VOID_P 8

16 February, 2014 01:52PM par aurel32

26 January 2014

Benoit Peccatte

Quand on me demande un script shell pour corriger un problème d’architecture

Scotch

Aucun tag pour cet article.

26 January, 2014 10:28PM par peck

25 December 2013

Carl Chenet

Cadeau de Noël : Publication de Brebis 0.9, le vérificateur automatisé de sauvegarde

Suivez-moi aussi sur Identi.ca ou sur Twitter 

Peu de temps avant ce Noël, l’équipe du projet Brebis a publié la version "Bouddhinette" 0.9 du vérificateur automatisé de sauvegardes. Pour rappel, Brebis est un programme en ligne de commande codé en Python permettant le contrôle automatisé de l’intégrité d’archives (tar, gz, bzip2, lzma, zip) et de la cohérence des fichiers à l’intérieur des archives. Au menu de cette version :

  • Support des archives apk
  • Nouvelles options de la ligne de commandes pour écrire le fichier de configuration (-C), la liste des fichiers dans l’archive (-L) ou les deux (-O) dans un répertoire défini par l’utilisateur (où précédemment ces fichiers étaient écrits par défaut dans le même répertoire que l’archive elle-même).
brebis-brown-big-logo

Anisette, la fière nouvelle mascotte et nouveau logo du projet Brebis généreusement contribué par Antoine Millet

Comme annoncé aux JM2L, Brebis continue d’intégrer des nouveaux types d’archives , mais aussi rend sa manipulation plus flexible afin d’être intégré plus simplement pour répondre aux besoins de ses utilisateurs en s’adaptant plus simplement aux différentes situations existantes..

Feedback sur Brebis

Et vous ? Que pensez-vous de Brebis ? N’hésitez pas à vous abonner à la liste de diffusion de Brebis,  à laisser un commentaire ici ou  un message sur le forum ou à me contacter directement, tous les retours seront appréciés.


25 December, 2013 10:01PM par Carl Chenet

08 December 2013

Carl Chenet

Retour sur Brebis, le vérificateur automatisé de sauvegarde, aux JM2L

Suivez-moi aussi sur Identi.ca ou sur Twitter 

Comme chaque année avait lieu à Sophia Antipolis les Journées Méditerrannéennes du Logiciel Libre, organisées par l’association Linux Azur. J’avais proposé pour cette année une présentation du projet  Brebis, le vérificateur automatisé de sauvegarde. C’était pour moi l’occasion de réaliser quelques slides parlant du projet (désormais disponible en ligne – CC by SA) et de recueillir les réactions du public.

jm2l

L’accueil est chaleureux, comma d’habitude et le public est présent. On m’avait accordé un créneau d’une bonne heure. j’ai donc essayé de captiver mon public pendant 50 minutes avant la séance de questions. La présentation se découpe en deux phases, une introduction au domaine de la sauvegarde et à la nécessité de vérifier les sauvegardes régulièrement, puis une seconde partie plus technique sur les fonctionnalités du logiciel Brebis lui-même.

brebis-brown-big-logo

Anisette, la fière nouvelle mascotte et nouveau logo du projet Brebis généreusement contribué par Antoine Millet

La conférence a été filmée, je pourrai donc vérifier ce qu’il en est une fois que les vidéos seront en ligne.

Niveau stand, les exposants sont accueillants et disponibles et je suis content de voir cet événement du Logiciel Libre toujours aussi fréquenté. Trois fois que je fais le déplacement et je repasse sans faute l’année prochaine !

Étiez-vous aux JM2L aussi ? Qu’en avez-vous pensé ? N’hésitez pas à réagir dans les commentaires de ce billet.


08 December, 2013 09:54AM par Carl Chenet

30 November 2013

Rodolphe Quiédeville

Utiliser GraphHopper avec Jetty8 sous Debian

Actuellement la seule solution documentée pour utiliser GraphHopper est l'utilisation de jetty runner, celle-ci n'est pas satisfaisante dans un mode de production, elle requiert de mettre en place des scripts de lancement. Il est plus simple d'administrer un service de routing en utilisant par exemple jetty ou Tomcat, ce billet va se concentrer sur la configuration de jetty sous Debian Jessie.

Tout d'abord installer le serveur jetty

apt-get install jetty8

Puis on récupère l'archive .war que l'on copie dans le répertoire de webapp de jetty

cd /var/lib/jetty8/webapps
wget http://oss.sonatype.org/content/groups/public/com/graphhopper/graphhopper-web/0.2/graphhopper-web-0.2.war

Toujours dans le répertoire webapps on va renommer le fichier war de GraphHopper afin que le déploiement se fasse dans le contexte racine, de même que l'on va supprimer le répertoire existant nommé root. La raison de cette opération peu orthodoxe est que par défaut GraphHopper répond aux requêtes d'api sur l'url /api/ et qu'il n'est pas actuellement possible de paramétrer cela simplement. La seule méthode de contournement est d'indiquer un paramètre host dans l'url ce qui n'est pas des plus ergonomique.

mv graphhopper-web-0.2.war ROOT.war
rm -fr root/ 

On va déployer les fichiers de configuration et de données dans /home/routing, il faut créer ce répertoire, dans lequel on en crée de suite un autre nommé data qui contiendra les données précompilées par GraphHopper

mkdir /home/routing
mkdir /home/routing/data/

On crée un fichier de configuration dans le dossier en utilisant l'exemple fournit sur le site du projet, fichier que l'on renomme dans la foulée.

wget https://raw.github.com/graphhopper/graphhopper/master/config-example.properties
mv config-example.properties config.properties

Maintenant on va récupérer le fichier qui servira de source de données, on télécharge directement un fichier protobuff depuis le site de Geofabrik, par exemple le fichier de données de la région Nord-Pas de Calais :

wget http://download.geofabrik.de/europe/france/nord-pas-de-calais-latest.osm.pbf

On édite le fichier de configuration pour qu'il corresponde à notre utilisation en ajoutant deux paramètres à la fin de celui-ci. Le premier qui correspond au fichier protobuff utilisé et le second qui indique où GraphHopper doit créer ses fichiers de données.

# data source
osmreader.osm=/home/routing/nord-pas-de-calais-latest.osm.pbf
# repertoire de données
graph.location=/home/routing/data/

Au lancement de jetty GraphHopper va pré-traiter les données du fichier .pbf afin de préparer ses tables de recherches qu'il stockera dans le répertoire /home/routing/data/ Si vous voulez mettre les données à jour il suffit télécharger un nouveau fichier de données et de relancer jetty, le fichier de données étant plus récent GrapHopper relancera une analyse.

Le serveur jetty tournant sous Debian avec l'utilisateur jetty il faut définir les bons attibuts de propriété aux répertoires ainsi qu'à tous les fichiers présents dans celui-ci.

chown -R jetty.jetty /home/routing

Dernière modification, éditer le fichier /etc/default/jetty8 pour paramétrer le démarrage automatique et indiquer le fichier de configuration de GraphHopper

# change to 0 to allow Jetty to start
NO_START=0

# Additional arguments to pass to Jetty    
JETTY_ARGS=-Dgraphhopper.config=/home/routing/config.properties

Par défaut comme souvent sur Debian le démon va écouter seulement sur le localhost, à vous de régler le paramètre JETTY_HOST suivant vos besoins.

Il ne reste plus qu'à lancer jetty avec le script d'init avec l'utilisateur privilégié root

invoke-rc.d jetty8 restart

A ce stade GraphHopper est prêt à répondre sur le port 8989 de votre machine et à vous indiquer la route !

30 November, 2013 03:45PM par Rodolphe Quiédeville

24 November 2013

David Mercereau

[ispconfig] Managesieve (dovecot) & Horde

sieve.infoDes dires de Wikipedia : “Sieve est un langage de filtrage du courrier électronique. Il est normalisé dans le RFC 5228. Sieve permet de filtrer sur les en-têtes d’un message qui suit le format du RFC 5322, c’est-à-dire un message Internet typique. ”

Sieve c’est très pratique car le filtrage du courrier est effectué au niveau du serveur dès la réception de l’email. Ce qui est presque indispensable quand on utilise plusieurs clients de messagerie (web &/ou desktop). Je vais donc utiliser Managesieve (qui est la partie serveur du protocole) pour Dovecot (projet Pigeonhole).

Actuellement le panel ISPconfig me permet d’éditer les filtres Sieve mais n’utilise pas Managesieve. ISPconfig stock en base (table mail_user_filter) et écrase le fichier à chaque modification.

Je ne souhaite plus passer par ISPconfig pour modifier mes filtres, mais directement par Horde (via Ingo) ou Roundcube (plugin) ou encore par thunderbird (plugin) selon mes besoins.

Installation de Managesieve

Rien de plus simple :

aptitude install dovecot-managesieved

Modifier le fichier /etc/dovecot/dovecot.conf :

< protocols = imap
> protocols = imap sieve

Puis redémarrer le service, le port 4190 doit ensuite être à l’écoute :

$ service dovecot restart
$ netstat -pnat | grep 4190
tcp        0      0 0.0.0.0:4190            0.0.0.0:*               LISTEN      11111/dovecot

Horde (ingo) & Sieve

Il vous suffit de modifier le fichier ingo/config/backends.php de votre instance horde de la façon suivante :

[...]
/* IMAP Example */
$backends['imap'] = array(
    // ENABLED by default
<    'disabled' => false,
>    'disabled' => true,
    'transport' => array(
        Ingo::RULE_ALL => array(
            'driver' => 'null',
            'params' => array(),
        ),
    ),
[...]
$backends['sieve'] = array(
    // Disabled by default
<    'disabled' => true,
>    'disabled' => false,
    'transport' => array(
        Ingo::RULE_ALL => array(
            'driver' => 'timsieved',
            'params' => array(
                // Hostname of the timsieved server
                'hostspec' => 'localhost',
                // Login type of the server
                'logintype' => 'PLAIN',
                // Enable/disable TLS encryption
                'usetls' => false,
                // Port number of the timsieved server
                'port' => 4190,
                // Name of the sieve script
<                'scriptname' => 'ingo',
>                'scriptname' => 'filtres',
                // Enable debugging. The sieve protocol communication is logged
[...]

Ne faites (peut être) pas ça chez vous

En effet ça ne s’avère pas être forcément la meilleure des solutions :

  • Il n’est apparemment pas possible d’importer des scripts existants.
  • Plus embêtant il s’avère que Horde fonctionne presque de la même façon qu’ISPconfig. A savoir qu’il stock en base les filtres et écrase le script sieve (via managesieve quand même) Ce qui me condamne à n’utilise qu’une interface (horde) pour modifier mes filtres :’-(

Bon je m’en contente, il est toujours plus agréable de modifier ses filtres via son webmail (horde) que via le panel ISPconfig.

24 November, 2013 08:17AM par David

04 November 2013

Stéphane Blondon

Évolution comparée du nombre de bogues entre distribution Linux

Il est difficile de connaitre la vitalité d’une distribution Linux. Il est possible de s’en faire une idée en fonction du nombre de posts sur des forums, de recherche sur un moteur de recherche, du nombre de téléchargement ou la visibilité sur Distrowatch, etc. Regarder le nombre de bogues en est une autre. Après tout, […]

04 November, 2013 10:47PM par ascendances

03 November 2013

Ulrich L.

Fix le démarrage du serveur RabbitMQ avec les logs système en RAM sur Debian

Astuce pour débloquer le lancement de RabbitMQ sur un serveur Debian, si vous avez déplacé le dossier de logs dans un montage temporaire.

03 November, 2013 11:00PM

21 October 2013

David Mercereau

Backup chiffré avec duplicity sur HubiC

EDIT 17/02/2014 : suite à des changements sur Hubic.com, Gu1 à mis à jour python-cloudfiles-hubic. J’ai donc mis à jour mon script en conséquence

Hubic GUI avec duplicityMon ADSL est depuis peut chez OVH. De ce fait je bénéficie d’un compte hubiC avec un espace de stockage d’1To. Quelle aubaine pour des sauvegardes ! Mais bon donner mes mails, mes sites, mes documents administratifs à un tiers… bof bof. Il faudrait un minimum de chiffrage !

Et bien comme disait les autres nuls : “Hassan Cehef c’est possible” avec duplicity et python-cloudfiles-hubic !

python-cloudfiles-hubic est nécessaire car duplicity n’intègre pas nativement le service cloud “HubiC” pour une sombre histoire de protocole d’authentification non standard de la part d’OVH (détail par l’auteur)

Installation

On commence par le plus simple (duplicity) :

aptitude install duplicity

Maintenant python-cloudfiles-hubic :

aptitude install python-setuptools git
cd /usr/src
git clone https://github.com/Gu1/python-cloudfiles-hubic.git
cd python-cloudfiles-hubic
python setup.py  install

Utilisation

Dans vos paramètre sur hubic.com dans votre menu “Vos application” il va falloir ajouter une application :

  • Nom : cequevousvoulez
  • Domaine de redirection : http://localhost/

Quand l’application est créer récupérer le “client id” ainsi que le “client secret” dans l’interface

screenshot.62

Quelques petits tests pour la prise en main :

# Désactiver le bash_history (c'est pénible avec les mots de passes)
unset HISTFILE
# Les variables 
export CLOUDFILES_USERNAME=toto@toujours.lui
export CLOUDFILES_APIKEY=je.vais.pas.vous.donner.le.mot.de.passe.de.toto
# CLOUDFILES_AUTHURL="hubic|client id|client secret|http://localhost/"
export CLOUDFILES_AUTHURL="hubic|api_hubic_XXXX|YYYYY|http://localhost/"
# Sauvegarde
duplicity /root cf+http://default
# Observer l'état
duplicity collection-status cf+http://default
# Liste les fichiers distants 
duplicity list-current-files cf+http://default
# Test la restauration d'un fichier 
duplicity  --file-to-restore .bash_alias cf+http://default /tmp/bash_alias_recup

Rendez-vous ensuite dans votre interface hubiC. Et là normalement il y a plein de fichier duplicity-BLABLA-blabla.bla ! On supprime tout ! (c’était juste pour les tests)

Il ne semble pas possible d’écrire dans un sous répertoire. Mais, comme je l’ai signalé dans mon commentaire, il semble possible d’écrire dans un autre “container” sur hubiC (autre que default). Il ne sera visible qu’après modification de l’URL. Exemple si vous avez écrit dans le conteneur backup rendez vous sur l’URL : https://hubic.com/home/browser/#backup

Le script

Voici mon script :

#!/bin/bash

###################################
## Backup sur HubiC avec duplicity
# Script sous licence BEERWARE
# Version 0.4 17/02/2014
###################################

set -eu

##### Paramètres

# Utilisateur Hubic
HUBICUSER="leuserdevotrehubic"
# Mot de passe HubiC
HUBICPASSWORD="lemotdepassedevotrehubic"
# Application client id Hubic
HUBICAPPID="api_hubic_XXXXX"
# Application client secret Hubic
HUBICAPPSECRET="YYYYYY"
# Application domaine de redirection Hubic
HUBICAPPURLREDIRECT="http://localhost/"
# Liste à sauvegarder (voir le man duplicity avec le filelist)
DUPLICITYFILELIST="/etc/backup-`hostname`.filelist"
# Passphrase pour le chiffrement
PASSPHRASE="VotrePassPhraseDeOufQueYaQueVousEtVousSeulQuiSavez:-p"
# Fréquence des sauvegardes complètes
FULLIFOLDERTHAN="1W"
# Rétention des sauvegardes
RETENTION="2M"
# Log d'erreur
LOGERROR="/var/tmp/backup-hubic-error.log"
# Bin de duplicity
DUPLICITY_BIN="/usr/bin/duplicity"
# Email pour les erreurs (0 pour désactiver)
EMAIL="david@mercereau.info"
# Envoyer un rapport par email sur l'état des backup
RAPPORT=1
# Log d'erreur
exec 2> ${LOGERROR}

##### Début du script

function cleanup {
	echo "exit..."
	unset CLOUDFILES_USERNAME
	unset CLOUDFILES_APIKEY
	unset PASSPHRASE
	if [ "`stat --format %s ${LOGERROR}`" != "0" ] && [ "$EMAIL" != "0" ] ; then
		cat ${LOGERROR} | mail -s "$0 - Error" ${EMAIL}
	fi
}
trap cleanup EXIT

# Gentil avec le système
ionice -c3 -p$$ &>/dev/null
renice -n 19 -p $$ &>/dev/null

if ! [ -f ${DUPLICITYFILELIST} ] ; then
	echo "Aucun fichier filelist : ${DUPLICITYFILELIST}"
	exit 1
fi

export CLOUDFILES_USERNAME=${HUBICUSER}
export CLOUDFILES_APIKEY=${HUBICPASSWORD}
export CLOUDFILES_AUTHURL="hubic|${HUBICAPPID}|${HUBICAPPSECRET}|${HUBICAPPURLREDIRECT}"
export PASSPHRASE

# Backup 
${DUPLICITY_BIN} --full-if-older-than ${FULLIFOLDERTHAN} / cf+http://default --include-globbing-filelist ${DUPLICITYFILELIST} --exclude '**'

# Suppression des vieux backups
${DUPLICITY_BIN} remove-older-than ${RETENTION} cf+http://default --force

# Rapport sur le backup
if [ "$RAPPORT" != "0" ] && [ "$EMAIL" != "0" ] ; then
        ${DUPLICITY_BIN} collection-status cf+http://default | mail -s "$0 - collection-status" ${EMAIL}
fi

unset CLOUDFILES_USERNAME
unset CLOUDFILES_APIKEY
unset PASSPHRASE

exit 0

A noter que mes bases de données sont dumpées à plat de façon indépendante du script de backup distant (par mysql_dump.sh)

Exemple de fichier filelist :

/etc
/var/backups/mysql
/var/chroot/bind9/etc/bind
/var/lib/mysql
/var/lib/awstats
/var/lib/mailman
/var/spool/cron
/var/vmail
- /var/www/mercereau.info/wp-content/cache/
- /var/www/default
/var/www
/home
- /root/.cpan
- /root/.cache
- /root/.npm
/root
/opt

Attention : les fichiers et répertoires à exclure doivent apparaître avant l’inclusion d’un répertoire parent. En effet, duplicity s’arrête à la première règle qui matche un chemin donné pour déterminer s’il doit l’inclure ou l’exclure. (sources)

Il n’y a plus qu’a le lancer en tâche cron :

44 4 * * *  /usr/local/bin/backup-to-hubic.sh

Ressources

21 October, 2013 08:46PM par David

26 September 2013

Olivier Berger (pro)

Qu’est-ce que le Linked Data

Voici une traduction en français d’un court document introductif au Linked Data, originellement écrit par Luca Matteis :

http://www-public.telecom-sudparis.eu/~berger_o/linkeddatawhat/whatislinkeddata.html

Bonne lecture.

26 September, 2013 02:20PM par Olivier Berger