Scalix Forums

Dear Scalix.

PLEASE drop support for Fedora and OpenSuse.

As you know, it's not supported for production, but many people have taken it there without understanding that there is a huge negative consequence involved.

1) Dropping support makes Scalix better because less time is spent doing QA on a platform that's effectively useless (Since it shouldn't be used in production).
2) It also helps because users who do not understand the consequence of a decision to use FC will simply not be able to make that (poor) decision.
3) From a reseller perspective, it saves me receiving a phone call from a client who is looking at a HUGE bill to do what should be a 5 minute upgrade. If they're on SBE20, they're going to spend more money migrating than they spend buying the software (and perhaps the hardware too). This makes Scalix look too expensive for them, and I can't help but feel like I'm ripping them off simply because they tried to save a bit of money. It's awkward all around.

With CentOS now officialy supported, there is no reason at all to maintain support for any other community supported distro. PLEASE PLEASE PLEASE drop them.

Kev.

I second that whole heartedly

Now that we have CentOS. Fedora & OpenSUSE cause to many issues on the forums.

Mike

Hi!

With all the "stars" agreeing in several threads on this topic, let me throw in a somewhat different opinion.

We all know the importance of choosing the *right* Linux distribution. It may be a semi-religious matter (see, e.g., http://ars.userfriendly.org/cartoons/?id=19990301 ) or be motivated by more earthly factors, for example, that the OS to be used should run on the available hardware.
We recently bought a state-of-the-art new machine to be the new mail server for our university department. It would run under openSUSE 10.3, with Postfix, SpamAssassin, Squirrelmail for web access, just like the old mail server did. Nobody had considered anything else yet. Only after the machine was up and running, the possibility of having "a groupware something" was suggested and only at this stage, we started looking at Scalix as one of the possible options.

However, the understandable desire of the "stars" to only have Scalix versions that require supported enterprise operating systems would effectively have ruled out this option. Our hardware was not yet sufficiently antique to be "supported". SLES10 (would have been the OS of choice, considering that we use openSUSE otherwise and started to use it when it still was S.u.S.E. long ago) could not be installed: the original version didn't even recognize the DVD drive with the installation medium. SLES10 SP1 did, but had problems with the SAS controller in Raid-1 mode. I haven't tested the latest CentOS 5.1; version 5.0 didn't work either.
On the other hand, openSUSE 10.3 installed flawlessly and setting up Scalix 11.3 (openSUSE 10.2 version) only required minimal non-permanent changes. We could test it and find that it does what we want and does it very well. We decided to keep using it and it is even being considered to upgrade from the Community Edition to a licensed edition.
This is the result of the availability of the unwanted openSUSE version.

I consider freedom of choice a good thing, even if it implies the freedom to choose an option that may have drawbacks. It is a good thing that Scalix so far has been open-minded enough to offer such a choice.

A final remark, to restore peace of mind: meanwhile, SLES10 SP2 is available and this release handles our hardware correctly. We will probably switch to this OS in the near future.

Hi nvehommes


We understand your requirement for freedom of choice and your desire to use your current hardware that is not complient with the SLES or RHEL HAL. However you have not looked very far ahead. Two Scalix versions from now your OS will no longer be supported. What then. You will be comming back to this forum with questions on how to mangle Scalix to do something which it will not be at that stage designed to do or you will not be able to upgrade your Scalix installation or you will be forced to trash your installation install the then current version of Opensuse or Fedora core and reinstall Scalix. In a production enviornment this would be unacceptable. From a support point of view this is unacceptable. We have seen SSSSOOOOO many people come to grief in this way in the past that I personally have recently started to ignore any request for help from people with these platforms. But that is OK because there are still those that will help.... for now.

IMHO

Mike

nvehommes,

hardware choice is critical. If you choose bleeding edge hardware, then 9 times out of 10 you'll need bleeding edge Operating Systems and that leads to you know what, which we've all talked about.... ;)

I always use HP servers, because they support RHEL. I know the hardware will work with RHEL and CentOS.
The only time i deviated, even though it was still a HP machine was for a firewire card, because thats what the client wanted, which required FC6. But then this server was NOT a Scalix server, just a BackupPC server. Yet it still caused me headaches, especially when i tried 64bit OS first and then had to go back to 32bit after issues. But i digress.....

Back to the point....

I don't mind if Scalix still provide packages for Fedora and OpenSuse, but i would like to see them come under the same hat as the provided Debian packages. That way its clearer to everyone that it is really an unsupported environment and this will help people when they initially make a choice of OS.

