[comp.sys.next] Bugs in 1.0!!

rogerj@batcomputer.tn.cornell.edu (Roger Jagoda) (10/03/89)

Folks,
 
Some bugs I've found so far in NeXT OS 1.0:
 
1) Even though the proper entries are made
in NetInfo for "-AUTOMATIC-" in the /etc/hostconfig,
under some cases the en0 interface receives the wrong
netmask. AS an example, our configuration server has
the IPs for all our "diskfull" clients (with 330s). It's
in /etc/bootparams under the "HOST" area, and it was entered
into the database with NetManager (New Host). Niutil confirms
the entry. On the clients themselves, the "Local Configuration"
was done with NetManager and the INETADDR and HOSTNAME fields
were set properly with "-AUTOMATIC-" and the echos to the screen
during /etc/rc.boot DO report that the Ethernet is being set with
the following:
 
Ethernet interface being set to -AUTOMATIC-
/usr/etc/ifconfig en0 128.253.232.25 netmask 255.255.255.0
broadcast 128.253.232.255 -trailers up
 
Which is as it should be. BUT: the ethernet address is in fact
NOT set. An ifconfig or an attempt to use tn3270 to our VM host
told the story:
 
/usr/etc/ifconfig en0 reports:
 
en0: flags 8063<UP,BROADCAST,NOTRAILERS,RUNNING>
     inet 128.253.232.25 netmask ffff0000 broadcast 128.253.232.255
ifconfig: socket: Protocol not supported
 
Of course the line should read:
 
en0 flags 63<UP,BROADCAST,NOTRAILERS,RUNNING>
    inet 128.253.232.25 netmask ffffff00 broadcast 128.253.232.255

This is in fact the result if you edit /etc/hostconfig and replace
the two -AUTOMATIC- entries with the hard coded numbers for netmask
and hostname (and IP #). BUT why isn't -AUTOMATIC working and why
is the ifconfig reporting correct results but doing WRONG configurations?
 
Very weird. Redoing the ifconfig by hand after it has been done wrong
by netinfo DOES work, echo lines placed in /etc/rc.boot still report
$IPNETADDR, $IPNETMASK, $IPBROADCAST are all being read, and reported
properly form the configuration server. I just can't figure out why this
breaks? Any ideas? For now, we have hard coded the entries, but it makes
moving the machines that much more difficult.

2) You can adjust nu.cf (by the way, nu works MUCH better that the UserManager
even with the "long-view", nice try though...a nicer touch would have been
a NeXTStep interface to the real nu though..;-) ) to make everyone appear
as /user/<loginname>. This is VERY beneficial if you won't be on the
same machine regularly or if you make use of various file servers (we
do both). Just change the line in /etc/nu.cf from "WantSymbolicLinks = 0" to "WantSymbolicLinks = 1". BUT this doesn't work. In the Browser people still
see themselves as being under /Net/<server>/Users instead of /user/<loginnid>.
To fix this, you can use nu -m and modify the login's home directory to     
/user/<loginid> BUT only after the /user symbolic link has been set. In other
words you can't set the home directory to default to /user because nu won't
know where to write the home directory setup from /usr/template/user. You see
the dilema? I don't relish doing a nu -m for every user, but I do want them to
have the flexibilty to log in from any machine no matter what file-server it's
being served by. Funny, this worked fine under 0.9! (We then rdist the /user
file to the servers which NFS mount each others /Users...now, got all that?)
 
3) /usr/ucb/tn3270 is the old verson, the newest version can be found at 
the normal Berkely sites and runs fine under gcc (no problems compiling).
It also fixes a BUG in the /etc/map3270 file where the cursor keys aren't
mapped properly (up arrow is /EOA NOT /[A, etc). It's also much faster.
 
So far, that's all I've found...so when does 2.0 come out?
 
Roger Jagoda
Systems Analyst
Cornell University
FQOJ@CORNELLA.CIT.CORNELL.EDU
(607) 255-8960