juin 25 2008

Debian weather est de retour !

Tag: Actualités, Debian GNU/LinuxSylvain @ 12:58

Debian Weather est un service non-officiel de Debian permettant d’avoir une indication sur la bonne santé de sa distribution préférée. Cette bonne santé, exprimée en %, est calculée simplement en divisant le nombre de paquets cassés (où toutes les dépendances ne sont pas satisfaites) par le nombre de paquets disponibles (uniquement la section « main »). Ce calcul est effectué chaque jour pour chaque distribution et pour chaque architecture, les résultats étant présentés sous forme d’icônes météo :

: % 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 :


juin 24 2008

Cookies d’Adobe Flash Player

Tag: Firefox, Logiciels diversSylvain @ 18:01

Vous utilisez Adobe Flash Player et vous pensiez vider complètement vos traces en utilisant la fonction idoine de votre navigateur ?
Si c’est le cas, vous aviez tort, allez faire un tour dans les répertoires suivants :

~/.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 :


juin 04 2008

Gestion des mime-types dans Subversion

Par défaut sous Subversion, l’heuristique utilisée pour détecter les mime-types est très basique ce qui est gênant lorsque l’on veut utiliser des fichiers (ex : des images) du dépôt via mod_dav_svn pour les intégrer dans un site.

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 :


mai 29 2008

Faire du SFTP dans un chroot avec scponlyc

Tag: Debian GNU/Linux, SystèmeSylvain @ 06:39

Commençons tout d’abord par expliquer les quelques termes alambiqués du titre de ce billet pour les néophytes :

  • 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 :


Page suivante »