GNU/Linux >> Linux Esercitazione >  >> Linux

RedHat e SUSE hanno annunciato di ritirare il supporto per OpenLDAP

Questo mese il progetto OpenLDAP festeggia il suo ventesimo compleanno! Il suo anno di nascita è il 1998 quando Kurt Zeilenga e altri hanno deciso di consolidare le patch che erano state diffuse su mailing list e gruppi di notizie per migliorare il codice server LDAP autonomo dell'Università del Michigan (slapd). Dopo le dimissioni di Kurt Zeilenga, Howard Chu ha assunto il ruolo di capo architetto del progetto. Il progetto OpenLDAP segue tradizionalmente la filosofia di progettazione Unix "un lavoro – uno strumento". Sotto la guida di Kurt Zeilenga, lo sviluppo di OpenLDAP come implementazione di riferimento del "Lightweight Directory Access Protocol" (LDAP) è stato guidato principalmente da Internet Draft e RFC. Questa attenzione all'apertura e all'interoperabilità ha trasformato il progetto in un importante punto di riferimento nel panorama dei servizi di rete, essendo supportato da tutte le principali distribuzioni Linux aziendali che offrivano OpenLDAP come componente mantenuto dei loro prodotti.

RedHat e SUSE hanno annunciato di ritirare il supporto per OpenLDAP

Sfortunatamente questo cambierà quest'anno da quando RedHat e SUSE hanno annunciato di ritirare il supporto per OpenLDAP nelle loro offerte Enterprise Linux a favore del 389 Directory Server di RedHat (389-ds). Questa notizia è stata comunicata ai clienti nelle note di rilascio di SLE 15. Il 389 Directory Server il progetto si basa su una base di codice che risale al 1996, quando Netscape ingaggiò il fondatore di LDAP, Tim Howes, e alcuni dei suoi ex colleghi dell'Università del Michigan. Questa base di codice è stata acquisita nel 2004 da RedHat e rilasciata ed estesa come Open Source sotto Gnu Public License (GPL).

OpenLDAP 1.0 stesso è nato nel 1998 da miglioramenti, che la comunità aveva raccolto nel corso di due anni. Il codice di oggi è stato così migliorato con la seconda major release che non ha quasi nulla in comune con il codice originale.

Il codice sorgente con licenza GPL di 389 Directory Server è la base tecnologica di due offerte separate. RedHat distingue tra la soluzione di gestione dell'identità (IdM) FreeIPA (Identity, Policy, Audit) da un lato e il "Red Hat Directory Server" (RHDS) dall'altro. Quest'ultimo è consigliato per applicazioni business critical generali con requisiti speciali. Fare riferimento ai seguenti collegamenti per maggiori dettagli.

  • https://rhelblog.redhat.com/2015/06/01/identity-management-or-red-hat-directory-server-which-one-should-i-use/
  • https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/index#comparing

