Hi to all,

Since I have several Slackware machines running, I decided I needed some central user management. I selected NIS as it is relatively simple to configure a server and some clients.

For administering access rights to shared directories, with network-wide groups, it works perfectly: I create a user on the server and I can login from any client, accessing the nfs-shares etc.

But how do I take care of access to local, hardware-related groups like audio, plugdev, cdrom, etc.?
When I login on a client where I do not have a local account, I am not a member of the local groups audio etc.

Searching through Google, I found some 'solutions', but all seem more like 'hacks' to me:

1. add user 'niels' locally to the audio groups editing the /etc/group file (then why do I have central user administration?)
2. changing the permissions to the devices in the udev-rules to 666 (then I simply have no security at all)
3. changing MINGID in /var/yp/Makefile to 1 (Then I show all my groups and members to all clients, doesn't seem right to me either...)
4. Create a new 'audio' group on the server with GID>500, delete the original group on the server and all clients, chgrp all files / devices (didn't try this one, have no idea of the consequences!)
5. Forget about NIS, use LDAP!

Is #5 really the only 'correct' solution?
I understand that NIS is from a time when we didn't have sound-cards, local cd-rom drives, USB-sticks, etc., but it is simple to use and for my local network I don't need anything more secure.
And does LDAP solve this problem? If it really does, I might try to configure it, as a new challenge, but it would be a frustration to find out in the end that I have the same problems...

Ah, I read something about PAM as well, but we Slackers don't do PAM

Well, I am open to suggestions and advice!

1. I add the user/group to NIS and local files, You have central administration for network accounts.
2. no.
3. your nuts.
4. I guess that would work but if there is ever an update to the audio files you will have to chgrp again.
5. Either way each is good at something. LDAP is kinda overkill for a home or small office network.

Your local system accounts and nis accounts sort of work together. See your machines needs to be able to run even if NIS goes down, maybe users can't log or their processes can't do anything, but the entire system shouldn't just stop. Everytime a process access a file or a device (* cause a device is just a file in /dev *) it needs permissions, if their are no system accounts or system groups on your local machine and nis goes down nothing can do anything.

Add your users and the system accounts to NIS . That way you can give your users access to the system accounts in NIS instead of having to run around to each machine to add a user to that hardware group. But don't take the system accounts away from the system.

Working backwards through the answers:

That's exactly what I thought and why I choose simpler NIS.
Again, this is why I didn't like this solution.
Well, not me... I just put this in my list of 'solutions' I found on the internet.
ok, like I said, a 'hack', not a solution.

Now about the solution...
Just for clarity, let me explain my situation:
I have my main desktop, which is also the server (NIS / NFS), and some other desktops, portables, etc.
My wife has her own desktop, where se has her local account (with access to audio, etc.) and she also exists in NIS.
If she uses our 'shared' laptop, she wants to access her files on the NFS server without problems. That's why centralized administration is necessary. Now, if I - for some reason - use her desktop (where I have no local account), I have no audio, no access to her CDRom drive, etc. I need to work as root (bad idea) or create a local account for me.
Like this, there are several situations like this with my son's computer, etc.

Ok, that's why every machine has it's main user as a local account as well - me on my desktop, my wife on hers, etc.

Now this I where I get confused... Can you elaborate here?
My wife's acount is in NIS and locally on her system.
My account is in NIS and on my system.
If we swap places, we loose access to local hardware.

Sorry if I am mixing up things... And thanks for your patience explaining!

Having exactly the same problem here.
Does anybody know something more?

I think this is a big problem of NIS, if there is no solution for it.

I came to the conclusion that there is no *real* solution for it, only some workarounds.

In my windows-days, we used to create local groups to define access to devices (printers etc.) and include global groups or individual users from the domain in these local groups to define who can use that specific device - locally or remotely.

Like I said in the original message, NIS (YP) is from a time where we weren't worried about local devices like audio etc.
But something must exist to solve this problem.

I read some bits and pieces about PAM, but never investigated more, as Slackware doesn't have PAM and I have read that it has some security problems. But then, NIS also has these problems...

How is this solved in a corporate environment, with Linux desktops? Or are we going to accept defeat and say that Windows is better in this aspect? (Just trying to create some reactions here...)

I'm not on the network staff here at work, but I understand that there's a cron job & daemon that does a partial sync on /etc/passwd and /etc/shadow (and probably /etc/group, too) to ensure that when you change your password centrally it's update on all the linux boxes. This daemon is a compiled binary and there's a domain server in there somewhere, too ...

Rummaging around brought up this http://www.faqs.org/docs/linux_netwo...is.passwd.html . I don't understand why, if all your local groups have the same GID, you can't set up your NIS server lists to contain those same groups with the same GIDs, and your server lists to contain your roaming users with the appropriate groups.

You'd end up during a NIS brownout without access to those things (since the fallback would be to use the local accounts), but while it's up, everything works as intended.

Obviously I'm not actually running this, so perhaps I'm glossing over something here. I wish I could be more help, it's an interesting problem!

- Piete.