humani nil a me alienum puto

Aller au contenu | Aller au menu | Aller à la recherche

lundi 25 août 2008

comment régler les problèmes d'accents sur FAT32 entre windows et linux

Il faut parfois partir du fait bien connu que Linux sait tout faire pour ne pas désespérer. J'espère que le titre est assez explicite pour google, car il n'y pour l'instant aucune bonne réponse sur google. Et à vrai dire, il n'y a pas d'aide du tout, même sur ce qui sert justement à résoudre le problème. Quel est-il, d'ailleurs ? Eh bien lors de la remigration de p'tite soeur vers les forces du bien, et sauvant in extremis les données (avant application de la fameuse méthode windaubienne par défaut : réinstallation de XP -- et Toshiba, ils ne mettent qu'une seule partition, donc le neuneu perd ses données sans même savoir ce qui lui arrive), avec une Mandriva One qui traînait dans mon sac (déjà une chance que je passais par là, une autre chance que j'avais piqué un live CD au dernier picnic libriste), en copiant directement le dossier des utilisateurs de la partoche NTFS (reconnue et montée automatiquement pas la Mandriva, notera-t-on) sur un disque dur externe en FAT32 (une autre mauvaise idée : ce format obsolète est le plus simple moyen au windaubien moyen de se faire couilloner dans les largeurs).

Et là, ce qui se passe, c'est que les accents sont paumés : le NTFS est en UTF-8, et le FAT32 en autre chose ; enfin, je crois, toujours est-il qu'à un moment où à un autre, quand vous regardez le dossier que vous avez copié, tous les accents sont morts. Et le problème est assez courant. Nous allons donc mener l'enquête et régler le problème (spoiler : en fait je suis parti dans un grand délire faute de doc correcte, donc si vous voulez vraiment avoir la solution, et que gogole vous a amené ici, allez directement à la fin du billet, c'est en gras).

Déjà, il faut chercher un peu sur le net d'où vient le problème : c'est une question de codage différent, comme je disais précédemment, et on apprend que sur FAT32 on parle le windows-1258. D'ailleurs, sous DOS, on parle autre chose : eh oui, encore une fois, m$ n'est pas foutu de rester compatible avec lui-même. Mais niveau solutions proposées ici et là, c'est mortel : on a droit à du renommage à la main (super !) ou à de l'astucieux iconv : un ls pipé dans "iconv -f windows-1258 -t
utf-8", et le tour est joué, y'a plus qu'à faire un script et rendre le truc récursif : au secours !! (essentiellement parce que la solution va entraîner une surcharge pas possible, outre le script chiant comme la mort à écrire).

On se dit donc qu'un montage intelligent du volume pourrait régler la situation : man mount, et voilà qu'on apprend que

iocharset=valeur
   Jeu de caractère pour les conversion entre les caractères 8 bits et  les  caractères  16  bitS  Unicode.  Par  défaut  c'est iso8859-1.  Les noms de fichiers longs sont stockés sur le disque en format Unicode.

Et ça tombe bien, parce qu'on est dans les options pour le montage de volumes FAT. Et on se dit que iso8859-1, c'est pas pareil que windows-1258, ah ça non. Du coup, quand on fait un ls sur le répertoire, on tombe par exemple sur ce genre de choses pas belles :

test�

Bouh pas beau. Alors, on va regarder de quoi il s'agit exactement, ce truc-là :

# ls test/test� | hexdump -C
00000000  74 65 73 74 2f 74 65 73  74 e9 0a                 |test/test..|
0000000b

Plusieurs remarques : la complétion marche, et si c'est mal affiché, c'est que l'encoding du terminal n'est pas bon ; ceci dit, j'ai essayé de le changer, ça ne m'a pas affiché mes accents pour autant. Deuxième remarque : on n'est pas ici sur le disque dur de ma p'tite soeur mais sur une maquette de test que j'ai faite à la main, déjà parce que c'est mieux pour bidouiller sans altérer des données, ensuite parce que j'étais déjà retourner à Paris lors de mon enquête, mais j'ai noté l'essentiel, à savoir qu'un accent "é" se note 0xE9. Et ça tombe bien, c'est justement ce que nous dit windows1258 (en cherchant ce lien, j'apprends que c'est le codage préféré pour le vietnamien, gné ?). En tout cas, c'est fortement incompatible avec l'ASCII, mais on s'en doutait, m$ adoooore faire des trucs incompatible avec tout ce qui existe déjà.

