rogerj@theory.tn.cornell.edu (Roger Jagoda) (02/14/91)
Folks, I have come across some ANNOYING bugs in Ultrix 4.1 and I was wondering if anyone else has seen these before and might have suggestions, work arounds, etc. On our RISC machines (DS3100s, 5000s): 1) The sendmail.cf file is broken. It says: # # The $w macro is preset by sendmail to the current host's unqualified # host name. Here we simply capture the value in our own $A macro. # DA$w BUT, this is not done. We did NOT touch this macro as the embedded documentation claims it is unnecesary. BUT, read on... # DDlocal Here is where the local domain goes, which for us, like most University sites, became our Internet domain address: DDtn.cornell.edu The name of the machine is "plasmips.tn.cornell.edu" which appears in out /etc/hosts file as: 128.84.253.208 plasmips.tn.cornell.edu plasmips Then the sendmail goes on to configure the entire host name in $j by concatenating their $w and $D...but it doesn't work! The use: # Dj$w.$D But look further, their ruleset 8 uses the $w and it's commented that this will return "localhost" as the $w name! Guess what...that's exactly what it does do! Everything we send out comes delivered as "From: <username>@localhost.tn.cornell.edu" Of course this will bomb if anyone tries to turn it around using mail's "R" command. Again, from /etc/sendmail.cf: ##### special local conversions # Here you can any special local rewriting rules and keep them all # in one place. Ruleset 8 is invoked at the beginning of ruleset 3 # and ruleset 6 is invoked at the end. Ruleset 3 always returns # the result of a call to ruleset 6. S8 # empty S6 # R$*<@$w>$* $:$1<@$w>$2 localhost.domain R$+<@$=w> $:$1<@$w> localhost R$-$+<@$w> $@$>3$1$2 localhost R$-$+<@$=w.$D> $@$>3$1$2 localhost R$-$+<@$=w.$=D> $@$>3$1$2 other local domains R$+<@$=S>$* $@$1<@$2.LOCAL>$3 localhost R$+<@$=S.$D>$* $@$1<@$2.LOCAL>$3 localhost R$+<@$=S.$=D>$* $@$1<@$2.LOCAL>$4 other local domains # R$*<@$+>$* $@$1<@$2>$3 already ok We have tried the following: Set hostname in the DA macro: DAplasmips and leave the DD macro DDtn.cornell.edu This produces mail with from lines: "From: <username>@plasmips" Note the lack of the domain after the host. Then we tried setting the name explicitly in the w macro: Dwplasmips This also produces mail with from lines: "From: <username>@plasmips" What finally WORKED was blanking out the D macro and setting the FQDN of the workstation in the w macro: Dwplasmips.tn.cornell.edu DD Does anyone else have a better solution? This still breaks some things and is not the best way to go. If DEC REALLY thinks the $w macro captures anything other than "localhost", then they probably refer to the loopback host in the host table: 127.0.0.1 localhost loopback-host loopback plasmips Now, this gets set WITHIN the kernel configuration and we never touched it...but it's NOT picked up by $w. Tis was reported to DEC in ULTRIX 3.0 and again in 3.1. Each time we were told a fix would be in the "next release". We don't have this problem in ANY other UNIX release we run here and we run them all (Xinu, Sun OS, HP/UX, etc...). Is anyone else out there working on a similar problem? Care to share your insights? 2) During the kernel configuration, two bugs occur/pop-up/etc. The installation procedure asks for a name for your machine and then puts it into the configuration file under that name: For us it was "/sys/conf/mips/PLASMIPS" Now, just look at the lines in that file for the system name: ident "PLASMIPS" ..etc. Notice it's in ALL CAPS! Look at the host table entries, they're all lower case. See the problem? As soon as you fire up nfsd (if you can) you'll get an error: gethostbyname() failed, nfsd not started. Of course gethostbyname() failed, the rpcinfo is looking for "PLASMIPS" and the machine name is "plasmips". The "fix" is to go into /etc/rc.local and change the /bin/hostname call to lower cased name: # # "@(#)rc.local 4.1.1.7 (ULTRIX) 8/9/88" # /bin/hostname PLASMIPS /bin/hostname plasmips Now the rest od this NFSD/rpc stuff SHOULD work: # %NFSSTART% - NFS daemons added by "nfssetup" echo -n 'NFS daemons:' >/dev/console [ -f /etc/mountd -a -f /etc/portmap -a -s /etc/exports ] && { /etc/mountd ; echo -n ' mountd' >/dev/console } [ -f /etc/nfsd -a -f /etc/portmap ] && { /etc/nfsd 8 ; echo -n ' nfsd' >/dev/console } [ -f /etc/biod ] && { /etc/biod 8 ; echo ' biod' >/dev/console } That one took forever to track down. 3) During the kernel configuration/installation, the DECStation's RAM is NOT counted properly. We have 24MB configured in one machine. During the PROM start-up (no ULTRIX yet), the machine SLOWLY ticks through all 24MB.......Great! But, look what it put into the configuration file: physmem 12 Great, so now we have to do a re-config again. Phooey! If the ROM can get the CORRECT RAM figure, why can't the installation/ kernel config procedure?? The last bug is in the LATEST but NOT greatest FORTRAN compiler for DEC's RISC side: Look at these results: program add real*8 r1,r2,sum1 r1 = 2.0000000 r2 = 3.0000000 sum1 = r1 + r2 print*,' in program',sum1 sum1 = sum(r1,r2) print*,' from subroutine',sum1 stop end real*8 function sum(a1,a2) real*8 a1,a2 sum = a1 + a2 print*,' in subroutine',sum return end The DS3100 produced: in program 5.000000000000000 in subroutine 5.000000000000000 from subroutine 0.0000000000000000E+00 while a VAX 3500 running Ultrix 3.1 produced in program 5.0000000000000 in subroutine 5.0000000000000 from subroutine 5.0000000000000 I regard the latter as the correct result. The RISC fortran compiler can't handle external function calls properly??!! That would REALLY hinder a LOT of our code. Well, if anyone has seen these bugs/problems before and has hints, suggestions, ideas, PULEEZE let me know! Thanks in advance! --------------------------------------------------------------------------- Roger Jagoda -- A wise man adapts Systems and Network Manager himself to a changing world. Laboratory for Plasma Studies -- A foolish man tries Cornell University to force the world to adapt to him. (607) 255-6115 -- Therefore most roger@ionvax.tn.cornell.edu progress is due to foolish men. --------------------------------------------------------------------------- -- --------------------------------------------------------------------------- Roger Jagoda -- A wise man adapts Laboratory for Plasma Studies himself to a changing world. Cornell University -- A foolish man tries
avolio@decuac.DEC.COM (Frederick M. Avolio) (02/14/91)
Well, your sendmail problems are really related to the fact that you don't want your hostname to be on the 127.0.0.1 line -- at least the software as it is set up doesn't like it. $w is set to the unqualified name (wrongly, but what the heck.. as long as we know....). The software is clearly confused as it looks things up, finds your unqualified name on the 127.0.0.1 line, and uses the first name it finds there (localhost). If you changed this string to FISHLIPS you'd find that that showed up on your mail. 1. Change your sendmail.cf back to how it was - don't define $w - Define $D to be your domain name 2. CHange /etc/hosts -- remove your hostname from the 127 line. 3. make sure your hostname command returns your fully qualified hostname things should work. Works for us on our machines. the 127.0.0.1 does NOT get set up when the kernel is configured but it does when you install the system. What the installation folks figured was that when you set up your network you would use the netsetup script as you are told to do in the installation guide and system management docs. When one uses this, the /etc/hosts file problem gets fixed at the same time it adds the ifconfig line in /etc/rc.local. Hope this helps. Fred
murphy@ufp.dco.dec.com (Rick Murphy) (02/15/91)
In article <1991Feb14.062908.4073@batcomputer.tn.cornell.edu>, rogerj@theory.tn.cornell.edu (Roger Jagoda) writes: Your sendmail.cf problem's already been addressed... >2) During the kernel configuration, two bugs occur/pop-up/etc. >The installation procedure asks for a name for your machine and >then puts it into the configuration file under that name: > >For us it was "/sys/conf/mips/PLASMIPS" > >Now, just look at the lines in that file for the system name: > > >ident "PLASMIPS" > >..etc. Notice it's in ALL CAPS! Look at the host table entries, >they're all lower case. See the problem? As soon as you fire up >nfsd (if you can) you'll get an error: > >gethostbyname() failed, nfsd not started. Of course gethostbyname() >failed, the rpcinfo is looking for "PLASMIPS" and the >machine name is "plasmips". The "fix" is to go into >/etc/rc.local and change the /bin/hostname call to lower >cased name: > > ># ># "@(#)rc.local 4.1.1.7 (ULTRIX) 8/9/88" ># /bin/hostname PLASMIPS >/bin/hostname plasmips Who put the '/bin/hostname' line into rc.local? Normally, it's the FQDN of the system. > >3) During the kernel configuration/installation, the DECStation's >RAM is NOT counted properly. We have 24MB configured in one >machine. During the PROM start-up (no ULTRIX yet), the machine >SLOWLY ticks through all 24MB.......Great! But, look what it >put into the configuration file: > >physmem 12 > >Great, so now we have to do a re-config again. Phooey! If the >ROM can get the CORRECT RAM figure, why can't the installation/ >kernel config procedure?? What led you to think that you needed to re-config? The 'physmem' line in the configuration file isn't necessarily the amount of memory on the system... to quote the 'Guide to Configuration File Maintenance': 'This parameter defines an estimate of the amount of physical memory currently in the system, in megabytes. The *number* argument is not used to limit the amount of memory; it is used to size the system page table.' Basically, it's not important. Until you raise it above 64k it will have NO affect on the kernel that you generate. >The last bug is in the LATEST but NOT greatest FORTRAN compiler >for DEC's RISC side: Look at these results: .... deleted ... >I regard the latter as the correct result. The RISC fortran compiler >can't handle external function calls properly??!! That would >REALLY hinder a LOT of our code. This isn't a compiler error; your program is missing a declaration for routine 'sum', so it's assuming the default of REAL*4 for the function. What else can the compiler do? The VAX gets the 'correct' result due to the layout of the VAX floating point numbers; the IEEE REAL*8 isn't just a REAL*4 with a few bits added to the end. Compiling with -r8 makes the program work as it makes 'sum' REAL*8 by default; compiling with -u finds the undeclared function reference. -Rick - Rick Murphy, WA1SPT/4 DEC Washington ULTRIX Resource Center Domain: murphy@burfle.dco.dec.com -or- murphy@ufp.enet.dec.com Bang: decwrl!ufp.enet!murphy Ding: (301) 306-2985 Disclaimer: This nonsense came from an AI program written in TECO. Ignore it.