Lago Maggiore International Trail 2018

Il 6 maggio ho corso la 50km del lago maggiore international trail. Si preanunciava una gara molto difficile a causa del cancelli orari piuttosto ristretti, e difatti all’ultimo cancello sono arrivato un po’ in ritardo e sono quindi stato escluso dalla graduatoria. C’è da dire che su 272 partiti, ne sono arrivati in tempo solo 195, mentre gli altri 77 hanno visto il loro pettorale ritirato. Io ho impiegato mezz’ora in più del tempo massimo, e ho distrutto le scarpe…

La corsa è comunque stata molto bella: le parti in quota sono veramente bellissime, ma durante la salita dopo il trentesimo chilometro, quella che porta al secondo cancello, me la sono vista proprio brutta, per la stanchezza e per il percorso per me devastante.

La giornata era prevista con cielo coperto, ma invece c’è stato sempre un gran bel sole, a volta fin troppo forte. Dopo l’arrivo è invece scoppiato un termporale micidiale, con grandinate impietose che hanno lasciato il ghiaccio sul terreno per tutta la notte. Siamo stati fortunati che il temporale è arrivato tardi.

L’organizzazione non è stata il massimo: a parte i tempi stretti ai cancelli, non è stata mantenuta aperta la cucina per fare mangiare che arriva parecchio dopo il termine ultimo. Immaginate uno che ha corso 12 ore, arriva allo scoppio del temporale, e gli dicono che la cucina ha pure chiuso. Altra macchina dell’organizzazione: i pettorali di chi arrivava tardi ai cancelli sono stati trattenuti, ma si tratta di un souvenir che agli atleti piace tenere, e a mio parere andavano annullati, ma non trattenuti. Non si priva del pettorale uno che ha dato il meglio di sè.

Creare un nuova directory in LDAP con la nuova configurazione in /etc/ldap/slapd.d

Quando si installa il pacchetto slapd, si configura una directory, generalmente chiamata dc=nodomain. Da quel punto in poi, tutta la modifica alla configurazione può essere fatta con un client LDAP, oppure si può operare direttamente con i file. Vediamo questa seconda via.

La prima cosa da considerare è che una directory LDAP viene memorizzata in una directory del file system tramite vari file che contengono dati e indici. Il sistema più vecchio di memorizzazione è quello chiamato bdb (Oracle Berkeley DB), ma ne esistono anche altri quali hdb (hierarchical Berkeley DB), mdb (Memory-Mapped DB) e sql. Ce ne sono anche altri, ma non sono generici. Scartiamo l’ultimo della lista, sql, poiché si tratta di uno strumento che permette solo di leggere dati, senza poterli modificare. Scartiamo anche il primo e il secondo, bdb e hdb, che sono ormai vetusti e addirittura sconsigliati per l’uso. Ci rimane sostanzialmente mdb. Continua a leggere Creare un nuova directory in LDAP con la nuova configurazione in /etc/ldap/slapd.d

SQL Server e la gestione automatica della memoria

Ogni istanza di SQL Server ha due parametri che indicano la quantità minima e massima di memoria RAM da utilizzare. Se questi valori sono diversi, SQL Server allocherà il minimo all’attivazione dell’istanza, e allocherà altra memoria secondo le necessità, arrivando eventualmente a raggiungere la soglia massima, ma senza superarla. Inoltre, l’istanza di SQL Server comunica al sistema operativo che, all’occorrenza, può liberare spazio, cosicché quando il sistema non riesce a dare memoria ad altre applicazioni, chiede a SQL Server di liberarne un po’. In questo caso la quantità di memoria usata cala, rimanendo sempre sopra la soglia minima impostata.

Fin qui tutto bene. Continua a leggere SQL Server e la gestione automatica della memoria

Copenhagen: non è un paese per vecchi

(Articolo perennemente incompleto, che aggiorno di quando in quando.)

