J'ai installé une nouvelle distro (ubuntu 6.10)...
Je me suis aperçu que pour que slrn (entre autres) puisse gérer l'utf-8,
je devais faire le ménage dans mon home, sans doute à cause des trop
nombreux et trop vieux fichiers de conf de mes applications.
Je me suis rapidement aperçu aussi que le plus simple était de créer un
nouvel user "ugo" et de ne copier que les seuls fichiers «normaux» de
/home/hugo (l'ancien home) vers /home/ugo (le nouveau home).
Mais hugo avait l'ID 1000 alors que ugo a l'ID 1002 et j'entrevois déjà
les «permission denied» que je vais prendre dans les ratiches quand je
vais vouloir travailler sur /home/ugo monté par NFS sur une autre
machine. (Sur toutes mes machines mon user "hugo" a l'ID 1000).
Suffit-il de supprimer du fichier /etc/passwd la ligne
hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash
puis de changer le 1002 en 1000 sur la ligne
ugo:x:1002:1002::/home/ugo:/bin/bash
pour que tout rentre dans l'ordre ?
Y aurait-il une autre solution plus élégante ?
A supposer que ce genre de bidouille soit nécessaire sur un système
gérant plusieurs dizaines d'utilisateurs, auquel cas cela deviendrait
sans doute vite inextricable, la solution s'appelle-t-elle LDAP, YP ou
NIS et autres joyeusetés ? (auquel cas, forget it (moi petit lameer ;-))
Est-ce que SaMBa est plus simple ?
Merci de vos avis
--
Les Russes et les Américains dépensent des fortunes pour détruire leurs
vieilles armes nucléaires dans le cadre des accords START, alors qu'il serait
tellement plus simple de les balancer sur Redmond. Étonnant, non ? -+- MA -+-
Hugo (né il y a 1 354 235 642 secondes)
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
Doug713705
Le jeudi 29 mars 2007 23:42, Hugolino s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Suffit-il de supprimer du fichier /etc/passwd la ligne hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash puis de changer le 1002 en 1000 sur la ligne ugo:x:1002:1002::/home/ugo:/bin/bash pour que tout rentre dans l'ordre ?
Ca peut se tenter sans trop de risque.
Pour ma part j'aurais plutôt supprimer l'utilisateur hugo et créer ugo avec l'ID 1000. (man userdel / man useradd)
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le jeudi 29 mars 2007 23:42, Hugolino s'est exprimé de la sorte sur
fr.comp.os.linux.configuration :
Suffit-il de supprimer du fichier /etc/passwd la ligne
hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash
puis de changer le 1002 en 1000 sur la ligne
ugo:x:1002:1002::/home/ugo:/bin/bash
pour que tout rentre dans l'ordre ?
Ca peut se tenter sans trop de risque.
Pour ma part j'aurais plutôt supprimer l'utilisateur hugo et créer ugo avec
l'ID 1000. (man userdel / man useradd)
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le jeudi 29 mars 2007 23:42, Hugolino s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Suffit-il de supprimer du fichier /etc/passwd la ligne hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash puis de changer le 1002 en 1000 sur la ligne ugo:x:1002:1002::/home/ugo:/bin/bash pour que tout rentre dans l'ordre ?
Ca peut se tenter sans trop de risque.
Pour ma part j'aurais plutôt supprimer l'utilisateur hugo et créer ugo avec l'ID 1000. (man userdel / man useradd)
-- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
ygg
29.03.2007 23:42 - Hugolino /
Suffit-il de supprimer du fichier /etc/passwd la ligne hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash puis de changer le 1002 en 1000 sur la ligne ugo:x:1002:1002::/home/ugo:/bin/bash pour que tout rentre dans l'ordre ? oui
Y aurait-il une autre solution plus élégante ?
oui cf dessous
A supposer que ce genre de bidouille soit nécessaire sur un système gérant plusieurs dizaines d'utilisateurs, auquel cas cela deviendrait sans doute vite inextricable, la solution s'appelle-t-elle LDAP, YP ou NIS et autres joyeusetés ? (auquel cas, forget it (moi petit lameer ;-)) oui mais on s'éloigne du sujet. La gestion par annuaire déporté ne
réglera pas les problèmes des fichiers de configuration (autres que les historiques .bash...) à chaque changement de distrib. Sûrement un problème à complexité non linéaire...
Est-ce que SaMBa est plus simple ? Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer sur LDAP comme Linux.
Merci de vos avis
29.03.2007 23:42 - Hugolino /
Suffit-il de supprimer du fichier /etc/passwd la ligne
hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash
puis de changer le 1002 en 1000 sur la ligne
ugo:x:1002:1002::/home/ugo:/bin/bash
pour que tout rentre dans l'ordre ?
oui
Y aurait-il une autre solution plus élégante ?
oui cf dessous
A supposer que ce genre de bidouille soit nécessaire sur un système
gérant plusieurs dizaines d'utilisateurs, auquel cas cela deviendrait
sans doute vite inextricable, la solution s'appelle-t-elle LDAP, YP ou
NIS et autres joyeusetés ? (auquel cas, forget it (moi petit lameer ;-))
oui mais on s'éloigne du sujet. La gestion par annuaire déporté ne
réglera pas les problèmes des fichiers de configuration (autres que les
historiques .bash...) à chaque changement de distrib. Sûrement un
problème à complexité non linéaire...
Est-ce que SaMBa est plus simple ?
Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer
sur LDAP comme Linux.
Suffit-il de supprimer du fichier /etc/passwd la ligne hugo:x:1000:1000:hugo,,,:/home/hugo:/bin/bash puis de changer le 1002 en 1000 sur la ligne ugo:x:1002:1002::/home/ugo:/bin/bash pour que tout rentre dans l'ordre ? oui
Y aurait-il une autre solution plus élégante ?
oui cf dessous
A supposer que ce genre de bidouille soit nécessaire sur un système gérant plusieurs dizaines d'utilisateurs, auquel cas cela deviendrait sans doute vite inextricable, la solution s'appelle-t-elle LDAP, YP ou NIS et autres joyeusetés ? (auquel cas, forget it (moi petit lameer ;-)) oui mais on s'éloigne du sujet. La gestion par annuaire déporté ne
réglera pas les problèmes des fichiers de configuration (autres que les historiques .bash...) à chaque changement de distrib. Sûrement un problème à complexité non linéaire...
Est-ce que SaMBa est plus simple ? Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer sur LDAP comme Linux.
Merci de vos avis
Nicolas.MICHEL
ygg wrote:
Est-ce que SaMBa est plus simple ? Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer sur LDAP comme Linux.
J'ai plus la procédure en tête mais il me semble au crontraire qu'il y a un pam_winbind qui permet de se loguer via samba, soit en se connectant à un domaine existant soit en configurant samba en tant que serveur de domaine. Testé une fois, il y a des lustres.
-- Nicolas
ygg <yggdrassil@a_supprimer.cegetel.net> wrote:
Est-ce que SaMBa est plus simple ?
Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer
sur LDAP comme Linux.
J'ai plus la procédure en tête mais il me semble au crontraire qu'il y a
un pam_winbind qui permet de se loguer via samba, soit en se connectant
à un domaine existant soit en configurant samba en tant que serveur de
domaine. Testé une fois, il y a des lustres.
Est-ce que SaMBa est plus simple ? Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer sur LDAP comme Linux.
J'ai plus la procédure en tête mais il me semble au crontraire qu'il y a un pam_winbind qui permet de se loguer via samba, soit en se connectant à un domaine existant soit en configurant samba en tant que serveur de domaine. Testé une fois, il y a des lustres.
-- Nicolas
ygg
03.04.2007 13:57 - Nicolas MICHEL /
ygg wrote:
Est-ce que SaMBa est plus simple ? Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer sur LDAP comme Linux.
J'ai plus la procédure en tête mais il me semble au crontraire qu'il y a un pam_winbind qui permet de se loguer via samba, soit en se connectant à un domaine existant soit en configurant samba en tant que serveur de domaine. Testé une fois, il y a des lustres.
Effectivement c'est flou. Je précise.
"Samba ne gère que les droits d'accès à son propre serveur smbd" Serveur qui peut être de domaine. A moins que ce ne soit l'insverse.
03.04.2007 13:57 - Nicolas MICHEL /
ygg <yggdrassil@a_supprimer.cegetel.net> wrote:
Est-ce que SaMBa est plus simple ?
Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer
sur LDAP comme Linux.
J'ai plus la procédure en tête mais il me semble au crontraire qu'il y a
un pam_winbind qui permet de se loguer via samba, soit en se connectant
à un domaine existant soit en configurant samba en tant que serveur de
domaine. Testé une fois, il y a des lustres.
Effectivement c'est flou. Je précise.
"Samba ne gère que les droits d'accès à son propre serveur smbd"
Serveur qui peut être de domaine.
A moins que ce ne soit l'insverse.
Est-ce que SaMBa est plus simple ? Hors-sujet. Samba ne gère que les droits d'accès à son propre serveur
pas au serveur de fichiers qui reste géré par Linux. Il peut s'appuyer sur LDAP comme Linux.
J'ai plus la procédure en tête mais il me semble au crontraire qu'il y a un pam_winbind qui permet de se loguer via samba, soit en se connectant à un domaine existant soit en configurant samba en tant que serveur de domaine. Testé une fois, il y a des lustres.
Effectivement c'est flou. Je précise.
"Samba ne gère que les droits d'accès à son propre serveur smbd" Serveur qui peut être de domaine. A moins que ce ne soit l'insverse.
Nicolas.MICHEL
ygg wrote:
Effectivement c'est flou. Je précise. "Samba ne gère que les droits d'accès à son propre serveur smbd" Serveur qui peut être de domaine. A moins que ce ne soit l'insverse.
Ici on a un domaine windows, donc je n'ai jamais monté un domaine samba.
Par contre j'ai déjà configuré linux pour qu'il authentifies d'autres services que samba via winbind et qu'il gère les utilisateurs.
Si je comprends ce que tu veux dire, winbind ne peux pas pointer en local et même en paramétrant /etc/nsswitch.conf, les utilisateurs ne peuvent pas être gérés par un domaine samba ?
Voilà qui m'étonnerais fort. -- Nicolas
ygg <yggdrassil@a_supprimer.cegetel.net> wrote:
Effectivement c'est flou. Je précise.
"Samba ne gère que les droits d'accès à son propre serveur smbd"
Serveur qui peut être de domaine.
A moins que ce ne soit l'insverse.
Ici on a un domaine windows, donc je n'ai jamais monté un domaine samba.
Par contre j'ai déjà configuré linux pour qu'il authentifies d'autres
services que samba via winbind et qu'il gère les utilisateurs.
Si je comprends ce que tu veux dire, winbind ne peux pas pointer en
local et même en paramétrant /etc/nsswitch.conf, les utilisateurs ne
peuvent pas être gérés par un domaine samba ?
Effectivement c'est flou. Je précise. "Samba ne gère que les droits d'accès à son propre serveur smbd" Serveur qui peut être de domaine. A moins que ce ne soit l'insverse.
Ici on a un domaine windows, donc je n'ai jamais monté un domaine samba.
Par contre j'ai déjà configuré linux pour qu'il authentifies d'autres services que samba via winbind et qu'il gère les utilisateurs.
Si je comprends ce que tu veux dire, winbind ne peux pas pointer en local et même en paramétrant /etc/nsswitch.conf, les utilisateurs ne peuvent pas être gérés par un domaine samba ?
Voilà qui m'étonnerais fort. -- Nicolas
ygg
04.04.2007 12:04 - Nicolas MICHEL /
ygg wrote:
Ici on a un domaine windows, donc je n'ai jamais monté un domaine samba. Ici c'est l'inverse. Je n'avance que des arguments théoriques.
Par contre j'ai déjà configuré linux pour qu'il authentifies d'autres services que samba via winbind et qu'il gère les utilisateurs. Dans ce cas ce n'est pas Linux qui gère les utilisateurs mais le serveur
NT sollicité par winbind (redirection nsswitch.conf). http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html#id382021 Evidemment ce serveur NT peut être Samba.
Si je comprends ce que tu veux dire, winbind ne peux pas pointer en local et même en paramétrant /etc/nsswitch.conf, les utilisateurs ne peuvent pas être gérés par un domaine samba ? Gérer des authentifications Unix par Winbind qui pointe en local le
domaine Samba cela me semble excessif mais possible. Surtout qu'en local les utilisateurs doivent également exister dans /etc/passwd. On peut rajouter un annuaire pour palier ce problème esthétique...
Voilà qui m'étonnerais fort. L'OP a parlé de Samba sans réelle motivation. Et pour cause. L'ajout
d'un serveur ne fait que déporter son problème sans le résoudre. Conclusion il devrait utiliser un groupe Unix et le fichier /etc/passwd. Je pense qu'il s'agit d'une mutuelle incompréhension. Quant je dis que "Samba ne gère que les droits d'accès à son propre serveur", si c'est un contrôleur de domaine il gère l'accès au domaine.
04.04.2007 12:04 - Nicolas MICHEL /
ygg <yggdrassil@a_supprimer.cegetel.net> wrote:
Ici on a un domaine windows, donc je n'ai jamais monté un domaine samba.
Ici c'est l'inverse. Je n'avance que des arguments théoriques.
Par contre j'ai déjà configuré linux pour qu'il authentifies d'autres
services que samba via winbind et qu'il gère les utilisateurs.
Dans ce cas ce n'est pas Linux qui gère les utilisateurs mais le serveur
NT sollicité par winbind (redirection nsswitch.conf).
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html#id382021
Evidemment ce serveur NT peut être Samba.
Si je comprends ce que tu veux dire, winbind ne peux pas pointer en
local et même en paramétrant /etc/nsswitch.conf, les utilisateurs ne
peuvent pas être gérés par un domaine samba ?
Gérer des authentifications Unix par Winbind qui pointe en local le
domaine Samba cela me semble excessif mais possible. Surtout qu'en local
les utilisateurs doivent également exister dans /etc/passwd. On peut
rajouter un annuaire pour palier ce problème esthétique...
Voilà qui m'étonnerais fort.
L'OP a parlé de Samba sans réelle motivation. Et pour cause. L'ajout
d'un serveur ne fait que déporter son problème sans le résoudre.
Conclusion il devrait utiliser un groupe Unix et le fichier /etc/passwd.
Je pense qu'il s'agit d'une mutuelle incompréhension. Quant je dis que
"Samba ne gère que les droits d'accès à son propre serveur", si c'est un
contrôleur de domaine il gère l'accès au domaine.
Ici on a un domaine windows, donc je n'ai jamais monté un domaine samba. Ici c'est l'inverse. Je n'avance que des arguments théoriques.
Par contre j'ai déjà configuré linux pour qu'il authentifies d'autres services que samba via winbind et qu'il gère les utilisateurs. Dans ce cas ce n'est pas Linux qui gère les utilisateurs mais le serveur
NT sollicité par winbind (redirection nsswitch.conf). http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html#id382021 Evidemment ce serveur NT peut être Samba.
Si je comprends ce que tu veux dire, winbind ne peux pas pointer en local et même en paramétrant /etc/nsswitch.conf, les utilisateurs ne peuvent pas être gérés par un domaine samba ? Gérer des authentifications Unix par Winbind qui pointe en local le
domaine Samba cela me semble excessif mais possible. Surtout qu'en local les utilisateurs doivent également exister dans /etc/passwd. On peut rajouter un annuaire pour palier ce problème esthétique...
Voilà qui m'étonnerais fort. L'OP a parlé de Samba sans réelle motivation. Et pour cause. L'ajout
d'un serveur ne fait que déporter son problème sans le résoudre. Conclusion il devrait utiliser un groupe Unix et le fichier /etc/passwd. Je pense qu'il s'agit d'une mutuelle incompréhension. Quant je dis que "Samba ne gère que les droits d'accès à son propre serveur", si c'est un contrôleur de domaine il gère l'accès au domaine.
Nicolas.MICHEL
ygg wrote:
Je pense qu'il s'agit d'une mutuelle incompréhension.
Oui, sans doutes.
Dureste je pense que Hugolino devrait plutôt rechercher le fichier de config qui le chagrine plutôt que de passer un rouleau compresseur en changeant de compte.
-- Nicolas
ygg <yggdrassil@a_supprimer.cegetel.net> wrote:
Je pense qu'il s'agit d'une mutuelle incompréhension.
Oui, sans doutes.
Dureste je pense que Hugolino devrait plutôt rechercher le fichier de
config qui le chagrine plutôt que de passer un rouleau compresseur en
changeant de compte.
Je pense qu'il s'agit d'une mutuelle incompréhension.
Oui, sans doutes.
Dureste je pense que Hugolino devrait plutôt rechercher le fichier de config qui le chagrine plutôt que de passer un rouleau compresseur en changeant de compte.
