: % de paquets cassés <= 1%

: % de paquets cassés <= 2%

: % de paquets cassés <= 3%

: % de paquets cassés <= 4%

: % de paquets cassés <= 100%

Sources :

• Debian Weather
• Debian weather is back

~/.macromedia/Flash_Player/#SharedObjects/xxxx/
~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys

Vous y trouverez toute une liste de sites internet sur lesquels vous avez surfé et qui ont déposés un « cookie Flash ».
Faisons en sorte de contrôler ces cookies et commençons tout d’abord, par faire table rase de tous ces fichiers :

user@gnusquad:~$ rm -r .macromedia

Redémarrez votre navigateur s’il est lancé et configurons Flash Player afin qu’il arrête d’enregistrer ces cookies sans notre permission. Pour cela, il faut :

• aller sur la page de configuration du plugin présente sur le site d’Adobe
• spécifier la quantité d’espace disque disponible pour les sites à « aucun »
• décocher la case « Stockez les composants Flash courants pour réduire la durée des téléchargements »

Désormais, Flash Player vous demandera l’autorisation d’écrire les cookies mais malheureusement, même si vous lui dites non, celui-ci écrit tout de même quelques informations sur le site dans le deuxième répertoire ! J’ai essayé de ruser un peu en utilisant les droits du système de fichier pour empêcher Flash Player d’écrire dans le deuxième répertoire tout en lui laissant la main sur le premier mais sans succès : ce dernier reste vide à cause de l’échec de l’écriture dans le second répertoire !

Une solution serait de positionner les droits d’écriture sur « ~/.macromedia » uniquement lorsque l’on en a besoin mais c’est super lourd et c’est là que j’ai découvert l’extension Firefox « Objection » qui permet de visualiser le contenu des cookies Flash (techniquement parlant, on utilise le terme de LSO) et de les supprimer :

Voilà, il ne vous reste plus qu’à penser à supprimer ces cookies Flash lorsque vous effacerez vos autres traces.

Trois petites notes pour clôturer ce billet :

• l’équipe de Firefox est au courant du problème et verra ce qu’il est possible de faire
• sachez que les cookies Flash sont partagés par les différents profils de Firefox (« firefox –ProfileManager »)
• notez enfin qu’Adobe Flash Player n’est pas le seul plugin sachant lire du Flash, il y a GNU Gnash (100% libre) qui pour l’instant n’implémente pas toute la “norme” mais le projet, prioritaire aux yeux du projet GNU, avance à grands pas !

Sources :

• Configuration d’Adobe Flash Player
• Extension Firefox : Objection
• BugZilla : block/clear Flash cookies
• Local Shared Object
• GNU Gnash

Logiciels utilisés :

• Subversion 1.4.6 (r28521)
• GNU Bash 3.1.17
• GNU Find 4.4.0
• File 4.24

Voici une petite commande permettant de définir les mime-types des fichiers de l’arborescence dans laquelle nous nous trouvons (vous pouvez retirez la partie « | bash > /dev/null » pour afficher ce qui sera exécuté) :

user@gnusquad:~/projet$ find . -type f ! -regex “.*/\.svn/.*” -exec echo svn propset svn:mime-type \”\$\(file -bi ‘{}’\)\” {} \; | bash > /dev/null

Il se peut que des messages d’erreurs apparaissent dûs à un non conformisme de Subversion vis à vis de la RFC 1521.

svn: Le type MIME ‘text/x-c++ charset=utf-8′ ne se termine pas par des caractères alphanumériques

Ce bug a été corrigé dans la révision 30795 de Subversion (tapez svn –version | head -1 pour voir votre révision).

Sources :

• Subversion : Automatic Property Setting
• RFC 1521

• SFTP signifie « Secure File Transfer Program », c’est un programme permettant de transférer des fichiers en utilisant une liaison chiffrée par SSH (Secure SHell) ; attention à ne pas confondre SFTP avec FTPS qui signifie pour sa part « File Transfer Protocol over SSL » !
• chroot est un programme permettant de changer le répertoire racine d’un processus afin que ce dernier n’ai accès qu’à une partie limitée de l’arborescence.
• scponlyc est un shell limité destiné uniquement aux transferts de fichiers dans un chroot.

Le but du jeu est donc de permettre à un utilisateur de transférer des fichiers sur un serveur de manière sécurisée sans qu’il n’obtienne pour autant un shell et sans qu’il lui soit permit de voir l’arborescence du serveur. Nous utiliserons pour l’exemple, la version 4.7 d’OpenSSH livrée avec Debian Testing.