Parlons rapidement de cette maquette de test :

# cd /tmp
# dd if=/dev/zero of=testfat bs=1M count=1
# mkfs.vfat testfat
# mkdir testdir
# mount -o loop testfat testdir
# cd testdir; touch teste; umount testdir

Nous voilà donc avec un fichier "testfat" contenant une partition FAT32, où se trouve un fichier unique "teste" : on ouvre avec un éditeur hexadécimal (et faute de trouver que khexedit avait changé son nom en okteta, j'ai utilisé ht en curses), on se place à hauteur du second "e" de "teste", et on replace par un 0xE9. On sauve, et c'est prêt : si l'on remonte le volume FAT, on voit un "?" à la place de l'accent, chouette non ? Notons que nous devons monter en loop device, puisqu'il s'agit d'un fichier (pour ceux qui viendrait de BSD : c'est pareil que le vnconfig, mais là ça marche, et c'est pas limité à quatre...), mais qui faut tout de même être root pour faire ça (ce que je trouve être un peu trop, des fois les restrictions peuvent être trop de choses -- pour ceux qui voudraient bidouiller du ext sans avoir à monter un fichier de la sorte, j'indique l'utilitaire debugfs).

Revenons-en à notre iocharset. On essaie de monter avec windows1258 :

# mount -o loop,iocharset=windows1258 testfat test
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       Dans quelques cas certaines informations sont utiles dans syslog - essayez
       dmesg | tail  ou quelque chose du genre

"C'est le drame" (avec ou sans tiret). Manifestement iocharset admet des trucs en iso*, mais pas en windows*. La question est donc de savoir : que peut-il accepter, et y aurait-il un codage compatible avec notre cochonerie made in m$ ? Je vous le donne dans le mille : y'a pas de doc, pas de liste, que dalle. C'est là où il n'y a plus qu'une solution : explorer le code du noyau.

Car on s'en doute bien, c'est au niveau du noyau que ça se passe. Je vous fait grâce du cours sur les systèmes de fichier : faut bien que je puisse me faire de l'argent de poche dans les écoles d'ingé de la capitale :D  (mais c'est rudement bien foutu -- assez classique en fait comme montage pour les UNIX, mais là, comme je disais, ça marche). On va directement dans les dossier de gestion du FAT. En fait, il y a : vfat, msdos, et une partie commune fat (tout court). C'est là qu'on fait un pari : celui que l'appel ioctl va filer l'option avec le même nom de "iocharset" au kernel, parce que le pifomètre nous dit, après apprentissage, que le monde Linux est souvent très cohérent avec lui-même. Au pire il faudra mater le code de mount, mais je vous laissez deviner : bingo !  :)

À partir de là, il faut remonter où mène cette option iocharset ; en fait, pas bien loin. Et là ça devient très intéressant. On remarque qu'un message d'erreur kernel doit être émis lorsque le mount chie dans la colle pour cause de charset invalide : vérifions.

# dmesg | tail -2
Unable to load NLS charset windows1258
FAT: IO charset windows1258 not found

Oh oh ! On est bien au bon endroit. On voit des trucs qui s'appelle "NLS" partout : dans le message d'erreur, mais aussi dans les noms des fonctions, comme "load_nls", qui prend d'ailleurs comme argument... "options.iocharset". Ça tombe bien, tiens. Je vous fait grâce de la recherche sur internet : y'a pas de doc. Y'a pas de manuel non plus (c'est la peine d'essayer info ?). Et manifestement, rien dans /usr/src/linux/Documentation/filesystems/, bref le truc est codé, mais on ne sait rien dessus...

Filons donc dans le code...

#ifdef CONFIG_KMOD
        ret = request_module("nls_%s", charset);
        if (ret != 0) {
                printk("Unable to load NLS charset %s\n", charset);
                return NULL;
        }
        nls = find_nls(charset);
#endif

Voilà donc notre erreur ! Et d'où ça vient ? Du "request_module" : chargement de module. Qui doit avoir un nom en nls_* : regardons donc dans le dossier NLS ! Y'a du cp*, du iso*, du koi8*, du eucjp, et notre ami l'utf8. Bonne nouvelle : les cp*, après recherche, sont les équivalents en norme unicode des codage windows*. Mauvaise nouvelle : y'a un tas de numéro, mais pas de cp1258 à l'horizon, et les numéros en dessous ne sont pas compatibles. Cherchons tout de même la table des caractères. On y trouve :

0xE9    0x00E9    #LATIN SMALL LETTER E WITH ACUTE

On googlise le truc, et on trouve l'ISO8859-14. Miracle : les accents et autre cédille correspondent au niveau de leurs codages en hexadécimal ! Et surtout, re-miracle : l'iso8859-14 est supporté niveau iocharset par NLS ! NLS, on l'a bien compris, c'est un module avec un ensemble de modules auxiliaires, qui permet la traduction à la volée des noms de fichiers d'un codage à un autre. On essaie donc le montage :

# mount -o loop,iocharset=iso8859-14 testfat test

Et là... ça marche pas  >_<". Va falloir continuer l'enquête... Regardons la fonction __fat_readdir, ie la fonction auxiliaire où est codé ce qui est appelé par "ls" via l'appel système stat/readdir : plus exactement au moment de l'affichage. On y remarque que les circuits passent soit par du iocharset, soit par de la traduction utf8, et selon que l'option "utf8" est présente ou non. Moralité :

# mount -o loop,utf8 testfat test

Et ça marche. Parfois faut pas se faire chier  :D. Il semblerait qu'en fait, iocharset soit destiné à... la traduction inverse, d'unicode (sur le disque) vers charset (à l'affichage). Mais franchement, l'aide la plus complète dans les sources du noyau Linux, linux/Documentation/filesystems/vfat.txt :

iocharset=name -- Character set to use for converting between the
                 encoding is used for user visible filename and 16 bit
                 Unicode characters. Long filenames are stored on disk
                 in Unicode format, but Unix for the most part doesn't
                 know how to deal with Unicode.
                 By default, FAT_DEFAULT_IOCHARSET setting is used.

                 There is also an option of doing UTF-8 translations
                 with the utf8 option.

                 NOTE: "iocharset=utf8" is not recommended. If unsure,
                 you should consider the following option instead.

utf8=<bool>   -- UTF-8 is the filesystem safe version of Unicode that
                 is used by the console.  It can be enabled for the
                 filesystem with this option. If 'uni_xlate' gets set,
                 UTF-8 gets disabled.

uni_xlate=<bool> -- Translate unhandled Unicode characters to special
                 escaped sequences.  This would let you backup and
                 restore filenames that are created with any Unicode
                 characters.  Until Linux supports Unicode for real,
                 this gives you an alternative.  Without this option,
                 a '?' is used when no translation is possible.  The
                 escape character is ':' because it is otherwise
                 illegal on the vfat filesystem.  The escape sequence
                 that gets used is ':' and the four digits of hexadecimal
                 unicode.

Assez sibyllin... Bref, on aura appris des trucs au moins  :). Notamment que Linux sait tout faire, même des trucs qu'on sait pas trop ce que c'est, et qui sont documentés bizarrement... En tout cas on aura trouvé notre solution au problème de codage des caractères accentués sur volume FAT32 : il faut monter avec l'option utf8. C'est tout  :D.

Ce moment d'intense geekitude vous était offert par...

mardi 12 août 2008

PXE pour OpenSUSE 11

Comme c'est un vrai merdier pour trouver deux ou trois informations à droite à gauche, et qu'il vaut mieux être un maître jedi Linux pour s'en sortir, voici les instructions pour mettre en place un PXE OpenSUSE11.

Warning: la rédaction informe que le présent article contiendra beaucoup trop de réseau, et recommande donc aux âmes sensibles de s'éloigner, et aux autres d'avoir un saut à proximité.

Tout d'abord, mettez-vous dans un réseau privé : c'est tellement abominable à monter en temps normal que l'on ne va pas en plus s'embêter avec des firewall et des restrictions de règles... Si vous êtes sous OpenSUSE/Fedora/Ubuntu et que le NetworkManager est actif, commencez par vous mettre hors ligne : ça évitera à un dhcpclient farceur de vous casser les pieds une fois que votre dhcpd sera en place (sinon il faudrait faire une règle spécifique pour votre adresse MAC, mais on n'a pas que ça à foutre).

Première étape : le tftp, c'est comme ça que le noyau PXE sera chargé (les gens qui font de l'embarqué connaissent très bien tftp). A partir d'ici, il faudra être root (ie : il faut tout faire en root). Dans un répertoire /tftpboot, copiez les fichiers suivant que vous trouverez dans le CD d'installation de l'OpenSUSE 11 (ici monté automatiquement dans /media/SU1100.001/) :

mkdir -p /tftpboot/pxelinux.cfg
cp /usr/share/syslinux/pxelinux.0 /tftpboot
cp /media/SU1100.001/boot/i386/loader/linux /tftpboot
cp /media/SU1100.001/boot/i386/loader/initrd /tftpboot
cp /media/SU1100.001/boot/i386/loader/isolinux.cfg /tftpboot/pxelinux.cfg/default
cp /media/SU1100.001/boot/i386/loader/message /tftpboot/pxelinux.cfg/

On va faire un truc vite fait mal fait, donc on ne s'embête pas à renommer les bidules, à optimiser, à faire un joli message d'invitation, bref on trace (sinon, la conf est dans le sous-répertoire pxelinux.cfg, c'est assez simple) (vous pouvez préconfigurer le futur NFS en rajoutant l'option  install=nfs://192.168.1.1/root/suse à la ligne qui commence par "append initrd=initrd", mais on vous posera quand même la question plus tard, c'est juste les champs concernés seront déjà remplis).

N'oubliez pas de lancer le serveur TFTP : il se trouve dans xinetd, à vous de voir comment configurer la bête (avec YaST ça se fait simplement, via l'interface de conf de xinetd). Au pire, dans le fichier /etc/xinetd.d/tftp :

service tftp
{
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = root
        server          = /usr/sbin/in.tftpd
        server_args     = -s /tftpboot
}

Puis redémarrez xinetd : /etc/init.d/xinetd restart (généralement). N'utilisez pas d'autre serveurs TFTPd que celui dans xinetd : ils sont bidons.

Deuxième étape : le serveur dhcp local, histoire de filer une IP à votre machine à installer lorsqu'elle bootera sur le réseau (évidemment, pensez à bien modifier le BIOS pour qu'il fasse ça). Copiez-collez :

option domain-name "pxeboot";
default-lease-time 14400;
ddns-update-style none;
subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.2 192.168.1.100;
  default-lease-time 345600;
  max-lease-time 345600;
  filename "pxelinux.0";
  option routers 192.168.1.1;
}

L'option filename indique le fichier qui sera filé pour booter. On donne des adresses à partir de 192.168.1.2 pour se réserver la 192.168.1.1 :

ifconfig eth0 192.168.1.1

(à adapter pour l'interface qui vous sert pour l'installation du PXE).

Il faut aussi indiquer quelle est l'interface concernée par le dhcpd : dans le fichier /etc/sysconfig/dhcpd, il faut que la ligne
DHCPD_INTERFACE="eth0"
soit bien mise (par exemple, sur mon Dell, c'est eth2 à la place de eth0 partout).

Troisième étape : le serveur NFS, c'est comme ça que votre PXE une fois chargé sur la machine distante (celle à installer) ira chercher les fichiers d'installation. Il faut d'abord copier le DVD entier sur disque dur :

mkdir /root/suse
cp -R /media/SU1100.001/.* /root/suse


Ensuite, on configure le serveur NFS. Dans le fichier /etc/exports, rajouter la ligne :

/root/suse      (ro,no_root_squash,async,anonuid=0,anongid=0)

Comme vous l'aurez remarqué, il vaudra mieux virer cette ligne ensuite : pas de contrôle d'accès (on pourrait mettre 192.168.1.* juste avant la parenthèse, en théorie), mais c'est du RO, donc on peut se permettre de ne pas squasher root (ie un accès root de l'extérieur est toujours root chez vous).

