woods@eci386.uucp (Greg A. Woods) (01/09/91)
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-ORWELLguy@auspex.auspex.com (Guy Harris) (01/13/91)
(Not S5/386 specific; followups to "comp.bugs.sys5", for now, although it might want to sneak into one of the other UNIX groups.) >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, Unfortunately, the word "system" there appears to have been interpreted differently by different folks. Back in the PWB/UNIX 1.0 (as in "V6-flavored") days, when "uname" first popped up, there was no "nodename" field because there wasn't anything such as UUCP in PWB/UNIX; there was only "sysname", which was the name of the *machine*. I suspect it tended to be a very short and non-unique name (e.g., "a"), so that when UUCP showed up, there needed to be another field to give a name more likely to be globally unique, so "nodename" was added. I think the original SVID implied that "sysname" was supposed to be the name of the *OS*, rather than the name of the machine, with "nodename" the name of the machine. I don't have the original handy to check, but I remember *some* standard - perhaps it was a POSIX draft, as the standard in question predated 1003.1 officially coming out - saying so. I also don't have volume 1 of SVID Issue 2 handy, but volume 2 says about the "uname" *command* that 1) "sysname" is "a name by which the system is known in the local installation", which could mean it's supposed to be a machine name, and 2) "uname" with no arguments prints "sysname". The model specified by POSIX, in which "sysname" is the "name of this implementation of the operating system", makes more sense to me; having two machine names doesn't seem useful. Unfortunately, a lot of code may have depended on "sysname" being the machine name - or, at least, on an unadorned "uname" generating the *machine's* name, which the S5 accounting scripts require, and which SVID Issue 2 specifies - so there may have been some resistance to converting it. >"release" and "version" *further* identify the *system*, Given "system" meaning "the OS", POSIX seems to specify that as well, with "release" being "current release level of this implementation" and "version" being "current version level of this release". Back in PWB/UNIX days (and this continued up to S5R2 or so), "release" was the release number (as in "3.0.1" for System III) and "version" was some administrator-specified string, typically the month and year on which the system was built - i.e., it wasn't a vendor-chosen version, it was a user-chosen or administrator-chosen version. POSIX's specification isn't exactly precise here.... >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 tend to agree, although there is a problem there - on my machine, more than one "/bin/<machine>" (well, "/usr/bin/machine" - it's running SunOS 4.x) command returns TRUE! "sparc", "sun", and "sun4c" all return TRUE. In other words, how much should it tell you about the machine? Some VAX versions of S5R2 seemed not to return "vax", but to tell you "vax780" or "vax750", which is even more specific than, say, "sun" or "sun4c". My personal vote would be to have "machine" identify the highest-level CPU architecture; i.e., basically the level for which ABI's exist. Thus, any machine with a 68K in it (or, at least, a 68020 or better) would say "m68k"; any machine with an 80386 or better would say "i386"; any VAX (if anybody cares any more) would say "vax"; any SPARC-based machine would say "sparc"; any 88K-based machine would say "m88k" or whatever; etc.. If AT&T's current WE32K-based machines can all execute each other's normal application binaries, they should say "we32k" or something, *NOT* "3B2" (unless all AT&T's current WE32K-based machines are 3B2's, not 3B15's or so). I.e., I don't think it should tell you who made the box, or what kind of I/O bus it has, or other stuff irrelevant to most applications. It might be useful to have other mechanisms to find that out, but the "machine" field shouldn't specify it. >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 tend to agree there. >I'm not sure how far spread this crazyness is, but beware. Anyone >know the details of SysVr4.0's behaviour? SVID, Third Edition (i.e., the S5R4 one) matches POSIX, not surprisingly, for the "uname()" procedure call. "uname(BA_OS)" says that "sysname" "name(s) the current operating system", while "nodename" is "the name that the system is known by on a communications network". "release" and "version" "further identify the operating system", and "machine" "contains a standard name that identifies the hardware on which the operating system is running" - the latter has a bit more of an implication of detailed information about the particular box than I'd like. Unfortunately, it *still* says that "sysname" is the default, and "is a name by which the system is known in the local installation", for the "uname" *command*, in "uname(BU_CMD)". *However*, the S5R4 *User's Reference Manual* says that the "uname" command prints "nodename" by default, and that "uname -s" prints "the name of the current operating system (e.g., UNIX System V)". It also indicates that "uname -S" changes the nodename, and doesn't seem to say that it changes the "sysname". I hope that the problem is that the SVID just hasn't caught up to reality.... (Of course, you now have the question of on *which* communications network the machine is known by what's in "nodename". The machine's name on a TCP/IP network may be different from the name on a UUCP network; SunOS 4.1's HDB, and perhaps the S5R3.2 HDB from which it's derived, do let you say that the UUCP name of the machine isn't its "standard" name, as derived from "gethostname()" or "uname()". Dunno what happens if the machine can talk, say, both TCP/IP and OSI....)
woods@eci386.uucp (Greg A. Woods) (01/15/91)
In article <5207@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >[.... Guy provided some very detailed and insightful information about uname(1,2) and and the historical background. Thanks! >....] > *However*, the S5R4 *User's Reference Manual* says that the "uname" > command prints "nodename" by default, and that "uname -s" prints "the > name of the current operating system (e.g., UNIX System V)". It also > indicates that "uname -S" changes the nodename, and doesn't seem to say > that it changes the "sysname". I hope that the problem is that the SVID > just hasn't caught up to reality.... The part that really pissed me off, and "made" me post my bug report in the first place was the fact that in SysVr3.x/386 "uname -S" changed both `sysname' and `nodename' to the same value, and the only way to avoid that would be to rewrite uname such that it could not call sysi86(SETNAME) and subsequently disable any sysadm things that took advantage of this "feature", *and* remember to reboot the system after building a new kernel with the new values. Now that I've found out the code which does this nonsense is ifdef'ed to i386 I'm really pissed! I hope S5R4's uname is indeed "fixed" (on all platforms). > (Of course, you now have the question of on *which* communications network > the machine is known by what's in "nodename". The machine's name on a At one time I though this would be a good use for `sysname' and `nodename', but I gave that up a long time ago! :-) Anyone choosing the contents of `nodename' should really read rfc1178! PS, I also agree that `machine' should indicate the highest level ABI. -- 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