willoblog

J'ai réinstallé récemment l'ordinateur qui me sert de télé/media center. J'ai un certain nombre de fichiers avi, que je regarde de temps en temps. Avant, je faisais ça avec, au choix, vlc, mplayer ou xine. Je me suis décidé à passer à Totem.

Pourquoi Totem ?

Bin simplement parce que c'est le logiciel par défaut de chez Gnome en fait, et donc le truc a priori le mieux intégré à mon environnement. Il est installé par défaut, il ne pause plus de problèmes de codecs comme j'ai toujours eu avant (et qui faisaient que je préférais l'éviter justement). Bref, pourquoi pas...
Autre avantage, il est plus rapide à se lancer que vlc, plus convivial que xine et... bon, ok, rien ne sera jamais mieux que mplayer. :)

Les codecs

Oui, tiens, précisons-le : il suffit d'installer le paquet ubuntu-restricted-extras, et il fait tout le reste... C'est pourtant simple, non ?

Problème : le lancement en plein écran

Moi ce que je veux, c'est juste d'ouvrir de façon systématique mes fichiers en double-cliquant dessus et que ça s'ouvre en plein écran. Je suis flemmard et je ne veux pas appuyer sur F après avoir ouvert le fichier. Avec tous les autres lecteurs, c'est une préférence à régler (dans un menu ou éventuellement un fichier de configuration).

Et là, on tombe sur un os. Impossible de trouver aucune configuration particulière, à part un .gconf/apps/totem/%gconf.xml inutilisable et un .gnome2/Totem/state.ini minimaliste. Le tout est visiblement mal documenté, ou du moins après avoir longtemps cherché je n'ai rien trouvé. Le menu des préférences bien sûr ne sert à rien.

Le man nous dit qu'il existe une option --fullscreen, mais uniquement pour Passer en plein écran une instance existante de Totem. Bon... Mal barrée cette histoire.

Et là, l'idée : créer un fichier /usr/local/bin/totem, qui sera systématiquement lancé à la place de l'original /usr/bin/totem, et y mettre ce qui va bien :

#!/bin/bash

[ "$TERM" != xterm ] && /usr/bin/totem $* || /usr/bin/totem "$*" &
sleep 1
/usr/bin/totem --fullscreen

Explications :

1. On lance /usr/bin/totem avec tous les arguments qu'on lui passe (en particulier, les noms de fichiers). Il faut échapper les noms si on lance totem en console, c'est pour ça que c'est un poil compliqué.
2. On attend une seconde, le temps que totem ait démarré. Sur une machine qui met un peu plus de temps, il faut rallonger...
3. On passe en plein écran.

C'est améliorable, je prends toute idée utile...

Edit 10 jours plus tard : J'avais oublié qu'il y a deux façon de prendre tous les arguments d'un script : "$*" concatène tout le monde entre des guillemets, on ne voit plus qu'un «mot»; "$@" met chaque argument entre des guillemets et les sépare par une espace, on voit le bon nombre de «mots». Il suffit donc de faire :

#!/bin/bash

/usr/bin/totem "$@" &
sleep 1
/usr/bin/totem --fullscreen

J'ai acheté un nouveau portable pour Noël (pas pour moi, pour Amélie en fait). Il s'agit d'un ultraportable. Le choix est restreint sur ce segment, sachant qu'on voulait un portable à la fois léger (2kg max) et puissant (processeur Intel Core 2 Duo T7100 minimum), et le tout sans mettre plus de 1300€.

Juste pour le garder à l'esprit, ça pourrait servir (piqué sur le blog de Damocles, en licence CC-ASA) :

Ça peut toujours servir. Au passage, ceux qui n'étaient pas au courant noteront combien il est facile de taper des accents sous Linux...

J'ai donc réinstallé mon serveur ce weekend, pour y mettre une Xubuntu toute neuve. J'ai installé proftpd, et je n'ai pas encore touché à la config (j'utilise en fait rssh et un certain paquet de comptes «réels», le tout pour faire du SFTP, ce qui est selon moi beaucoup plus sécurisé. J'y reviendrai, un jour...).

Le problème

Et là, je remarque avec horreur que tous les comptes utilisateurs créés peuvent se logguer en FTP et surtout se balader autant qu'ils veulent dans l'arborescence. Je n'avais jamais fait gaffe à ça. C'est très mauvais, en particulier parce que tout le contenu des connexions, depuis les mots de passe à la liste de tous les dossiers lus et le contenu des fichiers téléchargés, passent «en clair», non chiffrés.

La solution

Le problème vient de la directive AuthOrder, qui par défaut contient mod_auth_unix.c, ce qui signifie que la liste des utilisateurs est donnée par /etc/passwd (qui contient la liste des utilisateurs du système), les mots de passe étant stockés (chiffrés) dans /etc/shadow. Il faut donc rajouter dans /etc/proftpd/proftpd.conf (à éditer avec les droits root, par exemple avec sudo gedit /etc/proftpd/proftpd.conf ; personnellement j'utilise jed) :

AuthOrder mod_auth_file.c
AuthUserFile /etc/proftpd/proftpd.users

Cela dit à proftpd de ne pas utiliser /etc/passwd, mais uniquement le fichier spécifié dans la deuxième ligne.

Création des utilisateurs

C'est relativement simple, il y a un programme fait pour ça. Je vous laisse lire le résultat en console de man ftpasswd (j'espère que vous n'avez pas de problème avec l'anglais :) ). Au final, vous n'avez plus qu'à taper, tout simplement :

sudo ftpasswd --passwd --file=/etc/proftpd/proftpd.users --shell=/bin/false --uid=10000 --name=le_login --home=/le_repertoire_racine_de_l_utilisateur

