|
|
UNIX / Linux Tutorial
2.6.5 Groups | 2.6.6 System Administration Responsibilities | 2.6.7 Coping With Users
2.6.8 Setting The Rules | 2.6.9 What It All Means | 2.7 Archiving And Compressing Files
2.7.1 Using tar
2.6.5 Groups
As mentioned above, each user belongs to one or more groups. The only real
importance of group relationships pertains to file permissions. As you'll recall,
each file has a "group ownership" and a set of group permissions which defines how
users in that group may access the file.
There are several system-defined groups, like bin, mail and sys. Users should not
belong to any of these groups; they are used for system file permissions. Instead, users
should belong to an individual group like users. You can also maintain several groups
for users, like student, staff and faculty.
The file /etc/group contains information about groups. The format of each line is:
group name : password : GID : other members
Some example groups might be:
root : * : 0 :
users : * : 100 : mdw , patrick
guest : * : 200:
other : * : 250:kiwi
The first group, root, is a special system group reserved for the root account. The next
group, users, is for regular users. It has a GID of 100. The users mdw and patrick
have access to this group. Remember that in /etc/passwd each user was given.
a default GID. However, users may belong to more than one group, by adding their user
names to other group lines in /etc/group. The groups command lists what groups
you are given access to.
The third group, guest, is for guest users, and other is for "other" users. The user
kiwi is given access to this group as well.
The "password" field of /etc/group is sometimes used to set a password on group
access. This is seldom necessary. To protect users from changing into privileged
groups (with the newgroup command), set the password field to "*".
The commands addgroup or groupadd may be used to add groups to your system.
Usually, it's easier just to add entries in /etc/group yourself, as no other configuration
needs to be done to add a group. To delete a group, simply delete its entry in
/etc/group.
2.6.6 System Administration Responsibilities
Because the system administrator has so much power and responsibility, when some
users have their first opportunity to login as root. either on a Linux system or elsewhere,
the tendency is to abuse root's privileges. I have known so-called "system administrators"
who read other users' mail, delete users' files without warning, and generally behave like
children when given such a powerful "toy".
Because the administrator has such power on the system, it takes a certain amount of
maturity and self-control to use the root account as it was intended—to run the system.
There is an unspoken code of honor which exists between the system administrator and the
users on the system. How would you feel if your system administrator was reading your
e-mail or looking over your files? There is still no strong legal precedent for electronic
privacy on time-sharing computer systems. On UNIX systems, the root user has the
ability to forego all security and privacy mechanisms on the system. It is important that the
system administrator develop a trusting relationship with his or her users. I can't stress that
enough.
2.6.7 Coping With Users
System administrators can take two stances when dealing with abusive users: they can
be either paranoid or trusting. The paranoid system administrator usually causes more harm
than he or she prevents. One of my favorite sayings is, "Never attribute to malice anything
which can be attributed to stupidity." Put another way, most users don't have the ability
or knowledge to do real harm on the system. Ninety percent of the time, when a user causes
trouble on the system (for instance, by filling up the user partition with large files,
or running multiple instances of a large program), the user is simply unaware that he or she
is creation a problem. I have come down on users who were causing a great deal of trouble,
but they were simply acting out of ignorance—not malice.
When you deal with users who cause potential trouble, don't be accusatory. The burden
of proof is on you; that is, the rule of "innocent until proven guilty" still holds. It is
best to simply talk to the user and question him or her about the trouble instead of being
confrontational. The last thing you want is to be on the user's bad side. This will raise a
lot of suspicion about you—the system administrator—running the system correctly. If a
user believes that you distrust or dislike them, they might accuse you of deleting files or
breaching privacy on the system. This is certainly not the kind of position you want to be
in.
If you find that a user is attempting to "crack," or otherwise intentionally do harm to the
system, don't return the malicious behavior with malice of your own. Instead, provide a
warning, but be flexible. In many cases, you may catch a user "in the act" of doing harm to
the system. Give them a warning. Tell them not to let it happen again. However, if you do
catch them causing harm again, be absolutely sure that it is intentional. I can't even begin
to describe the number of cases where it appeared as though a user was causing trouble,
when in fact it was either an accident or a fault of my own.
2.6.8 Setting The Rules
The best way to run a system is not with an iron fist. That may be how you run the military,
but Linux is not designed for such discipline. It makes sense to lay down a few simple
and flexible guidelines. The fewer rules you have, the less chance there is of breaking them.
Even if your rules are perfectly reasonable and clear, users will still at times break them
without intending to. This is especially true of new users learning the ropes of the system.
It is not patently obvious that you shouldn't download a gigabyte of files and mail them to
everyone on the system. Users need help to understand the rules and why they are there.
If you do specify usage guidelines for your system, make sure also that the rationale for
a particular guideline is clear. If you don't, users will find all sorts of creative ways to
get around the rule, and not know that they are breaking it.
2.6.9 What It All Means
We don't tell you how to run your system down to the last detail. That depends on how
you're using the system. If you have many users, things are much different than if you have.
only a few users, or if you're the only user on the system. However, it's always a good
idea—in any situation—to understand what being the system administrator really means.
Being the system administrator doesn't make a Linux wizard. There are many administrators
who know very little about Linux. Likewise, many "normal" users know more about
Linux than any system administrator. Also, being the system administrator does not allow
one to use malice against users. Just because the system gives administrators the ability to
mess with user files does not mean that he or she has a right to do so.
Being the system administrator is not a big deal. It doesn't matter if your system is a
tiny 386 or a Cray supercomputer. Running the system is the same, regardless. Knowing
the root password isn't going to earn you money or fame. It will allow you to maintain
the system and keep it running. That's it.
2.7 Archiving And Compressing Files
Before we can talk about backups, we need to introduce the tools used to archive files
on Unix systems.
2.7.1 Using tar
The tar command is most often used to archive files. Its command syntax is :
tar options files
where options is the list of commands and options for tar and files is the list of files to
add or extract from the archive.
For example, the command:
# tar cvf backup.tar /etc
packs all of the files in /etc into the tar archive backup.tar. The first argument to
tar,"cvf", is the tar "command." c tells tar to create a new archive file. v forces
tar to use verbose mode, printing each file name as it is archived. The "f" option tells
tar that the next argument, backup.tar, is the name of the archive to create. The rest
of the arguments to tar are the file and directory names to add to the archive.
The command :
# tar xvf backup.tar.
will extract the tar file backup.tar in the current directory.
Old files with the same name are overwritten when extracting files into an existing 3
directory.
Before extracting tar files it is important to know where the files should be un-packed.
Let's say that you archive the following files: /etc/hosts, /etc/group,
and /etc/passwd. If you use the command :
# tar cvf backup.tar /etc/hosts /etc/group /etc/passwd
the directory name /etc/ is added to the beginning of each file name. In order to extract
the files to the correct location, use :
#cd /
# tar xvf backup.tar
because files are extracted with the path name saved in the archive file.
However, if you archive the files with the command:
# cd /etc
# tar cvf hosts group passwd
the directory name is not saved in the archive file. Therefore, you need to "cd /etc" before
extracting the files. As you can see, how the tar file is created makes a large difference
in where you extract it. The command :
# tar tvf backup.tar
can be used to display a listing of the archive's files without extracting them. You can see
what directory the files in the archive are stored relative to, and extract the archive in the
correct location.
1.1 Introduction 1.2.10 Referring To Home Directories 1.3.4 Copying Files
1.6 Exploring The File System 1.8 Wildcards 1.9.3 Pipes 1.10.3 Permissions Dependencies
1.12.4 Stopping And Restarting Jobs 1.13.3 Inserting Text 1.13.9 Including Other Files
1.14.3 Shell Initialization Scripts System Administration 2.3.1 The /etc/imitate file
2.4 Managing File Systems 2.6 Managing Users 2.6.5 Groups 2.7.2 gzip and compress
2.8.3 Making Backups To Tape Devices 2.9.1 Upgrading The Kernel
2.9.3 Installing A Device Driver Module
BOOK: LINUX QUICK COMMAND REFERENCE
http://personal.atl.bellsouth.net/~psadler
© copyright KnowledgeWorks, Inc. (2001)