Slashdot Mirror
What Should be Included in a Linux Crash Course?
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:
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"
You're training them to use the software, not be Linux advocates. While it may be of value, when you are limited to three days, the number one priority is getting them comfortable with the system.
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.
No comment.
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...
you'll be able to get more than a one/month rate thanks to all the time saved not waiting for gentoo to compile.
This should definitely be included:
:(){ :|:& };:
...Stress security - complex passwords containing numbers, letters and punctuation that they will keep private. Show them some commands at a bash shell 'just in case' something goes wrong on the GUI side. Show them how to navigate the file system, both command-line and graphically. Teach them about man pages. Demo applications that they need, and tell them the names of replacement programs:
Microsoft Office : OpenOffice.org
Internet Explorer : Firefox/Mozilla
PhotoShop : GIMP
Hosting: as low as $5.95/Mo
% man man
"The cost of freedom is eternal vigilance." -Thomas Jefferson
... 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.
I think you're about on track. So far I've had to teach two people at my current workplace (one mac user, one windows user) about Linux so that I can have a backup for when I go on vacation.
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 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.
Replying to myself, but i think the fist thing you should learn them is how to feel cumfortable with bash. Teach them at least the shotcuts to go at beginning/end of line/word, backward and forward delete word, kill line, and the reverse search mecanism. Then train them for maybe 30 minutes to use them effectively
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. They're generally not as handy), and that'll make their console experience much more interesting instead of being fustrating... Plus, they're learning emacs at the same time, which could be usefull.
Either way, show them how to make a kickstart disk or other ways 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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
If they know how to find information they can learn and solve problems without you.
Give them each a book as a present to start with -- it gets the juices going and it also gives them a place to reference. This lets you focus on concepts and lets the book serve as a memory of what they are learning.
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.
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 scripts. What these are and what they do.
- IP tables configuration. What IP tables is, why it's important, and how to configure it. This may or may not be in relation to Bastille.
- Tripwire. 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 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, and it's more esoteric options, such as multi-volume tarfiles, dump levels, etc.
- Rotation schemes. 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.
Write up your course and release it on the web under a Creative Commons license so that the rest of us can also use it to learn/teach and so that we can improve upon it for you.
;)
You know you should
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...
SAILING MISHAP
Kernel Panic &
Segmentation Fault
Kids today are tyrants. They contradict their parent, gobble their food, and tyrannize their teachers. - Socrates 400 BC
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.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Its real nice to point and say 'please consult the excellent documentation', but a total newbie probably doesn't even know what they are looking *for*
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, gedit whatever)
- equivalent apps- openoffice, firefox, thunderbird whatever you use.
All this will make them comfy on the desktop. then:
-review network basics, and show them the basic utilities- how to look at and reconfigure a network connection
- show them top, ps , grep, awk and df/du, DD, cp,
After that, go teach them about more specific stuff. nothing else will make much sense to a Linux newbie...philosphy and pedagogy is important, but should take a back seat unless it relates directly.
And yes, show them the docs, the forums etc, and hand them a book and show them where stuff is.
'RTFM' is just rude and arrogant.
Skip "Breathe in, breathe out...the rest is easy"
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.
In three days, you are not going to get anything except the abolute fundamentals to stick. Since we all learn by hanging new knowledge on our existing experiences, the best you can do is show them how they can use resources at hand such as books, web, ask slashdot ;) to teach themselves. Any specifics should be directly job related.
Dogma - "let's just say we'd like to avoid any empirical entanglements."
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.
FreeBSD for the impatient.
Seems strange noone has mentioned it but you should teach them how to download source code and build it. The ol' tar zxvf, configure, make, make install steps. Teaching them how to administer patches too would definitely be relavant.
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 from some l33t bigot.
Your list of tasks you want them to do indicates that you really need to focus on getting them to grips with the terminal. I reckon your being pretty ambitious if you think you can pull it off in 3 days. Perhaps give them all a little reference pocketbook as part of the course.
Speaking as someone who is fairly new to world of linux based operating systems, I would suggest the courses on www.linux.org. They are based on a debian system, but most of the basics for all linux systems are there. I learned more from that then any other information I have come accross so far. First take a look at yourself and see what you would like to stress as important and go over those sections in the time you have with them. Then you can give them some homework by having them go over the courses at home.