Trouble-free steps to upgrade mailscanner?

[Glenn Steen]

On 11/05/06, Julian Field <MailScanner at ecs.soton.ac.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dan Stromberg wrote:
> > On Thu, 11 May 2006 11:39:12 -0500, Alex Neuman van der Hans wrote:
> >
> >
> >
> >>> For example, is there a way to have two versions of mailscanner running on
> >>> the host at the same time, so you can test the new one, and cut over later
> >>> once you feel confident about the new one by doing something simple, like
> >>> changing a symlink and restarting a daemon?
> >>>
> >>>
> >> I think somebody mentioned something like this (they were talking about
> >> BSD I think) where someone would:
> >>
> >> 1. Stop MailScanner
> >> 2. Move /wherever/MailScanner to /old/mailscanner
> >> 3. Create symlink from /wherever/MailScanner to /old/mailscanner
> >> 4. install new MailScanner to /new/mailscanner
> >>
> >
> > Yes, this sounds like a good way to go.
> >
> >
> >> Then test everything separately using whatever method you want, and in
> >> the end you just stop MailScanner, change the symlink, and start it again.
> >>
> >
> > What are some "cover the fundamentals" test methods for MailScanner?  Is
> > it just a matter of sending four messages: ham+novirus, spam+novirus,
> > ham+virus, spam+virus and making sure they're handled well?
> >
> Download the EICAR test virus from www.eicar.org and send it through
> MailScanner a few times to check its reaction. That and a few spam
> messages will check it is basically working for you. I have a huge
> library of test messages that I use for testing various bits of the
> functionality, but unfortunately I can't share these with you for
> privacy reasons, sorry.
> > And if I wanted to test it out by just sending something from evolution on
> > my office server, would I need to configure a second pair of sendmail's,
> > where the -bd one of the second pair was listening on an alternate port
> > for a while?
> >
> You not only need that but they need to use different queue directories
> as well, and you'll need to configure the secondary queue directories in
> MailScanner as well.
>
> Using a spare machine for testing is rather easier, as you can leave it
> configured as a test system. If you stop the outgoing queue runner
> sendmail and set "Delivery Method = queue" then it won't actually
> deliver the processed messages, so you can examine the files in the
> queue. I always check the queue files than let them be delivered.
> >
> >> 2. Use the archive feature, albeit temporarily. You can always requeue
> >> e-mail back into the system if it breaks, right?
> >>
> >
> > I really like this feature.
> >
> Glad you find this useful.
>
> - --
> Julian Field
(Both replying to Dan and ... well... anyone... Just to be clear:-)
Wouldn't it be great if someone who actually uses the tar-ball typed
something about this into
http://wiki.mailscanner.info/doku.php?id=documentation:install_upgrade:upgrade:tar
(need not be more complex than the instructions found in this thread,
I think... Look at
http://wiki.mailscanner.info/doku.php?id=documentation:install_upgrade:upgrade:rpm
and http://wiki.mailscanner.info/doku.php?id=maq:index#upgrade_rpm for
inspiration:-)?
Julian? Alex? Someone?
I'd do it myself, but since I only use the rpm method (ATM)...:-)

As for the "best test" question... Well, there's some basic
instructions in the MAQ and the troubleshooting section of the wiki...
Basically
1) send mail->check,
2) send EICAR->check
3) send GTUBE->check
perhaps 4) send combined->check
And if you really want to ... stress things ... do as Julian suggest
and use a large body of collected mails for some "stress and quality
testing", to finish things up.
But ultimately there's no "test" like production...:-).

-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se