Vous redémarrez votre serveur NFS (/etc/init.d/nfsserver restart, généralement), et vous priez un bon coup : c'est surtout le NFS qui est galère, pour débugger tcpdump -i eth0 n'est jamais de trop.


Virez le Firewall si vous en avez un, ça évitera tout un tas de galères. Redémarrez votre PC à installer sur le réseau, ça devrait prendre une IP du style 192.168.1.99, puis charger le PXE par TFTP, puis faire défiler tout un tas de choses sur l'écran. Enfin, des boîtes de dialogue toutes moches en curses vont apparaître : laissez-vous guider, jusqu'à l'invite d'installation. Là il faudra préciser que les sources sont sur le NFS, indiquer la bonne interface réseau à emprunter (c'est pas le WiFI, c'est l'autre, là, filaire), puis dire que l'IP est obtenue par DHCP, que l'IP du NFS est 192.168.1.1, et que le chemin est "/root/suse".

Entrée, et normalement, ça devrait charger (sinon, débugguer à coup de tcpdump, une fois il se trompait d'interface, l'autre fois il n'avait pas les droits, etc). Dès que ça charge, on passe en graphique tour joli : vous avez gagné ! N'oubliez pas de tout nettoyer ensuite, sinon ça va foutre un bordel pas possible sur votre PC (genre il va prendre des IPs locales sur votre dhcp, etc).

vendredi 20 juin 2008

retour chez les geeks

Ça faisait bien longtemps que je n'avais pas vu mes amis geeks des premiers et troisièmes jeudis, essentiellement des Parinuxiens, d'ailleurs. Il faut dire qu'à chaque fois, ça tombait plutôt mal, et pour la grande majorité, en conflit direct avec ma vie sociale, un truc étrange que le geek ne connaît pas par définition, justement, et on comprend bien pourquoi. Car il faut vraiment être un no life pour s'amuser avec du uClinux sur de la DS ou de la PSP (mention spéciale pour le mec qui a intégré ça, et qui est allé jusqu'à coder un clavier en frame buffer accessible via les touches de jeu ! J'ai appris au passage que Sony a mis un MIPS sans MMU, je savais même pas que ça pouvait exister ; et qu'ils codent via un lien série passant par le jack stereo, que l'on peut même détourner pour faire une télécommande).

Il n'y avait pas vraiment grand monde lorsque je suis arrivé en retard au Bon Pêcheur, où se sont déjà passé les deux dernières éditions (c'est juste en face des Halles). Dont deux filles, plus tard renforcées par deux autres blondes, dont l'une découvrira que ça parle Linux dans le coin (soupir  :)  ). Je gagne un pin's Suse au passage, après tout c'était aussi hier la sortie de l'OpenSUSE 11, j'en reparlerai dès que je l'aurai installée !

Parlons simplement des activités geeks sur l'agenda : samedi, au carrefour du numérique de la cité des sciences, se déroulera la seconde partie dédiée aux grands débutants d'initiation à LaTeX (j'ai appris que de braves humains ne savaient toujours pas ce que c'est : il s'agit de l'outil de composition de documents destinés à la publication le plus puissant et pratique qui soit, où il n'y a qu'à entrer la structure du document, et laisser calculer la mise en page dans une étape séparée de compilation), ce sera un atelier, la présentation générale ayant déjà eu lieu ; le dimanche 22 juin, se sera install party à la Cantine (Grands boulevards, passage des Panoramas au 151 rue Montmartre, c'est dans une allée à gauche) ; le prochain first jeudi se déroulera le 3 juillet aux RMLL, mais comme c'est à Mont-de-Marsan, soit beaucoup trop paumé pour moi, je n'en serai pas ; third jeudi le 17 juillet, en revanche ; puis premier picnic du libre le 26 juillet, devant la Tour Eiffel (le second traditionnel aux Buttes Chaumont aura lieu le 30 août).

mercredi 18 juin 2008

entre deux compil', on s'amuse comme on peut

Let us pray...

Our system, who art on raised tile,
Hallowed be thy OS.
Thy portage come, thy emerge be done,
On servers, as it is on workstations.
Give us this day, our daily sync,
And forgive us our broken ebuilds,
As we forgive those who break ebuilds against us.
Lead us not into dependency frustration,
But deliver us from rpm evil.
For thine is the make.conf, the USE flags,
And the profile forever...
Gentoo.

Ce sont de grands malades, chez gentoo  :). Inspiré quelque part par the church of Emacs ; en fait, y'a encore un peu de marge pour arriver à leur niveau.

mercredi 11 juin 2008

pures mathématiques

Le xkcd de ce matin est tellement trop vrai...



Sinon, pour satisfaire les geeks informaticiens, j'ai cette superbe non-méthode de parsing d'arguments (en Java) ; un truc pour militaire, manifestement : aussi rapide d'exécution que porcasse dans l'absolu.

mercredi 4 juin 2008

le boeuf défunté, ou la geekerie amusante du jour

Sur l'une des ML que je suis (un hyperviseur de paravirtualisation libre), au cours d'une discussion sur "alignment fault at 0xdeadbefb from thread: 80000004" :

> Hi Geoffrey
>
> I attached the disassembled code. In the clist create function, it seems
> as if the first malloc returned a bad pointer(r4, MR04: 0x00000101).
> Maybe this is indicating an error condition? So when the code tries to
> write in the array, it is not performing a word aligned access (e.g.
> 0x101+12)

Hi Lukas

That is 8040282c not 8000282c :)

