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"
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.
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.
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 :-)