So that is how that happened!!  I built and tested SpamAssassin as a regular
user, but then re-ran make test as root to see if the 'uname: not super user'
message would go away (it did).  Sometime later I found that the hostname
had been changed to '--fqdn'.  This is Solaris 8 on a SPARCstation-20.

Which build script?

I just did a find . | xargs grep fqdn and couldn't find anything obvious.

I wonder if this could be a perl problem.  I can find the lines
=item ($hostname, $domain) = split_domain ($fqdn)
=item $domain = trim_domain($fqdn)
in lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm and
in blib/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm, but that does not
look like the cause of the problem.  I can also find the lines
Spam detection software, running on the system "--fqdn", has
Spam detection software, running on the system "--fqdn", has
in t/log/dns.1 and t/log/forged_rcvd.1 (I did not let the tests run to
completion as root).  make install does not cause this problem. Neither does
just make, so it is make test that does it. Using perl 5.8.1.

How is SA installed on Solaris? CPAN? Or just make install? This looks like it's
something outside SA that's getting stroked by the SA installation procedure.

The hostname is changed during test t/dnsbl and again during t/spf.  Now if I
run make test as a normal user I get the following output during these tests:
t/dnsbl.....................uname: not super user
t/dnsbl.....................ok
------------------------------------
t/spf.......................uname: not super user
t/spf.......................ok
I did not get the 'uname: not super user' output when I was running 3.0.0-rc5
and perl v5.8.0.  I also don't get it when running as root with the current
setup.  Given that SpamAssassin changed little since rc5, I suspect that
the problem is with perl 5.8.1.  If I can find the time, I will try all of
this with perl v5.8.0.

Subject: Re:  Build scripts renames host to --fqdn when run as root

Sys::Hostname::Long has this code on my system (looks like v1.0):

                # Default fall back
                #       - Most unix (have not tested them all)
                #               . Linux
                #               . FreeBSD
                #       - MacOS X (Rhapsody/Darwin)
                $hostlong = `hostname --fqdn`;
                $hostlong =~ tr/\0\r\n//d;


v1.2 on another system seems to possibly be a little more sane, if
you're not already at v1.2 maybe you could try an upgrade.

Michael

dnsbl.t and spf.t?  I think it's a bug in Sys::Hostname::Long, being called from
Net::DNS in that case.  unfortunately there's nothing we can do about it in SA!

however, it might be worthwhile creating a FAQ page on the SA Wiki about this,
because it's going to confuse a lot of solaris users.

Well, I am using perl out of the box.  I greped for fqdn in the source and did
not find '--fqdn' anywhere.  Ah, there it is under the cpan stuff.  I have v1.2
of Sys::Hostname::Long (I assume as the directory is
build/Sys-Hostname-Long-1.2). It must have been a prerequisite for something
else.  In any case, when I switch back to the perl 5.8.0 the problem goes away.
That was built in October of 2002 and would have had whatever version of
Sys::Hostname::Long that was current then. I don't know how to make perl tell
me the version of the installed modules.

Subject: Re:  Build scripts renames host to --fqdn when run as root

http://rt.cpan.org/NoAuth/Bug.html?id=7717

Michael

So they just noticed a few days ago.  I just tried editing Long.pm found in
Sys-Hostname-Long-1.2/lib/Sys/Hostname and also in
Sys-Hostname-Long-1.2/blib/lib/Sys/Hostname.  I just removed the --fqdn form
the "my $tmp = `hostname --fqdn`" line.  That fixed the problem.  Of course
there seems to be no problem if your run the tests as a normal user, you just
get a somewhat funny message when the test runs.

I suggest that you add a note to the INSTALL document that says
Do NOT build and test SpamAssassin as root
and consider this case closed.

Subject: Re:  Build scripts renames host to --fqdn when run as root

bugzilla-daemon@bugzilla.spamassassin.org wrote:

> http://rt.cpan.org/NoAuth/Bug.html?id=7717

http://rt.cpan.org/NoAuth/Bug.html?id=5492

I reported this in early March when I took a look at SPF support in SA,
together with a small workaround, although I did not give it an
eye-catching Subject. 

ciao
     Klaus

> I suggest that you add a note to the INSTALL document that says
> Do NOT build and test SpamAssassin as root
> and consider this case closed.

