i'm still new to understanding how linux works so i want to make sure i dont' screw up anything on the server. with my new job i'm the only one that is supposed to be log into the webserver but there are a couple of accounts that i don't know who's they are. looks like they haven't been used in a while. i'd like to do 2 things:

1) remove the old accounts
2a) remove the admin account
2b) or if removing the admin account will screw things up least change the password.

will programs still be able to run if they were installed by user "admin"?


reason for wanting to remove admin account is that i've been reading about some worms out there looking for servers with the common "admin" username.
will that break anything?
thanks again,
disorderly

Everything I've ever read has said to not delete user accounts, but to disable them. As for things still running if you disable the admin account, perhaps they will not. You may have to log in as root and change the ownership (man chown) of the program/process.

Ok, a number of things... I apologize... I'm "wordy"

#1) To delete an account, you can use the userdel command. You can accomplish the same thing manually by these 4 steps: remove the user's line from /etc/passwd, remove the user's line from /etc/shadow (if your system uses shadow passwords), remove the username from /etc/groups, and remove the user's home directory.

#2) smithtodda gives very good advice. You should disable an account before deleting it. If people are using the account, they will complain when they can't log in, and if the account is needed for day-to-day processes, the jobs will die with an error. It's much easier to reactivate an account than trying to reconstruct it from scratch (i.e. config files).

#3) Usually, a computer has "system" accounts. Accounts such as "mail", "uucp", "ftp", "nobody", etc. All of these accounts are usually numbered below user ID 100, 500, or 1000 (depending on your system). There's no magic number... it's just an arbitrary line-in-the-sand to organize accounts. These accounts do not correspond to real people. They are used to restrict a program's abilities. For instance, your mail program will likely run as user "mail" and be given ownership of one or more directories. That way, the mail program can record incoming mail on your system (it has write access), but it can only write to the directories it's explicitly given permission to. This is a method of restricting the power of automated tools on the system. You don't want to delete or disable any of these accounts.

#4) Removing a user account typically does not "break" any programs owned by that user on a system. The only exceptions to this are programs that check who they are when executed. For instance, some scripts are written to run only as root. Others are written to run as any user other than root. I would say 95% of all programs will still run even if the owner no longer exists

#5) If you're worried about the "admin" username, then you can change it. Open up /etc/passwd and change "admin" to "adm" or "manager" or whatever suits you. There's nothing special about the name admin. This is probably the best route to take, because it will highlight any programs that check what user is running them. If something breaks, you can try to fix it (change the expected name in the script) or just change the username back to admin.

#6) To change the password of admin, execute the following as the root:Alternatively, if you're logged in as admin, you can change the password by executing "passwd" by itself.

#7) Last thing I wanted to mention: the admin account is no different from a regular user account from the system perspective. A virus that wants to infect your system must jump through the same "hoops" to infect the admin account as any other on the system. That's done by brute force password cracking or finding a security hole in services provided. Typically, virus writers will target the root account of a system before anything else. The reason is once root is compromised, the virus can spread at will; it can do anything to the system it wants. That's not to say a virus can't focus on admin, but once admin is compromised, the virus is still limited in what it can do to the system. Permissions vary widely for admin accounts from one system to the next. If both the root password and the admin password are strong, then neither is easier to crack than the other. And if a cracker/virus has to work just as hard to compromise either of two accounts, why waste time compromising one that gives limited access when the other gives unlimited? Again, not saying there isn't any malware out there targeting admin, but from a logical standpoint, it would seem to be a waste.

As a side note, have you tried Webmin? you can get it Here It is a WONDERFUL program that helps with Linux administration and will prevent many a hair pulling days. I HIGHLY recommend it.

Travis

