|News||Sysadmin Horror Stories||Recommended Links||Creative uses of rm||Mistakes made because of the differences between various Unix/Linux flavors||Missing backup horror stories||Lack of testing complex, potentially destructive, commands before execution of production box||Pure stupidity|
|Locking yourself out||Premature or misguided optimization||Reboot Blunders||Performing the operation on a wrong server||Executing command in a wrong directory||Side effects of performing operations on home or application directories||Typos in the commands with disastrous consequences||Side effects of patching|
|Multiple sysadmin working on the same box||Side effects of patching of the customized server||Ownership changing blunders||Dot-star-errors and regular expressions blunders||Excessive zeal in improving security of the system||Unintended consequences of automatic system maintenance scripts||LVM mishaps||Abuse of privileges|
|Safe-rm||Workaholism and Burnout||Coping with the toxic stress in IT environment||The Unix Haterís Handbook||Tips||Horror stories History||Humor||Etc|
In most case differences between flavors of Unix are just annoying but in some case then can became source of serious errors
Linux killall command kill processes by name (killall httpd). On Solaris it kill all active processes. Here is example of an related blunder from email:
As the root user I killed all processes, and this was our main Oracle db box:
root user in linux is
in Solaris is
/. That means that
root ~/bin points to different directories in Solaris and Linux.
Imagine effect running rm ~/bin/* on Solaris.
Options of many commands are different or have different semantic.
Differences between flavors of Linux such as Red Hat and Suse can also also lead to unintended consequences. And some of them are really devious because the working assumption for syadmin is those two flavours of Linux are "almost identical". For example, if in one of those flavours a particular daemon is started via RC scripts and in other via xinetd. Often people even do not understand that different methods are deployed and start manually daemon which should be started via xinetd.
Also RHEL and SUSE has different security mechanisms in place. The SUSE administrative tools seem to be superior to RedHat (WebYast, Yast2), while authoyast is vastly inferiors to kickstart (and was way too buggy until SLES 12, when Yast was rewritten in Ruby).
But real fun starts when scripts designed and tested on one flavor of Linux or Unix are moved to the other. Here even innocent differences in location of files such as /var/log/messages on Suse and Red Hat vs /var/adm/messages on Solaris can led to interesting side effects. Another good example is that on HP-UX df command prodiuces completly different output then on all other flavors of Unix. You need to use bdf to get similar output.
Default locations of many classic Unix utilities differ and if script uses absolute path some commands might never be executed. Just because it works one flavor of *nix does not mean that it will work for another. That also means that you should never ever assume that some prepackaged script that you downloaded does anything right. Running such script without testing can be quite suicidal as they do not always check if particular cd operation is successful.
Sometimes scalability cause serious problem. It's one thing to run a particular script on the server with 10 users and the other with 10000 users:
...Management told us to email a security notice to every user on the our system (at that time, around 3000 users). A certain novice administrator on our system wanted to do it, so I instructed them to extract a list of users from /etc/passwd, write a simple shell loop to do the job, and throw it in the background.
Here's what they wrote (bourne shell)...for USER in `cat user.list`; do mail $USER <message.text & done
Have you ever seen a load average of over 300 ???
Note: You might be better off forgetting all this silly noise about compatibility and using bash. Bash is now standard de-facto and is available of almost all enterprise flavors of Unix and commercial Linuxes.
It is still not available on HP-UX 11 by default, but you can install it from a depo. Anyway even they provide bash with binaries available for all HP-UX versions. It is actually much easier to install bash on all systems that struggle with shell compatibility questions. Solaris, AIX and linuxes have bash installed out of the box and now bash in the natural least common denominator of shells. Moreover bash 3.xx is pretty close to ksh93 and if you tested you scripts with it, in most cases the script should work OK. That main difference is treatment of the last stage of pipeline, but now there is bash option via which you "enforce" ksh behaviour (which is actually the only rational behaviour ;-).
Originally sh was Born shell that has a separate implementation. Those days sh is often implemented as a special compilation of existing ksh version (or bash) and in most cases it does not make sense to use Born shell. You will be better off using bash
The second problem in writing portable script is that there are also many subtle differences in utilities provided and their location for various flavors of Unix. There are several ways to deal with this problem. One is to provide symbolic link to "most reasonable location", the second is to provide wrappers and the third that probably the most popular is to encode path and the name of the utility in shell variables.
Both the Bourne shell, and the Korn shell, can use the semicolon and the carriage return interchangeably in their syntax of the if, for, and while built-in commands. When using the brackets ([ ]) within if commands, you must separate both inside ends of the brackets from the inside characters with a space.
Shell Script Porting Guidelines
Here is a semi-useless table from the FAQ that compares shells. It is old and from purely academic point of view is incomplete as it does not include ksh93 which is in many respect the pinnacle of traditional Unix shells. But again you need to forget about academic discussion here: it is simpler to switch to bash then struggle with all this stupid complexity. Bash is not perfect but it works well enough to suit your needs. Sometime the best way to conquer obstacle is to go around it :-)
sh csh ksh bash tcsh zsh rc es Job control N Y Y Y Y Y N N Aliases N Y Y Y Y Y N N Shell functions Y(1) N Y Y N Y Y Y "Sensible" Input/Output redirection Y N Y Y N Y Y Y Directory stack N Y Y Y Y Y F F Command history N Y Y Y Y Y L L Command line editing N N Y Y Y Y L L Vi Command line editing N N Y Y Y(3) Y L L Emacs Command line editing N N Y Y Y Y L L Rebindable Command line editing N N N Y Y Y L L User name look up N Y Y Y Y Y L L Login/Logout watching N N N N Y Y F F Filename completion N Y(1) Y Y Y Y L L Username completion N Y(2) Y Y Y Y L L Hostname completion N Y(2) Y Y Y Y L L History completion N N N Y Y Y L L Fully programmable Completion N N N N Y Y N N Mh Mailbox completion N N N N(4) N(6) N(6) N N Co Processes N N Y N N Y N N Builtin artithmetic evaluation N Y Y Y Y Y N N Can follow symbolic links invisibly N N Y Y Y Y N N Periodic command execution N N N N Y Y N N Custom Prompt (easily) N N Y Y Y Y Y Y Sun Keyboard Hack N N N N N Y N N Spelling Correction N N N N Y Y N N Process Substitution N N N Y(2) N Y Y Y Underlying Syntax sh csh sh sh csh sh rc rc Freely Available N N N(5) Y Y Y Y Y Checks Mailbox N Y Y Y Y Y F F Tty Sanity Checking N N N N Y Y N N Can cope with large argument lists Y N Y Y Y Y Y Y Has non-interactive startup file N Y Y(7) Y(7) Y Y N N Has non-login startup file N Y Y(7) Y Y Y N N Can avoid user startup files N Y N Y N Y Y Y Can specify startup file N N Y Y N N N N Low level command redefinition N N N N N N N Y Has anonymous functions N N N N N N Y Y List Variables N Y Y N Y Y Y Y Full signal trap handling Y N Y Y N Y Y Y File no clobber ability N Y Y Y Y Y N F Local variables N N Y Y N Y Y Y Lexically scoped variables N N N N N N N Y Exceptions N N N N N N N Y Key to the table above. Y Feature can be done using this shell. N Feature is not present in the shell. F Feature can only be done by using the shells function mechanism. L The readline library must be linked into the shell to enable this Feature.
IDC interviewed 400 Unix/RISC customers about their attitudes to migration. The average interview time was 30 minutes. It makes very interesting reading. The report says Sun is the main target for migration and the clock is ticking. Here are some extracts...
"Sun Solaris continues to be the most popular Unix variant for Unix servers running Web infrastructure. While this is not surprising given the dot-com success that Sun enjoyed in the late 1990s and into 2000, it does continue to represent a challenge for Sun because these workloads have been frequent targets for migration over the past five years."
"IDC believes that the server life-cycle issues are driving much of this change, because the systems in the Unix installed base have aged in recent years, and this is compounded by the fact that many dot-com era installations with Web enablement of business workloads, are coming of age and will require replacement. In addition, many Unix/RISC servers were deployed in preparation for Y2K and many of these systems are now nearing the end of their useful life cycle." ...read the article (pdf), ...IDC profile, Solaris Migration Resources
18 November 2008 | ibm.com/developerworks
... ... ...
What you won't find with RHEL is an integrated GUI-like YaST2, from which you can launch any command that your heart desires. With Red Hat, you have GUIs, but you need to remember the names of the commands that launch them; there is not one command from which it all flows as there is with SLES. To add logical volumes, you'll use the system-config-lvm command. The first thing you'll need to do prior to setting up our volume group is initialize your unpartitioned space (see Figure 8), which, here, is 20 GB: # system-config-lvm.
ORACLE-BASE - UNIX Commands for DBAs
AIX to Solaris Operating System Migration Solutions
Linux Migration Guide - OpenSolaris
Migrating from Linux to Solaris or OpenSolaris - Solaris Developer ...
HP Solaris-to-HP-UX Porting Kit
Porting Solaris code onto Itanium HP-UX 11i and Red Hat.
HP to AIX migration - Network Tuning parameters - Toolbox for IT ...
HP Simplifies Migration for Sun Solaris Customers to More ...
Migrating from Solaris to HP-UX-components
Computerworld > HP's blue light special- 85% off HP-UX with ...
HP-UX to Solaris Migration
Last modified: July 01, 2018