Administrateur reseaux et syst=E8mes sur les produits Microsoft
Je travaille =E0 ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'exp=E9rience (probl=E8me ?) sur
l'impl=E9mentation de profil errant (=3Ditin=E9rant) sur les postes client
Windows 2000, et XP, avec un serveur Samba sur Debian.
Et savoir si il y a =E9galement cette possibilit=E9 sur les postes client
Linux.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Bernat
OoO En ce début de soirée du samedi 20 janvier 2007, vers 21:56, "theghost" disait:
Administrateur reseaux et systèmes sur les produits Microsoft Je travaille à ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'expérience (problème ?) sur l'implémentation de profil errant (=itinérant) sur les postes client Windows 2000, et XP, avec un serveur Samba sur Debian. Et savoir si il y a également cette possibilité sur les postes client Linux.
Habituellement, c'est NFS + LDAP, mais PAM supporte aussi Samba pour l'authentification et couplé à l'automounter, cela devrait donc aussi fonctionner avec des montages Samba. À noter que ce n'est pas réellement un profil itinérant : il n'y a pas copie du profil sur le poste local, mais utilisation du profil via le réseau. Sous Linux, il est possible d'être connecté depuis plusieurs stations à la fois. -- printk("What? oldfid != cii->c_fid. Call 911.n"); 2.4.3 linux/fs/coda/cnode.c
OoO En ce début de soirée du samedi 20 janvier 2007, vers 21:56,
"theghost" <theghost@ifrance.com> disait:
Administrateur reseaux et systèmes sur les produits Microsoft
Je travaille à ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'expérience (problème ?) sur
l'implémentation de profil errant (=itinérant) sur les postes client
Windows 2000, et XP, avec un serveur Samba sur Debian.
Et savoir si il y a également cette possibilité sur les postes client
Linux.
Habituellement, c'est NFS + LDAP, mais PAM supporte aussi Samba pour
l'authentification et couplé à l'automounter, cela devrait donc aussi
fonctionner avec des montages Samba. À noter que ce n'est pas
réellement un profil itinérant : il n'y a pas copie du profil sur le
poste local, mais utilisation du profil via le réseau. Sous Linux, il
est possible d'être connecté depuis plusieurs stations à la fois.
--
printk("What? oldfid != cii->c_fid. Call 911.n");
2.4.3 linux/fs/coda/cnode.c
OoO En ce début de soirée du samedi 20 janvier 2007, vers 21:56, "theghost" disait:
Administrateur reseaux et systèmes sur les produits Microsoft Je travaille à ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'expérience (problème ?) sur l'implémentation de profil errant (=itinérant) sur les postes client Windows 2000, et XP, avec un serveur Samba sur Debian. Et savoir si il y a également cette possibilité sur les postes client Linux.
Habituellement, c'est NFS + LDAP, mais PAM supporte aussi Samba pour l'authentification et couplé à l'automounter, cela devrait donc aussi fonctionner avec des montages Samba. À noter que ce n'est pas réellement un profil itinérant : il n'y a pas copie du profil sur le poste local, mais utilisation du profil via le réseau. Sous Linux, il est possible d'être connecté depuis plusieurs stations à la fois. -- printk("What? oldfid != cii->c_fid. Call 911.n"); 2.4.3 linux/fs/coda/cnode.c
JKB
Le 20-01-2007, à propos de Demande de retour d'expérience Profil Errant, theghost écrivait dans fr.comp.os.linux.configuration :
Bonsoir,
Administrateur reseaux et systèmes sur les produits Microsoft Je travaille à ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'expérience (problème ?) sur l'implémentation de profil errant (=itinérant) sur les postes client Windows 2000, et XP, avec un serveur Samba sur Debian.
De temps en temps, un Windows pète un câble et l'instinct grégaire des Windowzeries fait qu'il faut se prendre la tête huit jours pour reconfigurer le truc. Ça m'est encore arrivé cette semaine alors qu'aucune conf n'avait changée (XP s'est mis spontanément à ne plus fonctionner en l'absence d'ACL, alors qu'il le faisait sans problème depuis dix-huit mois...). De plus, il faut souvent contourner les dysfonctionnements^Wfeatures de Windows côté samba pour avoir un truc opérationnel (avec des oplocks sévères même quelquefois lorsque excel ou word [que ces deux-là] décide d'enregistrer un fichier en lecture seule sur le partage réseau. Le plus amusant, c'est que deux machines identiques avec les mêmes version de XP et de MS Office ne se comportent pas de la même façon !).
Bref, les profils itinérants sont des sources d'emmerdes incomparables (si un poste client merdoit à l'ouverture de la session, il est capable d'écraser à la fermeture le profil sur le serveur). Donc : règle primordiale, ne pas utiliser le profil (et donc bureau/mes documents et autres) pour mettre des fichiers sensibles, on n'est jamais à l'abri d'une perversité de la microsofterie. Plutôt utiliser un partage réseau où les fichiers sont directement copiés sur le serveur et non sur le profil local qui va répercuter les modifications lors de la fermeture de la session.
Moyennant ça, on arrive à des trucs utilisables (enfin pour des windoziens de base, parce que pour les gens des réseaux...).
Et savoir si il y a également cette possibilité sur les postes client Linux.
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la gestion des droits est limpide et que cela évite un chargement du profil sur la machine distante). Le profil itinérant n'est là que parce que Windows est infoutu d'utiliser un réseau normalement, c'est une verrue qui lui permet de continuer à travailler en local avec bidouillage de la base de registre à l'ouverture de la session, ce qui peut foutre la pagaille sur des postes qui ne sont pas installés de la même façon que les autres...
Il y a aussi un autre truc foireux dans l'API windows qui fait que celui-ci est _capable_ d'ouvrir en lecture un fichier de plus de 2 Go, mais dès qu'il essaye d'écrire dedans, il le fait exploser sans message d'erreur (enfin, la version 32 bits du bouzin). Idem pour la gestion des quota (il y a du boulot qui est fait dessus actuellement par l'équipe samba) où XP est persuadé qu'il peut écrire dans un partage réseau même si l'utilisateur est overquota parce qu'il reste de la place sur le disque.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 20-01-2007, à propos de
Demande de retour d'expérience Profil Errant,
theghost écrivait dans fr.comp.os.linux.configuration :
Bonsoir,
Administrateur reseaux et systèmes sur les produits Microsoft
Je travaille à ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'expérience (problème ?) sur
l'implémentation de profil errant (=itinérant) sur les postes client
Windows 2000, et XP, avec un serveur Samba sur Debian.
De temps en temps, un Windows pète un câble et l'instinct grégaire
des Windowzeries fait qu'il faut se prendre la tête huit jours pour
reconfigurer le truc. Ça m'est encore arrivé cette semaine alors
qu'aucune conf n'avait changée (XP s'est mis spontanément à ne plus
fonctionner en l'absence d'ACL, alors qu'il le faisait sans problème
depuis dix-huit mois...). De plus, il faut souvent contourner
les dysfonctionnements^Wfeatures de Windows côté samba pour avoir un
truc opérationnel (avec des oplocks sévères même quelquefois lorsque
excel ou word [que ces deux-là] décide d'enregistrer un fichier en
lecture seule sur le partage réseau. Le plus amusant, c'est que deux
machines identiques avec les mêmes version de XP et de MS Office ne
se comportent pas de la même façon !).
Bref, les profils itinérants sont des sources d'emmerdes
incomparables (si un poste client merdoit à l'ouverture de la
session, il est capable d'écraser à la fermeture le profil sur le
serveur). Donc : règle primordiale, ne pas utiliser le profil (et
donc bureau/mes documents et autres) pour mettre des fichiers
sensibles, on n'est jamais à l'abri d'une perversité de la
microsofterie. Plutôt utiliser un partage réseau où les fichiers
sont directement copiés sur le serveur et non sur le profil local
qui va répercuter les modifications lors de la fermeture de la
session.
Moyennant ça, on arrive à des trucs utilisables (enfin pour des
windoziens de base, parce que pour les gens des réseaux...).
Et savoir si il y a également cette possibilité sur les postes client
Linux.
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la
gestion des droits est limpide et que cela évite un chargement du
profil sur la machine distante). Le profil itinérant n'est là que
parce que Windows est infoutu d'utiliser un réseau normalement,
c'est une verrue qui lui permet de continuer à travailler en local
avec bidouillage de la base de registre à l'ouverture de la session,
ce qui peut foutre la pagaille sur des postes qui ne sont pas
installés de la même façon que les autres...
Il y a aussi un autre truc foireux dans l'API windows qui fait que
celui-ci est _capable_ d'ouvrir en lecture un fichier de plus de 2
Go, mais dès qu'il essaye d'écrire dedans, il le fait exploser sans
message d'erreur (enfin, la version 32 bits du bouzin). Idem pour la
gestion des quota (il y a du boulot qui est fait dessus actuellement
par l'équipe samba) où XP est persuadé qu'il peut écrire dans un
partage réseau même si l'utilisateur est overquota parce qu'il reste
de la place sur le disque.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 20-01-2007, à propos de Demande de retour d'expérience Profil Errant, theghost écrivait dans fr.comp.os.linux.configuration :
Bonsoir,
Administrateur reseaux et systèmes sur les produits Microsoft Je travaille à ma reconversion sur Linux GNU et Debian en particulier.
Je souhaite avoir un retour d'expérience (problème ?) sur l'implémentation de profil errant (=itinérant) sur les postes client Windows 2000, et XP, avec un serveur Samba sur Debian.
De temps en temps, un Windows pète un câble et l'instinct grégaire des Windowzeries fait qu'il faut se prendre la tête huit jours pour reconfigurer le truc. Ça m'est encore arrivé cette semaine alors qu'aucune conf n'avait changée (XP s'est mis spontanément à ne plus fonctionner en l'absence d'ACL, alors qu'il le faisait sans problème depuis dix-huit mois...). De plus, il faut souvent contourner les dysfonctionnements^Wfeatures de Windows côté samba pour avoir un truc opérationnel (avec des oplocks sévères même quelquefois lorsque excel ou word [que ces deux-là] décide d'enregistrer un fichier en lecture seule sur le partage réseau. Le plus amusant, c'est que deux machines identiques avec les mêmes version de XP et de MS Office ne se comportent pas de la même façon !).
Bref, les profils itinérants sont des sources d'emmerdes incomparables (si un poste client merdoit à l'ouverture de la session, il est capable d'écraser à la fermeture le profil sur le serveur). Donc : règle primordiale, ne pas utiliser le profil (et donc bureau/mes documents et autres) pour mettre des fichiers sensibles, on n'est jamais à l'abri d'une perversité de la microsofterie. Plutôt utiliser un partage réseau où les fichiers sont directement copiés sur le serveur et non sur le profil local qui va répercuter les modifications lors de la fermeture de la session.
Moyennant ça, on arrive à des trucs utilisables (enfin pour des windoziens de base, parce que pour les gens des réseaux...).
Et savoir si il y a également cette possibilité sur les postes client Linux.
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la gestion des droits est limpide et que cela évite un chargement du profil sur la machine distante). Le profil itinérant n'est là que parce que Windows est infoutu d'utiliser un réseau normalement, c'est une verrue qui lui permet de continuer à travailler en local avec bidouillage de la base de registre à l'ouverture de la session, ce qui peut foutre la pagaille sur des postes qui ne sont pas installés de la même façon que les autres...
Il y a aussi un autre truc foireux dans l'API windows qui fait que celui-ci est _capable_ d'ouvrir en lecture un fichier de plus de 2 Go, mais dès qu'il essaye d'écrire dedans, il le fait exploser sans message d'erreur (enfin, la version 32 bits du bouzin). Idem pour la gestion des quota (il y a du boulot qui est fait dessus actuellement par l'équipe samba) où XP est persuadé qu'il peut écrire dans un partage réseau même si l'utilisateur est overquota parce qu'il reste de la place sur le disque.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Emmanuel Florac
Le Sat, 20 Jan 2007 21:27:07 +0000, JKB a écrit :
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la gestion des droits est limpide et que cela évite un chargement du profil sur la machine distante).
LDAP est quand même plus sophistiqué et plus sûr que NIS (ypcat passwd anyone?)
-- Three may keep a secret, if two of them are dead. Benjamin Franklin.
Le Sat, 20 Jan 2007 21:27:07 +0000, JKB a écrit :
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la
gestion des droits est limpide et que cela évite un chargement du profil
sur la machine distante).
LDAP est quand même plus sophistiqué et plus sûr que NIS (ypcat passwd
anyone?)
--
Three may keep a secret, if two of them are dead.
Benjamin Franklin.
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la gestion des droits est limpide et que cela évite un chargement du profil sur la machine distante).
LDAP est quand même plus sophistiqué et plus sûr que NIS (ypcat passwd anyone?)
-- Three may keep a secret, if two of them are dead. Benjamin Franklin.
JKB
Le 21-01-2007, à propos de Re: Demande de retour d'expérience Profil Errant, Emmanuel Florac écrivait dans fr.comp.os.linux.configuration :
Le Sat, 20 Jan 2007 21:27:07 +0000, JKB a écrit :
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la gestion des droits est limpide et que cela évite un chargement du profil sur la machine distante).
LDAP est quand même plus sophistiqué et plus sûr que NIS (ypcat passwd anyone?)
J'utilise NIS avec des shadow password (et md5 lorsqu'il n'y a pas de Solaris à mettre dans le coup) sans aucun problème. Et personnellement, je n'ai jamais compris l'intérêt du LDAP. Par ailleurs, les montages nfs sont faits en mappant les utilisateurs.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 21-01-2007, à propos de
Re: Demande de retour d'expérience Profil Errant,
Emmanuel Florac écrivait dans fr.comp.os.linux.configuration :
Le Sat, 20 Jan 2007 21:27:07 +0000, JKB a écrit :
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la
gestion des droits est limpide et que cela évite un chargement du profil
sur la machine distante).
LDAP est quand même plus sophistiqué et plus sûr que NIS (ypcat passwd
anyone?)
J'utilise NIS avec des shadow password (et md5 lorsqu'il n'y a pas
de Solaris à mettre dans le coup) sans aucun problème. Et
personnellement, je n'ai jamais compris l'intérêt du LDAP. Par
ailleurs, les montages nfs sont faits en mappant les utilisateurs.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 21-01-2007, à propos de Re: Demande de retour d'expérience Profil Errant, Emmanuel Florac écrivait dans fr.comp.os.linux.configuration :
Le Sat, 20 Jan 2007 21:27:07 +0000, JKB a écrit :
NIS + NFS fonctionnent largement mieux (ne serait-ce que parce que la gestion des droits est limpide et que cela évite un chargement du profil sur la machine distante).
LDAP est quand même plus sophistiqué et plus sûr que NIS (ypcat passwd anyone?)
J'utilise NIS avec des shadow password (et md5 lorsqu'il n'y a pas de Solaris à mettre dans le coup) sans aucun problème. Et personnellement, je n'ai jamais compris l'intérêt du LDAP. Par ailleurs, les montages nfs sont faits en mappant les utilisateurs.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
olaf
Et personnellement, je n'ai jamais compris l'intérêt du LDAP.
Pour s'authentifier dans d'autres applis.
Et personnellement, je n'ai jamais compris l'intérêt du LDAP.
Et personnellement, je n'ai jamais compris l'intérêt du LDAP.
Pour s'authentifier dans d'autres applis.
theghost
Et personnellement, je n'ai jamais compris l'intérêt du LDAP.
Pour s'authentifier dans d'autres applis.
Bon ben le problème s'est bien Windows...(Sur NT4 ce fut un vrai cauchemard et bon nombre de mes confreres avaient renoncé... depuis en environnement Windows 2000, XP, le profile errant n'est plus utilisé, souvenir de trop grosse galere).
Et pour des clients Linux (Ubuntu...) exist-il un équivalence au profil errant ?
Et personnellement, je n'ai jamais compris l'intérêt du LDAP.
Pour s'authentifier dans d'autres applis.
Bon ben le problème s'est bien Windows...(Sur NT4 ce fut un vrai
cauchemard et bon nombre de mes confreres avaient renoncé... depuis en
environnement Windows 2000, XP, le profile errant n'est plus utilisé,
souvenir de trop grosse galere).
Et pour des clients Linux (Ubuntu...) exist-il un équivalence au
profil errant ?
Et personnellement, je n'ai jamais compris l'intérêt du LDAP.
Pour s'authentifier dans d'autres applis.
Bon ben le problème s'est bien Windows...(Sur NT4 ce fut un vrai cauchemard et bon nombre de mes confreres avaient renoncé... depuis en environnement Windows 2000, XP, le profile errant n'est plus utilisé, souvenir de trop grosse galere).
Et pour des clients Linux (Ubuntu...) exist-il un équivalence au profil errant ?