As stated the faulting memory address is 0xdeadbefb which, apart from
not being aligned on a 4 byte boundary looks a bit suspect.

Probably it is trying to dereference offset 0xc from 0xdeadbeef?

"La solution était dans le DEAD BEEF" (sur un thème de, lui même repris de). M00h !

lundi 19 mai 2008

les merveilles de la libc

Trois extraits de man pour la route :

1. strfmon

L'appel
              strfmon(buf, sizeof(buf), "[%^=*#6n] [%=*#6i]",
                      1234.567, 1234.567);
       affiche
              [ fl **1234,57] [ NLG  **1 234,57]
       Dans la localisation hollandaise (fl étant "florijnen" et NLG "Netherlands Guilders").  Le caractère de groupement  est  horrible  car  il  prend
       autant  de place qu'un chiffre, alors qu'il ne devrait occuper qu'un demi-espace, ce qui peut induire en erreur.  Etonnament, le "fl" est précédé
       et suivi par un espace, et "NLG" est précédé par un espace et suivi par deux.  Il s'agit peut-être d'un bogue dans le  fichier  de  localisation.
       Les localisations italienne, australienne, suisse, et portugaise donnent
              [ L. **1235] [ ITL  **1.235]
              [ $**1234.57] [ AUD **1,234.57]
              [Fr. **1234,57] [CHF  **1.234,57]
              [ **1234$57Esc] [ **1.234$57PTE ]