All,

first of all - thanks for the discussion, I really enjoy the fact that this forum is such a lively place with diverse opinions; certainly better to have heated debates than none and it helps me tremendously in my job of planning ahead for the product.

OS support has always been a specifically hot topic and it's pretty clear why. Obviously, what's needed here is a good balance between our efforts to support platforms (and each extra one is very, very expensive, especially when it comes to testing and QA and also support - just consider that we have to keep boxes up and running for reproducing issues, potentially put multiple versions of Scalix on, patch them - we literally have a library of 100s of VMs with different combinations lying around, plus some hardware boxes for performance-related issues as well, as well as we are running our multiple internal production servers on different distros for dogfooding reasons), customer demand, ease of deployment, but also questions of sustainability. Tough choices.

1. We definitely can't afford to support multiple versions of the community platforms at the same time - that would grow our test matrix beyond what's possible.

2. Support for current hardware vs. stability is one concern, so is freely available vs. commercial distros; CentOS is interesting, as it addresses the latter, however not the former.

3. For a production email server, I would personally always go for a fully-supported stack, including hardware, OS, software; fortunately the big hardware vendors give us this option these days and people like HP, Dell and IBM are great examples of how viable Linux has become as a server OS with them providing a very, very, very decent level of support, some minor glitches here and there, but in general, great work. They - and possibly some unnamed others - would be my preference.

4. I understand, and nvehommes story fits the picture, that sometimes, even in server environments, hardware was acquired,then repurposed. Now, I imagine there will be cases where people buy hardware for use with a Windows server OS, then decide that Linux is the way to go. That's a good thing, IMHO, as every Linux box out there helps the greater cause. Sometimes that means that bleeding edge hardware support is indeed required and that may trigger some temporary solutions that are not in line with what I named as preferred, yet unavoidable. Again, I'd always prefer someone using Scalix on top of Fedora over him going with Windows 2003 and Exchange, just because hardware is supported there. Yes, I do.

5. I can't even say that those distros have created us more support trouble than the enterprise linuxes in the past, at least by in large. On the contrary, some enterprise versions like early RHEL4 drops (and that would include their CentOS counterparts) carried forward terrible bugs in their kernels for a long time (I am thinking of LVM snapshot functionality being unstable and unuseable until SP3 or so!) where the community counterparts had long integrated the reuquired patches to fix the issue.

6. The exception to this is obviously the upgrade/migration situation, and again I can't see us doing anything to help that, as the only solution from our side would be multi-release support for those platforms and given their release cycles, that's not doable for us. I think it is up to us to do a couple things here. Those could include:

(1) Fully document the process for x-distro upgrades/moves/migrations of Scalix. This would not resolve the extended downtime issue compared to an in-place upgrade - in-place Scalix 11.3 to 11.4 takes about 10 minutes while x-distro migration requires the better part of a day, at minimum - but at least remove some of the repeated how-to questions on this forum.

(2) Make it more clear to users what they are signing up for. I don't agree that we should change the licensing to be the same as for debian, i.e. make SBE/EE license keys unavailable for those platforms. It would then be better to remove them completely as the discussions around not providing license keys for debian have caused us infinite grief as well. I am not sure about the Installer thing either. If it's a simple yes/no question, people will generally ignore it and read it about as carefully as a license agreement , and while I sometimes have my dark phantasies as well, my experience with proposals such as Kevin's cruel typing excercise is that the first person this hits back on is the person who invented it. I don't want to be that one, so I would possibly put a hidden switch in to avoid it, which would then become known through some leak or because the Installer is Open Source, and so on. Anyway, there is a task and I will think about it.

(3) become less distro-specific with the product - unfortunately, experience with at least the base server component has shown this to be highly problematic; other app vendors confirm that and sometimes even go farther and only support certain patch levels - fortunately, that hasn't been necessary for us so far although SLES9 SP4 broke a couple things here and there.

BTW, I like hvehommes tactics to consider his OSS 10.3 installation temporary on the way to SLES as it updates it's hardware support - this way he can keep using his hardware and will only have to go through the upgrade pain once, then be good. I'll also like to think that with his next hardware purchase, he'll be more careful checking his options - that's good example of freedom of choice combined with considerate strategy and I'd assume that he's facing the situation with his eyes wide open.