A Touch Of VintageSono stato a Copenaghen nel giugno 2017. La città è bella e ho avuto anche la fortuna di vederla in alcuni giorni di sole. La cosa che più mi ha colpito, al di là delle attrazioni turistiche, è la quantità di persone giovani che lavorano: non solo come camerieri, ma anche come bigliettai, come capitani delle imbarcazioni turistiche, negli hotel, alla guida degli autobus, all’aeroporto, giusto per elencarne alcuni.
Ho visto un matrimonio, di sfuggita, e gli sposi, come gli invitati, non raggiungevano i venticinque anni. Ho visto giovani coppie con passeggino, che in Italia sarebbero ancora all’università. Ho incontrato per strada, ma forse erano stranieri, poche persone sulla cinquantina, e solo uno sopra i settanta, in autobus.

La gente si muove molto in bici, spesso con delle bici che hanno un enorme cesto davanti per portare bimbi o merci. Ne ho viste con due bimbi davanti, e un terzo sul seggiolino posteriore. A volte con la pedalata assistita, altre volte no. A parte le bici col cesto, quasi tutte le altre hanno il solo freno anteriore, difatti sul manubrio c’è solo la leva di sinistra. A proposito delle bici danesi: ce ne sono veramente tante, ma se ne vedono raramente di eccezionali: sono più bici «da combattimento», nel senso che vanno usate e non semplicemente mostrate; e questo le differenzia molto da quelle italiane, dove più spesso la ricerca dell’accessorio particolare le rende anche (o principalmente) bici da guardare. Infine, i lucchetti sono spesso utilizzati per bloccare la ruota, ma non per fissare la bici al palo o al porta bici. È come se in Danimarca il lucchetto sia più on accessorio che qualcosa di veramente necessario.

L’architettura di Copenhagen è interessante, ma è moderna: non ci sono costruzioni interessanti di centianaia di anni, a parte la chiesa di Frederiks (Frederiks Kirke) che ne ha 300 e la cittadella fortificata (Kastellet) che ne ha 350. Ma ci sono parecchi progetti recenti che meritano almeno uno sguardo, come ad esempio il ponte ciclabile e pedonale Inderhavnsbroen che si apre scorrendo verso l’esterno del fiume, in orizzonale. Oppure tutto il grande complesso universitario (a partire da Søndre Campus) che prende gran parte della parte sud della città.

Per mangiare bene si deve spendere qualche soldo, inoltre se si sceglie un ristorante in base alle guide più o meno blasonate, è spesso necessario prenotare alcuni giorni prima. Nel mio caso, di una visita breve, non ho potuto farlo, ma ho comunque mangiato bene in ristoranti che le guide davano come seconda scelta.

Operare manualmente sulla mappatura UID/SID di winbind nel formato tdb2

Per collegare una macchina unix o Linux ad una Windows per l’autenticazione, si può utilizzare il winbind, cioè quella parte di samba che permette di autenticare gli utenti tramite le loro credenziali di dominio. Una volta che l’utente è autenticato, viene creato una utenza corrispettiva a quella Windows anche su Unix. La nuova utenza avrà un proprio UID e un GID generati al volo da winbind, ma quando l’utente tornerà una seconda volta a fare l’accesso a Unix, sarà meglio che trovi gli stessi UID e GID, così da avere gli stessi diritti che aveva al primo accesso. Per far sì che UID e GID siano mantenuti, questi vengono memorizzati da qualche parte e associati al SID (cioè all’UID per Windows).

Nel caso che si debbano avere più macchine unix collegate allo stesso dominio Windows, è il caso di memorizzare queste informazioni in un luogo accessibile a tutte le macchine, come ad esempio il dominio Windows stesso (utilizzando l’estensione SFU), oppure in un LDAP, oppure in alcuni file che possono essere periodicamente copiati dalla macchina unix principale alle secondarie. Invece, se la macchina unix è una sola, allora si possono semplicemente utilizzare dei file sul server unix stesso.