Tuttavia, per il funzionamento del prodotto RHDS è necessario un abbonamento di supporto separato. La decisione di RedHat di concentrarsi esclusivamente su 389-ds va vista in questo contesto. Secondo questo annuncio, OpenLDAP non sarà più supportato nella prossima major release di RedHat Enterprise Linux e il pacchetto software "openldap-servers" è già deprecato in RHEL 7.4 (vedi il paragrafo "Importante" in quell'annuncio).

Con questa mossa, i clienti RedHat che utilizzano OpenLDAP si trovano in una situazione in cui devono migrare a 389-ds (o RHDS) o ricorrere a pacchetti OpenLDAP di offerte di terze parti per il supporto (ad es. https://symas.com/message -presidente-regarding-red-hat-suse-removing-openldap-linux-distributions/ e https://daasi.de/en/2017/09/25/red-hat-wont-continue-openldap-support-rhel- 8-daasi-internazionali-supporti-migrazione/). I pacchetti gestiti dalla community continueranno a essere disponibili.

L'invenzione ha una prospettiva diversa

Dal 2003 Univention supporta OpenLDAP per uso aziendale. È uno dei componenti centrali del loro prodotto Univention Corporate Server (UCS). Questo è possibile, perché OpenLDAP è sempre stato mantenuto con un alto grado di professionalità. L'intera comunità risponde in modo rapido e professionale alle domande e alle proposte di patch presentate. Il team di OpenLDAP spedisce le versioni delle funzionalità in un ritmo di circa 12-18 mesi, intervallate da versioni di manutenzione come richiesto. Le versioni delle funzionalità maturano a lungo e non sono vincolate alla pressione delle scadenze di rilascio. A questo punto i progetti funzionano in modo simile ad altri progetti open source come Debian. Questo non è sempre facile da gestire per i distributori in termini di pianificazione del rilascio del prodotto, ma è la libertà di tali progetti di decidere nella propria misura quando qualcosa è considerato pronto per il rilascio.

Tutti questi sono i motivi per cui Univention consiglia UCS con OpenLDAP anche per i propri utenti aziendali. Nella più grande distribuzione UCS gestita dal provider di telecomunicazioni francese Orange, OpenLDAP offre servizi fino a 30 milioni di account di autenticazione e ha dimostrato la massima scalabilità e stabilità.

Affidabilità, prestazioni e scalabilità della tecnologia di base sono un criterio cruciale per operare in ambito professionale. Da questo punto di vista, così sostiene Unvention, la decisione di RedHat e SUSE è difficile da giustificare. 389-ds attualmente si basa ancora su un back-end Sleepycat Berkeley DB mentre OpenLDAP dalla 2.4 raccomanda il moderno LMDB (Lightning Memory Database) come back-end. Il database No-SQL/Key-Value LMDB è stato inventato e sviluppato da Howard Chu, che è stato il capo architetto del progetto OpenLDAP dal 2007. Il nuovo database backend presenta in particolare un funzionamento senza blocco, imparando da problemi di vecchia data di Berkeley DB (BDB ). Raggiunge un aumento delle prestazioni senza precedenti rispetto ad altre tecnologie di database, in particolare per quanto riguarda il profilo di utilizzo dei servizi di directory LDAP, che spesso si concentrano piuttosto sulle operazioni di lettura che di scrittura.

Dal 2014 Univention è passata anche a LMDB come backend OpenLDAP nel loro prodotto principale Univention Corporate Server (UCS). Secondo l'esperienza di Univention, LMDB ha aperto le porte a OpenLDAP per soddisfare i requisiti di progetti di scala ad alte prestazioni. In effetti, la robustezza e le prestazioni di LMDB sono così notevoli che Univention ha deciso di sostituire la propria cache di replica LDAP basata su BDB con un'implementazione basata su LMDB nel 2014. Anche se l'attuale ramo della versione 0.9 di LMDB ha già dimostrato una stabilità convincente, la serie 1.0 fornirà ulteriori miglioramenti che saranno cruciali come solido back-end per OpenLDAP.

La prossima grande pietra miliare per il progetto OpenLDAP stesso sarà il rilascio di OpenLDAP 2.5. Alcune delle funzionalità annunciate per OpenLDAP 2.5 hanno già visto la luce del giorno come aggiornamento a livello di patch per la serie 2.4, che sarà finalizzata entro la 2.4.47 secondo la roadmap attuale.

Un grande ringraziamento a OpenLDAP

Unevention ringrazia il progetto OpenLDAP ei suoi sviluppatori per il lavoro professionale e l'impegno nell'idea di open source. In qualità di distributore Linux, Univention non vede l'ora con entusiasmo e fiducia di continuare a utilizzare OpenLDAP nei progetti basati su UCS nei prossimi anni, offrendo a società e istituzioni pubbliche e private una soluzione software aperta, scalabile e professionale e allo stesso tempo autorizzando la libertà di scelta e l'indipendenza di vincoli del fornitore.

Questo è un post degli ospiti di Univention . Le opinioni dell'autore sono interamente sue e potrebbero non riflettere le opinioni di OSTechNix.


Linux
  1. Come utilizzo Ansible e anacron per l'automazione

  2. Cheat sheet per utenti e autorizzazioni Linux

  3. Bash For Loop Guida ed esempi

  4. Caffè:un'app di notizie e meteo per Linux

  5. Medleytext - Un'app per prendere appunti intuitiva ed elegante per i programmatori

Le 10 migliori distribuzioni Linux per laptop e desktop

Guida all'installazione e all'uso del firewall CSF

Come eseguire il backup e il ripristino della scheda SD per Raspberry Pi

Configurazioni di indirizzi IP statici e dinamici per DHCP

Supporto per Tmux, Term e 256 colori?

Interfaccia a nastro per GTK e Qt