[gentoo-user] Logwatch not resolving hostname

[gentoo-user] Logwatch not resolving hostname

[Chris Lieb]

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

I have recently setup logwatch-7.3.2 on a few of my machines along with
sendmail.  For all but one of the machines, I get emails that have the
hostname in the subject line (Logwatch for capitol (Linux)) as well as
on the line that reads 'Logfiles for Host' (Logfiles for Host: capitol).

However, on one machine, the hostname is not resolved correctly.  The
email has the subject line 'Logwatch for 10 (Linux)' and in the body of
the email has 'Logfiles for Host: 10'.  The IP address of this machine
is 10.192.202.xxx, and the hostname is high.

When I do a `hostname -va` on high, I get:
  gethostname()=`high'
  Resolving `high' ...
  Result: h_name=`high.opcdir.intranet'
  Result: h_aliases=`high'
  Result: h_aliases=`localhost'
  Result: h_addr_list=`127.0.0.1'
  high localhost
When I run the same command on congress, which has a working logwatch, I
get:
  gethostname()=`congress'
  Resolving `congress' ...
  Result: h_name=`congress.opcdir.intranet'
  Result: h_aliases=`congress'
  Result: h_aliases=`localhost'
  Result: h_addr_list=`127.0.0.1'
  congress localhost
This seems to me to eliminate the possibility of a misconfigured
hostname on high.

Does anyone have an idea as to what is causing logwatch to not resolve
the hostname correctly?

Thanks,
Chris Lieb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJJpWI7AAoJEJWxx7fgsD+Cq+8H/RwGltiY8fvbAfee3/e/jYG9
WyOm187M6LZBQ3hWJ2Q558hQUNr86CqfaLBwPaOeBK8KEv1WvhAS5iyQo/4FNU77
X7y+EwEpF4X1mYV0MNm+zLmvd/XqEeSCxNe96N6bubyXxSh+/uAR4Seqd4TtwjKH
aOVqvN94skUJY4MVgLHHrjbDVwNkv6TqVTIKDRquj3qx21TzKsMj3VrxlGUinvIW
/nXs0hI4SYWOXIB+t29z/P80KPSozJW9OW2GuEJIeph91eKoc9H8nfcFLE3I1k3x
dMAdxEtF7fPUB2KmIizRAoOauKYHHkPqPbxvUDqh8T3JABfzYu+cG4v7xuRfok4=
=Y0K4
-----END PGP SIGNATURE-----

[gentoo-user] Re: Logwatch not resolving hostname

[Chris Lieb]

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

Chris Lieb wrote:
> I have recently setup logwatch-7.3.2 on a few of my machines along with
> sendmail.  For all but one of the machines, I get emails that have the
> hostname in the subject line (Logwatch for capitol (Linux)) as well as
> on the line that reads 'Logfiles for Host' (Logfiles for Host: capitol).
> 
> However, on one machine, the hostname is not resolved correctly.  The
> email has the subject line 'Logwatch for 10 (Linux)' and in the body of
> the email has 'Logfiles for Host: 10'.  The IP address of this machine
> is 10.192.202.xxx, and the hostname is high.
> 
> When I do a `hostname -va` on high, I get:
>   gethostname()=`high'
>   Resolving `high' ...
>   Result: h_name=`high.opcdir.intranet'
>   Result: h_aliases=`high'
>   Result: h_aliases=`localhost'
>   Result: h_addr_list=`127.0.0.1'
>   high localhost
> When I run the same command on congress, which has a working logwatch, I
> get:
>   gethostname()=`congress'
>   Resolving `congress' ...
>   Result: h_name=`congress.opcdir.intranet'
>   Result: h_aliases=`congress'
>   Result: h_aliases=`localhost'
>   Result: h_addr_list=`127.0.0.1'
>   congress localhost
> This seems to me to eliminate the possibility of a misconfigured
> hostname on high.
> 
> Does anyone have an idea as to what is causing logwatch to not resolve
> the hostname correctly?
> 
> Thanks,
> Chris Lieb

I believe I've found the problem!  There is a hash called %swordsmen
that defines a pair of 'high => 10'.  It appears that a function is
calling getInt, which uses %wordsToInts to process hostname, turning my
hostname of 'high' into '10'.