When you install from CPAN, "install" implies "test", so the tests are always
run before installing. If you want to install site-wide you must install as
root.

How typical.

I probably have an unusual installation, but it is quite possible to have
your Prel installation owned by a normal user (user tools & group tools in
our case). You would have to create and/or change the ownership of the
base directory as root.  Then you can install perl as a regular user and can
run CPAN as that user also.  If Perl is already installed, you could still
change the ownership of your Perl installation and then run CPAN without
being root.

Does this only affect Sys::Hostname::Long (which is used by SPF) or also 
Sys::Hostname (which we use)? 
 
If both are affected, we should require the fixed version as soon as it's 
available. 
 
And somebody should tell the Mail::SPF developers (if they don't know yet) and 
they should do the same.  As soon as the new M::SPF version with the 
requirement is available, we should require at least that version of M::SPF 
(at least on Solaris). 

I just looked at the code for Sys::Hostname.  It uses the system hostname
command as a last resort istead of the first thing to try.  It also does
not use --fqdn on the hostname command.

This bug is deadly if you are using a Solaris system with Kerberos.  Sys::Hostname::Long changes
the hostname, then Kerberos cannot find the system in its key table -- and then nobody can log
in.  The priority of this bug should be raised.

The quick fix (in my case) was to edit Long.pm and remove all references to "--fqdn".

Created attachment 2414 [details]
patch against Mail/SPF/Query.pm

Here's a patch for Mail::SPF::Query 1.997 to kludge this bug on Solaris; it
also fixes another small bug where Sys::Hostname::Long returns the IP address
if it can't determine the hostname.

Seems like M::SPF::Q doesn't have a bug tracker, I'll send the patch to Meng
Wong.

Created attachment 2415 [details]
Patch against t/spf.t

Here's another patch against the spf.t regression test to simply skip it on
Solaris.  It's a kludge but better than nothing.  The regression test should be
the only part where M::SPF:Q is/can be called as root (I hope).

attachment 2415 [details] should go in 3.0.1. 

doesn't dnsbl.t do it too?
also, is $^O "solaris" on solaris?  iirc it may be "sunos"...

Subject: Re:  [review] Sys::Hostname::Long renames host to --fqdn when run as root

$ perl -e 'print "$^O\n"'
solaris
$ uname -rs
SunOS 5.9

Attachment 2415 [details] only checks for solaris.  The hostname command will also change
the hostname to --fqdn on HP-UX and on SunOS 4.* (pre Solaris).  There may be
others.  Perhaps the logic should be to skip the test unless one is running
Linux, or perhaps to skip the test if the user is root.

Hmm...  How about
Skip the test if the user is root and the system is not linux.

Created attachment 2429 [details]
replacement patch

ok, here's another patch that does that -- it just skips the test if running as
root on a non-linux OS, for safety.

oh btw -- little explanation -- I agree with Tom.  fundamentally the behaviour
of Sys::Hostname::Long is seriously broken, since *only* the GNU version of
"hostname" will support that --fqdn switch.  so running on *any* non-linux unix
is dangerous until the bug's fixed...

+1

+1

stupid modules...

Just now trying this out.  I get the message:
t/dnsbl.....................Bareword found in conditional at t/dnsbl.t line 15.
I suspect that in t/dnsbl.t the line
use constant DO_RUN     => TEST_ENABLED && HAS_SPFQUERY &&
should be
use constant DO_RUN     => TEST_ENABLED && HAS_NET_DNS &&

Seems to run ok with that change.  Ran make test as both a normal user and
as root.  The tests were skipped as expected when running as root.

ok applied to b3_0 -- r54712

Please see Comment #29.  I believe that there is a cut and paste error in
the patch.

that's ok, took care of that when applying. thx!

Just a little info.  If you are running cpan as root on a vulnerable system,
you will loose your hostname when you install Mail::SPF::query.  The tests
for Mail::SPF::query hit the same bug as SpamAssassin's tests did.  Just
something to keep in mind if someone claims that this bug is not fixed.

Subject: Re:  [review] Sys::Hostname::Long renames host to --fqdn when run as root

Hi,

Justin Mason wrote:
> that's ok, took care of that when applying. thx!

Net::DNS is not to blame for the error message in t/dnsbl.t on
Solaris (uname: not super user). The test dnsbl.t uses 'spamassassin' to
process a message which in turn uses the SPF rules thus producing the
error message.

I wonder whether it's enough to conditionally (M:Q:SPF installed)
disable dnsbl.t and spf.t. We saw the error message of two tests on
stdout. If spamd produced the same error message we probably would
not have seen it.


ciao
     Klaus

'Net::DNS is not to blame for the error message in t/dnsbl.t on
Solaris (uname: not super user). The test dnsbl.t uses 'spamassassin' to
process a message which in turn uses the SPF rules thus producing the
error message.'

damn, good point.  

I think we can leave t/dnsbl.t disabled as it is in 3.0.1, which avoids the bug
at the cost of not running dns tests, and just fix 3.1.0 to reflect this correctly.

I don't think that the check against HAS_NET_DNS has anything to do with
blaming NET::DNS for the problem.  I expect that it is there because you
can not run the test if you do not have NET::DNS installed.  If I recall
correctly, that check was there before anyone started to look at this
problem.  You could add a test against HAS_SPFQUERY too, but you would
have to define it first.

Just tried v3.0.1 on a couple of Solaris 9 systems (installed through CPAN in
Perl 5.8.4 on each) without initially knowing about this bug, and after getting
my composure back I found out that this is a very well-reported bug so it wasn't
so bad!

I'm dropping my systems back to v2.6.4 until v3.1.0 is ready as they handle mail
for a large number of users. 8-) 2.6.4 is giving some strange Perl-related
errors too, but it's not causing the hostname to be fiddled with.

