Humus numericus - Mot-clé - sysadmin

Ce blog est désormais accessible en nozav.42 !

2010-12-30T00:23:00+01:00

Pour tester et soutenir l’expérience 42, ce blog est désormais accessible via l’adresse :

http://nozav.42/

…si bien sûr votre système a été configuré pour résoudre ce nouveau TLD alternatif.

Pour savoir comment faire (c’est pas forcément trivial, le plus simple est sans doute d’utiliser les DNS fournis par Geeknode), comprendre le projet, voire enregistrer votre propre nom de domaine en .42, c’est là :

https://www.42registry.org/

Console graphique avec grub2 sous Debian

2010-11-12T09:42:00+01:00

Le passage à grub2 sous Debian a entraîné quelques changements dans la configuration du bootloader, et notamment si on souhaite obtenir une console graphique au moment du boot et pas seulement 25 lignes et 80 colonnes de texte.

À noter que l’ancienne méthode fonctionne toujours, à savoir passer un argument supplémentaire du type vga=788 dans les paramètres du noyau, mais ça n’est plus la méthode recommandée.

Si on regarde dans le fichier /etc/default/grub, on constate la présence d’un paramètre GRUB_GFXMODE qui permet de spécifier une résolution pour les consoles graphiques. Celui-ci fonctionne pour l’invite de grub (celle où vous pouvez choisir quel noyau booter), mais n’est pas prise en compte pour la console qui s’affiche ensuite. Pour cela il manque en effet un paramètre, que nous pouvons ajouter à l’aide de la ligne suivante dans /etc/default/grub :

GRUB_GFXPAYLOAD_LINUX=keep

Mettez ensuite à jour votre grub :

$ sudo update-grub

Et voilà ! Vous devriez normalement avoir une jolie console graphique au prochain démarrage.

En guise de complément, on pourra aussi noter que :

on peut configurer la police de la console graphique et sa taille en modifiant les paramètres FONTFACE et FONTSIZE du fichier /etc/default/console-setup.
si vous ne savez pas quelle résolution indiquer dans GRUB_GFXMODE, vous pouvez ouvrir une console grub en tapant sur c à l’invite de grub et tapez ensuite la commande vbeinfo, qui liste les modes graphiques supportés par votre système.

Comment révoquer une clé PGP

2010-03-08T15:38:00+01:00

Je viens de révoquer une clé PGP avec GnuPG pour une ancienne adresse mail. Voici la marche à suivre.

D’abord il faut noter l’identifiant de la clé publique que l’on souhaite révoquer. Pour cela on fait un :

$ gpg --list-keys

Et on note l’identifiant (8 caractères hexadécimaux du type A1B2C3D4). Ensuite on génère un certificat de révocation qu’on stocke dans un fichier :

$ gpg --gen-revoke A1B2C3D4 > revoke.txt

Puis on importe ce certificat de révocation :

$ gpg --import revoke.txt

On exporte la clé publique désormais révoquée :

$ gpg --export -a A1B2C3D4

On peut alors uploader la sortie de cette dernière commande sur un serveur de clé type pgp.mit.edu et d’ici peu, le monde entier sera informé que votre clé ne doit plus être utilisée.

Don't put a dot in your cronjobs names !

2010-02-10T17:23:00+01:00

So you just setup a wonderful new cron job on your server that will make your life easier and your family happy. You put it in your /etc/cron.d in a file called wonderfulcronjob.sh but… your job is never launched.

You checked the permissions, the crontab syntax, ran the script manually, evertything is fine. You checked your syslog, but nothing is reported on it, not even the fact that the job is started. What’s the problem ?

The answer is in the run-parts manual page :

If the —lsbsysinit option is not given then the names must consist entirely of upper and lower case letters, digits, underscores, and hyphens.

So if you put a dot in your cron job name, it will not be run at all. Rename it to wonderfulcronjob-sh or just wonderfulcronjob and everything should work fine.

