What not to do when trying to get Linux into your server room.
Let's face it: you can't make use of Linux Server Hacks (Volume One or Two) unless you have a Linux server to hack! I have learned from mistakes made by both myself and others that common community ideals are meaningless in a corporate boardroom, and that they can be placed in a more tiefriendly context when presented to decision-makers. If you use Linux at home and are itching to get it into your machine room, here are some common mistakes to avoid in navigating the political side of Linux adoption in your environment.
If you approach the powers that be and lead with a line about how Linux is free (as in beer), you're likely doing yourself a disservice, for multiple reasons. First, if you point an IT manager at the Debian web site (home of what's arguably the only "totally free in all ways" Linux distribution) and tell him to click around because this will be his new server operating system, he's going to ask you where the support link is. When you show him an online forum, he's going to think you are completely out in left field.
Linux IRC channels, mailing lists, and forums have given me better support for all technology, commercial or not, than the vendors themselves. However, without spending money on vendor support, your IT manager will likely feel that your company has no leverage with the vendor and no contractual support commitment from anyone. There is no accountability, no feel-good engineer in vendor swag to help with migrations, and no "throat to choke" if something goes wrong.
To be fair, you can't blame him much for thinking this—he's just trying to keep his job. What do you think would happen if some catastrophic incident occurred and he was called into a meeting with all the top brass and, when commanded to report status, he said "I've posted the problem to the linuxgoofball.org forums, so I'll keep checking back there. In the meantime, I've also sent email to a mailing list that one of the geeks in back said was pretty good for support…"? He'd be fired immediately!
IT departments are willing to spend money for software that can get the job done. They are also willing to spend money for branded, certified vendor support. This is not wasted money. To the extent that a platform is only one part of a larger technology deployment, the money spent on the software and on support is their investment in the success of that deployment. If it costs less for the right reasons (fewer man hours required to maintain, greater efficiency), that's great. But "free" is not necessary, expected, or even necessarily good.
It is also not Linux's greatest strength, so leading with "no money down" is also doing an injustice to the people who create and maintain it. The cost of Linux did many things that helped it get where it is today, not the least of which was to lower the barrier of entry for new users to learn how to use a Unix-like environment. It also lowered the barrier of entry for developers, who were able to grow the technological foundation of Linux and port already trusted applications such as Sendmail and Apache to the platform, making it a viable platform that companies were willing to adopt in some small way. Leading with the monetary argument implies that that's the best thing about Linux, throwing all of its other strengths out the window.
It's useless (at best) to talk about running Linux in your shop without talking about it in the context of a solution that, when compared to the current solution, would be more useful or efficient.
To get Linux accepted as a viable platform, you have to start somewhere. It could be a new technology deployment, or it could be a replacement for an existing service. To understand the best way to get Linux in the door, it's important to understand all of the aspects of your environment. Just because you know that management is highly displeased with the current office-wide instant messaging solution doesn't mean that Jabber is definitely the solution for them. Whining to your boss that you should just move to Jabber and everything would be great isn't going to get you anywhere, because you've offered no facts about Jabber that make your boss consider it an idea with any merit whatsoever. It also paints you in a bad light, because making blanket statements like that implies that you think you know all there is to know about an office-wide IM solution.
Are you ready for the tough questions? Have you even thought about what they might be? Do you know the details of the current solution? Do you know what might be involved in migrating to another solution? Any other solution? Do you know enough about Jabber to take the reins or are you going to be sitting at a console with a Jabber book open to Section 1.3 when your boss walks in to see how your big, high-profile, all-users-affected project is going?
"Linux is better" isn't a credible statement. "A Linux file-sharing solution can work better at the department level because it can serve all of the platforms we support" is better. But what you want to aim for is something like "I've seen deployments of this service on the Linux platform serve 1,500 users on 3 client platforms with relatively low administrative overhead, whereas we now serve 300 clients on only 1 platform, and we have to reboot twice a week. Mean-while, we have to maintain a completely separate server to provide the same services to other client platforms." The first part of this statement is something you might hear in a newbie Linux forum. The last part inspires confidence and hits on something that IT managers care about—server consolidation.
When talking to decision makers about Linux as a new technology or replacement service, it's important to understand where they perceive value in their current solution. If they deployed the current IM solution because it was inexpensive to get a site license and it worked with existing client software without crazy routing and firewall changes, be ready. Can existing client software at your site talk to a Jabber server? Is there infrastructure in place to push out software to all of your clients?
It's really simple to say that Linux rocks. It's considerably more difficult to stand it next to an existing solution and justify the migration cost to a manager whose concerns are cost recovery, ROI, FTEs, and man-hours.
Linux is well suited to performing an enormous variety of tasks that are currently performed using lower-quality, higher-cost, proprietary software packages (too many to name—see the rest of this book for hints). There's no reason to pitch it for tasks it can't handle, as this will only leave a bad taste in the mouths of those whose first taste of Linux is a complete and utter failure.
What Linux is suitable for is 100% site-dependent. If you have a large staff of mobile, non-technical salespeople with laptops who use VPN connections from wireless hotspot sites around the globe, and you have a few old ladies manning the phones in the office all day, the desktop might not be the place for Linux to shine.
On the other hand, if you have an operator on a switchboard built in the 1920s, and the lifeblood of the business is phone communication, a Linux-based Asterisk PBX solution might be useful and much appreciated!
The point is, choose your battles. Even in Unix environments, there will be resistance to Linux, because some brands of Unix have been doing jobs for decades that some cowboy now wants Linux to perform. In some cases, there is absolutely no reason to switch.
Sybase databases have run really well on Sun servers for decades. Sybase released a usable version of their flagship product for Linux only about a year ago. This is not an area you want to approach for a migration (new deployments may or may not be another story). On the other hand, some features of the Linux syslog daemon might make it a little nicer than Solaris as a central log host. Some software projects readily tell you that they build, develop, and test on Linux. Linux is the reference Unix implementation in some shops, so use that leverage to help justify a move in that direction. Do your homework and pick your battles!
Personally, I'd rather have a deployment be nearly flawless than have it done yesterday. Both would be wonderful, but if history is any indication, that's asking too much.
Don't bite off more than you can chew. Let Linux grow on your clients, your boss, and your users. Get a mail server up and running. Get SpamAssassin, procmail, and a webmail portal set up on an Apache server. Then maintain it, optimize it, and secure it. If you do all this, Linux will build its own track record in your environment. Create a mailing list server. Build an LDAP-based white pages directory that users can point their email applications at to get user information. If you play your cards right, a year from now people will begin to realize that relatively few resources have been devoted to running these services, and that, generally, they "just work." When they're ready to move on to larger things, whom do you think they'll turn to? The guy who wanted to replace an old lady's typewriter with a dual-headed Linux desktop?
Think again. They'll be calling you.
Get Linux Server Hacks, Volume Two now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