How far off is the release of v3.1.0 likely to be?

Hm...  The patch is already in SpamAssassin 3.0.1, but note that installing
Mail::SPF::query  will kill your hostname too.  Note also that this is a
problem with the  make test  phase of the install.  Once the install is done,
you can use SpamAssassin 3.0.1 without any problem.  Also see Comment #10
if you want to fix the cause of this problem in Sys-Hostname-Long.  Cpan
usually leaves it's sources in .cpan/build.

Thanks Tom for the tip. I've found where the source for Sys::Hostname::Long is
located using the 'look' command to the CPAN module and have identified where
the 'hostname --fqdn' command strings are.

If I simply edit those files, can I then run the installation of the module
again from the shell that the 'look Sys::Hostname::Long' command started, or do
I get back into CPAN proper and use 'force install Sys::Hostname::Long' to
re-install the module with the changes to it's source?

Craig.

I did not use CPAN at all to do the fix.  I just went to the source directory
and edited the file containing 'hostname --fqdn'.  Then in the base directory
of Sys-Hostname-Long-1.2 I ran  make  and then  make install.  I expect that
the shell started by the 'look Sys::Hostname::Long' would have put you in the
corrct directroy to run  make  and  make install.

this is fixed in 3.1.0; those tests do not run as root.

we can't do anything about the tests run by Mail::SPF::Query which change the
hostname, though.

In Comment #42 Justin says that this is fixed in 3.1.0, with the test not
running as root. But t/spf.t in trunk still has the test to not run if root and
not linux. Is there any other fix that was implemented?

The test is unecessarily being skipped in Win32. I want to change the !IS_LINUX
test to !(IS_LINUX || IS_WINDOWS), but the comment seems to imply that the whole
test is no longer necessary. Justin, can you clarify this?

Subject: Re:  [review] Sys::Hostname::Long renames host to --fqdn when run as root 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> In Comment #42 Justin says that this is fixed in 3.1.0, with the test
> not running as root. But t/spf.t in trunk still has the test to not run
> if root and not linux. Is there any other fix that was implemented?

no -- I'm not sure what the status is.

> The test is unecessarily being skipped in Win32. I want to change the
> !IS_LINUX test to !(IS_LINUX || IS_WINDOWS), but the comment seems to
> imply that the whole test is no longer necessary. Justin, can you
> clarify this?

go ahead -- make it run on windows, I think it'll be safe there.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFCIjWnMJF5cimLx9ARAveVAKCXxTLl8dfT/RtVN4wD8JymbND1nACfeN9Z
rs2vGVpT0PIkGHhTLarq5xc=
=RKAp
-----END PGP SIGNATURE-----

