Re: [Admin-ml] Avis sur soft de déploiement

François SCHOSSIG fs.nospam1 at laposte.net
Sam 3 Juil 12:40:04 CEST 2010


Le 2 juil. 2010 à 22:35, François SCHOSSIG a écrit :
> 
>>> Personnellement j'ai les réserves suivantes :
>>> - dans la construction du SI autour de plusieurs application est-ce qu'on ne perd pas le contrôle des mots de passes uniques, et quid d'une gestion SSO, voire kerberos ?
>> La version payante ou la version gratuite pour l'enseignement organisent les comptes à partir des données d'une base LDAP. Le contrôle des mots de passe uniques ne pose donc aucun problème. Ils parlent même d'API d'authentification unique.
>> http://www.google.com/apps/intl/fr/business/features.html
> 
> Sinon 40 euros annuels par compte. Bon... moi ça me fait 120Keurs...  soit le prix d'un bon serveur et de sa baie de stockage :) par an :) Bon ok c'est gratuit pour les facs.
Nous nous contente de la version gratuite à 50 comptes... :-)
Mais l'avantage c'est qu'il n'y a plus rien du tout à faire sur le mail/calendrier.

>>> - il existe un texte européen repris en France qui pose des conditions précises à l'externatlisation de données personnelles hors Europe.
>>> - quid de la possibilité d'une action en justice : si il faut une commission rogatoire USA pour accéder au contenu d'une boite au lettre on est... mal barré. On a donc une quasi immunité légale pour les usager sur le mail non ?
>> Langue au chat !
> 
> N'est-ce pas :) En fait la question ici est intéressante : la bonne gestion consiste non pas tant à faire marcher les choses qu'à prévoir comment gérer quand ça marchera moins bien et à prévenir les accidents. 
Bah, (Mail-IMAP + iCal + Carnet d'adresse + iChat avec archives de chat en clients Google) + un TimeMachine et les données sont "protégées" puisque toutes dupliquées sur le poste local. Cela permet même de revenir en très peu de temps (50 comptes...) sur un serveur local que l'on garderait au chaud. Il n'est pas nécessaire de renvoyer les 7 Go de données par compte sur le serveur, mais à la limite les utilisateurs font ce qu'il veulent en IMAP.
Le risque est minime, toujours dans notre cadre : 50 comptes.
De l'autre côté Google fait aussi ses sauvegardes...

>>> Après je dirais, la perte d'un savoir faire technologique, mais il parait que c'est pas à la mode :) :) :)
>> Dans ce cas, il n'est pas interdit de se garder un p'tit serveur dans un coin pour garder la main sur les évolutions technologiques autour du mail, DNS... On peut envisager de consacrer 10 % du temps gagné sur l'administration d'un service mail à la conservation d'une compétence. On reste gagnant et on évite les problèmes informatiques situés entre la chaise et le clavier...
>> :-)
> Heu.. es tu sûr que tu fais de l'administration système :) ? Parce que bon je n'ai jamais eu 5 minutes pour maqueter quelque chose qui n'avait pas d'utilité, de plus il y a une différence fondamentale de boulot entre faire son petit truc dans son coin sur sa machine et avoir un système vraiment opérationnel : les dépendances aux autres systèmes complexifient terriblement la chose. 
> Et bon...regarde les pb qu'ils ont pour fabriquer les EPR : une compétence qui n'est pas mise en pratique industriellement se perd toujours.
Bien sûr que je n'ai pas le temps de ça non plus (même si notre serveur de messagerie d'avant le passage chez Google est toujours au chaud).
Si j'ai tout mis chez Google, c'est que l'administration des autres machines m'en demandait plus !
Une fois un tour du mail fait, j'ai préféré développer de nouvelles compétences (Typo3, Asterisk...) :-)

J'avoue aussi que j'en avais assez d'expliquer aux utilisateurs que c'était normal qu'un petit film (d'une centaine de mégas) avait du mal à passer par mail et que ce n'était vraiment pas de la faute de notre serveur...
Ou aux administrateurs Windows de configurer convenablement leur DNS pour qu'ils puissent recevoir des messages de chez nous...
Le pire a tout de même été un italien m'expliquant que notre serveur devait forcément avoir un problème puisqu'il pouvait nous envoyer un message à partir de Yahoo, mais pas du compte de sa région. Leur serveur régional ne pouvait pas être cause, puisque c'était un serveur Microsoft : c'était donc forcément de notre faute... Il n'a jamais compris que le nom de sa machine posait problème « serveur_public.local ».
:-)

Bonne fin de semaine !
--
F. SCHOSSIG, ICT Manager
Assemblée des Régions d'Europe
http://www.aer.eu



Plus d'informations sur la liste de diffusion Admin-ml