HOWTO: updating sx 11.4.1 to 11.4.2 on opensuse

[ruth_schell]

hi folks,

since this forum helped me a lot in the past (and hopefully will in the future) i'd like to contribute my notes on a successful upgrade from sx 11.4.1 to 11.4.2 on opensuse (32bit).

---DISCLAIMER---
this is how it worked for ME.
it might screw up your installation.
BE SURE TO HAVE AN APPROPRIATE BACK BEFORE YOU START.
don't blame me if things go wrong. all commands were typed by you.

1. updating OSS 10.2 to OSS 11.0
1.1. make sure DVD is ok by checking installation medium via YAST.
1.2. boot from OSS 11.0 installation DVD
1.3. select 'Installation' and later on 'Update'
1.4. i had to (re-)install libglib-2-0-0, libgobject-2-0-0, libgthread-2-0-0 via YAST
1.5. change bootloader to the new OSS11.0 installation

2. installing SX 11.4.2
2.1. use the sx-installer to delete the scalix 11.4.1 DB package since it interferes with the new postgres-version shipped with OSS 11.0. no backup is needed, since the content will be recreated magically afterwards.
2.2. delete old postgres data: rm -r /var/lib/pgsql/data/* as root
2.3. reboot
2.4. install all the sx-components you need using the sx-installer
2.5. recreated scalix-db content: /var/opt/scalix/NN/s/diag/sxapiprerp.py -u 'SX-ADMIN-USER' -w 'PASSWORD'

3. enjoy the great new SCALIX 11.4.2. relaese.

hope this is useful for anyone out there.

[smpoole7]

Thanks, Ruth. That would have come in handy for us a couple of weeks ago.

By the way, I ditto the thing about deleting the postgres DB. That solved many issues that were having when we upgraded. We did the following:

1. Uninstall Scalix DB and Tomcat (and all Tomcat dependencies, of course).

2. Delete the postgres/data directory

3. Reinstall Scalix DB and the Tomcat stuff.

That solved a LOT of problems that we'd been having with messages magically reappearing, users suddenly losing Webmail access, etc. etc.

[smpoole7]

OK! We've finally done the complete move. I'll add to Ruth's comments by detailing what we did, step by step. Between the two descriptions, anyone upgrading should be able to do so without a lot of trouble. Obviously, you'll have to be logged in as root to do all of the following.

Scenario:
Old server - Poweredge 2850, Opensuse 10.2, Scalix 11.4.1, IP 192.168.1.95
New server - Poweredge 2950, CentOS 5.2, Scalix 11.4.2, IP 192.168.1.250

Our Internet access goes through a separate firewall/router with port forwarding to send the packets where they need to go. This made our installation go more smoothly. I recommend that you do this, for the server upgrade if nothing else. The two machines will be able to "talk" to one another on the LAN. You can go to a direct connection once you're sure everything is working (but be sure to change the IPs again, in that case, as discussed below).

You can build up the new server at leisure, but you'll be down during the actual move from old to new. Plan it for a weekend and send out a warning that the "server will be down," etc., etc. To give you an idea, our actual move (old 6.7 Gig mailstore to the new machine, back on line sending and receiving mail) took about 1-1/2 hours total.

Finally, remember that in a typical single Scalix installation, the name of the mailstore directory is derived from the hostname; in our case it's "pop," so the complete path is "/var/opt/scalix/pp." Yours may be something other than "pp."

But ACHTUNG: ESPECIALLY be warned that, with the same hostname, your bash prompts may look identical, leading to heartbreak if you use a KVM or SSH (such as deleting the wrong mailstore on the wrong machine ... speaking from experience!!!). I changed our prompts to show the last few digits of the IP address to make them different.

Here's how we did it, step by step:

1. Install CentOS on the new machine. Get it happy. Make sure it has network access, etc. Make sure it has the same hostname as the old server, as already discussed. Do NOT enable SELinux, unless you want to spend a huge amount of time later getting Scalix to work properly.

2. Install Scalix 11.4.2 on the new machine. Use the same passwords as for the old machine. Create a new, empty mailstore. Confirm that everything works: pull up a browser on the new machine, use SAC to create a couple of dummy accounts and send emails between them with Webmail.

3. Now kill ALL Scalix/mail-related services on both machines. I don't just use omshut; I've had problems with random mailstore corruption unless EVERYTHING is dead:

Code: Select all

service scalix stop
service apache2 stop (for Opensuse; it's "service httpd stop" on CentOS 5.2)
service sendmail stop
service ldapmapper stop
service scalix-tomcat stop
service scalix-postgres stop


3-1/2: Unplug your phone and throw it in the closet. Otherwise, you'll be constantly distracted by people yelling, "the mail is down!" ... even though you sent out that warning. (Trust me.)

4. Delete the tiny new mailstore on the NEW server. DO NOT delete the mailstore on the OLD server; triple-check to ensure that you're on the NEW server before entering this command:

Code: Select all

#ON THE NEW SERVER, NOT THE OLD ONE!

rm -f -r /var/opt/scalix/pp/*


4. Copy the mailstore from the old server to the new into that same location. On the OLD server, I entered:

Code: Select all

rsync -avz /var/opt/scalix/pp root@192.168.1.250:/var/opt/scalix/pp


Whatever you use -- "cp" with a flash drive, "rsync" over the network or some other method -- make sure to keep the permissions and ownerships intact (whence the "-a" option with rsync, in this case). This will save headaches later on. Also, you can now turn off the old server. Keep it safe. It's your fallback if you just can't get the new server working.

From now on, I'm referring exclusively to the NEW server.

5. Let's ensure that the "s" directory is owned by scalix (the UID and GID may not be the same on the two servers; this will fix that).

Code: Select all

chown -R scalix.scalix /var/opt/scalix/pp/s


6. Run omcheck to further confirm file permissions and ownerships. I used:

Code: Select all

omcheck -i -s > fixiti
sh fixiti
omcheck -d -s > fixitd
sh fixitd
rm -f fixiti
rm -f fixitd


If you like, run "omcheck -i" and "omcheck -d" one more time just to be sure. NOTE: it's normal to get "sendmail.m4 not found" and the usage info on "ompifchk" (?). You can ignore these.

7. Update the mailstore for the new version of Scalix.

Code: Select all

ompatchom


8. Now for the important part: run the scalix-installer and DELETE the scalix-DB component. When it offers to delete the current database, tell it YES. When it finishes, re-run the scalix-installer and re-install the scalix-DB. This will rebuild the database.

9. Just as important: your new server has a different IP address. Pull up each of these in an editor (I used nano) and do a search and replace on all occurrences of the old IP address. I had to change these files:

/var/opt/scalix/pp/res/config/ubermanager.properties
/var/opt/scalix/pp/postgres/pg_hba.conf
/var/opt/scalix/pp/sis/sis.properties
/var/opt/scalix/pp/s/sys/Osmtpd.conf

Reinstalling the DB should have fixed pg_hba.conf, but check it to be sure. We had to change Osmtpd.conf because we use an external Spam filter; this may not apply to you. If you have strange problems later such as Webmail or SAC not opening, use grep to find all occurrences of your old IP. Be warned that the Scalix mailstore has sockets and pipes scattered around that will cause grep to hang. (Sigh.) You may have to do each grep on a directory-by-directory basis. (Sigh again -- and speaking from experience.)

10. Rebuild the indexes. I used:

Code: Select all

rm -f -r /var/opt/scalix/pp/indexes/*
rm -f -r /var/opt/scalix/pp/indexwork/*
sxmkindex


NOTE: if you have a lot of users and a huge mailstore, it can take quite some time to rebuild the indexes. See "man sxmkindex" for options. My server isn't that huge, and I can rebuild all indexes at once in a couple of minutes.

11. Now cross your fingers and re-start scalix! Reverse the order of the "stop" commands listed above:

Code: Select all

service scalix-postgres start
service scalix-tomcat start
service ldapmapper start
service sendmail start
service httpd start
service scalix start


If any of these fail, stop at that point and check the appropriate log. I used the following as needed:

Code: Select all

less /var/opt/scalix/pp/postgres/pgstartup.log
less /var/opt/scalix/pp/logs/fatal
less /var/log/messages
less /var/log/mail.err
omshowlog -F xx:xx


The "pgstartup.log" will detail problems with the Scalix-DB (Postgresql). The "omshowlog" command with a specified time (ex., "-F 01:00" for everything since 1 AM) is handy for Scalix problems. Note the exact time in which you tried to restart the server and look at the logs from that time forward. In any event, one of these logs should tell you what the problem is (most often it will be a file permission error; find that file and "chmod" or "chown" to make it accessible).

12. Open the required ports in the new server's firewall. We don't use the Outlook connector and don't have SSL/HTTPS on our Scalix server, so all we needed was ports 25 (SMTP), 80 (HTTP), 110 (POP), 143 (IMAP) and 389 (LDAP, for our separate Barracuda Spam filter; if you don't have one, just leave this port closed).

13. In our case, since we use a router/firewall between the Scalix server and the Internet, we had to go in and redo the port forwarding. All mail now goes to 192.168.1.250, instead of 192.168.1.95. Once we were done, the server was live, exposed to the Internet and handling mail just fine!

The Scalix gurus here can doubtless suggest refinements. I admit that I probably inserted some steps that weren't absolutely necessary. The plus side is, though, I KNOW this procedure works.

[smpoole7]

... which, in retrospect, I probably should've mentioned. Those Dell Poweredge servers are *FAST*. Really FAST, with dual multi-GHz processors, tons of memory and all the bells and whistles. (We ordered them maxed-out and tricked up.)

It only took a few minutes to rebuild our indexes (for 400 users), but if you're on a slower machine, your mileage will obviously vary. I should have mentioned that.

[birdra]

Thanks, a bunch Ruth. Your info was spot on. I was upgrading from openSUSE 10.1.to 11.0 and was a little worried.