So... bottom line is that there is no right or wrong here; I don't really want to make Scalix less accessible for many. I have worked through some threads here as well describing upgrade hell. I totally support Community Edition installs who want to or need to go for a no-cost (on the licensing side) solution, as much as I also like my company being successful with their commercial endeavours, for which we need commercial customers and revenue, being as simple as that. So... no final verdict here, let's think about it some more and see where we can improve.

We'll all keep learning from each other, that I have no doubt about.

Cheers from Berlin, visiting LinuxTag 2008,
Florian.

Greetings!

florian wrote:... I think it is up to us to do a couple things here. Those could include:

(1) Fully document the process for x-distro upgrades/moves/migrations of Scalix. This would not resolve the extended downtime issue compared to an in-place upgrade - in-place Scalix 11.3 to 11.4 takes about 10 minutes while x-distro migration requires the better part of a day, at minimum - but at least remove some of the repeated how-to questions on this forum.

Florian, that would be excellent!
Of course, I've already searched the forum and found a couple of suggestions on how one might/should proceed, but they differ in details and I wouldn't simply start the migration based on this info. Therefore, I've decided to experiment on (for very good reasons ) an isolated system with copies of our mailstore. I've already discovered several seemingly correct ways to let the migration fail impressively, as well as a number of easily overlooked points that cause weird errors afterwards, but I also did manage to get things to work, including the update to 11.4. However, that involved several install/deinstall cycles, which of course is not satisfactorily.
So migrating definitely is tricky and every piece of additional documentation or experience will be very helpful. (I'd be happy to share my experiences, btw.)

On the other hand, 11.4 looks great. I had a few coworkers check that their mailbox copies were OK and they were very disappointed that they could not yet have the new, much faster SWA for daily use.

Best wishes,

Nico

nvehommes wrote:Greetings!

florian wrote:... I think it is up to us to do a couple things here. Those could include:

(1) Fully document the process for x-distro upgrades/moves/migrations of Scalix. This would not resolve the extended downtime issue compared to an in-place upgrade - in-place Scalix 11.3 to 11.4 takes about 10 minutes while x-distro migration requires the better part of a day, at minimum - but at least remove some of the repeated how-to questions on this forum.

Florian, that would be excellent!
Of course, I've already searched the forum and found a couple of suggestions on how one might/should proceed, but they differ in details and I wouldn't simply start the migration based on this info. Therefore, I've decided to experiment on (for very good reasons :wink: ) an isolated system with copies of our mailstore. I've already discovered several seemingly correct ways to let the migration fail impressively, as well as a number of easily overlooked points that cause weird errors afterwards, but I also did manage to get things to work, including the update to 11.4. However, that involved several install/deinstall cycles, which of course is not satisfactorily.
So migrating definitely is tricky and every piece of additional documentation or experience will be very helpful. (I'd be happy to share my experiences, btw.)

On the other hand, 11.4 looks great. I had a few coworkers check that their mailbox copies were OK and they were very disappointed that they could not yet have the new, much faster SWA for daily use.

Best wishes,

Nico

Nico,

this has worked for me in the past, (if i remember it correctly...)

1. backup all of var opt/scalix and make note of the scalix usier id and gid, you want it to be the same.
2. install new OS. Rather than do upgrade installs, i tend to to clean installs and start a-fresh. Use the same hostname and IP address so you end up with the same mailnode etc.
3. install new version of scalix matching the new OS. Make sure scalix uid and gid match as previous install.
4. stop scalix.
5. mv /var/opt/scalix /var/opt/scalix-virgin
6. restore /var/opt/scalix
7. mv /var/opt/scalix/xx/postrges /var/opt/scalix/xx/postges.old
8. rsync -av /var/opt/scalix-virgin/xx/postgres /var/opt/scalix/xx/.
9. run ompatchom
10 run omcheck
omcheck -s -d > /tmp/check_file
review the file and then type:
sh /tmp/check_file
11. check your /etc/opt/scalix directories and /etc/opt/scalix-tomcat to make sure configs are right.
12. start scalix.

reason for postgres stuff - it changed versions from 7.4 to 8 and it could upgrade the data, so just let it recreate all the indexes.

Thats how i remember it. The vital things are the uid/gid, same hostname, ip address.

Hope that helps you out.

Regards,

Les

Greetings!

Les, thanks for the info. I ran your complete procedure, starting with a fresh install of Scalix 11.4. However, it appears that some things have changed; it may of course also have to do with the fact that the original mailstore was created on a different system. I noticed the following problems:
1. webmail is extremely slow; loading a mailbox, calendars, the options dialog, the rules editor, whatever I tried takes forever.
2. mobile access reports the dreaded "error A00000", even though the IP number and hostname are correct. (This is on an isolated system, with local DNS server.)

However, I've now figured out a procedure that at least appears to reliably get my installation migrated. Here, I present a description, with comments, of what I did and what happened, hoping for comments and additions, in particular from Scalix people, in order to improve the procedure. This is on an isolated test system, not yet on the real server.

Starting situation: Scalix 11.3 community edition for openSUSE 10.2, installed on an openSUSE 10.3 system. Target: Scalix 11.4 on a SLES10 SP2 system.

1. On the production mailserver, stop all Scalix services, write a tar-file of the contents of /var/opt/scalix; restart Scalix. This tar archive will be used to test the installation on a freshly installed SLES10SP2 system.
2. Install SLES10 SP2 on the test system. Note that you are expected to set up LDAP authentication. This is incompatible with Scalix. A local DNS server is helpful (for an isolated system, it is of course essential). Postfix must not be installed, sendmail must be included.
2a. Make sure that the user scalix has the same UID as before and that the group scalix has the same GID. Setting up user and group is not necessarily sufficient. Create a dummy user and a dummy group with UID and GID one lower and the Scalix installer will generate user and group scalix with the correct UID and GID.
2b. When everything is installed and running, disconnect the machine from the network and set IP number and hostname to those of the production mailserver.
3. Install Scalix 11.3. No problems arose here, no error messages in the logfile. Stop all Scalix services after the installation.
4. Unpack the tar-archive of the mailstore; be careful not to overwrite /var/opt/scalix/sx.
5. Delete /var/opt/scalix/s; from the original mailstore, copy the subdirectories s and indexes to /var/opt/scalix/sx.
6. Start scalix-postgres, scalix-tomcat, scalix. Tests using the Firefox browser show that the administrative console, webmail, mobile access and api/dav work as expected. I noticed that omscan.server and omctmon are active for quite some time. I waited tor those processes to finish before upgrading to Scalix 11.4
7. Start the Scalix 11.4 installer. It issues a warning that the server is running. Should one stop the server first? The documentation and installation instructions contains a lot of irrelevant verbiage, but nothing on this point. As it turns out later, the installer is capable of stopping the services.
7a. A warning is written in the logfile: the installer cannot tidy up the message store, so one should consult the installation guide about running omtidyallu. Not unexpectedly, the installation guide contains no information at all. Could this be a leftover message from udates of very old Scalix versions?
8. Very important: before doing any tests, empty the browser cache.
9. Again, test with Firefox: Administrative console, webmail, mobile client and api/dav all work fine. This time, SWA is much faster that with 11.3.


Some additional comments:

Which packages are needed to run Scalix? This is very poorly documented, in the form of a confusing inaccurate generic one-size-fits-all overview of which "packages" are needed. Many of these packages don't exist as such, others are part of the default installation set or included in other packages. A professional documentation should contain, for each OS, a list of the required packages, using the OS-specific names, and indicate which ones are not part of the default installation set.

The few required 32-bit packages mean another 4 GB download. Isn't it getting time to provide a true 64-bit version of Scalix, given that this architecture is around for a couple of years now?

Why install 11.3 and then upgrade? I had of course tried 11.4 first, hoping to save time. Instead, I had a chance to explore many ways that don't work. Getting the message store to work with 11.4 didn't work (see above). I was very surprised, however, to see in the installation logfile that the postgres database could not be initialized. And indeed, even though the installer claimed to have finished successfully, I could not start Scalix. Fortunately, a reboot miraculously solved this problem, but ones confidence does suffer from such an experience.

Some tasks that should be performed by the installer:
1. Enabling Submit and/or LMTP
2. setting up SSL for apache2. Secure access should be standard, not a hacker-option!
3. setting up stunnel for POP3, IMAP, SUBMIT, etc.

That is my contribution so far. As stated above, I hope to see comments, additions, and improvements.

Best wishes,

Nico

nvehommes wrote:1. webmail is extremely slow; loading a mailbox, calendars, the options dialog, the rules editor, whatever I tried takes forever.
2. mobile access reports the dreaded "error A00000", even though the IP number and hostname are correct. (This is on an isolated system, with local DNS server.)

sounds like either imap cache needs resetting or indexes are being generated post upgrade causing slowness. This is to be expected, especially if you dump indexes and start afresh. There are settings in general.cfg to control the CPU load during this period.

nvehommes wrote:7. Start the Scalix 11.4 installer. It issues a warning that the server is running. Should one stop the server first? The documentation and installation instructions contains a lot of irrelevant verbiage, but nothing on this point. As it turns out later, the installer is capable of stopping the services.

Goes without saying that if you were upgrading the mail server it should be stopped before proceeding. You should also block mail coming in until you've tested post the upgrade to ensure all is working.

nvehommes wrote:7a. A warning is written in the logfile: the installer cannot tidy up the message store, so one should consult the installation guide about running omtidyallu. Not unexpectedly, the installation guide contains no information at all. Could this be a leftover message from udates of very old Scalix versions?

i dont think omtidyallu is absolutely necessary unless you want to rebuild imap cache for all users. I've never had to do it.

One thing you should do before the upgrade, especially if you've migrated to another server - run an omscan to verify your message store is in good condition. If it isn't then you're simply upgrading a problem.

nvehommes wrote:Which packages are needed to run Scalix? This is very poorly documented, in the form of a confusing inaccurate generic one-size-fits-all overview of which "packages" are needed. Many of these packages don't exist as such, others are part of the default installation set or included in other packages. A professional documentation should contain, for each OS, a list of the required packages, using the OS-specific names, and indicate which ones are not part of the default installation set.

Yes, perhaps this should be documented better. However when i've noticed missing rpm's the installer has told me which ones were needed.

nvehommes wrote:The few required 32-bit packages mean another 4 GB download. Isn't it getting time to provide a true 64-bit version of Scalix, given that this architecture is around for a couple of years now?

Someone can correct me if i'm wrong, but in some cases it may not be Scalix's fault that 32 bit packages are required on a 64 bit system. It could be that the maintainers of those packages have not written 64bit code yet, hence forcing everyone to use 32bit code.

4gb download???? for a few rpms???? surely not.....

p.s. So you're now on 64bit? Did you migrate from 32bit to 64bit? That could have caused you some grief.

nvehommes wrote:Why install 11.3 and then upgrade? I had of course tried 11.4 first, hoping to save time. :) Instead, I had a chance to explore many ways that don't work. Getting the message store to work with 11.4 didn't work (see above). I was very surprised, however, to see in the installation logfile that the postgres database could not be initialized. And indeed, even though the installer claimed to have finished successfully, I could not start Scalix. Fortunately, a reboot miraculously solved this problem, but ones confidence does suffer from such an experience.

[/quote]

Surprised you couldn't get anything to work in 11.4. If you ran ompatchom that would have upgraded your mailstore. Could the problem also be related to a switch from 32bit to 64bit?

Postgres may not have upgraded because of a major version change as i alluded to. Thats why i mentioned resetting postgres so that it started from scratch.

Hard to say what may have required a restart of the server without seeing what was going on at the time. Log files (fatal) should have painted a picture as to what was wrong and why scalix wouldn't start. Maybe scalix and its associated services never got stopped properly by the installer and this was only cleared up after a restart?

The process i outlined worked on rhel based systems, maybe some differences for SLES, wouldn't have expected too much difference there though.

Hello Les (and all others, of course)

Thanks for your comments. A few additions from my side:

Both the server machine and the test machine are 64-bit systems. There was no change from 32-bit to 64-bit involved. Probably a good thing.

The 4 GB download is the 32-bit DVD image. I found no repository with single packages on the Novell download site. The required 32-bit packages (cyrus-sasl stuff) all do exist as 64-bit versions, but unlike some others, no 32bitt compatibility version is available.
To me, it looks like a real requirement of 32-bit versions by some Scalix components.

les wrote:Yes, perhaps this should be documented better. However when i've noticed missing rpm's the installer has told me which ones were needed.

I didn't check all possible permutations, but I've noticed too often (with other programs) that packages require a specific file, usually some library version, instead of the RPM that contains the file. Simple lists with, for each supported OS, the required packages as they are called in the distribution would be a significant improvement.
As an example: SLES10 does not have packages called heimdal-lib or ps (these are required explicitly for SUSE); mx, pgdg, and sendmail-cf also don't exist, they are probably included in other packages.

les wrote:Goes without saying that if you were upgrading the mail server it should be stopped before proceeding. You should also block mail coming in until you've tested post the upgrade to ensure all is working.

That is correct. However, the user interface is poor. The installer issues a warning for something that has no consequences, because the installer itself handles it correctly. Apart from that, it is not too uncommon that an installer gathers data from running services when preparing an update.

les wrote:One thing you should do before the upgrade, especially if you've migrated to another server - run an omscan to verify your message store is in good condition. If it isn't then you're simply upgrading a problem.

This appears to be done automatically: omscan ran for several minutes. No errors or warnings were reported (assuming omshowlog would display them)

les wrote:Postgres may not have upgraded because of a major version change as i alluded to. Thats why i mentioned resetting postgres so that it started from scratch.

Right (even though a change from 8.2 back to 8.1 would be a minor change everywhere else).
However, the problem with postgres not being initialized occurred before anything was migrated: a fresh installation of SLES10 SP2, followed by a fresh installation of Scalix 11.4 for SLES10. I could reproduce this, it might be a problem in the installer. Perhaps someone else can try this (clean install of SLES10 SP2, then Scalix 11.4) and report the result.
After a reboot, things appeared to be OK. No problem when installing 11.3 or with the upgrade from 11.3 to 11.4.

les wrote:Surprised you couldn't get anything to work in 11.4. If you ran ompatchom that would have upgraded your mailstore.
[...]
The process i outlined worked on rhel based systems, maybe some differences for SLES, wouldn't have expected too much difference there though.

Yes, I did run ompatchom, which took quite some time to finish. All scalix processes were stopped.
Your procedure did work, but in my case it resulted in a very slow system. Things didn't improve after the system had run for an hour, no update processes were active anymore. It did surprise me too.

nvehommes wrote:As an example: SLES10 does not have packages called heimdal-lib or ps (these are required explicitly for SUSE); mx, pgdg, and sendmail-cf also don't exist, they are probably included in other packages.

Seems as though SLES is not as clear cut with its dependencies as with RHEL. Then i don't know SLES so i may not have all the knowledge necessary to make that call ;)

Nonetheless you are right, a general list of dependencies per distro should be available. It actually should be part of the installer, seeing as how each package is specific to a release, one of the first screens which simply states what non-scalix packages are required to run scalix. It could even do a check to see if they are installed.

I had a similar issue on a brand new 11.4 CentOS 5 install where i needed cyrus-sasl-md5. The installer correctly identified that as the rpm though.

That should be a feature request on the feedback forum.

nvehommes wrote:This appears to be done automatically: omscan ran for several minutes. No errors or warnings were reported (assuming omshowlog would display them)

I meant run omscan before you upgrade. The upgrade doesn't run omscan before it upgrades packages, and afterwards what you see running is not what i mean by a full omscan run in fix mode. And you want to be clean before upgrade.

To run a full fix mode omscan before upgrade.....

omscan -Aafvx

/opt/scalix/bin/sxmaint will do this for you regularly, check the scalix wiki for instructions.

nvehommes wrote:Yes, I did run ompatchom, which took quite some time to finish. All scalix processes were stopped.
Your procedure did work, but in my case it resulted in a very slow system. Things didn't improve after the system had run for an hour, no update processes were active anymore. It did surprise me too.

would have been nice to try and pinpoint exactly what was causing the slowness, but you've gone past that point now. I cant imagine it would have been anything permanent.

What you did with the 11.3 migration and then 11.4 upgrade is valid anyway. Plenty of ways to skin a cat ;)

les wrote:

nvehommes wrote:As an example: SLES10 does not have packages called heimdal-lib or ps (these are required explicitly for SUSE); mx, pgdg, and sendmail-cf also don't exist, they are probably included in other packages.

If heimdal stuff is still listed as a requirement for SLES10, please log a bug against documentation. Fortunately, in SLES10 Heimdal-Kerberos was replaced by MIT Kerberos (Heimdal sucks for ActiveDirectory interop, that's the reason why SSO doesn't work with Scalix and SLES9)..... so that one is correct.

Florian.

florian wrote:If heimdal stuff is still listed as a requirement for SLES10, please log a bug against documentation. Fortunately, in SLES10 Heimdal-Kerberos was replaced by MIT Kerberos (Heimdal sucks for ActiveDirectory interop, that's the reason why SSO doesn't work with Scalix and SLES9)..... so that one is correct.

Florian.

http://www.scalix.com/documents/Scalix_ ... de_113.pdf on page34. Nothing SLES10-specific, heimdal-lib listed as requirement.
Entered as https://bugzilla.scalix.com/show_bug.cgi?id=17428

Nico