Using stdin to add Samba user/password in bash script

[capscrew]

I use this command to add my samba users:

useradd htpc -u 1001 -M -d /dev/null -s /dev/null -U -G raid

Is that the correct way to do it?

If it works, then great. I've never tried this but here are my initial thoughts: The switch -M means don't create a home directory automatically, but then you manually crate one to nowhere. If you didn't want one why run the -d switch at all. Why create a shell (with -s) if you don't want one either.

[Jonathan L]

As far as I know the interactive shell access and home dir is all that separates a mortal user from a system user. Think of samba server with 200 users of the share that you need to police from messing with your server. Not to mention all those home directories that they have a right to. I think I would drop the -d /home/$user from the script and see what happens. All in all, a very nice script you have created.

Edit: There is one more thing about system users -- NO PASSWORD. This means you do not have to sync the Ubuntu pass with the samba user pass. No PAM problems either. Yes the smbpasswd will work. The limitation is that there must be a Ubuntu user, not whether it has a password.

Yes you can update the account with usermod. You can add a home directory as well as an interactive shell.

... just some thoughts: there are really a number of kinds of account here:

1. Samba users: accounts for those to use the file server (ie, the samba users we started with)
2. Interactive users: accounts of those to use shells (the potential users we've just been speaking about)
3. Admin users: accounts of those who run the system (ie, Ryan)
4. System users: accounts of those who never log in but just own directors (root, daemon, bin, ...)

It's traditional that those 'system users' in category 4 have low user ids, which helps keeps things straight (but isn't as far as I know used anywhere) from the users which are in higher numeric range..

For your samba users (case 1), I'd try putting them in the normal UID space, with disabled passwords, no home directory, no login shell etc. But I wouldn't use the useradd -r method, I'd use the appropriate flags (-M don't create home, -s /usr/bin/nologin, and don't set a password.

useradd $user -d /home/$user -M -s /usr/sbin/nologin

This makes an account with the home directory defined but not created, and no password (look in /etc/shadow), with a never-log-in shell, with a uid in the 1000 range.

For interactive users (case 2), you make another script to convert them (make directories, install dot files, change shell, apply password and so on. Many times I've seen users categories as "samba-only", "mail-only", "ftp only" and so on.

Script looks nice and tidy! But did you know that the "function" keyword is unique to bash? Given that the default system shell changes from time to time, I'd suggest being conservative with this script.
If you run your script with another implementation of the bourne shell (ie, the normal shell /bin/sh, which is currently 'dash'), it's incompatible? Given they both accept the original syntax, I'd recommend it:

useradd ()
{
...
}

Hope that's of some use

Kind regards
Jonathan

[CharlesA]

If it works, then great. I've never tried this but here are my initial thoughts: The switch -M means don't create a home directory automatically, but then you manually crate one to nowhere. If you didn't want one why run the -d switch at all. Why create a shell (with -s) if you don't want one either.

Thought all users had to have a home directory and shell?

If you run the command without redirecting it to /dev/null, it adds the shell as /bin/sh. Of course that wouldn't work if the user doesn't have a password set, but better safe then sorry.

sudo useradd test1 -u 1002

test1:x:1002:1002::/home/test1:/bin/sh

[RyanRahl]

@erixnow That was out of left field, definitely something to think about.

Script looks nice and tidy! But did you know that the "function" keyword is unique to bash? Given that the default system shell changes from time to time, I'd suggest being conservative with this script.
If you run your script with another implementation of the bourne shell (ie, the normal shell /bin/sh, which is currently 'dash'), it's incompatible?

Thanks, and I didn't know that. Is there a place where I can compare the syntax differences between the shell scripting languages?

If you run the command without redirecting it to /dev/null, it adds the shell as /bin/sh. Of course that wouldn't work if the user doesn't have a password set, but better safe then sorry.

Interesting point. I like the idea of using

-s /dev/null

I looked in the /etc/passwd file and most of the system users use /bin/sh however there are some that use /bin/false and /sbin/nologin which are good and slightly better, respectively but neither as good as /dev/null.