Debian e i GID a muzzo
Cosa succede quando uno si trova a dover amministrare un po’ di macchine server e client di OS diversi? Che ad un certo punto lo sbattimento di gestire e replicare utenze su enne servizi a destra e a manca diventa troppo e si cerca una soluzione centralizzata. La scelta cade, per motivi di possibilità di ridondanza nella nostra architettura, su OpenLDAP, con cui per questa ragione il sottoscritto sta lottando da tempo.
Di per sé non è neanche una brutta cosa, che esista un server di directory libero, peccato che i principali sviluppatori sembra si sentano parte di un’elite estremamente esclusiva, secondo la cui etichetta i non iniziati non hanno il diritto di capire perché la baracca non funziona. E quindi via, un errore più incomprensibile dell’altro, ognuno condito da linguaggio accademico e infarcito di buzzword. Va da sé che i “non iniziati” hanno, dall’altro lato, scritto centinaia di guide che dovrebbero aiutare chi, come loro, comincia ad affrontare l’argomento. E va da sé che non esistono due guide completamente d’accordo su ogni punto. Ma anche a questo il sysadmin più cocciuto può resistere, e se infinite prove fallite e chili di documentazione non lo spaventano, può arrivare a grokkare, fino ad un certo punto, la configurazione di OpenLDAP. Quel tanto che basta per fargli fare quello per cui è stato inventato.
Ed è qui che arriva Debian. Il sistema operativo danno universale. Ma andiamo con ordine. Mi viene messa in mano una mezza installazione di OpenLDAP qualche mese fa perché prenda confidenza con questo strumento del demonio nei tempi morti al lavoro, e capisco subito che non sarà impresa facile. La macchina è uno dei nostri server Sarge, regolarmente aggiornato. Configuro dunque il db, il server, il client, baracca e burattini, importo a fatica i dati del sistema, dopo un po’ di smadonnamenti riesco anche a querarlo con ldapsearch. Sembra funzionare, fico. Peccato che le modifiche fatte al db non siano viste dal sistema, e nonostante il demone nscd sia avviato, funzionante e configurato per parlare con ldap, getent continua a ritornare i vecchi risultati per passwd e compagnia cantante.
Dopo qualche giorno di questo andazzo, facendosi più pressante la richiesta per il server, decido di dare una scossa allo sviluppo della cosa e riparto da zero, forte dell’esperienza accumulata, su una Lenny dedicata. Magia, tutto funziona senza troppa fatica e getent ritorna allegramente le informazioni del db. Ormai considero gran parte del lavoro come concluso. Fast forward di qualche settimana in cui ho avuto altro da fare, decido di portare la configurazione sulla macchina Sarge e… non funziona più nulla! Com’è?
Decido, dopo varie litigate con nscd, che c’è qualche problema su Sarge, ed inizio a considerare ldap rotto a livello di distro. Niente di tragico, significa semplicemente che il server andrà a finire su una macchina Lenny, le Sarge saranno solo client. E qui casca l’asino. Esporto in un file ldif /etc/group del server Sarge, lo trasloco sulla Lenny e faccio un rapido check prima di importarlo. Resto allibito: i GID sono diversi tra le due macchine! Ovviamente non parlo dei GID utente, ma di quelli creati per i demoni di sistema “extra”, che vengono assegnati tra il 100 e il 1000.
Perché ogni servizio non ha il suo GID fisso? Come diamine faccio a mettere su un server LDAP che gestisca anche i gruppi per un tot di macchine senza trovarmi i GID sminchiati? Devo forse fermare una macchina di produzione per dare chown ricorsivi a manetta su tutta la root ed uniformare i server? Come accidenti si fa ad integrare macchine Debian preesistenti in una directory LDAP evitando problemi del genere?
Deve esserci una spiegazione, non possono essere così stupidi in debian… deve esserci un modo! Si accettano consigli 
Posted by bardo under acido, g33k1ng around, wtf? | Comments (5)