Skip to Content.
Sympa Menu

en - [sympa-users] Redundancy

Subject: The mailing list for listmasters using Sympa

List archive

Chronological Thread  
  • From: Johann Spies <address@concealed>
  • To: Sympa Mailing list <address@concealed>
  • Subject: [sympa-users] Redundancy
  • Date: Tue, 29 Aug 2006 09:37:41 +0200

I have a server (mail3) which acts as a sympa server (version3.3) inter alia.
The web-address for users is https://mail3.sun.ac.za/wws and they email to
<mailing list>@mail3.sun.ac.za to send messages to a list.

On mail2 I have now installed a newer version (5.1.2) of Sympa using
https://mail2.sun.ac.za/sympa as address and handling email coming to
<mailing list>@mail2.sun.ac.za.

On mail3 I did not use changes in /etc/aliases but router and transport
entries
in the exim-configuration in stead. I did this because on 3.3 I had to change
/etc/aliases every time when a new list was created. On the newer version
/etc/mail/sympa.aliases gets updated by sympa programatticaly. So on the mail2
I want to return to the use of the aliases-file and not use the
router/tranport-configuration in exim for this purpose.

I want mail2 to be able to stand in as sympa server when mail3 is not
available. The first opportunity will be when I upgrade mail3 to a
similar version in the near future. It is easy to setup a virtual IP
address to advertise itself as mail3 on the network when mail2 is down.
But how do I handle the sympa-related stuff without re-doing the whole
configuration on mail2 (both for sympa and exim)?

I have thought of doing something like this, but I would like some
advice from this group on a better way of doing it:

1. Inform the mailing list owners of a period of possible unstability
for sympa.
2. Create an alias (in the Apache configuration) for wws/ on mail2
referring to sympa/.
3. Copy the ssl-certificate of mail3 to mail2 and restart apache on mail2.
4. Dump the postgresql-database on mail3.
5. Stop Sympa on mail3.
6. Import the database on mail2. (In future I would like to get some sort of
database replication going.)
7. Copy the content of /var/lib/sympa/expl from mail3 to mail2
8. Update /etc/mail/sympa.aliases on mail2 to reflect the situation of sympa
on mail3.
9. Stop the network on mail3
10. Create a virtual IP on mail2 with mail3's IP address.
11. Restart sympa on mail2 and see what is malfunctioning...

What have I overlooked?

Regards
Johann
--
Johann Spies Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

"Preach the word; be instant in season, out of season;
reprove, rebuke, exhort with all longsuffering and
doctrine." II Timothy 4:2



Archive powered by MHonArc 2.6.19+.

Top of Page