Using Debian in Commercial Environments?
sydb asks: "I am currently persuading my employer to try out Linux. We are heavily dependent on IBM software technologies just now, and it's a very conservative operations organization. As a challenge, I am trying to persuade them to use my preferred distro but there are hurdles: IBM doesn't officially support Debian as a platform, though I have anecdotal evidence that most of it can be persuaded to work (with alien etc). Does Slashdot have experience shoe-horning Debian into this kind of scenario? Most importantly, how have things gone getting IBM support? My rationale for pushing Debian boils down to its vast array of packages available to apt-get, easy upgrades, apt-get itself, and the overall quality and consistency of the system."
Imagine if you tried to introduce them to Gentoo! They'd probably faint.
Despite the fact that my employer has a software environment that they are comfortable with, and that I have very little to gain and everything to lose, I have moved my software evangelism to the workplace. Can you help?
In general, you're buying IBM software because you can call them up, tell them "it don't work, nosirree" and your contract says they get to send out some engineer(s) and make it work.
If they support your environment.
The gains you might think you'll get by using Debian are absolutely not worth losing your service contract, which you've likely already paid for. There's nothing horribly wrong with SuSE or Redhat, both generally supported IBM environments. If you succeed in getting your boss to install Debian, you're on the process of going up a river without the proverbial paddle.
MORTAR COMBAT!
---- death to all fanatics
You want to put Debian on the systems because of the vast array of software available for it.
They want to run IBM solutions because they can trust that the few apps that they actually want to run on the system will run with no trouble.
The trouble here is that you want Debian on the systems for your own selfish reasons. They want to run their systems as reliably as possible. Since this is a business and not a college dorm room, the business case will always win out.
Debian is a fine distribution. But no company in their right mind would go through a migration just so you can install the latest and greatest software via apt-get. You see, they've already got the software they need running on the system.
I cannot speak about the IBM support, but I can speak about using a less main-stream Linux distro, such as Debian in a serious, commercial software development shop. What I found was that a lot of time was wasted on getting some of the more complex applications to work on it (e.g. Oracle 9i), while getting the same sw to run on something more 'standard', such as RedHat, was a bit easier. In fast-paced environments where every developer's day counts, this does matter. This experience is a bit over 1 year old, so maybe (hopefully!) things have changed since then.
Simpy
you focus on whats best for your company and ultimately your client by using the right tool for the right job instead of trying to hammer the proverbial square peg (Debian) into the round hole? Sorry to not really answer your question but hobbies and personal preference shouldnt take the place of a better solution (e.g. whatever distro of Linux IBM prefers for their hardware)
I went through this same discussion at my company, as Debian is my preferred distro as well. The thing is, beyond the distribution scheme, I really don't get to experience the true differences between the distros, as I'm usually running an unstable release anyways.
The link above also documents creating an apt RPM repository - we did this at my company, and to be honest, 99.9% of my gripes with RedHat went away completely.
I'd suggest looking into apt for RPM, it fixes a lot of the problems, and doesn't introduce those posed by a totally new distro on your production boxes.
Q: What do you think about American Culture?
A: I think it's a good idea.
(adapted from Gandhi)
Wouldn't that result in some kind of explosion?
I would say that what you want to to do is set up a technology demo. Put a server together doing a task using debian. The reasoning being that you have expertise in debian, so it reduces cost of the tech demo if you do and support what you know.
When it comes time to decide on an actual rollout they have to make a decision to go with a distro that they know is proven in their environment, or go with what IBM pitches.
But in either case, what you're doing is making the haters defend on two fronts: the vendors pushing for one linux and you pushing for another. With the debate being "which Linux" it stops being "why Linux". It's a win-win.
"Let him go, Ralph. He knows what he's doing." --Otto Mann (simpsons)
PS: No, I am not an HP employee.
Ok, I love Linux. I use it at work. I work in a really big, international company.
..
Here's my take .
If it's not supported/approved by IBM and you are dealing with IBM then find out what they support and use that.
Why?
Because 1) it's easier, and 2) you want to succeed.
Your job is not to move the organization. Your job is to make your boss look good. IBM is very very talented at making their customers look good at very reasonable prices. You will make your boss look better with IBM's willing help than by trying to fly it yourself.
Apt-get is nice and all, but frankly, support is nicer. If you don't understand that, btw, then you are not experienced enough to be making the decission on what to move forward with. I'm not saying this to be an ass . . . but simply because it's true. Moving them to Linux is smart, but moving them to something the hardware vendor doesn't support is stupid
Everybody get your fire-retardant suits on for the ensuing flamewar...
The core differences between distros are package management, the version of the kernel, and the version of libc. Debian might work fine for what you want it to do, but a subtle problem might occur that you didn't catch during testing, due to a version difference. I've found that shoehorning, as you mentioned, is generally a bad idea. Shoehorn too much, and your feet will hurt.
Given your conservative environment, I think RedHat's Enterprise Linux product line is more appropriate. RedHat can sell you a commercial support contract, and they promise software updates for 5 years. Also, future Linux admins are more likely to be familiar with RedHat, which avoids needing to learn Debian's quirks. Also, IBM or other commercial software (like Oracle) is more likely to be supported on RedHat.
We're running Debian on several xSeries systems. At first, we were having problems with server lockups. While it turned out to be a problem with the XFS file system, IBM supported us by swapping out just about the entire server.
They won't support the software, but they will support their hardware running it.
make a sandbox running Deb on your network to start showing them what it can do. this is what I did at my work, and it worked. Currently CVS and the Build machine are running my Linux distro of choice; Gentoo, for mainly the same reasons you mention.
RHCE's aren't going to do what we can do with *our* distro's, it's more than just LInux to us.
CB
free ipod and free gmail!
So, you need to ask these questions to yourself and your co-workers:
If you have a stable working enviroment, why change?
Is this move going to be cost effective?
Is the distro I use going to be the proper one?
Why am I really using this distro? If you say, because it is the one I use at home, then you need stop this project right in its tracks.
How easy is it to manage this distro in my enviroment. Running "apt-get upgrade" on 500 servers is not do-able.
Is there proper management software out there for my distro/platform of choice?
Does my software I need even run on my distro/platform of choice?
What about support for my software on my distro/platform of choice?
Can I keep my system software in sync across all servers?
Can I easily manage the distro install process?
Can I trim down the install time?
Can I make the install process automated?
These are just the basic questions you need ask. Don't get stuck on one distro. Be flexable and look around. Redhat or Gentoo or something might be better choices.
Linux O Muerte!
I used to work for IBM in the division that developed DB2 for Windows, OS/2, Linux, and various Unicies (but not OS/400 or other "big iron" systems) three years ago, and worked on code for DB2 v6 through to v8.
At that time, our Linux testing was primarily against Red Hat and a few others (from hazy memory, Turbo Linux, Red Flag, and one other I don't recall at the moment). Debian was not tested at all for any of their products. Red Hat was their primary focus, and seemed to be the Linux platform most of the developers ha on their desktop systems (although a lot of the Unix development was actually done through AIX-based systems).
Things may have changed since this time, but I haven't seen any outside evidence of this. Do you really want to try running these applications on platforms and with packages that the original vendor hasn't done any testing with? The IBM products you mention are not cheap -- why risk having them break by running them on an unsupported platform?
If you're a big account, talk to your IBM account rep and tell them you'd like to move to Debian. You'd be suprised how much IBM will do for a big account (or, at least, would do when I was there).
Yaz.
The fact that you're talking about "shoehorning" Debian in, using "anecdotal evidence that most of it can be persuaded to work" should answer your question.
This isn't a PHB issue, either. Anyone with a real production system should be scared off by language like that.
What do you mean by "doing everything the Debian way"? Are you saying Debian doesn't adhere to the FHS? Or are you just saying that -- while complying with standards relevant to a *nix -- it does things differently than RedHat or SuSe?
If you're simply saying that it does things differently from RedHat, then who says that the way RedHat does things is "the standard"? As for "special config tools", etc, why are Debian's config tools "special Debian config tools", and RedHat's config tools not "special RedHat config tools"?
It seems to me that your either saying that Debian doesn't adhere to standards (such as FHS), which would be a good criticism (even though sometimes standards are wrong), but in which case I'd want some examples; or you're saying that it doesn't do things the "RedHat" way, which is like complaining about it because all of its programs aren't in C:\Program Files.
PS: Personally, I use Gentoo.
social sciences can never use experience to verify their statemen
We have had a government contract that required Oracle 8i for odd reasons. Debian still has available the older libc versions needed for Oracle 8i. I don't if any current versions of RHEL or SLES support 8i, but I know Debian + the older 1.1.8 JDK allowed the Oracle installer to run and work with minimal shoe-horning.
The other Debian box we built for this application was for running Tomcat with the Sun JDK pushing a web-based reporting tool. We were able to demonstrate how Debian supported removing all unrelated packages (including compilers) and lowered the security profile lower than their Solaris boxes. (They still used telnet, God help them) The demonstration worked and the server is running Debian in production on the [redacted] government network.
Don't push it. We recommend Debian because of access to the build/distribution system and the ability to craft custom loads for specific purposes (point-of-sale, thin client, rich client, etc.). Controlling the build/distribution environment is a bigger issue than many people realize. But we really support anything because after a certain point, Linux is just Linux.
Comment on DebianPlanet about how we do it
We use it in our business and support it for our customers. No problems here! Go Debian!
My God! It's full of Voids!
I, too, am in a heavy IBM Websphere and DB2 environment and when we bought new hardware I looked into upgrading the distro from Red Hat 7.3.
First, the install on Debian isn't smooth. I tried the latest stable Debian as well as some updated packages that I knew I'd need. I installed Websphere and had some problems. Stuff worked, eventually, but it was a pain that I wasn't willing to deal with on an ongoing basis (fixpacks and such). Java GUIs were particularly troublesome, although the web console is really all you ever need. Java problems worried me a lot.
I tried Suse and Red Hat's enterprise offerings, which I had been given demo disks for, as well as their free counterparts. One major hurdle with Red Hat was that there are some major Java threading issues with RHEL 3.0 and Red Hat 9 and above, so I'd be stuck with RHEL 2.1 or RH 8. I decided to go with Suse 8.2, which is supported as a development platform (no free Linux is supported for production use).
What I found on my distro adventures is that IBM supports anything, but they do complain about it. For instance, even our old environment had RH 7.3 while only 7.2 is supported. During my Debian install it was IBM who helped me get it working. When supporting these distros they constantly question the Java version and go through a checklist of software versions to make sure everything's ok. But like I said, they will support it.
While I have gotten bad support from IBM before, overall they are much better than any other company I've had to deal with on an ongoing basis. They really do try to help out. A couple times I've had some idiot at their help desk so I asked to be transfered to someone else, but other than that they've been great.
The global economy is a great thing until you feel it locally.
You could not be more wrong. Production environments require stability, period - not the latest glitz. Most Sun shops are using Solaris 8 - it's ancient. Most windows shops are using Windows 2000. Conservative and stable is debian's strength. The reason Red Hat is such a mess is because they keep changing shit, and the wrong shit into the bargain. Worse yet, they put "enhancements" and bug fixes into up2date, which is in my opinion a big no no. I've had up2date break systems more often than update them. You point was?
Many of us inside IBM would like to see at least one free distribution supported. However, IBM won't support Debian unless there's customer demand. You're a customer, so demand it. Keep demanding it.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
It's truely free and fully open source, support is just about as good as Red Hat or Suse [again unless you're willing to paybig bucks], forward and backward releases are supported fully...no pressure to upgrade on a company's timetable, and software compatiblity is of the highest level... In a nutshell Debian IS Linux!
What's needed in the general OSS movement is to get more corperate interest in the grassroots OSS movements... Personally, I'm a Suse fan...because they have some great IBM hardware ports [like iSeries/AS400!] but realistically, distros like Gentoo and Debian are the future of software...companies like RH & Suse are attempts to strap "traditonal" lock-in software business to OSS/Linux... they are bound to fail...and leave you holding the bag. The beauty of Gentoo and Debian is that anybody can bolt anything they want on to the very stable bases...and when the base changes it's easy to work the changes into your custom software...they are DESIGNED to do just what most companies need!!!
As far as stability and compatibility, isn't it an open joke that the current version of Debian Stable is pushing 3 years old...I'd call that a pretty reliable standard base...better than ANY of the corperate Linuii.
They test new packages and software to death before including it into the official version. The current official version of Debian is Woody, and it uses version 2.2 the Linux kernel. I mean really, you don't get more conservative than that. There is something to be said for using older well tested software. Debian is such a solid founation, it is the basis for many other distributions such as Knoppix, Libranet, Xandros etc.
Comparing Debian to Mandrake, Suse, Slackware or even RHEL I think you will find that Debian it the most cautious about adopting new versions of core libraries, graphics system or the kernel.
I work in a Windows shop. Well, okay, we have a whole IBM AIX side of the company that runs the Peoplesoft stuff, but for all the rest of the company it's Windows. We tie peoplesoft and pretty much everything else you can think of into Active Directory. It works.
But there's places where I can see Linux boxes excelling where other software falls short. One of them is our Spam "solution." It was very expensive and it doesn't work for shit. 80% accuracy, maybe. Lots of false positives. In 2002, it was really cool shit. But that's the problem - things change fast when it comes to certain things like Spam and when you pay $50,000 for a license to filter spam you don't want to upgrade or change softwares every six months.
Enter OSS - My (*gasp*) spamassassin+dspam+amavisd-new is easily doing 99.99% of the spam with extremely low occurances of false positives. Is it supported? Nope. Wait, yes it is. I SUPPORT IT.
Some companies are all about support, support, support. They don't trust their IT staff, they consider them expendable. I don't work at a company like that. They put weight in our abilities. If you can make a good case for an OSS solution, one where you can support it yourself and train others, it will be seriously considered. Apparently there's other companies like this too, since a lot of places are running Linux now and not all of them use RedHat Enterprise.
- It's not the Macs I hate. It's Digg users. -
Um, no, Not even a little bit. It doesn't matter if you think Debian is the greatest thing in the world, or something you found at the bottom of your garbage can, there's one key difference.
Imagine some updated package broke all your applications. And your quarterly statements are due tomorrow. And the CEO is touring your server farm. And the planets are aligned infavorably. And it's Friday the 13th. Let me show two different scenarios:
And the alternative:
There is no sig, there is only Zuul.
I agree. Debian is wonderful, I use it at home, I use it at work. If your work is expecting to get Enterprise level support, you can get Enterprise level support for Debian with HP.
However, it sounds like your Enterprise has already standardized around IBM. As good as Debian is, I can't see how it's good enough to lose an enterprise support agreement, even if it's just a few machines.
Maybe you can threaten the sales people to go to HP if they don't amend the support contract to include Debian. They probably will know you're bluffing, but it might help.
----
Open mind, insert foot.
Either you live in some alternate universe in which vendors work on bugs for individual users, or you've been smoking some exceptionally strong weed. Or, possibly, you don't have a clue.
I don't believe in alternate universes.
Or...
Employee: Um, look harder please, remember we're paying you all this money for [Operating System]
[Any Vendor At All]: Ah, ok, I think we've found the problem. You're running software we don't support. Now go fix it yourself and stop bothering me.
How about this instead?
CEO: What's going on here?
Employee: I unwisely installed a new package on our production server without testing it first. I'm just in the process of removing it and going back to the old version. Everything should be back up by the end of our maintenance window.
CEO: Good. Let me know how it turns out and why this won't happen again.
Paying a lot of money for a support contract is no excuse for being careless. If your server absolutely has to be running tomorrow, then keep it running. I don't care if you use a cold spare, restore from a backup or try to fix it yourself, but I do know that if I told my boss that I couldn't be bothered to find a solution and was sitting in my butt waiting for a vendor to fix it for me instead, I would soon be out of a job. And I would have earned it.
Being a sysadmin means you always have a backup plan. Having someone to point your finger at does _not_ constitute a plan.