Lately we are looking at groupware options, and have been looking at Scalix and Zimbra. We may need the features in the proprietary versions of these products, unfortunately.
So I downloaded an evaluation copy of Scalix.
They say they support RedHat and SuSE. Fine, I think, I’ll just alien the RPMs to debs and be happy.
Not so fast. They have a whole proprietary install system. They check for /etc/redhat_release or /etc/SuSE_release (or something like that) and do different things depending on what is there. Ugh. Why can’t these proprietary vendors just target LSB? The differences seem mostly related to init anyway.
So I touch /etc/SuSE_release into existence, run the installer again. It complains that DISPLAY is not set. UGH. I log in with ssh forwarding, to root (sigh), and run it again.
Now it complains that the SuSE_release file doesn’t contain a valid release. I google a bit, but the file format doesn’t seem to be documented anywhere. I extract it from an RPM somewhere, but no luck.
So, I figure at this point, let’s try an actual RPM distro. I’m running this in a Xen domain anyway, so it should be no big deal, right?
I think CentOS will be a good choice. It’s RHEL with the non-free stuff stripped out. And they support RHEL and don’t need any non-free stuff. I google, and find instructions for installing via rpmstrap for Xen uses.
Let me say, rpmstrap is not nearly the nice tool that cdebootstrap is. rpmstrap totally hosed the networking on the Xen host machine, requiring me to reboot to get it back to proper state. The resulting install wouldn’t boot, either — I later found out that, even though I listed explicit devices in /etc/fstab like usual, it requires labels on all my partitions to boot. Ugh. There are a host of other problems with the rpmstrap-installed chroot, and it’s broken beyond my ability to repair due to problems with the rpm database.
So then I downloaded the “Server” CD for CentOS, which is supposed to have just the stuff a person would need for a server, and leave off all the graphical tools, multimedia, etc. I fired up VMware and did an install. Then I booted Debian From Scratch in VMware and used tar and netcat to copy the installed image over to Xen.
I got it booting fairly easily. But now I start to remember why I had this instinctive gag reflex last time I used RHEL.
First off, the network configuration, by default, is tied to the MAC address of your ethernet card. So if you replace your Ethernet card, your network is broken by default.
Then, there’s the way the network is brought up. It uses arping as part of its procedure to bring up a NIC. If it sees a reply anywhere on the network with the IP you’re trying to assign, it leaves the NIC half-up — it’s been ifconfig’d up, but without an IP. So that’s right, if somebody happens to have a rogue device plugged in at the moment your server boots, your server will come up without a network configured. This is *Enterprise* Linux and it’s pulling this sort of thing. Terrible design.
Next, there’s the way the network is *configured*. There are commands such as system-config-network-tui, -gui, -cmd, -druid, etc. I go for -tui. to start with. It’s a dialog-like interface, and asks the basics like IP address, etc. It doesn’t have any way to configure more than one Ethernet card that I can tell. And some of the settings — like nameserver — apparently require you to press F12 to visit. But the program doesn’t recognize F12 as sent by an xterm, so it doesn’t work.
All the other options require X. So, I reluctantly ssh -X into it as root and run system-config-network-gui. It doesn’t work — complains it can’t find DISPLAY. Strange, I think; DISPLAY is set properly to localhost:whatever. It turns out that /etc/hosts is empty by default, so the thing can’t resolve localhost! Argh. I add a line to /etc/hosts and it fires up.
This tool works decently. I save, uncheck the tie to a MAC address box, and exit. I then think it might be good to fire it up again and see what it did. I try running it again, and get the same error about DISPLAY. The stupid tool blew away /etc/hosts and replaced it with an empty file! This is NOT what I would expect from an Enterprise Linux. You don’t blow away a config file the administrator touched without asking, EVER.
Next, I figure, let’s try installing the XFS tools so I can switch the root filesystem to xfs. I start with “yum update”, which doesn’t quite do what I expect. (It is more like apt-get update && apt-get -u dist-upgrade) So I hit Ctrl-C, but — surprise — IT DOESN’T WORK. I press it a few more times, and it seems to just make the downloader cycle through mirrors because of a “download error”. So I hit Ctrl-Z and kill %1. I have my prompt, but it’s STILL DOWNLOADING STUFF and spewing all over my console. Ugh.
I finally use ps and kill -9 and eventually get it killed off. Stupid thing.
I don’t understand why anybody would want to use RedHat Enterprise Linux in an enterprise. It seems more suited to a hobbyist system at home. From reading some forums, it seems there are quite a few people out there using Debian for enterprise systems for similar reasons.
So now, maybe I’ll have the chance to actually try Scalix.
(BTW, our intern got Zimbra installed on Debian just fine, so that’s a plus for it.)
I haven’t seen so many people using RHEL among the other IT workers I interacted with. Nearly all of them use whatever in their notebooks/desktop and whatever they were forced to run in the servers unless they had the choice and installed Debian (those that didn’t have the choice are always sad ;)
Hi John,
appreciate the feedback on your Scalix experience, let me add a couple of comments here and try to explain what’s going on….
The whole architecture of our current core product installation process has been designed about one of our most difficult yet very important target audiences – Windows admins. You seem like a Linux expert, but most people looking at Scalix just do their first steps in moving away from a pure Microsoft-based infrastructure, so they need some serious help. Give those guys a stack of RPMs and config files to edit, and you’ve lost them. To be very clear – I don’t think that’s something to critizise or judge upoin – it’s just a different set of previous experience that we’re looking it; once we’ve got them up and running, we’ll give them lots of good reasons to look at our command line interface for administration, especially when it comes to mass operations and automation and everybody appreciates that. After all, even Microsoft is adding more scripting with Exchange 12 next year.
So, bottom line here is, RPM just doesn’t do the trick because it’s not interactive enought; deb is better that way because there is a standard menu-driven dialog UI to it, but it’s hard to only support debian – I’ll say something later to the why. The installer also does some system checks for DNS configuration, network stuff and package dependencies – we’ve had too many people stumbling over those in the early days.
What I’m surprised to hear is your remark about the display variable; since Scalix 10.0, released last February, the installer should automatically run in text mode if the variable is not set. Can you please re-check? We thought of this as an important feature, in particular for remote installs. I was heavily behind that.
Should you still prefer debian for your evaluation, we also provide some help here – we’ve released Scalix Community Edition Raw in April, providing (a) .deb packages and (b) manual installation instructions throgh a Wiki. CE Raw can be found at http://www.scalix.com/ceraw. I’m the original author of the installation wiki, so any feedback here would be appreciated.
I don’t really want to go to deep on the Redhat vs. thing; being a 2 decade Unix guy myself, I like debian the best for it’s most logical and straightforward config file structure. RedHat comes in second while SuSE/Novell introduces the concept of “Meta config files” which totally confuse me. Anyway, none is perfect, I would probably say that I would currently prefer straight Solaris.
However, couple of good things RedHat has done… first, they’ve been most successful positioning themselves as “the company that provides Linux” and doing so big time – therefore helping our little penguin OS to take off in the enterprise. Appreciated. Next, most hardware vendors, especially the biggies, trust them and like working with them. Installing RHEL on typical HP, Dell or IBM server hardware is usually straightforward, including strange gigabit ethernet interfaces and funny raid controllers. Try to get debian up and running with fibrechannel and raid controllers on a IBM blade and you find yourself recompiling kernels and other stuff the usual system admin doesn’t want to do. And finally – you can still use their graphical tools and edit the respective config files directly and it will mostly work – try that on SuSE and you’re lost. So – while I don’t love the RedHat platform, I appreciate what they’ve done. The MAC-based ethernet adapter binding comes in handy, btw., when you have a server with more than 2 or 3 interfaces. and some hardware change – on some of the other Linuxes, interface naming in then hopelessly messed up while RedHat at least informs you that something substantial has changed in your sys-config…..
… whatever – hope you can try again and let me know how it goes!
Cheers,
Florian, Scalix.
Thanks for the comment, Florian. We did get the Small Business Edition evaluation installed under CentOS.
I had noticed the Community Edition Raw, which sounded perfect for us… Except we will be wanting some of the Small Business features like the Outlook connector and PDA syncing. I e-mailed your sales team, and talked to someone about it Friday, who indicated that we could still license those components if we’re doing a community edition install, which is great.
I am curious about one thing though: do you think you could still use your graphical installer but target the LSB instead of particular distros?
Hi John,
thanks and good that this got you going… CE Raw will not do 100% of what you want because currently we don’t really provide license keys other than community edition for it (that’s pretty much exactly the difference of ce raw – no full support options), but let’s see what we can do for you; your might also want to watch for some announcements from our side this week – around OSCON in Portland, I just arrived there – that could be interesting for you.
On the LSB thing – believe me, we’d love to as it would make our build process and testing SO much simpler. However, unfortunately the standard is still a little too weak for some practical purposes… one thing is the binary build itself, most of the stuff works across the board but we have seen some subtle differences (like the use of MIT vs. Heimdal Kerberos or exact versions of OpenLDAP or Cyrus SASL libraries) that have made us turn to a “build on platform” model to avoid _any_ incompatibilities with our supported platforms. Even worse, checking out the system configuration is very different between distros. You’ve probably named the most obvious example yourself – network configuration which is 3 worlds on SuSE, RedHat, debian. If that doesn’t fully convince you, check out Apache configuration on SuSE, including the fact that they provide multiple different binaries for Apache, compiled with support for multiple threading models (worker, etc.); so… as long as standardization does not become more common for those things as well, I don’t see a unified install happening. Unfortunately. Really.
BTW, abstracting here a bit – I think this very problem broke Unixes neck in favor of Windows on the desktop long time ago – surely the X-Window system was technically superior to the Window GUI, however this didn’t help anybody because end use just doesn’t want to have 7 Window Managers with thousands of configuration options that can be configured at system, user, session and probably process level. I remember a X-Window conference in Edinburgh more than 10 years ago where everybody seemed to be proud to have added the latest level of complexity. And even today, Linux folks can’t really decide between KDE and Gnome for what is really to be called The Linux Desktop.
What a pity. :-(
Typing this on my MacBookPro… the only …X with The Touch. .-)
— Florian.