What Should be Included in a Linux Crash Course? 110
Olivier Van Acker asks: "Since I started working at my current job a year ago I've installed on average one (Gentoo) Linux machine a month. Included are developer desktop machines, development servers, router/firewall, web servers, video server, MPEG encoders, etc. (It's a platform for interactive television). Since I'm the only one who is able to maintain them I want to train two of my colleagues. I've got three days dedicated time, three computers to work with and they are both Linux/Open source newbies (A technician and a programmer). What should this crash course include, what is the best learning method and what resources are available online?"
"My background: I'm a programmer, a systems engineer and I used to give IT training. I have been using Unix-based operating systems since 1995.
My list so far:
Linux system Installation
Software installation
General Linux system administration
Network administration
Web server configuration
Database administration
Video server administration
History of Unix and Linux
Philosophy of open source software"
Skip History and Philosophy (Score:5, Insightful)
And I would add a significant period of time covering the layout of the Linux filesystem--nothing is worse than having a bunch of novices with root access who drop random files wherever they damn well please.
but kill a few GPL myths along the way (Score:2, Interesting)
That said, a few words here and there to put to rest some of the myths about the GPL can be quite useful. Also, sometimes a little history is needed to put things in context. Just a few words, though.
Re:Skip History and Philosophy (Score:5, Insightful)
I agree that this isn't the place to indoctrinate them on the details of acceptable language as defined by Richard Stallman. ("When someone refers to the 'Linux operating system', look blankly at them and pretend you have no idea what they're talking about.") But it certainly is worthwhile to make it clear to them that they can perform multiple installs from the same disk, and generally get the concept of freely licensed software across to them.
Same with history -- don't get them bogged down in the minutiae of SCO charges and counter-charges, but do explain that almost all Linux software ("Linux...software? I don't know what you mean. Perhaps you're thinking of GNU/Linux?") will compile and run on other Unixes, and spend a minute or two talking about how other Unixes are similar to and different from Linux.
Re:Skip History and Philosophy (Score:1, Insightful)
Re:Skip History and Philosophy (Score:3, Insightful)
Re:Skip History and Philosophy (Score:1, Insightful)
No begging the question there! Here's an equally biased statement taking the opposite stand:
"One fully-integrated program works better than lots of small badly-named programs that are strung together to crudely approximate the desired function."
Re:Skip History and Philosophy (Score:2)
No begging the question there! Here's an equally biased statement taking the opposite stand:
"One fully-integrated program works better than lots of small badly-named programs that are strung together to crudely approximate the desired function."
The philosophy doesn't have to be right; it just has to be THERE, which it most certainly is in Linux. The general statement that most Linux (or Unix) programs are built upon the idea t
Throw them into the deep end (Score:4, Funny)
Make them bring their own computers to work, confiscate their hard drives, give them an empty hard drive and a slackware install CD. Tell them they'll get their hard drives back in a week.
They'll figure it out if they like their pr0n enough...
Re:Throw them into the deep end (Score:2)
they'll get to their porn sure, but haven't you ever been in shit with a totally 'wrong' way configured linux box, with stuff pushed into some startupscripts etc?
(he should skip the history/philosophy part though, though he should mention that without support most things are free)
Re:Throw them into the deep end (Score:3, Funny)
Heh. A Linux crash, of course. ;-)
Re:Throw them into the deep end (Score:2)
Re:Throw them into the deep end (Score:1)
Re:Throw them into the deep end (Score:2)
Better Yet (Score:2)
try another distro... (Score:4, Funny)
In a crash course? (Score:5, Funny)
Re:In a crash course? (Score:3, Insightful)
This should definitely be included:
:(){ :|:& };:
Kudos, this is the coolest fork bomb I've ever seen :-)
Re:In a crash course? (Score:2, Insightful)
You should also teach them that they shouldn't believe everything they read on
The safe way to see this fork bomb in action is to type it into a Cygwin shell on a W
Re:In a crash course? (Score:1)
change the : to . and thats it.
good to add that function to someones bashrc if they leave their terminal open. They are much more likely to unsuspectingly use . than : at the command
line (why would you NOP in an interactive shell?)
Anyway I first saw it in someones
My poor 486dx was never quite the same agai
So what DOES it do??? (Score:1)
I'm sure it's all fine and dandy that you all come with little do's and don'ts, but a few of us would like to know what that little gimmick actually does, *in plain english*.
My "shell-fu" is practically nonexistent, and I don't have cygwin (the app, the source, the need or the skill).
Please, could someone post a two-liner about what the devil that bunch of parentheses do, and why it would be dangerous to do the obvious and copy/paste it?
Thanks.....
Re:So what DOES it do??? (Score:1)
http://www.google.com/search?q=%22fork+bomb%22 [google.com]
Re:So what DOES it do??? (Score:1)
Neither -- the dictionaries I frequent were unfamiliar with this term, and the web sites I dug up were rather much unrelated (at least it seemed so, but then I didn't really know what I was looking for). Have _you_ tried to search for ":(){
Alas, I still was not able to decipher what the ":(){
Re:So what DOES it do??? (Score:1)
FYI -- your google-fu is nonexistent. I set up a google search for you for "fork bomb". If you had actually done that search and followed a link or two, you would have found this: http://www.madisonlinux.org/pipermail/madlug/2003- October/007113.html [madisonlinux.org].
What's more, you would have had to read some stuff to find it, which would have made you a bit more intelligent in the process.
The next time you have a specific question like this, you shouldn't doubt for a second that you can find the answer onli
Re:In a crash course? (Score:1)
For starters... (Score:4, Insightful)
Microsoft Office : OpenOffice.org
Internet Explorer : Firefox/Mozilla
PhotoShop : GIMP
Re:For starters... (Score:1, Insightful)
It's funny that you assume that someone unfamiliar with Linux must know nothing about security. It's possible to not have used Linux but still choose good passwords or know what a command prompt is.
Re:For starters... (Score:2)
Teach them how to learn (Score:4, Insightful)
Re:Teach them how to learn (Score:3, Insightful)
Absolutely!
You can't teach everything they need to know, and certainly not in that time period.
Give them a good list of resources for Linux help. Man pages are great, but beginners may need a little more hand-holding than that.
Good forums can be incredibly helpful. Don't forget an introduction to the shell and basic linux terminology. Nothing is worse than needing to know HOW to do something but having no clue waht to google for!
From my experience... (Score:5, Insightful)
... the single most important thing to explain in depth is the different filesystem scheme. Almost all users are used to the MicroSoft scheme with drives and it's one of the most important things to explain that in Linux and other UNIX systems there is no such thing as a drive as everything is exposed as one directory tree.
This raises such questions as But how am I supposed to access my CD if I can't change the drive ? and other confusions. So pay attention that you explain how different media are mounted into the tree and what the big advantages of a single tree are (especially when combined with symlinks -> you can move tree parts onto different media/another hard disk and mount them somewhere and link to it, etc. pp.)
Speaking of it, symlinks are also something new that no Windows user knows of. Many people think Windows desktop links are like symlinks but as we all know, they are not even close ;-) Same for NTFS junctions: they are simply hardlinks to directories, not symlinks. Explain the use of symlinks, e.g. when moving a tree part somewhere else and you leave a symlink at the old place pointing to the new place, or when installing different versions of a software and switching between them by changing the symlink.
Of course the standard UNIX filesystem scheme with /{bin,lib,sbin}, /usr/{bin,lib,sbin}, /usr/local/{bin,lib,sbin}, /etc and /opt should be explained as well.
Once your people understand this piece of Linux/UNIX the rest is a piece of cake to teach, IMHO.
Re:From my experience... (Score:2)
It helps, but I have to drill into their head file locations every lesson it seems. At least until I teach them locate.
Re:From my experience... (Score:2)
This is easy. Just ignore the horribly confused FHS and follow traditional Unix dictums. As the local admin you should NEVER be dumping stuff into
Re:From my experience... (Score:3, Insightful)
Oh, I couldn't agree more...so, um, care to explain a little? I'm relatively new to Linux, and this was one of the things that I've never found a good explanation of. I don't admin anything; I just installed and tried some distros on a desktop at home. What I didn't know was where to put stuff when I would download and want to install something. I
Re:From my experience... (Score:3, Informative)
The FHS explains the why of the distribution of the various files tossed around the system by various packages.
As for the where were the files dumped, each package manager has a command to show you that.
rpm -ql package-name will list the files installed via the rpm for package-name
Re:From my experience... (Score:4, Informative)
Well, it's quite simple: programs go into bin directories, programs only intended for the superuser into sbin and libraries into lib.
Then you have the different levels: /, /usr and /usr/local.
Things in the top-level (/{bin,lib,sbin}) are the most elemental tools/libraries needed to start the system and rescue a broken system (/usr might not yet be mounted).
The /usr level is for programs/tools for normal runtime. Most tools are found in this level. And /usr/local is for "third-party" programs that you've installed yourself, mostly when compiled from source.
The bin and lib directories can also be found in other directories as well: the most notable is /usr/X11R6 which is such a vital and big software package that it is allowed to break the rule that additional packages should live in /opt. And if you have a look at your /opt/kde3 directory you'll find a bin and lib as well.
There is another directory that can be found in many directories that have a bin and lib directory: the share directory, which holds data files for programs. You can find it e.g. in /usr, /usr/local, /usr/X11R6 and /opt/kde3.
Whew... I hope it's of use for you :-)
Re:From my experience... (Score:2)
My Crash Course Syllabus (Score:5, Insightful)
The first thing I do is have them install Linux on a desktop -- SUSE in my case at the moment. While installing, I give them a bit of the history and philosophy, since it really helps in understanding why there are 2,000 packages to choose from, and why everything is modular and named weirdly (why do you have Linux, X11, Sawfish, Gnome, *AND* KDE?).
Then I get them to learn how to make it a usable desktop machine for regular things (browsing, e-mail). After teaching them how to patch the machine, I start giving them administrative tasks.
I mostly needed a backup for doing desktop support, as we've got about 50 unix servers and 100 unix desktops. Most of my training curriculum is tuned to giving them the ability to help other people with their mostly desktop problems, but perhaps you could make use of my Linux Training Syllabus [indiana.edu] anyways. It's setup as two 60-90 minute sessions a week, with the expectation that after 6 weeks they can handle all the normal problems that come up. It's been pretty successful so far, and I've got another coworker starting it in a few weeks.
The hardest part for me was determining an order of lessons. For instance, I decided on teaching them how to customize their environment last. I need them to be able to handle whatever environment gets thrown at them without customization, and it's not crucial for them to debug problems. It is however, a great timesaver if you've really tuned your environment for you.
I suppose the most important lesson of all is teaching them to use manpages and google to solve most of their problems. It annoys them when you don't give them a straight answer on how to fix something, but it really does make them more independent.
Re:My Crash Course Syllabus (Score:5, Insightful)
In everything you do, you should try to relate it to something familiar to the user. If the user knows Windows, relate everything you can to them. Relate how
not enough anyhow (Score:1, Interesting)
Try to teach them cool things so they'll be happy and curious enough to dig more into it later. If it's a pain for them, they'll quickly forget it... And i'd stick at the console, show them how X works and what you can do
Re:not enough anyhow (Score:3, Informative)
In my experience, they'll ask themselves after one hour how they have been able to live without such editing capabilities (most windows persons don't use editing shortcuts, even when they exists.
Re:not enough anyhow (Score:2)
End of line : C-e
Preceding word: M-b
Next word: M-c
delete word after cursor: M-d
delete word before cursor: M-backspace
kill (end of) line: C-k
paste (previously killed ):C-y Reverse search : C-r, then type the first letters of a command you previously entered, enter to redo command, C-c to quit
Others: M-u: capitalize word after cursor
M-l : decapitalize word M-c : capitalize letter after cursor
C-t: invert lette
Re:not enough anyhow (Score:2)
I learnt the basics in a weekend on a P2 450, (CLI, Gnome, KDE), you could learn to work on a command line somewhat in 3 days.
Teach scripting later.
Re:Let them train themselves... (Score:2)
Automated installs, packaging managers (Score:3, Interesting)
Either way, show them how to make a kickstart disk [redhat.com] or other ways [uni-koeln.de] to automate a custom installation.
Packaging managers are a must. Whether it's dpkg or rpm or yast, show them the different tricks and options. Also, if show how to roll a custom package, but choose one of the simpler ones.
For servers, cover iptables, tcpwrappers, inetd/xinetd, sshd, sudo and apache. System log file analysis is another must.
For desktop machines, cover KDE/Fluxbox/Gnome. Kiosk mode might be useful for some parts of your work environment.
Re:Automated installs, packaging managers (Score:1)
He uses gentoo. No need to learn tricks when you have emerge.
The most important command (Score:2, Insightful)
If they know how to find information they can learn and solve problems without you.
Re:The most important command (Score:2)
Here's an example, I want to use tar to gzip a directory and put it in a file. Using the man page to find the syntax involves scrolling through 30 pages of worthless shit before finding the examples, and THEN you can work out what to do. By contrast, I can get the answer with Google using "I'm Feeling Lucky" in like a 10th the time.
You can't search man files like yo
Re:The most important command (Score:2)
An example of a process involving more than one command being documented in a man page:
$ PAGER='grep rsh' man xauth
Reformatting xauth(1x), please wait...
% xauth extract - $DISPLAY | rsh otherhost xauth merge -
Re:The most important command (Score:2)
to appear on the screen is as good as the help in MacOS X or Windows, you're failing ... utterly.
Re:The most important command (Score:2)
Re:The most important command (Score:2)
To learn how to search man pages, type "man more" if your pager is more or "man less" if your pager is less. And unlike Windows Help and OS X Help files you can use regular expressions. There's also no gui overhead - very nic
Re:The most important command (Score:2)
The first time someone told you "everything is a file" when describing Unix it probably sounded goofy/confusing. But after you understand what that means the power and control it gives you is awesome. man pages are like th
Re:The most important command (Score:1)
Man pages can be a little dry reading, but all the information is there for a reason.
If you can't read a few screens of text to get your question answered, you might as well unplug the computer right now and use it as a doorstop...
Re:The MORE important command (Score:1)
I can type "man thingamabob" to find out how something works, but from there I don't know how to look for the next thing. And, how the devil do you scroll up?
No, the most important comment to go with the "man" command is the information that a simple single "Q" gets out out of
Don't forget to get them a book (Score:3, Informative)
A great book to start with is Linux Administration: A Beginners Guide. Good stuff. Especially helpful for administrators moving from Windows power user to Linux administrator.
Agreed: Get "Linux Administration" by Graham&S (Score:1)
I concur. Helped me greatly, even just admin'ing my own machine. Has questions at the end of each chapter. (Better than O'Reilly's "Running Linux")
Written by Steven Graham & Steve Shah; published by McGraw-Hill Osborne (www.osborne.com). ISBN 0-07-222562-9
This is an admin course: Hardening and backups. (Score:5, Informative)
They should know how to protect the system from disaster and attack. Tips on hardening should include:
- Hardening a new install with the Bastille Linux [bastille-linux.org] scripts. What these are and what they do.
- IP tables configuration [netfilter.org]. What IP tables is, why it's important, and how to configure it. This may or may not be in relation to Bastille.
- Tripwire [tripwire.org]. A PITA to configure, but *really* useful in knowing what is happening on the server.
- Kernel options. Do you need loadable modules on a production server? Disable them if not. Do you need USB or CDROM access? Remove them from the kernel. If it's not needed, don't include it.
- Kernel upgrades. When and why. Just because the latest 2.6.87 kernel has been released is no reason to put it in. However, if there is a remote root 'sploit posted to Bugtraq for the current kernel, everything else is a lower priority.
- BugTraq [securityfocus.com] and other security lists. What they are and why they should be monitored.
- Application security patches. Like kernel upgrades, guidelines on why and when production apps should or should not (or must) be upgraded.
Also important would be a good understanding of how to set up a backup regime. This should include topics like:- tar [gnu.org], and it's more esoteric options, such as multi-volume tarfiles, dump levels, etc.
- Rotation schemes [vic.edu.au]. What is Grandfather, Father, Son? Why is it important to do this? What is the difference between a differential and an incremental backup?
- Backup media. Redundant hard drive? CDR? DVD-R? Tape? Onsite vs offsite?
- Recovery procedures. Ok, you've got a backup. What do you do if you need it? You have tested the tapes, right?
:)
Some thought on a disaster plan might be a good idea too.grnbrg.
The most important thing is to... (Score:5, Insightful)
You know you should
some handy things: (Score:3, Insightful)
the basics of installing new programs for whatever distro you train them on
bash / other shell usage
And the most important to any linux user:
Nethack. How to move about and kill grid bugs, stairs, not to attack dragons, etc...
Crash (Score:4, Funny)
Kernel Panic &
Segmentation Fault
from my own gentoo experience (Score:1)
-- learn what to do when you reboot and your ReiserFS comes up read only
-- research hardware problems (yes, of course i knew i had to unplug my PCMCIA NICs, load the appropriate modules, and then repeat the procedure later...)
not that i'm bitter.... had to go back to Win2k due to some work arriving in but i will return gentoo and dammit you will work!!!
*grovelling* tho if someone could explain the filesystem problem for me that would be great...
Re:from my own gentoo experience (Score:1)
Documentation (Score:3, Interesting)
I don't mean creating and enforcing ridgid doctrine, though.
Here's an example -- if you've never done this or need a refresher;
The tool(s) used are up to the admin and training in them should be direct and simple. The people who are new to the tools should be given resources (books, notes, and someone experienced to talk to). That the tasks are being performed at all should be easily verifiable. Keep it simple as possible so that it actually gets done, though have it just formal enough that someone else can figure out what should be done -- not necessarily be told how they should do the job.
From experience (Score:1)
A table of equivalents, replacements .... (Score:1)
http://www.google.ca/search?hl=en&ie=UTF-8&q=progr am+equivalents+linux+windows&btnG=Google+Search&me ta=/ [google.ca]
After all, it is mostly about the applications right?
Shell scripts and booting (Score:3, Informative)
In addition to the other good stuff that has been mentioned (file system layout, key config files, etc.), I think a very important thing for anyone who needs to administer Linux/Unix systems to understand is a bit of shell scripting. They don't have to be able to write scripts, but being able to read them is immensely valuable, because so much of how the system works is held together by script glue.
And there's one particular part of the system that is both very important and almost entirely scripted: The boot process.
It's hard to overestimate the value of understanding the boot process. Nearly any kind of system problem can be traced down by first figuring out where the process in question got started, how, and with what parameters. Don't know what files you use on this system to configure networking? Look at the boot scripts. Don't know where X server messages get logged to? Look at the boot scripts. Don't know what parameters are used to start apache? Look at the boot scripts. And so on.
In addition to being a basic troubleshooting tool, understanding the init process does more than anything else to "de-magick" the system. When you see how simple the boot process is, and how everything gets started up, you suddenly understand that there is no magic here; everything is out in the open, visible and understandable. In my experience this knowledge does more to build confidence in new Linux admins than anything else, because it lets them know that whatever goes wrong, they can dig down and find out why. To Windows users/admins, this is a revelation of huge proportions, because they're so used to thinking that stuff just happens magically and they have no real visibility into it or control over it.
I think building their confidence is important, also. Unless they're really gung-ho about the whole idea, they're probably going to be frustrated from time to time by the fact that this environment is not what they're used to. Giving them the understanding that they have the tools to figure out and fix just about anything should go a long way to compensating for the discomfort of a different environment.
Re:Shell scripts and booting (Score:2)
As a Windows admin with complete and utter control and understanding of everything my box does, and why, I will indeed grant you that Windows does *allow* you to believe it's all magic.
It does not, however, keep you out of the nitty-gritty if you're willing to go looking for it. Tools to see startup items and their properties, tools to directly manipulate the LDAP database and XML schema of an AD domain, all exist.
If anything, MS admins have to be better problem solvers than Linux admins --
Re:Shell scripts and booting (Score:2)
I resent that.
Chill, man.
As a Windows admin with complete and utter control and understanding of everything my box does, and why, I will indeed grant you that Windows does *allow* you to believe it's all magic. It does not, however, keep you out of the nitty-gritty if you're willing to go looking for it.
I'll grant you that you have a lot more understanding and control than most Windows users or even most Windows admins, but Unix takes this to a much higher level because it was designed to be open
Basic Linux Training (Score:2, Interesting)
Teach them:
File system stuff- where, how- make a new directory, find a file, check permissions
- permissions- look at and change
-mounting devices (start above with 'Linux sees everything as a file system'), unmounting devices, names of devices
- text editors. vi, emacs, whatever. start from the gui of your choice and show them the equivalent of notepad (Kate, g
The most important thing can't be taught (Score:3, Interesting)
As a sysadmin I've had the opportunity to work with, or closely observe the work of, about 30 other admins. The ones who do well are those that have a healthy respect for the system. I try to keep my setups as default as possible. Any change must have a good reason. This keeps things more stable (defaults are better tested) and easier for my replacement. The "problem" admins are the ones that can't resist tweaking everything. Yes, they might get a 1% performance boost, but they're also more likely to generate system instability.
In terms of priorities, there are a few basic rules: #1 priority is security, #2 is stability, and #3 is performance or other user requirements.
Finally, there's the concept of structuring the environment. Think about dependencies. Try to consolidate services so there's a single point of failure. This means not having multiple fileservers with crossmounts. Running a single OS/distribution will make your life a lot easier, assuming your shop doesn't require the diversity.
As others have said, there's a lot you can teach them about how to read manpages and use google, but without the basic philosophy of how to be an admin, all their knowledge will probably just lead them to manage unstable systems.
Re:The most important thing can't be taught (Score:2)
Re:The most important thing can't be taught (Score:2)
I think you're confusing security with ability to stay up during a crisis (stability). Yes, if you're running a webserver farm, it's good to have a spread of OSes to keep them from all dying from the same thing. But that's a stability issue, as the concern is keeping them online, not keeping intruders out.
The more common case is to have a few machines that users log in to. If those machines are all the sam
Learn to learn (Score:4, Insightful)
make a wiki (Score:3, Insightful)
example configs with thourough documentation would be most edifying, of course. a friend of mine has a FreeBSD wiki (still a work in progress, i'm sure that when there's more content he'll want to make it more well-known, but for now, no link) and it's been quite handy and I've seen how useful it is to find something right away with no-nonsense answers.
Linux Crash Course (Score:2)
Infrastructure configuration mangement. (Score:2)
Tarballs and building from source. (Score:2, Insightful)
Furthermore you should give them some tips on troubleshooting. Ie searching google and IRC for tips and advice. Knowing where to turn to for help is _very_ important. Also make them read he "How to ask questions" guide. This way you won't have them suffer humiliation fr
o'reilly (Score:2)
to encourage them to learn, show them the intro man pages - man 1 intro; man 2 intro; man 3 intro; etc.
Re:o'reilly- (still availabel and GREAT) (Score:1)
Essential System administration is in fact still availabel, recently (2003?) updated even...and its a *great* resource, very thorough but I wouldn't recemmend it to just anyone. its very dense and dry, and it goes into pretty good detail on a lot of things.
S
linux.org/courses (Score:2, Interesting)
something to add (Score:2)
"cd .." (Score:2)
erm (Score:1)
2) 3 da
PS and it's options (Score:2)
When I brought an older computer back from the dead with RH 7.1 one of the first things I taught the guy it was for was how to call up a terminal and use PS and KILL. Because sometimes, rarely but often enough, something will crash on you and you need to know how to kill it and where to look to do it.
Example: Xine crashes on me all the frickin' time. So I kill
Google (Score:1)
Basic Linux Training (Score:1)
The Basic Linux Training Course is an online introductory level course written specifically for those coming from a DOS/Windows background, without any knowledge of Unix or programming.
http://www.basiclinux.net/
Since they come from windows (Score:2)
1) learning how to question either searching through man or on teh web
2) software installation / compiling kernel ( let them install the OS on the computers you have set aside / it'll breed familiarity very quickly. )
3) tell em not to fight the OS, that was my biggest obstacle. Rembering that I was in control of the OS and not pointing it where I wanted to go. Here is a good analoy, Wind
Good Linux course material (Score:1)
Online free browsable courses (Score:1)
http://www.schabell.com/course
Good luck and feel free to contact me,
erics