hostname variable in attachment replacement

[Julian Field]

On 07/08/2009 09:51, Michael Mansour wrote:
> Hi,
>
> --- On Fri, 7/8/09, Randal, Phil<prandal at herefordshire.gov.uk>  wrote:
>
>    
>> From: Randal, Phil<prandal at herefordshire.gov.uk>
>> Subject: RE: hostname variable in attachment replacement
>> To: "MailScanner discussion"<mailscanner at lists.mailscanner.info>
>> Received: Friday, 7 August, 2009, 5:07 PM
>> Julian Field wrote:
>>      
>>> On 06/08/2009 16:21, David Lee wrote:
>>>        
>>>> Dare I say "me, too"?
>>>>
>>>> I seem to recall reporting this (empty 'HOSTNAME')
>>>>          
>> a few years ago.
>>      
>>>> We're now on CentOS 5.3 with MS 4.76.24, and a
>>>>          
>> configuration that
>>      
>>>> tries not to change things unnecessarily.
>>>>          
>> Still seeing it (although
>>      
>>>> our MS configuration only rarely invokes pathways
>>>>          
>> that need it.)
>>      
>>>> I get the feeling that the _intended_ behaviour is
>>>>          
>> for MS's
>>      
>>>> "HOSTNAME" variable to try to inherit a default
>>>>          
>> value from somewhere
>>      
>>>> (i.e. to try to avoid being empty).
>>>>
>>>> This intention might be the result of "uname -n"
>>>>          
>> or similar, and
>>      
>>>> probably for a shell HOSTNAME variable, if any, to
>>>>          
>> override it.  Fair
>>      
>>>> enough. Indeed, when I ssh to a box, there is such
>>>>          
>> a variable
>>      
>>>> present on such a login.
>>>>
>>>> But I suspect that, on a reasonably "out of the
>>>>          
>> box"
>>      
>>>> Fedora/CentOS/Redhat installation, by the time
>>>>          
>> "/etc/init.d" is
>>      
>>>> starting MS, neither is HOSTNAME yet set, nor is
>>>>          
>> MS getting it from
>>      
>>>> executing "uname -n" (or similar).
>>>>
>>>> Shouldn't the startup algorithm be something like
>>>>          
>> (pseudo-perl):
>>      
>>>>      $HOSTNAME = if $ENV{'HOSTNAME'} was
>>>>          
>> set
>>      
>>>>
>>>>          
>>    then $ENV{'HOSTNAME'}
>>      
>>>>
>>>>          
>>    else `uname -n`;
>>      
>>>>
>>>>          
>>    # i.e. inherit env.var. HOSTNAME
>>      
>>>>
>>>>          
>>    # else fall back to using system hostname
>>      
>>>> Sorry that's so vague.  But I hope it helps.
>>>>
>>>>
>>>> Jules: could you (a) confirm the intention (for
>>>>          
>> HOSTNAME to be
>>      
>>>> non-empty) (b) outline the intended algorithm to
>>>>          
>> achieve that at
>>      
>>>> "/etc/init.d"-driven startup?
>>>>          
>>> It doesn't currently call uname or anything like that
>>>        
>> at all. If
>>      
>>> $ENV{'HOSTNAME'} is not set, and you had "Hostname =
>>>        
>> $HOSTNAME" or
>>      
>>> similar in your MailScanner.conf, then you will end up
>>>        
>> with an empty
>>      
>>> "Hostname" setting.   
>>>
>>> Jules
>>>        
>> Well, it is set on my boxes, and not messed with in the
>> init scripts, so
>> I'm still at a loss.
>>      
> I did some trouble-shooting (and querying in this list) some year(s) ago too on this very same behaviour and was never able to solve it.
>
> Looking at my setup now, I have a ruleset for Hostname = %rules-dir%/hostnames.rules and in there I have various items with the default being:
>
> FromOrTo:       default                         the %org-name% ($HOSTNAME) Mailscanner
>
> But as I said, the $HOSTNAME has never worked in the reports.
>    
"$HOSTNAME" shouldn't work in the reports, only in MailScanner.conf. But 
"$hostname" should work in the reports.

Jules

-- 
Julian Field MEng CITP CEng
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

Need help customising MailScanner?
Contact me!
Need help fixing or optimising your systems?
Contact me!
Need help getting you started solving new requirements from your boss?
Contact me!

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
Follow me at twitter.com/JulesFM and twitter.com/MailScanner


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.