[comp.unix.ultrix] Ultrix 3.0

hubcap@hubcap.UUCP (Mike Marshall) (12/31/88)

Reply-to: hubcap@hubcap.UUCP (Mike Marshall)


Well, I got my tapes last week.

Haven't loaded it yet, but I've looked through the documentation...

It's got an obsolete version of BIND (4.7something) with "DEC enhancements"...
kinda scary if you think about it. Who knows though... maybe the enhancements 
are fixes for whatever it was that made everyone eschew 4.7.

I checked the man page for gethostent, and they're still using the
old-style hostent structure in netdb.h that has the single dimensional
h_addr... I wonder how their sendmail handles MX records? (hmmm... I wish
I was in my office where the manuals are... I wonder IF it handles MX
records...)

Looking forward to what everyone else has to say...

-Mike Marshall        hubcap@hubcap.clemson.edu

kjd@rust.DEC.COM (Kevin J. Dunlap - DECwest Engineering) (01/31/89)

Reply-to: kjd@rust.DEC.COM (Kevin J. Dunlap - DECwest Engineering)



>>?From: hubcap@hubcap.UUCP (Mike Marshall)
>>?	...
>>?
>>?I checked the man page for gethostent, and they're still using the
>>?old-style hostent structure in netdb.h that has the single dimensional
>>?h_addr... I wonder how their sendmail handles MX records? (hmmm... I wish
>>?I was in my office where the manuals are... I wonder IF it handles MX
>>?records...)

The Ultrix V3.0 manual page for gethostent is wrong.  
The Ultrix V3.0 /usr/include/netdb.h has the correct multi dimensional 
list of host addresses.

Looks like the gethostent manual page did not get updated with the new hostent
data structure.  The hostent structure for Ultrix V3.0 is the same as 
4.3BSD & systems running BIND:

struct	hostent {
	char	*h_name;	/* official name of host */
	char	**h_aliases;	/* alias list */
	int	h_addrtype;	/* host address type */
	int	h_length;	/* length of address */
	char	**h_addr_list;	/* list of addresses from name server */
#define	h_addr	h_addr_list[0]	/* address, for backward compatiblity */
};

MX support is in Ultrix V3.0 sendmail!!

-Kevin Dunlap  kjd@decwrl.DEC.COM

bin@primate.wisc.edu (Brain in Neutral) (01/31/89)

Reply-to: bin@primate.wisc.edu (Brain in Neutral)


>From article <76661@felix.UUCP>, by hubcap@hubcap.UUCP (Mike Marshall):
> I checked the man page for gethostent, and they're still using the
> old-style hostent structure in netdb.h that has the single dimensional
> h_addr... I wonder how their sendmail handles MX records? (hmmm... I wish
> I was in my office where the manuals are... I wonder IF it handles MX
> records...)

Oh, no, you're kidding...augghh!!

Maybe they did this so that when we replace their BIND, sendmail, ftp,
etc. with 4.3BSD versions, we'll still have to go through the usual
gyrations to make them compile compatibly...  (only 1/2 :-))

Did you check the netdb.h file itself.  Hopefully it's just the manual
page that's out of date...

Paul DuBois
dubois@primate.wisc.edu	rhesus!dubois
bin@primate.wisc.edu	rhesus!bin

avolio@decuac.dec.com (Frederick M. Avolio) (01/31/89)

Reply-to: avolio@decuac.dec.com (Frederick M. Avolio)

Mike Marshall is mistaken in his use of the term "obselete" in reference to
the BIND in 3.0 of ULTRIX.  it is not the LATEST BIND.  The "latest"
BIND changes as much as the "latest" version of GNU Emacs. :-)  It does
support MX record, etc.  It is a proper BIND implementation.

Fred

craig@BBN.COM (Craig Partridge) (01/31/89)

Reply-to: craig@BBN.COM (Craig Partridge)



> It's got an obsolete version of BIND (4.7something) with "DEC enhancements"...
> kinda scary if you think about it. Who knows though... maybe the enhancements 
> are fixes for whatever it was that made everyone eschew 4.7.
> 
> I checked the man page for gethostent, and they're still using the
> old-style hostent structure in netdb.h that has the single dimensional
> h_addr... I wonder how their sendmail handles MX records? (hmmm... I wish
> I was in my office where the manuals are... I wonder IF it handles MX
> records...)

Well that's certainly disturbing.

Bind 4.7 is dead -- in fact, it was never an official release according
to the Berkeley document.

People should get bind 4.8.  I append the general comments from the 4.8
CHANGES file to give you some sense of why.  The robustness checking and
negative caching issues are key -- there's a real move on to turn on
negative caching, and anyone who isn't running 4.8 or better is likely to
get flamed when that happens.

As for old-style hostent structures, my view is that there is no
excuse for that (but then again, I was the guy who pushed Berkeley
into developing the new hostent structure in 1985/6 so I'm biased).

Craig Partridge

(from the bind 4.8 distribution -- dated April 6, 1988)

Welcome to version 4.8 of bind.

There have been several changes to the named boot file (/etc/named.boot)
of which you should be aware.  The "domain" line for each zone is no longer
needed, but one such line may still be used to specify a default domain
to be used for queries containing names with only a single component.
The term "suffixes", which was added in version 4.7alpha, has been removed.

The manual page on named (named.8) has been updated to reflect all
these changes.  Please read this and look at the example files
before installation.  You should also note the changes in the
resolver code to support non-fully-qualified addresses and per-user
host aliases.  See hostname(7) for an overview.  Two new routines
have been added to the resolver library since the last test release:
res_query formulates a query, sends it, waits for a response and does
preliminary error checking; res_search implements the search rules
of gethostbyname using res_query.

The MX lookup routine in sendmail has been modified to use res_search.  
Also, dn_skip takes an additional parameter and has been renamed
to dn_skipname.  While old sendmail binaries will work with the new
version of bind, because of these changes, it is desirable to install
new sendmail sources and recompile sendmail.  Do not rebuild sendmail 
from old sources.   The new sendmail is on ucbarpa.Berkeley.EDU for
anonymous FTP from pub/4.3/sendmail.MX.tar and pub/4.3/sendmail.MX.tar.Z.

There have been numerous changes to named, fixing most of the known
bugs that can be fixed without major structural changes in the server.
Several server configurations that failed before should now work.
Certain robustness problems have been fixed, in particular bounds-
checking when processing incoming packets.  Two changes have been made
in preparation for negative caching: SOA records are sent in the authority
section in negative responses with NXDOMAIN set, and a bug was fixed that
caused confusion and repeated requests if a response had no error, no answer
and an SOA in the authority section.  As such responses are already sent
by other servers, and will be sent by the next release of BIND, it is
important that all sites upgrade to this version as quickly as possible.

The root "hint" cache and cache file remain the largest problem area,
along with named's naivete in accepting bogus server's data.
These will be addressed in the next release, along with asynchronous
zone transfers, intelligent reloading of zone files, faster startup,
and caching of negative responses.

This version (4.8) will replace the last officially released version (4.5).
Version 4.5 has a serious bug that causes the generation of a continuous
stream of bogons to the root domain servers (bogus queries with the query
response bit set and possibly garbage for nsid and rcode).  It is imperative
that these versions of named be replaced as fast as possible.  We urge you to
field 4.8 quickly, for the sake of the root domain servers.

	Mike Karels
	Jean Wood
	bind@ucbarpa.Berkeley.EDU

yba@sabre.bellcore.com (Mark Levine) (01/31/89)

Reply-to: yba@sabre.bellcore.com (Mark Levine)


In article <76661@felix.UUCP> hubcap@hubcap.UUCP (Mike Marshall) writes:
>It's got an obsolete version of BIND (4.7something) with "DEC enhancements"...
>kinda scary if you think about it. Who knows though... maybe the enhancements 
>are fixes for whatever it was that made everyone eschew 4.7.
>
>Looking forward to what everyone else has to say...

Our biggest problem with 3.0 is we got it before customer support....

I run BIND on an 8650, and it works well except for the case where the
secondary server loses the primary for longer than the cache time,
after which you get wonderful "Cannot find initialize address for
server" messages and dead lossage -- examining the dump and cache files
(we specify one in /etc/named.boot) confused me -- it didn't seem to
read them except at boot and then they got shorter....  Anybody else
play with this?

Anyone tried replacing the Ultrix 4.7 with Berkeley's latest (is it 4.8)?

Installation of the 3-tape set on a VS2/GPX was interesting: despite
the /etc/motd proclaiming it was "Ultrix 3.0 (Rev. 64) UWS 2.0 (BL 10)"
the folks in Atlanta claimed that it couldn't be workstation software
because UWS wasn't released yet.  It seems there is a program called
/bin/btd in the standalone memory only UNIX which is supposed to return
the unit it booted from -- on an MVII this returns nothing, on my GPX
it returns tms0 -- if you are unlucky enough to get "tms0", the shell
script will neglect to honor its obligation to change tapes to the
SUPPORTED tape (2 of 3) and drive you crazy (this can be fixed by
replacing /bin/btd with a shell script that does not return a valid
device to "install.1").  Customer support claims this is because if I
really had UWS, the standalone system should appear on the same tape as
the Supported software (with the root dump).  Using the MIT X11
software with 3.0 gets a bit tough if it only works with DECWindows.

Using the 8650 as an RIS server also loses -- BIND and /etc/ris really
don't understand each other: ris strips off the domain qualifier, the
documentation tells you you must supply it, and rsh gives you
permission denied when you try to use setld, since the client name is
not qualified in ~ris/.rhosts.  This looks hack-able but bothersome.

My other problem is that mop_download seems to no longer work; DEC
claims no other 8650 server has this problem, so I am looking for the
experience of others.  My syslog get messages saying either that the
tertiary load file is too large, or that the load timed out.  This same
network was using Ultrix 2.3 happily, so I'm inclined to think the
problem lies with 3.0.  I was suprised to hear that 6 MB of core was
required on a workstation for 3.0, which is what the support folks
asked me to check first (someone apparently was unable to net boot
because of insufficient memory!?).

And have you noticed that when using the man command on a vt100, the
underlined or bolded program names (.PN macro?) seem to get eaten?
Works on xterm, so I guess the page/more filtering or termcap is
wrong somewhere (fix appreciated, as I doubt this will reach the
top of my queue anytime soon).

jan@philtis.UUCP (Jan Stevens) (03/22/89)

Reply-to: jan@philtis.UUCP (Jan Stevens)


After several attempts to install Ultrix 3.0 we discovered some serious
problems with our distribution tape(s). It seems one file is missing from
the first (standalone) tape. Even a tape from a service engineer had the
same problem. Does somebody know more about this problem ?


Jan Stevens                              Unix system support
Philips CAD Centre                       Eindhoven
The Netherlands

aad@stpstn.UUCP (Anthony A. Datri) (03/29/89)

In article <88314@felix.UUCP> jan@philtis.UUCP (Jan Stevens) writes:
>
>After several attempts to install Ultrix 3.0 we discovered some serious
>problems with our distribution tape(s).

I couldn't get the standalone tape to boot, but the "supported software"
tape booted and went through the installation just fine.  I think the first
thing it asks you when you boot it is whether you want a standalone shell or
do installation.

-- 
@disclaimer(Any concepts or opinions above are entirely mine, not those of my
	    employer, my GIGI, my VT05, or my 11/34)
beak is@>beak is not
Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad

mason@goofy..Stanford.EDU (Tony Mason) (04/29/89)

The RISC compiler fails to handle enumerated type comparisons correctly.  For
instance, the following code fragment generates warnings:

	{
		enum {a,b} x;
		int z;

		z = (a == b);
	}

generates a warning message on the assignment line claiming a type mismatch
(this causes expressions using logical operations to break inside if
statements.  Thus, "if((a == a) && (b == b))" won't work because the operands
of "&&" aren't integers (according to the compiler.))

Let me guess, it's fixed in the Mips 2.0 compiler, right? :-)

Tony Mason
Distributed Systems Group
Stanford University
mason@pescadero.stanford.edu

rogerk@mips.COM (Roger B.A. Klorese) (05/01/89)

In article <8829@polya.Stanford.EDU> mason@goofy.Stanford.EDU (Tony Mason) writes:
>The RISC compiler fails to handle enumerated type comparisons correctly.
>Let me guess, it's fixed in the Mips 2.0 compiler, right? :-)

Actually, that's a good guess...

As our C compiler is based on an early (pre-enums) PCC, when we chose to
implement enums, we had a choice of three models, either (a) treating them
as pointers, (b) treating them as integers, or (c) treating them as a new
derived type.  Up intil the 2.0 release, we have treated them as a derived
type, which prohibits some operations.  As of 2.0, we treat them as integers.

   % [rogerk] 101) cc1.31 foo2.c
   ccom: Warning: foo2.c, line 6: enumeration type clash, operator =
         		   z = (a == b);
         ------------------------------^
   % [rogerk] 102) cc2.0 foo2.c
   % [rogerk] 103)

This release has recently been shipped to DEC as input for their poritng
process.
-- 
Roger B.A. Klorese                                  MIPS Computer Systems, Inc.
{ames,decwrl,pyramid}!mips!rogerk      928 E. Arques Ave.  Sunnyvale, CA  94086
rogerk@servitude.mips.COM (rogerk%mips.COM@ames.arc.nasa.gov)   +1 408 991-7802
"I want to live where it's always Saturday."  -- Guadalcanal Diary