cvs co ya7ans

Tags: , ,
No Comments »

fouyou, ce voyage dans le passé…

Il y a 7 ans, je commettais ceci. EasyLDAP était une librairie qui permettait d’implémenter une interaction LDAP en C assez simplement. Mais son but final était plus concret; en effet, en 2001, FreeBSD ne possédait pas de port nss_ldap, son architecture nss était quelque peu aride, et l’un de mes projets dans mon job de l’époque, c’était de trouver le moyen de centraliser l’authentification de nos serveurs FreeBSD, et de préférence, via LDAP.
La sale magouille que j’avais trouvé à l’époque, c’était d’utiliser la variable LD_PRELOAD et de préloader, donc, la librairie eldap dans laquelle j’avais redéfini les fonctions getpwnam, getpwuid, getgrnam etc etc…
Et ça marchait ! :)

Aujourd’hui, FreeBSD et NetBSD sont tous deux capables de loader des plugins nss_ldap et pam_ldap, c’est tout beau tout propre, et il n’y a plus besoin de bidouiller de trucs infames pour centraliser ses utilisateurs.
Sauf sous OpenBSD.
Et c’est la que les vapeurs du passé ressurgissent; deux des domU de zone0 sont des OpenBSD, l’un d’eux plus particulièrement, est destiné à heberger moult shells des membres contributeurs du groupe. jusqu’à présent, nous avions jeté notre dévolu sur cette methode, qui présente le désavantage de devoir tout de même ajouter l’utilisateur au fichier /etc/passwd. Et puis de fil en aiguille, je me rappelle de mon “fameux” EasyLDAP.
D’abord à tatons, je regarde mon code de loin, je fixe les autotrucs permettant sa compilation, et apres quelques ajustements, ce dernier compile. J’ecris sans trop y croire ce bout de code de verification :

#include <stdio.h>

#include <sys/types.h>
#include <pwd.h>

int
main(int argc, char *argv[])
{
        if (getpwnam(argv[1]) != NULL)
                printf("%s exists\\n", argv[1]);
        else
                printf("%s does NOT exists\\n", argv[1]);

        return 0;
}

Je compile puis quelques SEGFAULT / corrections plus loin, je tente ma chance :

[~/src/eldap] LD_PRELOAD=.libs/libeldap.so.1.1 ./testpw pinpin
pinpin exists

Je n’en crois pas mes yeux, ça fonctionne toujours !
Quelques ajustements plus tard, j’arrivais à me connecter via OpenSSH-lpk (clé publique dans une db LDAP, donc) avec un utilisateur absent du fichier /etc/passwd.

J’ai donc entrepris de faire subir à ce vieux code mal indenté, peu sur et emprunt de vapeurs de gin, un bon gros lifting. Le site est de nouveau en ligne, le CVS ne nouveau accessible, et j’ai revampé un peu le codebase. Il est à peu près certain que ce travail n’aura d’interet que le temps qu’OpenBSD n’integre une vraie abstraction dans la libc, mais il est toujours agréable de jouer avec ces notions. Si le cœur vous en dit, vous savez ou me trouver.

64 / 2

Tags: , , ,
1 Comment »

Décidemment, le “choix” de l’OS d’un domU n’est pas si large qu’il n’y parait…
Nous avions statué l’archi suivante pour zone0 :

. dom0: debian stable amd64 + Xen 3.1
. domU services: OpenBSD 4.1 amd64
. domU shells: OpenBSD 4.1 amd64
. domU www1: NetBSD 3.1 x86
. domU www2: NetBSD 3.1 x86

Le choix de NetBSD x86 avait été dicté par le fait que l’installation même de la version 64 bits s’avérait impossible, cette dernière ne trouvant jamais le media cd0.

Du fait de l’architecture de services un peu particulière que nous avions à l’esprit, nous avons du compiler certains ports OpenBSD… et là, mauvaise surprise, un bête ./configure faisait loader la machine à 3 et prenait en moyenne un quart d’heure, à raison de 3 secondes par ligne ! Après quelques recherches, nous trouvons quelques threads sur des problèmes similaires, mais toutes les pistes évoquées -même un vilain patch du cpu.c du noyau- ne donnent aucun résultat.

Hier soir, nous nous sommes donc rabattus sur la version x86 d’OpenBSD, et comme on pouvait s’y attendre: plus de soucis. Les deux domUs carburent, les ./configure et autres compilations sont rapides, et les machines virtuelles semblent stables, mêmes soumises à quelques stress tests de forking et de memoire.

Il semble que le problème concerne l’utilisation de fork() -qu’un ./configure utilise evidemment massivement-.

L’archi finale est donc :

. dom0: debian stable amd64 + Xen 3.1
. domU services: OpenBSD 4.1 x86
. domU shells: OpenBSD 4.1 x86
. domU www1: NetBSD 3.1 x86
. domU www2: NetBSD 3.1 x86

Une dernière astuce, pour une raison que j’ignore, une de plus, le boot cd cd41.iso fait paniquer le domU dès le chargement du noyau, aussi, pour installer OpenBSD 4.1, j’ai utilisé l’image cdemu qui n’a posé aucune complication.

Rackage imminent.

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in