tbeehler after you mentioned webmin remembered seeing it in the list of software onteh machine so i tried port 10000 and there it was!! i logged in as root ( i didn't know you could do that - kinda scares me actually) right over the web.

Dark_Helmet - thank you so much for your 'wordy' reply it really made alot of things much clearer i got thrown into this position and have to learn alot about linux administration and FAST.
just as you and smithtodda said i'm going to try and disable the admin account instead of removing it. the only thing i can imagine it would affect would be proftpd - i ftp in using proftp's admin account but don't know how to modify it.

one other thing - when you install programs on linux, i've found you sometimes have to be root to do it. i thought whatever you are logged in as = the permissions the program then is given - right?

this is a great forum!
thanks so much again,
- disorderly

Technically, you don't need to be root to install software. You only need to be a user that has appropriate write permissions for each directory that receives files as part of an installation. I'll try to illustrate with an example. Say you downloaded a source code tarball of some software you want to install. Typically, you need to run a configure script after extracting the source code. 95% of the time, that configure script will accept a command line option of "--prefix=<some directory>". The directory specified becomes the top, containing directory for all the files copied as part of the "make install" procedure. So, if you wanted to install this software for you to use, and you alone, you could specify "--prefix=/home/disorderly/local_install". Then, you (as user disorderly) could "make" and "make install" the software without becoming root. The program and all its files would be stored inside subdirectories within /home/disorderly/local_install. In fact, you would probably see a number of subdirectories made: bin, etc, lib, and others.

There are a couple problems with this though. You would need to add the /home/disorderly/local_install/bin directory to your PATH (which isn't a big deal really), but anyone else that wanted to use the software would have to do the same. In addition, everyone else using the system would need read and execute permission for each directory in the path, and on the program itself. That, or they could simply install it locally themselves with the same --prefix routine. Clearly, that's not ideal, because you don't want to consume the disk space for 1,000 installation copies of the same program.

That's the purpose behind directories such as /bin, /usr/bin, and /usr/local/bin. All users default to accessing those directories and "share" system utilities found in them. Root is typically the only one with write access to those directories. Depending on your perspective, this is a security precaution. You don't very well want any random Joe Blow user to replace the system utility "ls" with one they have written themselves. That could be catastrophic for a number of reasons: the program could be flawed, and simply unusable. The program might have a critical bug that causes it to delete files. The program may work perfectly, except that it spawns a key logger, and mails the author a list of passwords typed in (a Trojan horse). So, the system relies on the root account to install legitimate software, and that only root can change that software. That's why you need to be root to install a lot of software. By default the configure script is set up to copy executables and configuration files to those directories maintained by root.

When a program is executed on the system, it inherits the user ID of the person that executed it. Again, this is a security precaution, because you don't want your system to get fubar'ed by a regular user accidentally typing "rm -rf /*". However, that doesn't address the Trojan horse situation mentioned before; every user has the ability to monitor their own keystrokes, and every user (probably) has the ability to email any other user on the system, or on the internet for that matter.

It's tradition for root to own those basic shared directories and maintain them, but as always, that doesn't have to be the case. You can change the ownership of those directories to another user, or you can change their group ownership. Then the new owner, or members of the new group can place files in those directories. You just need to make sure the appropriate permissions are set.

Wow. Good stuff, DARK_HELMET. Thanks for taking the time to explain it so thoroughly.

bravo Dark_Helmet! bravo! thank you very much for explaining it so clearly! i understand much better. next step is to figure out how to structure the permissions!

thanks again,
disorderly

You can change the port number that webmin uses if you'd like. Just go into webmin and look under the Webmin Configuration button and Ports and Addresses. Also, you can set up SSL on it if you'd like. I did and it makes me sleep better at night.

Travis

tbeehler i'm glad you told me that - iknowing that webin lets you log in as root over the browser has me worried...
thanks man,
disorderly

Don't quote me, but I think you can tell webmin not to allow root to logon. Check the documentation on it to be sure though. Always glad to be of service. I just got done with a wonderful crash course in Sendmail's AUTH process.

Travis

Added notes on "system users"
Look at their shells in the passwd file. Notice things like nologin or false.

As for nuking regualr systems off the system... userdel -r will remopve the account and their home directories, but that user may have had files all over the system... ie /tmp, /var etc. If you delete the account, then any files owned by them will now show that they are owned by a user id number rather than a name.

If you encounter something like a file owned by 502, then you have files that have no human user assciated with them.

find / -name 502 -exec rm -fr {} \;
will search for all files owned by the old user that had user id 502 and then remove them. Of course you also use chown someuser:somegroup instead of rm -fr.


try something like

cpl notes on webmin...
1st, webmin allows tcpwrappers to restrict what IP addresses can be used to log in from.
2nd. Webmin can be used with the net:ssleay perl plugin to allow access only via https

3rd the default login is admin and you can also add any user name you want and specify what exactly that user can do with webmin. It is great for designating duties to other users with a nice GUI based tool.

finally.. No one forces anyone to use webmin. Security measures depend on a person's paranoia. If you think webmin is insecure, it is. But once ya tighten it up, it is no different than using ssh.