Scalix Forums

Hello Folks,

When we first installed Scalix I was told by our rep that the SIS server and the webmail server can be split off to their own machines. I was able to get the webmail portion working in a few minutes. However, after getting the SIS services installed on a new machine I can't for the life of me figure out how to get the primary Scalix install to point to it. Has anyone else made a configuration like this work?

You have a running instance of scalix on machine1? And want the indexer to run on machine2? Why?

First you must plan ahead what you want to do.

Plan on what (physical) server you want to run what services. make a note of the IP adresses and password for every service you want to configure and just start building.

Build the server where the mailstore will reside first and afterwards build the web-access server..

If you have a SAN you might pull it off to have the SIS on different server from your mailstore.. but both servers should have acces to the data..

Thanks for the reply Paul. I am looking to move the SIS service to avoid some issues were are having with the indexer. Basically on a regular basis we hit a point where when the indexer is running the tomcat instance will hit "Too many open file handles". This takes out smtp, calendar, and webmail services. After beating my head against it for a while, combing the forums, and talking to support. It appears the answer is"this just happens sometimes", and our only 100% functional work around is to stop the indexer. That means server side searches stop working. Since the issue can not be currently solved it seems prudent to break off the sis service and if that tomcat instance crashes then it will not affect the other services.

Does the SIS server need direct access to the mail store? It appears that if I run the indexer binary on the machine with the mailstore and point it to SIS on another server the indexes will be stored on that second server and available to scalix via "http://<newserver>/sis/".


Q

The "too many open files" issue can be resolved by increasing ULIMIT_NUM_FILES in /etc/opt/scalix-tomcat/scalix-tomcat.conf.
As a rules of thumb it was said that one should calculate 20 open files per mailbox, but a heavy public folder usage will add additional files for SIS.

We have moved the SIS to a seperate Instance for systems with a large userbase (a couple of thousands mailboxes).
In general we only need to install the SIS webapp, but the installer is a bit keen when dealing with such special setups. It would be acceptable just to install a dummy instance, even with an empty messagestore and without license.
During the setup the IP of the real server should be used to whitelist the source address (look at the whilelist settings in sis.properties).

The InstallGuide PDF (p. 117) refers to another necessary point

When it is installed on a different machine, edit the following lines in the file /var/opt/scalix/<nn>/s/sys/general.cfg where nn varies with installation:
USRL_SIS_URL=sxidx://<FQDN:port>/%u
USRL_BB_SIS_URL=sxidx://<FQDN:port>/BB@<fqdn>
where FQDN is the host that the Scalix Search and Index Service is installed on, and the port is optional, but is almost always 80.

Once this it adjusted, the messagestore has to be reindexed. In theory it would be possible to move the indexes structure and do an ommodu to adjust the SIS-URL. But I would only do that if a full reindex is not an option due to the heavy load the index.browse are creating on the backend.
To reindex the messagestore, the "slow moving indexer" http://downloads.it25.de/scripts/misc/sx_slowindex could be used.

wow, nice one..

Thanks for the reply. I got it working.
The ULIMIT_NUM_FILES would delay the problem but not fix it.

The SIS Variables and one other small piece were what I was missing. Those vars were not in my general config so I had to add them then I had to write a small shell script to change the SIS_URL for all the existing users ( omodu --index) to point to the new server. I kicked off a re-index and everything is moving along great.

Thanks again for the help,

Q