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