Unix System Administration Pt 1 - Day 1

Admin

Goals

In this session you will:

• Refresh your understanding of Unix Philosophy and history
• Your role as admin/user
• Divide administrative tasks into Strategic, Tactical (usually cronjobs), or User requests.
• Learn how to set up a new user
• Learn how to delete a user

Unix Background Refresher

• Arbitrary, cryptic (cat)
• job-oriented (individual processes, based on users)
• ownership (chown/chgrp) and permissions (chmod) oriented, based on user and group
• "the user" != "the person" (whoami)
• simple, chainable programs that "do one thing well"

Admin / User

Even the root user is a user (sometimes called the superuser or "god"). You will log in as a user normally, and will only be root when absolute necessary. Login as a regular user at all times when it is not explicitly necessary to be root. You can su to root when necessary (it may be impossible to telnet or ssh in as root).

Danger!

It is a common beginner's mistake to log on as root even when unnecessary. This will cause massive trauma to the system the first time you do a rm -rf somewhere you shouldn't.

Trick of the Trade

In many shells, the prompt changes to a "#" when you are root.

If for some odd reason a trusted user needs to perform some root-like functions, you can give her sudo rights (see below).

finding your feet on a new box

• note login info
• eyeball filesystem setup in /etc/fstab
• check for the presence of crucial software
• check for the presence of a C compiler
• take the system's temperature on critical performance metrics (later sessions)

Day-to-Day tasks

• Strategic (big picture)concerns
  • What is this box supposed to do?
  • What do I, as admin, need to do to make that happen?
  • What resources (vendor or institutional support do I have? What UGs exist?
  • Stay advised of technical and security concerns about your box and services
  • peer information in newsgroups
  • continue to refine your security, resource, and network strategy (discussed under user section)
• Tactical (local) concerns
  • read administrative mail (alias the root address). You may find procmail or other filters useful for sorting your mail.
  • tail -f logfiles every once in a while, or use cron to email them to the admin email (discussed later).
  • stay aware of server load (w, top), diskspace usage (df, du), and backup integrity (tar, zip), and security violations (discussed later).
  • keep users informed with your MOTD
• User-related requests This section will frequently represent the bulk of your admin workload, and the majority of our classtime...

USER: Adding a new user

1. Think first, type later.
2. pick a username. unambiguous (l10O)

   Trick of the Trade

   You can save a bunch of time in the future by enforcing the use of official rather than personal logins on your system. e.g., "sales" is much better than "fred", because fred won't be there in two months and then you have to convert everything for the next salesperson. Better to leave it "sales" and reset the password when Fred moves on. Which will happen.

3. consider which group this user will be in (review of group), based on their needs.
4. come up with a password, or use a password generator
5. useradd [login] (or adduser, or similar)
6. tail /etc/passwd to see if it looks right to you: home dir, login shell

   Trick of the Trade

   The format of the password file is usually something like this: username:encrypted_passwd:UID:GID:user_info:~homedir:shell bob:xxy3JJdewlk:105:506::/home/bob:/bin/csh notice that the passwd field is encrypted and not even root can read it. you can temporarily lock out an account by prepending an "*" or something to the front of the encrypted_passwd bob:*xxy3JJdewlk:105:506::/home/bob:/bin/csh you can semi-permanently lock out an account by replacing the encrypted_passwd with an "*". You'll have to passwd [username] later to allow them access again. bob:*:105:506::/home/bob:/bin/csh you can keep a user from telneting in by setting the shell to "/dev/null" or "/bin/false" (may affect other services like FTP). You may have to edit the /etc/shells config file. bob:xxy3JJdewlk:105:506::/home/bob:/dev/null If the passwd field contains an "X", the passwd file is likely shadowed. (More on this under security) bob:X:105:506::/home/bob:/dev/null

7. telnet localhost and login as them to see if it works
8. send login information to the user, including hostname, username, and password. And the way to contact you when they can't log in. :-)

USER: deleting a user

• destroy user's login after writing down UID: [editor] /etc/passwd (and /etc/shadow )
• destroy user's home directory: cd ~username ; cd .. ; rm -rf username
• destroy user's mailspool: rm /var/spool/mail/username
• destroy web or ftp space if granted
• remove user from groupfile. Look for both UID and username in groupfile: [editor] /etc/group
• if you expect lots of mail for this user, alias the username in sendmail.cf (beyond the scope of this course)

sudo p9-11

The user will be prompted for their pass and will be able to run the app as root for a limited amount of invocations (generally 1) or for a number of minutes (generally 5).
This behavior is controlled by a /etc/sudoers file.

Danger!

Do not allow sudo to shell scripts or any app that has a shell in it

Homework

1. Permissions. 25-34
2. groups p191-197
3. Backups. 467-478, 489-494, 509
4. Tar. 478-480, 484
5. Cron jobs. 381-389

© 1994-2002 jason carr.
distributed under the terms of the GNU Free Documentation License.

jason carr

Reminders

• Classroom temperature can be wildly variable. Dress lightly and bring layers.
• your username is based on the class title and the last two digits of your workstation's hostname.
• remember to take your work with you.