专题讨论之handbook版－第3章（讨论版）

hongzjx

没有这本书啊

网上有电子书下载
http://down.vv66.com/soft/153/4380.htm

剑心通明

原帖由 hongzjx 于 2005-10-25 09:40 发表

网上有电子书下载
http://down.vv66.com/soft/153/4380.htm

正在下载，多谢！

access-list

第8章 用户和基本的帐户管理
       
        在一个FreeBSD系统上不同用户帐户之间的区别。
                     如何添加用户帐户。
                     如何删除用户帐户。
                     如何改变帐户细节，如用户的全名，或首选的shell。
                     如何在每个帐户基础上设置限制，来控制像内存，CPU时钟这样的资源。
                     如何使用组来使帐户管理更容易。

我先写这章是因为我机器上的网卡还没装好，第四章packages和ports还没完全理解
第五章x－windown我不用就不看了，配置和调整和freebsd的启动过程的这几章没看懂，
就只能写这一章了，其实这一章没什么东西，很快就看完了，也不难理解，但我却搞了两天，你看我笨不笨 ，其实看手册没分先后顺序，那看懂了就认真看，看不懂就回头看。
   其实手册上的东西看上去写的东西很简单，也没什么东西，一会就看完，但有些时候并不是这样，短短的一句话，其实里面隐含着很多东西，关键你能否理解它内在的东西，以前我在学cisco时候有一位前辈说过，你知道为什么真正的hacker喜欢unix吗，因为在字符界面上能留给人思考的余地，但真正的意义并不在于字符或GUI，关键是能否掌握它的内蕴。
你知道文件和inode的关系吗？cpu和内存的调度是如何？找个问题，去看书，去找答案
活学活用，那本书上也没教。
8.2：介绍
用户名：在登陆时候唯一的标识，建立一个用户后，系统会建立一个和用户名一样的组。
password：和用户名配对，使用一个空的口令不是一个好主意，在用户登陆的时候，系统会在/etc/passwd中检查是否匹配，如果不匹配的话，在/etc/master.passwd中检查，如果都不匹配的话，那就拒绝登陆，当登陆完成后就是/home/username中和环境变量的那些profile的事了。
Uid：每个用户都有不同的uid，不管你转换成那个用户，你的uid还是不变的 ＃whoami
Gid：可以把多个用户划分到一个组中，方便管理。
登陆类：这个就是用户的详细类别，口令改变日期，帐户到期日期，fullname，和主目录
        主目录建议放在/usr/home/username中，这里的空间比较大。
Shell：就是用户进入系统后的环境变量，路径等各方面的设置，值得详细研究一下。
8.3
超级用户帐户：
  root，拥有系统最大权限，不受其他权限限制，就是老大了（FQ??）可以干他喜欢干的事，但使用时要小心，过火了就要郁闷了。不是重要的事情可以叫小弟去干（other user）.
8.4
系统帐户：
有事就叫小弟去干，不能什么事都自己操心，诸葛亮就是一个例子了，活干的越多，权力就越大，该用户占用的进程和拥有的权力就越大。不同的人干不同的活，做不同的事，不能一个人都干完了，Nobody是拿了钱，但活少，属门房一类，但谁进去都要给它打招服，和大家的关系密切。
钱多活少离家近，睡觉睡到自然醒，不变的真理啊。
8.6
修改帐户
使用adduser，rmuser， chpass，passwd，pw，不同的命令有不同的用法，功能强大，没有说谁好，谁不好，关键是顺手和熟悉运用。
8.6.1
增加用户：
   在增加用户前必须了解要增加什么用户，属那个组，如何查看，和它们关联的数据库是什么。增加后它们做了什么动作，不是简单的就加了一个用户就完事了。
在增加前先看一下/etc/share/skel,在这里有八个文件，都是以dot.xxxx开头的，最好man一下他们是什么的干活。大致了解一下。
   当建立了用户后那些数据库会变动呢，都变了些什么？
和用户关联的数据库有四个
/etc/passwd          /etc/pwd.db
/etc/master.passwd    /etc/spwd.db
当增加了用户后在
/etc/passwd可以看到新加的用户和它的兽行，用户shell和home目录等，密码是以*表示
/etc/master.passwd和上面的差不多，但密码表示方式不同，以汉列（hash）表示。都是加密。
/etc/pwd.db  /etc/spwd.db就是相关联的数据库，不能用cat或ee打开。
在看这些文件的时候有一点注意的就是在username和：之间的字符，正常登陆用户后面跟的是hash字符，锁定用户后面跟的是*,没有密码用户后面就是空的。