Démarrons par l’installation du paquet scponly :

root@gnusquad:~# aptitude install scponly

Un script permettant de créer un compte utilisateur destiné au SFTP chrooté a été installé dans le répertoire « /usr/share/doc/scponly/setup_chroot/ », exécutons le en utilisant les réponses par défaut aux questions :

root@gnusquad:~# cd /usr/share/doc/scponly/setup_chroot/
root@gnusquad:/usr/share/doc/scponly/setup_chroot# gunzip setup_chroot.sh.gz
root@gnusquad:/usr/share/doc/scponly/setup_chroot# chmod +x setup_chroot.sh
root@gnusquad:/usr/share/doc/scponly/setup_chroot# ./setup_chroot.sh

Next we need to set the home directory for this scponly user.
please note that the user’s home directory MUST NOT be writeable
by the scponly user. this is important so that the scponly user
cannot subvert the .ssh configuration parameters.

for this reason, a writeable subdirectory will be created that
the scponly user can write into.

Username to install [scponly]
home directory you wish to set for this user [/home/scponly]
name of the writeable subdirectory [incoming]

creating  /home/scponly/incoming directory for uploading files

Your platform (Linux) does not have a platform specific setup script.
This install script will attempt a best guess.
If you perform customizations, please consider sending me your changes.
Look to the templates in build_extras/arch.
 - joe at sublimation dot org

please set the password for scponly:
Enter new UNIX password:
Retype new UNIX password:
passwd : le mot de passe a été mis à jour avec succès
if you experience a warning with winscp regarding groups, please install
the provided hacked out fake groups program into your chroot, like so:
cp groups /home/scponly/bin/groups

Un compte utilisateur contenant les fichiers nécessaires au chroot a été créé dans « /home/scponly/ », celui-ci est presque complet, il ne lui manque que le fameux « /dev/null » que nous allons créer à la main :

root@gnusquad:/usr/share/doc/scponly/setup_chroot# cd ~scponly
root@gnusquad:/home/scponly# mkdir dev
root@gnusquad:/home/scponly# mknod -m 666 dev/null c 1 3

Dernière étape avant que ça ne fonctionne : pour pouvoir utiliser le programme « scponlyc », il faut que celui-ci soit exécuté avec les droits root ; pour cela, il faut placer le « sticky bit » sur l’exécutable « scponlyc » :

root@gnusquad:/home/scponly# chmod u+s $(which scponlyc)

Il est maintenant temps de tester notre compte chrooté : nous allons créer un fichier et l’envoyer à l’utilisateur « scponly » grâce au répertoire accessible en écriture « incoming » :

root@gnusquad:/home/scponly# cd
root@gnusquad:~#  echo “coucou” > test.txt
root@gnusquad:~#  scp test.txt scponly@localhost:incoming
scponly@localhost’s password:
test.txt                                                           100%    7     0.0KB/s   00:00

Vérifions maintenant que le chroot fonctionne bien en utilisant « sftp » :

root@gnusquad:~# sftp scponly@localhost
Connecting to localhost…
scponly@localhost’s password:
sftp> ls
bin       dev       etc       incoming  lib       usr
sftp> cd incoming
sftp> ls
test.txt
sftp> quit

Voilà, tout fonctionne correctement ! Notez cependant que toute cette procédure ne sera bientôt plus nécessaire avec les futures releases d’OpenSSH qui inclueront la possibilité de définir des chroot directement dans le fichier de configuration ce qui évitera par la même occasion de devoir mettre à jour son chroot lors de mise à jour de sécurité touchant les fichiers de celui-ci si l’on s’intéresse un tant soit peu à la sécurité !

Source :

• Chroot in OpenSSH

Aujourd’hui, je décide donc d’aller jeter un œil dans les logs sans y trouver de traces d’exécution de mon script alors que ses petits copains dans le répertoire étaient eux, bien exécutés !

Que diable se passe t-il ? Pour le savoir, il faut chercher la manière dont sont lancées ces tâches planifiées. Un petit tour dans le fichier « /etc/crontab » nous montre ceci :

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Nous voyons donc que les tâches sont exécutées grâce à la commande « run-parts ». Intéressons-nous au manuel de cette commande : « man run-parts ».

run-parts exécute tous les fichiers exécutables situés dans répertoire, et dont le nom satisfait les contraintes décrites ci-dessous. Les autres fichiers sont ignorés.

