[comp.sys.dec] comp.sys.ultrix

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.