Thanks to birdy for finding this one…

Astuces Linux du jour

2008-12-02T00:19:00+01:00

Ajouter un utilisateur à un groupe rapido

Jusqu'ici, quand je voulais m'ajouter à un groupe, je faisais un bête :

# adduser julien group

Problème : dans ces cas-là on est obligé de fermer sa session pour que le changement soit pris en compte. Et bien je viens de découvrir la commande newgrp qui permet de faire ça directement :

$ sudo adduser username group
$ newgrp group

Source : http://linuxfr.org/comments/911699....

Accélérer les connexions SSH

Si vous avez tendance à vous connecter souvent aux mêmes serveurs, les versions récentes d'openSSH permettent d'accélérer les temps de connexion via du multiplexage de connexion. Pour cela il faut rajouter les lignes suivantes dans ~/.ssh/config (fichiers à mettre en 600) :

Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p

Puis de lancer un ssh de la manière suivante (par exemple dans votre .xsession :

ssh -fMN nomduserveur

A partir de là les temps d'établissement de connexion vers ce serveur seront beaucoup plus rapides...

Source : http://linuxfr.org/comments/911768....

Faire de l'ipv6 facilement

J'avais déjà essayé deux ou trois manières de me connecter en ipv6 depuis la maison, mais c'est en général un peu lorudingue : faut s'inscrire chez un tunnel broker, mettre en place des scripts, avoir une IP fixe... Mais je viens de tomber sur un article de Debian administration qui présente le paquet miredo qui permet de faire tout ça de manière hyper-simple. Une commande suffit :

# apt-get install install miredo

Et vous aurez la joie de voir la tortue danser !

Source : http://www.debian-administration.or...

Quelles belles courbes !

2008-11-25T11:09:00+01:00

Que voilà :

C'est quoi donc ? C'est le nombre de mails contenus dans la file d'attente du postfix de ce serveur... La jolie courbe bleue qui monte qui monte ce sont les 15000 mails reçus dans la nuit de dimanche à lundi suite à un envoi massif de spams depuis un autre serveur qui ne m'appartient pas mais dont je reçois les mails d'admin. Les 15000 mais sont tous les Undelivered mail returned to sender résultant de cet envoi de spams.

Bon ben tout ça n'a pas plu à mon postfix, mais surtout à mon dspam, qui a régulièrement lâché après les différentes relances effectuées dans la journée. Ça n'est que dans la soirée que j'ai vraiment pu m'occuper du problème (Lles jolies courbes verrtes sur la figure), surveiller dspam et le relancer lorsqu'il plantait. Mais vu le débit (pas plus d'un mail à la seconde, pas sûr que mon installation soit bien optimisée), j'en avais pour un moment.

Heureusement, j'ai pu trouver un petit script permettant de supprimer des mails de la file d'attente à partir d'un regexp sur le résultat de postqueue -p. Résultat, le script suivant :