Si ni l’option –lsbsysinit ni l’option –regex n’est pas utilisée, alors les noms ne doivent être constitués que de lettres minuscules ou majuscules, de chiffres, de tirets de soulignement (« underscore ») ou de tirets.

Le problème apparaît alors clairement : notre lien symbolique, reprenant le nom du script, contient un point et n’est donc pas exécuté !

Deux solutions s’offrent alors à nous pour résoudre ce problème :

• ajouter l’option « –lsbsysinit » à « run-parts » pour les 4 lignes présentes dans « /etc/crontab »
• renommer le lien symbolique « bonne_bouffe.sh » en « bonne_bouffe »

Personnellement, j’ai choisi la seconde solution afin de coller à la façon de faire de Debian

• les fonctionnalités de pending backup
• le driver MyISAM natif permettant de mixer des backups logiques et physiques
• les fonctionnalités de chiffrement et de compression lors des backups

Nous voilà donc rassurés !

Sources :

• MySQL : un peu moins ou un peu plus libre ?
• MySQL Server is open source even backup extensions
• Présentation : MySQL Online Backup (téléchargement local)

Pour leur « démonstration », les ingénieurs de Microsoft ont utilisés ce qui semble être un Windows 2003 Server 64 bits ainsi que la version 7.04 d’Ubuntu en 64 bits également.

Commencons par détailler le screencast Windows : celui-ci démarre par l’installation de Perl en mode CGI accompagné d’un script de test, pour cela, ils ont eu besoin d’un double clic, de 32 clics et de 4 commandes à taper puis ils sont passés à l’installation de PHP, toujours en mode CGI, accompagné lui aussi de son script de test et qui a nécessité quant à lui, 5 double-clics et 18 clics ce qui fait au total : 6 double-clics, 50 clics et 4 commandes à taper !!!

Passons maintenant au screencast Ubuntu : les ingénieurs de Microsoft ont commencés par installer PHP en tant que module Apache ce qui a nécessité : 1 double-clic et 2 commandes à taper puis ils ont réitérés la chose avec Perl, toujours en tant que module, l’installation a nécessité 1 double-clic et 5 commandes à taper ce qui donne au total 2 double-clics et 7 commandes à taper.

Rapidement, en tant que Linuxien convaincu, on pourrait dire qu’ils se sont bien plantés dans leur « démonstration » vu la facilité avec laquelle Perl & PHP ont été installés sous Ubuntu comparé au cliquodrôme Windows qui nous fait perdre plus de temps qu’autre chose ! D’ailleurs, si l’on s’en tient aux chiffres, le screencast Windows est 20 secondes plus long que son concurrent !

Cependant, leur but était de faire peur aux aficionados de Windows en leur montrant de la ligne de commande, chose qu’ils n’ont pas l’habitude de pratiquer et qui par conséquent, fait peur. Le fair-play aurait été de mise, ils auraient, sous Ubuntu, installer Perl & PHP avec Synaptic et copié les fichiers avec Nautilus mais ça aurait été trop simple.

On peut remarquer également que sous Windows, les programmes d’installation étaient déjà téléchargés sur le bureau alors que sous Ubuntu, tout est téléchargé durant le screencast sur les serveurs de la distribution ; imaginez maintenant le temps qu’il aurait fallu pour télécharger les deux programmes d’installation sous Windows : lancer le navigateur, surfer sur les sites de PHP & Perl, trouver l’espace de téléchargement, télécharger les versions correspondant au système d’exploitation, mine de rien ça aurait pu doubler le temps de leur screencast ! Tout ceci sans compter le fait que pour les futures mises à jour de ces logiciels, il aurait fallu tout rechercher sur internet et tout réinstaller laborieusement alors que sous Ubuntu, les mises à jour se seraient faites quasi automatiquement !

Autre différence : en tant que Windowsiens pur & dur, ils tournent sous le compte administrateur alors que sous Ubuntu, bien évidemment, c’est un compte utilisateur avec lequel il faut utiliser « sudo » pour exécuter des commandes privilégiées : c’est tout bon pour Microsoft car ça rallonge les lignes de commandes et on peut facilement faire semblant de l’oublier pour provoquer une erreur comme ils l’ont fait lors du changement de droits sur l’exemple Perl avec « chmod ».

Ils sont bien rigolos aussi au niveau de l’édition des fichiers : une fois ils utilisent Gedit, une autre fois ils utilisent pico en ligne de commande qui, il faut l’avouer, est plutôt moche à voir. Rien de tel pour embrouiller un Windowsien !