This bug, which has been fixed in most 3.0.x releases, appeared
like a phoenix in 3.1.0.

> This bug, which has been fixed in most 3.0.x releases,
> appeared like a phoenix in 3.1.0.

Can you supply some details including what OS you are running under and how you
ended up encountering the problem?

As per the previous comments, the fix was supposed to be skipping the offending
test in t/spf.t if running under an OS other than Linux and Windows which are
not supposed to be affected.

Also, as mentioned in the comments, installing Mail::SPF::Query as root in
Solaris and some other OSs will cause the same problem during its make test
step, and there isn't anything SpamAssassin can do about that.

So 1) What OS? 2) Did the hostname change during the SpamAssassin make test? If
so, is the test in t/spf.t not being skipped? 3) Did you perhaps install a new
Mail::SPF::Query as part of your upgrade of SpamAssassin and that install is
what caused the problem?

Another report of this in bug 4575. The author of that bug reported the issue
directly to the Sys::Hostname::Long maintainer who indicated on 20050908 that
he'd address it. I've not heard anything since then.

*** Bug 4575 has been marked as a duplicate of this bug. ***

There is a difference between the situation here and that reported in bug 4575.
In that case the complaint is about a logged error message when the attempt was
made to change the hostname while not running as root. That is an interaction
between Mail::SPF::Query and a bug in Sys::Hostname::Long for which the only
good solution is to upgrade to the latest version of Sys::Hostname::Long or if
that doesn't help let the maintainer know which OS is still showing that
problem. But the symptom is minor, an unnecessary error message in the log.

Comment #45 is complaining about something that is supposed to be fixed, which
is the triggering of this problem in SpamAssassin's make test when it is run as
root. We try to prevent that from happening even if Sys::Hostname::Long has the
bug by skipping the offending test if running as root and not under Linux or
Windows.

reaiming at a release that hasn't been released yet ;)

Linus, we need more information about the latest incarnation of this bug. I
assume that you are still running Solaris. Do you have the latest version of
Sys::Hostname::Long, which I thought fixes that problem in Solaris? Did you
install a new version of Mail::SPF::Query as root and is it possible that
install changed the hostname instead of the SpamAssassin install? If installing
SpamAssassin as root did cause the hostname to be changed, can you identify at
which step the change did happen? The test that makes it happen should be
skipped in t/spf.t if running as root in an any OS other than linux and Windows.
Was the test done anyway or is there now a different step that invokes
Sys::Hostname::Long --fqdn?

Some answers will help in reproducing this and tracking it down.

Sorry for the delay. Yes this is still Solaris for Intel:

>uname -a
SunOS igloo 5.9 Generic_117172-07 i86pc i386 i86pc

Installing Mail::SPF::Query may very well be the cause. Testing
it again with "force install Mail::SPF::Query" causes the problem.
I do not remember installing it as part of SpamAssassin but may very
well have happened.

Upgrading Sys::Hostname::Long and then reinstalling Mail::SPF::Query
again doesn't cause the problem so Sys::Hostname::Long was definately
the culprit.

You could close this again then...

Created attachment 4253 [details]
no need to disable a test with fixed versions of Sys::Hostname::Long

The previous fix disables t/dnsbl.t assuming the Sys::Hostname::Long is
broken. The bug has been fixed in 1.3/1.4, so the previous fix unnecessarily
disables the test on systems with fresh versions of Sys::Hostname::Long,
e.g. on FreeBSD. The proposed patch checks for version of Sys::Hostname::Long
and only disables the test when a bug is present.

The Sys::Hostname::Long 1.4 tests for the following systems:
MacOS, IRIX, cygwin, MSWin32, *bsd*, *nto*, solaris

reopening, hoping for a more selective check to go into 3.2.5

Created attachment 4254 [details]
removed one unnecessary line from 4253 patch

+1

+1

$ svn -m 't/dnsbl.t: no need to disable a test with new/fixed versions
          of Sys::Hostname::Long, bug 3806' ci
Sending t/dnsbl.t
Committed revision 620371.

To 3.3/trunk:

r627800:
spf.t, uribl.t, dnsbl_sc_meta.t: (same change as already in dnsbl.t)
  no need to disable a test with new/fixed versions of Sys::Hostname::Long,
  bug 3806