*BSD News Article 70854


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!Germany.EU.net!howland.reston.ans.net!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!tube.news.pipex.net!pipex!lade.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!newsfeed.internetmci.com!news.sprintlink.net!new-news.sprintlink.net!newsreader.sprintlink.net!news.sprintlink.net!news-fw-12.spr
intlink.net!neonramp.com!cynjut.neonramp.com!cynjut.neonramp.com!not-for-mail
From: burgess@cynjut.neonramp.com (Dave Burgess)
Newsgroups: comp.unix.bsd.netbsd.announce,comp.unix.bsd.freebsd.announce,comp.answers,news.answers
Subject: [comp.unix.bsd] NetBSD, FreeBSD, and 386BSD (0.1) FAQ (Part 5 of 10)
Supersedes: <386bsd-faq-5-833176807@cynjut.neonramp.com>
Followup-To: comp.unix.bsd.netbsd.misc
Date: 13 Jun 1996 01:00:10 -0500
Organization: Dave's House in Omaha
Lines: 1015
Approved: news-answers-request@MIT.Edu,cgd@sun-lamp.cs.berkeley.edu
Expires: 07/01/96 01:00:03 CDT
Message-ID: <386bsd-faq-5-834645603@cynjut.neonramp.com>
References: <386bsd-faq-1-834645603@cynjut.neonramp.com>
Reply-To: burgess@cynjut.neonramp.com (386bsd FAQ Maintainer)
NNTP-Posting-Host: cynjut.neonramp.com
Keywords: FAQ 386bsd NetBSD FreeBSD !Linux
X-Posting-Frequency: Posted on/about the 13th and the 27th of every month.
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.announce:190 comp.unix.bsd.freebsd.announce:256 comp.answers:17324 news.answers:67170

Posted-By: auto-faq 3.1.1.2
Archive-name: 386bsd-faq/part5

Section 4.	(System Additions)

  Thanks go to Marc Wandschneider (storm@cs.mcgill.ca) for putting this
  section of the FAQ together..

4.0	Introduction

	If you have written some addition to the kernel or some other 
	part of the system, or know of one that feel should be mentioned, 
	send mail to Dave Burgess (burgess@cynjut.neonramp.com) with all 
	the relevant information, and it will be added for the next 
	release.

4.1	Common Kernel-related problems

4.1.1	Where are the commands "rpcinfo" and "rpcgen"?

	Chris Flatters (cflatter@nrao.edu) informs us in the following
	posting excerpt where we can find them:

	--------------------------------------------------------------------
	The sources for the Sun OS 4.0 RPC are on titan.rice.edu (I don't 
	have the inet number handy) in directory sun-sources.  You will have 
	to pick up all the shell archives and unpack them to get at rpcgen.
	--------------------------------------------------------------------

	These sources are also included in NetBSD and FreeBSD as part of the
	normal installation.
 

4.1.2	How can I fix NFS to work with my NE2000 board?

	Ken Raeburn (raeburn@cambridge.cygnus.com) has both identified the
	problem and provided us with a work around:

	--------------------------------------------------------------------
	I reported previously that I was seeing problems reading files over
	NFS using the ne2000 driver; timeouts would eventually be reported, no
	data would be read.  Listing files and directories (small ones
	anyways) were not a problem.

	After playing with etherfind and kernel printfs, I've come to this
	conclusion: Fragmented 8K UDP packets from the NFS server are not
	reaching the UDP layer in the kernel.  The Sun is sending them 
	(according to another Sun spying on the network), but the UDP 
	input routine is never called.  I don't know if the bug here 
	is on the *BSD or Sun side, and won't have time to look into it 
	in the next couple of days.

	In the meantime, mounting NFS file systems with "rsize=1024" does get
	rid of this problem.

	--------------------------------------------------------------------

	Hopefully, the real solution (a UDP fix) will be forthcoming so
	that the slow TCP problem is fixed as well.

	See also:  Section 2.6.3.3c "I am getting lousy performance 
		   out of my network card.  What are some of the other 
		   possibilities?"

	Recent work in FreeBSD and NetBSD may have deprecated this problem.
	There is a new network card driver called the ed0 driver.  This
	replaces the original NE1000/NE2000 drivers, as well as replacing
	the we0 driver.  By combining the two, a more flexible driver has
	been developed and most of these types of problems have been fixed.
	Once again, upgrading to FreeBSD or NetBSD seems to be the answer.


4.1.3	How can I get "ps" and "w" to work?

	The patch-kit contains a fix for /src/lib/libutil/kvm.c, which,
	last we heard, was due to the work of Jim Paradis 
	(paradis@sousa.ltn.dec.com).  New versions of the kernel should
	have this problem fixed.

	In order for users to be able to use certain flags with ps and
	the w/uptime commands, the kernel must have permissions 755.

	Also, when the internal structure of the kernel changes (as
	with the changes to NetBSD and FreeBSD that change fundamental
	parts of the kernel) a new ps, w, and uptime must usually be 
	recompiled.  If you are having trouble with your ps and have 
	recently upgraded/rebuilt your kernel, you will probably have 
	to rebuild ps etal.


