météo sous linux avec ZyGrib
posté par cep le 7 décembre 2008
Dans cet article, j’avais déjà parlé d’un programme permettant de visualiser les fichiers grib sous linux.
Une autre solution, bien meilleure à mon avis, est d’utiliser ZyGrib, programme sous licence GNU GPL v3.
ZyGrib est l’équivalent du programme Ugrib sous Windows, simple à utiliser et avec beaucoup de fonctionnalités, y compris celle de faire une animation avec les données récupérées.
Il est aussi possible d’avoir la distance orthodromique entre deux poins, en mille marin ou Km. La vitesse du vent peut être affichée en noeuds, Km/h ou m/s. En outre la distance est bien sûr adaptée à la latitude. Par exemple vers les latitudes 40 Sud, 1° de longitude correspond à environ 44 milles nautiques.
Pour installer ZyGrib, il faut disposer de QT4 de Trolltech. Installation sous Debian / Ubuntu :
aptitude install libqt4-gui libqt4-core proj
wget http://www.zygrib.org/getfile.php?file= … 2_i386.deb
gdebi zyGrib_3.0.0_ubuntu2_i386.deb
Il est aussi possible d’installer des images de plus grande définition grâce à un script récupérable sur le site dans les pages de téléchargement.
Ensuite l’utilisation est identique à ugrib sous windows, on séléctionne la zone souhaitée et le téléchargement des data se fait automatiquement.
Quelques captures d’écran ( cliquer sur l’image pour avoir une vue agrandie ) :
La deuxième vue montre les conditions météo sur le Vendée Globe, à hauteur des îles Kerguelen.
cep
p.s. Pour ceux qui voudraient compiler ZyGrib sur une Debian ou Ubuntu, il faut modifier le fichier Makefile et remplacer :
QTBIN=/usr/lib/qt4/bin
par
QTBIN=/usr/bin
Topics : Général | 2 Commentaires »
dernier samedi du mois
posté par cep le 21 novembre 2008
On a parfois besoin de savoir à quelle date va tomber le dernier samedi du mois, ou autre jour de l’année.
Le petit programme ncal lancé sans paramètre supplémentaire affiche le mois en cours.
:~$ ncal
novembre 2008
lu 3 10 17 24
ma 4 11 18 25
me 5 12 19 26
je 6 13 20 27
ve 7 14 21 28
sa 1 8 15 22 29
di 2 9 16 23 30
Partant de là, la simple commande :
ncal |awk '/sa/ {print $NF}'
permet d’afficher la date du dernier samedi du mois en cours. Pour connaitre le dernier dimanche, il suffit de remplacer /sa/ par /di/ et pour un autre mois, il faut passer l’option du mois à ncal.
Ainsi on peut par exemple lancer précisément un script le dernier samedi du mois car cron ne le permet pas directement. Le script pourrait être :
#!/bin/sh
#compare la date du jour avec une référence
#représentant la date du dernier samedi du mois.
#Si les dates concordent, le programme ou le script
#passé en paramètre SAVE est lancé
SAVE=$(sh ton_script_à_lancer) #à adapter en portant le chemin du scrip
JOUR=$(date +%d)
REF=$(ncal |awk '/sa/ {print $NF}') #remplacer /sa/ pour un autre jour
if [ $JOUR = $REF ]
then
$SAVE
else
echo "ce n'est pas le bon jour"
fi
Il suffira ensuite de demander à cron de lancer cette tâche sur une plage de jours, par exemple du 22 au 31, et à son tour cette tâche lancera le programme au moment voulu.
ncal comme cal et calendar font parti du paquet bsdmainutils, en principe installé en standard sur toutes les distributions.
cep
Topics : Général, linux | Pas de commentaire »
Superblocs de secours ext3
posté par cep le 30 octobre 2008
Il peut être nécessaire de localiser les super blocs de secours sur un système de fichiers ext3 ou ext4 endommagé. Ces valeurs peuvent être utilisées pour lancer un fsck ou un mount alors que le premier super ne permet plus de lancer ces procédures.
Le man de fsck.ext3, pour l’utilisation de l’option -b précise :
-b superbloc
Au lieu d’utiliser le superbloc normal, utiliser un autre superbloc spécifié par
superbloc. On se sert de cette option lorsque le superbloc primaire a été corrompu.
L’emplacement du superbloc de sauvegarde dépend de la taille des blocs du système de
fichiers. Pour les systèmes de fichiers avec des blocs de taille 1K, le superbloc de
sauvegarde est situé dans le bloc 8193, avec des blocs de taille 2K, il se situe dans le
bloc 16384 et avec les blocs de 4K, dans le bloc 32768.D’autres superblocs de sauvegardes peuvent être retrouvés en utilisant le programme mke2fs avec l’option -n pour afficher les emplacements où les superblocs seraient créés.L’option -b de mke2fs, qui spécifie la taille des blocs du système de fichiers, doit être utilisée
pour que les emplacements des superblocs indiqués soient exacts.
L’usage de mke2fs peut être dangereux si l’on oublie d’y ajouter l’option -n.
Pour pailler à cet inconvénient, dumpe2fs nous offre une solution, et il a l’avantage de ne pas risquer d’écrire sur le système de fichiers.
En effet, dumpe2fs sans l’option -h nous donne des détails supplémentaires sur les descripteurs, dont l’emplacement de ces supers de secours. Il peut être utilisé aussi sur un système de fichiers monté.
Par exemple pour voir leur emplacement sur la partition /dev/hdc8, on va utiliser la commande dumpe2fs avec grep pour isoler uniquement les lignes mentionnant superbloc Secours et on utilise awk pour n’afficher que les 4 premiers groupes de mots dans chaque ligne. L’ensemble donnera :
:~# dumpe2fs /dev/hdc8 |grep ’superbloc Secours’ |awk ‘{print $1,$2,$3,$4}’
dumpe2fs 1.41.3 (12-Oct-2008)
superbloc Secours à 32768,
superbloc Secours à 98304,
superbloc Secours à 163840,
superbloc Secours à 229376,
superbloc Secours à 294912,
superbloc Secours à 819200,
superbloc Secours à 884736,
superbloc Secours à 1605632,
superbloc Secours à 2654208,
superbloc Secours à 4096000,
La conversion wordpress semble modifier le sens des ‘ ‘ je remets donc la ligne de commande :
dumpe2fs /dev/hdc8 |grep 'superbloc Secours' |awk '{ print $1,$2,$3,$4 }'
Maintenant, si on voulait utiliser le superbloc 819200 pour lancer un fsck avec option de réparation automatique, la commande serait :
:~# fsck.ext3 -v -f -y -b 819200 /dev/hdc8
Pour plus de détails sur les solutions afin de monter un système de fichiers ext3 endommagé, voir :
http://www.cepcasa.info/blog/?p=11
cep
Topics : Général, linux | Pas de commentaire »
mhddfs pour réunir des points de montage
posté par cep le 17 octobre 2008
Mhddfs ( Multi HDD Fuse Filesystem ) est un système permettant de regrouper virtuellement, et grâce à Fuse, plusieurs points de montages de systèmes de fichiers en un seul point, donnant ainsi l’impression que ce répertoire a la taille de l’ensemble des montages combinés.
La création de nouveaux fichiers ayant pour cible le point de regroupement se fera d’abord dans le premier point de montage, et ainsi de suite s’il y a manque de place. Par exemple si on regroupe /A /B /C en /D et on demande la création du fichier f en /D, f sera créé dans /A sous réserve que /A ait encore au minimum 4 Go de place disponible. Si ce n’est pas le cas, il sera créé en /B. La limite de 4 Go peut être modifié, mais ne peut descendre en dessous de 100 Mo.
- Exemple d’utilisation :
Avec mhddfs on va regrouper /mnt/commun/, /mnt/compil/, et /mnt/hdc4jfs, le tout dans /mnt/test/
:~# mhddfs /mnt/commun/,/mnt/compil,/mnt/hdc4jfs /mnt/test/ mhddfs: directory '/mnt/commun/' added to list mhddfs: directory '/mnt/compil' added to list mhddfs: directory '/mnt/hdc4jfs' added to list mhddfs: mount to: /mnt/test/ mhddfs: move size limit 4294967296 bytes
Avec la commande mount on vérifie ce qui a été monté :
:~# mount -tfuse.mhddfs /mnt/commun/;/mnt/compil;/mnt/hdc4jfs on /mnt/test type fuse.mhddfs (rw,nosuid,nodev)
Idem avec la commande df, qui révèle qu’un ensemble de 87 Go a été créé :
:~# df -aTh -tfuse.mhddfs Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur /mnt/commun/;/mnt/compil;/mnt/hdc4jfs fuse.mhddfs 87G 20G 68G 23% /mnt/test
Détail du pool, toujours avec la commande df :
:~# df -aTh /mnt/commun /mnt/compil/ /mnt/hdc4jfs/ /mnt/test Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur /dev/hdc6 xfs 53G 17G 36G 32% /mnt/commun /dev/hdc7 ext3 9,2G 3,0G 6,2G 33% /mnt/compil /dev/hdc4 jfs 26G 3,4M 26G 1% /mnt/hdc4jfs /mnt/commun/;/mnt/compil;/mnt/hdc4jfs fuse.mhddfs 87G 20G 68G 23% /mnt/test
Pour tester le fonctionnement du système, nous allons créer un fichier.img d’une taille de 200Mo dans /mnt/test :
:~# head -c 200m < /dev/zero > /mnt/test/fichier.img
Comme /mnt/commun était placé en première position dans la commande de construction du pool, je vérifie que le nouveau fichier y est bien présent, de même que dans /mnt/test/. Bien sûr un seul fichier a été créé :
:~# ls -lh /mnt/commun/fichier.img -rw-r--r-- 1 root root 200M oct 17 10:05 /mnt/commun/fichier.img phusis:~# ls -lh /mnt/test/fichier.img -rw-r--r-- 1 root root 200M oct 17 10:05 /mnt/test/fichier.img
Pour supprimer le regroupement, on va utiliser la commande fusermount avec l’option -u :
:~# fusermount -u /mnt/test
Mhddfs est toujours en développement. Il pourra aussi être avantageusement utilisé pour, par exemple, regrouper deux partitions logiques que l’on aurait voulu réunir mais qu’il est impossible de faire de par leur situation respéctive sans se lancer dans de grosses modifications. Pour autant il ne doit être comparé ni à une solution raid, ni à du lvm.
cep
Topics : Général, linux | 2 Commentaires »
Bind et VFS Shared subtrees
posté par cep le 16 octobre 2008
Depuis les noyaux 2.4 la commande mount –bind permet de monter en parallèle un point de montage sur un autre point de montage. Mais ces points de montage restent statiques.
Avec les shared subtree il est maintenant possible d’étendre les possibilités de bind et rendre le tout dynamique. Ainsi un mount ou un umount dans un point “clone” sera répercuté dans les autres points de montage. On peut ainsi distinguer quatre types de montages :
-a. shared mount = montage partagé répercutant les nouveaux montages ou démontages vers les “clones” et le montage source.
-b. slave mount = montage esclave qui se différencie du shared par le fait que mounts et umounts dans le montage esclave ne se répercutent pas dans le montage source.
-c. private mount = mount classique
-d. unbindable mount = on ne peut pas répercuter le point de montage, le bind va échouer.
Pour plus de détails, se référer au fichier /Documentation/filesystems/sharedsubtree.txt fourni avec les sources du noyau. Pour ceux qui n’ont pas les sources, je mettrai en annexe ce fichier.
Exemples d’utilisation du shared mount subtree :
Après avoir monté /dev/hdc4 dans /mnt/hdc4jfs, on donne le caractère shared au point de montage source puis on fait le bind vers le point de montage /mnt/test/
:~# mount --make-shared /mnt/hdc4jfs
:~# mount --bind /mnt/hdc4jfs/ /mnt/test
On vérifie grace à la commande mount que le bind est bien présent :
:~# mount |grep hdc4 /dev/hdc4 on /mnt/hdc4jfs type jfs (rw) /mnt/hdc4jfs on /mnt/test type none (rw,bind)
Pour vérifier avec df il faut ajouter l’option -a qui permet d’afficher les systèmes de fichiers factices.
:~# df -aTh -tjfs -tnone Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur /dev/hdc4 jfs 26G 3,4M 26G 1% /mnt/hdc4jfs /mnt/hdc4jfs none 26G 3,4M 26G 1% /mnt/test
Maintenant on va monter /dev/hdc8 dans /mnt/test/hdc8 pour vérifier que ce nouveau nom de montage se répercute aussi dans le point de montage source /mnt/hdc4jfs :
:~# mount /dev/hdc8 /mnt/test/hdc8/ :~# ls -lh /mnt/test/hdc8/ total 1,1G -rw-r--r-- 1 root root 997M jui 17 12:05 hda10_image drwxr-xr-x 23 cep cep 4,0K sep 6 18:30 linux-2.6-2.6.27~rc5 -rw-r--r-- 1 cep cep 552K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.diff.gz -rw-r--r-- 1 cep cep 4,9K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.dsc -rw-r--r-- 1 cep cep 61M sep 3 00:37 linux-2.6_2.6.27~rc5.orig.tar.gz drwx------ 2 root root 16K mai 6 09:21 lost+found drwxr-xr-x 2 cep cep 4,0K mai 9 08:47 ms_xp drwxr-xr-x 2 cep cep 4,0K sep 6 18:20 source_26
On vérifie qu’il est aussi présent dans /mnt/hdc4jfs/hdc8/ :
:~# ls -lh /mnt/hdc4jfs/ /mnt/hdc4jfs/hdc8/ /mnt/hdc4jfs/: total 80K drwxr-xr-x 6 cep cep 4,0K sep 15 16:10 hdc8 -rw-r--r-- 1 cep cep 39K oct 15 10:50 sharedsubtree.txt -rw-r--r-- 1 cep cep 32K oct 14 19:25 sharedsubtree.txt~ -rw-r--r-- 1 cep cep 64 oct 14 19:11 test_char.txt -rw-r--r-- 1 cep cep 0 oct 14 19:50 un /mnt/hdc4jfs/hdc8/: total 1,1G -rw-r--r-- 1 root root 997M jui 17 12:05 hda10_image drwxr-xr-x 23 cep cep 4,0K sep 6 18:30 linux-2.6-2.6.27~rc5 -rw-r--r-- 1 cep cep 552K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.diff.gz -rw-r--r-- 1 cep cep 4,9K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.dsc -rw-r--r-- 1 cep cep 61M sep 3 00:37 linux-2.6_2.6.27~rc5.orig.tar.gz drwx------ 2 root root 16K mai 6 09:21 lost+found drwxr-xr-x 2 cep cep 4,0K mai 9 08:47 ms_xp drwxr-xr-x 2 cep cep 4,0K sep 6 18:20 source_26
Comme j’ai monté de manière classique /dev/hdc8, c’est à dire sans bind, le df -a le signale seulement dans /mnt/test/hdc8.
De même la sortie de df montre qu’il est possible de mélanger les systèmes de fichiers :
:~# df -aT -tjfs -tnone -text4dev Sys. de fich. Type 1K-blocs Occupé Disponible Capacité Monté sur /dev/hdc4 jfs 26593952 3436 26590516 1% /mnt/hdc4jfs /mnt/hdc4jfs none 26593952 3436 26590516 1% /mnt/test /dev/hdc8 ext4dev 20295680 3770180 16319308 19% /mnt/test/hdc8
Par contre, si on donne le caractère unbindable à /mnt/hdc4jfs, le bind va échouer :
Depuis les noyaux 2.4 la commande mount –bind permet de monter en parallèle un point de montage sur un autre point de montage. Mais ces points de montage restent statiques.
Avec les shared subtree il est maintenant possible d’étendre les possibilités de bind et rendre le tout dynamique. Ainsi un mount ou un umount dans un point “clone” sera répercuté dans les autres points de montage. On peut ainsi distinguer quatre types de montages :
-a. shared mount = montage partagé répercutant les nouveaux montages ou démontages vers les “clones” et le montage source.
-b. slave mount = montage esclave qui se différencie du shared par le fait que mounts et umounts dans le montage esclave ne se répercutent pas dans le montage source.
-c. private mount = mount classique
-d. unbindable mount = on ne peut pas répercuter le point de montage, le bind va échouer.
Pour plus de détails, se référer au fichier /Documentation/filesystems/sharedsubtree.txt fourni avec les sources du noyau. Pour ceux qui n’ont pas les sources, je mettrai en annexe ce fichier.
Exemples d’utilisation du shared mount subtree :
Après avoir monté /dev/hdc4 dans /mnt/hdc4jfs, on donne le caractère shared au point de montage source puis on fait le bind vers le point de montage /mnt/test/
:~# mount --make-shared /mnt/hdc4jfs
:~# mount --bind /mnt/hdc4jfs/ /mnt/test
On vérifie grace à la commande mount que le bind est bien présent :
:~# mount |grep hdc4 /dev/hdc4 on /mnt/hdc4jfs type jfs (rw) /mnt/hdc4jfs on /mnt/test type none (rw,bind)
Pour vérifier avec df il faut ajouter l’option -a qui permet d’afficher les systèmes de fichiers factices.
:~# df -aTh -tjfs -tnone Sys. de fich. Type Tail. Occ. Disp. %Occ. Monté sur /dev/hdc4 jfs 26G 3,4M 26G 1% /mnt/hdc4jfs /mnt/hdc4jfs none 26G 3,4M 26G 1% /mnt/test
Maintenant on va monter /dev/hdc8 dans /mnt/test/hdc8 pour vérifier que ce nouveau nom de montage se répercute aussi dans le point de montage source /mnt/hdc4jfs :
:~# mount /dev/hdc8 /mnt/test/hdc8/ :~# ls -lh /mnt/test/hdc8/ total 1,1G -rw-r--r-- 1 root root 997M jui 17 12:05 hda10_image drwxr-xr-x 23 cep cep 4,0K sep 6 18:30 linux-2.6-2.6.27~rc5 -rw-r--r-- 1 cep cep 552K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.diff.gz -rw-r--r-- 1 cep cep 4,9K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.dsc -rw-r--r-- 1 cep cep 61M sep 3 00:37 linux-2.6_2.6.27~rc5.orig.tar.gz drwx------ 2 root root 16K mai 6 09:21 lost+found drwxr-xr-x 2 cep cep 4,0K mai 9 08:47 ms_xp drwxr-xr-x 2 cep cep 4,0K sep 6 18:20 source_26
On vérifie qu’il est aussi présent dans /mnt/hdc4jfs/hdc8/ :
:~# ls -lh /mnt/hdc4jfs/ /mnt/hdc4jfs/hdc8/ /mnt/hdc4jfs/: total 80K drwxr-xr-x 6 cep cep 4,0K sep 15 16:10 hdc8 -rw-r--r-- 1 cep cep 39K oct 15 10:50 sharedsubtree.txt -rw-r--r-- 1 cep cep 32K oct 14 19:25 sharedsubtree.txt~ -rw-r--r-- 1 cep cep 64 oct 14 19:11 test_char.txt -rw-r--r-- 1 cep cep 0 oct 14 19:50 un /mnt/hdc4jfs/hdc8/: total 1,1G -rw-r--r-- 1 root root 997M jui 17 12:05 hda10_image drwxr-xr-x 23 cep cep 4,0K sep 6 18:30 linux-2.6-2.6.27~rc5 -rw-r--r-- 1 cep cep 552K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.diff.gz -rw-r--r-- 1 cep cep 4,9K sep 5 00:37 linux-2.6_2.6.27~rc5-1~experimental.1~snapshot.12183.dsc -rw-r--r-- 1 cep cep 61M sep 3 00:37 linux-2.6_2.6.27~rc5.orig.tar.gz drwx------ 2 root root 16K mai 6 09:21 lost+found drwxr-xr-x 2 cep cep 4,0K mai 9 08:47 ms_xp drwxr-xr-x 2 cep cep 4,0K sep 6 18:20 source_26
Comme j’ai monté de manière classique /dev/hdc8, c’est à dire sans bind, le df -a le signale seulement dans /mnt/test/hdc8.
De même la sortie de df montre qu’il est possible de mélanger les systèmes de fichiers :
:~# df -aT -tjfs -tnone -text4dev Sys. de fich. Type 1K-blocs Occupé Disponible Capacité Monté sur /dev/hdc4 jfs 26593952 3436 26590516 1% /mnt/hdc4jfs /mnt/hdc4jfs none 26593952 3436 26590516 1% /mnt/test /dev/hdc8 ext4dev 20295680 3770180 16319308 19% /mnt/test/hdc8
Par contre, si on donne le caractère unbindable à /mnt/hdc4jfs, le bind va échouer :
:~# mount --make-unbindable /mnt/hdc4jfs
:~# mount --bind /mnt/hdc4jfs/ /mnt/test
mount: wrong fs type, bad option, bad superblock on /mnt/hdc4jfs, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
Dans un prochain article je montrrai comment il est possible d’étendre simplement la taille d’un système de fichiers avec mhddfs.
cep
Annexe : /Documentation/filesystems/sharedsubtree.txt
Topics : Général | Pas de commentaire »
bips machine
posté par cep le 3 octobre 2008
Les bips machine sont parfois agaçants.
Il est possible de les supprimer totalement en ajoutant la ligne xset b 0 dans .bashrc pour avoir :
:~$ grep -1 bell .bashrc ## ding bell off xset b 0
Une autre solution est de ne supprimer que les bips lors de l’utilisation de l’autocompplétion, qui sont tout de même les plus fréquents et les plus inutiles.
Pour cela il faut modifier en conséquence les lignes se rapportant au ” bell ” dans /etc/inputrc. On peut choisir de ne plus avoir de bip, ou bien d’avoir un bip visuel.
Exemple de configuration :
:~$ grep bell /etc/inputrc # do not bell on tab-completion set bell-style none # set bell-style visible
cep
Topics : Général, debian, linux, ubuntu | 3 Commentaires »
datapacker
posté par cep le 29 septembre 2008
Je voulais graver sur cdrom de nombreuses photos, tout en conservant le classement initial et l’ordre chronologique. Après quelques recherches, grâce à The Changelog j’ai enfin trouvé datapacker qui me semble pour le moment la solution idéale.
Pour son installation, un paquet deb est disponible pour debian lenny et sid en version 1.0.1, et ubuntu intrepid en version 1.0.0.
Datapacker est très rapide, car on peut utiliser l’option hardlink qui ne copie pas réellement le document à archiver mais fait un lien “en dur”, pointant sur l’emplacement physique du fichier source. De ce fait les copies des répertoires source ne prennent pas de place sur le système de fichiers, et on peut supprimer ensuite ces liens sans risque pour la source.
Si l’on utilise l’option hardlink, il faudra rester sur le même système de fichiers (partition). Il faut aussi créer le répertoire de destination des listes de fichiers à graver. Pour l’exemple nous l’appellerons bins.
On peut préciser aussi en option quelle taille donner aux fragments des sauvegardes, suivant que l’on veut les graver sur cdrom ou dvdrom, ou tout autre destination.
Nous utiliserons aussi les option :
-D pour préserver la structure des répertoires source, leur agencement. Cette option est aussi utile s’il y a des fichiers avec le même nom dans différents répertoires source.
-p pour conserveer l’organisation des répertoires source et l’ordre chronologique s’il y en a un. Les photos par exemples ne seront pas déplacées d’un dossier à un autre pour permetre de satisfaire la taille des répertoires demandé
-b pour formater le nom des fichiers de destination, par exemple avec %03d pour nommer chaque répertoire par un nombre à trois chiffres.
Exemple d’utilisation pour décomposer le dossier ~/photos/ en containers de 600 Mo :
On utilise find avec le paramètre -iname afin de faire porter la recherche sur des noms des fichiers indifféremment en majuscule ou en minuscule, et “*.[j-p]*g” pour sélectionner toutes les extensions jpeg, jpg, png.
Avec l’option -b et %03d les noms des répertoires de sauvegarde seront composés de trois chiffres.
Ce qui, sur deux lignes ( \ ) pour en simplifier la lecture, donne les commandes :
:~$ cd ; mkdir bins
:~$ find ~/photos -iname "*.[j-p]*g" -print0 | \ datapacker -0Dp -s 600m --sort -a hardlink -b ~/bins/%03d -Il a ainsi été créé quatre sous-dossiers (containers) portant les noms de 001, 002, 003, 004 dans le répertoire ~/bins/. On peut en vérifier la taille par la commande :
:~$ du -sh bins/00* 601M bins/001 600M bins/002 599M bins/003 18M bins/004
Pour montrer en détail le fonctionnement de l’option hardlink, avec ls -i on va regarder le numéro d’inode de quelques photos de la “sauvegarde”, et les comparer avec les numéros d’inodes des photos sources :
:~$ ls -i1 bins/003/home/sidcep/photos/soudan/ 212725 cailloux2.jpg 81862 cailloux.JPG 81860 P1010081.JPG 81864 P1010083.JPG 81866 P1010084.JPG 81868 P1010085.JPG 81824 P1010086.JPG sidcep@phusis:~$ ls -i1 /home/sidcep/photos/soudan/ 212725 cailloux2.jpg 81862 cailloux.JPG 81860 P1010081.JPG 81864 P1010083.JPG 81866 P1010084.JPG 81868 P1010085.JPG 81824 P1010086.JPG
Ce sont bien les mêmes inodes, ce qui prouve qu’il n’a pas été fait une copie réelle de l’original, et que l’on ne peut parler de sauvegarde tant que la gravure des listes n’a pas été réalisée.
Pour la petite histoire, on aurait aussi pu comparer les inodes par :
:~$ stat -c %i /home/sidcep/photos/soudan/cailloux.JPG ~/bins/003/home/sidcep/photos/soudan/cailloux.JPG 81862 81862
ou par :
:~$ find . -inum 81862 -print0 ./bins/003/home/sidcep/photos/soudan/cailloux.JPG ./photos/soudan/cailloux.JPG
ou bien :
:~$ find . -samefile ~/photos/soudan/cailloux.JPG -print0 ./bins/003/home/sidcep/photos/soudan/cailloux.JPG ./photos/soudan/cailloux.JPG
Par un pipe, on peut aussi demander à ce que datapacker passe la main directement à genisoimage pour graver les cdroms. D’autres exemples d’utilisation sont présentés dans les pages man.
cep
Topics : Général, debian, linux, ubuntu | Pas de commentaire »
comparer dates
posté par cep le 28 septembre 2008
Suite aux commentaires d’Alexandre dans l’article sur tests et bash, voici une solution si le but est vraiment de comparer les dates de deux fichiers. Pour cela on peut utiliser la commande stat avec l’option %y pour afficher la date de la dernière modification. On peut aussi utiliser d’autres options d’affichage comme détaillé dans le man stat.
La commande sera donc :
$ stat -c %y ancien nouveau 2008-01-17 12:30:00.000000000 +0100 2008-09-28 18:21:44.000000000 +0200
Si on veux l’utiliser plus généralement sur d’autres fichiers, on peut faire un script. Dans ce cas, on remplacera %y par %Y pour avoir l’affichage de la ” date de la dernière modification en secondes depuis le temps zéro de l’ordinateur “ :
#!/bin/sh # dat_comp.sh # usage ./dat_comp.sh fichier_1 fichier_2 FIC=$1 FIC2=$2 stat1=$(stat -c %Y $FIC) stat2=$(stat -c %Y $FIC2) if [[ $stat1 = $stat2 ]] then echo "dates semblables" else echo "dates différentes" fi
Exemple d’utilisation :
$ sh dat_comp.sh ancien nouveau dates différentes $ touch un deux $ sh dat_comp.sh un deux dates semblables
cep
Topics : Général, linux | Pas de commentaire »
crypto/padlock-aes.ko warning
posté par cep le 24 septembre 2008
Si je charge le module aes dans une debian, j’ai un message d’erreur :
:~# modprobe aes [sudo] password for sidcep: WARNING: Error inserting padlock_aes (/lib/modules/2.6.26-1-686/kernel/drivers/crypto/padlock-aes.ko): No such device
Cependant deux modules aes sont bien chargés :
:~$ grep aes /proc/modules aes_i586 7744 0 - Live 0xd8b59000 aes_generic 29256 1 aes_i586, Live 0xd8bd0000
Malgré le message d’erreur padlock-aes.ko est bien présent dans /lib/modules/ du kernel :
:~$ ll /lib/modules/2.6.26-1-686/kernel/drivers/crypto/padlock-aes* -rw-r--r-- 1 root root 7772 sep 10 23:10 /lib/modules/2.6.26-1-686/kernel/drivers/crypto/padlock-aes.ko
De même dans la config du kernel
:~$ grep -i _aes /boot/config-2.6.26-1-686 CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m
Ce message n’est pas vraiment gênant. Il l’est bien d’avantage si l’on automatise le chargement du module au boot.
Pour solutionner ce problème, il aurait été possible de blacklister padlock_aes dans /etc/modprobe.d/blacklist
mais cela provoque toujours l’affichage d’un message précisant que ce module a été blacklisté.
Or dans /lib/modules/version_kernel/modules.alias il y a justement un alias aes vers padlock_aes.
:~$ grep "aes padlock" /lib/modules/2.6.26-1-686/modules.alias alias aes padlock_aes
La solution ( temporaire ) sera donc de commenter cet alias.
Avant tout, on fait une sauvegarde de ce fichier :
:~# cp /lib/modules/2.6.26-1-686/modules.alias /lib/modules/2.6.26-1-686/modules.alias_save
Ensuite, comme ce fichier contient 7863 lignes, il serait très long et malaisé de le parcourir pour y trouver notre ligne. On va donc utiliser perl (ou sed) :
:~# perl -i -p -e 's/alias aes padlock_aes/#alias aes padlock_aes/g;' /lib/modules/2.6.26-1-686/modules.alias
On vérifie si la ligne a bien été commentée :
:~# grep "aes padlock" /lib/modules/2.6.26-1-686/modules.alias #alias aes padlock_aes
On peut maintenant charger le module sans message d’erreur, et vérifier sa présence :
:~# modprobe aes :~# grep aes /proc/modules aes_i586 7744 0 - Live 0xd8b59000 aes_generic 29256 1 aes_i586, Live 0xd8bd0000
L’inconvénient de cette solution est qu’il faudra refaire la procédure lors de chaque mise à jour du noyau ( à moins que le bug disparaisse ).
Si l’avertissement ne gêne pas, et afin de ne pas avoir à éditer modules.alias à chaque mise à jour du noyau, il est aussi possible de blacklister ce module par la commande :
echo "blacklist padlock_aes" >> /etc/modprobe.d/blacklist
Pour plus de détails, voir :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464673 message 50.
cep
Topics : Général, debian, linux | 1 Commentaire »
tests et bash
posté par cep le 18 septembre 2008
À l’usage des débutants, différentes façons de comparer en bash si un fichier est plus ancien qu’un autre au moyen des opérateurs
-nt : teste si un fichier est plus récent qu’un autre fichier
-ot : teste si un fichier est plus ancien qu’un autre
On crée un fichier ancien dont la date de création sera le 17 janvier 2008, et un fichier nouveau portant la date actuelle :
$ touch -t 01171230 ancien $ touch nouveau $ ll total 0 -rw-r--r-- 1 cep cep 0 jan 17 2008 ancien -rw-r--r-- 1 cep cep 0 sep 17 16:53 nouveau
Avec la commande test on vérifie si nouveau est plus récent que ancien, et suivant le cas on affiche vrai ou faux
$ test nouveau -nt ancien && echo vrai ||echo faux vrai $ test nouveau -ot ancien && echo vrai ||echo faux faux $ test ancien -nt nouveau && echo vrai ||echo faux faux
On remplace echo vrai ou faux par l’équivalent $? qui va renvoyer 0 = vrai ou 1 = faux
$ test ancien -nt nouveau ; echo $? 1 $ test ancien -ot nouveau ; echo $? 0
On peut avoir le même résultat en remplaçant test par les [ ]
$ [ ancien -nt nouveau ];echo $? 1 $ [ nouveau -nt ancien ];echo $? 0
Pour d’autres options de tests, voir man bash.
cep
Topics : Général, linux | 5 Commentaires »