en remplaçant bien sûr ce qui va bien... Mais ça ne suffirait pas, comme vous le dit la commande que vous venez de taper. Vous devez insérer dans /etc/proftpd/proftpd.conf juste en-dessous des lignes précédentes

RequireValidShell off

Relancez maintenant le serveur :

sudo /etc/init.d/proftpd restart

Il y a un dernier problème. En effet, connectez-vous en FTP avec l'utilisateur que vous venez de créer (ce lien doit fonctionner si vous faites ça en local), et remontez dans l'arborescence : tout est encore visible. Facile, il suffit de rajouter, toujours dans /etc/proftpd/proftpd.conf,

DefaultRoot ~

Cadeau bonus

Il y a encore quelques problèmes de sécurité. En fait, au moins deux choses à faire. D'abord, rendre le fichier /etc/proftpd/proftpd.users illisible aux autres utilisateurs que root, histoire que personne n'accède aux logins FTP, ni au mots de passe, même chiffrés :

sudo chmod 600 /etc/proftpd/proftpd.users

Ensuite, il faut juste avoir conscience que la directive DefaultRoot fait utiliser à proftpd le programme de «chrootage» chroot (pour «change root»), dont des failles de sécurité sont connues. Il vaut peut-être mieux en fait utiliser directement la configuration de proftpd, en enlevant DefautRoot et en ajoutant «à la place» :

<Anonymous /le_repertoire_racine_de_l_utilisateur>
  User le_login
  RequireValidShell off
  AnonRequirePassword on
  <Directory *>
    <Limit WRITE>
      DenyAll
    </Limit>
  </Directory>
</Anonymous>

C'est une configuration de base qui peut être largement améliorée, mais ceci est une autre histoire...

J'ai ici un ordinateur «fixe», actuellement sous Debian mais plus pour très longtemps à mon avis (on en reparlera...), qui sert accessoirement de serveur de toute sorte. Et deux portables (un à moi, un à Amélie). Et nos données, surtout en ce qui concerne le boulot, sont importantes... Donc on sauvegarde. Enfin, plutôt devrai-je dire : nos ordis sauvegardent tous seuls nos données ! :)

La solution que j'ai trouvée, c'est un script bash, lancé automatiquement par cron, qui utilise rsync.
Voilà le script, que j'ai simplement appelé sauvegarde :
$ cat /usr/local/bin/sauvegarde

#!/bin/sh
echo -n "Dernière sauvegarde effectuée le" > /home/login1/.rsync.log
date '+ %A %d %B %Y à %T' >> /home/login1/.rsync.log
rsync -vruLpogt --delete --delete-excluded --exclude=*.ies4linux* --exclude=*.wine* --exclude=*Cache* --exclude=.thumbnails* --exclude=.aptitude* --exclude=*lock --ignore-errors /home/login/ login2@serveur:. >> /home/login1/.rsync.log

Les paramètres de exclude sont modifiables à votre guise... login1 est mon login sur le portable, login2 sur le serveur. Chez moi ils sont identiques (c'est plus simple), mais ce n'est pas obligatoire.

Pour que cela fonctionne, écrire ce fichier ne suffit pas. Il faut (ça paraîtra évident à «ceux qui savent») :

• donner le droit d'exécution sur le script. Sur le portable : sudo chmod +x /usr/local/bin/sauvegarde
• que rsync soit installé sur les deux machines. C'est un logiciel de synchronisation qui utilise des connections sécurisées ici. Son principal avantage est de n'envoyer que les fichiers qui ont été modifiés depuis la fois précédente. Pour l'installer, il suffit de faire sur chaque machine sudo aptitude install rsync

Plus complexe, il faut aussi que l'on puisse se connecter en ssh sans rentrer le mot de passe. Par clé, quoi. Pour cela, sur le portable, je tape ssh-keygen -t dsa, ce qui génère les fichiers /home/login1/.ssh/id_dsa et /home/login1/.ssh/id_dsa.pub. id_dsa.pub, c'est la clé publique, celle que l'on partage avec les autres, celle qui fait qu'ils peuvent nous identifier. C'est un fichier qui contient une seule ligne. id_dsa, c'est la clé privée, celle qui ne doit jamais sortir. Sur serveur, il faut donc que le contenu de id_dsa.pub soit sur une ligne dans un fichier /home/login2/.ssh/authorized_keys.
Là où ça se complique, c'est que comme tout sera synchronisé, le fichier serait effacé si on ne l'avait pas sur le portable... D'où, tout simplement, sur le portable :

cat /home/login/.ssh/id_dsa.pub >> /home/login/.ssh/authorized_keys

Et ensuite, on envoie tout ça sur serveur :

scp -r /home/login1/.ssh login2@serveur:.

Il ne manque maintenant plus qu'une chose : que le script se lance automatiquement. Là, c'est cron entre en jeu. Il stocke les commandes qu'il lance et la périodicité dans un fichier inaccessible directement, mais on peut avoir la liste par crontab -l, supprimer toutes les commandes par crontab -r et éditer le fichier par crontab -e. Chaque utilisateur a sa crontab et ne peut accéder aux autres.
S'ouvre alors un éditeur de texte. Votre fichier doit ressembler au final à :
$ crontab -e

SHELL=/bin/sh
USER=login1
PATH=/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/games
0 5    * * *  sauvegarde

sauvegarde sera alors lancé toutes les minutes «zéro» de la cinquième heure de chaque jour. Une étoile représente un «chaque», et après minutes et heures nous avons jour de la semaine (de 0 à 7), jour du mois et mois. C'est relativement simple, non ?

Vous n'avez donc plus d'excuse pour ne pas faire attention à vos données !