2. strfry :

NOM
       strfry - Créer une anagramme d'une chaîne.

SYNOPSIS
       #include <string.h>

       char *strfry (char *string);

DESCRIPTION
       La  fonction   strfry()  crée  une anagramme du contenu de la chaîne string en utilisant la fonction rand(3) pour échanger aléatoirement des car-
       actères.

3. memfrob :

NOM
       memfrob - Crypter une zone de mémoire.

SYNOPSIS
       #include <string.h>

       void *memfrob (void *s, size_t n);

DESCRIPTION
       La  fonction  memfrob()  crypte  les  n  premiers octets de la zone de mémoire s en effectuant un OU-exclusif entre chaque octet et le nombre 42.
       L'effet inverse est obtenu en rappelant à nouveau memfrob() sur la zone cryptée.

       Notez que cette fonction n'est pas vraiment un cryptage, car la constante du OU exclusif est fixée. Elle est simplement  utile  pour  cacher  des
       chaînes de texte clair.

C'qu'on se marre. A noter qu'à chaque pauvre utilisation de dynamique de la libc, ces fonctions à la con sont aussi chargées en mémoire. edit: une fois suffit, qu'on en ait besoin ou pas, mais qu'une seule fois (cf commentaires) Tout à coup ça fait moins rire.

Puisque j'y suis, avez-vous vu ces illustrations hyper drôles à propos de la dernière faille abominable (ah, les mêmes dessins, ça a eu du succès :) ) sur openSSL sous Debian (&co, dont ubuntu) de ces derniers jours ?

