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.
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.
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.
You would find this http://www.pathname.com/fhs/ a useful link to follow and read.
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
I can throw myself at the ground, and miss.
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 :-)