Common Traits of the Veteran Unix Admin 592
snydeq writes "Deep End's Paul Venezia offers a field guide to understanding your resident Unix veteran, laying out the nine traits common to this grizzled, hardcore set. From not using sudo, to wielding regular expressions like weapons, to generally assuming the problem resides with whomever is asking the question, each trait is key to 'spotting these rare, beautiful creatures in the wild,' Venezia writes. 'If some of these traits seem anti-social or difficult to understand from a lay perspective, that's because they are. Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.'"
So... Dilbert got it right (Score:4, Informative)
http://ozguru.mu.nu/Photos/2005-11-11--Dilbert_Unix.jpg [ozguru.mu.nu]
Re:We don't use sudo? (Score:5, Informative)
You're wrong, the article is right.
Re:We don't use sudo? (Score:2, Informative)
Seconded. Obligatory car analogy:
Relying on sudo to keep you safe is like relying on your car's bumpers to avoid injury. You'd have been better served just watching the f**king road.
Where the analogy breaks down, is that bumpers are still a good idea even if you're most cautious. There are other morons sharing the same road.
Your shell, however, is yours and yours alone for the lifetime of the process. If you don't trust yourself not to type something stupid, you shouldn't be working as an administrator. Period. Sudo was never intended to function as training wheels. To imply its necessity is to claim you, the junior admin, knows better than the senior admin. When you've done your trench time, you too will trust yourself.
Sudo's proper place is for developer and QA commands that happen with annoying frequency should an admin have to get involved.
Rebooting (Score:5, Informative)
The reason that Unix SAs don't like to reboot is deep seated in the history of Unix running decades ago on hardware for which a reboot cycle meant interrupting potentially dozens of people all sharing the same machine for a sequence that might take 10 to 20 minutes if nothing went wrong. Rebooting was correctly viewed as something to avoid whenever possible.
Windows was not engineered for long uptimes until NT 4.0 and is a johnny-come-lately OS in comparison. Windows didn't run on significant (read: capable of simultaneously supporting more than one user in a non-trivial way) hardware until, what, 1994 or 1995? Meanwhile Unix and its intellectual antecedents had been supporting multi-dozen-user installations for nearly three decades.
When there's only one user, rebooting isn't nearly as big a deal as when there are 20, 30 or more. That dichotomy alone drove the reliability of Unix, and the the lax attitude of Windows.
Personally, even though rebooting my desktop Linux computer with it's fast processor, SSD and RAID disks, takes well under a minute, I still don't like doing it. There's something wrong: It shouldn't need to be done. If I'm rebooting for a non-hardware related issue, it's because I'm being sloppy.
Re:RegEx? (Score:4, Informative)
Requirement: Long URLs must have a slash between the domain and the path component.
The generic URI syntax consists of 4 main components... ://?
The path component is optional, and the authority component can be terminated directly by a ?. Per RFC 2396.
3.2 The authority component is preceded by a double slash "//" and is
terminated by the next slash "/", question-mark "?", or by the end of
the URI.
So I am unclear sure where your requirement to insert a slash actually comes from.
I challenge you to find a non-regex solution as nice as this:
Given you are using java, using the URL class. I would expect url.toString() to emit a well formed URL, with the various components separated to spec.
I suppose you could also construct the string manually from the url parts in a straightforward manner... something along the lines of...
urlstring = url.getProtocol() + "://" + url.getAuthority() + "/" + url.getFile();
Re:We don't use sudo? (Score:4, Informative)
Re:We don't use sudo? (Score:5, Informative)
This guy lost me with the first thing on the list. Going directly to root is great - if you're a noob in mom's basement. Nobody who has ever run systems in a serious environment mucks around as root as an alternative to something like sudo.
Nonsense. Su is much simpler software and much less likely to have security vulnerabilities. Sudo has had many. Allowing the 'sudo' binary to be setuid root in a serious environment is considered a major risk. The 'su' binary is much simpler code, and slapping the setuid bit on it is considered much safer. Well, on BSD 'su' binary is extremely safe. On a GNU/Linux OS, system's setuid su might be linked against a nightmare called GLIBC, but then sudo would be also. Sudo has the issue of 'subtle/sneaky ways around' any configured policies. And sneaky ways to gain sudo permissions not assigned by policy.
Assigning full Sudo privileges to ANY user is a serious security risk, since you have reduced the number of passwords that must be guessed to gain full root privileges to one password, because sudo requires a password that is the same as the user's login password. The security of requiring knowledge of the user password and separate root password is considered stronger; when you disable root login and require wheel/admin group membership to 'su'. If you assign full sudo privileges to any user then only that user's password is required to gain full root access, which is a reduction in root authentication security strength.
Also 'idle timeout' for root logins is ineffective when sudo is used. If a third party gained access to any logged in ssh session they can run sudo commands; 'sudo command timeout' can be defeated by merely staying logged in until the legitimate user logs in somewhere else and runs a sudo command; once any legitimate user types the proper sudo password, ALL terminals/remote login sessions under the same username can use any 'sudo' command without a password reprompt, due to the way sudo is designed.
Su is used in serious environments all the time for the purpose of system maintenance and is considered preferable to sudo for such purpose --- hardly anyone ever even imagined using sudo for that purpose until 5 or 6 years ago. Sudo is a relative newcomer, not installed by default on most systems, and the purpose it was created for is misunderstood if you suggest actual admins use it to perform commands. Sudo is for enabling non-admins to perform some tasks that require UID 0 privileges, under rules established by the system admin; that is the reason the Sudo tool was created, its purpose for existing, and it has nothing to do with the root/sysadmin performing their own duties which actually require root.
That is 'sudo is for partial roots / guest root users, "guests" who are to temporarily have root access but not be one of the persons entrusted with the root passwords.
If you don't login to the system to perform administrative tasks, it is better to simply login as a normal user and then 'su' when you need it. That way you have to know two different passwords to do things as root; which is strong security.
My environment has some critical systems with minimal installs, where sudo isn't even installed and won't be; root filesystem being read-only and requiring signed binaries and all. Sudo not even available for some older OS flavors.
It's common to have some paths non-root isn't even allowed to CD into; and this is an improvement for security, but of course sudo is useless here: Hint: there is no such thing as 'sudo cd'; if you think otherwise, you need to lookup what the cd command does again.
The fact of the matter, is, when you are performing system administrative tasks, typing 'sudo' after each command is too cumbersome. Convenience, and speed matter, as they have a direct impact on admin performance and efficiency. Sudo introduces inconveniences that are likely to result in serious system-e
Re:vim? really? (Score:5, Informative)
When not using ed(1), Real Unix vets use Bostic's One True vi, not some fagged-up Vegas showplace of an editor like vim.
Indeed.
A particularly nasty vim change is that:
- In vi "u" undoes the last change - even if it was another "u". Hit "u" repeatedly and the screen flips between with and without the last change, making it blink. Useful if a multi-change command may have done something goofy.
- In vim "u" backs you through a history of changes. Handy sometimes. But to redo you have to "control-r". Forget about blinking the screen to use your eye's motion sensors to spot the trouble. Also watch out for accidentally undoing a bunch of changes just before you close and exit. Oops!
Geez, guys. If you want to add new stuff (like a history to go backward through), don't change the behavior of an existing command. Add another, or at least make it configurable - preferably with the default the old behavior.
Re:vim? really? (Score:5, Informative)
That's what netcat, socat are for (Score:4, Informative)
I still use telnet, mainly for connecting to remote http and smtp servers.
Telnet sends terminal management information included in the byte stream. Use netcat or socat if you just want to pipe stdin into a TCP session.
Re:RegEx? (Score:4, Informative)
We exist. It's really pretty simple, achieve enlightenment, then the regular expressions will get you. It's much harder the other way around.
I once wrote a program that read tables from a database to generate regular expressions to parse really messed up addresses (third world, not easy US style). The regex generated the Perl variables that would populate the database table. I think the largest of the expressions was ~43k, hence why the regex was generated, being a concept that was used in the code, but never appeared, for the intense fear it would incite. 10 pages of code and a few tables to replace an expensive program we bought that didn't work.
As with any type of programming, you have to look at it from the computer's perspective and understand how the computer will feel about the code you're feeding it.