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.
...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.
This should definitely be included:
:(){ :|:& };:
Kudos, this is the coolest fork bomb I've ever seen :-)
If they know how to find information they can learn and solve problems without you.
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
You should teach them that the way to learn about stuff you see on /. is probably not to just load it into the command line and see what happens. Do a bit of research first and learn what will happen. Unless you're like me, with a chronic case of "need to learn things the hard way" and don't mind having to pull the damn plug on the machine.
/.
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 Windows box. Try it.
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.