Basic Required UNIX Skills? 57
xirlosan writes "I'd like to get a job working in a UNIX environment, be it programming or administrating UNIX machines. My question is this: What skills are absolutly 'must haves' and what other skills are attractive to employers when looking for a job in this field? I have my BS in Computer Science and have a fair amount of experience with Linux and Solaris, so I'm interested in what more I need. I looked for jobs at Monster, and there are so many skills the recommend it's hard to figure out what the most critical are. Any help would be certainly appreciated."
Basic skills (Score:2)
The devil is in the details of course, you should have a basic understanding of TCP/IP, and standard programs such as sendmail, apache, etc.
Have a look at... (Score:3, Informative)
Re:Have a look at... (Score:3, Interesting)
Sorry, but that's the way it is.
Re:Have a look at... (Score:1)
Yeah, but those three years come and go whether you like it or not. It feels a whole lot nicer to look back and know you've learned something. Five years ago I didn't know my ls from a hole in the ground. Now I know my way around pretty well. I'd rather not be a Unix admin, but I don't regret having that knowledge.
And 3 years from now, when you're up to "par", the bar will have been moved again
True, but we're all in that situation. The bar keeps moving for everyone. The core concepts and algorithms don't change much. That's the value of formal education. Yet you'll still need to know how to implement them in a commercially relevant manner. Five years from now, I want to be working in a job that hasn't been invented yet. Ten years from now I want to be inventing jobs. A whole lot of living in the next ten years is going to determine how that all plays out. It's only a LONG haul if you only look at the endpoints and forget about the life in the middle.
You need to know everything, not just the OS! (Score:5, Informative)
You can have all kinds of sysadmins, really, but being a good one requires a lot more knowledge than just the OS. Of course as a junior admin you'll prolly be handling monkey-work such as backing up stuff to tapes or even CDs and other tedious tasks the real admins dont want to do. You will deal with the lusers whose mail proggy is misconfigured or whose caps lock was left on so that now they can't get in their PC.
But as you progress in your career, you better get yourself familiarized with all the little
You need to understand that you are a handyman. You will be expected to know and do a bit of everything, and to "think outside the box". Even as a Unix admin you will probably need to be skilled in the inner workings of Microsoft software. Most networks are hybrid: The lusers all have MS crapware and Unix will be confined to the servers.
Solid knowledge of computer networks is a major plus. You need to know how to set up a network, both at the hardware and software level. Bridges, routers, switches, cabling, the works.
You need to know how to configure routers. Cisco routers are very popular, and books on them are easy to find. Knowledge of routing protocols is a big plus.
If you're lucky you might even get to play with "legacy" networks that are getting out of mainstream every second. So you better get some training on Novell stuff, and pray that's the worse you'll come across, since there is a whole lot of old stuff out there that should really be in a museum. I'm talking about early IBM hardware running long-forgotten software with manuals that have rotten away ten years ago.
You probably learned about some of this stuff in college but it wouldnt hurt to take a second look.
The stuff that you glanced over and thought you would never need to know, in particular. Such as token rings. Everyone has Ethernet right? Wrong.
Of course you should really focus on what your future employers ask in their ads.
Certifications are always nice to have. A lot of the stuff you need to know you will NOT learn in any college.
Really, the subject sums it up. You have to know a bit of everything to be a good sysadmin. I guess the same could be said about a programmer or a doctor or any other person. Knowledge is power!
Re:You need to know everything, not just the OS! (Score:3, Interesting)
The two big areas that probably help to be knowledgeable in? Programming, and networking.
What you say about legacy is true, but often it isn't a major issue. I've got FDDI (100mbit fiber running a token-ring protocol) attached to a number of my servers. In the next year or two, it'll be replaced by 100mbit ethernet or gigabit ether.
Agreed that "knowledge is power". But to go along with that, troubleshooting and the ability to 'figure things out' seems to go a long ways.
We hired on a guy who wasn't advanced... he learned Linux for himself while he was on a boat that was doing some sort of oil exploration. But it was the willingness to learn and discover new things that caught our eye. Sure enough, he ramped up very quickly and became extremely skilled at systems administration.
There doesn't seem to be any must-haves, except a lot of positions call for previous experience. That catch-22 thing. I don't think college does a great deal to prepare anyone to be a systems administrator (well, except for the paperwork), but a degree can limit how high you can go in certain companies.
just a few things (Score:2, Informative)
man
cat
pipe "|"
more, less, and most
#!/bin/bash -- to test your ideas
export
echo
vim
lynx (to get to google to search for help)
xchat-text (to pester people in search of help)
and, of course, apt-get
I'd say with those (and fewer if you know something about something) you can figure out how to do just about any job (and then do it)
Re:just a few things (Score:4, Informative)
ls, cd, cp, mv, mkdir, rm - your basic file system commands. Learn them, love them, they are your lifeblood.
cat - cat will always be there, usually you will have either more or pg, I wouldn't bet on less or most. If you know how to redirect and use vi you can get by without a paging viewer just fine.
man - occasionally called something else (QNX calls it use). The ability to derive meaning from man files is extremely important.
|, > - If you don't know |, you don't know *nix, and > is a close second.
sh/csh - the vast majority of *nix default to some variant of sh, of which ksh is the most common. If you know sh you can use any of the variants (ksh, bash, etc) and learn the particulars as you go. There are rumors of *nices that default to csh, but I've never encountered one. Regardless, you should be familiar with it just in case.
vi - emacs is available for every *nix, but vi is included with every *nix. vim is the most popular vi variant because it has lots of nifty features, but don't count on having it. You should be able to navigate vi using only the keys you would find on a standard typewriter.
find - They say locate is easier, but I've never seen it on a non-Linux system.
Everything else you list is non-standard or part of something else on my list (except echo, which I don't consider essential). Yeah, you can probably install most of it on any *nix system one way or another, but don't expect it to be there by default.
Re:just a few things (Score:2)
Repeat that about 1000 times.
sh/csh - the vast majority of *nix default to some variant of sh, of which ksh is the most common. If you know sh you can use any of the variants (ksh, bash, etc) and learn the particulars as you go. There are rumors of *nices that default to csh, but I've never encountered one. Regardless, you should be familiar with it just in case.
The only thing you need to be able to do in csh is type "/bin/sh". Knowing sh is key, at least know how to do "for i in...do...done", "if..[..fi", and "case". Know how to use "["/"test".
Also get and know netcat.
find - They say locate is easier, but I've never seen it on a non-Linux system.
locate is far more limited, though much faster (it uses an index instead of an fs search). Know find, and know that it's different on non-GNU systems. "find" alone works with GNU find, but you'll want at least "find . -print" on other systems.
Probably make a
And _do_ learn to read and use man pages. You'll eventually get caught on a machine without the GNU tools available and need to figure out how the local "mount" works to get back to them.
And _don't_ alias rm to "rm -i" (or similar with cp, mv, etc). You'll wind up destroying files on a machine without the alias.
Sumner
experience in Linux and Solaris? (Score:4, Informative)
Generally, my experience is that shops hiring Unix people expect them to rival McGyver and connect e.g. the SHINY NEW network management system to the legacy systems THEMSELVES without shelling out money to integrators, using not much more than a few perl scripts and duct tape -- whereas those hiring Windows will more often than not, in my experience, expect their employees to oursource it to someone more qualified (mostly because the duct tape is a COM object with 5000 undocumented methods that no one really knows how to use; Yes, this is from experience).
Make sure you've mastered all of the standard Unix tools (cron, awk, perl, vi, and friends), Unix-Windows integration stuff (Samba, sun's SMB server whose name eludes me at the moment, OpenLDAP, Cygwin), _basic_ database management (unless you plan to become a DBA, you don't want more than basic but you DO need basic), mail configuration, and _basic_ system administration (unless you are planning to be a sysadmin, in which case basic is not sufficient). Most importantly, the unix philosophy that that everything is a file (or equivalent to it), and that most everything gets done by copying or piping data from one place to the other, possibly transforming it in the process with (ideally) a one-line simple, modular, command.
fscking Microsoft emacs (Score:5, Funny)
You must cleverly write "fsck" when you mean "fuck".
You need to be able to roll your eyes when someone says they use a Microsoft or Apple operating system, unless they are talking about a part of the OS that was originally implemented on a Unix OS, in which case you need to be able to smugly slip something into the conversation about how it was first invented in 1902 by RMS or ESR or TMBG.
Re:fscking Microsoft emacs (Score:1)
>
>
I _love_ They Might Be Giants -- and that was *before* I knew they were kernel hackers! (They're pretty energetic for old guys, too.)
Re:fscking Microsoft emacs (Score:1)
Here, hold this for a minute...
Re:Go get a job with the DoD... no exp. req. (Score:1)
Since you're just starting out... (Score:5, Informative)
I can't give you specifics, because they depend on the field you're looking to enter, and more importantly, the details of the job, which vary widely. I hope the general descriptions above help.
Contact me directly if you want to talk more.
-Erik
Systems Architect
Re:Since you're just starting out... (Score:5, Insightful)
Re:Since you're just starting out... (Score:2)
Every sys admin should know at least one programming language and one scripting language. Knowledge of sed/awk and shell scripting are nearly essential.
Aside from that, I remember something one of the admins where I work said when I asked what skills were required. A good understanding of the hardware (RAID in its many forms and incarnations especially) and a good understanding of UNIX in general. The particular OS isn't as important as knowing what the tools in UNIX are and how to find the info you need for that particular flavor.
Finally, speaking from my experience, know the details of any protocol you support. You should know TCP/IP intimately and be very familiar with tcpdump. If you are a mail admin, you had better be able to send e-mail using telnet and have it go through. If you are a web admin, be able to request web pages through telnet and understand the response completely. Remember, telnet can be your friend.
Nothing annoys me as a customer support person more than getting a call from an admin who hasn't done their own troubleshooting. If you have a deep understanding of how the stuff running on your system works and the protocols and services you are supporting, you should be able to do nearly all the troubleshooting yourself. By the time you call me, you should be able to tell me exactly what is happening and how you know that. Nothing annoys customer support more than teaching an admin to do their job.
Re:Since you're just starting out... (Score:1)
- t
Re:Since you're just starting out... (Score:2)
*ahem*
I started out in '93 when I got out of college as an SCM for a large company. I inherited their build-management tools, which were all in ksh. I learned it really quickly, and still those skills to this day (although more for personal use). After 1.5 years, they wanted me to move into a position with more potential. After all, SCM is SCM, once you get it running smoothly, there isn't much else to do.
This is where my *ahem* comes in. I moved into testing from SCM, and have been in QA ever since. Want to insult a good QA person? Refer to QA as an entry level position where you can move up to programmer. Part of the problem is that people see QA as entry level, and farm people off to other parts of the business. Gee, I wonder why our QA department has so much turnover and bugs get through? There are entry level positions in QA, but they aren't all like that. Many of the QA people I have worked with have been sharper and better programmers than some of the programmers I have worked with. If you are lucky, maybe you can move up from programmer to QA.
Re:Since you're just starting out... (Score:1)
Configuration Managment consists of source control, defect tracking, and change control. Depending on the complexity and sophistication of a particular enviornment, this can rapidly turn into a team. It also can go head to head with project and development managers who are cutting corners, hence it is not often a stepping stone to being a coding geek.
Quality Assurance acts as an oversight and approval group for design, development, testing, and delivery. Some companies require QA "buy in" for a proposal to go out the door. Some QA folks are involved from the beginnings to the end of a project, these folks are not going to be looking to become developers as they are off on another career track entirely and often quite far into it. Sometimes they get cut back to part of the lifecycle, sometimes they are involved more than the parent ever imagines. Check out ISO9001, CMM-SW, and Six Sigma and feel the process joy. These guys can also go toe to toe with project or development managers if they grow enough.
Testing consists of creating, validating, and dispensing requirements testing. Sometimes developers or QA analysts take on part of this burden. In that case the prestige of testing drops with the responsibillity. Testing is probably the folks the parent is slagging. If they need pull with project managers or development managers they often need to get the backing of CM or QA. That said, they can often turn into toolsmiths using automated testing tools, custom scripts, and all kinds of clever techniques.
Any of the poeple good at the above jobs can make your life painless and easy, those who are bad at it can make your life a living hell.
Re:Since you're just starting out... (Score:2)
My problem with that is that people consider it a move up to leave QA. I am going off of my own experiences here, and may have read too much into the original poster's comments. But I have seen it many times over the years.
And you are right, we can be extremely picky bastards, and can make life a living hell. :-)
Re:Since you're just starting out... (Score:1)
IME the "test group" has been something quite different from QA and CM. It may be because my experience largely comes from federal and millitary contract work. QA/CM are more like people side stepping from Project Managment or Business Development with the occasional process guru type rounding out the mix. The lower level folks in QA/CM also sometimes worked their way up from testing or doco.
More than anything else, the living hell bit for me is a matter of clarity. Someone can produce a massive lists of reasons something was rejected but that can be very useful. The magick is if they can clearly articulate why it is unacceptable, suggest an alternate approach that is acceptable, and remain consistant in their evaluations. When your lucky, you get all three, if get none of those qualities, welcome to hell.
BTW, anyone looking for a C++ guy recently recruited into the Java fold? Damn economy.
Re:Since you're just starting out... (Score:1)
vi (Score:3, Insightful)
It will teach you everything you need to know about why unix is the way it is...
It will break you of your bad microsoft habits.
Or it will break any desire you have to learn the rest of unix.
food for thought:
unix will never ask you, "are you sure?"
Unix assumes you never miss a keystroke, that you are perfect and know everything already.
vi is to ed as pi is to ln
Re:vi (Score:3, Insightful)
I would add, though, that vi is ubiquitous. Emacs is available for every *nix, vi is included with every *nix, and you will encounter situations where, for whatever reason, you won't be allowed to install the apps you would usually use.
Re:vi (Score:2)
I didn't want to learn vi, but I've been on some systems where it was the only editor installed. No Emacs, no Pico, just vi.
So, learn it now with no pressure. Don't wait to learn it while trying to edit a config file on a downed production server!
OT: your sig (Score:1, Funny)
Re:vi (Score:1)
Re:vi (Score:3, Insightful)
Definitely.
Use vi frequently for a while, that vi skill will pay off if you get dropped into ed. Learn enough ed to fix things up and get
Plus, it'll make the local MCSE's head explode if he sees you using it
Unless he remembers edlin from his DOS days
Sumner
Re:vi (Score:1)
Not really. edlin was actually much more user-friendly than ed.
Re:vi (Score:2)
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!!!!!!
Heh. [gnu.org]
Re:vi (Score:3, Funny)
Re:vi (Score:2)
I thought format c: ->press any key to continue was pretty funny
The KISS answer (Score:1)
Enoch
Impossible question (Score:3, Interesting)
There is no such thing as a universal skill-set, that will be good enough for any kind of job. You will have to be more specific about what kind of job you want, and work on that skill-set. This is usually simple if you are a nerd, because then you want to work with what you are interested, and refining those skills are you hobby anyway.
Finally, don't believe some of those job-ads will ever find their ideal candidate. Most of them just lists every three-letter-acronym they've heard about, and expect the ideal candidate to just walk in the door. It will never happen. Use common sense, and decide for yourself whether it would be worth applying for the job you are looking at.
If you are intelligent, knowledgeable, and a quick learner, you should get a job pretty soon, but the times have made it a lot worse for newly educated to land a good job.
"Must have" ability to acquire new skills (Score:2, Informative)
On a more practical level, learning how to configure and run the following applications, which you can do at home on a small Linux network, will give you a solid grounding in many Unix admin principles & relevant protocols even if you then take a job where some or all of them are irrelevant:
(Note: You will make many mistakes while setting these up. The methods and means by which you debug these errors will be the measure of you as a sysadmin. Research and use the tools you have well. Do not give in to the dark side, Luke... wait, wrong movie.)
Good luck with your well-chosen career.
Ade_
/
Don't forget... (Score:2, Funny)
Like my pappy always said. (Score:3, Funny)
YOU CAN SLIDE FURTHUR ON BULLSHIT, THAN YOU CAN ON CONCRETE
'nuff said.
BOFH (Score:1)
Learn the core skills, then go with your interests (Score:2)
In terms of core Unix skills, I'd suggest there are three: vi (the One True Text Editor), Bash (the One True Shell), and Perl (the One True not-just-a-scripting-Language).
After that, the best advice has to be go with what interests you: you'll learn faster and be more productive. If you really enjoy networking, you'll want to find out how to use all the tools around that subject. Same goes for programming, webservers, security, e-mail...whatever floats your boat. It's all good, and you will pick up whatever else you need along the way.
An understanding of basic commands (Score:2)
Here's a couple of commands to NEVER issue (unless a complete reinstall is in order):
rm -rf
dd if=/dev/random of=/dev/hda
Using either command willy-nilly without understanding what they are doing is a recipe for disaster.
Re:An understanding of basic commands (Score:1)
Say you try to
rm -rf
and you accidentally type
rm -rf / var/somedir
then you are in a world of hurt.
Programming side of things (Score:2)
Tats in addition to just about everything else listed here.
You must have (Score:1)
2) Ability to read manuals. Start by man man
Basic Required *NIX Skills (Score:1)
Do yourself and the sysadmins out there a favor (Score:1)
Don't become a UN*X developer until you've learned how to deal with the environment you'll be working in, be it Linux, Solaris, whatever. There are few things more irritating than a "Senior Developer" who doesn't know how to set his PATH, but expects root access to your machines so he can piddle with his applications.
unix skills for programmers (Score:1)
editors:
vi, emacs, and maybe know some ancient editor like 'ed'. pfft.
test manip:
perl, sed, awk - and more the merrier
core unix utilities:
grab UNIX in a nutshell by O'Reilly, you should know pretty much the whole book. typically, i use ls, touch, mkdir, rmdir, rm, echo, su, rlogin, source, grep, finger, who, ping, set
programmers utilities:
top, ldd, dbx, make
regular expressions (skill):
for any unix guru, you need to know your regular expressions. virtually all text tools allow you to use regex. so grab Mastering Regular Expressions by Oreilly
as i mentioned. this is not a complete list. get to know these, and just keep on expanding your knowledge! the good thing about unix is that there's about a 100 ways to do something and you just need to choose what's right for you.
Know these commands (Score:2)
# unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep