• Does the account name exist? If no, you will not be able to log in
• Is the login name "root"? If so, prompt only for local password
• Prompt for "AFS Password", which is the kerberos password for the given ID. Note that if you duplicate a SUNeT ID on your machine, that SUNeT ID will be able to log into your system. AFS passwords are "sufficient" in the PAM sense, so if this password is correct, the person can log in
• If the AFS password is wrong, prompt for local password.

This may not be what you want. If you only want to use local passwords, do not use the AFS auth mechanism. Suppose you want to allow all SUNeT ID's to log in. You again use the PAM module, buth also run "authconfig" and configure hesiod support (just check it, the values should be filled in automatically). Hesiod will act as an addition to your /etc/passwd, mapping user names to home directories (AFS directories, mind you). Please see the hesiod documentation in redhat for more information on how hesiod works.

Another possibility is you want the local users to auth using *both* their local ID and their SUNeT ID. To do this, you must edit the PAM configuration. I personally have not done this, but I believe all you should have to do is change the word "sufficient" for the PAM AFS module to "necessary". If you can confirm this, please email sulinux-help and let me know.

The last possibility is you want leland system cluster solaris style auth, i.e. AFS passwords but reading .klogin to map user names to SUNeT IDs. Notice the subtle difference. In the default scheme, the username in /etc/passwd maps directly and automatically to a SUNeT ID for normal users. In this scheme, the username in /etc/passwd doesn't correspond to a SUNeT ID, but any principle (SUNeT ID) listed in the home directories .klogin file can log in. To enable this, replace /bin/login with /etc/leland/login.krb. NOTE: login.krb doesn't work with MD5 shadow files, so please make sure you use the old style "crypt()" passwords. Please make sure you know what you are doing, as you can mess up your system so you can only log in in single user mode until you fix it.

After installing the updates, run as root:

 # /sbin/chkconfig portmap on
 # /sbin/chkconfig nfs on
 # /etc/rc.d/init.d/portmap start
 # /etc/rc.d/init.d/nfs start

After installing the updates, run as root:

 # /sbin/chkconfig portmap on
 # /sbin/chkconfig autofs on
 # /etc/rc.d/init.d/portmap start
 # /etc/rc.d/init.d/autofs start

At Stanford, Leland Systems uses AFS to provide and maintain a campus-wide distributed filesystem -- the ir.stanford.edu AFS cell. This cell currently consists of twenty AFS servers, geographically distributed across campus, and one Terabyte of available diskspace, which is backed up nightly.

Leland Systems uses this AFS cell to provide home directories for all Leland Accounts, many Stanford classes, and many Stanford University departments and campus organizations. Our AFS cell is also the home for our /usr/pubsw campus software service, which allows AFS client machines (for a variety of supported architectures) to access and use software compiled and maintained by Leland Systems personnel.

Over a thousand machines on the Stanford campus run AFS client software, giving their users local access to their Leland Account home directory, all the software available in /usr/pubsw, and hundreds of other AFS cells worldwide.

To enable AFS, run as root:

    # /sbin/chkconfig afs on
    # /etc/rc.d/init.d/afs start
    

• touch /etc/noafs
• reboot
• run

  /sbin/chkconfig afs off

If you have questions about the Kerberos, AFS, Security, or LibSafe package or other SULinux-specific question, email sulinux-help@stanford.edu

If a program isn't coded correctly, it may resemble an exploit. This is similar to a "segmentation violation" in C. Libsafe will force such a program to exit. Examples are old versions of netscape and adobe acrobat reader. Quite likely if you simply upgrade the package that is core dumping the problem will go away.

More information is available at http://www.avayalabs.com/project/libsafe/index.html

To get your mail, run:

	$ /usr/bin/fetchmail -u (your sunet id) --ssl .pobox.stanford.edu
	

	# apt-get install zephyr-X11
	

# apt-get remove sulinux-afsconfig
# apt-get install sulinux-afsconfig

This past weekend, the Graphics lab stumbled onto an apparent nfs bug in Redhat 7.3's new 2.4.18 kernel. This is standard on all RedHat (and thus SULinux) 7.3 systems. Apparently, an experimental patch (for 2.4.17) was applied providing NFS v3 over TCP. In that mode, a 32K buffer is a maximum. The default for UDP or TCP should be 4096K. Regardless, the kernel is attempting 32K packets over UDP (not TCP) and a lot of fragments cause the client to go to 100% of its network utilization, and the NetApp becomes unresponsive to other hosts.

Solutions to date are to either force NFS v2 (option "v2" on mounts) and to mount affected file servers with "rsize=8192,wsize=8192". Just specifying 'v2' is not enough.

Another solution that also seems to work wonders (I've tested it with compiles, etc) is to specify "tcp" as the only necessary option. Even at 32K packets, the NetApps work fine without performance issues when v3/tcp/32K is the applied combination.

I'd advise all users to use tcp or enforce some w/rsize limits for NFS connections from RH 7.3 clients until a patch is posted. This is equivalent to a DoS attack.

Update: SULinux 7.3 now provides a new kernel (2.4.18-5) that addresses this problem. Please upgrade to at least that version.