J’ai une carte SD qui ne veut pas se laisser démonter : à ce qu’il paraît, une application en empêcherait le démontage (Resource Busy). J’ai essayé de la libérer en quittant toutes les applications classiques qui étaient ouvertes, sans succès : audacity, thunderbird, pidgin, firefox, rhythmbox, calculatrice, OO.org calc, terminal, les fenêtres nautilus. La corbeille a été vidée, itou. J’ai aussi essayé umount -l /media/disk, rien.
Méheu.
Il faut d’abord connaître l’endroit où la carte est montée (/media/disk dans mon cas), puis essayer de savoir quelle est cette application qui nous emmerde.
lsof | grep /media/disk
Cette commande renvoie la liste des processus (accompagnés de leur pid et tout le toutim, mais aussi du nom des fichiers qu’ils utilisent) amputée de toutes les lignes ne contenant pas /media/disk. Dans mon cas, c’était Nautilus qui gardait la main sur un fichier son mis à la corbeille (/media/disk/.Trash-1000/super-interview.wav)pour une raison inconnue. Il y a sûrement mieux comme commande, lsof a plein d’options, mais j’avais pas envie de découvrir-ce-merveilleux-outil-qu’est-lsof. Un autre jour peut-être (:
killall nautilus
umount /media/disk
Et ça marche, le volume est démonté. Ya plus qu’à redémarrer Nautilus : alt+f2, taper nautilus, entrée, et hop !
Non, le serveur n’est pas tombé dans la journée d’hier. Il y a eu une mise à jour de la sfr/neufBox pendant toute la journée, qui s’est soldée par un redémarrage de la dite box, ce que le serveur (en DHCP, pourtant) semble ne pas apprécier. J’ai fixé son adresse IP à sa MAC dans la box, on verra bien !
Edit : j’ai un peu modifié le patch en ne laissant dans des fichiers séparés que ce qui devait l’être. Tout le reste est inclus. Télécharger ici.
Pour une future surface de contrôle à base d’Arduino, très simple, j’avais besoin de pouvoir assigner chaque bouton du contrôleur à un paramètre différent de Pure Data selon le contexte, très rapidement et très simplement. Évidemment, c’est encore mieux si on peut rappeler les réglages, et les stocker sous une forme lisible.
Voici donc la ParaMatrice, qui fait exactement ce que son nom indique : elle permet à 20 contrôleurs différents d’être assignés à 20 paramètres différents, de stocker les couples contrôleur/paramètre et de les rappeler en un seul clic.
J’ai utilisé un système de stockage à base de [msgfile] (lib zexy), laaaargement inspiré du merveilleux tuto d’Obiwannabe.
Il faut choisir l’action a effectuer, puis l’emplacement (avec l’atom), et cliquer “Apply”. “Next” charge le preset suivant, “prev” le précédent, “R” recharge les presets à partir du fichier texte et “F” flushe le fichier dans la console Pure Data. Attention, car [msgfile] a un comportement bizarre, et veut un chemin absolu ou relatif selon qu’il lit ou écrit. Dans le doute, mettez un chemin absolu partout. Les sliders servent à démontrer le fonctionnement, ils ne sont pas connectables en l’état. Mais si vous avez compris tout ça, les utiliser sera un jeu d’enfant !
Le patch est téléchargeable ici.
Un petit billet en forme de bloc-notes qui répertorie différents projets de DDS sur base d’Arduino :
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1227287786
http://www.adrianfreed.com/content/arduino-sketch-high-frequency-precision-sine-wave-tone-sound-synthesis
http://interface.khm.de/index.php/lab/experiments/arduino-dds-sinewave-generator/
http://code.google.com/p/tinkerit/wiki/Auduino
AdZHosts distribue un fichier hosts de plus de 8000 lignes, contenant plus de 70000 URL douteuses ou inutiles, dont des régies publicitaires, des sites de statistiques, etc.
C’est très pratique à l’usage, car contrairement à une extension du genre Adblock, le contenu indésirable n’est pas chargé, puisqu’on redirige la requête vers la machine locale. Il y a un seul inconvénient, c’est que la personne qui fabrique et distribue ce fichier hosts peut être malveillante. En l’occurrence, en ce qui concerne AdZHosts, ça n’a pas l’air d’être le cas, mais restons vigilants (: Il est tout à fait possible qu’une personne malveillante glisse une ligne de ce genre au beau milieu du fichier :
12.34.56.78 www.ma-banque.fr
Que se passe-t’il alors ? Lorsque j’essaie de me connecter à www.ma-banque.fr, je me connecte en fait à l’IP 12.34.56.78, laquelle peut héberger un site identique à celui que j’ai demandé, mais qui en fait me vole mes identifiants. Cela s’appelle du phishing.
Nous allons vérifier qu’aucune vilaine ligne n’est présente. La vérification est très simple à faire :
~$ grep -nv '^127.0.0.1' /etc/hosts
Cette commande ne doit pas retourner de lignes inconnues de vous. Elle parcourt le fichier /etc/hosts, et renvoie toutes les lignes qui ne commencent pas par 127.0.0.1, potentiellement dangereuses, précédées de leur numéro de ligne. Chez moi, cela donne :
2:127.0.1.1 mamachine
3:
4:# The following lines are desirable for IPv6 capable hosts
5:::1 localhost ip6-localhost ip6-loopback
6:fe00::0 ip6-localnet
7:ff00::0 ip6-mcastprefix
8:ff02::1 ip6-allnodes
9:ff02::2 ip6-allrouters
10:ff02::3 ip6-allhosts
11:
12:#
13:# AdZHosts v0045
14:
Quelques lignes vides, des commentaires, des adresses de loopback : tout va bien. On remarque tout de même que la commande a trouvé ::1, qui est l’équivalent de 127.0.0.1 en IPv6.
On peut raffiner un poil cette commande, pour qu’elle prenne en compte les adresses en IPv6, qu’elle exclue les lignes vides et les commentaires :
~$ egrep -nv '^127.0.0.1|^::1|^$|^#|' /etc/hosts
Ce qui retourne maintenant :
2:127.0.1.1 mamachine
6:fe00::0 ip6-localnet
7:ff00::0 ip6-mcastprefix
8:ff02::1 ip6-allnodes
9:ff02::2 ip6-allrouters
10:ff02::3 ip6-allhosts
Voilà ! À partir de maintenant, si j’utilise un fichier hosts provenant d’une source non-sûre (c’est-à-dire pas moi), elle passera à la moulinette de cette commande.
Cet article part d’une question formulée sur ce forum, et la commande qui en résulte a été améliorée à partir des scripts présents sur cette même page.
Un matin, en regardant mes logs, j’ai vu ça :
[Tue Feb 02 14:16:54 2010] [error] [client 192.168.1.20] File does not exist: /var/www/favicon.ico
[Tue Feb 02 14:16:57 2010] [error] [client 192.168.1.20] File does not exist: /var/www/favicon.ico
[Tue Feb 02 14:28:36 2010] [error] [client 82.230.79.111] File does not exist: /var/www/favicon.ico
[Tue Feb 02 14:28:39 2010] [error] [client 82.230.79.111] File does not exist: /var/www/favicon.ico
[Tue Feb 02 18:27:07 2010] [error] [client 88.164.111.127] File does not exist: /var/www/favicon.ico
[Tue Feb 02 18:27:10 2010] [error] [client 88.164.111.127] File does not exist: /var/www/favicon.ico
[Wed Feb 03 05:55:12 2010] [error] [client 84.244.181.86] File does not exist: /var/www/roundcubemail
[Wed Feb 03 05:55:12 2010] [error] [client 84.244.181.86] File does not exist: /var/www/rc
[Wed Feb 03 05:55:12 2010] [error] [client 84.244.181.86] File does not exist: /var/www/webmail
[Wed Feb 03 05:55:12 2010] [error] [client 84.244.181.86] File does not exist: /var/www/roundcube
[Wed Feb 03 05:55:12 2010] [error] [client 84.244.181.86] File does not exist: /var/www/mail
[Wed Feb 03 05:55:13 2010] [error] [client 84.244.181.86] File does not exist: /var/www/README
Ce qui signifie plusieurs choses :
Pas de favicon
Je n’ai pas de favicon, et le navigateur la demande. Résolvons l’erreur, ça coûte rien et ça rend mes logs plus lisibles ; on se déplace dans le répertoire web par défaut /var/www/, puis on crée un fichier vide appelé favicon.ico, et enfin on lui attribue les bons droits :
~$ cd /var/www/
~$ sudo touch favicon.ico
~$ sudo chown 777 favicon.ico
Ouh le coquin
Un petit canaillou s’amuse à essayer de trouver un dossier qui n’existe pas. À la lecture du log, on voit bien qu’il ne me veut pas que du bien. J’avais déjà installé fail2ban, mais je n’avais créé de jail que pour SSH. Il va falloir en créer pour Apache : d’après mes recherches, il existe quelques jails classiques. On va éditer le fichier de config de fail2ban pour les ajouter.
sudo vim /etc/fail2ban/jail.local
Tant qu’on y est, on va faire en sorte de ne pas pouvoir bannir une adresse locale : chez moi, une adresse locale a la forme
192.168.1.*
On va donc compléter la ligne ignoreip comme suit :
ignoreip = 127.0.0.1 192.168.1.0/24
Et on ajoute nos jails :
# Jail pour les attaques dictionnaire qui visent phpmyadmin
[apache-admin]
enabled = true
port = http
filter = apache-admin
logpath = /var/log/apache*/error*.log
maxretry = 6
# Jail pour les curieux qui essaient de trouver un dossier au pif
[apache-404]
enabled = true
port = http
filter = apache-404
logpath = /var/log/apache*/error*.log
maxretry = 10
# Jail pour les attaques par requêtes DFind w00tw00t
[apache-w00tw00t]
enabled = true
filter = apache-w00tw00t
action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp]
logpath = /var/log/apache2/access*.log
maxretry = 1
Maintenant, les filtres associés à ces jails :
On crée le fichier pour la jail apache-admin
~$ sudo vim /etc/fail2ban/filter.d/apache-admin.conf
Et on y colle
[Definition]
failregex = [[]client <HOST>[]] File does not exist: .*admin|PMA|mysql
ignoreregex =
Ensuite on crée le fichier pour la jail apache-404
~$ sudo vim /etc/fail2ban/filter.d/apache-404.conf
Et on y colle
[Definition]
failregex = [[]client <HOST>[]] File does not exist: .*
ignoreregex =
Et puis on crée le fichier pour la jail apache-w00tw00t
~$ sudo vim /etc/fail2ban/filter.d/apache-w00tw00t.conf
Et on y colle
[Definition]
failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*".*
ignoreregex =
Ça, c’est fait. On recharge les préférences de fail2ban :
~$ sudo fail2ban-client reload
Et on vérifie que nos jails on bien été créées :
~$ sudo fail2ban-client status
Status
|- Number of jail: 4
`- Jail list: apache-admin, apache-w00tw00t, ssh, apache-404
On retrouve bien nos trois nouvelles jails (celle pour ssh était déjà là avant), tout va bien !
Un plugin Munin pour fail2ban
C’est bien beau tout ça, mais comment je sais si j’ai attrapé quelqu’un dans mes filets ?
Très simple, on va dire à Munin qu’il faut aussi surveiller fail2ban.
Créer le fichier /usr/share/munin/plugins/fail2ban
~$ sudo vim /usr/share/munin/plugins/fail2ban
On y colle :
#! /bin/bash
#
# script venant de Majorxtrem’s Blogs (merci)
# http://www.majorxtrem.be/2009/08/14/plugins-fail2ban-pour-munin/
PROGNAME=fail2ban
STATEDIR=/var/lib/munin/plugin-state
LISTJAIL=$(fail2ban-client status | grep " Jail list:" | sed 's/`- Jail list:\t\t//g' | sed 's/,//g')
if [ "$1" = "config" ]
then
echo 'system.type ABSOLUTE'
echo 'graph_title Fail2ban'
echo 'graph_vlabel Number of ban'
echo 'graph_category Security'
for f in $LISTJAIL; do
# replace - with _
echo "$(echo "$f.label" | tr - _) $f"
done
exit 0
fi
for f in $LISTJAIL; do
# replace - with _
echo "$(echo "$f.value" | tr - _) $(fail2ban-client status $f | grep " Currently banned:" | sed 's/ |- Currently banned:\t//g')"
done
Comme Munin n’aime pas les tirets (?), le plugin les remplace par des underscores.
On fait un lien symbolique du plugin dans le dossier des plugins Munin :
~$ sudo ln -s /usr/share/munin/plugins/fail2ban /etc/munin/plugins/
Et on rend le plugin exécutable :
sudo chmod +x /usr/share/munin/plugins/fail2ban
Pour que Munin puisse utiliser fail2ban, il doit avoir des privilèges plus élevés. On édite
~$ sudo vim /etc/munin/plugin-conf.d/munin-node
Et on ajoute
[fail2ban]
user root
Il n’y a plus qu’à redémarrer Munin :
~$ sudo /etc/init.d/munin-node restart
Et peu de temps après, bingo ! On a notre premier client :
~$ sudo vim /var/log/fail2ban.log
2010-02-08 11:21:49,698 fail2ban.filter : ERROR No 'host' found in '[Mon 2010] [error] [client 205.244.148.43] File does not exist: /var/www/mysql' using '<_sre.SRE_Pattern object at 0xb17c50>'
2010-02-08 11:21:51,312 fail2ban.actions: WARNING [apache-404] Ban 205.244.148.43
2010-02-08 11:31:52,146 fail2ban.actions: WARNING [apache-404] Unban 205.244.148.43
Du côté de Munin :
Bon évidemment, il n’ a été banni que 600 secondes, durée par défaut (ça fait 10 minutes, croyez-le ou non). Je vais augmenter ce temps, histoire de lui apprendre qu’on ne foule pas impunément mon territoire.
~$ sudo vim /etc/fail2ban/jail.local
Trouver la ligne bantime et mettre un nombre de secondes dissuasif :
bantime = 86400 #te voilà en taule pour 24h, brigand !
On recharge la configuration de fail2ban :
~$ sudo fail2ban-client reload
Et nous voilà débarrassés de cette engeance.
Billet tiré des pages suivantes :
- Plugin corrigé pour régler le problème des tirets : dans les commentaires de la page ci-dessus, d’après Didier Mission, mais le formatage casse le plugin. Ma version fonctionne pour de vrai
[apache-admin]
enabled = true
port = http
filter = apache-admin
logpath = /var/log/apache*/error*.log
maxretry = 6
[apache-404]
enabled = true
port = http
filter = apache-404
logpath = /var/log/apache*/error*.log
maxretry = 10
L’avantage de s’héberger soi-même, c’est qu’on peut s’offrir de petits raffinements, comme l’URL rewriting.
Pour être plus clair, les URL des billets vont passer de ça :
http://mon.domain.com/blog/?p=1
à ça :
http://mon.domaine.com/blog/2010/02/03/bonjour-tout-le-monde/
ce qui est plus long, mais plus compréhensible (et surtout plus cool, mais sachons rester simple).
Dans Wordpress, aller dans Réglages/Permaliens et choisir l’option “date et titre” (par exemple).
Enregistrer les modifications : Wordpress va nous donner quelques lignes qu’il voudrait nous faire insérer dans un fichier .htaccess :
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /MONBLOG/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /MONBLOG/index.php [L]
</IfModule>
Seulement, comme les fichiers .htaccess c’est top ringard et qu’on peut se le permettre, on va plutôt utiliser les possibilités du fichier de config d’Apache.
Mais d’abord, nous allons vérifier que le mod_rewrite d’Apache est bien activé :
~$ sudo a2enmod rewrite
Module rewrite already enabled
Pour moi c’est ok, alors éditons le fichier de configuration d’Apache:
~$ sudo vim /etc/apache2/apache2.conf
Nous allons ajouter quelques lignes à la fin de ce fichier (remplacer MONBLOG par le dossier qui contient l’installation Wordpress) :
# URL rewriting
Options +FollowSymlinks
RewriteEngine on
<Directory /var/www/MONBLOG>
# entre les balises directory, nous mettons les lignes fournies par Wordpress
</Directory>
Ce qui chez moi donne :
# URL rewriting
Options +FollowSymlinks
RewriteEngine on
<Directory /var/www/MONBLOG>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /MONBLOG/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /MONBLOG/index.php [L]
</IfModule>
</Directory>
Ne reste plus qu’à redémarrer Apache :
~$ sudo /etc/init.d/apache2 restart
Et voilà, à nous les URL de luxe !
Sources :
Apache tutorial : When (not) to use .htaccess files
http://www.wordpress-fr.net/support/viewtopic.php?pid=156156#p156156
http://doc.ubuntu-fr.org/apache2#activer_l_url_rewriting
Ça commence bien.
Résumé des épisodes précédents :
1. Achat d’un Packard Bell IMax Mini C2600FR pour 149€. Deux gigots de rames, 1.6GHz, 160 Go, environ 20W/h de conso, ce qui donne environ 20€ d’électricité par an.
2. Remboursement de la licence Windows Vista (40€) > prix total 109€. Pas mal ! Il faut juste envoyer l’ordi chez Packard Bell, qui prend tous les frais de transport à sa charge. J’attends encore le chèque de 40€…
3. Grâce à un live-USB, installation de la version serveur d’Ubuntu Karmic Koala (9.10). Grub n’était pas de bon poil, j’ai donc mis LILO ; et pour faire le malin jusqu’au bout, le système est installé sur des volumes logiques (LVM). On y revient plus tard.
4. Configuration du firewall avec iptables : pour le moment tout est bloqué vers l’extérieur sauf le port 80. Je débloquerai SSH plus tard, mais j’ai déjà installé fail2ban.
5. Installation de Munin, pour surveiller la conso mémoire, processeur, etc.
6. Installation d’un serveur obby, pour travailler de concert sur un même texte.
~$ sobby -p 6522 --password mot_de_passe -i --autosave-file=gobby --autosave-interval=10
7. Installation du daemon Deluge, pour télécharger et seeder des torrents. En ce moment, je partage deux isos Ubuntu 64bits, version desktop et serveur 9.10.
~$ sudo apt-get install deluge deluge-webui
~$ deluged &
~$ deluge -u web
8. Installation de Tiny Tiny RSS.
9. Configuration d’Apache, lien de /var/www avec un dossier situé dans le /home de l’utilisateur principal.
Et là, souci. J’ai modifié la page d’accueil de base d’Apache en remplaçant le fameux “It Works !” par une chouette image, laquelle reste désespérément invisible. Question de permissions ? Après un peu de lecture, je décide de me rendre membre du groupe www-data :
~$ sudo usermod -G www-data moi
Les plus perspicaces auront détecté une monumentale erreur : je suis bien devenu membre de www-data, mais je me suis aussi enlevé du groupe admin et de tout autre groupe dont je faisais partie.
Hum, comme dirait l’autre.
Pas la peine de réfléchir longtemps pour voir que je me suis mis dans un beau pétrin : plus personne n’est admin sur la machine.
Il n’y a pas 36 solutions, mais presque :
Méthode 1 : booter en recovery mode, histoire de redevenir root. Résultat : pas d’entrée recovery dans le menu LILO, juste un laconique “Linux”, et pas moyen d’aller fouiller dans la config comme avec Grub. Raaaaah. Fail.
Méthode 2 : chroot. Boot sur live-USB (f12 au bios pour changer le disque de démarrage), puis :
~$ sudo mkdir /media/system
~$ sudo mount </dev/partition> /media/system
Hophophop ! J’ai installé sur des volumes logiques, vous vous souvenez ? Où sont mes partitions ? Comment je fais ? J’essaie de faire comme d’hab.
~$ sudo mount /dev/sda1 /media/system
mount: type inconnu de système de fichiers 'LVM2_member'
Caramba. Un petit tour dans Synaptic, installation du paquet lvm2. On peut maintenant lister les volumes logiques :
~$ sudo lvmdiskscan
/dev/ram0 [ 64,00 MB]
/dev/serveur/systeme [ 4,77 GB]
/dev/ram1 [ 64,00 MB]
/dev/sda1 [ 149,05 GB] LVM physical volume
/dev/serveur/var [ 9,54 GB]
/dev/ram2 [ 64,00 MB]
/dev/serveur/data [ 95,37 GB]
/dev/ram3 [ 64,00 MB]
/dev/serveur/swap [ 1,91 GB]
/dev/ram4 [ 64,00 MB]
/dev/ram5 [ 64,00 MB]
/dev/ram6 [ 64,00 MB]
/dev/ram7 [ 64,00 MB]
/dev/ram8 [ 64,00 MB]
/dev/ram9 [ 64,00 MB]
/dev/ram10 [ 64,00 MB]
/dev/ram11 [ 64,00 MB]
/dev/ram12 [ 64,00 MB]
/dev/ram13 [ 64,00 MB]
/dev/ram14 [ 64,00 MB]
/dev/ram15 [ 64,00 MB]
4 disks
16 partitions
0 LVM physical volume whole disks
1 LVM physical volume
Et hop :
~$ sudo mount /dev/serveur/systeme /media/system
Ça marche, ce coup-ci ! On continue :
~$ sudo mount --bind /dev /media/system/dev
~$ sudo mount -t proc /proc /media/system/proc
On change d’environnement :
~$ sudo chroot /media/system
chroot: cannot run command `/bin/bash': Exec format error.
Fail 2.
Alors là, je suis colère, et j’ai plus envie de chercher d’où vient le souci (64 bits?).
Méthode 3 : j’édite /etc/group comme un gros porc, et j’ajoute mon user à la ligne ‘admin’. Et ça re-marche !
Moralité :
~$ sudo usermod -G www-data moi
C’est mal.
Il faut plutôt faire :
~$ sudo usermod -aG www-data moi
C’est parti !
L’Indien :
J’aimerais bien que tu restes. On va manger des chips.
Et puis parler de ce blog, auto-hébergé, ainsi que des quelques bricolages que je risque de commettre.
