Slashdot Mirror
How Hard is it to Manage Different Unices?
vrmlguy asks: "Where I work has several Unix-based servers, all running the same vendor's OS. We are getting ready to buy another big server, and management wants to get bids from other vendors. However, our staff is only familar with our current vendor's OS. Yes, I know that any two flavors of Unix are more alike than not, and yes, I know about the Rosetta Stone for Unix that makes it easy to transfer skills. I want to know about the down-side: What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?"
You have a team of mechanics, and for the last 20 years all they have serviced, as well as driven themselves are Ford automobiles. Now, your boss tells them to jump right in and service Chevrolet autos too. How easy will this change be? Depends on the mechanics and how they've been trained I suppose.
It has always been my opinion that if you have people who understand the concepts and underpinnings of how *nix systems work, the flavor of the OS doesn't matter. People who have a good understanding from an abstract point of view will easily pick the differences in syntax, location, etc.
"I'm just here to regulate funkiness."
What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?
$32,593.12
Now can we stop with these stupid, inane questions? I would rather read Jon Katz than these awful Ask Slashdot questions of the past 3 months or so.
Your biggest expense is going to be training, but your company will probably choose to take it out of your clients' and employees' pockets by doing it "on-the-job". Next up would be licensing fees.
Unless Vendor B is offering a competitive upgrade from Vendor A's software, it would be much cheaper to negotiate an additional Server and Client license pack from your existing vendor than to enter into a new business relationship with some new vendor. Unless, of course, the new "vendor" is (sigh) Linux.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
Not a flippant post.
The quality of Unix sysadmins has declined so much over the past decade that what passes for a sysadmin right now is what I used to call "an operator".
We have 5 unix sysadmins (major transportation company). Not one of them could write a shell script if their life depended on it.
They insist on doing everything by hand and then complain there are no automated tools to them. Their definition of an automated tool really means "graphical front end to those grubby text commands".
They have no appreciation for the modularity of unix, and they look longingly at Windows servers.
Meanwhile, they're all getting paid twice what they're worth because apparently as dumb as the Unix sysadmins are, the NT ones are apparently on a different evolutionary scale where "rock" is considered the most intelligent life form.
So my point is that getting these sysadmins to switch won't happen. They'll piss, bitch and moan about the opportunity to learn something to enhance their skills, then complain the application is screwing up "their" servers.
If only ASPs would take off, my life would be much better, because sysadmin skills suck so bad, black holes pale in comparision to the event horizon of these so-called admins.
So, is it just me or does it bother you that the "Rosetta Stone" states "This custom drawing feature requires IE 5"?
ALL HAIL BRAK!!!
The same principle applies to natural and computer languages - the more you know, the better you understand the fundamentals.
:)
Sure, you might know how to do x,y,and z on your Solaris box, but once you understand how to do it also on RedHat and AIX, you'll understand much better how it works conceptually. Then when you get an HP box, it'll be pretty easy.
Of course, don't run killall on HP.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Generally, this is not difficult to do, as long as your admins understand the bases of UNIX. (Vendor-centric admins sometimes don't, as they get dependent on their vendor's tools.)
The problems can arise with:
1. vendor-centric admins who aren't willing to learn
2. different service contracts creating differing expectations of uptime between systems
3. added costs from maintaining multiple service contracts and training on multiple platforms
4. finger-pointing, if the systems interact
5. rewriting in-house tools which are needed on the new platform, but were not written generically before
6. 3rd party licensing costs may differ (if you are licensing the same product on both OSs)
7. dilution of expertise, since your admins will have to be more generalists (this is often overbalanced by the expansion of perspective in problem-solving that comes from broader experience)
Other than that, I can't think of anything off the top of my head which would make this hard. Generally, it is not a problem to do.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
I'm going to try and not sound like a troll here. But this Ask Slashdot question seems complete rubbish.
Coukd the Slashdot folks be a little more discriminating in their choice of questions, please? The most entertaining/thought-provoking parts of this story, seem to be the idiot troll posts. This is hardly a thought-provoking or difficult question to answer/figure out with the most miniscule of job skill.
To answer this silly question:
The difference is: a lot, due to training/familiarization, support contracts, possible hardware differences, etc. DUH.
What's the difference in the cost of operations between a mono-culture and a shop running two or more vendors' OSs?
How much of a raise are you asking for?
-... ---
Sure, an environment with only one vendor's OS deployed is easier for the admins to handle. However, if a problem develops, that problem will affect EVERY SINGLE MACHINE you have. Don't lose sight of that in your zeal to minimize the admins' workloads.
Learn to spell: nickel, missile, lose, solely, amendment, speech, kernel, probably, ridiculous, deity, hierarchy, versus
Are what's going to kill you. Having to support software and software interoperability between different platforms can be a serious pain. A mono-culture is easier when dealing with software. However if you are presented with a significant enough savings from another platform, consider it.
Your admins, if they're any good, should be able to adapt to a different UNIX easily. Yes there are differences, but not ones that should trouble an experienced admin any longer then it takes him to read a couple man pages.
Statement of Bias: I "administer" several UNIX OS versions (Solaris, IRIX, Linux, occasional HP-UX), but in an isolated network with no outside connections (so very little emphasis on security).
Two factors come to mind:
No matter how close the systems are, you will still "loose" time to training (either formal or OJT) requirements for the new system. This may actually be a benefit for your staff (wider perspective, more to put on Resume).
Depending on how much focus is placed on security, you may end up doubling the time required to track vulnerabilities and install patches. Again, this may be an advantage as well since a single-os shop tends to have equal vulnerabilities on all systems. In a multi-os shop an attacker will have to work harder to get control of everything.
It is easist to manage servers from only one vender. Unix makes ti easy to transfer skills, but here is the contradiction: It is easier to manage servers from many different venders and versions, than to manage just one server that is different from the rest.
When you have all OSes the same it is easy because everything automaticly transfers. When all are different it is harder because you always have to remember the correct incarnation of each procedure, but because they are all different you get in the habbit of looking it up each time. When all are the same except for one machine you forget on that one machine that everything is different and you aply the wrong incarnation (ofte with disasterious results, see discussions of killall linux vs hpux on comp.risks) Because of this, the one different machine will get [invalid] complaints often due to these differences.
If you can't stick with one vender, then you should go with many so you are in the habbit of checking the differences. At the very least get some linux (debian, redhat, suse), and bsd (free, open, net) machines in house now, and use them for production. You need to make sure that your admins are used to subtile differences. The other alternative is to just stick with one vender, but not only do you pay more, but your admins become lower quality as they learn only one system. (think of it is a resume builder, you want different systems on your resume!)
It seems to me that the biggest cost is in sysadmin time. I figure it this way, at work I use a few UNIX systems. We have one machine running IRIX, a couple running BSD and one running Linux. Now, when I write a script one one of the BSD machines, it works on all of them, but it may or may not work on the Linux machine, and certainly won't work on the System V-esque IRIX machine.
Now, if your sysadmins employ a lot of scripts, figure you'll have to spend twice the time maintaining them if you have two different platforms that are not fully compatible. You can minimize this if you stick to POSIXly correct scripting, but you'll never completely eliminate it.
The same goes for custom programming. For instance, if you're running everything on BSD, and you want to take on a Sun machine running solaris, there may be some issues with the occasional socket call that Sun implments differently from the rest of the world.
So, the more custom scripting/custom apps you have, the more time your sysadmins will have to spend maintaining/porting/testing the stuff.
---
Play Six Pack Man. I
From personal experience, I found that backup and recovery can be quite different depending on the flavours involved. For example, I back up my AIX systems with /usr/bin/mksysb, ftp the file to a system that is connected to a tape library and copy the image to a 4mm tape. I can do a bare-metal recovery from that tape to any equivalent or better RS/6000 in about an hour or so and have an exact clone of the original system as of the date the backup was taken. In this regard, AIX rocks.
/usr/sbin/ufsdump, but restoring a system from tape is more involved, and I cannot restore that tape on a different class of Sun hardware.
My Solaris backup and recovery strategy is not as elegant in that I make backup tapes via
I do not expect both to work identically, but there are some significant differences between the two.
*** Where are we going? And what's with this handbasket?
The short term costs to retrain staff for the new system will be higher but the long term benefits will definitely outweigh them. Once you build a multi-OS capable IT department the cost to add new hardware later on becomes significantly less. By not being locked into one OS (and one vendor) you have the freedom and flexibility to choose the best solutions for future problems (as well as hunt for the lowest cost). The smart thing to do is diversify your IT shop as much as possible so that you can insure you always have the right tool for the right job. No single vendor or OS can provide all the answers, regardless of what IBM/Sun/Microsoft may try to tell you.
A more serious answer.
You have a skewed view of the UNIX admin world. In my workplace (small investment firm), we have 6 UNIX admins who jump at the chance to learn something new. They'll dive into Linux, then realize OpenBSD is better for their task because of its security and inhale the documentation, all while keeping a fleet of Solaris servers running for production work.
If one of them does not know how to program, he picks up a book and starts writing python in a couple of days.
It sounds like you and I are at the extreme ends of the UNIX admin experience, because my situation sounds so opposite to yours.
To the original poster: what kind of workplace is yours? If your UNIX people jump at new stuff, they'll soon figure out if the new system can be successfully integrated and how long it will take.
Just keep text-file logbooks as you learn new things about the different UNIX implementation. Keep them in a hierarchical database on an NFS file system or web server somewhere, name the directories and files consistently by OS and topic (topics such as DNS, network booting, firmware, SCSI naming conventions, package management, etc.).
I do this at home to juggle Solaris, OpenBSD, and Linux and it works well. If I forget how to setup DNS under Solaris, I just go to <base_dir>/Solaris/8/DNS_Setup.txt, for example.
Also, install all of the on-line documentation you can and have it network-accessible. For example, when the man pages aren't detailed enough, on-line Solaris Answerbooks can save the day.
Also, keep well-organized bookmark lists for useful websites, such as http://docs.sun.com or http://sunsolve.sun.com, that cover your particular UNIX.
Having any number of UNIX implementations really isn't unmanagable (unless they have broken network protocol implementations). The key to success is documentation and more documentation (and unambiguously sharp sysadmins). On that note, if you don't have faith in your system and network administrators, you should just give up and stick with one OS, since no amount of documentation helps a truly stupid human.
Healthcare article at Kuro5hin
Money.
You obviously already know that managing support contracts from multiple vendors is going to suck. I would also recommend taking a long hard look at ongoing support charges.
For example, we have both HP/UX and Sun platforms where I work. We have both servers and workstations. For the workstation support contracts on similarly sized machines, there was a world of difference in cost.
The annual fee for an HP C240 workstation was somewhere between $2500 and $3000. The same annual charge for a Sun Ultra of equal speed, was between $1000 and $1500. Multiply that by the number of workstaions you have to maintain, and it can add up very quickly.
The up front cost typically isn't where they get you. It's on the back end. I would research the back end on all of the platforms you are considering very carefully before making any final decisions.
Hope that helps a little.
For example, on Solaris (without Veritas Volume Manager), you have to "carve out" your disk filesystem by filesystem, and work with devices in /dev/dsk/cAtBdCsD format. On AIX, the concept is totally different with Logical Volume Manager, wherein filesystems can be created on the fly. But HP-UX uses both in an odd fashion, forsaking slices and using a "castrated" form of LVM. This is just one example, as you will find other things in HP-UX such as the useradd command being identical to Linux and Solaris, and the SAM tool being very close to AIX's SMIT utility.
In the end, as you will find, there is no uber-Unix that will carry over to all of the other flavors. IMHO, HP-UX is as close as you will get. But, my personal preference of all Unices is AIX due to its ease of use (an IBM tool easy to use? I know it sounds like an oxymoron) and robust capabilities, combined with Linux integration in the most recent versions. Flame as you will, I'm interested in hearing anybody else's insight.
--Chag
Most companies I have worked at or know people at go with a third party backup solution such as the ones from Tivoli or Veritas.
Makes your backup/recovery fairly consistent across different products, plus everything can then be managed from a central console.
"What kind of unixes do you run?"
"Oh, we have both kinds. RedHat and Debian.
The reason homogenous environments are easier to manage than heterogenous environments is due to complexity.
Simply put, if every server and workstation is identical, interoperability is not an issue, and the work associated with tracking, testing, and applying changes to that one, homogenous OS image is minimal.
The moment you branch out into different configuations of the same OS version, different OS versions, or different OS platforms, you've increased the complexity of the system, and thus increased your workload. Suddenly, interoperability is a factor in every decision, and issues with multiple versions and/or vendors must be tracked.
I've been meaning to write a short paper on this for some time, and attempt to relate it to Christopher Langton's Lamba parameter for the measurement of complexity (in the 3rd Annual Proceedings of the Artificial Life Conference). I've studied the identification of single points of failure for some time, as well as the question of "how many sysadmins do I need?". Both answers are directly related to the complexity of the system being managed (here, defining "system" as the collection of applications, OSes, hardware, and networks that comprise the scope of a sysadmin's responsibility). There are indeed identifiable factors that define the heterogeneity of an environment, and the ways in which these dimensions impact such things as the number of SA's required to manage them can be defined.
.@.
1) You can install the same shell on just about all UNIX's. Most people where I am prefer tcsh as it has some nice features.
2) You can standardize on scripts, either use csh (blah) or sh. We prefer sh as it is found on just about EVERY unix (Sun, HP, AIX, BSD's, Linux).
3) Avoid vender extensions to the basic shell. HP has done some aweful things there in its bourne shell and they are not compatible with Sun and in some cases Linux either. I.E. Always use `cat foo` and not $(cat foo) in sh scripts. There are other things like that.
There are problems in supporting more than one UNIX, but there are also workarounds if you do it right.
Only 'flamers' flame!
Going from SuSE to LFS wasn't as bad as you might think. The main difference that I can recall is that the scripts that control various services live in /sbin/init.d on a SuSE box, but /etc/init.d on an LFS box.
The biggest difficulty is dealing with the automated config software that most distros use. I can usually set up most things on a SuSE box through YaST, but I haven't figured out whatever config utilities are used by the one Redh*t box at work that I haven't nuked yet. (Then again, I ran SuSE at home for a couple of years. I ran Slackware before that, and SLS before that. I've never installed Redh*t or had to deal with it prior to my current job.) I'd still rather tweak the different config files manually for the few apps that need adjustment, though; it's usually easier to dial in the exact setup you want that way. That's why most of the Linux machines I control run LFS now (the only exceptions are the aforementioned Redh*t box and an ancient 486 print server that was set up with Slackware because I didn't want to wait for that slug to build LFS).
20 January 2017: the End of an Error.
Knowing that (as an example) AIX has a pretty self tuning kernel, that Solaris has a modular kernel, and that UnixWare needs a recompile (relink) for any minor changes forces the admin to think about the operating system instead of just drooling on the keyboard.
The biggest differences are still SysV vs BSD. Understanding those is vital in a mixed OS environment. Beyond that, there are usually differences in disk layout (and filesystems), but they just add to the rich diversity that is my favourite OS.
At my work, we are big users of Solaris, but because we develop software for multiple platforms, I've also had exposure to AIX, UnixWare, Sequent Dynix/PTS, HP-UX and DRS/NX. These days we've dropped Dynix/PTS (EOL anyway I think), HP-UX (too expensive for our customers), and DRS/NX (dead?) but we're looking to port to OpenUnix 8 and Red Hat Linux, so things are still pretty mixed. I just think it's a shame that I don't get to work with HP-UX and that Unixware is dying (yes - I like it!).
We also port to NT/2000, which is good to compare - it's a nightmare to work with when used to UNIX.
As a senior systems engineer from a similar organization (Carrier1 (FALCO!)) I can say there were no issue running a multi unix environment, and I've never had any issue with it at any of my previous companies (nor have any of the engineers I've worked with).
:). I had Mac OS X, GNU/HURD, Debian and Solaris all on my desk at one point.
:)
At Carrier1 had FreeBSD, Red Hat & Debian Linux, Solaris 9 & 9, HP-UX, even GNU/Hurd and Mac OS X (well, on *my* system
The only problem I've ever had is the fairly trivial (?!) one of getting the command flags right - stuff like the 'ps','route','ipchains, 'ipfw' and 'ifconfig' commands syntax being different, the different flags for package management tools, that sort of thing.
I quickly came to realise that it's not possible to remember all the flags for all programs and remember the best way to do something on a particular system if you are busy all the time, things just seem to seep out. This happens if you are spending lots of time programming or in meetings or working on large projects - in which case you might not touch one type of system for months (until there is a problem with it), at which point you find your self quickly reading man pages and referring to Google a lot. All you need to do is remeber what's improrant, especially things you'll need for troubleshooting, and not worry about the rest - it's enough to know about tool's like Solaris 'ndd' and Linux's 'mknod' and what they do, if you need to remeber exactly how to use them in a given instance you can refer to man pages, O'Reilly Books or Google (which I often find the fastest).
Staying current, reading Freshmeat everyday, installing and configuring new Unixes and new & un-familer packages regularly, being on mailing lists and reading Slashdot are good ways to stay up to date - the more you know the less likely you are to run into something completely unexpected. If your resourceful (which you should be as a Systems Engineer) the only real problems arise went you don't even know where to start, everything else is a piece of cake.
Basically, if you really know unix (and are not just a Red Hat Linux or Solaris flunky who has convinced themselves they are Gurus while they still run Windows 2000 day to day) then you won't have any problems.
Oh, and making lame excuses like 'well I need Windows for work stuff' and 'they won't let me run Unix on my desktop' DO NOT wash - they are just that - excuses for lameness.
I have been for job interviews and been introduced to guys who called themselves (literally!) 'Unix Gods', yet they had only ever used Solaris - if you have any of those you are in deep shit right now. [ Needless to say I ran a mile! ]
Most people fall somewhere in the middle of those two, you'll probably only have one or two decent guys, if your lucky, though if you need to ask you are very possibly in trouble already!
YMMV.