Une dernière chose : sous Windows, ils installent les applications en mode CGI alors que sous Ubuntu, celles-ci sont installées en tant que module ce qui est grandement avantageux niveau performances ; pourquoi n’ont-ils pas installés Perl & PHP en mode ISAPI (équivalent des modules d’Apache) sous Windows ? Tout simplement parce que ça aurait complexifié l’installation et rallongé leur screencast, ce qui n’était pas leur but !

Bref, tout ceci n’est qu’une bonne blague de la part de Microsoft, j’attend les screencasts suivants avec impatience, pas vous ?

Sources :

• Get the facts
• Screencast Perl & PHP sous Windows (téléchargement local)
• Screencast Perl & PHP sous Ubuntu (téléchargement local)

Sources :

• O’Reilly France
• Blog Immatériel : O’Reilly France, c’est déjà du passé

Tout d’abord, commençons par un petit rappel pour les plus néophytes d’entre nous : le changement de répertoire. Nous avons ici, respectivement, l’entrée dans le répertoire « test » puis le retour au répertoire parent grâce aux « .. » :

user@gnusquad:~$ cd test
user@gnusquad:~/test: cd ..
user@gnusquad:~$

La base étant rappelée, passons aux astuces plus intéressantes.
Le retour au répertoire utilisateur peut se faire de maintes façons, je vous laisse choisir la plus rapide :

user@gnusquad:~/test$ cd
user@gnusquad:~$

user@gnusquad:~/test$ cd ~
user@gnusquad:~$

user@gnusquad:~/test$ cd $HOME
user@gnusquad:~$

Comme vous venez de le voir, « ~ » correspond au répertoire personnel de l’utilisateur en cours (en anglais : sa « homedir») ; par extension nous pouvons suffixer ce « ~ » par le login de n’importe quel utilisateur pour atterrir directement dans son répertoire personnel (pour information : cette donnée se trouve, par défaut, dans le 6ème champ du fichier « /etc/passwd ») :

user@gnusquad:~$ cd ~www-data
user@gnusquad:/var/www$

user@gnusquad:~$ cd ~www-data/blog
user@gnusquad:/var/www/blog$

Imaginons maintenant que nous souhaitions revenir dans le répertoire précédent, deux possibilités s’offrent à nous : une, extrêmement simple et rapide et une autre, plus longue, qui à vrai dire, n’est là que pour vous signaler l’existence de la variable « OLDPWD » qui peut être utile lors de l’écriture d’un script :

user@gnusquad:~$ cd /var/www
user@gnusquad:/var/www$ cd -
user@gnusquad:~$

user@gnusquad:~$ cd /var/www
user@gnusquad:/var/www$ cd $OLDPWD
user@gnusquad:~$

Lorsque vous jonglez avec différents répertoires, il peut être pratique de les assigner à des variables pour ne pas devoir les taper systématiquement. Notez que vous pouvez très bien les utiliser en tant qu’arguments (exemple sur le billet « Modifier le contenu d’une révision dans un référentiel Subversion ») :

user@gnusquad:~$ WWW=/var/www
user@gnusquad:~$ SVN=/var/local/lib/svn/blog
user@gnusquad:~$ cd $WWW
user@gnusquad:/var/www$ cd $SVN
user@gnusquad:/var/local/lib/svn/blog$

Pour récupérer le chemin du répertoire courant dans une variable, on utilisera la commande « pwd » dans un sous-shell « $(xxx) ou `xxx` » :

user@gnusquad:/var/local/lib/svn/blog$ BLOG=$(pwd)
user@gnusquad:/var/local/lib/svn/blog$ BLOG=`pwd`

Une dernière astuce pour clôturer ce billet est l’utilisation d’un nouveau shell ce qui permet d’effectuer tout un tas d’opérations puis de retourner instantanément dans le répertoire précédent en appuyant simplement sur CTRL+D (commande « logout ») :

user@gnusquad:~$ bash
user@gnusquad:~$ cd /var/log/
user@gnusquad:/var/log$ …
user@gnusquad:/var/log$ ^D (CTRL+D)
user@gnusquad:~$

À titre d’information, il existe 3 commandes dédiées aux répertoires que je n’ai pas présenté parce qu’à mon sens, pas très pratiques. Je vous laisse consulter le manuel de « Bash » pour avoir l’aide des fonctions suivantes : « pushd », « popd » et « dirs ».

Sources :

• Sun May Begin Close Sourcing MySQL Features
• Mysql & FOSS