What is/are the standard CLI program(s) to manage users and groups?

Clash Royale CLAN TAG#URR8PPP
I'm basically asking about user management from the command line (e.g. on a system where there are no graphical tools available). In the past I've used several different programs to add or delete users and groups or to modify their attributes: adduser, useradd, usermod, gpasswd, and perhaps others I've forgotten. I've also heard a couple times that some of these programs are low-level and should be avoided for general use, but I can never remember which. So I'd like to get a definitive answer for which programs are the recommended ones for at least the following tasks:
- Create a new user
- Add a user to a group
- Remove a user from a group
- Change a user's primary group
- Change a user's login shell or home directory
- Delete a user
I'm looking for standard tools which I can expect to be available on pretty much any Linux system (of any distribution).
linux users utilities
add a comment |
I'm basically asking about user management from the command line (e.g. on a system where there are no graphical tools available). In the past I've used several different programs to add or delete users and groups or to modify their attributes: adduser, useradd, usermod, gpasswd, and perhaps others I've forgotten. I've also heard a couple times that some of these programs are low-level and should be avoided for general use, but I can never remember which. So I'd like to get a definitive answer for which programs are the recommended ones for at least the following tasks:
- Create a new user
- Add a user to a group
- Remove a user from a group
- Change a user's primary group
- Change a user's login shell or home directory
- Delete a user
I'm looking for standard tools which I can expect to be available on pretty much any Linux system (of any distribution).
linux users utilities
1
alsogroupmod. I'm not going to make this an answer.... but the most standard way is probably to use your text editor... remember the files affected are just delimited text.
– xenoterracide
Aug 19 '10 at 1:53
Interestingly, prior to asking this question, I had never once seen so much as a mention of directly editing the files. (Somehow I had the impression that/etc/passwdwas just one part of a complex system)
– David Z
Aug 19 '10 at 7:41
add a comment |
I'm basically asking about user management from the command line (e.g. on a system where there are no graphical tools available). In the past I've used several different programs to add or delete users and groups or to modify their attributes: adduser, useradd, usermod, gpasswd, and perhaps others I've forgotten. I've also heard a couple times that some of these programs are low-level and should be avoided for general use, but I can never remember which. So I'd like to get a definitive answer for which programs are the recommended ones for at least the following tasks:
- Create a new user
- Add a user to a group
- Remove a user from a group
- Change a user's primary group
- Change a user's login shell or home directory
- Delete a user
I'm looking for standard tools which I can expect to be available on pretty much any Linux system (of any distribution).
linux users utilities
I'm basically asking about user management from the command line (e.g. on a system where there are no graphical tools available). In the past I've used several different programs to add or delete users and groups or to modify their attributes: adduser, useradd, usermod, gpasswd, and perhaps others I've forgotten. I've also heard a couple times that some of these programs are low-level and should be avoided for general use, but I can never remember which. So I'd like to get a definitive answer for which programs are the recommended ones for at least the following tasks:
- Create a new user
- Add a user to a group
- Remove a user from a group
- Change a user's primary group
- Change a user's login shell or home directory
- Delete a user
I'm looking for standard tools which I can expect to be available on pretty much any Linux system (of any distribution).
linux users utilities
linux users utilities
edited Feb 10 at 19:08
Rui F Ribeiro
41.1k1479137
41.1k1479137
asked Aug 19 '10 at 1:01
David ZDavid Z
569310
569310
1
alsogroupmod. I'm not going to make this an answer.... but the most standard way is probably to use your text editor... remember the files affected are just delimited text.
– xenoterracide
Aug 19 '10 at 1:53
Interestingly, prior to asking this question, I had never once seen so much as a mention of directly editing the files. (Somehow I had the impression that/etc/passwdwas just one part of a complex system)
– David Z
Aug 19 '10 at 7:41
add a comment |
1
alsogroupmod. I'm not going to make this an answer.... but the most standard way is probably to use your text editor... remember the files affected are just delimited text.
– xenoterracide
Aug 19 '10 at 1:53
Interestingly, prior to asking this question, I had never once seen so much as a mention of directly editing the files. (Somehow I had the impression that/etc/passwdwas just one part of a complex system)
– David Z
Aug 19 '10 at 7:41
1
1
also
groupmod. I'm not going to make this an answer.... but the most standard way is probably to use your text editor... remember the files affected are just delimited text.– xenoterracide
Aug 19 '10 at 1:53
also
groupmod. I'm not going to make this an answer.... but the most standard way is probably to use your text editor... remember the files affected are just delimited text.– xenoterracide
Aug 19 '10 at 1:53
Interestingly, prior to asking this question, I had never once seen so much as a mention of directly editing the files. (Somehow I had the impression that
/etc/passwd was just one part of a complex system)– David Z
Aug 19 '10 at 7:41
Interestingly, prior to asking this question, I had never once seen so much as a mention of directly editing the files. (Somehow I had the impression that
/etc/passwd was just one part of a complex system)– David Z
Aug 19 '10 at 7:41
add a comment |
9 Answers
9
active
oldest
votes
Sadly, none of those operations were ever standardized.
Some operating systems offer this functionality as part of the OS, like Linux, but even if your Linux system includes them, over time and across Linux distributions the tools and their names changed so you can not really depend on a standard set of tools to do those tasks.
You need to have a per-operating system set of tools.
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
1
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
add a comment |
On Debian (and derived) systems, adduser and deluser are higher-level wrappers around useradd and related functionality. The cover user creation, group membership addition and subtraction, and user deletion. The corresponding commands from making/deleting groups are, sensibly enough, addgroup and delgroup. usermod appears to cover the remaining use case you name.
add a comment |
You mention Linux in the last part of your question, but since the title is generic I'll answer for FreeBSD.
FreeBSD has similar commands as Linux but they are commands passed to the pw utility:
pw useradd [user|uid] ...
pw usermod [user|uid] ...
and so on. However, one can parse the command into two parts: user and mod; a noun and a verb. Moreover, one can also use group and del:
pw groupdel [group|gid] ...
to, for example, delete a group. So here's what I think is really cool: the order doesn't matter, nor does the spacing! What this means, is that you can remember what to call by thinking about what you want to do (in English anyway):
pw del user [user|uid] ...
pw mod group [group|gid] ...
pw show user [user|uid] ...
pw next user [user|uid] ...
and more! The pw utility also lets you lock and unlock accounts:
pw lock [user|uid] ...
pw unlock [user|uid] ...
Options and any parameters that you pass are all standardized (although don't always apply to call commands) so memorization is minimized. All in all a nice way to do things.
Note: the ellipses in the above examples represent options and parameters passed to pw not additional users or groups.
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
add a comment |
Just for completeness, in the low-level end of the spectrum I'd mention vipw(8) and vigr(8), just above "vi /etc/passwd" and "cat > /etc/passwd" but right below "useradd". Oh, and they exist in most Unix variants.
add a comment |
All of these tools are ultimately built to edit text files for you. If you want to know how to manage users and groups over systems, you should get familiar with these underlying text files. Lucky for you, there's just two of them, /etc/passwd and /etc/group. There are also complementary /etc/shadow and /etc/gshadow files for shadowing passwd and group respectively.
4
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
add a comment |
In many situations, knowing how to edit "/etc/passwd" is still useful.
1
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
add a comment |
If you are using a backend other than the default local machine backend - OpenLDAP being the most common - then cpu (change password utility) might be the command you are looking for. It can be run on machines other than the LDAP master if configured correctly, and it's syntax is mostly just the same as useradd etc with a prefix of cpu. So to add myself I could do
$ sudo cpu useradd hamish
See the cpu man page for more details.
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
add a comment |
If your question was limited to
any Linux system (of any distribution)
but all of the systems have network access to a single server. You could use something like NIS or YP. So this answer is limited to admins within a single organization.
You still have the issue where almost every distribution has slightly different ways to configure YP, but configuration only happens once. Also, this type of network is not trivial.
Within a single site/network you will gain a lot doing this. In combination with automount, my favorite is being able to SSH to any *nix machine and have all my home files and tools available to me.
To the point, the distribution you choose for the master is the system you use for managing users. You then will have a single set of tools/documentation to manage users and groups.
It is even possible to use something like LDAP and samba tools on the master. Using samba also allows me to have my home files available to me on windows machines.
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
add a comment |
The closest thing to a standard you'll get is vi /etc/passwd, vi /etc/shadow, and vi /etc/groups. (Heretics may substitute emacs.) Everything since then that I've found will only work on some systems.
Seriously, find out what tools your OS has, and use them. Just don't expect them to work the same on all systems. It would be nice if they were standardized, but they aren't.
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for/etc/passwd,/etc/shadow,/etc/group, and/etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.
– Aaron Toponce
Aug 19 '10 at 23:04
Never call an editor on/etc/passwdand friends directly. Usevipwandvigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.
– Gilles
Aug 20 '10 at 13:34
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f745%2fwhat-is-are-the-standard-cli-programs-to-manage-users-and-groups%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sadly, none of those operations were ever standardized.
Some operating systems offer this functionality as part of the OS, like Linux, but even if your Linux system includes them, over time and across Linux distributions the tools and their names changed so you can not really depend on a standard set of tools to do those tasks.
You need to have a per-operating system set of tools.
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
1
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
add a comment |
Sadly, none of those operations were ever standardized.
Some operating systems offer this functionality as part of the OS, like Linux, but even if your Linux system includes them, over time and across Linux distributions the tools and their names changed so you can not really depend on a standard set of tools to do those tasks.
You need to have a per-operating system set of tools.
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
1
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
add a comment |
Sadly, none of those operations were ever standardized.
Some operating systems offer this functionality as part of the OS, like Linux, but even if your Linux system includes them, over time and across Linux distributions the tools and their names changed so you can not really depend on a standard set of tools to do those tasks.
You need to have a per-operating system set of tools.
Sadly, none of those operations were ever standardized.
Some operating systems offer this functionality as part of the OS, like Linux, but even if your Linux system includes them, over time and across Linux distributions the tools and their names changed so you can not really depend on a standard set of tools to do those tasks.
You need to have a per-operating system set of tools.
answered Aug 19 '10 at 1:44
miguel.de.icazamiguel.de.icaza
4,29322525
4,29322525
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
1
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
add a comment |
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
1
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
I've never had the names change... but I have had the switches change. I recall once finding out that a linux didn't have gpasswd -a.
– xenoterracide
Aug 19 '10 at 1:52
1
1
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
If memory serves-- RedHat once used 'adduser' instead of 'useradd', and it behaved differently (I think useradd was more Debianish). They later made 'adduser' a symlink to 'useradd'. See some old references at redhat.com/docs/manuals/linux/RHL-5.2-Manual/install-guide/…
– Stefan Lasiewski
Aug 19 '10 at 3:17
add a comment |
On Debian (and derived) systems, adduser and deluser are higher-level wrappers around useradd and related functionality. The cover user creation, group membership addition and subtraction, and user deletion. The corresponding commands from making/deleting groups are, sensibly enough, addgroup and delgroup. usermod appears to cover the remaining use case you name.
add a comment |
On Debian (and derived) systems, adduser and deluser are higher-level wrappers around useradd and related functionality. The cover user creation, group membership addition and subtraction, and user deletion. The corresponding commands from making/deleting groups are, sensibly enough, addgroup and delgroup. usermod appears to cover the remaining use case you name.
add a comment |
On Debian (and derived) systems, adduser and deluser are higher-level wrappers around useradd and related functionality. The cover user creation, group membership addition and subtraction, and user deletion. The corresponding commands from making/deleting groups are, sensibly enough, addgroup and delgroup. usermod appears to cover the remaining use case you name.
On Debian (and derived) systems, adduser and deluser are higher-level wrappers around useradd and related functionality. The cover user creation, group membership addition and subtraction, and user deletion. The corresponding commands from making/deleting groups are, sensibly enough, addgroup and delgroup. usermod appears to cover the remaining use case you name.
answered Aug 19 '10 at 2:06
Phil MillerPhil Miller
33624
33624
add a comment |
add a comment |
You mention Linux in the last part of your question, but since the title is generic I'll answer for FreeBSD.
FreeBSD has similar commands as Linux but they are commands passed to the pw utility:
pw useradd [user|uid] ...
pw usermod [user|uid] ...
and so on. However, one can parse the command into two parts: user and mod; a noun and a verb. Moreover, one can also use group and del:
pw groupdel [group|gid] ...
to, for example, delete a group. So here's what I think is really cool: the order doesn't matter, nor does the spacing! What this means, is that you can remember what to call by thinking about what you want to do (in English anyway):
pw del user [user|uid] ...
pw mod group [group|gid] ...
pw show user [user|uid] ...
pw next user [user|uid] ...
and more! The pw utility also lets you lock and unlock accounts:
pw lock [user|uid] ...
pw unlock [user|uid] ...
Options and any parameters that you pass are all standardized (although don't always apply to call commands) so memorization is minimized. All in all a nice way to do things.
Note: the ellipses in the above examples represent options and parameters passed to pw not additional users or groups.
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
add a comment |
You mention Linux in the last part of your question, but since the title is generic I'll answer for FreeBSD.
FreeBSD has similar commands as Linux but they are commands passed to the pw utility:
pw useradd [user|uid] ...
pw usermod [user|uid] ...
and so on. However, one can parse the command into two parts: user and mod; a noun and a verb. Moreover, one can also use group and del:
pw groupdel [group|gid] ...
to, for example, delete a group. So here's what I think is really cool: the order doesn't matter, nor does the spacing! What this means, is that you can remember what to call by thinking about what you want to do (in English anyway):
pw del user [user|uid] ...
pw mod group [group|gid] ...
pw show user [user|uid] ...
pw next user [user|uid] ...
and more! The pw utility also lets you lock and unlock accounts:
pw lock [user|uid] ...
pw unlock [user|uid] ...
Options and any parameters that you pass are all standardized (although don't always apply to call commands) so memorization is minimized. All in all a nice way to do things.
Note: the ellipses in the above examples represent options and parameters passed to pw not additional users or groups.
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
add a comment |
You mention Linux in the last part of your question, but since the title is generic I'll answer for FreeBSD.
FreeBSD has similar commands as Linux but they are commands passed to the pw utility:
pw useradd [user|uid] ...
pw usermod [user|uid] ...
and so on. However, one can parse the command into two parts: user and mod; a noun and a verb. Moreover, one can also use group and del:
pw groupdel [group|gid] ...
to, for example, delete a group. So here's what I think is really cool: the order doesn't matter, nor does the spacing! What this means, is that you can remember what to call by thinking about what you want to do (in English anyway):
pw del user [user|uid] ...
pw mod group [group|gid] ...
pw show user [user|uid] ...
pw next user [user|uid] ...
and more! The pw utility also lets you lock and unlock accounts:
pw lock [user|uid] ...
pw unlock [user|uid] ...
Options and any parameters that you pass are all standardized (although don't always apply to call commands) so memorization is minimized. All in all a nice way to do things.
Note: the ellipses in the above examples represent options and parameters passed to pw not additional users or groups.
You mention Linux in the last part of your question, but since the title is generic I'll answer for FreeBSD.
FreeBSD has similar commands as Linux but they are commands passed to the pw utility:
pw useradd [user|uid] ...
pw usermod [user|uid] ...
and so on. However, one can parse the command into two parts: user and mod; a noun and a verb. Moreover, one can also use group and del:
pw groupdel [group|gid] ...
to, for example, delete a group. So here's what I think is really cool: the order doesn't matter, nor does the spacing! What this means, is that you can remember what to call by thinking about what you want to do (in English anyway):
pw del user [user|uid] ...
pw mod group [group|gid] ...
pw show user [user|uid] ...
pw next user [user|uid] ...
and more! The pw utility also lets you lock and unlock accounts:
pw lock [user|uid] ...
pw unlock [user|uid] ...
Options and any parameters that you pass are all standardized (although don't always apply to call commands) so memorization is minimized. All in all a nice way to do things.
Note: the ellipses in the above examples represent options and parameters passed to pw not additional users or groups.
edited May 5 '13 at 16:29
Anthon
61k17104166
61k17104166
answered Aug 19 '10 at 2:35
gvkvgvkv
2,3251817
2,3251817
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
add a comment |
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
It was a Linux question but the information is appreciated anyway. It would be great if Linux had something like this.
– David Z
Aug 19 '10 at 3:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
Noun and verb, you mean.
– Warren Young
Aug 19 '10 at 13:19
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
D'oh! Fixed it.
– gvkv
Aug 19 '10 at 13:44
add a comment |
Just for completeness, in the low-level end of the spectrum I'd mention vipw(8) and vigr(8), just above "vi /etc/passwd" and "cat > /etc/passwd" but right below "useradd". Oh, and they exist in most Unix variants.
add a comment |
Just for completeness, in the low-level end of the spectrum I'd mention vipw(8) and vigr(8), just above "vi /etc/passwd" and "cat > /etc/passwd" but right below "useradd". Oh, and they exist in most Unix variants.
add a comment |
Just for completeness, in the low-level end of the spectrum I'd mention vipw(8) and vigr(8), just above "vi /etc/passwd" and "cat > /etc/passwd" but right below "useradd". Oh, and they exist in most Unix variants.
Just for completeness, in the low-level end of the spectrum I'd mention vipw(8) and vigr(8), just above "vi /etc/passwd" and "cat > /etc/passwd" but right below "useradd". Oh, and they exist in most Unix variants.
answered Aug 19 '10 at 8:52
codeheadcodehead
3,0681138
3,0681138
add a comment |
add a comment |
All of these tools are ultimately built to edit text files for you. If you want to know how to manage users and groups over systems, you should get familiar with these underlying text files. Lucky for you, there's just two of them, /etc/passwd and /etc/group. There are also complementary /etc/shadow and /etc/gshadow files for shadowing passwd and group respectively.
4
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
add a comment |
All of these tools are ultimately built to edit text files for you. If you want to know how to manage users and groups over systems, you should get familiar with these underlying text files. Lucky for you, there's just two of them, /etc/passwd and /etc/group. There are also complementary /etc/shadow and /etc/gshadow files for shadowing passwd and group respectively.
4
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
add a comment |
All of these tools are ultimately built to edit text files for you. If you want to know how to manage users and groups over systems, you should get familiar with these underlying text files. Lucky for you, there's just two of them, /etc/passwd and /etc/group. There are also complementary /etc/shadow and /etc/gshadow files for shadowing passwd and group respectively.
All of these tools are ultimately built to edit text files for you. If you want to know how to manage users and groups over systems, you should get familiar with these underlying text files. Lucky for you, there's just two of them, /etc/passwd and /etc/group. There are also complementary /etc/shadow and /etc/gshadow files for shadowing passwd and group respectively.
edited Aug 19 '10 at 20:25
answered Aug 19 '10 at 4:32
Eli FreyEli Frey
1,3281014
1,3281014
4
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
add a comment |
4
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
4
4
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
...and /etc/shadow, since most systems will croak if i is inconsistent with /etc/passwd
– codehead
Aug 19 '10 at 11:03
add a comment |
In many situations, knowing how to edit "/etc/passwd" is still useful.
1
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
add a comment |
In many situations, knowing how to edit "/etc/passwd" is still useful.
1
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
add a comment |
In many situations, knowing how to edit "/etc/passwd" is still useful.
In many situations, knowing how to edit "/etc/passwd" is still useful.
answered Aug 19 '10 at 2:28
Kevin CantuKevin Cantu
1,94631312
1,94631312
1
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
add a comment |
1
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
1
1
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Knowing how to read /etc/passwd is useful, but modifying it directly is a bad practice. On some *ixes I've used (modern SysV, OS X...) these files aren't the primary place the user and group data is stored. They're either shadow copies for compatibility, or they are primary sources but there is a database or index that needs to be updated whenever they change. On those systems, if you don't update the files through the official tools, the changes won't immediately take effect, if ever they do.
– Warren Young
Aug 19 '10 at 13:21
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
Just don't munge /etc/passwd
– Stefan Lasiewski
Aug 19 '10 at 17:02
add a comment |
If you are using a backend other than the default local machine backend - OpenLDAP being the most common - then cpu (change password utility) might be the command you are looking for. It can be run on machines other than the LDAP master if configured correctly, and it's syntax is mostly just the same as useradd etc with a prefix of cpu. So to add myself I could do
$ sudo cpu useradd hamish
See the cpu man page for more details.
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
add a comment |
If you are using a backend other than the default local machine backend - OpenLDAP being the most common - then cpu (change password utility) might be the command you are looking for. It can be run on machines other than the LDAP master if configured correctly, and it's syntax is mostly just the same as useradd etc with a prefix of cpu. So to add myself I could do
$ sudo cpu useradd hamish
See the cpu man page for more details.
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
add a comment |
If you are using a backend other than the default local machine backend - OpenLDAP being the most common - then cpu (change password utility) might be the command you are looking for. It can be run on machines other than the LDAP master if configured correctly, and it's syntax is mostly just the same as useradd etc with a prefix of cpu. So to add myself I could do
$ sudo cpu useradd hamish
See the cpu man page for more details.
If you are using a backend other than the default local machine backend - OpenLDAP being the most common - then cpu (change password utility) might be the command you are looking for. It can be run on machines other than the LDAP master if configured correctly, and it's syntax is mostly just the same as useradd etc with a prefix of cpu. So to add myself I could do
$ sudo cpu useradd hamish
See the cpu man page for more details.
answered Aug 19 '10 at 14:49
Hamish DownerHamish Downer
1,05587
1,05587
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
add a comment |
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
Interesting, but an answer that only applies on a machine which gets its user info from LDAP is of very limited use to me.
– David Z
Aug 20 '10 at 1:06
add a comment |
If your question was limited to
any Linux system (of any distribution)
but all of the systems have network access to a single server. You could use something like NIS or YP. So this answer is limited to admins within a single organization.
You still have the issue where almost every distribution has slightly different ways to configure YP, but configuration only happens once. Also, this type of network is not trivial.
Within a single site/network you will gain a lot doing this. In combination with automount, my favorite is being able to SSH to any *nix machine and have all my home files and tools available to me.
To the point, the distribution you choose for the master is the system you use for managing users. You then will have a single set of tools/documentation to manage users and groups.
It is even possible to use something like LDAP and samba tools on the master. Using samba also allows me to have my home files available to me on windows machines.
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
add a comment |
If your question was limited to
any Linux system (of any distribution)
but all of the systems have network access to a single server. You could use something like NIS or YP. So this answer is limited to admins within a single organization.
You still have the issue where almost every distribution has slightly different ways to configure YP, but configuration only happens once. Also, this type of network is not trivial.
Within a single site/network you will gain a lot doing this. In combination with automount, my favorite is being able to SSH to any *nix machine and have all my home files and tools available to me.
To the point, the distribution you choose for the master is the system you use for managing users. You then will have a single set of tools/documentation to manage users and groups.
It is even possible to use something like LDAP and samba tools on the master. Using samba also allows me to have my home files available to me on windows machines.
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
add a comment |
If your question was limited to
any Linux system (of any distribution)
but all of the systems have network access to a single server. You could use something like NIS or YP. So this answer is limited to admins within a single organization.
You still have the issue where almost every distribution has slightly different ways to configure YP, but configuration only happens once. Also, this type of network is not trivial.
Within a single site/network you will gain a lot doing this. In combination with automount, my favorite is being able to SSH to any *nix machine and have all my home files and tools available to me.
To the point, the distribution you choose for the master is the system you use for managing users. You then will have a single set of tools/documentation to manage users and groups.
It is even possible to use something like LDAP and samba tools on the master. Using samba also allows me to have my home files available to me on windows machines.
If your question was limited to
any Linux system (of any distribution)
but all of the systems have network access to a single server. You could use something like NIS or YP. So this answer is limited to admins within a single organization.
You still have the issue where almost every distribution has slightly different ways to configure YP, but configuration only happens once. Also, this type of network is not trivial.
Within a single site/network you will gain a lot doing this. In combination with automount, my favorite is being able to SSH to any *nix machine and have all my home files and tools available to me.
To the point, the distribution you choose for the master is the system you use for managing users. You then will have a single set of tools/documentation to manage users and groups.
It is even possible to use something like LDAP and samba tools on the master. Using samba also allows me to have my home files available to me on windows machines.
answered Aug 19 '10 at 12:51
Stephen JazdzewskiStephen Jazdzewski
44935
44935
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
add a comment |
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
Thanks, but I'm looking for an answer that applies just as well to non-networked systems.
– David Z
Aug 20 '10 at 1:07
add a comment |
The closest thing to a standard you'll get is vi /etc/passwd, vi /etc/shadow, and vi /etc/groups. (Heretics may substitute emacs.) Everything since then that I've found will only work on some systems.
Seriously, find out what tools your OS has, and use them. Just don't expect them to work the same on all systems. It would be nice if they were standardized, but they aren't.
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for/etc/passwd,/etc/shadow,/etc/group, and/etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.
– Aaron Toponce
Aug 19 '10 at 23:04
Never call an editor on/etc/passwdand friends directly. Usevipwandvigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.
– Gilles
Aug 20 '10 at 13:34
add a comment |
The closest thing to a standard you'll get is vi /etc/passwd, vi /etc/shadow, and vi /etc/groups. (Heretics may substitute emacs.) Everything since then that I've found will only work on some systems.
Seriously, find out what tools your OS has, and use them. Just don't expect them to work the same on all systems. It would be nice if they were standardized, but they aren't.
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for/etc/passwd,/etc/shadow,/etc/group, and/etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.
– Aaron Toponce
Aug 19 '10 at 23:04
Never call an editor on/etc/passwdand friends directly. Usevipwandvigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.
– Gilles
Aug 20 '10 at 13:34
add a comment |
The closest thing to a standard you'll get is vi /etc/passwd, vi /etc/shadow, and vi /etc/groups. (Heretics may substitute emacs.) Everything since then that I've found will only work on some systems.
Seriously, find out what tools your OS has, and use them. Just don't expect them to work the same on all systems. It would be nice if they were standardized, but they aren't.
The closest thing to a standard you'll get is vi /etc/passwd, vi /etc/shadow, and vi /etc/groups. (Heretics may substitute emacs.) Everything since then that I've found will only work on some systems.
Seriously, find out what tools your OS has, and use them. Just don't expect them to work the same on all systems. It would be nice if they were standardized, but they aren't.
answered Aug 19 '10 at 18:17
David ThornleyDavid Thornley
233215
233215
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for/etc/passwd,/etc/shadow,/etc/group, and/etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.
– Aaron Toponce
Aug 19 '10 at 23:04
Never call an editor on/etc/passwdand friends directly. Usevipwandvigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.
– Gilles
Aug 20 '10 at 13:34
add a comment |
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for/etc/passwd,/etc/shadow,/etc/group, and/etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.
– Aaron Toponce
Aug 19 '10 at 23:04
Never call an editor on/etc/passwdand friends directly. Usevipwandvigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.
– Gilles
Aug 20 '10 at 13:34
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for
/etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.– Aaron Toponce
Aug 19 '10 at 23:04
Using a text editor to edit configuration files that tools can, and should edit for you is not a standard. You should never use a text editor to change a configuration file, when the operating system, or application provides a utility to do this for you. This is especially true for
/etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow. This is what the tools are for. Humans are prone to error, whereas tools have been tested and are (hopefully) bug-free.– Aaron Toponce
Aug 19 '10 at 23:04
Never call an editor on
/etc/passwd and friends directly. Use vipw and vigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.– Gilles
Aug 20 '10 at 13:34
Never call an editor on
/etc/passwd and friends directly. Use vipw and vigr, which: lock the file against concurrent edition; run your favorite editor ($VISUAL); don't change the file if you make a syntax error; on some systems (e.g. FreeBSD) also regenerate other files that must be kept in sync.– Gilles
Aug 20 '10 at 13:34
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f745%2fwhat-is-are-the-standard-cli-programs-to-manage-users-and-groups%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
also
groupmod. I'm not going to make this an answer.... but the most standard way is probably to use your text editor... remember the files affected are just delimited text.– xenoterracide
Aug 19 '10 at 1:53
Interestingly, prior to asking this question, I had never once seen so much as a mention of directly editing the files. (Somehow I had the impression that
/etc/passwdwas just one part of a complex system)– David Z
Aug 19 '10 at 7:41