Hi,
if I change an entry in /etc/group by simply editing the file the
changes won’t get recognised. Is there any way to make the system
recognise the changes?
Changing groups with usermod -[R|A], works as expected, where is the
difference to a simple edit?
I just want to do a simple file synchronisation between machines.
Hi,
if I change an entry in /etc/group by simply editing the file the
changes won’t get recognised. Is there any way to make the system
recognise the changes?
Changing groups with usermod -[R|A], works as expected, where is the
difference to a simple edit?
I just want to do a simple file synchronisation between machines.
System is SLES 11 (2.6.32.27-0.2 x86_64)
Cheers,
Walter
[/color]
Hi
If you use YaST instead, that will run the necessary routines to sync;
Hi,
if I change an entry in /etc/group by simply editing the file the
changes won’t get recognised. Is there any way to make the system
recognise the changes?
Changing groups with usermod -[R|A], works as expected, where is the
difference to a simple edit?
I just want to do a simple file synchronisation between machines.
System is SLES 11 (2.6.32.27-0.2 x86_64)
Cheers,
Walter
[/color]
Hi
If you use YaST instead, that will run the necessary routines to sync;[color=green]
[/color][/color]
Code:
--------------------[color=blue][color=green]
[/color]
yast users
[/color]
--------------------[color=blue][color=green]
[/color]
Hi Malcolm,
I’m sorry, but this is not helpful. How would using yast2 be a
solution for a (automated) synchronisation between machines? As I
wrote in my OP I don’t have a problem with changing users’ groups
(it’s faster and easier with usermod, BTW), it is just that SLES is
behaving strangely and I am searching for a solution or explanation to
that.
Cheers,
Walter
P.S.
yast2 is incredibly slow. Just listing users >[/color]
Code:
--------------------[color=blue][color=green]
yast2 --ncurses users list[/color][/color]
--------------------[color=blue][color=green]
takes more than a second, whereas >[/color][/color]
Code:
--------------------[color=blue][color=green]
awk -F: ‘$3 >= 1000 && $3 <= 6000’ /etc/passwd[/color][/color]
--------------------[color=blue][color=green]
takes 0.001 seconds. Even a more universal >[/color][/color]
Code:
--------------------[color=blue][color=green]
GID_MIN=$(awk ‘/[1]*GID_MIN/ {print $NF}’ /etc/login.defs);\[/color]
GID_MAX=$(awk ‘/[2]*GID_MAX/ {print $NF}’ /etc/login.defs);\
awk -F: ‘$3 >= ‘“$GID_MIN”’ && $3 <= ‘“$GID_MAX”’’ /etc/passwd[/color]
--------------------[color=blue][color=green]
would take only 0.007 seconds. Try this in a landscape with 100+[/color]
machines on every machine and you’ll see what I mean.
W.[/color]
Hi,
if I change an entry in /etc/group by simply editing the file the
changes won’t get recognised. Is there any way to make the system
recognise the changes?
Changing groups with usermod -[R|A], works as expected, where is
the difference to a simple edit?
I just want to do a simple file synchronisation between machines.
System is SLES 11 (2.6.32.27-0.2 x86_64)
Cheers,
Walter
[/color]
Hi
If you use YaST instead, that will run the necessary routines to
sync;[color=darkred]
[/color][/color]
Code:
--------------------[color=green][color=darkred]
[/color]
yast users
[/color]
--------------------[color=green][color=darkred]
[/color]
Hi Malcolm,
I’m sorry, but this is not helpful. How would using yast2 be a
solution for a (automated) synchronisation between machines? As I
wrote in my OP I don’t have a problem with changing users’ groups
(it’s faster and easier with usermod, BTW), it is just that SLES is
behaving strangely and I am searching for a solution or explanation
to that.
Cheers,
Walter
P.S.
yast2 is incredibly slow. Just listing users >[/color]
Code:
--------------------[color=green][color=darkred]
yast2 --ncurses users list[/color][/color]
--------------------[color=green][color=darkred]
takes more than a second, whereas >[/color][/color]
Code:
--------------------[color=green][color=darkred]
awk -F: ‘$3 >= 1000 && $3 <= 6000’ /etc/passwd[/color][/color]
--------------------[color=green][color=darkred]
takes 0.001 seconds. Even a more universal >[/color][/color]
Code:
--------------------[color=green][color=darkred]
GID_MIN=$(awk ‘/[1]*GID_MIN/ {print
$NF}’ /etc/login.defs);\[/color]
GID_MAX=$(awk ‘/[2]*GID_MAX/ {print
$NF}’ /etc/login.defs);\ awk -F: ‘$3 >= ‘“$GID_MIN”’ && $3 <=
‘“$GID_MAX”’’ /etc/passwd[/color]
--------------------[color=green][color=darkred]
would take only 0.007 seconds. Try this in a landscape with 100+[/color]
machines on every machine and you’ll see what I mean.
W.[/color]
[/color]
Hi
If you look at the man page for groups;
BUGS
As the 4.2BSD initgroups(3) man page says: No-one seems to
keep /etc/group up-to-date.
What if you use vigr and grpck commands, they may cause an update, but
have a feeling your hitting the above bug.
On Tue, 06 Sep 2011 15:16:02 GMT
[…]
Hi
If you look at the man page for groups;[color=green]
[/color][/color]
Code:
--------------------[color=blue][color=green]
[/color]
BUGS
As the 4.2BSD initgroups(3) man page says: No-one seems to
keep /etc/group up-to-date.
[/color]
--------------------[color=blue][color=green]
[/color]
What if you use vigr and grpck commands, they may cause an update,
but
have a feeling your hitting the above bug.
[/color]
Alas, nether grpck or vigroup has any effect on a user’s group
membership.
But I’ve just found the culprit: it’s nscd, the name service cache
daemon. Even when restarted after changes in /etc/group it will restore
the previous state.
Changing
Code:
enable-cache group yes
to
Code:
enable-cache group no
in /etc/nscd.conf and restarting nscd solved my problem.
So I’ve only to roll out the changed configuration and restart nscd on
all machines and my synchronisation goes as planned.
Thanks for your time,
Hi Walter,
instead of disabling caching completely, you might just tell nscd to
reload the groups… unless you have other reasons to disable nscd,
too.
[…][/color]
As I said, simply restarting/reloading nscd won’t help. And as I see no
advantage in credential caching in our current environment it’s more
convenient for me to disable it.