Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Seven Habits of Highly Effective Unix Admins

Soulskill posted about 4 months ago | from the make-sure-you're-in-folder-you-think-you're-in dept.

Unix 136

jfruh writes: "Being a Unix or Linux admin tends to be an odd kind of job: you often spend much of your workday on your own, with lots of time when you don't have a specific pressing task, punctuated by moments of panic where you need to do something very important right away. Sandra Henry-Stocker, a veteran sysadmin, offers suggestions on how to structure your professional life if you're in this job. Her advice includes setting priorities, knowing your tools, and providing explanations to the co-workers whom you help." What habits have you found effective for system administration?

cancel ×

136 comments

Sorry! There are no comments related to the filter you selected.

Number 6 Problem (5, Insightful)

magamiako1 (1026318) | about 4 months ago | (#46726373)

The issue with #6 is that users almost invariably never accept an answer here. And a lot of the time it may be something you can't adequately explain, which is something they don't like even more. Especially if you know the problem wasn't the result of something you did.

Re:Number 6 Problem (2, Informative)

zacherynuk (2782105) | about 4 months ago | (#46726501)

Indeed - not only that, but even if you are really good at keeping docs, an intranet log or similar - it still won't be read, understood or appreciated. Later on, with even the best of everyone's interests at heart the worst thing you could ever say is - "I documented this here, and explained it here and asked for feedback here and you said you read it..." Nothing like a few reference facts and common sense to drive a wedge between admins and users.

What... (1)

fyngyrz (762201) | about 4 months ago | (#46730049)

...habits have you found effective for system administration?

I like to shut all the ports in the firewall. The sense of calm that descends on the servers is downright pleasant. Of course, then the phone begins to ring...

Silly boy! (1)

Anonymous Coward | about 4 months ago | (#46727603)

With Linux/Unix just say, "Well it's an antiquated operating system." - and if Linux add "and with this F/OSS operating system, well, you get what you paid for and with the addition of [insert package name like systemd] 'blah blah blah blah' caused our problem. I need a raise to work with this shit!"

If we were on Windows, this wouldn't happen!

It works the other way around if you are a Windows admin, too. Just replace F/OSS with "closed undocumented source and [insert money hungry profit driven dribble screwing over customers stuff here] ' blah blah blah' If this were Linux, this wouldn't have happned! I need a raise to work with this shit!"

The exception is Oracle. Everybody throws their hands up, skakes their heads, and gets the knee pads and KJ and LIKE IT!

I forgot - MacMini shops (1)

Anonymous Coward | about 4 months ago | (#46727683)

If you are in a shop that chains together MacMini servers, whe there's problem, start crying, ask for a hug and just say "I don't know what happened?! *sobbing* Mac is Go...Job's gift to mankind kind! *sob* I'm such a failure! *snot runs from nose*"

You'll get a couple of days off, they'll power down everything, turn it back on, and it'll all be working fine when you get back.

Bait (0)

zacherynuk (2782105) | about 4 months ago | (#46726375)

For an inter-OS flame war ? (Again)

Re:Bait (0, Troll)

Anonymous Coward | about 4 months ago | (#46726655)

Certainly seems like a blatant attempt to stir one up, as none of the "advice" in TFA is remotely UNIX specific, only a few of the examples. Although the general air of arrogant douchiness with which the article was written certainly reeks of a UNIX admin.

Re:Bait (3, Interesting)

cusco (717999) | about 4 months ago | (#46726831)

From TFS, I really don't get why that applies only to Unix admins. That describes the years I've spent as a Windows admin as well.

Re:Bait (2)

zacherynuk (2782105) | about 4 months ago | (#46727121)

Fact is - a good SysAdmin can play well anywhere on the pitch. Typically a 'system' comprises of more than one discipline.

Basic time management, inter-personal skills and some grasp of hygiene are pretty much must-haves.

Knowledge of the tools required to perform your duties and save the planet are a gimme, surely, once you are in that position. I am sure a 'nix admin can't avoid other disciplines the same as a wintel admin can't avoid *nix. Difference perhaps is that a decent multi-disciplines admin won't throw their toys out of the pram when they find out they have to interact with 3rd parties. (personally, physically or programmatically - take your pick)

By definition a system is a "complex whole" and should not, in 2014 be defined by OS...unless you are going to be specific about that OS, in which case you are not a sysadmin you are a *nix admin shirly.

Re:Bait (4, Funny)

inasity_rules (1110095) | about 4 months ago | (#46727497)

You really need to have a beard to get it. Do you have a beard? You don't sound like you have a proper beard.

Beard (1)

formfeed (703859) | about 4 months ago | (#46728937)

You really need to have a beard to get it. Do you have a beard? You don't sound like you have a proper beard.

Ehhh, of course you need a beard. But the article also says, to be successful you should remove spaghetti once in a while:

Habit 7: Make time for yourself
[... ]Taking care of yourself is an important part of doing a good job."

Re:Bait (1)

jacobsm (661831) | about 4 months ago | (#46728999)

And as a zOS Systems Programmer too.

Tmux (4, Informative)

matthiasvegh (1800634) | about 4 months ago | (#46726377)

I discovered tmux (terminal multiplexer) a while back, and is a very potent replacement for screen, it supports splitting windows, having multiple sessions, sharing windows between sessions, customizable status bars etc. Try it out!

Re:Tmux (2)

wonkey_monkey (2592601) | about 4 months ago | (#46726521)

Try it out!

Make me!

Re:Tmux (5, Funny)

oodaloop (1229816) | about 4 months ago | (#46726605)

Sudo try it out!

Re:Tmux (1)

Anonymous Coward | about 4 months ago | (#46726653)

ok....

Re:Tmux (1)

evilviper (135110) | about 4 months ago | (#46727587)

sudo: try: command not found

Re:Tmux (1)

Dishevel (1105119) | about 4 months ago | (#46727831)

sodo do

Re:Tmux (1)

Anonymous Coward | about 4 months ago | (#46727681)

oodaloop is not in the sudoers file. This incident will be reported.

Re:Tmux (0)

Anonymous Coward | about 4 months ago | (#46727709)

oodaloop is not in the sudoers file.
This incident will be reported. [xkcd.com]

Re:Tmux (1)

rubycodez (864176) | about 4 months ago | (#46726531)

screen also has split windows, multiple sessions, customizable status bar. For my use cases, I could not find a compelling reason to use tmux

Re:Tmux (3, Informative)

evilviper (135110) | about 4 months ago | (#46727249)

For my use cases, I could not find a compelling reason to use tmux

Obviously if you've been limiting yourself to the features of "screen" for many years, you're not going to think you need the added features of "tmux"...

A big one is sharing:
"window can be linked to an arbitrary number of sessions". If you or somebody else has a screen session open, you don't have to detach it from their terminal to see what's on it. You can just attach it to your terminal as well. Works great when you've got a session attached to your desktop, then want to access it on your laptop/tablet/phone/etc. The tmux session will even change geometry to match the smallest terminal window.

Being more lightweight and responsive is good. Saner keys for some functions, like ctrl-a pg-up to access scrollback. And just the fact that it's still getting active development is an important feature.

Re:Tmux (3)

Chalex (71702) | about 4 months ago | (#46727265)

screen -x shares the screen just fine for me.

Re:Tmux (1)

evilviper (135110) | about 4 months ago | (#46727417)

I oversimplified the explanation a bit...

Here it is in nicm@'s words:
"In particular, being able to share a single window between multiple terminals, with other windows in the same session but entirely separate. Adding this to screen was implausible"

http://undeadly.org/cgi?action... [undeadly.org]

Re:Tmux (3, Informative)

dissy (172727) | about 4 months ago | (#46728169)

Here it is in nicm@'s words:
"In particular, being able to share a single window between multiple terminals, with other windows in the same session but entirely separate. Adding this to screen was implausible"

Perhaps I am still misunderstanding the features of tmux (most likely in fact), but to say that is implausible to add to screen is misleading to say the least, since I have been doing exactly that in screen for nearly a decade.

On one terminal, either start a new screen session or -r to a detached session.
If starting a new one, try: screen -S LetsShare

On a second terminal, run: screen -list
You should see a list of screen sessions and their status (attached, detached, multi, etc)
If you used -S on start that will be the name, otherwise it's some tty.host.number string.

Now on that second terminal run: screen -x

Try to adjust both terminal sessions so you can see them at the same time. Type in either, watch in either. They are shared seemingly matching your tmux description.

You can change permissions per terminal so others can't type but will see everything you do (aka tutorial mode) using ^a *

Also for split/multiple windows showing on the same terminal, use ^a S (control-a capital-S)
To switch between split windows use ^a tab
Close a section of split window with ^a Q

The status bar problem is true and pretty annoying. I fixed it myself with a line in ~/.screenrc but of course I have to pretty much install that user config file on every new system I use which can get annoying.
If you want an always-on status bar showing window numbers and titles (^a A to change the title), add this to .screenrc (and hope slashdot doesn't munge it!)

hardstatus alwayslastline "%{= wk}%-Lw%{= BW}%n%f* %t%{-}%+Lw %-=%{= BW}%H%{-}%{-}"

Note the two "BW" bits? That's background blue and foreground white, and applies to the window with focus. Change B to R for red for example (production vs not-production in my case)

Here is my whole .screenrc file for copy/paste purposes: http://pastebin.com/kMkuFXi9 [pastebin.com]
No splash screen, always on status bar, 10k line scrollback history for copy/paste (^a [ and ^a ] ), and auto-open three windows with preset titles and commands running in them.

I don't mean to knock tmux in any way at all, having not used it (and I do plan to check it out now) - but hopefully these screen tips help out others here.

Re:Tmux (0)

Anonymous Coward | about 4 months ago | (#46729393)

Trying to argue after mentioning it is like trying to convince people that EMACS is better than VI, or VI is better than EMACS. It's pointless, and you did your job getting a few people to look at something they may have never seen before.

Most of us have our toolbox, and in that toolbox we have the tools that we like. Our reasons may not always make sense, but our tools work very well for us. I'm more efficient in VI than anyone I know, and a guy behind me is more efficient in EMACS than anyone I have ever met. We both do very well at our jobs, and both function with our own favorite editor. Making us switch would hurt our productivity.

Taking 2 months to get accustomed to a new way of doing something is not always affordable, and not always wise. If you tool was voice activated and provided porn while people used it more people would want to use it. You are not better at tasks because of software, you are better because of how you use software.

Re:Tmux (1)

emag (4640) | about 4 months ago | (#46727475)

Does tmux support connecting to serial consoles yet?

Re:Tmux (0)

Anonymous Coward | about 4 months ago | (#46728257)

byobu is better:

http://en.wikipedia.org/wiki/Byobu_(software)

Re:Tmux (1)

antdude (79039) | about 4 months ago | (#46728279)

I still like the plain old screen. I don't need the fancy splits, status bars, etc. If I wanted more than one screens, I run separate commands. I have had screen crash before even though very rare. I would hate to see tmux crash all my sessions.

Re:Tmux (-1)

Anonymous Coward | about 4 months ago | (#46728637)

I don't know what the fuck you idiots are even talking about. Screens crashing? Splits? Fancy? Why not just use Windows instead of this bugged up cluster fuck you call Linux, and X-server or whatever the fuck weird ass layer upon layer of shit you fewls are calling a UI. Windows has plenty of screen sharing tools available that just fucking work without a god damn cluster fuck all over your monitor.

Or do you even use monitors on your Linux?

Re:Tmux (1)

kybred (795293) | about 4 months ago | (#46729925)

Or do you even use monitors on your Linux?

I'm doing just fine with my ASR-33, thank you!

Re:Tmux (1)

excelsior_gr (969383) | about 4 months ago | (#46729663)

You should tell Microsoft. I hear they are looking to upgrade Metro.

Using multiple shells (4, Informative)

Neruocomp (513658) | about 4 months ago | (#46726403)

When working on a problem, I usually have two or more shells open. I don't mean multitasking, but with more then one open, I can issue commands from one and use the others to monitor logs/etc.

One habit is ... (0, Funny)

Anonymous Coward | about 4 months ago | (#46726405)

Have a mini-fridge under your cubicle desk for constant snacking. The constant snaking would be the habit. Really though, there are too many fat bastards in IT. (and everywhere else, but especially IT). And no, on a plane, I do not prefer sitting next to a fat person that needs to seats, that is sweaty and smelly versus a person of normal weight.

Re:One habit is ... (4, Funny)

Fallen Kell (165468) | about 4 months ago | (#46726687)

The reason there are more fat people in IT isn't because we want to be. It is because the GOOD IT people get fat because they know that the best IT people never need to leave their seats. If you have to leave your seat to do something as an admin, you are doing something wrong and not using the technology that is available to you to be able to fix everything but physical hardware failure or installation from your seat.

Re:One habit is ... (1)

Anonymous Coward | about 4 months ago | (#46729957)

OK fatass.

Re:One habit is ... (0)

Anonymous Coward | about 4 months ago | (#46727035)

While killing time we use it to master the latest app game.
When Angry Birds arrived, it helped to improve on our egg aim and timing skill.
We couldn't be more ready for the next app needing an egg launching expert !

Re:One habit is ... (0)

Anonymous Coward | about 4 months ago | (#46727171)

How about a person of normal weight that is sweaty and smelly? Would you take them over an overweight person that is clean and odor free?

Re:One habit is ... (1)

jones_supa (887896) | about 4 months ago | (#46727631)

Have a mini-fridge under your cubicle desk for constant snacking. The constant snaking would be the habit. Really though, there are too many fat bastards in IT.

Obligatory video: Valve Snack Bar [youtube.com] .

i was so wrong (5, Funny)

zlives (2009072) | about 4 months ago | (#46726417)

i thought they were
sloth, gluttony, pride,...

Re:i was so wrong (3, Funny)

kimvette (919543) | about 4 months ago | (#46726469)

That's "How to be a BOFH"

Habits ... (3, Informative)

Xaemyl (88001) | about 4 months ago | (#46726489)

What habits have I found effective for system administration? BOFH spring to mind ...

Re:Habits ... (1)

ClownPenis (1315157) | about 4 months ago | (#46726799)

+1 Funny, Insightful

Knowing your tools (5, Funny)

Rosco P. Coltrane (209368) | about 4 months ago | (#46726497)

I know them all. They all work in Marketing.

Re:Knowing your tools (4, Funny)

rcamans (252182) | about 4 months ago | (#46726707)

Apparently you have not interacted with management much, or you would not have restricted your answer to marketing...

Re:Knowing your tools (1)

Bigbutt (65939) | about 4 months ago | (#46727571)

Or engineering or development.

[John]

Re:Knowing your tools (1)

ThatsDrDangerToYou (3480047) | about 4 months ago | (#46729195)

Or engineering or development.

[John]

Oh hey, watch it buster. This is /.

Re:Knowing your tools (2)

gstoddart (321705) | about 4 months ago | (#46727461)

I know them all. They all work in Marketing.

No, a couple are in HR as well, and there is at least one in the Finance department. Some days I'm not so sure about IT.

Have you ever been told you need to submit accurate time sheets for the week on Wednesdays? How the hell do you expect me to give you accurate timesheets for the entire week on a Wednesday when I usually work Wednesday and Friday evenings for an unknown period of time??? And if I had to submit it on Wednesday, don't grumble that I had to submit a correction on Monday to come up with the real number.

But, I digress. ;-)

#7 Be Appriopriately Lazy (5, Insightful)

tiberus (258517) | about 4 months ago | (#46726541)

The first time a task comes up deal with it manually, it may or may not be related to a problem.

The second time this task occurs deal with it manually.

The third time this task occurs, it's time to start scripting.

It may take you a day or more to write the script, test debug, etc. or even longer for complex tasks but, this behavior tends to be a winner. The script is already some degree of documentation, it records the steps, etc. If it's robust enough it can be used to by your support techs to resolve issues, expanding the number of people who can resolve an issue, freeing the admin for other tasks. Scripts tend not to make typos (yes, I know your command line skills are legendary) and can save a lot of time and effort in the long run.

Re:#7 Be Appriopriately Lazy (1)

tiberus (258517) | about 4 months ago | (#46726549)

#EpicFail, can't count, shoulda been #8...

Re:#7 Be Appriopriately Lazy (0)

Anonymous Coward | about 4 months ago | (#46727163)

Shoulda used a script.

Re:#8 Be Appriopriately Lazy (3, Funny)

tiberus (258517) | about 4 months ago | (#46727819)

First time for this task ;-)

Re:#7 Be Appriopriately Lazy (1)

Capt.DrumkenBum (1173011) | about 4 months ago | (#46727193)

I have always said, "Anything you are going to do more than three times. Script it."
Also Cron is your best friend. :)

Re:#7 Be Appriopriately Lazy (1)

Leif_Bloomquist (311286) | about 4 months ago | (#46727197)

Just watch out for this:

https://xkcd.com/1319/ [xkcd.com]

Re:#7 Be Appriopriately Lazy (1)

gauauu (649169) | about 4 months ago | (#46727309)

Just watch out for this:

https://xkcd.com/1319/ [xkcd.com]

Either way, you'll have a lot more fun maintaining the script than you would doing the same boring task over and over :)

Re:#7 Be Appriopriately Lazy (1)

Anonymous Coward | about 4 months ago | (#46727217)

It may take you a day or more to write the script, test debug, etc. or even longer for complex tasks but, this behavior tends to be a winner.

Step #7.1: Prepare excuse for mgmt why it is taking you 10 times longer to complete this task than it did the first two times.

Re:#7 Be Appriopriately Lazy (1)

tiberus (258517) | about 4 months ago | (#46728399)

Step #7.1: Prepare excuse for mgmt [...]

#1 - It's not an excuse, it's a reason get in the proper mindset.

#2 - You already know the reason and bonus, bean counters love this. You're gonna save the company long term dollars with a short term expenditure.

I hate to break it to you... (1)

mr_mischief (456295) | about 4 months ago | (#46726555)

If you are not doing active improvements, planning for failover, and using good configuration management techniques then your slow time is adding to the number of hurry-up-and-fix-all-the-things times. There are always external matters like heartbleed that will come along, as a sysadmin's job is not to review the memory allocator in the SSL library regularly. However, if your web services or mail services are down because a single system went offline then you're to be blaming yourself.

Re:I hate to break it to you... (0)

Anonymous Coward | about 4 months ago | (#46727013)

and using good configuration management techniques

The problem is, almost nobody implements good configuration management techniques.

I'll happily take a text file full of notes over some of the monstrosities I've seen devised using Puppet, Chef and the like just because lolololdevopsbitches!!!!!!!!!!!1111

#0 (1)

radarskiy (2874255) | about 4 months ago | (#46726693)

Did you try turning it off then on again?

The columnist must be FORTRAN programmer. (2)

140Mandak262Jamuna (970587) | about 4 months ago | (#46726873)

Everyone knows real programmers code in C, and in C you count from zero. Counting from one? that is so FORTRAN. Retire already, old chap.

Re:The columnist must be FORTRAN programmer. (0)

Anonymous Coward | about 4 months ago | (#46728693)

What the fuck does that even mean? Counting in C? That number in between the brackets if a fucking offset from the first element. Not a "count" of array elements.

And I'm not even a fucking programmer by trade.

uh... (2)

rs79 (71822) | about 4 months ago | (#46726945)

"What habits have you found effective for system administration?"

Carrying an Uzi.

Rebooting is not a fix (5, Insightful)

hawguy (1600213) | about 4 months ago | (#46726957)

As someone who's managed a team of sysadmins that moved to the Linux world from Windows, I have this tip: "Reboot does not fix anything, it just hides things".

For some reason, Windows admins have been trained to reboot immediately when things don't work well rather than to figure out why something is failing. I'm sure this was a valid "fix" in older versions of Windows, but Windows has been stable for quite some time, and things shouldn't mysteriously stop working for no reason. Take a bit of time to figure out *why* the CPU is suddenly spiking on the database server, since if you reboot it, you will have lost most of the evidence for why it's happening, and it's likely to happen again. If it's a production server and you can't spend much time, run a few diagnostics (ps, "top", lsof, etc) and save to a file for the postmortem, but don't just go in and reboot before looking around.

Re:Rebooting is not a fix (3, Insightful)

evilviper (135110) | about 4 months ago | (#46727321)

"Reboot does not fix anything, it just hides things".

That's not specific to rebooting... It's more a question of doing root-cause analysis, versus quick bandaids. I'm firmly in the RCA camp, but sometimes it's the companies that are to blame, rather than the individual admins. Some companies are heavily slanted towards always getting the quickest possible workaround, rather than ever actually finding and fixing the problem. It's one of those false-economies, like counting lines of code and similar.

Re:Rebooting is not a fix (1)

Bacon Bits (926911) | about 4 months ago | (#46727375)

On the flip side, spending six weeks fixing an issue on a single server running a non-critical, non-time-sensitive service which occurs once or twice a year and is 100% worked around by a reboot probably isn't an efficient use of your time.

Re:Rebooting is not a fix (1)

evilviper (135110) | about 4 months ago | (#46727523)

On the flip side, spending six weeks fixing an issue on a single server running a non-critical, non-time-sensitive service which occurs once or twice a year and is 100% worked around by a reboot probably isn't an efficient use of your time.

In the long-term, it is. If you let issues like that continue to exist, then you'll get stuck with an unnecessary proliferation of servers, with each running just one service, so rebooting one doesn't take the others down.

Not to mention that you'll find that you get stuck maintaining multiple, overlapping services, because the first one wasn't reliable enough for the tasks some department decided to bring-in, later.

And also, I don't think I've ever seen a service that was non-critical and non-time-sensitive. Whatever it is, people won't even try to use it until the very last minute, when they need it to work immediately. It could be a damn web page that just hosts the phone extension list, and because HR needs to call someone about something simple, at 5pm on Friday, that server is now delaying everyone's paychecks. EVERYTHING ends up being varying degrees of critical.

On the other hand. . . make sure whatever changes (0)

Anonymous Coward | about 4 months ago | (#46728193)

On the other hand. . . make sure whatever changes you make will survive a reboot. . .

Re:Rebooting is not a fix (5, Informative)

pla (258480) | about 4 months ago | (#46728695)

For some reason, Windows admins have been trained to reboot immediately when things don't work well rather than to figure out why something is failing.

Because in the Windows world, I usually don't have the luxury of digging into the kernel's or driver's source code to figure out exactly why it has stopped behaving correctly. If it doesn't log any errors, doesn't export any useful diagnostic messages, doesn't outright crash on reproducible conditions, and just stops working "right", your avenues of further inquiry get very very ugly, very fast.

I can reboot a VM in well under a minute. For any nontrivial problem that happens roughly twice a month and a reboot makes it go away, it would take twenty years of rebooting to justify spending an entire eight hour day diagnosing the root cause.

And I say that as someone who (in the Linux world) has written his own kernel patches to work around buggy hardware. In Windows, just not worth the time; because even if you do successfully diagnose the problem, you may well have no ability to correct it.

Re:Rebooting is not a fix (1)

magamiako1 (1026318) | about 4 months ago | (#46729799)

This person knows what's up.

Re:Rebooting is not a fix (1)

magamiako1 (1026318) | about 4 months ago | (#46729833)

For what it's worth, even if you do have access to dive into the code/kernel memory to find what the problem is, you must first know how to read what you're looking at. A lot of good this stuff does for you if you have no idea how it works in the first place. That's not a uniquely Windows problem, though; because very little in the Linux Admin world over the years strictly enforces that you should know this stuff. The technical information on it out there is about as good as the Technet articles on Windows that tell you how to appropriately identify system bottlenecks (Disk Queue Length, etc.).

I believe dtrace was added not too long ago and seems to be the goto solution for most Linux admins I know, but I've not personally used it to seek out issues.

Re:Rebooting is not a fix (1)

magamiako1 (1026318) | about 4 months ago | (#46729839)

The good news is the modern desire to 'web all the things' with stuff like ROR, PHP, Tomcat, etc; you can generally find in the code where something is an issue without having to necessarily trace system calls. You don't have quite that luxury on compiled applications. Though occasionally you could run into issues with the interpreted languages that just don't compile properly and cause problems--then you're back to the same problem...

Re:Rebooting is not a fix (0)

Anonymous Coward | about 4 months ago | (#46728777)

Bullshit. Windows admins are not trained to reboot when there is a problem. That's just anti-Windows admin rubbish. It's pretty trivial to restart the offending service, and all Windows admins I've known (myself included) will do this before rebooting a machine. I can't even rememeber the last time I rebooted a machine to try to fix an issue. That's just lazy stupidity. "Derp... I don't know what the problem is and am too stupid to figure it out... Herp.. Just reboot!"

And all of us can view the fucking task manager to find offending processes. We all know how to use performance counters to find bottlenecks (do you even have something similar on linux?). We all know how to review logs. You're painting Windows admins as stupid because you feel superior as a linux-using bitch.

Fuck off, linfag.

Re:Rebooting is not a fix (0)

Anonymous Coward | about 4 months ago | (#46729405)

I don't think anyone is suggesting all Windows Admins do. I've worked with good Windows Admins and bad ones. The good ones will perform due diligence and investigate the problem before rebooting. The bad ones go straight for the reboot. I've hard dinks like that reboot a Windows box on me while I'm in the middle of doing a postmortem. It used to piss me off to no end...

But than again, the bad Windows admins are the folks that figured they knew how to click around in a pretty GUI and reinstall windows on a family members machine and figured IT was easy.... We've all worked with those type of people! They couldn't even traverse a file system from a command prompt if their life depended on it.

Re:Rebooting is not a fix (1)

hawguy (1600213) | about 4 months ago | (#46729679)

Bullshit. Windows admins are not trained to reboot when there is a problem

It's amusing that in the post right before yours (and not an AC like you), a Windows Admin explained why he does reboot first:

Because in the Windows world, I usually don't have the luxury of digging into the kernel's or driver's source code to figure out exactly why it has stopped behaving correctly

Re:Rebooting is not a fix (0)

Anonymous Coward | about 4 months ago | (#46729351)

Real Unix admins don't reboot to fix a problem. Any good *nix OS (and no linux is NOT there yet) should be able to stay up for years...

Hell, I've seen up times on Solaris boxes that were in the 5 and 6 year (multiple times)!

Let the Windows admins reboot... the Unix ones will fix the problem w/o it!

video games (0)

Anonymous Coward | about 4 months ago | (#46726981)

have a Windows computer on hand for video games and Facebook.

Only three habits are necessary (5, Funny)

Anonymous Coward | about 4 months ago | (#46726991)

Only three things are necessary for a highly effective unix admin:

To crush your userbase
To see their accounts deleted before you
To hear the lamentations of the salesmen

Re:Only three habits are necessary (2)

SlickUSA (1749194) | about 4 months ago | (#46727911)

If i could mod you up for this, i would. Hail Conan!

Keep a sucker rod handy... (1)

rgbatduke (1231380) | about 4 months ago | (#46727015)

... works like a charm for me.

rgb

Habit #1 (1)

damn_registrars (1103043) | about 4 months ago | (#46727047)

Don't waste time reading slashdot.

90% of the job (1)

beernutmark (1274132) | about 4 months ago | (#46727319)

90% of the job: "Have you tried turning it on and off again?" https://www.youtube.com/watch?... [youtube.com]

Re:90% of the job (1)

beernutmark (1274132) | about 4 months ago | (#46727351)

And yes I know that this isn't really a fix for unix systems. It's just a joke.

Automate everything using chef/puppet (1)

ptaff (165113) | about 4 months ago | (#46727457)

Using anything like puppet [puppetlabs.com] or chef [getchef.com] under version control to do all server ops will not only leave you with a full timestamped documentation, but will allow you to easily horizontally scale servers, rebuild them should disaster strike and protect you from stupid upstream package updates that b0rk your config files.

Have a staging and production environment? pushing your chef/puppet scripts to production after they're proven to work insures you have the same changes applied on both sides, and avoid manual operations on production.

Re:Automate everything using chef/puppet (1)

mlts (1038732) | about 4 months ago | (#46727559)

Don't forget Splunk, so the servers that you are managing have a place to dump logs, and where you can do syslog searches from one place. Splunk isn't a magic bullet, but it does a lot of useful functions and can scale up, and it is a very useful troubleshooting tool.

good habits = not in that job (0)

Anonymous Coward | about 4 months ago | (#46727495)

If you really acquired good work habits, one would expect that you would be able to get out of the tedious, low end job that sysadmin is. That so much of the job can be automated should tell you a lot about it too.

Re:good habits = not in that job (1)

jedidiah (1196) | about 4 months ago | (#46727957)

Yes... getting out of "the tedious low end job that sysadmin is" just so that you can sit in painfully dull meetings all day. Great plan that.

the most useful talent (1)

roc97007 (608802) | about 4 months ago | (#46727633)

I think the most useful talent I've developed is the ability to go to sleep fast and to wake up fast and alert. When the phone rings or pager goes off, the faster you can reach "full on", find and fix the problem, and get back to sleep, the more sleep you get in the long run. Cohorts who have trouble getting to sleep after a late night emergency tend to be seriously dragging by the end of their oncall time.

Re:the most useful talent (1)

fl!ptop (902193) | about 4 months ago | (#46728867)

the most useful talent I've developed is the ability to go to sleep fast and to wake up fast and alert

Your not fooling anyone, we can all hear snoring coming from your cubicle.

Re:the most useful talent (1)

roc97007 (608802) | about 4 months ago | (#46728975)

the most useful talent I've developed is the ability to go to sleep fast and to wake up fast and alert

Your not fooling anyone, we can all hear snoring coming from your cubicle.

I didn't say *where* I was going to sleep...

ugh (0)

Anonymous Coward | about 4 months ago | (#46727743)

Seriously Slashdot, please don't summon up that old seven habits trite again. It takes a special type of ignorance to ascribe to this garbage. Just like the "100 ways to" maximize self indulgence.

To be an effective admin AND stay in a job (4, Interesting)

petes_PoV (912422) | about 4 months ago | (#46727855)

Rule #8 would be not to fix problems too quickly (and let some that you can see coming, happen).

If you fix every problem before it gets serious and avert the other 90%, your bosses will think they have a highly reliable IT infrastructure. They will then cast their eyes about for cost savings - and the biggest target will be the most highly paid admins - the most senior ones - YOU!!!

So keep the problems coming, as all that management have to assess you on are the number of fixes and the time to fix. Nobody ever got promoted for solving problems that never happened.

Finally: 60 hours a week? Don't be daft. If you're really an effective administrator you should have your work finished well inside 30 hours and/or 4 working days.

Re:To be an effective admin AND stay in a job (2)

Anon-Admin (443764) | about 4 months ago | (#46728335)

This is so true! I worked at a company where I set up nagios with event handlers that would fix a lot of issues when they happened and when it could not fix it, the system would txt me to come fix it. Problems and downtime when to almost 0. It is amazing what happens when you have a system that can catch java leaks and restart the tomcat server.

When layoffs came around my boss called me in and told me that I was being laid off because there had not been a major issue in 6 months and they could not justify having more than one Unix admin on staff. As I was the highest paid admin I was the one being let go.

As to your "Finally:" I call BS. The last company I worked for read Gartner and really believed that one admin could manage 900 servers. They missed the part where it was 900 identically configured virtual machines. After they cut head to meet the numbers they could not figure out why we were working 80 hour weeks and people were quitting. Well when you expect one admin to run 900 unix systems that are on average 15 years old, have no underlying management system, and no unified authentication then you get what you deserve and you can holler "Gartner says" all you want to the empty room.

Re:To be an effective admin AND stay in a job (0)

Anonymous Coward | about 4 months ago | (#46728831)

There is a better solution to this problem: New Shiny

All management staff love shiny new projects. So once you fix all the egregious problems, redo the architecture, put the monitoring in place and generally reduce the maintenance issues to nearly nothing it's time to start rolling out new capabilities. That in turn will generate new problems you'll need to fix and so on and so on.

Delegate and Automate. (1)

jpvlsmv (583001) | about 4 months ago | (#46727937)

Find the people on your team who can be trusted to do the job well. Encourage them to do it. Work with them to build their skills as well as yours.

Find the people on your team who can not be trusted to do the job well, and replace them with shell scripts.

To "Know your systems" (1)

adam525 (813427) | about 4 months ago | (#46728361)

For habit #2 Nagios comes in really handy (could watch MRTG et al as well).

Setup all hosts in Nagios, sending alerts to an email for a couple weeks. Figure out what hosts have certain patterns.

What will stop you from getting fired? (0)

Anonymous Coward | about 4 months ago | (#46728815)

Realistically, all that managers know these days is outsourcing. That's their response to anything that comes up. So what difference does it make what you do when you're going to get fired anyway? They're going to fire you, outsource what you're doing to someone who does it cheaper, and give themselves a bigger bonus. If you're an employee, you're going to get fired because you cost too much.

From TFA (1)

StripedCow (776465) | about 4 months ago | (#46728949)

For example, I have some processes that involve visual basic scripts that run on a windows virtual server and send data files to a Unix server that reformats the files using Perl, preparing them to be ingested into an Oracle database.

I guess that answers the question of how many times one can curse in one sentence.

Re:From TFA (1)

g0bshiTe (596213) | about 4 months ago | (#46729443)

Why not have Perl running on the windows box and just send the data out that way?
Active Perl anyone?

What habits have you found effective for system ad (1)

g0bshiTe (596213) | about 4 months ago | (#46729437)

Hello IT,
Have you tried turning it off and back on again?
No problem mate.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>