while true; do for i in $( sudo postqueue -p |head -n 500 | grep -i mail |awk '{print $1}'|sed s/\*// );do sudo postsuper -d $i; done; done

m'a permis de terminer l'évacuation du bouchon vers 2h du matin, au lieu de beaucoup plus tard...

Problème avec VirtualBox

2008-05-14T17:54:00+02:00

VirtualBox est une application de virtualisation qui peut servir, entre mille autres choses, à faire tourner un windows à l'intérieur d'un linux.

Après la mise à jour de ma Debian unstable effectuée ce matin, plus moyen de démarrer l'appli. J'avais un pop-up d'erreur me signalant une impossibilité de démarrer les services COM, et en cas de lancement de la commande VirtualBox en ligne de commande, j'obtenais le joli message suivant :

/usr/lib/virtualbox//VBoxSVC: symbol lookup error: /usr/lib/virtualbox/VBoxXML.so: undefined symbol: _ZN11xalanc_1_1016XalanTransformer10initializeERN11xercesc_2_713MemoryManagerE

La solution ? Récupérer la dernière version (la 1.6) depuis le site de Virtual Box. Apparemment leurs dépôts Debian sont un peu en retard, d'ailleurs le lien de téléchargement renvoit sur le site de Sun, je ne savais pas qu'ils avaient été rachetés...

En tous cas l'installation du .deb pour Debian 4.0 a résolu le problème en ce qui me concerne.

Générer un certificat SSL auto-signé pour Apache

2008-05-14T11:27:00+02:00

D'abord on génère une clé non chiffrée sur disque (pour éviter d'avoir à saisir un mot de passe à chaque redémarrage d'Apache) :

# openssl genrsa -out mykey.key 1024

Ensuite on crée un certificat signé avec cette clé :

# openssl req -new -x509 -days 365 -key mykey.key -out mycert.crt

Répondre à l'ensemble des questions posées. Le nom de la machine doit être donné en réponse à Common Name. On peut utiliser un wildcard (joker) du type *.example.com pour que le certificat s'applique à un ensemble de sous-domaines.

Ensuite, dans Apache, modifier le fichier de définition du VirtualHost qui va bien :

NameVirtualHost *:443
<VirtualHost *:443>

        SSLEngine on
        SSLCertificateFile    /etc/ssl/mycert.crt
        SSLCertificateKeyFile /etc/ssl/mykey.key
        SSLVerifyClient none

        [etc., etc.]

</VirtualHost>

Automatiser les mises à jour de sécurité sous Debian

2007-01-12T22:10:00+00:00

Tout utilisateur de Debian qui se respecte connaît les dépôts de paquets spécialement conçus pour colmater les failles de sécurité. Dès qu'un problème est identifié, l'équipe de sécurité applique les correctifs existants et met tout ça à disposition le plus vite possible. Nous allons voir ici comment faire en sorte que ces mises à jour soient appliquées automatiquement, par exemple une fois par jour.

La première chose à faire est d'installer le paquet cron-apt, qui est spécialement fait pour ça :

# apt-get install cron-apt

Ce paquet permet de lancer une mise à jour à intervalle régulier. Le problème est que nous ne voulons mettre à jour que les paquets concernés par les problèmes de sécurité, et pas l'ensemble de notre distribution. Ceci est particulièrement important si on utilise une distribution testing ou unstable. Pour cela nous allons créer une source de paquets restreinte aux dépôts de sécurité. On va donc éditer un fichier /etc/apt/security.sources.list contenant la ligne suivante :

deb http://security.debian.org/ testing/updates main contrib non-free

(remplacez testing par stable ou unstable selon votre config)

Il faut ensuite indiquer à cron-apt d'utiliser ce fichier. Pour cela, ouvrez le fichier /etc/cron-apt/config et ajoutez ou décommentez la ligne suivante :

OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"

Par défaut, cron-apt ne fait que mettre à jour les sources de paquets, et ne les installe pas. Si vous souhaitez automatiser également l'installation, il faut que vous rajoutiez un fichier nommé 5-install dans le répertoire /etc/cron-apt/action.d/ et qui contient la ligne suivante :

dist-upgrade -y -o APT::Get::Show-Upgraded=true

Attention : il est normalement déconseillé d'effectuer ce genre d'actions automatiquement sur un serveur. En cas de problèmes lors de la mise à jour, ceci peut empêcher certains services de redémarrer. Dans tous les cas, pensez à bien regarder les rapports envoyés par Cron pour vérifier que tout s'est bien dérouolé...

Et voilou. Il nous reste à régler la fréquence et le moment des mises à jour. Par défaut elles ont lieu une fois par jour à 4h du matin (cf le fichier /etc/cron.d/cron-apt). Ceci est très bien si vous avez un serveur qui tourne en permanence. Mais pour une machine de bureau, on pourra plutôt utiliser anacron et faire un lien sympolique vers /usr/sbin/cron-apt dans /etc/cron.daily :

# ln -s /usr/sbin/cron-apt /etc/cron.daily/cron-apt

Boîtes aux lettres corrompues par Procmail

2006-08-18T22:45:11+00:00

Il y a visiblement un petit problème récurrent avec procmail, l'outil de tri de courrier électronique sous Linux, que la plupart des gens utilisent sans forcément le savoir. J'avais déjà rencontré le souci il y a pas mal de temps, ça s'était réglé, et finalement c'est revenu.

Le problème vient du fait qu'à certains moments, les fichiers stockant les messages reçus, du type /var/mail/user, sont corrompus car ils commencent par rom au lieu du traditionnel et attendu From. Du coup, plus moyen d'accéder aux messages situés à l'intérieur.

La solution est facile à trouver avec un minimum de googling, mais je la mets ici pour m'en souvenir : il suffit de rajouter le code suivant à la fin de votre fichier procmailrc (en général, ~/.procmailrc).

:0
* ^^rom 
{
 LOG="*** Dropped F off From_ header! Fixing up. "

 :0 fhw
 | sed -e '1s/^/F/'

}

Mettre en place un antivirus pour Linux à la maison

2006-02-06T10:41:28+00:00

A priori, le fait d'utiliser un système Linux met déjà son utilisateur à l'abri de la plupart des virus circulant sur le réseau et qui ciblent des systèmes plus répandus et moins fiables (suivez mon regard). Mais cela ne dispense pas d'utiliser un antivirus, surtout quand il en existe de très bons libres et gratuits comme ClamAV.

Voici la méthode que j'utilise pour filtrer mes mails à la maison. Elle utilise un ptit script Perl trouvé sur le web, et n'est certainement pas adéquate pour un gros serveur gérant des dizaines de comptes mails. Elle suppose que vous ayiez déjà un MTA (type postfix ou exim) qui tourne sur votre machine.

La première chose à faire est d'installer clamav en tant que démon. Sous Debian, comme toujours, c'est très simple, en une commande on installe tout ça ainsi que le service de mise à jour automatique de la base de virus :

# apt-get install clamav-freshclam clamav-daemon

La seconde chose est de faire passer tous les mails à travers l'antivirus. Ceci se fait à l'aide de la commande clamdscan. La solution la plus simple que j'ai trouvée consiste en un petit script Perl nommé clamfilter.pl. Le seul inconvénient est qu'il n'utilise pas le démon, mais le client clamav qui lui lance un processus à chaque mail scanné et prend beaucoup plus de ressources système. Le script étant du domaine public (vive le libre !), j'ai donc modifié une dizaine de caractères pour lui faire utiliser clamdscan plutôt que clamscan. Le résultat est le suivant :

#!/usr/bin/perl -w
#
# ClamFilter 1.0
# by Matt Hahnfeld (http://www.everysoft.com/)
# Requires perl, clamscan, procmail, and this script.
#
# This script is public domain.
#

use strict;
use File::Temp 'tempfile';

&main();
exit 0;

sub main {
  # Set up a temporary file for the original message
  my ($tmpfh, $tmpfn) = tempfile( UNLINK => 1 );
  -w $tmpfn or die 'Could not open temp file!';

  # Pass 1: Write out the temporary file
  while (<STDIN>) {
    print $tmpfh $_;
  }
  seek($tmpfh, 0, 0);

  # Pass 2: Scan the message
  open CLAMSCAN, "/bin/cat $tmpfn | /usr/bin/clamdscan --stdout - 2>/dev/null |" or die 'Could not open clamscan!';
  my $clamstatus = qq|X-Virus-Found: yes
X-Virus-Status:
 
 Virus Scan Status:
 
|;
  while (<CLAMSCAN>) {
    $clamstatus .= ' ' . $_;
  }
  close CLAMSCAN;
  $clamstatus .= qq| 
 

|;

  # Pass 3: Print out the message
  my $bodyflag = 0;
  while (<$tmpfh>) {
    if (! $bodyflag and $_ eq "
") {
      if ($?) {
	print $clamstatus;
      }
      else {
	print "
";
      }
      $bodyflag = 1;
    }
    else {
      print;
    }
  }
}

L'installation de ce script est très simple : copiez le contenu dans un fichier /usr/local/bin/clamfilter.pl, rendez le exécutable avec un petit chmod +x clamfilter.pl et ajoutez la ligne suivante dans votre fichier .procmailrc :

:0fw
| /usr/local/bin/clamfilter.pl

Et voilà ! Normalement tous vos mails devraient être scannés avant leur distribution. S'ils contiennent un virus détecté, le script rajoute un flag X-virus-found: yes dans les en-têtes (pratique pour créer des filtres automatiques dans votre lecteur de mail préféré) et ajoute quelques lignes d'information au début du message.

Vous pouvez tester le bon fonctionnement de votre installation d'abord en vérifiant qu'un mail normal passe sans problème, et ensuite en testant avec le fichier de test d'antivirus eicar.

Changer récursivement les permissions de répertoires

2005-05-12T15:15:31+00:00

Il peut parfois être utile de changer d'un coup les permissions ou les propriétés d'un répertoire et de ses sous-répertoires, mais seulement des répertoires, pas des fichiers normaux.

Deux exemples pratiques :

vous venez de transférer des fichiers depuis une parto windows, et ceux-ci ont tous la permission "éxecutable". Seulement, si vous faites un chmod -R -x *, vos répertoires vont perdre leur attribut exécutable et vous ne pourrez plus rentrer dedans. C'est gênant ;
vous avez un répertoire (par exemple /var/www) que vous voulez partager entre plusieurs personnes d'un même groupe (par exemple le groupe web). L'idéal est de positionner le "sticky bit" de ce répertoire et de ses sous-répertoire pour le groupe, afin que tous les fichiers nouvellement créés appartiennent également à ce groupe. Là aussi, un chmod -R g+s * pose problème.

Voilà donc la solution à ces deux problèmes. Il suffit de se positionner dans le répertoire racine choisi et de faire un :

find . -type d | xargs chmod +x

ou, pour le deuxième problème :

find . -type d | xargs chmod g+s

Et voilou !

Surveiller l'arrivée d'un mail

2004-09-23T11:42:03+00:00

Voici une petite astuce vous permettant de jouer un son lors de l'arrivée d'un mail ayant certaines caractéristiques (auteur, mot-clé, etc.). Ceci nécessite cependant d'utiliser procmail pour le filtrage de vos courriers, donc a priori d'être sous Linux ou équivalent.

Voici les lignes à ajouter à votre .procmailrc :

:0 hwic
* ^From:.*kikvouvoulez
| cat > /dev/null; /usr/bin/play /usr/share/sounds/toto.wav

Vous pouvez consulter l'explication de la syntaxe en anglais.

Pour personnaliser, il faut que vous remplaciez la deuxième ligne par l'expression rationnelle que vous voulez surveiller, et modifier la troisième ligne pour indiquer l'utilitaire pour jouer le son et le fichier à jouer.

Régler l'heure sous Linux

2004-08-30T11:25:11+00:00

Je sais pas vous, mais moi j'arrive jamais à me souvenir la syntaxe de la commande date qui permet sous unix/linux de consulter et modifier l'heure du système. Donc je le note une bonne fois pour toutes ici histoire de l'avoir sous la main, et dès fois que ça puisse servir à quelqu'un d'autre...

Donc la syntaxe est la suivante (en tous cas chez moi) :

# date MMDDHHmmAA

où MM est le mois, DD le jour, HH l'heure, mm les minutes et AA l'année, tous sur deux chiffres.

Par exemple, pour passer au 30 août 2004 à 11h23, la commande est, en tant que root :

# date 0830112304