I'm going to play around with it some more to see if this is the case.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJJqAf0AAoJEJWxx7fgsD+C3dcH/2gWwHoDG7tIeBN2NV6Gq8L5
sMOgI/QKqRcOFWEefnc8PQDZ6yj66fAu12MuTEcUi6CLP1XaHcqjjOdeVnu4giDd
3lJl8Bk7LdTjpz+TAF/vlj5D0ERMIVftrF73JoaTBEp5QeNFwcHu9UywVy1I4/KH
FkrPuS9lSW6gSdovo7ZN+Q0ok9ooD70grhrzXg6355sNONt1zbbWV/7AkKip357T
H6BpNx4xeS0CzyG8hAdkNAbjYd7MAilxX2p8ihLNdjLDmh25WvaBYL3MkRjIMt38
ENuS64vODniIUe2I2FAQ7iyVMoHULXdWfdvqoLLK8CiQ2cEMH2p1n6XvWR54Mg8=
=Tco2
-----END PGP SIGNATURE-----

[gentoo-user] Re: Logwatch not resolving hostname

[Chris Lieb]

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

Chris Lieb wrote:
> Chris Lieb wrote:
>> I have recently setup logwatch-7.3.2 on a few of my machines along with
>> sendmail.  For all but one of the machines, I get emails that have the
>> hostname in the subject line (Logwatch for capitol (Linux)) as well as
>> on the line that reads 'Logfiles for Host' (Logfiles for Host: capitol).
> 
>> However, on one machine, the hostname is not resolved correctly.  The
>> email has the subject line 'Logwatch for 10 (Linux)' and in the body of
>> the email has 'Logfiles for Host: 10'.  The IP address of this machine
>> is 10.192.202.xxx, and the hostname is high.
> 
>> When I do a `hostname -va` on high, I get:
>>   gethostname()=`high'
>>   Resolving `high' ...
>>   Result: h_name=`high.opcdir.intranet'
>>   Result: h_aliases=`high'
>>   Result: h_aliases=`localhost'
>>   Result: h_addr_list=`127.0.0.1'
>>   high localhost
>> When I run the same command on congress, which has a working logwatch, I
>> get:
>>   gethostname()=`congress'
>>   Resolving `congress' ...
>>   Result: h_name=`congress.opcdir.intranet'
>>   Result: h_aliases=`congress'
>>   Result: h_aliases=`localhost'
>>   Result: h_addr_list=`127.0.0.1'
>>   congress localhost
>> This seems to me to eliminate the possibility of a misconfigured
>> hostname on high.
> 
>> Does anyone have an idea as to what is causing logwatch to not resolve
>> the hostname correctly?
> 
>> Thanks,
>> Chris Lieb
> 
> I believe I've found the problem!  There is a hash called %swordsmen
> that defines a pair of 'high => 10'.  It appears that a function is
> calling getInt, which uses %wordsToInts to process hostname, turning my
> hostname of 'high' into '10'.
> 
> I'm going to play around with it some more to see if this is the case.

It ends up that was the issue.  I have opened bug 260524 on Gentoo
Bugzilla that includes a patch and a -r1 ebuild for 7.3.6, which went
stable yesterday.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJJqBF5AAoJEJWxx7fgsD+CY1AIAKFqDK3e49MuiLlcgJYMHmRU
Mm09ijk6JECqGjLzfyFbnlhIItKX5njS/NGu8Ki9mr53LTc3A0M08MGEbeg2TJl6
XZPzR/DM/5x9EWZn6uIVxY3mLo/G4xTj1EOWH/aGpQN7uDDQFNjq27gnkfs3V2VB
gNLxN1lylSep6u0knIcvdtt90xHyk3TLwgNORn2KgDSEJPmRIz9hpglrNIHganyQ
ihl2t1SVTitdyKNyhaj5NcYy9BMJDRjyhgZ+FPBEkW27ekaJUQhP/16VlftQVLjk
62Z0Dz7J7Je0jLh2ldLi1+p/iyNxyKH8IXstmDsrwiMU39mjmtDJn3R8zcKBV6A=
=Rq6i
-----END PGP SIGNATURE-----