hostname variable in attachment replacement

[Julian Field]

On 06/08/2009 16:21, David Lee wrote:
> On Thu, 6 Aug 2009, Randal, Phil wrote:
>
>> Erik Bloodaxe wrote:
>> [...]
>>>>> Is there a way to have a variable in the attachements that replace
>>>>> unacceptable file types and content that expands to the host names.
>>>>>
>>>>> I.e. in stored.filename.message.txt in etc/reports/en
>>>>>
>>>>> I want a line saying
>>>>>
>>>>> File is in: $(HOSTNAME) in $quarantinedir/$datenumber/$id
>>>>>
>>>>> so that my sysadmins can see which of the many servers the file is
>>>>> on as the standard reports give them no indication of which server
>>>>> to get the file from.
>>>>>
>>>>> I have tried all the obvious
>> [...]
>> I see that on CentOS 5.3 too, so it is no just your installation.
>
> 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

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