brain-damage in SysV/386 r3.2 uname, etc.

[Greg A. Woods]

Weirdness with uname in SysV/386 r3.2:

	- uname -S changes sysname (which should be something like
	  AIX/ATT/BSD/ISC/ULTRIX/etc.)

	- uname -S re-writes /etc/rc2.d/S11uname

	- on ISC's version of r3.2 (2.0.2) 'sysadm setup' calls uname
	  -S and then re-writes /etc/rc.d/nodename too

Also note that all of the stuff in /etc/rc?.d isn't necessarily linked
to "originals" in /etc/init.d, so one must be very careful about
unlinking things there-in.

Given that, note that when the system boots, /etc/rc.d/nodename
executes, which includes a 'uname -S', which re-writes
/etc/rc2.d/S11uname, which executes, and since it also includes a
'uname -S' it then re-writes itself!  WHAT BRAIN-DAMAGE!

(Actually, it leaves behind an absolute marker of the last time the
system went into run-level 2 by the ctime on S11uname, unless the
clock was wrong.)

Also note that /etc/rc.d is obsolete.  I don't think it exists in the
3b2 version of r3.2.  I suppose that instead of fixing "sysadm setup"
which is also obsolete (replaced by face in most other r3.2's), ISC
just left everything as it was.  They sound more like SCO every day!

Although it may not be entirely clear to some people, as I read the
uname(2) man-page, it is obvious uname(1,2) are meant to determine the
system type, by default, and nodename is *always* an option.  As the
manpage says, "sysname" is the name of the current UNIX *system*,
"nodename" is the name that system is known by on a network, "release"
and "version" *further* identify the *system*, and "machine" contains a
standard name that identifies the hardware (which in my experience
should be the same as the /bin/<machine> command which returns TRUE).

I.e. instead of "eci386 eci386 1.0.6 1 80386", our machine should
answer "ISC eci386 1.0.6 1 i386" to 'uname -a'.

I'm not sure how far spread this crazyness is, but beware.  Anyone
know the details of SysVr4.0's behaviour?

I've noticed that newer versions of NCR Tower UNIX have a
/usr/lib/uucp/setuname which can modify either the appropriate kernel
config file, the kernel in /unix, or the running kernel, or all
three.  That seems somewhat more intelligent to me.
-- 
							Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP		ECI and UniForum Canada
+1-416-443-1734 [h]  +1-416-595-5425 [w]  VE3TCP	Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL