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 triesavolio@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.