First of all, if you reply to this thread, please fork the subject line... <grin> On Thu, 13 Dec 2001, Brent Harding wrote: > The one thing rh does do is offer to fix up the permissions > when you name change, move the home directory, I believe. If you are talking about using usermod only to change a user name, then no, it does not offer to fix up permissions or ownership, for the simple reason that it is not necessary, nor is it necessary to move (ie, rename) the home directory (but with the right options it can do that last, and a bunch of other things). Also, usermod is not Red Hat specific. There seems to be some confusion about how these things work, which has led to some unnecessarily complicated instructions about how to do it. The adduser command should not be necessary at all when merely changing a username: usermod will suffice, all by itself, with NO other commands. In particular, usermod is smart enough to change the name of the users mailbox when using the -l option, though this behavior is not documented in the man page. The permissions and ownership (UID,GID _numbers_) can and should remain the same. Perhaps a quote from the shadow password HOWTO, included in the same utility package, will clarify things: The /etc/passwd file also contains information like user ID's and group ID's that are used by many system programs. Therefore, the /etc/passwd file must remain world readable. If you were to change the /etc/passwd file so that nobody can read it, the first thing that you would notice is that the ls -l command now displays user ID's instead of names! Lest there be some misunderstanding, due to ambiguity, as there was before, let me point out that the author is refering to ownership names, not the filenames. More clarification in the longish next section. Users who understand how this stuff works, and haven't been confused by the misinformation or misunderstanding in the previous posts, can skip to the word "shifting", (in pine, start the search entry with the "w" key), where I answer other related posts about new admin utilities, upgrades, fetchmail, and security, that have been spawned by this thread. > At 12:37 PM 12/13/01 -0800, you wrote: > >On Wed, Dec 12, 2001 at 08:32:36PM -0700, L. C. Robinson wrote: > >> On Wed, 12 Dec 2001, Rafael wrote: > >> > >> > On Wed, Dec 12, 2001 at 03:42:38PM -0700, L. C. Robinson wrote: > >> > > It seems to me that it would be much easier to just change > >> > > the username on such an account. Do: man usermod for > >> > > details. > >> > > >> > That won't take care of user's mailbox name and it's > >> > permissions nor it will change the ownership of files in user's > >> > home dir as far as I know. At least it won't work that way in > >> > all versions of Unix. > >> > >> On the contrary. The filesystem does not store user names in the > >> directory structure. Do "ls -ln" on your home dir, to see what > >> there really is. Now do "id", to see what your id numbers are. > >> So when you change a username, it just changes the appropriate > >> mapping table (/etc/passwd), which file utilities like "ls" use. > >> Now, if you want to change user id numbers -- that can get hairy; > >> but there are automated ways to do that too. And take my word > >> for it, that IS standard Unixen behavior. > >File names are stored in the directory structure. One file > >keeps names of files in a directory. Where else do you think > >they reside? Hard drive brackets? ;-) In Unix everything is > >treated as "files" including hardware devices. Perhaps I overlooked some ambiguity in my explanation (maybe I was more tired than I thought). My apologies. The reference I made to user names was to ownership, not filenames, which should have been obvious by the context (what do you think the -n option to ls does)? Excessively rude replies can be embarrassing! You are, of course, quite right about filenames: I never said otherwise. > >Changing user ID numbers is trivial, one command line. Maybe to a power user, who knows how to pick just the right command or utility, in just the right situation. But that command might have to change the ownership id numbers on perhaps hundreds of files scattered all over the filesystem. Remember, we are trying to tutor some relatively new users. > >You need to rename the mailbox file manualy otherwise it won't > >belong to the right owner as far as MTA is concerned. As far > >as I know, tools that change the login name won't touch other > >things like mailboxes which is good. But, as we have seen, usermod is smart enough to rename it for you. Make a dummy user account and try it. For newbies: Remember to remove or disable the dummy account afterward, for security, -- don't be afraid to experiment, it's a great way to learn. Try removing only the passwd entry at first, (use vipw, not a raw editor, and make a backup copy of the passwd file first), then list the now orphaned user directory with "ls -l", and see what happens to the owner and group fields: you'll understand things a lot better if you actually see it. Now list the mail spool directory (/usr/spool/mail), and observe the same thing (you should be able to spot a difference, too). > >If you change name only in the passwd file then yes, you do > >not need to change the ownership of the home directory. So apparently, you do understand the filesystem structure, relative to permissions and ownership. Do you see how your previous posts could have been confusing to newbies? > >However, you were talking about adduser command before usermod > >which would create a new user with different UID. I see now that you must have been thinking I was advocating using usermod after things were messed up by an unnecessary adduser command. I was, in fact, trying to point out a utility that could simplify the whole problem, not fix the previous "error" with adduser. The easiest way to fix a bogus new account that is in the way of a rename is to just rename it (with usermod), or use userdel. Good practice to do both, for a new admin. Anyway, the original poster got some good experience doing things manually, and can appreciate the better tools. *** shifting subject focus: > >In any case you'll run into some issues if files in home > >diretory have been customized for a particular user based on > >the login name and you change the name so some handwork will > >be needed. X windows managers setup is one of them. Do you mean, for instance, if you have in .fetchmailrc: server mailhost.myisp.com proto pop3 username director there is jondo here password passxxxxx that you might need to change your local user name in there, too? A good reminder. <snip> > >> BTW, I was reading the new Red Hat manuals about the new > >> sysadmin utilities last night, and I was impressed. They > >> have some very readable tutorials, much of which would apply > >> to any distribution, particularly the text mode utilities... And to reply to a different post, asking about these: the best way to find out about them is to download the new RH7.2 manuals and look over the table of contents, then read the sections that interest you. Or read them on the web, if you prefer. If you've already upgraded to RH7.2, you may have already installed them on your hard disk, or have them on the documentation CD. And you can probably download and upgrade or add just the packages you want. If the binary versions won't install because of different library versions, you can probably just do: rpm --rebuild package.src.rpm on corresponding source rpm packages, to make a usable binary rpm. If you are new to Linux, you may not know that it is not necessary to keep up with the latest releases of your distribution, on a constant upgrade treadmill, like in the proprietary OS world. In fact, it can be rather counterproductive to do so, depending on your needs. In the proprietary M$ world, this forced upgrade cycle has pretty much destroyed the productivity gains on corporate investment in new computers and software, according to studies and experience. But it is critical that you keep up with security patches for the version that you do use. Failure to do so is, by far, the most serious security problem on the internet, regardless of what OS you use. For instance, security researchers in the Honeynet project have found that a pristine install (no security patches or anything) of Red Hat 6.2 lasts, on average, only 72 hours, before being cracked into. M$ stuff, less than a day. This issue is often overlooked: it was mentioned in the recent security thread on this list, but only in passing. You will need an automated tool to keep up with this: most of the professionals can't (and usually don't) keep up without such tools. <snip> LCR -- L. C. Robinson reply to no_spam+munged_lcr@onewest.net.invalid People buy MicroShaft for compatibility, but get incompatibility and instability instead. This is award winning "innovation". Find out how MS holds your data hostage with "The *Lens*"; see "CyberSnare" at http://www.netaction.org/msoft/cybersnare.html