8.6.1
增加用户：
   adduser –v
当第一次建立用户的时候会建立一个模板，写到/etc/adduser.conf和/etc/adduser.message中，(我建完用户后就找不到这两个文件，还找了半天，以为是我用错了)
需要留意的是bsd默认如果新建一个用户，就以这个用户名建一个用户组，用adduser时候要留意看一下，后面的就是一些交互式的问答就可以了，如果不喜欢这个模板，使用
adduser –s改变可以了。进入用户目录可以看到多了八个文件，没错，就是从/etc/share/skel拷贝过来的，但变成了..XXXX,这些文件各有用处，如环境变量，path设定，邮件设定。主机访问权限等。
Rmuser：
  只有root才能使用，分别是删除用户的corntab记录，at job，用户的进程，本地口令文件记录，用户目录，邮件，再删除/etc/group中的用户。 Rmuser username，这样就可以安全点
chpass：更改用户个人设定
普通用户可以更改个人的shell，fullname，location等
root就可以更改所以人的用户设定

passwd：就是更改密码了。

8.6.5  
pw
   使用增加，修改，删除用户
pw useradd –n yuanl; -g sale –m –s /bin/csh   简单吧。
还麻烦的话就这个。echo <password>; | pw useradd -n yuanl; -g sale; -m -s /bin/csh -h 0

其他增加修改，删除用户组也是一样用法。Man一下就可以。

8.7
限制用户的行为
就是对用户使用环境修改cpu，内存使用数量磁盘分配等。
这个我也不太熟悉，不敢乱说。
完了。

打字太累，心里更郁闷，这些东西在网上google一下，一大把，在cu上02年就有人写过了，比我的还要详细。当写笔记吧，书读千编，其意自见。


Ps：有个问题想问问各位老大，也是我看这一章花了这么久的原因，
当我使用pw， adduser建立用户后，它老是骂我
pw: opteration not permitted
adduser: there was an error adding user.
就是不能建立用户，用/stand/sysinstall里建立，也是同样出错，不能建立。
后来重新安装一个系统就可以了，（bsd 5.4 mini安装，还安装了doc）我对比过两个系统中的/etc/passwd,/etc/master.passwd, /usr/sbin/pw, /usr/sbin/adduser, /usr/share/skel发现它们的权限都一样，内容也一样，就是不知道错在那。

剑心通明

你用的是root用户吗？

access-list

原帖由 剑心通明 于 2005-11-2 16:42 发表
你用的是root用户吗？

是的

hbaoy

Now that you know how to set up a useful environment for yourself, it's time to share the wealth.

It's very easy for a system administrator to ensure that each newly created user starts out with the same configuration files. For example, every user can receive the same customized prompt, shell variables, or hotkeys.

Whenever you create a new user, several default (and hidden, or dot, files) are copied into the new user's home directory. In FreeBSD, the source of these files is /usr/share/skel/. Any customizations you make to these files will be seen by all subsequently created users. Do note that you'll have to manually copy over any modified files to existing users.

It's useful to understand these files, as they apply to every user you create. Depending upon your needs, you'll probably end up removing some of the defaults, customizing others, and even adding a few of your own.

1.10.1 Default Files
Let's take a quick tour of the default files:

% ls -l /usr/share/skel

total 24

drwxr-xr-x   2 root  wheel  512 Jul 28 16:09 ./

drwxr-xr-x  27 root  wheel  512 Jul 28 16:06 ../

-rw-r--r--   1 root  wheel  921 Jul 28 16:09 dot.cshrc

-rw-r--r--   1 root  wheel  248 Jul 28 16:09 dot.login

-rw-r--r--   1 root  wheel  158 Jul 28 16:09 dot.login_conf

-rw-------   1 root  wheel  371 Jul 28 16:09 dot.mail_aliases

-rw-r--r--   1 root  wheel  331 Jul 28 16:09 dot.mailrc

-rw-r--r--   1 root  wheel  797 Jul 28 16:09 dot.profile

-rw-------   1 root  wheel  276 Jul 28 16:09 dot.rhosts

-rw-r--r--   1 root  wheel  975 Jul 28 16:09 dot.shrc


Note that each starts with the word dot. However, when the files are copied into a user's home directory, the dots turn into literal dots (.). Also, the files in this directory are owned by root, but when a new user is created, the copied over files will change ownership as they are placed in that user's home directory.