vendredi 18 avril 2008

pas la classe

Conrad vient de m'envoyer une pub avec le truc le plus geeko-stupide que je n'aie jamais vu : une casquette à ventilateur intégré marchant à l'énergie solaire ! Comme ce genre de lien commercial peut mourir à tout moment, je vous ai fait un screenshot de la bête (et en différents coloris, tant qu'à faire).



Je subodore que ça ne doit pas trop aider pour draguer les filles, tout de même...

jeudi 27 mars 2008

le single user sur openBSD (et ses facéties)

Pour un truc hyper sécurisé, des fois, ça me laisse songeur... Regardez le code par ici de init. BSD n'est pas SystemV, donc ça ne marche pas comme un Linux de base : il ne fait que lancer le script /etc/rc (codé en dur) ; il n'y a pas d'inittab. De fait, la présence de login via getty est déduite en fonction du fichier /etc/ttys, qui par défaut en met un sur tty00, la première console (on remarquera que getty est dans /usr/libexec, encore une des plaisanteries pas drôle de cet OS mal fichu ; à remarquer que c'est pareil sur MacOS, d'après ce que j'ai vu).

Sauf que si l'on regarde dans le code, la lecture de ce fichier se fait via la fonction "read_ttys()", qui elle-même appelle "start_session_db()" ; si cela échoue, c'est "single_user()" qui est appelé (par pointeur de fonction), sinon plus bas, c'est "multi_user()" (idem). multi_user, c'est le truc standard, avec un login/mot de passe demandé pour se logguer. Tout ceci se passe évidemment après avoir lu et entièrement exécuté le fichier /etc/rc (fonction "runcom()" ; à remarquer que c'est le même script qui est exécuté lorsque l'on arrête ou que l'on reboote la machine, pratique non ? Heureusement, un argument "shutdown" est passé dans ce cas, fonction "nice_death()"), tout ce qui doit être démarré pour avoir un système viable (un serveur apache, par exemple) est donc démarré. Notamment, on a depuis longtemps dépassé la fonction "main()" qui avec son while sur getopt en tête, vérifie que l'on n'a pas explicitement demandé un single mode dans le sens unixien/linuxien du terme, c'est-à-dire le fameux démarrage en mode dégradé directement sur shell (remarquons d'ailleurs que de plus en plus de distribution Linux semblent désactiver cette fonction du kernel par défaut : sinon avec un accès physique à un portable, il suffit d'éditer la ligne de conf avant démarrage, sous grub, et ajouter "single" à la liste des arguments, avant de changer le mot de passe root et redémarrer, par exemple) ; sous bsd, ça s'appelle en mettant un argument "-s" au noyau (stocké usuellement dans /bsd, soit à la racine, tout est simpliste dans ce monde).

Résumons : le single user est comme sous Linux, et tout aussi dangereux ; il n'est pas désactivable, sauf à compiler le kernel sans support de la ligne de commande (la gestion de la compilation de bsd est d'ailleurs des plus folkloriques ; à noter que la notion de modules n'est pas encore au goût du jour, et que désactiver le support d'une carte pcmcia dont on n'a que faire peut avoir des conséquences fâcheuses inattendues -- j'ai fini par la remettre, j'étais prévenu -- ah, si vous trouvez la faq austère, sachez qu'elle est en réalité fort complexe, si si, et que c'est pour ça qu'elle n'est pas aux standards w3c). C'est-à-dire que s'il est déclenché, on se loggue sans mot de passe en root, et l'on peut faire la fête sur le système. Parlons donc de cette fonction "start_session_db()"...

Il semble que bien des choses reposent sur db, la base de donnée antédiluvienne, notamment la gestion des mots de passe (pas de shadow mais un pwd.db). Et apparemment pour la gestion des ttys aussi. Or, db a besoin de son répertoire /var/db. Que se passe-t-il si le disque est plein, ou si /var est read-only ou du moins non inscriptible, par exemple parce que le file system de sa partoche (enfin, slice, je passe sur les détails...), est corrompu et automatiquement monté en ro ? (ce qui peut avoir des conséquences tragi-comiques : ayant un fichier sur lequel j'ai créé par virtual node -- le loopback du pauvre sur bsd -- un système bsd complet, et notamment une partition primaire bootable, le fait de vouloir la monter alors qu'un qemu fermé un peu trop vite m'avait un peu pourri le file system -- qui n'est pas journalisé, sous bsd --, a fait détecter au système que je voulais remonter une partition système avec bootloader et certainement noyau alors que celle-ci n'était pas nettoyé : refus catégorique et affichage de warning sur toutes les consoles ! Ou comment une mesure de sécurité légèrement pensé mène à du grand n'importe quoi) Ou encore que /var ou /var/db n'existe plus ? (imaginons qu'une coupure de courant fasse rebooter violement la machine, et que certains dossiers soient perdus ou fichier de création dynamique de répertoires corrompu)

