Distribuzione FUSS » fuss-manager

Segnalo da #742 che oltre alle utenze ldap, nelle scuole è anche in uso un utente root con la master password del fuss-server (in /etc/fuss-server/fuss-server.yaml, se presente)

Ho aggiunto la lettura dei gruppi dell'utente. Per un login, e per avere informazioni su un utente, ci sono da fare 3 query LDAP: dati utente, nome gruppo primario, elenco nomi e gid gruppi secondari.

Probabilmente è possibile togliere ldap_bind_dn_template e aggiugnere sempre uid=$UID a ldap_user_search_base. Chiedo feedback a Simone.

Ho improvvisato una struttura User in ldap.py, che sarà poi da tirar fuori da ldap.py e mettere in un qualcosa di piú generico in fuss-manager. Accetto suggerimenti sul suo layout.

La configurazione di esempio per LDAP ora è:

    'ldap_uri': "ldap://server:port",
    'ldap_bind_dn_template': 'uid={uid},ou=People,dc=fuss,dc=example,dc=it',
    'ldap_user_search_base': 'ou=People,dc=fuss,dc=example,dc=it',
    'ldap_group_search_base': 'ou=Group,dc=fuss,dc=example,dc=it',

Allora ldap_bind_dn_template secondo me è inutile, per ogni utente il DN sarà sempre nella forma uid=username,{{ldap_user_search_base}}.

Inoltre sul fuss-server l'albero ha sempre la seguente struttura (creata dal playbook) sulla base del dominio specificato in fase di lancio (ex. fuss.lan) ed in genere si contatta sempre su localhost, per cui l'elenco sopra lo esprimerei come (in yaml):

ldap_uri: "ldap://localhost:port" 
ldap_base: dc=fuss,dc=lan
ldap_user_search_base: ou=Users,{{ldap_base}}
ldap_group_search_base: ou=Groups,{{ldap_base}}

ci son pure dei rami ou=Computers e ou=Idmap ad uso di Samba, che si possono ignorare, visto che non mi risulta usino più il fuss-server come PDC.

Ho tolto ldap_bind_dn_template e uso invece ldap_user_search_base.

Ho implementato un'astrazione per User, Group, e database utenti e gruppi.

Ho implementato l'autenticazione per LDAP e per db utenti unix locale. Possiamo usare il db utenti unix locale come fallback se ldap non è configurato. Per autenticare utenti però serve essere root.

A questo punto ti passo il ticket per review, e per eventualmente:

• vedere come impostare la configurazione di default
• documentare le chiavi di configurazione LDAP

Per la gestione della master password si può fare un MasterPasswordMixin per i vari user database, che controlla la master password prima di fare super().authenticate(...)

Ho aggiunto anche un user database mock, e l'autodetect del database da usare con lo stesso meccanismo is_viable usato per le machine data source

Fatto il merge in master, mi tengo il ticket per quanto nei commenti 13 e successivi

Aggiunto un nuovo backend per la master password (al posto di un mixin, sembrava più coerente col resto).

È sul branch t853, mi tengo il ticket per il resto.

il branch mergiabile era t856 (typo, sorry)

Fatto merge in master, grazie!