"Posta elettronica": persi 6 Atenei in ~3 anni...
Come alcuni ricorderanno, poco meno di tre anni fa --esattamente il 14/02/2021-- fotografai lo stato delle infrastrutture di Posta Elettronica in uso nei vari Atenei del nostro Paese. Il quadro che ne emerse non era particolarmente confortante: * Google: 31 * Microsoft: 16 * Interna all’Ateneo: 19 Oggi (27/12/2023), approfittando di un po' di tempo libero, ho "aggiornato" la fotografica, prendendo in esame *ESATTAMENTE* gli stessi 66 domini di posta analizzati a suo tempo. La situazione aggiornata è la seguente: * Google: 33 * Microsoft: 20 * Interna all’Ateneo: 13 In poco meno di tre anni, abbiamo "perso" 6 atenei/istituzioni: * sissa.it * unica.it * unipa.it * unirc.it * unisannio.it * uniss.it L'articolo integrale --aggiornato con questi ultimi valori-- è disponibile on-line: https://dvblog.soabit.com/la-posta-elettronica-negli-atenei-italiani/ Bye, DV -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
Vedo che UNICH resiste al trend della esternalizzazione !! Paolo Del Romano
unimi è passata a Microsoft pochi giorni fa, purtroppo On 27/12/2023 13:41, Damiano Verzulli wrote:
Come alcuni ricorderanno, poco meno di tre anni fa --esattamente il 14/02/2021-- fotografai lo stato delle infrastrutture di Posta Elettronica in uso nei vari Atenei del nostro Paese.
Il quadro che ne emerse non era particolarmente confortante:
* Google: 31 * Microsoft: 16 * Interna all’Ateneo: 19
Oggi (27/12/2023), approfittando di un po' di tempo libero, ho "aggiornato" la fotografica, prendendo in esame *ESATTAMENTE* gli stessi 66 domini di posta analizzati a suo tempo.
La situazione aggiornata è la seguente:
* Google: 33 * Microsoft: 20 * Interna all’Ateneo: 13
In poco meno di tre anni, abbiamo "perso" 6 atenei/istituzioni:
* sissa.it * unica.it * unipa.it * unirc.it * unisannio.it * uniss.it
L'articolo integrale --aggiornato con questi ultimi valori-- è disponibile on-line:
https://dvblog.soabit.com/la-posta-elettronica-negli-atenei-italiani/
Bye, DV
-- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa> -- Andrea Trentini ⠠⠵ http://atrent.it public key ID: 0xA7A91E3B Dip.to di Informatica Università degli Studi di Milano
BTW ho visto ora che l'MX punta ancora a unimi, ma sono certo che sia migrata, boh -- Andrea Trentini ⠠⠵ http://atrent.it public key ID: 0xA7A91E3B Dip.to di Informatica Università degli Studi di Milano
Non è solo la posta a migrare! Google e Microsoft forniscono sistema di gestione identità e permessi, e un botto di applicazioni integrate con questo. Le applicazioni sono sia per utenti finali (posta e contatti, calendario e gestione file, tutto sincronizzato desktop/mobile, multipiattaforma) che per amministratori (antispam, logging, security policy, etc.) Hai voglia a dire "si può fare tutto interno, mio cugino usa nextcloud, Collabora, LDAP, un cluster Ceph ecc..." Il mondo open source ha perso almeno un decennio dicendo che Gmail è la posta e "cloud è il computer di un altro" quando invece i fornitori di questi sistemi di sorveglianza aggiungevano e integravano di tutto, e nuovi utenti iniziavano a digitalizzarsi la vita usando computer tascabili aspettandosi ben altre funzioni di quelle fornite da Debian su desktop. IMO questo gap funzionale si può colmare solo ripensando ai concetti di "program" e "user" descritti nel Manifesto GNU... discorso complesso. In breve, per riconquistare il diritto alla libertà digitale bisogna andare oltre gli slogan che hanno funzionato negli anni '90. On Wed, Dec 27, 2023 at 1:41 PM Damiano Verzulli <damiano@verzulli.it> wrote:
Come alcuni ricorderanno, poco meno di tre anni fa --esattamente il 14/02/2021-- fotografai lo stato delle infrastrutture di Posta Elettronica in uso nei vari Atenei del nostro Paese.
Il quadro che ne emerse non era particolarmente confortante:
- Google: 31 - Microsoft: 16 - Interna all’Ateneo: 19
Oggi (27/12/2023), approfittando di un po' di tempo libero, ho "aggiornato" la fotografica, prendendo in esame *ESATTAMENTE* gli stessi 66 domini di posta analizzati a suo tempo.
La situazione aggiornata è la seguente:
- Google: 33 - Microsoft: 20 - Interna all’Ateneo: 13
In poco meno di tre anni, abbiamo "perso" 6 atenei/istituzioni:
- sissa.it - unica.it - unipa.it - unirc.it - unisannio.it - uniss.it
L'articolo integrale --aggiornato con questi ultimi valori-- è disponibile on-line:
https://dvblog.soabit.com/la-posta-elettronica-negli-atenei-italiani/
Bye, DV
-- Damiano Verzulli e-mail: damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Grazie Stefano. Mi offri numerosi ulteriori spunti di riflessione e... cerchero' di trattanermi, minimizzando la verbosity. Prima di ogni cosa, pero', voglio fare una precisazione: a me *NON* interessa togliere Google/AWS/Microsoft dalla faccia della terra. Ne' mi interessa che il mondo privato ne faccia largo uso. Quando scrivo su questa lista, il mio focus è *SEMPRE* quello della P.A., ed in particolare del mondo UNIV. Mi interessa --ripeto-- mi interessa, che gli Atenei tornino a fare da apripista nella riappropriazione di parte del mondo tecnologico... che gli e' stato scippato. Sono certo --ripeto-- sono *CERTO* che è "tecnicamente" possibile. Il problema è solo "politico". Fatta questa precisazione... Il 28/12/23 17:00, Stefano Maffulli ha scritto:
Non è solo la posta a migrare! Google e Microsoft forniscono sistema di gestione identità e permessi, e un botto di applicazioni integrate con questo. Le applicazioni sono sia per utenti finali (posta e contatti, calendario e gestione file, tutto sincronizzato desktop/mobile, multipiattaforma) che per amministratori (antispam, logging, security policy, etc.)
Ritengo che un 99% degli utenti "UNIV", utilizzi un 5% degli strumenti presenti nel pacchetto di BigG. E di quel 5%, ne sfrutti un 10% di feature. Lato ADMIN (...sono stato "admin" per lungo tempo), BigG ha costretto molti di loro a "cambiare approccio" alla soluzione dei problemi. In altri termini: BigG non ha offerto, agli admin, le soluzioni di cui hanno bisogno. Ha offerto i propri strumenti. E gli "admin" si sono piegati. Presuntuosamente, ritengo che sia possibile fare di meglio (molto meglio) nell'erogazione di alcuni servizi (inclusa "la posta") In altre parole: quello che dici è corretto. Ma riportato nel contesto UNIV, è un falso problema (IMO). La dimostrazione è proprio nelle migrazioni cui stiamo assistendo: perché si migra? Perché quello che c'e' non è all'altezza? Oppure perché quello che c'e' "impone" una gestione... da cui si vuole scappare? Qual'e', quindi, il problema? La posta che non va, oppure l'incapacita' di gestire persone e problemi... magari congiuntamente ad una dinamica di gestione dei costi che rende banale l'acquisto dei servizi GAFAM, e tremendamente complesso l'allestimento di una mini-squadra di tecnici capaci?
Hai voglia a dire "si può fare tutto interno, mio cugino usa nextcloud, Collabora, LDAP, un cluster Ceph ecc..." Il mondo open source ha perso almeno un decennio dicendo che Gmail è la posta e "cloud è il computer di un altro" quando invece i fornitori di questi sistemi di sorveglianza aggiungevano e integravano di tutto, e nuovi utenti iniziavano a digitalizzarsi la vita usando computer tascabili aspettandosi ben altre funzioni di quelle fornite da Debian su desktop.
Google, Microsoft e AWS hanno sempre avuto la necessita' di "innovare", per poter essere sempre piu' competitivi e allargare il proprio parco utenti, sia su scala geografica (scala "mondo"), sia su target sempre piu' ampi. Di tutti i loro servizi, pero', a me... interessa zero. A me interessa che la corrispondenza fra studenti e docenti (le e-mail), oppure fra docenti e docenti, o ancora fra docenti e ministeri, non transiti sui loro sistemi. Il resto... è un dettaglio (per il momento).
IMO questo gap funzionale si può colmare solo ripensando ai concetti di "program" e "user" descritti nel Manifesto GNU... discorso complesso. In breve, per riconquistare il diritto alla libertà digitale bisogna andare oltre gli slogan che hanno funzionato negli anni '90. Tu punti a migliorare il mondo e, quindi, ti poni obiettivi ambiziosi. Io punto a qualcosa di estremamente piu' semplice e, soprattutto, a scala estremamente piu' ridotta (UNIV). D'altronde.... se non si riesce a fare quello che io immagino, come pensiamo possa essere mai possibile ambire a fare quello che tu speri?
Io continuo a crederci (nel mio "obiettivo") e... nel mio piccolo, piano piano, continuero' a provare a dare il mio piccolo contributo :-) Un saluto, DV -- Damiano Verzulli e-mail: damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
Ciao Damiano, Il 28 Dicembre 2023 21:24:05 UTC, Damiano Verzulli <damiano@verzulli.it> ha scritto:
Mi interessa --ripeto-- mi interessa, che gli Atenei tornino a fare da apripista nella riappropriazione di parte del mondo tecnologico... che gli e' stato scippato. Sono certo --ripeto-- sono *CERTO* che è "tecnicamente" possibile. Il problema è solo "politico".
[...]
D'altronde.... se non si riesce a fare quello che io immagino, come pensiamo possa essere mai possibile ambire a fare quello che tu speri?
Ciò che io proprio non riesco a capire è che credibilità possa avere una Università che si affida a Google o Microsoft per l'email pur avendo informatica o ingegneria informatica fra i percorsi di laurea proposti. È deprimente pensare che nessuno si vergogni di tali scelte, viste le molte alternative nettamente migliori disponibili sul mercato. A volte penso che oltre alla dismissione dell'Olivetti, il Piano Marshall ci sia costato l'idea stessa di un'Università competente, che tanto ad una colonia a-democratica non serviva. Giacomo
Cari tutti, perdonatemi ma vorrei portare alla vostra attenzione le difficoltà di gestione che affrontano quotidianamente gli Atenei. Il problema non è la disponibilità di talenti e competenze ma quella delle risorse necessarie a garantire i servizi che noi come privati siamo abituati a ricevere dai nostri provider preferiti. In parole povere, occorrono soldi. E tanti. Secondo me andare a sindacare le scelte dei singoli atenei mi sembra un esercizio sterile, quando spesso si tratta di scegliere tra mettere soldi in un Servizio IT o rinnovare le aule di un Dipartimento. La questione dovrebbe essere affrontata dal punto di vista della politica industriale e della cultura tecnologica del Paese, insieme ad altri problemi come l'indipendenza sulle infrastrutture digitali. Se si è deciso di affidare ad un singolo soggetto la gestione amministrativa e finanziaria degli Atenei, e ad un solo provider la gestione della rete di ricerca, forse una analoga decisione potrebbe essere presa per i servizi mail ed IT in genere. Dopo aver fatto un bilancio tra i costi ed i benefici, anche appunto quelli di natura "strategica". Senza una decisione di questo genere il numero degli Atenei con gestioni in-house della mail si ridurrà sempre di più. Un caro saluto a tutti ed auguri per un eccellente 2024. Giorgio Il 29/12/23 17:54, Giacomo Tesio ha scritto:
Ciao Damiano,
Il 28 Dicembre 2023 21:24:05 UTC, Damiano Verzulli <damiano@verzulli.it> ha scritto:
Mi interessa --ripeto-- mi interessa, che gli Atenei tornino a fare da apripista nella riappropriazione di parte del mondo tecnologico... che gli e' stato scippato. Sono certo --ripeto-- sono *CERTO* che è "tecnicamente" possibile. Il problema è solo "politico".
[...]
D'altronde.... se non si riesce a fare quello che io immagino, come pensiamo possa essere mai possibile ambire a fare quello che tu speri? Ciò che io proprio non riesco a capire è che credibilità possa avere una Università che si affida a Google o Microsoft per l'email pur avendo informatica o ingegneria informatica fra i percorsi di laurea proposti.
È deprimente pensare che nessuno si vergogni di tali scelte, viste le molte alternative nettamente migliori disponibili sul mercato.
A volte penso che oltre alla dismissione dell'Olivetti, il Piano Marshall ci sia costato l'idea stessa di un'Università competente, che tanto ad una colonia a-democratica non serviva.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- ======================================================================== Prof. Ing. Giorgio Ventre Scientific Director, Apple Developer Academy Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione Università degli Studi di Napoli Federico II Via Claudio 21 80125, Napoli, Italy Tel: +39 081 7683908 Fax: +39 081 7683816 Mob: +39 3807679372 E-mail: giorgio@unina.it http://www.dieti.unina.it http://www.developeracademy.unina.it/en/ http://www.docenti.unina.it/giorgio.ventre ========================================================================
Certamente l'aspetto economico è importante, per questo sarebbe interessante sapere quanto costano questi contratti di servizio, che come giustamente osservava Stefano Maffulli, integrano molti servizi, sia per gli admin che per gli utenti finali, e sono quindi percepiti positivamente dall'utenza finale. È importante, sia per confrontarli col costo di personale interno, sia perché poi, di fatto, rischia di determinarsi, per un ateneo, una situazione di "vendor lock-in" che può far lievitare i costi senza freno. Forse ricordo male, ma anche alle scuole nel periodo di lockdown le piattaforme erano state offerte gratis, e adesso non lo sono più. Qualcuno ha dati precisi su questo? Il punto è poi anche che, oltre al costo economico, c'è il valore della profilazione degli utenti, che diventa sempre più grande. Con il Machine Learning sempre più affamato di nuovi testi, ciò che passa per le caselle di posta elettronica e i cloud degli atenei penso sia un valore significativo per le Big Tech. Ecco, posto che sono conti niente affatto facili da fare (e in certa misura anche arbitrari: come fai a dare valore ai dati personali?), penso comunque che avere la conoscenza in casa secondo me sia, sul lungo periodo, sempre più conveniente per una grande amministrazione come un ateneo. A maggior ragione per chi dovrebbe essere sulla frontiera della conoscenza, come giustamente sostiene Giacomo Tesio. A condizione che riesca a capire l'importanza strategica di governare le infrastrutture digitali: mission impossible, temo, per molta della classe dirigente italiana centrale e locale. E a proposito: è su questa lista che ho letto dei problemi che le Big Tech creano agli email provider medi e piccoli nel gestire i loro messaggi? È chiaro che se anche 1 su 20 delle tue mail viene bloccata perché il tuo server di ateneo è stato messo in blacklist quando poi si passa ai Big tirano tutti un sospiro di sollievo... Infine, sarei curioso di sapere se ci sono analisi simili fatte per Paesi un po' più attenti del nostro a queste problematiche, tipo la Francia. Con l'occasione un augurio di buona fine e miglior principio. Enrico Il 29/12/2023 18:07, Giorgio Ventre ha scritto:
Cari tutti,
perdonatemi ma vorrei portare alla vostra attenzione le difficoltà di gestione che affrontano quotidianamente gli Atenei.
Il problema non è la disponibilità di talenti e competenze ma quella delle risorse necessarie a garantire i servizi che noi come privati siamo abituati a ricevere dai nostri provider preferiti.
In parole povere, occorrono soldi. E tanti.
Secondo me andare a sindacare le scelte dei singoli atenei mi sembra un esercizio sterile, quando spesso si tratta di scegliere tra mettere soldi in un Servizio IT o rinnovare le aule di un Dipartimento.
La questione dovrebbe essere affrontata dal punto di vista della politica industriale e della cultura tecnologica del Paese, insieme ad altri problemi come l'indipendenza sulle infrastrutture digitali.
Se si è deciso di affidare ad un singolo soggetto la gestione amministrativa e finanziaria degli Atenei, e ad un solo provider la gestione della rete di ricerca, forse una analoga decisione potrebbe essere presa per i servizi mail ed IT in genere. Dopo aver fatto un bilancio tra i costi ed i benefici, anche appunto quelli di natura "strategica".
Senza una decisione di questo genere il numero degli Atenei con gestioni in-house della mail si ridurrà sempre di più.
Un caro saluto a tutti ed auguri per un eccellente 2024.
Giorgio
Il 29/12/23 17:54, Giacomo Tesio ha scritto:
Ciao Damiano,
Il 28 Dicembre 2023 21:24:05 UTC, Damiano Verzulli <damiano@verzulli.it> ha scritto:
Mi interessa --ripeto-- mi interessa, che gli Atenei tornino a fare da apripista nella riappropriazione di parte del mondo tecnologico... che gli e' stato scippato. Sono certo --ripeto-- sono *CERTO* che è "tecnicamente" possibile. Il problema è solo "politico".
[...]
D'altronde.... se non si riesce a fare quello che io immagino, come pensiamo possa essere mai possibile ambire a fare quello che tu speri? Ciò che io proprio non riesco a capire è che credibilità possa avere una Università che si affida a Google o Microsoft per l'email pur avendo informatica o ingegneria informatica fra i percorsi di laurea proposti.
È deprimente pensare che nessuno si vergogni di tali scelte, viste le molte alternative nettamente migliori disponibili sul mercato.
A volte penso che oltre alla dismissione dell'Olivetti, il Piano Marshall ci sia costato l'idea stessa di un'Università competente, che tanto ad una colonia a-democratica non serviva.
Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- -- EN https://www.hoepli.it/libro/la-rivoluzione-informatica/9788896069516.html ====================================================== Prof. Enrico Nardelli Presidente di "Informatics Europe" Direttore del Laboratorio Nazionale "Informatica e Scuola" del CINI Dipartimento di Matematica - Università di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma home page: https://www.mat.uniroma2.it/~nardelli blog: https://link-and-think.blogspot.it/ tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it online meeting: https://blue.meet.garr.it/b/enr-y7f-t0q-ont ====================================================== --
Io sono perfettamente allineato con Enrico, Giorgio, Giacomo, Damiano. Mi permetto di aggiungere che, a mio giudizio, gli incarichi delle scuole e delle università alle Big Tech sono illegali perchè violano l'art.68 del vecchio codice dell'amministrazione digitale e le norme comunitarie per la protezione dei dati personali. Secondp i miei conti approssimativi i fatturati in Italia delle Big Tech sono dell'ordine di grandezza del reddito di cittadinanza, ma quei fatturati sono una perdita sevva della ricchezza del nostro Paese, mentre le spese rese possibili dal reddito di cittadinanza restano in Italia e sono equivalenti aad un investimento . Raf Meo ________________________________ From: nexa <nexa-bounces@server-nexa.polito.it> on behalf of Enrico Nardelli <nardelli@mat.uniroma2.it> Sent: Friday, December 29, 2023 8:18 PM To: nexa@server-nexa.polito.it <nexa@server-nexa.polito.it> Subject: Re: [nexa] "Posta elettronica": persi 6 Atenei in ~3 anni... Certamente l'aspetto economico è importante, per questo sarebbe interessante sapere quanto costano questi contratti di servizio, che come giustamente osservava Stefano Maffulli, integrano molti servizi, sia per gli admin che per gli utenti finali, e sono quindi percepiti positivamente dall'utenza finale. È importante, sia per confrontarli col costo di personale interno, sia perché poi, di fatto, rischia di determinarsi, per un ateneo, una situazione di "vendor lock-in" che può far lievitare i costi senza freno. Forse ricordo male, ma anche alle scuole nel periodo di lockdown le piattaforme erano state offerte gratis, e adesso non lo sono più. Qualcuno ha dati precisi su questo? Il punto è poi anche che, oltre al costo economico, c'è il valore della profilazione degli utenti, che diventa sempre più grande. Con il Machine Learning sempre più affamato di nuovi testi, ciò che passa per le caselle di posta elettronica e i cloud degli atenei penso sia un valore significativo per le Big Tech. Ecco, posto che sono conti niente affatto facili da fare (e in certa misura anche arbitrari: come fai a dare valore ai dati personali?), penso comunque che avere la conoscenza in casa secondo me sia, sul lungo periodo, sempre più conveniente per una grande amministrazione come un ateneo. A maggior ragione per chi dovrebbe essere sulla frontiera della conoscenza, come giustamente sostiene Giacomo Tesio. A condizione che riesca a capire l'importanza strategica di governare le infrastrutture digitali: mission impossible, temo, per molta della classe dirigente italiana centrale e locale. E a proposito: è su questa lista che ho letto dei problemi che le Big Tech creano agli email provider medi e piccoli nel gestire i loro messaggi? È chiaro che se anche 1 su 20 delle tue mail viene bloccata perché il tuo server di ateneo è stato messo in blacklist quando poi si passa ai Big tirano tutti un sospiro di sollievo... Infine, sarei curioso di sapere se ci sono analisi simili fatte per Paesi un po' più attenti del nostro a queste problematiche, tipo la Francia. Con l'occasione un augurio di buona fine e miglior principio. Enrico Il 29/12/2023 18:07, Giorgio Ventre ha scritto: Cari tutti, perdonatemi ma vorrei portare alla vostra attenzione le difficoltà di gestione che affrontano quotidianamente gli Atenei. Il problema non è la disponibilità di talenti e competenze ma quella delle risorse necessarie a garantire i servizi che noi come privati siamo abituati a ricevere dai nostri provider preferiti. In parole povere, occorrono soldi. E tanti. Secondo me andare a sindacare le scelte dei singoli atenei mi sembra un esercizio sterile, quando spesso si tratta di scegliere tra mettere soldi in un Servizio IT o rinnovare le aule di un Dipartimento. La questione dovrebbe essere affrontata dal punto di vista della politica industriale e della cultura tecnologica del Paese, insieme ad altri problemi come l'indipendenza sulle infrastrutture digitali. Se si è deciso di affidare ad un singolo soggetto la gestione amministrativa e finanziaria degli Atenei, e ad un solo provider la gestione della rete di ricerca, forse una analoga decisione potrebbe essere presa per i servizi mail ed IT in genere. Dopo aver fatto un bilancio tra i costi ed i benefici, anche appunto quelli di natura "strategica". Senza una decisione di questo genere il numero degli Atenei con gestioni in-house della mail si ridurrà sempre di più. Un caro saluto a tutti ed auguri per un eccellente 2024. Giorgio Il 29/12/23 17:54, Giacomo Tesio ha scritto: Ciao Damiano, Il 28 Dicembre 2023 21:24:05 UTC, Damiano Verzulli <damiano@verzulli.it><mailto:damiano@verzulli.it> ha scritto: Mi interessa --ripeto-- mi interessa, che gli Atenei tornino a fare da apripista nella riappropriazione di parte del mondo tecnologico... che gli e' stato scippato. Sono certo --ripeto-- sono *CERTO* che è "tecnicamente" possibile. Il problema è solo "politico". [...] D'altronde.... se non si riesce a fare quello che io immagino, come pensiamo possa essere mai possibile ambire a fare quello che tu speri? Ciò che io proprio non riesco a capire è che credibilità possa avere una Università che si affida a Google o Microsoft per l'email pur avendo informatica o ingegneria informatica fra i percorsi di laurea proposti. È deprimente pensare che nessuno si vergogni di tali scelte, viste le molte alternative nettamente migliori disponibili sul mercato. A volte penso che oltre alla dismissione dell'Olivetti, il Piano Marshall ci sia costato l'idea stessa di un'Università competente, che tanto ad una colonia a-democratica non serviva. Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it<mailto:nexa@server-nexa.polito.it> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa -- -- EN https://www.hoepli.it/libro/la-rivoluzione-informatica/9788896069516.html [cid:part1.XpNn0ilR.kGlJIqo0@mat.uniroma2.it] ====================================================== Prof. Enrico Nardelli Presidente di "Informatics Europe" Direttore del Laboratorio Nazionale "Informatica e Scuola" del CINI Dipartimento di Matematica - Università di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma home page: https://www.mat.uniroma2.it/~nardelli blog: https://link-and-think.blogspot.it/ tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it<mailto:nardelli@mat.uniroma2.it> online meeting: https://blue.meet.garr.it/b/enr-y7f-t0q-ont ====================================================== --
On Fri, Dec 29, 2023 20:18:52 PM +0100, Enrico Nardelli wrote:
E a proposito: è su questa lista che ho letto dei problemi che le Big Tech creano agli email provider medi e piccoli nel gestire i loro messaggi? È chiaro che se anche 1 su 20 delle tue mail viene bloccata perché il tuo server di ateneo è stato messo in blacklist quando poi si passa ai Big tirano tutti un sospiro di sollievo...
Presente: 2021: https://stop.zona-m.net/2021/12/self-hosted-email-must-remain-practical/ 2010: https://stop.zona-m.net/2010/05/the-real-obstacles-to-personal-email-managem... Buon 2024 a tutti! Marco -- Vi aspetto su Substack: https://mfioretti.substack.com
gestisco in prima persona il mail server della mia famiglia e delle mie (piccole) aziende su un server virtuale preso da un provider europeo. nessuno dei miei utenti ha lamentato problemi (a parte una volta che ho fatto un reboot della vps) non sono un grande tecnico e ogni tanto (una volta ogni paio d'anni) mi capita di chiedere qualche consiglio a chi ne sa di piu'. credo che se migrassi a uno dei gafam avrei personalmente meno spam, ma e' assolutamente gestibile (ed i miei indirizzi email sono ovunque, a disposizione di spammer di tutto il globo). non credo che un sistemista esperto dedicato, con risorse adeguate (poche) non sia in grado di gestire una organizzazione efficacemente... buon 2024! On 31/12/23 10:35, M. Fioretti wrote:
On Fri, Dec 29, 2023 20:18:52 PM +0100, Enrico Nardelli wrote:
E a proposito: è su questa lista che ho letto dei problemi che le Big Tech creano agli email provider medi e piccoli nel gestire i loro messaggi? È chiaro che se anche 1 su 20 delle tue mail viene bloccata perché il tuo server di ateneo è stato messo in blacklist quando poi si passa ai Big tirano tutti un sospiro di sollievo...
Presente:
2021: https://stop.zona-m.net/2021/12/self-hosted-email-must-remain-practical/
2010: https://stop.zona-m.net/2010/05/the-real-obstacles-to-personal-email-managem...
Buon 2024 a tutti!
Marco
Il 31 dicembre 2023 19:52:09 CET, Stefano Quintarelli <stefano@quintarelli.it> ha scritto:
gestisco in prima persona il mail server della mia famiglia e delle mie (piccole) aziende su un server virtuale preso da un provider europeo.
nessuno dei miei utenti ha lamentato problemi (a parte una volta che ho fatto un reboot della vps)
non sono un grande tecnico e ogni tanto (una volta ogni paio d'anni) mi capita di chiedere qualche consiglio a chi ne sa di piu'.
credo che se migrassi a uno dei gafam avrei personalmente meno spam, ma e' assolutamente gestibile (ed i miei indirizzi email sono ovunque, a disposizione di spammer di tutto il globo).
non credo che un sistemista esperto dedicato, con risorse adeguate (poche) non sia in grado di gestire una organizzazione efficacemente...
Idem, son svariati anni che gestiscono questo indirizzo letteralmente da casa mia. Le mie impressioni sono sovrapponibili alle tue, anche se ho la fortuna di avere dal mio provider un IP con buona reputazione.
buon 2024!
A te, e a tutta la lista! Buon anno! Roberto Resoli
Il 31/12/23 19:52, Stefano Quintarelli ha scritto:
gestisco in prima persona il mail server della mia famiglia [...] nessuno dei miei utenti ha lamentato problemi [...] non credo che un sistemista esperto dedicato [...] non sia in grado di gestire una organizzazione efficacemente...
Il 31/12/23 23:25, Roberto Resoli ha scritto:
[...] son svariati anni che gestiscono questo indirizzo letteralmente da casa mia. Le mie impressioni sono sovrapponibili alle tue [...]
Stefano, Roberto, purtroppo la vostra esperienza è quasi del tutto scorrelata dalla realta' che impatta *GRANDI* organizzazioni (a spanne, da mille mailbox in su...). Il numero di problemi che un "admin" deve affrontare al crescere delle mailbox e del relativo traffico, cresce *ESPONENZIALMENTE* con l'aumentare delle stesse. Su server "familiari" o anche di piccole organizzazioni, i concetti di "prestazione" (lato I/O), di "quantita' di storage occupato" (GB vs. TB) e relativa "protezione" e, soprattutto, di analisi dei problemi riportati dagli utenti ("pochi casi/anno" vs. "diversi casi/giorno").... anche causati dai livelli di "educazione informatica" degli utenti ("molto simili" vs. "estremamente variegati"), *NON* rappresentano un problema (...ammesso di seguire --come nei vostri due casi-- le best-practice basilari). Quanto sopra fa una differenza *ENORME* in termini di SPAM. Quando hai MIGLIAIA di utenti, troverai: 1. quello che vuole ricevere una mail da un server SMTP remoto, il cui admin *NON* è come voi due e... piuttosto, per me, admin "ricevente", quella mail è SPAM "a prescindere" perché il server è configurato da cani (mancanza di reverse-DNS; errori SPF/DKIM; mismatch di nomi; mancato rispetto degli RFC); 2. quello che vuole utilizzare un client scaricato da Android, sviluppato da qualcuno che ha fatto qualche esercizio per testare l'SMTP, per inviare mail (con il tuo server) ad un destinatario che magari è in Cina o Russia (o in un paese dove il charset di default NON è quello europeo)... e il client non supporta UTF-8; 3. quello che viene da te e dice: "Attendevo una mail da un tizio... perché non l'ho ricevuta?". Poi ti metti la, e dopo pochi minuti (tipicamente, meno di 1, se sei organizzato per bene) gli dici: "Guarda che è arrivata. Ce l'hai nella inbox. Sicuro che i messaggi siano ordinati per ordine di ricezione E NON PER DATA... dato che potrebbe avere una data 'indietro nel tempo'?" 4. quello che si è attivato un "forward" verso GMAIL (un "forward" vero...) e si accorge che --solo per questo-- GMAIL gli rifiuta (quasi sempre) tutti i messaggi in ingresso (perché in arrivo dal tuo server, che non è quello autorizzato dal dominio mittente) ...e potrei continuare. È in questo scenario che Google e Microsoft si inseriscono e, a causa delle proprie logiche (non note e, a volte, non rispettose degli standard), ti "segano". Uno dei casi emblematici --non noti al grande pubblico-- fu un paio d'anni fa... quando un *GROSSO* Ente di ricerca nazionale (piu' grosso di INFN; forse il piu' grosso che abbiamo in Italia) si vide blacklistata da microsoft la subnet associata ai suoi server SMTP *UFFICIALI*. Risultato: svariati giorni di caos e, subito dopo, l'ordine "dall'alto" di migrare la posta (...perché "non funziona!") a... Microsoft. Cosa prontamente avvenuta nei mesi successivi... Devo riconoscere che --per un "admin"-- passare la posta a Google o Microsoft è una salvezza: a tutti quelli che vengono da te, rispondi: "Mi spiace, non posso farci nulla!". A volte, pero', ti rispondono: "Ma come! E' sicuramente un problema 'di rete'! Avrete ["voi incompetenti" sottinteso] fatto qualche modifica!". E quindi... ti tocca comunque andare a spiegare / fare qualcosa che... *DIMOSTRI* (perchè "tu" DEVI dimostrare... mentre BigG e M$ possono fare bello e cattivo tempo senza che nessuno possa alzare un dito!) che tutto è a posto. Ricordo un altro caso emblematico: Facebook che, ~tre anni fa, modifico' il routing della sua CDN e, per qualche stranissimo caso, faceva si che da UniChieti e UniBrescia (solo noi due, che avevamo reti "adiacenti" in termini di IP) raggiungevano i server della loro DCN... *PASSANDO DAL PERU'*!!!!! Risultato: dai nostri due Atenei, i tempi di accesso a facebook erano drammaticamente lenti e, inoltre, alcuni contenuti non si vedevano proprio (georestrizioni). Fu *ESTREMAMENTE COMPLESSO* dimostrare che il problema *NON* era "nostro". E fu soltanto grazie ad *AMICIZIE PERSONALI* che alcuni tecnici GARR avevano con i loro colleghi di Facebook, che riuscimmo a portare sul sentiero corretto il troubleshooting e, nel giro di pochi giorni, portare facebook a "risolvere". Ovviamente il messaggio che passava --internamente-- era: "Ecco! Avete visto? Avete 'risolto' i vostri problemi e... ora tutto funziona!". Il punto saliente dei ragionamenti che provavo a stimolare su ITNOG [1] (un gruppo Telegram di "specialisti" di networking, ambito TELCO, Italia) è che... se tutto cio' accade *PER CAUSA TUA*, allora tu lavori e ti prendi le giuste ramanzine.... Se tutto, pero', accade per causa dei GAFAM, sei sempre tu che lavori... e sei [quasi] sempre tu a prenderti le ramanzine. In questo secondo caso, pero', la tua Azienda ha un danno (perché devi lavorare per risolvere i problemi causati da altri).... e non lo trovo giusto. Per questo suggerivo di cambiare atteggiamento (nostro, nei confronti loro) quantomeno per portare esplicitamente alla luce le problematiche che --viceversa-- tendono a restare "al buio". In ogni caso --e concludo-- per poter "vedere" queste problematiche.... devi quantomeno affacciarti a contesti decisamente "estesi": fin quando hai qualche decina di caselle afferenti ad utenti che --piu' o meno-- hanno poche e simili abitutini.... il mondo (dell'SMTP) ti sembrera' sempre "tranquillo" :-) Un caro saluto e AUGURI DI BUON ANNO a tutti! Bye, DV [1] il thread gira attorno a questo messaggio https://t.me/IT_NOG/1/113087 -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
confermo l'atteggiamento. conosco bene il problema. con I.NET, prima di spam assassin, prima di gmail, prima di open-xchange - c'era critical path, ma il nostro era più performante) gestivamo >> 100k mailbox, avevamo scritto il nostro server, il nostro directory server, il nostro antispam e avevamo una nostra webmail (avevamo comperato una startup che si chiamava Matrice). il team di sviluppo erano tre persone (5 a livello di picco post acquisizione), quello di gestione erano circa due persone (uno degli sviluppatori e Marco Negri, loro capo e direttore tecnico). (Poi c'era il customer care, ma che era lo stesso per tutti i servizi) Oltretutto i nostri utenti pagavano e quindi erano molto esigenti e all'epoca non capivano proprio perché ricevessero mail indesiderate! il server erano una coppia di risc 6000 (aix con dietro un db2 con replica simmetrica asincrona). lo storage era sempre IBM. continuo a ritenere che un sistemista esperto con risorse adeguate sia in grado di gestire la posta di un ateneo. ciao, s. p.s. i problemi di routing sono un'invariante rispetto alla gestione della mail (e anche i DOS ed anche le SAN, che all'epoca non c'erano) Il 1 gennaio 2024 10:39:33 UTC, Damiano Verzulli <damiano@verzulli.it> ha scritto:
Il 31/12/23 19:52, Stefano Quintarelli ha scritto:
gestisco in prima persona il mail server della mia famiglia [...] nessuno dei miei utenti ha lamentato problemi [...] non credo che un sistemista esperto dedicato [...] non sia in grado di gestire una organizzazione efficacemente...
Il 31/12/23 23:25, Roberto Resoli ha scritto:
[...] son svariati anni che gestiscono questo indirizzo letteralmente da casa mia. Le mie impressioni sono sovrapponibili alle tue [...]
Stefano, Roberto,
purtroppo la vostra esperienza è quasi del tutto scorrelata dalla realta' che impatta *GRANDI* organizzazioni (a spanne, da mille mailbox in su...).
Il numero di problemi che un "admin" deve affrontare al crescere delle mailbox e del relativo traffico, cresce *ESPONENZIALMENTE* con l'aumentare delle stesse.
Su server "familiari" o anche di piccole organizzazioni, i concetti di "prestazione" (lato I/O), di "quantita' di storage occupato" (GB vs. TB) e relativa "protezione" e, soprattutto, di analisi dei problemi riportati dagli utenti ("pochi casi/anno" vs. "diversi casi/giorno").... anche causati dai livelli di "educazione informatica" degli utenti ("molto simili" vs. "estremamente variegati"), *NON* rappresentano un problema (...ammesso di seguire --come nei vostri due casi-- le best-practice basilari).
Quanto sopra fa una differenza *ENORME* in termini di SPAM.
Quando hai MIGLIAIA di utenti, troverai:
1. quello che vuole ricevere una mail da un server SMTP remoto, il cui admin *NON* è come voi due e... piuttosto, per me, admin "ricevente", quella mail è SPAM "a prescindere" perché il server è configurato da cani (mancanza di reverse-DNS; errori SPF/DKIM; mismatch di nomi; mancato rispetto degli RFC);
2. quello che vuole utilizzare un client scaricato da Android, sviluppato da qualcuno che ha fatto qualche esercizio per testare l'SMTP, per inviare mail (con il tuo server) ad un destinatario che magari è in Cina o Russia (o in un paese dove il charset di default NON è quello europeo)... e il client non supporta UTF-8;
3. quello che viene da te e dice: "Attendevo una mail da un tizio... perché non l'ho ricevuta?". Poi ti metti la, e dopo pochi minuti (tipicamente, meno di 1, se sei organizzato per bene) gli dici: "Guarda che è arrivata. Ce l'hai nella inbox. Sicuro che i messaggi siano ordinati per ordine di ricezione E NON PER DATA... dato che potrebbe avere una data 'indietro nel tempo'?"
4. quello che si è attivato un "forward" verso GMAIL (un "forward" vero...) e si accorge che --solo per questo-- GMAIL gli rifiuta (quasi sempre) tutti i messaggi in ingresso (perché in arrivo dal tuo server, che non è quello autorizzato dal dominio mittente)
...e potrei continuare.
È in questo scenario che Google e Microsoft si inseriscono e, a causa delle proprie logiche (non note e, a volte, non rispettose degli standard), ti "segano". Uno dei casi emblematici --non noti al grande pubblico-- fu un paio d'anni fa... quando un *GROSSO* Ente di ricerca nazionale (piu' grosso di INFN; forse il piu' grosso che abbiamo in Italia) si vide blacklistata da microsoft la subnet associata ai suoi server SMTP *UFFICIALI*. Risultato: svariati giorni di caos e, subito dopo, l'ordine "dall'alto" di migrare la posta (...perché "non funziona!") a... Microsoft. Cosa prontamente avvenuta nei mesi successivi...
Devo riconoscere che --per un "admin"-- passare la posta a Google o Microsoft è una salvezza: a tutti quelli che vengono da te, rispondi: "Mi spiace, non posso farci nulla!". A volte, pero', ti rispondono: "Ma come! E' sicuramente un problema 'di rete'! Avrete ["voi incompetenti" sottinteso] fatto qualche modifica!". E quindi... ti tocca comunque andare a spiegare / fare qualcosa che... *DIMOSTRI* (perchè "tu" DEVI dimostrare... mentre BigG e M$ possono fare bello e cattivo tempo senza che nessuno possa alzare un dito!) che tutto è a posto.
Ricordo un altro caso emblematico: Facebook che, ~tre anni fa, modifico' il routing della sua CDN e, per qualche stranissimo caso, faceva si che da UniChieti e UniBrescia (solo noi due, che avevamo reti "adiacenti" in termini di IP) raggiungevano i server della loro DCN... *PASSANDO DAL PERU'*!!!!! Risultato: dai nostri due Atenei, i tempi di accesso a facebook erano drammaticamente lenti e, inoltre, alcuni contenuti non si vedevano proprio (georestrizioni). Fu *ESTREMAMENTE COMPLESSO* dimostrare che il problema *NON* era "nostro". E fu soltanto grazie ad *AMICIZIE PERSONALI* che alcuni tecnici GARR avevano con i loro colleghi di Facebook, che riuscimmo a portare sul sentiero corretto il troubleshooting e, nel giro di pochi giorni, portare facebook a "risolvere". Ovviamente il messaggio che passava --internamente-- era: "Ecco! Avete visto? Avete 'risolto' i vostri problemi e... ora tutto funziona!".
Il punto saliente dei ragionamenti che provavo a stimolare su ITNOG [1] (un gruppo Telegram di "specialisti" di networking, ambito TELCO, Italia) è che... se tutto cio' accade *PER CAUSA TUA*, allora tu lavori e ti prendi le giuste ramanzine.... Se tutto, pero', accade per causa dei GAFAM, sei sempre tu che lavori... e sei [quasi] sempre tu a prenderti le ramanzine. In questo secondo caso, pero', la tua Azienda ha un danno (perché devi lavorare per risolvere i problemi causati da altri).... e non lo trovo giusto. Per questo suggerivo di cambiare atteggiamento (nostro, nei confronti loro) quantomeno per portare esplicitamente alla luce le problematiche che --viceversa-- tendono a restare "al buio".
In ogni caso --e concludo-- per poter "vedere" queste problematiche.... devi quantomeno affacciarti a contesti decisamente "estesi": fin quando hai qualche decina di caselle afferenti ad utenti che --piu' o meno-- hanno poche e simili abitutini.... il mondo (dell'SMTP) ti sembrera' sempre "tranquillo" :-)
Un caro saluto e AUGURI DI BUON ANNO a tutti!
Bye, DV
[1] il thread gira attorno a questo messaggio https://t.me/IT_NOG/1/113087
continuo a ritenere che un sistemista esperto con risorse adeguate sia in grado di gestire la posta di un ateneo.
"The average user may not care, but for those of us on the deep-end of the geek spectrum, these trends have worrying implications for software freedom, open standards, overall interoperability and net neutrality. Our concern is highly political." (dal primo degli articoli segnalati da Enrico) Più che sistemista esperto, mi vedo più nella fascia del "deep-end of the geek spectrum" ... Nella mia vita lavorativa e extra (nella prima, da sistemista più o meno esperto, nella seconda da geek), ho installato e gestito di tutto. Server email, sicuramente, più di vent'anni fa, ma poi, server x newsgroups NNTP (il "famoso" INN), groupware ICQ (ovviamente free, con IServerd), fino agli ultimi Matrix (con Synapse), istanze Mastodon (con Pleroma e altri). E' vero, come dice Damiano, fino ad una ventina di utenti il mondo (dell'SMTP e di tutto ciò che ho elencato sopra) mi è sembrato sempre "tranquillo". Di utenti siamo arrivati ad averne qualche centinaio (colleghi e amici smanettoni, più che altro, che certo non ti chiamavano perché la preziosa email da loro tanto attesa era finita nello spam). Ma allora fissiamolo questo "limite", sotto il quale si può gestire la posta di un (ateneo/ente/società/ministero/ecc.) con risorse interne e superato il quale bisogna rivolgersi a fornitori esterni. E se proprio, come scrive Carlos Fenollosa, "After self hosting my email for twenty-three years, I have thrown in the towel. The oligopoly has won." è tutto perso, beh, ma lasciamola perdere questa posta elettronica, "buttiamoci" su Matrix e ActivityPub. Ciao e buon anno a tutti, Antonio
Ciao Antonio, Antonio <antonio@piumarossa.it> writes: [...]
Ma allora fissiamolo questo "limite", sotto il quale si può gestire la posta di un (ateneo/ente/società/ministero/ecc.) con risorse interne e superato il quale bisogna rivolgersi a fornitori esterni.
scusa se mi ripeto, il "limite" è solo e soltanto un (piccolo) gruppo di SMTP Relay hosts (autenticati, ovviamente) messi a disposizione di atenei/enti/ministero una cosa analoga per le aziende lo potrebbero fare le Camere di Commercio, se solo si mettessero in testa che /dovrebbero/ avere un ruolo importante nell'informatica dei propri associati (obbligati) [...]
è tutto perso
balle
beh, ma lasciamola perdere questa posta elettronica, "buttiamoci" su Matrix e ActivityPub.
seeee, hanno così ancora da correre per poter competere nella comunicazione distribuita e /asincrona/! andateci piano a dare - per l'ennesima volta - l'email per morta Saluti, 380° [...] -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Il 01/01/24 12:46, Stefano Quintarelli ha scritto:
[...] continuo a ritenere che un sistemista esperto con risorse adeguate sia in grado di gestire la posta di un ateneo.
Mi viene il dubbio che io possa essermi espresso male. Quindi, sottoscrivendo la tua opinione, ribadisco *CON FORZA* che... SI, anche solo una singola persona, con competenze adeguate e risorse dell'ordine di 100K€ da ammortizzare in tempi dell'ordine di 5/7 anni (quindi: ~15/20k /anno), puo' gestire una infrastruttura al servizio di un Ateneo da 1.5K unita' di personale. Per inciso: è quello che ho fatto, fra il 2003 ed il ~2020. Il 01/01/24 20:44, Antonio ha scritto:
[...] Ma allora fissiamolo questo "limite", sotto il quale si può gestire la posta di un (ateneo/ente/società/ministero/ecc.) con risorse interne e superato il quale bisogna rivolgersi a fornitori esterni.
Non si tratta di porre un limite "tecnico". Tecnicamente... le architettura possono essere banalmente replicabili (es.: dopo aver speso [tanto] tempo per passare da 1 a 2 backend, il passaggio successivo [da 2 a 3, a 4, a 5... a 10] è stato talmente "banale" che quello da 10 a 11 l'ha fatto qualcuno... che non aveva mai visto prima l'architettura di cui si parla). Il problema è "politico": non puo' essere il "settore tecnico" la prima linea che fronteggia gli utenti i quali --in un contesto completamente deregolamentato-- pretendono di fare cio' che vogliono. E' necessario predisporre delle "regole" d'uso [es.: niente "forward" verso servizi terzi; niente "pull" da servizi terzi; solo "client" ufficiali; 2FA obbligatoria per tutti; limiti/throttling nell'accesso dall'estero; analisi del numero e della distribuzione degli accessi e degli invii, pro-misure-sicurezza ; etc.] le quali non possono non avere il pieno endorsement della componente "politica". Quando la componente "politica" e quella "tecnica" godono di stima reciproca, si possono facilmente scalare anche le montagne piu' impervie.... In ogni caso, per quella che è la mia esperienza personale, nella scala odierna, non credo ci siano piu' le condizioni --per un Ateneo piccolo/medio-- di gestire la Posta in autonomia... ma non tanto per problemi "tecnici", quanto per il fatto che i tecnici --sob!-- stanno scomparendo letteralmente e, a tendere, (~5 anni), spariranno del tutto (pensionamento).... SENZA RICAMBIO GENERAZIONALE. E' per questo motivo che --sempre secondo me-- la via è quella di Gruppi di Lavoro cross-Atenei: riunire le menti (tecniche) e farle lavorare per "pianificare le architetture" e, soprattutto, definire le metologie (automatiche) di implementazione e monitoraggio. A quel punto, anche le architetture piu' sofisticate potranno essere gestite da "junior" che --si spera-- prima o poi torneranno ad occupare le scrivanie tecniche. Si spera... (hint: è *ESATTAMENTE* quello che fanno i GAFAM... per la definizione/gestione delle proprie infrastrutture.... Solo che lo fanno su scala piu' ampia [mondo]). Bye, DV -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
la via è quella di Gruppi di Lavoro cross-Atenei: riunire le menti (tecniche) e farle lavorare per "pianificare le architetture" e, soprattutto, definire le metologie (automatiche) di implementazione e monitoraggio.
Grazie Damiano della sponda :) Anche se sono cose che ho scritto altre volte in questa lista, li voglio ripetere, non sia mai che questo 2024, a dispetto del detto "anno bisesto anno funesto", almeno nei temi di cui si discute qui, non sia "sfortunato". Gruppi di Lavoro cross-Atenei, e perché non cross-PPAA ? L'ultimo "incontro" che ho avuto con informatici di altre PP.AA. risale agli inizi del millennio, poi niente più. Il virus della "competitivizzazione" della P.A. si è diffuso ormai anche nel più piccolo ente locale e allora succede che: - la mia Università è la migliore perché offre il servizio migliore al prezzo più basso; - il mio ufficio provinciale ottiene risultati migliori dell'ufficio della provincia confinante; A decidere come "vincere" è il management (spesso inquinato dalla peggiore politica) che si affida al direttore tecnico il quale mette in pratica pedissequamente quanto richiesto. Apparire efficienti, tutto il resto sono ciance per "pensatori critici", "utopisti", perché lo sanno tutti (loro), la "tecnica non è democratica". Riunire le menti tecniche non è semplice, quando sono pochi e ... "ma io ho tanto da fare, se mi metto pure a dispensare consigli ad enti esterni il mio lavoro chi lo fa", e questo perché ognuno di noi è convinto di essere indispensabile. Fossi io metterei una regola (lo so, le regole non piacciono a nessuno, ma qualche eccezione) che una volta al mese ci se debba confrontare, non tra direttori tecnici di ogni ente, in questo modo si risolverebbe poco o nulla, ma ad ogni incontro persone diverse. Antonio
Aggiungo un paio di articoli che sono riuscito a ritrovare sulle difficoltà di self-hosting della posta elettronica. Descrivono un panorama abbastanza preoccupante. Rant against centralising e-mail in big-tech silos, and breaking the internet in the process https://proycon.anaproy.nl/posts/rant-against-centralising-e-mail/ After self-hosting my email for twenty-three years I have thrown in the towel. The oligopoly has won https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-yea... Ciao, Enrico Il 01/01/2024 11:39, Damiano Verzulli ha scritto:
Il 31/12/23 19:52, Stefano Quintarelli ha scritto:
gestisco in prima persona il mail server della mia famiglia [...] nessuno dei miei utenti ha lamentato problemi [...] non credo che un sistemista esperto dedicato [...] non sia in grado di gestire una organizzazione efficacemente...
Il 31/12/23 23:25, Roberto Resoli ha scritto:
[...] son svariati anni che gestiscono questo indirizzo letteralmente da casa mia. Le mie impressioni sono sovrapponibili alle tue [...]
Stefano, Roberto,
purtroppo la vostra esperienza è quasi del tutto scorrelata dalla realta' che impatta *GRANDI* organizzazioni (a spanne, da mille mailbox in su...).
Il numero di problemi che un "admin" deve affrontare al crescere delle mailbox e del relativo traffico, cresce *ESPONENZIALMENTE* con l'aumentare delle stesse.
Su server "familiari" o anche di piccole organizzazioni, i concetti di "prestazione" (lato I/O), di "quantita' di storage occupato" (GB vs. TB) e relativa "protezione" e, soprattutto, di analisi dei problemi riportati dagli utenti ("pochi casi/anno" vs. "diversi casi/giorno").... anche causati dai livelli di "educazione informatica" degli utenti ("molto simili" vs. "estremamente variegati"), *NON* rappresentano un problema (...ammesso di seguire --come nei vostri due casi-- le best-practice basilari).
Quanto sopra fa una differenza *ENORME* in termini di SPAM.
Quando hai MIGLIAIA di utenti, troverai:
1. quello che vuole ricevere una mail da un server SMTP remoto, il cui admin *NON* è come voi due e... piuttosto, per me, admin "ricevente", quella mail è SPAM "a prescindere" perché il server è configurato da cani (mancanza di reverse-DNS; errori SPF/DKIM; mismatch di nomi; mancato rispetto degli RFC);
2. quello che vuole utilizzare un client scaricato da Android, sviluppato da qualcuno che ha fatto qualche esercizio per testare l'SMTP, per inviare mail (con il tuo server) ad un destinatario che magari è in Cina o Russia (o in un paese dove il charset di default NON è quello europeo)... e il client non supporta UTF-8;
3. quello che viene da te e dice: "Attendevo una mail da un tizio... perché non l'ho ricevuta?". Poi ti metti la, e dopo pochi minuti (tipicamente, meno di 1, se sei organizzato per bene) gli dici: "Guarda che è arrivata. Ce l'hai nella inbox. Sicuro che i messaggi siano ordinati per ordine di ricezione E NON PER DATA... dato che potrebbe avere una data 'indietro nel tempo'?"
4. quello che si è attivato un "forward" verso GMAIL (un "forward" vero...) e si accorge che --solo per questo-- GMAIL gli rifiuta (quasi sempre) tutti i messaggi in ingresso (perché in arrivo dal tuo server, che non è quello autorizzato dal dominio mittente)
...e potrei continuare.
È in questo scenario che Google e Microsoft si inseriscono e, a causa delle proprie logiche (non note e, a volte, non rispettose degli standard), ti "segano". Uno dei casi emblematici --non noti al grande pubblico-- fu un paio d'anni fa... quando un *GROSSO* Ente di ricerca nazionale (piu' grosso di INFN; forse il piu' grosso che abbiamo in Italia) si vide blacklistata da microsoft la subnet associata ai suoi server SMTP *UFFICIALI*. Risultato: svariati giorni di caos e, subito dopo, l'ordine "dall'alto" di migrare la posta (...perché "non funziona!") a... Microsoft. Cosa prontamente avvenuta nei mesi successivi...
Devo riconoscere che --per un "admin"-- passare la posta a Google o Microsoft è una salvezza: a tutti quelli che vengono da te, rispondi: "Mi spiace, non posso farci nulla!". A volte, pero', ti rispondono: "Ma come! E' sicuramente un problema 'di rete'! Avrete ["voi incompetenti" sottinteso] fatto qualche modifica!". E quindi... ti tocca comunque andare a spiegare / fare qualcosa che... *DIMOSTRI* (perchè "tu" DEVI dimostrare... mentre BigG e M$ possono fare bello e cattivo tempo senza che nessuno possa alzare un dito!) che tutto è a posto.
Ricordo un altro caso emblematico: Facebook che, ~tre anni fa, modifico' il routing della sua CDN e, per qualche stranissimo caso, faceva si che da UniChieti e UniBrescia (solo noi due, che avevamo reti "adiacenti" in termini di IP) raggiungevano i server della loro DCN... *PASSANDO DAL PERU'*!!!!! Risultato: dai nostri due Atenei, i tempi di accesso a facebook erano drammaticamente lenti e, inoltre, alcuni contenuti non si vedevano proprio (georestrizioni). Fu *ESTREMAMENTE COMPLESSO* dimostrare che il problema *NON* era "nostro". E fu soltanto grazie ad *AMICIZIE PERSONALI* che alcuni tecnici GARR avevano con i loro colleghi di Facebook, che riuscimmo a portare sul sentiero corretto il troubleshooting e, nel giro di pochi giorni, portare facebook a "risolvere". Ovviamente il messaggio che passava --internamente-- era: "Ecco! Avete visto? Avete 'risolto' i vostri problemi e... ora tutto funziona!".
Il punto saliente dei ragionamenti che provavo a stimolare su ITNOG [1] (un gruppo Telegram di "specialisti" di networking, ambito TELCO, Italia) è che... se tutto cio' accade *PER CAUSA TUA*, allora tu lavori e ti prendi le giuste ramanzine.... Se tutto, pero', accade per causa dei GAFAM, sei sempre tu che lavori... e sei [quasi] sempre tu a prenderti le ramanzine. In questo secondo caso, pero', la tua Azienda ha un danno (perché devi lavorare per risolvere i problemi causati da altri).... e non lo trovo giusto. Per questo suggerivo di cambiare atteggiamento (nostro, nei confronti loro) quantomeno per portare esplicitamente alla luce le problematiche che --viceversa-- tendono a restare "al buio".
In ogni caso --e concludo-- per poter "vedere" queste problematiche.... devi quantomeno affacciarti a contesti decisamente "estesi": fin quando hai qualche decina di caselle afferenti ad utenti che --piu' o meno-- hanno poche e simili abitutini.... il mondo (dell'SMTP) ti sembrera' sempre "tranquillo" :-)
Un caro saluto e AUGURI DI BUON ANNO a tutti!
Bye, DV
[1] il thread gira attorno a questo messaggio https://t.me/IT_NOG/1/113087
-- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa --
-- EN https://www.hoepli.it/libro/la-rivoluzione-informatica/9788896069516.html ====================================================== Prof. Enrico Nardelli Presidente di "Informatics Europe" Direttore del Laboratorio Nazionale "Informatica e Scuola" del CINI Dipartimento di Matematica - Università di Roma "Tor Vergata" Via della Ricerca Scientifica snc - 00133 Roma home page: https://www.mat.uniroma2.it/~nardelli blog: https://link-and-think.blogspot.it/ tel: +39 06 7259.4204 fax: +39 06 7259.4699 mobile: +39 335 590.2331 e-mail: nardelli@mat.uniroma2.it online meeting: https://blue.meet.garr.it/b/enr-y7f-t0q-ont ====================================================== --
Buongiorno, Damiano Verzulli <damiano@verzulli.it> writes:
Il 31/12/23 19:52, Stefano Quintarelli ha scritto:
gestisco in prima persona il mail server della mia famiglia [...] nessuno dei miei utenti ha lamentato problemi [...] non credo che un sistemista esperto dedicato [...] non sia in grado di gestire una organizzazione efficacemente...
Il 31/12/23 23:25, Roberto Resoli ha scritto:
[...] son svariati anni che gestiscono questo indirizzo letteralmente da casa mia. Le mie impressioni sono sovrapponibili alle tue [...]
evito di raccontare la rava e la fava sulle esperienze professionali del mio alter ego in materia di posta elettronica, vi basti sapere che conosco molto bene la materia :-D l'executive summary è: gestire un servizio di posta elettronica tecnicamente è una sciocchezza, se non fosse per le politiche "embrace, extend and extinguish" messe in atto da almeno 15 anni da alcuni grossi operatori email, praticamente /tutti/ statunitensi. detto in altre parole, è FUORI DI DUBBIO che c'è una volontà politica, di politica industriale globale, per accentrare tutta la posta elettronica occidentale, compresa quella "on rest", sui server controllati dal governo USA. come con moltissime altre strategie globali, la SCUSA per mettere in pratica "embrace, extend and extinguish" è la "lotta all SPAM", che precede di qualche anno la "lotta al terrorismo" :-O la cosa che mi fa impressione è che "embrace, extend and extinguish" è una pratica vecchia di almeno 30 anni... ma continua ad essere ampiamente usata e RARAMENTE riconosciuta da chi dovrebbe intervenire per stroncarla [...]
Il numero di problemi che un "admin" deve affrontare al crescere delle mailbox e del relativo traffico, cresce *ESPONENZIALMENTE* con l'aumentare delle stesse.
sì ma SOLO per questi due motivi, in ordine di peso: 1. il numero di provider coinvolti nel traffico SMTP cresce (non esponenzialmente) con l'aumento degli utenti e di conseguenza aumenta il rischio di essere bloccati da almeno uno di essi per motivi FUTILI se non palesemente ANTICOMPETITIVI (fattore politico) 2. la competenza quadratica media nell'utilizzo degli strumenti di gestione della posta elettronica cala, questa sì esponenzialmente, con l'aumentare degli utenti e di conseguenza il supporto diventa sempre più oneroso (fattore culturale)
Su server "familiari" o anche di piccole organizzazioni, i concetti di "prestazione" (lato I/O), di "quantita' di storage occupato" (GB vs. TB)
relativamente allo storage, dipende moltissimo dalla cattiva pratica di lasciare tutti i messaggi su UN server; l'ideale sarebbe che tutta la posta stesse su un "server personale" dell'utente, o in alternativa "server di gruppo" (tipo familiari) di massimo un paio di decine di utenti [...]
Quanto sopra fa una differenza *ENORME* in termini di SPAM.
il problema dello SPAM è ampiamente sopravvalutato e usato per fini anticompetitivi
Quando hai MIGLIAIA di utenti, troverai:
1. quello che vuole ricevere una mail da un server SMTP remoto, il cui admin *NON* è come voi due e... piuttosto, per me, admin "ricevente", quella mail è SPAM "a prescindere" perché il server è configurato da cani (mancanza di reverse-DNS; errori SPF/DKIM; mismatch di nomi; mancato rispetto degli RFC);
suvvia: qui c'è poco da "discutere" :-D
2. quello che vuole utilizzare un client scaricato da Android, sviluppato da qualcuno che ha fatto qualche esercizio per testare l'SMTP, per inviare mail (con il tuo server) ad un destinatario che magari è in Cina o Russia (o in un paese dove il charset di default NON è quello europeo)... e il client non supporta UTF-8;
qui ricadiamo nel "fattore culturale", anche se l'esempio è un po' "tirato"... e in ogni caso la risposta che il supporto tecnico può dare all'utente è veramente semplice
3. quello che viene da te e dice: "Attendevo una mail da un tizio... perché non l'ho ricevuta?". Poi ti metti la, e dopo pochi minuti (tipicamente, meno di 1, se sei organizzato per bene) gli dici: "Guarda che è arrivata. Ce l'hai nella inbox. Sicuro che i messaggi siano ordinati per ordine di ricezione E NON PER DATA... dato che potrebbe avere una data 'indietro nel tempo'?"
"quello" viene da te perché tu esisti e "quello" si sente autorizzato a farti domande imbarazzantissime perché "sei pagato" per quello... se "quello" usasse gmail, invece, chiederebbe aiuto a /suo cuggino/, non a Google
4. quello che si è attivato un "forward" verso GMAIL (un "forward" vero...) e si accorge che --solo per questo-- GMAIL gli rifiuta (quasi sempre) tutti i messaggi in ingresso (perché in arrivo dal tuo server, che non è quello autorizzato dal dominio mittente)
il problema l'admin lo deve risolvere adottando un server che supporti SRS [1]
...e potrei continuare.
oggi, il principale motivo di "attrito" con gli utenti è il fatto che i soliti noti monopolisti (occidentali) dell'email bloccano messaggi o intere sottoreti senza che sia chiaro il motivo
È in questo scenario che Google e Microsoft si inseriscono e, a causa delle proprie logiche (non note e, a volte, non rispettose degli standard), ti "segano".
ecco, appunto; da quello che so non c'è nulla di non rispettoso degli standard, il fatto è che "semplicemente" ogni provider può adottare le policy di blocco che vuole e non deve risponderne a nessuno
Uno dei casi emblematici --non noti al grande pubblico-- fu un paio d'anni fa... quando un *GROSSO* Ente di ricerca nazionale (piu' grosso di INFN; forse il piu' grosso che abbiamo in Italia) si vide blacklistata da microsoft la subnet associata ai suoi server SMTP *UFFICIALI*. Risultato: svariati giorni di caos e, subito dopo, l'ordine "dall'alto" di migrare la posta (...perché "non funziona!") a... Microsoft. Cosa prontamente avvenuta nei mesi successivi...
Appunto: embrace, extend and extinguish Uno alla volta li "prenderanno" tutti, perché invece che incazzarsi anche quelli che /dovrebbero/ opporsi si arrendono Tipo: perché per l'intero mondo scolastico+universitario le istituzioni non mettono in piedi un gruppo di SMTP Relay per tutte le scuole e UNI e difendono la sua "deliverability" con le unghie e coi denti? La risposta è una sola: NANISMO culturale ancora prima che politico.
Devo riconoscere che --per un "admin"-- passare la posta a Google o Microsoft è una salvezza: a tutti quelli che vengono da te, rispondi: "Mi spiace, non posso farci nulla!".
e gli utenti zitti... non solo gli utenti, anche i dirigenti NANISMO culturale. Punto.
A volte, pero', ti rispondono: "Ma come! E' sicuramente un problema 'di rete'! Avrete ["voi incompetenti" sottinteso] fatto qualche modifica!". E quindi... ti tocca comunque andare a spiegare / fare qualcosa che... *DIMOSTRI* (perchè "tu" DEVI dimostrare... mentre BigG e M$ possono fare bello e cattivo tempo senza che nessuno possa alzare un dito!) che tutto è a posto.
ecco appunto... più che nanismo assomiglia moltissimo a TOTALITARISMO [...] alla fin dei conti, comunque, rimane il fatto che /tecnicamente/ istanziare e manutenere un server di posta elettronica per la propria organizzazione è ampiamente fattibile. Saluti, 380° [1] https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Buongiorno a tutt, avendo vissuto professionalmente accanto a chi gestiva i server in-house dell'Ateneo dove lavoro, posso dire che lo stress e l'effort necessario al mantenimento di un mail server con ~20k caselle di posta, con relativi problemi di spazio, spam, blacklist etc. è davvero molto faticoso. A cui si aggiunge una scarsissima consapevolezza delle dirigenze che nella posta elettronica, come ion molti altri servizi considerati "di base" (telefonia, Internet...) non riescono a vederci alcun valore: semplicemente, come per l'acqua potabile e la corrente elettrica, devono esserci e ci si aspetta che ci siano. Migrare tout-court la posta su Google (decisione per la quale evidenziai le potenziali criticità future) è stato, per il nostro piccolo staff IT che da anni non vede alcuna nuova acquisizione ma svariati pensionamenti, un sospiro di sollievo. Certo, c'è chi si lamenta dello spam, dei problemi di spedizione e le altre problematiche note delle mail ma -e qui pare brutto da dire ma sarò diretto- ci "passa male" Google. In questo scenario neanche la normativa e la politica sembrano aiutare molto per un cambio di rotta ma, anzi, mi pare proprio che i vari obblighi di affidarsi ai servizi in cloud dirigano la PA dritta nelle braccia di pochi grandi fornitori di servizi (la vicenda Westpole e PA digitale è emblematica, non trovate?). Nel breve termine potrà anche funzionare e con costi sopportabili, ma nel lungo? Questa sempre maggiore dipendenza del "pubblico" dal "privato" temo possa essere una enorme spada di Damocle sulla testa della Democrazia nazionale e non sono affatto tranquillo di quanto potrà accadere. Del resto, però, gli investimenti della PA in personale ICT sono sempre meno. L'ICT è visto come un costo e non come una risorsa (basti vedere in ambito sicurezza informatica, per dirne una...) e quindi si cerca, con i famosi ulteriori adempimenti "/senza ulteriori costi a carico della finanza pubblica/", di spostare fattori di costo dove si può... Just my 2 cents, ovviamente. MP Il 31/12/23 19:52, Stefano Quintarelli ha scritto:
gestisco in prima persona il mail server della mia famiglia e delle mie (piccole) aziende su un server virtuale preso da un provider europeo.
nessuno dei miei utenti ha lamentato problemi (a parte una volta che ho fatto un reboot della vps)
non sono un grande tecnico e ogni tanto (una volta ogni paio d'anni) mi capita di chiedere qualche consiglio a chi ne sa di piu'.
credo che se migrassi a uno dei gafam avrei personalmente meno spam, ma e' assolutamente gestibile (ed i miei indirizzi email sono ovunque, a disposizione di spammer di tutto il globo).
non credo che un sistemista esperto dedicato, con risorse adeguate (poche) non sia in grado di gestire una organizzazione efficacemente...
buon 2024!
On 31/12/23 10:35, M. Fioretti wrote:
On Fri, Dec 29, 2023 20:18:52 PM +0100, Enrico Nardelli wrote:
E a proposito: è su questa lista che ho letto dei problemi che le Big Tech creano agli email provider medi e piccoli nel gestire i loro messaggi? È chiaro che se anche 1 su 20 delle tue mail viene bloccata perché il tuo server di ateneo è stato messo in blacklist quando poi si passa ai Big tirano tutti un sospiro di sollievo...
Presente:
2021: https://stop.zona-m.net/2021/12/self-hosted-email-must-remain-practical/
2010: https://stop.zona-m.net/2010/05/the-real-obstacles-to-personal-email-managem...
Buon 2024 a tutti!
Marco
nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- Michele Pinassi PGP/GPG 6EC4 9905 84F5 1537 9AB6 33E7 14FC 37E5 3C24 B98E Ufficio esercizio e tecnologie Università degli Studi di Siena
Il 29/12/23 18:07, Giorgio Ventre ha scritto:
[...] perdonatemi ma vorrei portare alla vostra attenzione le difficoltà di gestione che affrontano quotidianamente gli Atenei. [...] In parole povere, occorrono soldi. E tanti.
Credo --forse presuntuosamente-- di avere le idee abbastanza chiare su questi aspetti. Ho avuto la fortuna di lavorare per ~18 anni nel settore (tecnico) IT, di un Ateneo che *NON* offriva corsi di laurea in informatica, ne in ingegneria. Le difficolta' di gestione che Giorgio richiama, sono certamente evidenti... ma ai miei occhi appaiono totalmente scorrelate dalla necessita' di fare scelte tecnologiche o, peggio, di indirizzo politico/strategico (in ambito tecnologico). Sono pronto a scommettere che la decisione di migrare all'esterno il servizio di Posta è *sempre* dettata dal fatto che "gestire" è molto piu' complesso che "pagare". Specie se, pagando, si ritiene di acquisire anche una sorta di "tutela indiretta" dai problemi che potrebbero insorgere. Detto in altri termini: in assenza di un chiaro mandato "politico", la prima opzione di un dirigente pubblico sara' quella di affidare all'esterno quanti piu' servizi possibile.... perché cio' semplifichera' la sua vita (se trovate "bug" in questo mio ragionamento, per cortesia, fatemelo notare). Certamente il mantenimento di una infrastruttura di posta è qualcosa "di costoso". Ma la domanda vera è: "Ok. Ma quanto costa?" magari aggiungendo: "Che margini di manovra ho, nella modulazione di questi costi, rispetto --ad esempio-- ad un aumento minimo del rischio di indisponibilita'?" Alzi la mano qualcuno che è in grado di citare un, ripeto, "UN", documento che dettagli questo aspetto. A pensarci bene, il primo (e unico) documento di questo genere... è del "solito" Enrico Venuto - PoliTO - che al workshop GARR 2022 presento' una sua analisi comparativa "cloud vs. on-prem" [1] per un problema --relativamente "particolare"-- che lui dovette affrontare [e che discutemmo anche su questa lista [1b]]. Fermo restando la particolarita' del suo caso (che era storage-centrico)... il risultato fu agghiacciante: il cloud era PIU' COSTOSO di un fattore variabile da x83 a x165 (rif. slide 10 e 17) Perché di questa sua valutazione, non si discute? Perché non se ne legge, in giro? Perché non viene estesa in altri ambiti (es.: la Posta)? E perchè --viceversa-- il mantra ricorrente [che lo stesso Giorgio evidenzia] è: "...occorrono soldi. E tanti" (per l'on-prem)? La mia sensazione *FORTE* è che il tam-tam che da oltre 10 anni sentiamo a tutti i livelli, ossia --"Nessuno è capace di fare cose cosi' buone come i GAFAM. Cose non solo 'buone', ma anche gratis"--, è totalmente fuorviante. La verita' è che oggi (2023) una P.A. puo' acquistare un server con 24 core fisici, 256GB di RAM e 2 dischi SSD da 1TB, per 3.637,17€ [2]. E aggiungere altri 16 dischi SSD da 800GB costa altri 4.632 €. Per i non-tecnici, segnalo che --complessivamente-- parliamo di "ferro" in grado di gestire *TRANQUILLAMENTE* una infrastruttura di posta di un Ateneo "medio". Dunque, se decidiamo che Enrico Venuto non racconta sciocchezze e se si da per corretto quanto affermo nel paragrafo precedente, dobbiamo scartare il problema "costo": l'on-prem costa MENO (a latere, sul punto, segnalo anche un interessantissimo articolo recentemente pubblicato da... qualcuno che ha scelto di comprare 600K$ di server, per alleggerire la bolletta cloud che pesava 140/150K$ / mese [3]) Quindi, qual'e' il problema? Il problema è che per capire come configurare quei server, quanti comprarne, dove dislocarli [...dovesse mai essere che arrivi un ransomware....], quali software (open-source) metterci sopra, come far si che tutto il setup venga effettuato con "automatismi" (in grado di essere banalmente replicati su altre macchine, magari presso altri enti), come monitorarne il regolare funzionamento... come garantirne una "ragionevole" funzionalita'.... è una attivita' COMPLESSA. Una attivita' che ~30 anni fa veniva svolta da una figura specifica (il "tecnico universitario"), appositamente prevista per quello scopo... ma che, negli ultimi 20 anni... è stata completamente distrutta: quei tecnici che 30 anni fa erano giovani, ora stanno per andare in pensione; quelli che erano meno-giovani, ci sono gia' andati. Nel mezzo, ~20 anni di "abbandono politico" (scarsa formazione; scarsissima incentivazione; nessuna azione concreta volta a favorire l'allineamento delle competenze a quelle di mercato). Non è un caso che io stesso --per primo-- sia "figlio" di quella "nuova" politica (sono stato ~18 anni a fare il lavoro di un tecnico... a fianco di tecnici... ma senza essere uno strutturato). E quindi? Come se ne esce? La buona notizia è che non c'e' una prescrizione medica che ordina a *TUTTI* gli Atenei di allestire, al proprio interno, la migliore infrastruttura di posta possibile. E' perfettamente possibile che un piccolo manipolo di tecnici (pochissime unita'; meno di 10), si ritrovino attorno ad un tavolo (un GdL?) e tirino giu' un "disegno" dal quale, poi, tutti gli altri (....se lo vorranno) possano "prendere". Oggi esistono sia le condizioni economiche (perché i server e lo storage costano un tozzo di pane...), sia quelle software (la qualita' dei software open-source è a livelli mai raggiunti finora, ed in aumento... posto che li si sappia scegliere), sia quelle infrastrutturali (le tecnologie di automazione oggi disponibili consentono la creazione di interi "virtual-data-center" in tempi dell'ordine dei MINUTI... posto che le si conosca!) per arrivare *RAPIDAMENTE* ad un risultato del genere. Serve "solo" la volonta' (politica) di volerlo fare.
Se si è deciso di affidare ad un singolo soggetto la gestione amministrativa e finanziaria degli Atenei, e ad un solo provider la gestione della rete di ricerca, forse una analoga decisione potrebbe essere presa per i servizi mail ed IT in genere. Dopo aver fatto un bilancio tra i costi ed i benefici, anche appunto quelli di natura "strategica".
Rispetto a CINECA e GARR (...perché è di questi che parliamo), lascio sul tavolo tre elmenti di riflessione: * Cineca gestiva --fino a ~8/10 anni fa-- una infrastruttura di Posta che "vendeva" agli Atenei (1€/anno a casella) e gli Atenei, principalmente, utilizzavano per offrire una casella di posta ai propri studenti. Quel servizio era basato su infrastrutture disegnate con logiche ante-cloud (perché quando sono state "pensate", il cloud non era ancora cosi' "affidabile") e quindi era una spina nel fianco dello stesso Cineca (i costi del solo storage, con gli SLA che Cineca si era auto-inflitto, erano maggiori dei ricavi) . D'altro canto, tutti --ripeto: TUTTI-- i rappresentanti degli Enti consorziati, non mancavano occasione per segnalare l'esosità del servizio ("Ma Google ce le da gratis! Perché Cineca ce le fa pagare?"). Alla fine, l'ex-ex-Direttore... decidette di "staccare la spina". Il servizio fu dismesso; * GARR: non è un segreto che GARR abbia allestito, negli ultimi anni, infrastrutture di calcolo e storage particolarmente rilevanti: a GARR-Cloud (11.500 vCPU, 90TB di RAM e 16PB di storage sparsi su 5 datacenter) sono state affiancate altre risorse (INFRA: 10752 vCore, 84TB di RAM e 7.7 PB di storage sparsi su altri 5 datacenter) - fonte: Presentazione "Evoluzione del modello cloud GARR", di Massimo Carboni, al recente workshop GARR del 9/11/2023 [4]; * Cineca e GARR: non ho alcuna esitazione a definire entrambe come eccellenze italiane di cui andar fieri. Ma allo stesso tempo, sono pronto a scommettere che se giriamo nei corridoi degli Atenei e chiediamo: "Sai chi è Cineca? Sai cosa fa GARR? Sai chi vi partecipa? Sai come vengono finanziate?".... un buon 90% non riesce a rispondere a nessuna domanda, ed il restante 10% risponde (forse) solo alle prime due....
La questione dovrebbe essere affrontata dal punto di vista della politica industriale e della cultura tecnologica del Paese, insieme ad altri problemi come l'indipendenza sulle infrastrutture digitali.
Non ho strumenti per valutare la questione a questo livello di scala. La mia sensazione, pero', è che la tendenza è verso un costante peggioramento --se guardata in ambito Italia--. Personalmente credo che le uniche speranze possono arrivare solo per via Europea (a partire da Francia e Germania). Mi fermo qua, scusandomi per la prolissita'. Un caro saluto, e grazie a tutti per gli spunti di riflessione. Bye, DV [1] slide: https://www.eventi.garr.it/it/ws22/programma/materiali-conferenza-2019/699-i... stream: https://peertube.devol.it/w/rUs1KLWXZoDd5gWFRixr72 [1b] https://server-nexa.polito.it/pipermail/nexa/2022-November/024313.html [2] rif. convenzione CONSIP Tecnologie Server 4 - Lotto 4 - https://www.italware.it/convenzioni/ts4-lotto-4.htm [3] https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010 [4] rif. slide 4 di https://www.eventi.garr.it/it/documenti/workshop-garr-2023/presentazioni-12/... -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
Buongiorno, «Now you went from writing bad code to building bad infrastructure.» [3] Damiano grazie infinite per la segnalazione dell'articolo «The Big Cloud Exit FAQ» (coitato sotto): è bellissomo e assolutamente da leggere, attentamente, /tutto/. Damiano Verzulli <damiano@verzulli.it> writes: [...]
l'on-prem costa MENO
dipende da come si fanno i conti e RARAMENTE li ho visti fare bene, perché anche per fare i conti (fatti bene) ci vogliono le giuste competenze ...e quanto lo mettiamo al kilo il costo di essere GDPR compliant?!? :-O
(a latere, sul punto, segnalo anche un interessantissimo articolo recentemente pubblicato da... qualcuno che ha scelto di comprare 600K$ di server, per alleggerire la bolletta cloud che pesava 140/150K$ / mese [3])
la bolletta pare pesasse di più: nell'articolo «Our cloud spend in 2022» [1] c'è scritto che spendevano 266797$ al mese in servizi cloud. Parto dalla fine: è fondamentale comprendere che la differenza tra "on-premises" e "on cloud" NON è dove diavolo stanno fisicamente i server che costituiscono l'infrastruttura, ma chi installa e gestisce l'infrastruttura a partire dal SISTEMA OPERATIVO che serve a erogare i servizi informatici necessari, su su fino alle applicazioni, passando per i sistemi di "infrastructure as code". La stragrande maggioranza delle infrastrutture "on-premises" è ospitata in /colocation/ (e una forma di "on-premises" "sporca" è anche l'affitto del bare-metal). QUINDI, executive summary: il solo e unico problema in campo informatico della PA *e* del sistema imprenditoriale italiano è quello di avere adeguati "white glove" data centre professionali dove poter affittare rack/stanze/capannoni presso i quali far arrivare i propri server o in alternativa affittare direttamente il bare-metal... tutto il resto è noia :-D. C'è così tanto lavoro da fare di fronte a noi! Per fini archivistici, l'articolo che cita Damiano è questo: https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010 «The Big Cloud Exit FAQ» by David Heinemeier Hansson December 19, 2023 --8<---------------cut here---------------start------------->8--- Just over a year ago, we announced our intention to leave the cloud. We then shared our complete $3.2 million cloud budget for 2022, and the fact that we were going to build our own tooling rather than pay for overpriced enterprise service contracts. The mission was set! --8<---------------cut here---------------end--------------->8--- è un denso articolo, ricco di link che vale la pena seguire - tipo l'articolo che espone alcuni costi per il 2022 [1] - che segue l'articolo: https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0 «Why we're leaving the cloud» October 19, 2022 --8<---------------cut here---------------start------------->8--- Basecamp has had one foot in the cloud for well over a decade, and HEY has been running there exclusively since it was launched two years ago. We've run extensively in both Amazon's cloud and Google's cloud. We've run on bare virtual machines, we've run on Kubernetes. We've seen all the cloud has to offer, and tried most of it. It's finally time to conclude: Renting computers is (mostly) a bad deal for medium-sized companies like ours with stable growth. The savings promised in reduced complexity never materialized. So we're making our plans to leave. [...] Let's take HEY as an example. We're paying over half a million dollars per year for database (RDS) and search (ES) services from Amazon. Yes, when you're processing email for many tens of thousands of customers, there's a lot of data to analyze and store, but this still strikes me as rather absurd. Do you know how many insanely beefy servers you could purchase on a budget of half a million dollars per year? Now the argument always goes: Sure, but you have to manage these machines! The cloud is so much simpler! The savings will all be there in labor costs! Except no. Anyone who thinks running a major service like HEY or Basecamp in the cloud is "simple" has clearly never tried. Some things are simpler, others more complex, but on the whole, I've yet to hear of organizations at our scale being able to materially shrink their operations team, just because they moved to the cloud. It was a wonderful marketing coup, though. Sold with analogies like "well you don't run your own powerplant either, do you?" or "are infrastructure services really your core competency?". Then lathered up with a thick coat of NEW-NEW-NEW paint, and The Cloud has beamed so brightly only the luddites would consider running their own servers in its shadow. [...] The cloud is sold as computing on demand, which sounds futuristic and cool, and very much not like something as mundane as "renting computers", even though that's mostly what it is. --8<---------------cut here---------------end--------------->8--- Sottolineo che anche David Heinemeier Hansson, il 19 Ottobre 2022, ha usato una parafrasi del vecchio slogan "the cloud is just someone else's computer" :-D Relativamente ai costi, vale la pena sottolineare che per tenerli sotto controllo applicano un sistema integrato di controllo di gestione *e* hanno contratti a prezzi scontati, come scrivono in [1]: --8<---------------cut here---------------start------------->8--- Getting this massive spend down to just $3.2 million has taken a ton of work. The ops team runs a vigilant cost-inspection program, with monthly reporting and tracking, and we’ve entered into long-term agreements on Reserved Instances and committed usage, as part of a Private Pricing Agreement. This is a highly-optimized budget. --8<---------------cut here---------------end--------------->8--- Cigliegina sulla torta (ma questo è OVVIO per chi ha competenza sistemistica) è che la performance dei servizi eseguiti "on-premises" supera quella degli stessi eseguiti "on cloud" (a parità di risorse e ottimizzazione): https://world.hey.com/dhh/cloud-exit-pays-off-in-performance-too-4c53b697 «Cloud exit pays off in performance too» by David Heinemeier Hansson May 2, 2023 --8<---------------cut here---------------start------------->8--- The median request now runs in just 19ms, compared to 67ms before. The mean request in 95ms vs 138ms. The median query time has dropped in half (which adds up when you do a lot of queries per request!). Basecamp Classic was no slouch in the cloud before, but now 95% of all requests are below that magic 300ms cut-off. (But take these comparisons with a pound of salt. It's not exactly a clean-room, scientific test. Just a peak at the reality of leaving a fine-tuned cloud setup for a fully-owned hardware alternative.) --8<---------------cut here---------------end--------------->8---
Quindi, qual'e' il problema?
Il problema è che per capire come configurare quei server, quanti comprarne, dove dislocarli [...dovesse mai essere che arrivi un ransomware....], quali software (open-source) metterci sopra, come far si che tutto il setup venga effettuato con "automatismi" (in grado di essere banalmente replicati su altre macchine, magari presso altri enti), come monitorarne il regolare funzionamento... come garantirne una "ragionevole" funzionalita'.... è una attivita' COMPLESSA.
joke: è più difficile saper suonare bene un concerto per violino e oboe di Vivaldi :-D Complessa ma NON complicata, le complicazioni le inventano solo quelli che non hanno sufficiente competenza... o BARANO. [...] Saluti, 380° [1] https://dev.37signals.com/our-cloud-spend-in-2022/ P.S.: e qui soprassediamo sulle buzzwords tipo "serverless" [2] o "microservices" [3], perché entreremmo nel tecnico "spinto". [2] https://world.hey.com/dhh/don-t-be-fooled-by-serverless-776cd730 [3] https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-micr... -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Buongiorno Stefano, Stefano Maffulli <smaffulli@gmail.com> writes: [...]
IMO questo gap funzionale si può colmare solo ripensando ai concetti di "program" e "user" descritti nel Manifesto GNU... discorso complesso.
Qui non abbiamo per nulla fretta e abbiamo tutto il tempo per affrontare discorsi estremamemnte complessi... tipo la natura *culturale* e i motivi economici del percepito "gap funzionale". Per esempio: il rispetto del GDPR (nel software as a service) la ritieni una "feature" o chissenefrega? ...aggià, c'è sempre uno "shield" che mette le cose /magicamente/ a posto.
In breve, per riconquistare il diritto alla libertà digitale bisogna andare oltre gli slogan che hanno funzionato negli anni '90.
Considerato che sei Executive Director di Open Source Initiative (OSI) immagino che abbiate un piano per andare oltre quelli che tu definisci "vecchi slogan", magari con nuovi slogan? Saresti così gentile da riassumere le vostre proposte in tal senso e magari completarle con link a pagine di approfindimento su opensource.org? ...se no, a me questa pare la solita vecchia sterile polemica di OSI *contro* GNU e la FSF. Saluti, 380° [...] -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
On Fri, Jan 5, 2024 at 11:27 AM 380° <g380@biscuolo.net> wrote:
Per esempio: il rispetto del GDPR (nel software as a service) la ritieni una "feature" o chissenefrega? ...aggià, c'è sempre uno "shield" che mette le cose /magicamente/ a posto.
La domanda mi pare pretestuosa: il rispetto delle norme è "table stakes", scontato che esista. Le cose illegali non dovrebbero essere acquistabili, non penso sia il compito dell'acquirente finale di verificare l'aderenza alle norme del fornitore. Considerato che sei Executive Director di Open Source Initiative (OSI)
immagino che abbiate un piano per andare oltre quelli che tu definisci "vecchi slogan", magari con nuovi slogan?
Yes, abbiamo stimolato e stiamo coordinando da più di due anni una conversazione sul significato di Open Source nel contesto delle intelligenze artificiali. Tema che come previsto si sta dimostrando non banale. Dettagli e collegamenti alle bozze di definizioni e altro materiale prodotto è su https://opensource.org/deepdive/ Gli altri temi devono aspettare visto che come organizzazione abbiamo solo 3 persone in staff e una manciata di consulenti part time, non possiamo gestire altri processi complicati in parallelo. Mi dai l'occasione per ricordare a tutti di donare per aiutarci ad allargare il nostro staff :) https://opensource.org/donate.
...se no, a me questa pare la solita vecchia sterile polemica di OSI *contro* GNU e la FSF.
Nessuno ha parlato di FSF e non c'è nessuna polemica con FSF da parte mia. /stef
participants (14)
-
380° -
Andrea Trentini -
Angelo Raffaele Meo -
Antonio -
Damiano Verzulli -
Enrico Nardelli -
Giacomo Tesio -
Giorgio Ventre -
M. Fioretti -
Michele Pinassi -
Paolo Del Romano -
Roberto Resoli -
Stefano Maffulli -
Stefano Quintarelli