|
Next revision
|
Previous revision
|
docpublic:info:2010-01-19-cume-extserv [2010/01/19 21:29]
PROCACCIA created |
docpublic:info:2010-01-19-cume-extserv [2010/01/20 08:51] (current)
PROCACCIA |
| * 5) acces a l'info, rectification, opposition possible. | * 5) acces a l'info, rectification, opposition possible. |
| |
| il existe des modeles de contrat, exp guide info et liberté pour l'ens/rech, cf reseau supCIL (cnil et cpu) | il existe des modeles de contrat, exp [[http://www.cnil.fr/fileadmin/documents/Guides_pratiques/Guide_CNIL_AMUE_2009.pdf|guide info et liberté pour l'ens/rech]], cf [[https://listes.cru.fr/wiki/cil/|reseau supCIL]] (cnil et cpu). |
| Le reponsable est tj le president d'etablissement, en cas d'externalisation il le reste et d'autant plus qu'il n'a encore moins de visibilité sur l'implementation et les données, ce dernier peut exercer un droit de regard => visite du site, procedures ... | Le reponsable est tj le president d'etablissement, en cas d'externalisation il le reste et d'autant plus qu'il n'a encore moins de visibilité sur l'implementation et les données, ce dernier peut exercer un droit de regard => visite du site, procedures ... |
| |
| Livre interessent -> [[http://www.nicholasgcarr.com/bigswitch/|"Big switch" de Nicholas Carr]] | Livre interessent -> [[http://www.nicholasgcarr.com/bigswitch/|"Big switch" de Nicholas Carr]] |
| |
| société pratiquant l'hebergement de datacenter pour le grand public se retrouve sur le cloud => microsoft, google, amazon. | les sociétés pratiquants l'hebergement de datacenter pour le grand public se retrouvent sur le cloud => microsoft, google, amazon. |
| M$ datacenter de dublin (100 000 mchines 500 Millions de $, 26 millions de users liveMessenger en FR), autre Datacenter a Amsterdam pour l'europe. | Microsoft datacenter de dublin (100 000 machines 500 Millions de $, 26 millions de users liveMessenger en FR), autre Datacenter a Amsterdam pour l'europe. |
| evolution des types de datacenter => colocation/ serveur => proprio/Rack(baie) quincy = 11 terrains de foot => classe Container/container, 4eme generation = containers (de bateau !) standardisés (froid, electric) stockés en "plein air" , deposés par grue dans un lieu surveillé. | |
| | Evolution des types de datacenter => colocation/ serveur => proprio/Rack(baie) quincy = 11 terrains de foot => classe Container/container, 4eme generation = containers (de bateau !) standardisés (froid, electric) stockés en "plein air" , deposés par grue dans un lieu surveillé. |
| | |
| hotmail des 1996 (+450M users), msn(97), windows update(98), live messenger(99), bing(99), Xbox live(2001), LiveMeeting (2003), M$ online service (2004) , maintenant Office 2010 | hotmail des 1996 (+450M users), msn(97), windows update(98), live messenger(99), bing(99), Xbox live(2001), LiveMeeting (2003), M$ online service (2004) , maintenant Office 2010 |
| |
| | |
| |
| exchange(mail,calendrier => outlookLive(webmail)), espace de stokage en ligne (SkyDrive), synchro file en ligne(liveMesh), messagerie instantanée avec messenger et partage de site internet, Office Web Apps(OWA) editer en ligne un doc office quand on ne l'a pas localement, sauvegarde directe en ligne. | exchange(mail,calendrier => outlookLive(webmail)), espace de stokage en ligne (SkyDrive), synchro file en ligne(liveMesh), messagerie instantanée avec messenger et partage de site internet, Office Web Apps(OWA) => editer en ligne un doc office quand on ne l'a pas localement, sauvegarde directe en ligne. |
| base des identités reste sur l'infra d'etablissement, on les push sur live@edu afin de creer les BAL (winRM/GALSync), Exchange web services => API pour pusher des info en ligne vers un service ENT, celendrier existant . | |
| | La base des identités reste sur l'infra d'etablissement, on les push sur live@edu afin de creer les BAL (winRM/GALSync), |
| | "Exchange web services" => API pour pusher des info en ligne vers un service ENT, celendrier existant afin de synchroniser les outils locaux et ceux en ligne. |
| Administration sous forme d'interface Web (exchange control panel) ou via Windows PowerShell creation/administration a distance en shell. | Administration sous forme d'interface Web (exchange control panel) ou via Windows PowerShell creation/administration a distance en shell. |
| Mars 2005 = hotmail service grd public, depuis mars 2009 live@edu = exchange comme support de messagerie | |
| a venir => shapoint online, ADFSv2 <=> interoperabilité shibboleth (SAML!) | debut de live@edu en Mars 2005 = hotmail service grd public, depuis mars 2009 live@edu = exchange comme support de messagerie |
| | a venir => sharepoint online, ADFSv2 <=> interoperabilité shibboleth (SAML!) |
| pour tester: http://www.microsoft.com/liveatedu | pour tester: http://www.microsoft.com/liveatedu |
| gratuit ! => car cela permet souvent de mettre en test reel un produit, exp echange2010 sortie en nov2009, pourtant en prod dès printemps2009 sur live@edu avec 4Millions de users. | |
| |
| === Paris Descartes live@edu === | Service **gratuit** ! => car cela permet souvent de mettre en test reel un produit, exp echange2010 sortie en nov2009, pourtant en prod dès printemps2009 sur live@edu avec 4Millions de users. |
| | |
| | ==== Paris Descartes live@edu ==== |
| |
| (Patrick.De Carne Disi ) | (Patrick.De Carne Disi ) |
| |
| externalisation de 40K boite au lettre (BAL) sur live@edu | externalisation de 40K boites au lettre (BAL) sur live@edu |
| 2 IG pour gerer 45K BAL de 500Mo, clients lourds (imap/pop) sastisfaisant, en revanche webmail depassé avec IMP. Constat que 20% des BAL sont forwardés vers des BAL en ligne. | 2 IG pour gerer 45K BAL de 500Mo, clients lourds (imap/pop) sastisfaisant, en revanche webmail depassé avec IMP. Constat que 20% des BAL sont forwardés vers des BAL en ligne. |
| Des services deja mutualisé => RAP, podcast, CentrexIP, SMS ... | |
| Experimentation live@edu sur un nouveau nom de domaine pasrisdescartes.eu -> 40K BAL etudiantes. | Des services deja mutualisés => RAP, podcast, CentrexIP, SMS ... |
| Techniques: enregistrement sur live@edu d'un compte d'admin, un domain (+ 2eme est testlive.parisdescartes.eu), recup kit SSO (services RPS), un certificat X509 live@edu, un serveur 2008, externalisation d'un annuaire minimal: uid,mail,sn | |
| | Experimentation live@edu sur un nouveau nom de domaine pairsdescartes.eu -> 40K BAL etudiantes. |
| | |
| | === Techniques: === |
| | * enregistrement sur live@edu d'un compte d'admin, un domain (+ 2eme est tetlive.parisdescartes.eu), |
| | * recup kit SSO (services RPS), |
| | * un certificat X509 live@edu, |
| | * un serveur 2008, |
| | * externalisation d'un annuaire minimal: uid,mail,sn |
| un script powershell recupere ces 3 attributs depuis l'annuaire d'etablissement et genere un CSV à destination de live@edu de type: | un script powershell recupere ces 3 attributs depuis l'annuaire d'etablissement et genere un CSV à destination de live@edu de type: |
| | |
| action;type;name;email;password;displayname;forceUpdatePassword | action;type;name;email;password;displayname;forceUpdatePassword |
| | |
| Realisation en une passe de 24H pour la création de 40K comptes. | Realisation en une passe de 24H pour la création de 40K comptes. |
| Integration de ce service live@adu dans l'ENT esup via un onglet/icone. en cliquant dessus on part sur un IIS casifié (via ISAPI), qui fournis un ASP qui recupere le remote_user via CAS et enfin redirection avec certif x509 vers live@edu. Ainsi l'etudiant n'a meme pas besoin de connaitre son password live@edu, le SSO CAS suffit. En revanche si necessité d'acces avec client lourd vers live@edu => necessité de le connaitre !. | |
| Attention petit pb avec IE et non acceptation dans un Iframe d'un cookie ne venant pas du "parent" => solution => ouverture de live@edu dans une nouvelle fenetre plutot qu'une Iframe. DE meme pas de Single Sign Out . | Integration de ce service live@edu dans l'ENT esup via un onglet/icone. en cliquant dessus on part sur un IIS casifié (via ISAPI), qui fournis un ASP qui recupere le remote_user via CAS et enfin redirection avec certif x509 vers live@edu. Ainsi l'etudiant n'a meme pas besoin de connaitre son password live@edu, le SSO CAS suffit. En revanche si necessité d'acces avec client lourd vers live@edu => necessité de le connaitre !. |
| | |
| | Attention petit pb avec IE et non acceptation dans un Iframe d'un cookie ne venant pas du "parent" => solution => ouverture de live@edu dans une nouvelle fenetre plutot qu'une Iframe. |
| | De meme pas de Single Sign Out . |
| pcc at parisdescartes.fr | pcc at parisdescartes.fr |
| ow at parisdescartes.fr | ow at parisdescartes.fr |
| |
| Sous traitance et externalisation deja existante, pas d'opposition de principe | Sous traitance et externalisation deja existante, pas d'opposition de principe |
| | |
| inria tres decentralisé, 8 centres 3500 comptes, strategie de mutualisation des infra et collaboratif. | inria tres decentralisé, 8 centres 3500 comptes, strategie de mutualisation des infra et collaboratif. |
| constat la messagerie es utilisée comme outils collaboratif. | |
| | constat la messagerie est utilisée comme outils collaboratif. |
| anti-spam et agenda deja centralisé, mais parfois basé sur des solutions qui n'evoluent plus, developpement tres important des smartphones, developpement du nomadisme. | anti-spam et agenda deja centralisé, mais parfois basé sur des solutions qui n'evoluent plus, developpement tres important des smartphones, developpement du nomadisme. |
| constat: presence d'offres SAAS allechantes, gratuites !, fuites informelles d'utilisateurs vers ses services | |
| le besoin n'est plus simplement messagerie mais s'elargie et s'oriente vers des suites collaboratives. | constat: presence d'offres SAAS allechantes, gratuites !, fuites informelles d'utilisateurs vers ces services |
| | |
| | Le besoin n'est plus simplement messagerie mais s'elargie et s'oriente vers des suites collaboratives. |
| decorreler le choix d'une plateforme et de sa mise en oeuvre . | decorreler le choix d'une plateforme et de sa mise en oeuvre . |
| googleApps a été etudié mais rejeté car: 1) cadre contractuel US (voire Californien), 2) pas de garantie de confidentialité des données, 3) reprise de l'existant (2 a 3 To de données inria !) et pb de reversibilité. | |
| | googleApps a été etudié mais rejeté car: |
| | * 1) cadre contractuel US (voire Californien), |
| | * 2) pas de garantie de confidentialité des données, |
| | * 3) reprise de l'existant (2 a 3 To de données inria !) et pb de reversibilité. |
| consultation => short liste: IBM Lotusdomino/notes, Microsoft exchange, Oracle beehive, Zimbra collaborative Suite | consultation => short liste: IBM Lotusdomino/notes, Microsoft exchange, Oracle beehive, Zimbra collaborative Suite |
| 2 solutions se sont demarqués, M$ exhange2010 et zimbra sur ce perimetre messagerie et agenda , choix final Zimbra => support des standards ouverts (calDAV,XMPP), integration existant (linux,ldap,postfix ...), support protocoles M$ (MAPI,ActiveSync pour smartphone). Mais cela ne couvre pas tous les besoins, partage de docs (alfresco deja deployé). | |
| | 2 solutions ce sont demarquées, Microsoft exhange2010 et zimbra sur ce perimetre messagerie et agenda , choix final Zimbra => support des standards ouverts (calDAV,XMPP), integration existant (linux,ldap,postfix ...), support protocoles Microsoft (MAPI,ActiveSync pour smartphone). Mais cela ne couvre pas tous les besoins, partage de docs (alfresco deja deployé). |
| Choix d'une exploitation en interne. | Choix d'une exploitation en interne. |
| Mutualiser est le maitre mot, rapellons nous des debut de Renater, on disait a l'epoque que les operateurs privés etaient là et rendraient le service, il n'empeche que la mutualisation operée via Renater a été un franc succés. Attention aussi ici où la question est encore plus complexe que le reseau => les données pose la question fondamentale de la reversabilité !. | |
| | Mutualiser est le maitre mot, rapellons nous des les debuts de Renater, on disait a l'epoque que les operateurs privés etaient là et rendraient le service, il n'empeche que la mutualisation operée via Renater a été un franc succés. Attention aussi ici où la question est encore plus complexe que le reseau => les données posent la question fondamentale de la reversabilité !. |
| |