4.1.5	Where are re_comp and re_exec?

	These two functions are currently not in libc.a.  However, there
	are two related functions that seem to work exactly the same in
	all cases we've heard of---These are regcomp() and regexec().

	Thus, a pretty ugly fix for the problem would be to always compile
	as follows:

	$(CC) -Dre_comp=regcomp -Dre_exec=regexec ....

	There is a slightly nicer fix available for this, listed in 4.2

4.1.6	What about the termio, termios, and termcap stuff?

4.1.6.1	Sometimes I have trouble with my system resetting the terminal
	to seven bit mode.  Isn't BSD eight bit clean?

	The answer is "sort of".  The problem seems to come from the
	fact that the <sgtty.h> interface is not guaranteed to be eight
	bit clean.  The <termios.h> interface is better, and should be
	eight bit clean in all cases.  If you find an application that
	uses the <sgtty.h> interface, you should either contact the
	author and try and get them to use the termios interface or port
	the code yourself.


4.1.7	The system hangs with the HD light on after intense disk usage.
	The system hangs when trying to fsck -p both of my IDE hard drives
	at boot-up.

	Brett Lymn (blymn@mulga.awadi.com.AU)  Provides us with a
	description of the problem and the steps that he had to take
	to fix it:

        It seems that, on some disk subsystems, the controller and the
	hard disk get out of synchronization when they are being used 
	intensively.  The result of this is that the disk completes a 
	command but the controller still believes the disk not to have 
	completed the command, so the controller status register 
	indicates the disk is busy when it is not really.  The standard 
	wd drivers are too trusting of the hardware and expect it to do 
	the right thing all the time.  There are a few while loops in 
	the wd drivers that loop on a status change from the disk 
	controller, however; if the problem I have described takes place 
	then the wd driver will be stuck looping waiting for the disk to 
	not be busy - which never happens, so you lock the machine because 
	this is a kernel level wait.  To fix this problem I put a timeout 
	into the while loops so that after a specified time the wd driver 
	will give up waiting for the drive to become ready, reset the 
	controller and retry the command.  In my experience the retry 
	always succeeds.

	Ed.Note:  The retry doesn't ALWAYS work, but it IS better than 
	just waiting for the drive to wake back up (which it never does).

	It has been recently noted that, from time to time, a SCSI disk
	subsystem will behave exactly the same way.  It is usually because
	of bad/out-of-tolerance cables.  It is not a common problem, but it
	is one that you, the reader, may need to take into account when
	you are trouble-shooting your drives.

	Dan Yergeau (yergeau@gloworm.Stanford.EDU) provides us with more 
	insight into this problem.  The README accompanying the original 
	sources used as a base for the NetBSD driver indicates that

	> There's also another problem still bothering me: There's some 
	sort of timing/reentrancy error still lurking in here, that was 
	there in the original 0.1 wd driver as well.  The symptom is that, 
	on *some* controllers, doing the initial wdopen() (which will 
	then call the readdisklabel() function) for two or more disks at 
	the same time (so that wdopen() gets called again while it's 
	already being executed), the controller gets hung.  I'm still 
	looking for this, meanwhile I specify in my config file that I 
	have swap on all disks.  This causes the kernel to wdopen() the 
	drives nicely in order -- and once it's been done for each disk, 
	the problem will, of course, not occur.  Without the "swap on ... 
	and ... and ..." stuff, my wd1, wd2 and wd3 would be opened 
	simultaneously by "fsck -p" forks, which would nicely hang up 
	everything...  I note a "sleep(10)" in fsck, but it obviously 
	doesn't do that.

	So, changing the appropriate config line to

	config		"kernel"	root on wd0 swap on wd0 and wd1
	                                                        ^^^^^^^
	may get around the problem.  I don't run NetBSD, but I do use a
	variation of the barsoom/NetBSD driver.  This works for me.  
	Please let the NetBSD people know if it works for you.


#include <std.disclaimer>

	[Ed. again] Other methods for fixing this problem include doing a 
	dd if=/dev/wd1d of=/dev/null count=1 before the initial 'fsck -p'.
	This method is considered brute force.  It works by making sure
	that the drive is properly initialized before the disklabel is
	read in the fsck.

	Another method involves using the '-l1' (little L) flag to make sure
	that the fsck doesn't try to open both unopened hard drives at the
	same time.  This method is a little better (from a purely brute
	viewpoint) but does cause your startup to run longer, since the
	purpose of this option is to have each of your fsck passes run
	one after another.


4.1.8	How do you implement quotas on Net/2 derived BSD systems?

	From: tinguely@plains.NoDak.edu (Mark Tinguely)

 	maybe you did not complete the setup, here is a step-by-step 
 	instructions to get them to work:

	1)  make a kernel with "options QUOTA" installed

	2)  edit /etc/fstab and include the kinds of quotas you want, 
	    below I used "userquota", you could also add "groupquota".

	/dev/wd0h		/usr		ufs	rw,userquota 1 2

	3)  for each filesystem that is in /etc/fstab that uses quota,
	    create the file "quota.user" (and "quota.group if appropriate).
	    Above I have user quotas in the /usr filesystem, so I would:

	    # touch /usr/quota.user

	4)  scan filesystem for files ownership (and/or group ownership).

	    # quotacheck -a

	5)  now you can add individual quota limits, if you want to add 
	    the same quotas to the many people, then make a template and 
	    replicate the template.  If they change for each user, then 
	    edit seperately.

	    # edquota tinguely

	 (an editor is kicked up and says something like:

	Quotas for user tinguely:
	  /usr: blocks in use: 11876, limits (soft = 0, hard = 0)
	        inodes in use: 891, limits (soft = 0, hard = 0)

	 a limit of 0 means "unlimited".  Change these to the appropriate 
	 number of blocks.  A soft limit generates a warning, and can be 
	 exceed for period of time (7 days?), after which time a soft limit 
	 is treated like a hard limit.  A hard limit denies new writes.

 	to replicate a template (for this example let us assume "tinguely" 
 	is the template):

	    # edquota -p tinguely user1 user2 user3 ... userN

	6)  turn quotas on (usually done in the /etc/rc file, but turn it 
	    on manually so you do not have to reboot right now:

	    # quotaon

	that should take care of setting up quotas.  You can look at the 
	status of use of files with repquota, the -a option lists all 
	filesystems with quotas.

4.1.9	What are the correct permissions for the /tmp, /usr/tmp, and
	/var/tmp directories?

	All of these directories should be owned by bin, group bin, mode
	1777.  This turns on the sticky bit, so that the only people who
	can remove a file from these directories are the owner and root.


4.2	Available kernel add-ons

4.2.1	The Patch-Kit

	Perhaps the most famous of all additions to the kernel, the Patch-Kit,
	coordinated by Rodney Grimes (rgrimes@agora.rain.com) contained 
	numerous bug fixes, Julian's SCSI drivers, as well as fixes
	for other parts of the system.

	It is highly recommended that all users with space for the source code
	apply the patch-kits as many things that seem broken in 0.1 suddenly
	start working with the patch-kits.

	Of course, there is no such thing as a patch kit for NetBSD or FreeBSD.
	The update method for these systems is different, and covered in the
	section about the System Update Protocol (sup) updates.


4.2.2	Shared Libraries

	For NetBSD and FreeBSD users, two seperate and different shared 
	library systems have been developed.  This feature is included in
	the '-current' tree of both systems, and will be included in the
	next major release of eiter or both.

	The shared libs have, in general, been very well behaved.  The
	closest thing to a FAQ that has been introduced is the
	following: 


	I installed FreeBSD-1.1-BETA a few weeks ago but can't get
	dynamically linked programs to run for some reason.  Every time
	I try to run a dynamically linked program, I get a message that 
	says "No ld.so"...	

	The answer is: 

	# chmod 755 /usr/* /usr/share/misc


4.2.3	Sound Blaster Drivers

	For a fact, the following sound cards are supported in FreeBSD:

		1	Yamaha FM Synth
		2	Soundblaster/Soundblaster Pro DSP
		3	PAS PCM and Midi
		4	Gravis UltraSound
		5	MPU-401

	In the release notes I have, there is some doubt as to the 
	operational status of the MPU-401 sound card driver.  If you have 
	one of these cards and want to try the driver out, you should 
	contact Jordan Hubbard (jkh@freefall.cdrom.com) when you are 
	finished installing it and let him know how it is working.

	The docs for the FreeBSD driver are in 
	/usr/src/sys/i386/doc/sound.doc.
	
	In NetBSD, all you should need to do is add the following lines
	to your config file:

		sb0	at isa? port 0x220 irq 5 drq 1	# SoundBlaster

		options         sound
	or
        	pseudo-device   audio

	When the new kernel re-boots, you should see a line something like
	this in your boot-up messages (use dmesg after reboot to make
	sure):

		sb0 at isa0 port 0x220-0x237 irq 5 drq 1: dsp v4.13

	Once you have created the device, you should be all set.

	To create the devices, 'cd' to the /dev directory and run the
	'./MAKEDEV sound' and './MAKEDEV audio' commands.  These will
	make the appropriate device entries.


4.2.4	Bus Mouse Drivers

	This is taken from the INDEX in the Freebsd.cdrom.com mice 
	directory:

	"We currently have four bus mouse drivers for *bsd available by
	anonymous ftp on XFree-86.cdrom.com in pub/XFree86/mice:

	ms-busmouse.tar.z

		Sandi Donno's <sandi@uctcs.cs.uct.ac.za.> port of 
		Erik Forsberg's Microsoft bus mouse driver to *bsd.

	logitech-busmouse-0.2.shar.z

		Fred Cawthorne's <fcawth@delphi.umd.edu> second version 
		of a logitech Bus Mouse driver.  

	busmouse.tar.z:

		Eugene Stark's port of Rick Macklem's driver to the 
		Microsoft bus mouse.  Rick's driver supports the 
		Logitech and ATI Inport Bus mice with *bsd.  It's also 
		available by e-mail to stark@cs.sunysb.edu and by anon. 
		ftp on cs.sunysb.edu in pub/*BSD/busmouse.tar.Z.

	psm.tar.z:

		Johan Solhed <Johan.Solhed@lu.erisoft.se> ported the 
		Linux PS/2 mouse driver to *BSD.  It includes a PS/2 
		to Microsoft protocol converter in the driver so XFree86 
		understands the mouse events.

	In addition we have busmouse.v3.z which is Erik Forsberg's original
	post of his device driver for BSDI/386 and Microsoft (and
	compatible) bus mice using the Microsoft InPort chip as well as a
	device driver for Logitech bus mice. "

	Most of these busmouse drivers are now included in the current
	releases of NetBSD and FreeBSD.  There is some question about
	how well they work (especially the psm driver), but they are
	all there.

	Additional information about configuring the psm device is
	included below to help make the psm driver work reliably.

	Add the following entries to your config file:

	options        ALLOW_CONFLICT_IOADDR
	device         psm0    at isa? port "IO_KBD" tty irq 12 vector psmintr
	
	Duplicate the options and device lines into your own kernel 
	configuration file, making sure to obey the proviso given about 
	following your pc0/sc0 devices, recompile it, install it, and 
	you should be off.  The the LINT configuration file for more
	information.


4.2.7	Kernel Loadable Modules

	Several strides have been made in the past to reduce the amount
	of 'cruft' that gets into the default kernel.  One way is to
	make the kernel so hard to use that practically no one but a
	person with precisely the 'right' hardware would be able to use
	the system

	Another way is to implement something called 'LKM's or "Loadable
	kernel modules.  These are run-time extensions to the system
	that allow the distribution kernel to not include things that
	people might want, but not nbeed until they get the system up
	and running.  While the security concerns of LKMs are valid,
	their implementation is such a win that the research to
	implement them is well worth it.

	As an experiment, Micheal Graff has worked a few hours on making 
	some small portions of the kernel into loadable modules.  So far, 
	he has built the kernfs, procfs, and msdosfs.   He plans on adding 
	others, including some devices, as time permits.  Others might be 
	interested in seeing what I have so far.

	It was really _very_ simple to make these, so this is nothing
	spectacular.  Just something to keep from having to recompile just to
	add msdosfs support to a machine.  ;)

	To try this:

		1)  get ftp://ftp.flame.org/pub/netbsd/lkm.tar.gz

		2)  untar it somewhere.  It will create a subdirectory 
		    called lkm and all extracted files will go in it. 
		    (I use /usr/src, but that may be a bad place)

		3)  follow the directions in lkm/README

	Please mail suggestions, and (especially) fixes and more 
	modules to Michael Graff <explorer@flame.org>.  Once it is 
	clean enough, I'll send it in as a send-pr and see what 
	happens.  :)

	One question which still needs to be resolved is where should 
	these *.o LKM's be installed?  The directory '/usr/lkm' would 
	be a good idea, with the output (modload's -o option) in 
	/var/run/lkm or something like that.


4.3	Other program building type problems.

4.3.1	Greetings from Mars.  I am building a program that requires access
	to the crypt library.  Either I have it and it isn't getting copied
	into the executable, or I don't have it; why?

	This is actually two separate questions, but they are close enough
	to the same that I can answer them here.  The first problem that
	anyone building a 'crypt' aware program needs to remember is that
	the crypt library is a separate library and requires a '-lcrypt' 
	to be added at the end of the link line.  The other half of the 
	problem is the 'US Non Export' policy for DES encryption.  There 
	are several good sources (about one per country) for non-US
	crypt libraries.  IF you are outside the US and need one, look 
	around on some of the NetBSD/FreeBSD FTP sites in the 
	'local area'.


4.3.2	I am having trouble with long file names in my libraries.  It
	seems like there is a 16 character limit in the library
	somewhere.

	There is a 16 character limit, sort of.  The most likely symptom
	for this is that the header for the file _after_ the long file
	name will be mangled.  It turns out that there is a "T" option
	that may not be documented very well that provides the correct
	functionality for long filename support in ar.


4.4	System Administration Questions
4.4.1	Where can I get good books about NetBSD or FreeBSD?

	There is a set of books produced by O'Reilly and associates that
	describe in some detail the 4.4 BSD system.  The six volume set
	includes a book on system administration which directly pertains
	to the operation and management of NetBSD and FreeBSD.  Also see
	the Section 1 for a good list of the books that folks use for
	the system.


4.4.2	I am concerned about system security.  What should I do to
	protect my system from net attacks?

	With the release of the System Administrators Tool for Analyzing
	Networks (SATAN), network security has suddenly become a serious
	issue.  There are a few things you can do.

	--  Get, read, and understand the CERT advisories
	--  Get SATAN and run it against your own system or network.
	Fix whatever it finds as holes
	--  Get courtney, a program that was written to recognize a
	SATAN attack pattern and notify you whenever someone tries to
	probe your system
	--  Log all failed login attempts (see below)


4.4.3	How can I log failed login attempts?
	
	Failed logins are logged (without the attempted login name) at
	LOG_NOTICE priority.  Failed logins are logged _with_ the 
	attempted login name at LOG_NOTICE priority, and with the 
	LOG_AUTHPRIV facility.

	If you set up some lines in syslog.conf like:

	# The authpriv log file should be restricted access;
	# these messages shouldn't go to terminals or publically-readable files.
	authpriv.*                                      /var/log/secure

	Make absolutely sure, though, that it's really what you want:  
	logging actual supplied logins is often a great way to offer 
	cleartext passwords to an adversary...

	Which is why you have 
	    authpriv.*			/var/log/secure
	...,authpriv.none,...		/var/log/messages

	So none of the authpriv messages (those that actually display 
	the failed login) goto /var/log/messages, but they do go to
	/var/log/secure (which you have with 600 perms.)  Bear in mind
	that this still does not prevent someone that has hacked into
	your system with root privs from reading them.  See 4.4.2 for
	more information.


4.4.4	Can I use a Concatenated Filesystem with NetBSD?

	The "ccd" device (in -current) provides the capability to span a
	file system across multiple hard drive partitions.  Jason Thorpe
	<thorpej@nas.nasa.gov> has been working on it; if you try it and 
	have problems, here are the debug instructions:


4.4.4.1	Why, when I type "ccdconfig ccd0 16 none /dev/wd0a > /dev/wd1a", do
	I get back "ccdconfig: ioctl (CCDIOCSET): /dev/ccd0d: Device not
	configured"?

	Considering that the error comes froom the ioctl (rather than the 
	open) I'm tempted to say it comes from either the vn_open() or 
	subsequent VOP_*() operations on the components.  If you compile 
	your kernel with `options CCDDEBUG' and set the ccddebug variable 
	(near the top of ccd.c or with the ddb) to 0x03, you should be able 
	to see where it fails.  If you could send me that information, 
	that would be most helpful.

	Might be the same problem I had; it turns out that the partitions 
	that you build your concatenated disk device from must not be 
	marked "unused" in their native disks' labels.  This "device not 
	configured" is the way ccdconfig informs you of this condition...  :-)

	Actually, I guess this indicates a need for a special "ccd 
	component" type entry for disklabel?  Or should the partition 
	simply be marked as a "raw" partition, sharing this type with 
	database log partitions etc?

	'Der Mouse' (mouse@collatz.mcrcim.mcgill.edu) adds:

	Personally, I think ccd has no business looking at those 
	partition types.  But I definitely think a special ccd-component 
	partition type is _not_ the way to go; if nothing else, it makes 
	life hard for people running ports using non-NetBSD disk 
	partitions.  For example, under NetBSD/sparc on a disk with 
	a SunOS label, there are no partition types in the label, so 
	it would be impossible to use a ccd that insisted on a special 
	partition type on such a disk.


4.5	Daemon questions
4.5.1	I'd like to use amd to mount a file system (/dev/sd0f aka 
	/usr/local) on another machine as "/usr/local".  What's the magic?


	There are several ways to achieve 'amd nirvana'.  Each of these
	elements below is an important consideration for getting amd to
	work correctly.

	The "-" means use these as defaults, so you need an entry without 
	a "-".  Also, I think one "-..." overrides the previous one 
	completely.

	As a start, you can use the following in your amd.project file:

	usr/local	opts:=rw;type:=nfs;rhost:=hostname;rfs:=/usr/local

	Then run "amd /usr/local /your/map/name -type:=direct".

	One word of warning, however.  In NetBSD 1.0, I couldn't get direct
	mount points to work for some reason.  I don't know if this has been
	fixed or not.

	If you are using a NetBSD 1.0 (or earlier) system, make /usr/local 
	a real symbolic link into an automount filesystem.

	Another instance of the amd.project file might look like this:
	/defaults type:=nfs;opts:=rw,soft,intr,grpid
	local	\
		host==hostname;type:=link;fs=/usr/local ||\
		host!=hostname;rhost:=hostname;rfs:=/usr/local
	
	You amd.master file might look like this:
	/project amd.project

	Here's another example which auto-mounts /usr/src from another 
	machine:

	grizu% ls -lad /usr/src
	lrwxr-xr-x  1 root  wheel  29 Dec 30 15:33 \ (split by ed.)
		/usr/src -> /tmp_mnt/mounts/src10/usr/src

	grizu% cat /etc/amd/master
	/net            /etc/amd/net
	/tmp_mnt/mounts /etc/amd/src
	
	grizu% cat /etc/amd/net
	/defaults       type:=host;fs:=${autodir}/${rhost};rhost:=${key}
	*               opts:=ro,soft,intr

	grizu% cat /etc/amd/src
	/defaults       type:=host;fs:=${autodir}/${rhost};
	src10           opts:=rw,soft,intr;rhost:=rfhu1001

	grizu% grep ^amd /etc/netstart
	amd=YES
	amd_dir=/tmp_mnt                # AMD's mount directory
	amd_master=/etc/amd/master      # AMD 'master' map
	
	grizu% ls -la /tmp_mnt
	total 9
	drwxr-xr-x   5 root  wheel   512 Jan  3 12:09 .
	drwxr-xr-x  26 root  wheel  1024 Jan  3 12:09 ..
	dr-xr-xr-x   3 root  wheel   512 Nov 20 19:29 ftp.uni-regensburg.de
	dr-xr-xr-x   2 root  wheel   512 Jan  4 10:43 mounts
	dr-xr-xr-x   4 root  wheel   512 Dec 11 08:18 rfhu1001
	
	grizu% ls -la /tmp_mnt/mounts
	total 3
	dr-xr-xr-x  2 root  wheel  512 Jan  4 10:43 .
	drwxr-xr-x  5 root  wheel  512 Jan  3 12:09 ..

	I guess that's all. rfhu1001 is the NFS server, grizu the client.
	

4.4.5	Are there any alternatives to 'NIS' available for NetBSD, etal.?

	Yes, there is 'hesiod' which provides (according to Ted Lemon 
	<mellon@fugue.com>i)another way of distributing databases like
	/etc/passwd, /etc/services, /etc/groups, and so on.  It uses
	DNS, which is (IMHO) slightly more robust and less easily
	subverted than NIS, and doesn't claim to provide authentication
	(authentication is Kerberos's job), so as part of a complete
	system, I think it's a much better solution.  It certainly has 
	a smaller installed base than NIS, though.

	There is also Kerberos IV, which provides similar functionality.
	NetBSD (1.0 or -current) now has a new set of changes to the 
	kerberosIV tree in

	ftp://ftp.unit.no/pub/NetBSD/ports/kerberosIV.diffs-0.1-0.2

	The author of the patches has also renamed the other Kerberos 
	files in the same directory to adhere to this private version
	number scheme, to allow for changes that will come later.


4.6	Adding new users.
4.6.1	Where can I FTP the 'adduser' program?

	There is one you can FTP (see the URL below).  You will need to
	be able to use 'vipw' to make it work, but that shouldn't be a
	big problem for most people.

	    ftp://ftp.quick.com.au/pub/unix/adduser.sh

	The man page is there too..

	    ftp://ftp.quick.com.au/pub/unix/adduser.8


4.5.2	Where is the 'adduser' program?

	Here.

#!/bin/sh
# This is a shell archive.
# remove everything above the "#!/bin/sh" line
# and feed to /bin/sh
# Use -c option to overwrite existing files
#
# Contents: 
#	adduser.sh
#
# packed by: <sjg@zen.void.oz.au> on Sun Aug 21 10:25:30 EST 1994
#
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f adduser.sh -a x$1 != x-c ; then
  echo shar: Will not over-write existing file \"adduser.sh\"
else
  echo shar: Extracting \"adduser.sh\" \(6443 characters\)
  sed 's/^X//' >adduser.sh << '!EOF'
X:
X#
X# NAME:
X#	adduser.sh - portable add user script
X#
X# SYNOPSIS:
X#	
X#	adduser.sh [-G "Group"] [-H "Homes"] [-S "Shell"] [-u "uid"] \\
X#		[-p "encrypted"] [-P "cleartext"] [-l]
X#
X# DESCRIPTION:
X#	Simply adds users and their home directory.  It prompts for a
X#	"username" and "fullname" which become part of the passwd file
X#	entry for the new user.  It adds "username" to "Group"
X#	(creating it if necessary) and uses "uid" or the 'gid' of
X#	"Group" as a starting point for its search for an unused
X#	'uid'.  By default it will prompt for a passwd after adding
X#	each user, but '-p' can be used to set a pre-encrypted password
X#	or '-P' can be used to give a clear text password which the
X#	script will encrypt and then use for each new "username".
X#
X#	Most of the variables used are obvious.  "Homes" is the parent
X#	directory of new users home directories.
X#	
X#	The '-l' option causes the script to show the default values
X#	for the variables that it uses.  Most if not all can be set on
X#	a per machine basis by creating a file '.adduserrc' in the
X#	super users home directory or in the directory where
X#	'adduser.sh' is found.  If "Homes"/.adduserrc exists it will
X#	be processed after any others, so can be used to set defaults
X#	on a per project basis.
X#	
X# NOTES:
X#	The script handles shadow password files on Solaris 2.3, other
X#	machines may break.  It has been tested on NetBSD, SunOS,
X#	Solaris and HP-UX.
X#	
X# AUTHOR:
X#	Simon J. Gerraty <sjg@zen.void.oz.au>
X#
X
X# RCSid:
X#	$Id: adduser.sh,v 1.2 1994/05/08 22:54:04 sjg Exp sjg $
X#
X#	@(#) Copyright (c) 1993 Simon J. Gerraty
X#
X#	This file is provided in the hope that it will
X#	be of use.  There is absolutely NO WARRANTY.
X#	Permission to copy, redistribute or otherwise
X#	use this file is hereby granted provided that 
X#	the above copyright notice and this notice are
X#	left intact. 
X#      
X#	Please send copies of changes and bug-fixes to:
X#	sjg@zen.void.oz.au
X#
X
XMyname=`basename $0 .sh`
XMydir=`dirname $0`
Xcase $Mydir in
X.)	Mydir=`pwd`;;
Xesac
X
XETC=/etc
X# for testing only
X#ETC=/tmp
X#VIPW="ed $ETC/passwd"
X
X# thinks that the rc file may override.
Xhost=`hostname 2>/dev/null`
XHomes=/home/${host:-`uname -n`}
XShell=/bin/csh
X[ -x /bin/ksh ] && Shell=/bin/ksh
XGroup=users
XPasswd='**'
X
X# look for an rc file
Xfor d in $HOME $Mydir 
Xdo
X  [ -s $d/.${Myname}rc ] && { . $d/.${Myname}rc; break; }
Xdone
X
XEXF=/tmp/e$$
XTF=/tmp/u$$
XTF2=/tmp/uu$$
X
Xcase `echo -n .` in
X-n*)	N=;C="\c";;
X*)	N=-n;C=;;
Xesac
X
XOS=`uname -s`
X
Xadd_path () { [ -d $1 ] && eval ${2:-PATH}="\$${2:-PATH}:$1"; }
X
Xget_id()
X{
X  file=$1
X  name=$2
X  min=${3:-1000}
X  max=`expr $min + ${4:-999}`
X  > $EXF
X  
X  id=`grep "^$name:" $file | cut -d: -f3`
X  case "$id" in
X  "")
X    # missing, must add it
X    i=$min
X    while [ $i -lt $max ]
X    do
X      n=`cut -d: -f1,3 $file | grep ":$i\$"`
X      case "$n" in
X      "")
X        # an empty slot - use it
X        id=$i
X        break;;
X      esac
X      i=`expr $i + 1`
X  done
X  ;;
X  *)
X    echo $id > $EXF;;
X  esac
X  echo $id
X}
X
Xmkdirs()
X{
X  case $1 in
X  /*)	pp=/;;
X  *)	pp=;;
X  esac
X  for p in `echo $1 | tr / " "`
X  do
X    case "$pp" in
X    "")	pp=$p;;
X    /)	pp=/$p;;
X    *)	pp=$pp/$p;;
X    esac
X    [ -d $pp ] || mkdir $pp || exit 1
X  done
X}
X
X
Xadd_group()
X{
X  echo "adding $1:*:$2: to $ETC/group"
X  echo "$1:*:$2:" >> $ETC/group
X}
X
Xupd_group()
X{
X  [ "$mygroup" ] || mygroup=`grep "^$1:" /etc/group | cut -d: -f4`
X  case ",$mygroup," in
X  ",,")				# empty
X    add=$2;;
X  *,$2,*)			# already there
X    add=;;
X  *)				# missing
X    add=,$2;;
X  esac
X  [ "$add" ] && sed "/^$1:/s/\$/$add/" $ETC/group > $ETC/group.$$ &&
X  	mv $ETC/group.$$ $ETC/group
X}
X
Xupd_passwd()
X{
X  EDITOR=ed
X  VISUAL=ed
X  export EDITOR VISUAL
X
X  didit=
X  
X  echo "adding $1:$2:$3:$4:$5:$6:$7 to $ETC/passwd"
X  case "$OS" in
X  SunOS)
X    if test -f /etc/shadow; then
X      # we are assuming its Solaris
X      echo "$1:x:$3:$4:$5:$6:$7" > $TF
X      echo "$1:$2:6445::::::" > $TF2
X      didit=yes
X    fi
X    ;;
X  *BSD)	  # NetBSD at least
X    echo "$1:$2:$3:$4::0:0:$5:$6:$7" > $TF
X    didit=yes
X    ;;
X  esac
X  # most OS's just want this.
X  test "$didit" || echo "$1:$2:$3:$4:$5:$6:$7" > $TF
X
X  line=`grep -n '^+:' $ETC/passwd | cut -d: -f1`
X  ( sleep 1; echo ${line}-1r $TF; echo w; echo q;
X    if test -f /etc/shadow && test "$OS" = SunOS
X    then
X      # this is a crok...
X      sleep 5
X      echo e
X      sleep 5
X      echo '$r' $TF2
X      echo w
X      echo q
X    fi
X  ) | ${VIPW:-vipw} 
X}
X
Xadd_user() 
X{
X  group=$1; shift
X  
X  eval set -- `echo "'$*'" | sed "s/:/' '/g"`
X  
X  gid=`get_id $ETC/group $group $4 256`
X  if [ "$gid" ]; then
X    [ -s $EXF ] || add_group $group $gid 
X    uid=`get_id $ETC/passwd $1 $3 1024`
X    if [ "$uid" ]; then
X      [ -s $EXF ] || upd_passwd "$1" "$2" "$uid" "$gid" "$5" "$6" "$7"; upd_group $group $1
X      [ -d $6 ] || { mkdirs $6 && chown $1 $6 && chgrp $group $6 && chmod 2775 $6; }
X    else
X      echo "can't add user $1" >&2; exit 1
X    fi
X  else
X    echo "can't add group $group" >&2; exit 1
X  fi
X}
X
Xrm_user()
X{
X  ( echo /^$1:/d; echo w; echo q ) | ${VIPW:-vipw}
X}
X
X# needs perl
Xencrypt() {
X  for d in /usr/libexec /usr/lib
X  do
X    [ -x $d/makekey ] && { makekey=$d/makekey; break; }
X  done
X  perl -e "print pack('a8a2', '$1', '${2:-$$}')" | ${makekey:-makekey}
X}
X
X# ok, time to get to work...
Xset -- `getopt H:S:G:u:p:P:l $*`
X
Xadd_path /sbin
Xadd_path /usr/sbin
Xadd_path /usr/ucb
Xadd_path /usr/etc
X
Xfor i in $*
Xdo
X  case "$i" in
X  --)	shift; break;;
X  -H)	Homes=$2; shift 2;
X	# pick up group defaults...
X	test -s $Homes/.${Myname}rc && . $Homes/.${Myname}rc
X        ;;
X  -S)	Shell=$2; shift 2;;
X  -G)	Group=$2; shift 2;;
X  -u)	uid=$2; shift 2;;
X  -p)	Passwd="$2"; shift 2;;
X  -P)	Passwd=`encrypt $2`; shift 2;;
X  -l)	list=yes;;
X  esac
Xdone
X
Xgid=`get_id $ETC/group $Group 100 1000`
X[ "$uid" ] || uid=$gid
X
Xcase "$Passwd" in
X""|none)	Passwd=;;
Xnologin)	Passwd='*';;
Xesac
X
Xif [ "$list" = yes ]; then
X  echo "Defaults:"
X  for v in Group Homes Shell
X  do
X    eval echo "\	$v=\$$v"
X  done
X  [ "x$Passwd" = "x*" ] && echo "	Passwd=prompt" || echo "	Passwd=$Passwd"
X  [ "$uid" ] && echo "	Initial uid=$uid"
X  echo
Xfi
Xecho Enter username and fullname - spaces in fullname are ok, no quotes needed.
Xecho An empty line terminates input.
Xecho
X
Xecho $N "username fullname: $C"
Xwhile read uname fname
Xdo
X  [ "$uname" ] || exit 0
X  add_user $Group "$uname:$Passwd:$uid:$gid:$fname:$Homes/$uname:$Shell"
X  [ "x$Passwd" = "x**" ] && passwd $uname
X  echo $N "username fullname: $C"
Xdone
!EOF
  if test 6443 -ne `wc -c < adduser.sh`; then
    echo shar: \"adduser.sh\" unpacked with wrong size!
  fi
  chmod +x adduser.sh
fi
exit 0

-- 
Dave Burgess  (The man of a thousand E-Mail addresses)
386bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean that there isn't someone
that wants to do it...."