Per dire a winbind quale percorso seguire, vanno impostati i «backend» della mappatura degli identificatori, detta idmap. Nel mio caso ho utilizzato il backend tdb2, cioè la nuova versione del tdb («Trivial DataBase», che in italiano significa «base dati elementare»). Nel file di configurazione di samba, ho scritto:

idmap config *:backend = tdb2
idmap config *:range = 4000-4100

Che vuol dire: per le utenze di qualsiasi dominio Windows, memorizza le associazioni SID/UID e SID/GID tramite il backend tdb2. Inoltre crea gli UID e GID nell’intervallo da 4000 a 4100,  in modo da essere sicuro che non si sovrappongano a UID e GID già presenti sul sistema unix locale. (Nota: l’intervallo per UID e GID locali è definito in /etc/login.defs.)

Per tutti quelli che usano Debian GNU/Linux (state già usando tutti Debian, vero?), tdb2 andrà a creare il suo database nella directory /var/lib/samba e lo chiamerà idmap2.tdb.

Questo database è — appunto — elementare: cioè è capace di inserire solo dati nella forma chiave/valore. Per vedere quali chiavi sono memorizzate, si può usare il comando tdbtool in questo modo:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb keys
key 9 bytes: GID 4037
key 43 bytes: S-1-5-21-1142429371-1648316-403635728-1131
key 9 bytes: GID 4024
key 9 bytes: UID 4043
key 43 bytes: S-1-5-21-1142429371-1648316-403635728-1136
[...]

come si vede, le chiavi sono a volte un UID a volte un GID, a volte un SID. Non è scritto nella documentazione online, ma l’informazione su quanto sia lunga la chiave è di grande aiuto: la chiave “UID 4043” è lunga 9 byte, ma sono solo 8 caratteri, quindi c’è qualcos’altro. Idem per le altre chiavi.

Per sapere a cosa è associata una certa chiave potremmo usare lo stesso comando, con argomenti diversi. Proviamo:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb show 'GID 4037'
fetch failed

L’errore è criptico, ma ricordando il messaggio precedente sulla lunghezza della chiave, e con un po’ di fantasia (o leggendo il codice sorgente), si può trovare il comando corretto, con l’aggiunta di un byte 0 alla fine della chiave:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb show 'GID 4037\0'

key 9 bytes
GID 4037
data 43 bytes
[000] 53 2D 31 2D 35 2D 32 31  2D 31 31 34 32 34 32 39  S-1-5-21 -1142429
[010] 33 37 31 2D 31 36 34 38  33 31 36 2D 34 30 33 36  371-1648 316-4036
[020] 33 35 37 32 38 2D 31 31  38 35 00                 35728-11 85

bene, adesso non ci sono errori: alla chiave GID 4043 è associato il SID S-1-5-21-1142429371-1648316-403635728-1185, e viceversa:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb show \
'S-1-5-21-1142429371-1648316-403635728-1185\0'

key 43 bytes
S-1-5-21-1142429371-1648316-403635728-1185
data 9 bytes
[000] 47 49 44 20 34 30 33 37  00                       GID 4037

Lo stesso comando permette anche di cancellare un’associazione, ma questa operazione — ora che abbiamo capito che winbind scrive due record per ogni associazione — va fatta per entrambe le chiavi. Il comando in questo caso non fornisce nessun messaggio riguardo l’esito, nel miglior stile unix:

root@miura:~# tdbtool /var/lib/samba/idmap2.tdb delete \
'S-1-5-21-1142429371-1648316-403635728-1185\0'
root@miura:~# tdbtool /var/lib/samba/idmap2.tdb delete 'GID 4037\0'

Chiudo così questo breve excursus sul trivial database, che nel mio caso è il frutto dello studio dovuto ad un problema, su un server, che presentava due utenti con lo stesso UID. Erano difatti due diverse associazioni memorizzate nel tdb di winbind: una era riferita ad una utenza effettivamente presente sul dominio, mentre l’altra era una associazione rimasta memorizzata nonostante l’utenza sul dominio fosse stata cancellata. Ah, già, dimenticavo: winbind non cancella mai le associazioni locali SID/UID.