1.10.1.1 dot.cshrc
Let's examine each default file, starting with dot.cshrc. ( [Hack #2] introduced several .cshrc hacks.) If you'd like new users to receive your customizations, simply replace /usr/share/skel/dot.cshrc with your hacked version of .cshrc. Don't forget to rename the file as you copy it:

# cp /root/.cshrc /usr/share/skel/dot.cshrc


Here, I overwrote the default dot.cshrc by copying over the superuser's customized version of .cshrc. Although you could edit /usr/share/skel/dot.cshrc directly, you may find it more convenient to have a customized copy stored elsewhere.

All isn't lost if you already have existing users whom you'd like to receive this file. First, find out what users already exist and have home directories. This is a quick way to do so:

# ls /usr/home

dru    test


Since this system has only two existing users, it's an easy matter to copy over my customized .cshrc. I'm also a lazy typist, so I use ~ instead of typing out /usr/home. Also note that I have to remember to manually change ownership:

# cp /root/.cshrc ~dru/

# chown dru ~dru/.cshrc

# cp /root/.cshrc ~test/

# chown test ~test/.cshrc


If your system already contains many users, you'll probably prefer to write a script. Here is an example:

#!/usr/bin/perl -w



# copydotfiles.pl

#    - copy default files to user directories

#    - change ownership of those files

# You may wish to change these constants for your system:



use constant HOMEDIR => '/usr/home';

use constant SKELDIR => '/usr/share/skel';

use constant PREFIX  => 'dot';



use strict;



use File::Copy;

use File::Spec::Functions;



die "Usage: $0 <files> <to> <copy>\n" unless @ARGV;



for my $user ( get_users( ) )

{

    for my $dotfile (@ARGV)

    {

        my $source = catfile( SKELDIR( ),         PREFIX( ) . $dotfile );

        my $dest   = catfile( $user->{homedir},              $dotfile );



        if (-e $dest)

        {

            warn "Skipping existing dotfile $dest...\n";

            next;

        }



        copy(  $source,      $dest )

            or die "Cannot copy $source to $dest: $!\n";

        chown( $user->{uid}, $dest );

    }

}



sub get_users

{

    local *DIRHANDLE;

    opendir( DIRHANDLE, HOMEDIR( ) )

        or die "Cannot open home directory: $!\n";



    my @users;



    while (my $directory = readdir( DIRHANDLE ))

    {

        next if $directory =~ /^\./;



        my $path = File::Spec->catdir( HOMEDIR( ), $directory );

        my $uid  = getpwnam( $directory );



        next unless -d $path;

        next unless $uid;



        push @users, { homedir => $path, uid => $uid };

    }



    return @users;

}


This script first examines all of the users with home directories, returning a list of those directories and the user IDs. It loops through that list, copying each dot file you provided on the command line to that user's home directory and changing the ownership to the user.

If you run it as:

# copydotfiles.pl .cshrc


all users will receive a new .cshrc file, unless one already exists.

1.10.1.2 dot.login
The next file, dot.login, is used only by the csh and tcsh shells. If your users don't plan on using these shells, you can safely remove this file from /usr/share/skel. If your users do use those shells, consider whether there are any commands you would like to run when users log in. Note that this file is read after .cshrc.

By default, the only uncommented line in this file is:

% grep -v '#' /usr/share/skel/dot.login



[ -x /usr/games/fortune ] && /usr/games/fortune freebsd-tips


Here, I used the reverse filter switch -v to the grep search utility to look for all the lines that do not begin with the # comment symbol.

The resulting line tells the shell to run the fortune program. If you chose to install the games distribution when you installed FreeBSD, your fortune appears just before the MOTD whenever you login. Have you ever noticed that you don't receive a fortune when you use su? That's because .login is only read when you log in, and the default invocation of su does not actually log you in.

Instead, it opens what is known as a nonlogin shell. You also get one of those every time you open an xterm. Basically, the only time you get a real login shell is when you type in your username and password at a login prompt.

Herein lies the difference between .cshrc and .login. Place what you would like to happen only when you log in into .login, and place what you would like to happen whenever you use the csh shell, even if it isn't a login shell, into .cshrc. If you don't see the need for a difference, you don't need /usr/share/skel/dot.login.

1.10.1.3 dot.login_conf
Reading the default contents of dot.login_conf will give you an idea of its purpose and where to go for additional information:

% more /usr/share/skel/dot.login_conf

# $FreeBSD: src/share/skel/dot.login_conf,v 1.3 2001/06/10 17:08:53 ache Exp $

#

# see login.conf(5)

#

#me:\

#        :charset=iso-8859-1:\

#        :lang=de_DE.ISO8859-1:


Note that this file is commented by default, but shows the syntax a user can use to create a customized .login.conf. Usually such settings are set in the globally administrated /etc/login.conf file, and individual users can override only some of those settings. If your users don't have a need or the know-how to configure those settings, you can safely remove this file from /usr/share/skel.

1.10.1.4 dot.mail_aliases and dot.mailrc
The next two files work hand in hand and customize the behavior of man mail. Since it is quite rare to find users who still rely on the original mail program, you can safely remove those files.

hbaoy

继续

1.10.1.5 dot.profile
The dot.profile file is read by the Bourne, bash, and Korn shells. It is the only file read when a user logs into a Bourne shell, the first file read when a user logs into the Korn shell, and is optional for bash users.

If your users don't use the Bourne or Korn shells, there's not much sense populating their home directories with this file. Depending upon your slant, you may wish to keep this file in order to place path statements and environment variables for use with Bourne shell scripts. However, most users tend to place those directly into the script itself to allow for portability.

If your users wish to use the bash shell, which isn't installed by default, keep in mind that .profile allows a user to override the settings found in the global /etc/profile file. You may find it easier to make your edits to the global file and then remove /usr/share/skel/dot.profile. More sophisticated users can always create their own ~/.profile. However, most bash users tend to make their modifications to ~/.bash_profile.

1.10.1.6 dot.rhosts
Did you happen to notice in the earlier long listing that this file has different permissions from most of the other files? If you read man rhosts, you'll see that this file is ignored if it is writable by any user other than the owner of the file.

So, when is this file used? It's used when a user types one of the r* commands: rsh, rcp, or rlogin. I won't show you how to set up this file or use those commands, as they were designed for use back in the days when networks were considered trusted. They've pretty well been replaced by ssh and scp, which provide a much safer way to log into remote systems and to transfer files. For this reason, I always remove /usr/share/skel/dot.rhosts from my systems.

1.10.1.7 dot.shrc
The last default file is dot.shrc. As you may have guessed, it is the rc file for sh, the Bourne shell. Again, if your users don't log into that shell, they won't miss this file.

1.10.2 Missing (but Useful) Dot Files
Now that we've had the opportunity to look at the default files, it's time to consider any useful missing files.

1.10.2.1 dot.logout
We've already seen that ~/.login is read when a user logs into the csh or tcsh shells. Not surprisingly, ~/.logout is read when a user logs out of their login shell. This is an excellent place to put commands you would like to execute as a user logs out. It could be something as simple as:

# more dot.logout

# this line clears your screen when you logout

clear

# add your own commands or scripts, one line at a time,

# which you would like to execute

# whenever you logout and leave your terminal


This dot.logout will clear the user's terminal, making it much neater for the next person who logs in. Notice that I commented this file, so the user is aware of its use. When creating your own dot files, use lots of comments. If you intend for your users to customize their own dot files, use comments that explain the syntax they can use when they do their modifications.

dot.logout can run any command or script that suits a user's needs. Here are some ideas to get your imagination rolling:

A script that backs up the user's home directory

A script that shows how much time the user spent online

A script that displays other statistics, such as available disk space

1.10.2.2 dot.xinitrc
I also find it very useful to create a custom dot.xinitrc. By default, users receive the extremely lightweight twm window manager. Since I usually install KDE, this line ensures that each user will receive that window manager instead:

# more dot.xinitrc

exec startkde


You can also specify which programs you would like to launch when a user types startx and their ~/.xinitrc file kicks in. For example, this is a popular line to add:

# more dot.xinitrc

exec xterm &

exec startkde


This starts an xterm in the background. Notice the & at the end of its line—this is to ensure that once xterm loads, it doesn't interfere with any other programs that are still loading. When you're creating your own dot.xinitrc, you can start any program you like. However, start your window manager last. Start your other programs, one line at a time, putting an & at the end of each line. The only line that does not have an & will be the very last line, the one that loads your window manager.

Since I prefer to start my browser instead of an xterm, here is my customized dot.xinitrc:

#to start another program when you "startx", type:

#exec path_to_program &

#before these lines

exec /usr/X11R6/bin/mozilla &