Eh bien tout simplement, la fonction échoue, et on se retrouve, alors que login et getty peuvent se lancer tout à fait correctement, avec le prompt "Enter pathname of shell or RETURN for sh: ", ce qui en appuyant sur Entrée donne directement sur un shell root, sans passer par l'étape habituelle de la demande de mot de passe.

"Ah bein bravo", comme on dit...

(en l'occurrence, cette enquête a été mené parce que /var était par erreur un répertoire sur un file system / RO par mesure de sécurité, au lieu d'être un lien vers /tmp/var, lui-même monté en RAMdisk, ou "mfs" sous bsd -- d'ailleurs le "mount_mfs" reste un processus lancé, c'est-à-dire en toute rigueur une gestion en userland via allez-retour kernel/processus pour de la mémoire que l'on veut la plus rapide possible -- contrairement à un FUSE linux qui de toute façon a toujours été un gros hack, bien inférieur à ce que ferait un hurd --, et en plus non déboulonnable ensuite, du moins un kill -9 n'y fait rien... Magnifique design, pour la peine)

mercredi 19 mars 2008

on n'arrête pas le progrès/c'est plus ce que c'était

Oh oui, je suis un blogueur ultra-influent qui reçoit souvent une fois par an des suppliques d'acteurs commerciaux en manque de visibilité. Avec mailing automatique, mais on fait ce qu'on peut...

Link Request (Contact humani nil a me alienum puto)

Courtney Sullivan to Palpatine

Dear webmaster,

My name is Courtney Sullivan, and I am contacting you regarding your Geekeries section located at http://palpatine42.free.fr/blog/

I'm working in association with Geek.com; I have been tasked with promoting their new Gadgets section, which can be found at http://www.geek.com/gadgets/.  It's a comprehensive resource center featuring information and reviews on the most recent technology trends and gadgets.

If you think your readers would also be interested in the Gadgets section on Geek.com, I would love to know if you could link to it from Palpatine.


I can be reached via email at courtneysullivan98@gmail.com , or, if you'd like to talk about this by phone, my direct number is 646 442 0832.

Best regards,

Courtney Sullivan

Bon, je vais voir chez eux... Et là, c'est le drame. Non seulement il n'y a pas grand' chose, mais en plus, on y vend du iPhone. Beaaaarrrkkkkk. C'est pas un truc de geek, ça, coco, juste un truc de djeunz qui veulent se la péter (oups, il a quel âge mon chef ?) ou de vieux plein de sous (coucou ! :D ). Mais pas un truc de geek, y'a une vieille merde de MacOS dedans, rien que de savoir que ça vient de BSD ça me fait mal, et en plus recuisiné par derrière, je crois que je vais vomir. Avec des DRMs dans tous les sens. Non non non non !!

Un vrai truc de geek, coco (ah, non, cocotte ! Courtney, z'avait pas vu ; enfin, une chance sur deux que ce soit un homme quand même), c'est thinkgeek, avec une vraie section gadget, où l'on peut trouver un tas de trucs qui laissent rêveur, comme ce microscope digital usb (déjà que j'ai dû utiliser mon chauffe-tasse hub usb que deux fois...)  (mais là, je trouverais une application imméditate : <private joke> inspection d'alignement dentaire </private joke>) (200$... à 1,5$ l'€)  (merde, il m'en faut un absolument !! :p ).

Y'en a marre de ces gens qui dévoient la cause Geek, non mais !

- page 2 de 20 -