Basic Required UNIX Skills?

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

[Lando]

If you understand how to get around in UNIX, compile new packages, read (not necessarily write) shell script and have a basic understanding of Perl, that's about all you need.

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...

[.@.]

You might want to check out the Unix module to the SAGE certification [sagecert.org]. The cert was put together by sysadmins, and the junior level test is a good overview of the skills you'd need.

Re:Have a look at...

[tomhudson]

If you have to ask what skills you'll need, you're at least 3 years behind getting those skills and the necessary experience. So be prepared for a LONG haul. (And 3 years from now, when you're up to "par", the bar will have been moved again).

Sorry, but that's the way it is.

Re:Have a look at...

[Bald Wookie]

If you have to ask what skills you'll need, you're at least 3 years behind getting those skills and the necessary experience. So be prepared for a LONG haul.

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!

[eggstasy]

If you want to be a Linux / Unix system administrator, you first have to understand the vagueness of the term. An "administrator" is just someone who "administrates". You can either be behind a bleeding edge distributed system running on a huge server room crammed full of racked blades or you can get an easy job at a small company with 2 or 3 athlons that mostly take care of themselves. Any half-baked MCSE could do that.

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 /etc files and such things as the SNMP protocol, MIBs, and of course the latest, most buzzword-compliant, administration-facilitating apps...

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!

[AtariDatacenter]

Absolutely true. The Systems Administrator is the jack of all trades. You are expected to know a little about everything, and what you don't know, you better be willing to look up. As an SA, you get hit from every direction with every problem that is somewhat related to what you do.

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

[dalutong]

ls
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

[MrResistor]

That's a great list as long as you only plan to use Debian. Half of the things you list don't apply to the majority of the *nix world. Here is my short-list of apps you will always find:

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

[pthisis]

man - occasionally called something else (QNX calls it use). The ability to derive meaning from man files is extremely important.

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 /usr/gnu/bin on every new machine and put it first in your path (with GNU fileutils, textutils, find, etc). df, find, echo, and a ton of others will work differently between Unix variants and you'll make your life more consistent if you can use the same set of tools on all platforms.

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?

[Circuit Breaker]

You mention a fair amount of experience in Solaris, which is probably the most common "official" (in the trademark sense) Unix out there, and Linux, which is probably the most common "nonofficial" Unix out there. What kind of experience is it? If it's as a workstation user, through KDE, Gnome, CDE etc, then it might come in useful, but don't count it as fair.

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

[splattertrousers]

You have to be able to react in disgust when someone says they use { vi | emacs } and give a long list of why { emacs | vi } is far superior and anyone who uses { vi | emacs } is an idiot.

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

[himself]

>
> ...a part of the OS that was originally implemented...in 1902 by RMS or ESR or TMBG.
>
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

[back_pages]

Don't leave the Bastard Operator from Hell out of this. You must have a copy, electronic or print, always close at hand to guide you through tougher situations you encounter in your career.

Here, hold this for a minute...

Re:Go get a job with the DoD... no exp. req.

[Satanboy]

tell him to rm -r * at /

Since you're just starting out...

[trims]

I'm going to give you a short summary of the various computer-related professions for someone looking for entry-level work in the UNIX field:

• Systems Administrator - this is probably what you're thinking of right now. This entails a huge variety of skills, from installing hardware and basic system OS, managing system configurations and upgrades, user management, system troubleshooting, etc. Basically, you're responsible for making sure that the computer systems (usually servers, but sometimes desktops) are up, available, and working properly, and that everyone can access the information on them as appropriate. A little bit of DBA and programmer skills thrown in is a good idea too.
• Network Administrator is related to SysAdmins, and often shares similar workload and skills. However, the emphasis is on networks - design, troubleshooting, maintaining and configuring network devices (switches, routers, NAT/firewall devices, et al). Typically, both LAN and WAN knowledge is required, and a certificate (or equivalent experience/knowledge) in CCNP is a good idea.
• Systems Programmer (including Embedded Programmer) these are folks who write systems-level code. That is, drivers, kernel modules, low-level libraries, and in the case of Embedded Programmers, work on devices which aren't quite what most peope think of as a computer (i.e. firewall devices, etc.) Typically, you'll need some very low-level understanding of how software interfaces with hardware, a good bit of hardware knowledge, and primarily C and assembly programming experience. A very good grasp of algorithms is also typically important, as the code produces generally needs to be as efficient and compact as possible.
• Application Programmer write user-land programs (word processors, order processing/entry systems, inventory tracking systems, etc). This is what people generally think of when they say "programmer". Java and C++ are the dominant languages here. These days, a good understanding of SQL is a good idea too, since most custom apps talk to a DB.
• Webmaster is more than the stupid morons that have been doing it for the last 3 years. It combines a bit of graphic artist with a modest programming ability (primarily in scripting languages) and a dash of SysAdmin thrown in. In general, a good webmaster has site management tools for deployment and tracking of the website, is concerned with performance and maintainability, and also has a hand in the design and coding of section of the site. Perl, Python, PHP, JavaScript, and Java (for JSP) are good languages to know.
• Toolsmith is not terribly well known. However, most large organizations need someone like this, which is typically a junior programmer or junior sysadmin detailed to do the work. It involves building common tools for everyone else to use. Typically, this include downloading, compiling, deploying, and maintaining common OSS tools (e.g. keeping a working Perl setup for 6 CPU/OS architectures with all the needed modules). It often also includes work with all the other professions here to find out what they need to do their job, and create it. The person here typically has lots of scripting experience in 4 or 5 script languages, plus decent coding experience in 2 or so "real" lanuages (C, C++, Java, et al), and understands how to write small programs quickly. In essence, the Toolsmith is the person responsible for producing the company's Swiss Army Knife collection of programs.
• QA / SCM is Quality Assurance (e.g. Testing) and Software Configuration Management. Being a Sr. QA person is a real good way to move into either Toolsmith or Application Programmer, since you gain a whole lot of knowledge about how things work (otherwise, how are you to test it correctly?), and get good at automating test stuff. SCM is often a gateway to SysAdmin, but is different, in that it really is concerned with change management, deployments, and usually builds. Both positions require a good smattering of script language knowledge, some programming experience (enough to read other people's code and tell if it's doing the Right Thing, but not necessarily able to write it from scratch), and a good head for organization.
• DBA isn't really in this category, but I thought I'd mention it anyway. Most DBAs have a bit of SysAdmin experience on the platform that their DB runs on, but the rest of their knowledge is tied up in the very different field of SQL and Database software.

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...

[mosch]

I'd like to add some more concrete things to the sysadmin skills:

• be able to use vi. it's the lingua franca, and it'll be on every unix box.
• be able to use fsck in a manner that's not equivalent to just running fsck -y
• understand how RAID is implemented on your platforms. for solaris, you should know how to use veritas, and you shouldn't get confused by terms like disks, subdisks, and plexes
• know how to run extended diagnostics on those sun boxes
• know how to trace a process and be able to quickly parse the output
• know enough networking to be able to accurately tell which machine is causing the problem in a multi-machine clusterfuck
• know how not to kill your boss when he tells you 'yah, that stuff I had you do last week? blow all that work away and do it my way.'
• know not to be a dick about GPL v BSD or open source versus closed
• learn to document things. system setups, network setups, you name it, you'll need it at some point.
• learn how to use a task list. you'll have shitloads of things to do, and if you're like me, you'll forget something if you don't write it down
• be competent in your use of MS Office. Yes MS is evil, it's also the way people in the business world communicate. Deal with it.
• Know how to tell if a process is I/O bound, memory bound, or CPU bound.
• Know where to look for performance tweaks, even if you don't know them by heart

I'd list more, but I'm already getting quite rambly.

Re:Since you're just starting out...

[freakinPsycho]

The above two posts are absolutely true. I think they pretty much cover everything except programming.

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...

[thempstead]

Couple of things I would add to your list:

• learn how to use common backup and restore utilities for the platform you are going to administer .... as you know you are going to need them.
  
• learn how to communicate successfully face to face .... the idea of the admin hidden away in the basement is long gone.
  

- t

Re:Since you're just starting out...

[gosand]

QA / SCM is Quality Assurance (e.g. Testing) and Software Configuration Management. Being a Sr. QA person is a real good way to move into either Toolsmith or Application Programmer, since you gain a whole lot of knowledge about how things work (otherwise, how are you to test it correctly?), and get good at automating test stuff. SCM is often a gateway to SysAdmin, but is different, in that it really is concerned with change management, deployments, and usually builds. Both positions require a good smattering of script language knowledge

*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...

[broody]

I think you missed out on the core problem with the parent. Configuration Management, Testing, and Qaulity Assurance are three job descriptions not one. Sometimes the same body fills all three roles but that doesn't make them the same job.

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...

[gosand]

Thanks for the descriptions, they were pretty good. But I have done all three of these jobs - SCM and system testing at Motorola (you can't get much more anal than that, unless you talk military or gov), a combo QA/Testing role at a small company, and now a testing/QA role leaning more towards QA. I am aware of the differences. I am also aware that a lot of people at companies consider "the test group" to be a stepping stone where you can "teach people the ropes" of your product. I have seen many people come and go, where they "start out" in QA to get a good idea of how things work, then move UP to development.

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...

[broody]

Interesting.

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...

[theoldwizard]

trims did a great summary of different jobs in the Unix field. After 26 years in the computer biz (hence the nickname) I'll throw in some comments. Different employers want different (combinations) of talents. Big companies (like where I work) have things very "compartmentalized". I'm not allowed to touch any network gear and (thank God) I don't have to do any WinDoz support. I do some VMS support, but that is where I cut my teeth. We have a couple of app programmers, a Webmaster, a SCM guru and a QA "jack-of-all-trades" guy. My "sidekick" and I admin about 70 boxes, running 2 different flavors of Unix, in 3 different buildings, in 2 different cities (10 miles apart). We are responsible for installing/tuning/cutomizing the OS and GUI (more later). We also "build" gnu/public domain apps like perl and some of its infinite modules, a2ps, lsof, emacs, nedit, etc, etc. We also install all commercial apps. Most small companies want you to "wear multiple hats", or maybe even all the hats that trim mentioned ! Breadth of knowledge is frequently more important than depth. Unfortunately, the School of Hard Knocks is frequently the best instructor. Unix never "lives" alone these days. Either you have WinDoz or IBM Maninframes or VMS or some "odd" flavor (QNX, AIX) that you have to co-exist with. You'll have to learn enough about the other guys jobs to talk to them. The same applies with networking. From a sys admin perspective the most difficult thing I had to "grasp" was automount. KISS applies here, especially if you have an even moderate number of systems. At my site we basically have one "big" machine NFS serving all the rest. Easy to understand and back up. Anyone still using fsck on Solaris (8 and up) needs to do a man mount_ufs and check the logging option. I'm not knowledable of Linux, but I think any "modern" Unix should have a log based file system (which means you never have to fsck again). Working in "different" Unix environments at the same time is a pain. Solaris will tell you that System V is the only way and then hide all of their XPG4 compliant stuff in other directories. Carefull PATHing kept my user base (some who still can't spell Unix) from string me up. I hate the SVID printing so much (how many times has Sun re-written it) that we have built our own BSD printing subsystem on Solaris (MUCH easier to admin). Lastly, I would like to kill the folks who invented CDE. It is a pain to admin/configure on a large scale. Give me a simple "laucher" and a Motif window manager and I'm happy. Very last. Know enough hardware that you can talk to your support folks. Enough or I'll start talking about 36 bit computing !!!

vi

[Perdo]

Learn vi.

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

[MrResistor]

Agreed.

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

[dieMSdie]

Also agreed.

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

[Anonymous Coward]

Now, I'm confused... e^{j pi) = -1, therefore j pi = ln(-1), therefore jvi = ed(-1), but my man pages don't have a -1 section.

Re:vi

[Jonathan the Nerd]

Also, learn ed. You may need it someday. On my system (FreeBSD 4.6), ed is installed as /bin/ed, and vi is installed as /usr/bin/vi. If something disastrous happens, and /usr will no longer mount, I have to be able to use ed. (Plus, it'll make the local MCSE's head explode if he sees you using it.)

Re:vi

[pthisis]

Also, learn ed. You may need it someday. On my system (FreeBSD 4.6), ed is installed as /bin/ed, and vi is installed as /usr/bin/vi

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 /usr/bin mounted. And keep a statically linked copy of your favorite small(ish) editor and of sash (and scp/ftp/wget/netcat if you can swing it) on the root partition --libc.so _will_ eventually die on one of your machines, and having sash and vi available for recovery will make you much, much happier.

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

[Rysc]

> Unless he remembers edlin from his DOS days

Not really. edlin was actually much more user-friendly than ed.

Re:vi

[elemental23]

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

[Tim Macinta]

food for thought:

unix will never ask you, "are you sure?"

Are you sure about that? [sourceforge.net]

Re:vi

[budgenator]

>unix will never ask you, "are you sure?"
I thought format c: ->press any key to continue was pretty funny

The KISS answer

[Enoch]

• Good problem solving techniques
• A proclivity for reading documentation and surfing archived email lists in the wee hours
• patience
• perseverance

After you have achieved such, your system administrative abitities will be tripled.

Enoch

Impossible question

[joto]

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

[ader]

There are no "must-haves" outside of broad topics like scripting & TCP/IP, because the required skills vary from job to job depending on what a particular site is using. Hence the main soft skill you "must have" is adaptability - the key to which is the ability to locate, read and understand documentation (RTFM). The lack of this ability is the main failing I find in weaker admins.

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:

• DNS
  
• Firewalling (iptables) w/ NAT
  
• NFS & autofs
  
• Apache
  
• Sendmail
  
• MySQL or similar RDBMS
  
• Optionally: NIS (popular in the Sun world, but LDAP may be more forward-looking); NTP; Samba; INN
  

(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...

[orbit222]

Start growing the beard now!

Like my pappy always said.

[His name cannot be s]

The Most important skill to have, especially in an IT related field:

YOU CAN SLIDE FURTHUR ON BULLSHIT, THAN YOU CAN ON CONCRETE

'nuff said.

BOFH

[spoonist]

Everything I learned about getting around OSes, I learned here [ntk.net].

Learn the core skills, then go with your interests

[Kirruth]

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

[Webmoth]

Every *nix administrator needs a solid understanding of basic shell commands. Probably the two most important to completely understand are rm and dd because they are the most dangerous.

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

[zfalcon]

rm -rf is generally dangerous.

Say you try to
rm -rf /var/somedir
and you accidentally type
rm -rf / var/somedir
then you are in a world of hurt.

Programming side of things

[thogard]

You need to be able to grok everything in "The Unix Programming Environment [bell-labs.com]" by Kernighan & Pike.

Tats in addition to just about everything else listed here.

You must have

[tawaste]

1) Brains faster than hands. You don't have to be absolutely fast on thinking, but you must be able to think before doing.

2) Ability to read manuals. Start by man man

Basic Required *NIX Skills

[everfoo]

Being a proficient *NIX administrator really only requires a desire to learn and a modicum of common sense. *NIX isn't rocket science, although when compiling a new kernel, I sometimes wish I had Robert Goddard's brains...

Do yourself and the sysadmins out there a favor

[Shadestalker]

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

[tkny]

this is in no way a complete list, but here are some basic tools that you should/need-to know... even if it's basic knowledge.

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

[cr@ckwhore]

# unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep