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.
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
Kernel Panic &
Segmentation Fault
Kids today are tyrants. They contradict their parent, gobble their food, and tyrannize their teachers. - Socrates 400 BC
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."