Dumb question about uucp

[Guy Harris]

> The box is of the opinion that its uuname is `clm' we would like to
> convince it otherwise; there does not seem to be a hostname command, or any
> equivalent.  One system V that we have has a magic little file that lives in
> /usr/lib/uucp that contains this name, does callan?
> 
>     It seems to me that I read somewhere that the host name was compiled
> into the kernel under sysV, that seems dumb, and unbelievable (we don't
> have source).

It may or may not be dumb and unbelievable, but it is true.  Given the
environment that the USG/USDL UNIX releases were, until recently, targeted
at (namely, AT&T sites who had source, and who ran big machines with a wide
variety of possible hardware configurations, so you'd build a kernel
specifically for that machine), it's not that dumb.  The intent is that the
distribution would come with a "generic" kernel, whose sole purpose was to
run on just about any configuration long enough to build a kernel tailored
for your configuration.  At that time you'd assign a name to the system and
build a kernel with that name built in.  A company offering S5 on their
machine could, if AT&T's binary licensing terms permit it (I don't know
whether they do or not - they *should*, but that's no guarantee), offer the
contents of "/usr/src/uts/<machine>/cf" as part of their distribution, along
with pre-compiled object libraries for the kernel.  That's sufficient to
build a tailored kernel and to set the system name.

This solution fails to some degree in the case of 4.xBSD, where you may
build a kernel which isn't completely generic but which will run on several
machines (using the autoconfiguration code), and fails miserably in the case
of the small UNIX boxes where there are a limited number of possible
hardware configurations and where you may not trust the end user to be able
to configure a kernel.  Some micro vendors have a command that'll either
patch your /unix (or whatever it's called) or your running kernel or both to
give the system a particular name.  If any such micro vendors didn't do
this, but instead kludged up all the user-mode programs which want the
system name to get it out of a file, they didn't do a very good job.  CCI
originally did that until I got fed up and hacked the "uname" command to
patch the kernel if you have it a name as an argument.

If you want, you can patch it yourself using "adb" (or, if you're feeling
ambitious, write a program to do it).  The structure returned by a "uname"
system call is called "utsname".  Unless the vendor has monkeyed with it, it
consists of 5 (or 4, for System III) 9-character strings; the strings are
embedded in the structure, not pointed to by pointers in the structure.
Starting at the location "utsname" (or "_utsname", as is likely on most
systems), there will be 9 bytes which will probably be the system name.  The
next 9 bytes after it (starting at "utsname + 9") will definitely be the
system name unless something is badly screwed up.  Just patch those to the
name you want - remember to include the terminating '\0' (if the first
string isn't the current system name, don't patch it).  Remember to make a
copy of the kernel before doing this, and remember to reboot afterwards if
you only patched it and not /dev/kmem.

It may not be optimal, but it's a lot better than, say, V7, where you needed
all the source to do a sysgen (many V7 vendors changed this, but out of the
box you needed source) *and* the name of the system was not affected by a
sysgen - it came out of an include file and was compiled directly into
user-mode programs (many V7 vendors fixed this, also).

	Guy Harris