Configuration suggestion...

[Julian Field]

On 10/08/2009 19:56, Michael H. Warfield wrote:
> On Mon, 2009-08-10 at 19:00 +0100, Jules Field wrote:
>    
>> I don't quite see what that would achieve that the
>> upgrade_MailScanner_conf doesn't.
>> I don't entirely understand your point, sorry.
>>      
> 	The point is that upgrade_MailScanner_conf is a PITA.  I typically have
> to have two screens up and refer back and forth while I've got the
> instructions from one process in one screen and performing the actions
> in another.
>    
Sorry, I always thought it was rather neat, in that it copies over all 
your old settings, puts all the comments in the right place and so on. 
Damn site easier than just having what most packages give you, which is 
your old file and a new "default unconfigured" file where you have to 
merge the two by hand to create your new one.

Adding "include" files means that I need to allow settings to be 
over-written by later instances of the same setting, and I need to keep 
track of a whole stack of nested "include" files. Currently it will 
complain if it sees the same setting twice, but I would have to disable 
that, which I'm not keen on doing. And in the nested "include" file 
handling, I've got to do loop detection and other nasties so you can't 
trivially break it.

Most sensible people who have multiple servers always document upgrade 
instructions like this so you can just follow some noddy guide you wrote 
rather than trying to be sure you didn't miss anything each time when 
you get distracted by the phone ringing in the middle of it all. And you 
just cut and paste your instructions :-)

> 	The install script tells you to run upgrade_MailScanner_conf, but then
> it tells you "if you're running an rpm distro do..."
>
> cd /etc/MailScanner
> upgrade_MailScanner_conf MailScanner.conf MailScanner.conf.rpmnew>  MailScanner.new
> mv -f MailScanner.conf MailScanner.old
> mv -f MailScanner.new  MailScanner.conf
>
> 	... But then that tells you ...
>
> then you should do
>    diff -w MailScanner.conf.rpmnew MailScanner.new
> and check for any differences in values you have not changed yourself.
>    
My instructions are fine for beginners in my view. They can add the 
"diff -w" step into their process, I'm sure it's not *that* confusing. 
If you already know what you're doing, like you, then you can skip the 
bits of the instructions that you know you don't need. Occasionally I do 
change default values of things, and so *may* overwrite your previous 
setting. If you don't know about that, it could be a nasty surprise. 
Hence the added extra step.
>
> Once you have checked that MailScanner.new contains what
> you want, you can then save your old one and move the new
> one into place, using commands like these:
>    mv -f MailScanner.conf MailScanner.old
>    mv -f MailScanner.new  MailScanner.conf
>
> 	That's a lot of manual steps that have to be performed each time on
> each system.
That's why God invented cut and paste.
>    Having a site configuration would obviate the need for all
> of that.  You just update the main file which could be easily handled in
> a simple rpm update like all the other packages do.
>    
I could just do an upgrade_MailScanner_conf; mv; mv in the RPM instead, 
that would remove the whole exercise from your hands. I just thought 
many people might like the opportunity to do it by hand so they get to 
see it working.

I'm not against you or anything like that, I just wanted to present my 
side of the situation too, to see what you think. It's not only your 
opinion that matters, I need input from others before I change any of 
this too.

Implementing nested include files is non-trivial.
> 	Mike
>
>    
>> On 10/08/2009 18:42, Michael H. Warfield wrote:
>>      
>>> Hey all, Julian,
>>>
>>> 	I was just in the process of upgrading MailScanner on several machines
>>> and had been doing a few other similar things to some other packages and
>>> had a thought regarding the configuration file.  Right now, we use the
>>> configuration upgrade script and some diffing and what not (I'm on an
>>> rpm based system - Fedora 10).
>>>
>>> 	Maybe this has been brought up in the past and dismissed and maybe
>>> there are good reasons for not doing it or may it can be done, I just
>>> don't know how...  But...  What about a separate, site specific,
>>> configuration file?  Keep the main file with all the default options but
>>> then have the admin put customized options in a separate file and not
>>> modify the main file?
>>>
>>> 	Several other packages I know do it this way and it makes updating so
>>> much easier and less error prone.  The main file would then have
>>> instructions to put customized values into the site file while it still
>>> retains all the possible options and their defaults and the detailed
>>> instructions.  The admin can make the site file as complex or as simple
>>> as he likes.  Updates then merely require a check that the main file has
>>> not been alter and then a simple replacement.  Value checks and warnings
>>> could still be applied but then it would be to both the main and site
>>> specific file.  Maybe make the configuration file(s) a colon separated
>>> string, like a PATH, with the last value read from any of them holding
>>> precedence.
>>>
>>> 	Yes, there is the possibility that the user might have some
>>> incompatible option in a site file that could cause a version skew
>>> problem.  Given the normal tunable parameters, this would seem pretty
>>> unlikely and could be caught in the update check for default files.
>>>
>>> 	It would certainly make packaging for a distribution much easier and
>>> updates much more convenient for the system administrator.
>>>
>>> 	Just a thought.
>>>
>>> 	Regards,
>>> 	Mike
>>>
>>>        
>> 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.
>>      
>    

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.