exec startkde


There are dozens of possibilities for customized dot files. Take stock of your own systems, and ask yourself: "What programs do my users use?" For example, if your users use bash, vim, screen, procmail, or fetchmail, why not start them off with a customized configuration file that contains comments on how to add their own customizations and URLs of where to go for further ideas? A little homework and creativity on your part can help your users get the most out of the utilities they use on a daily basis.

1.10.3 Editing /usr/src/share/skel/Makefile
Let's end this hack by examining where the default dot files in /usr/share/skel came from in the first place. You'll find the answer here:

% ls /usr/src/share/skel

./            dot.login           dot.profile

../           dot.login_conf      dot.rhosts

Makefile      dot.mail_aliases    dot.shrc

dot.cshrc     dot.mailrc


That Makefile controls the installation of those files:

# more /usr/src/share/skel/Makefile



#        @(#)Makefile        8.1 (Berkeley) 6/8/93

# $FreeBSD: src/share/skel/Makefile,v 1.8 2002/07/29 09:40:13 ru Exp $



FILES1= dot.cshrc dot.login dot.login_conf dot.mailrc dot.profile dot.shrc

FILES2=        dot.mail_aliases dot.rhosts

MODE1=        0644

MODE2=        0600



NOOBJ=        noobj



all clean cleandir depend lint tags:



install:

        ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${MODE1} ${FILES1} \

            ${DESTDIR}${BINDIR}/skel

        ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${MODE2} ${FILES2} \

            ${DESTDIR}${BINDIR}/skel



.include <bsd.prog.mk>


Even if you've never read a Makefile before, you'll find it's not too hard to figure out what's going on if you already know which results to expect. In this Makefile, FILES=1 is simply a list of files to install. Take a look at MODE1; it tells the chmod command what permissions to set on those files.

Similarly, FILES=2 is another list of files. Those two files had different permissions, which were defined by MODE2.

Move down to the install section. Don't worry so much about the syntax; rather, notice the pattern. The first set of files are installed and their mode is applied. Then the second set of files are installed with their mode.

It's an easy matter to customize this file to reflect the dot files you'd like to see installed. In this example, I only want to install my custom versions of dot.cshrc, dot.login, and dot.xinitrc. Since they all require the first mode, I'll remove any references to the second set of files:

# cd /usr/src/share/skel

# cp Makefile Makefile.orig

# vi Makefile



#        @(#)Makefile        8.1 (Berkeley) 6/8/93

# my customized dot files to be installed into /usr/share/skel



FILES1= dot.cshrc dot.login dot.xinitrc

MODE1=        0644



NOOBJ=        noobj



all clean cleandir depend lint tags:



install:

        ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${MODE1} ${FILES1} \

            ${DESTDIR}${BINDIR}/skel



.include <bsd.prog.mk>


Now let's try a test run. I'll replace the default dot files found in /usr/src/share/skel with my customized versions. I'll then remove the contents of /usr/share/skel and see what happens when I run my customized Makefile:

# cd /usr/src/share/skel

# rm dot.*

# cp ~/mystuff/dot.* .



# rm /usr/share/skel/*

# ls /usr/share/skel



# make install

install -o root -g wheel -m 0644 dot.cshrc dot.login dot.xinitrc

    /usr/share/skel

# ls /usr/share/skel

dot.cshrc    dot.login    dot.xinitrc


I find it very handy to keep a copy of my customized Makefile and dot files in a separate directory, in this case ~/mystuff. This ensures they are backed up. It's easy for me to grab those files whenever I want to customize a particular system.

It's especially important to use a separate location if you use cvsup to keep your system up-to-date. Otherwise, your next update will notice your modified src and happily replace those missing original source files. But don't worry; it won't touch your new /usr/share/skel.

Of course, sometimes this is a very useful trick in itself. If you ever mess up a file located somewhere within /usr/src, a quick cvsup will put everything back the way it was. See [Hack #80] for details on automating cvsup.

1.10.4 The Other BSDs
The preceding discussion is based on FreeBSD, but it also applies to NetBSD and OpenBSD systems, save for a few tiny differences outlined here.

1.10.4.1 NetBSD
NetBSD administrators will find the skeleton home directory in /etc/skel. Specify a different location by passing the -k option to useradd.

1.10.4.2 OpenBSD
OpenBSD systems store the skeleton home directory in /etc/skel. Specify a different skeleton directory location by passing the -dotdir option to adduser.