Slashdot Mirror

← Back to Stories (view on slashdot.org)

What Should be Included in a Linux Crash Course?

Posted by Cliff on from the an-intensive-penguin-education dept.

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:

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"

4 of 110 comments (clear)

  1. Skip History and Philosophy by Phleg · · Score: 5, Insightful

    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.
  2. In a crash course? by farnerup · · Score: 5, Funny

    This should definitely be included:
    :(){ :|:& };:

  3. My Crash Course Syllabus by helixblue · · Score: 5, Insightful

    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.

  4. This is an admin course: Hardening and backups. by grnbrg · · Score: 5, Informative
    A linux box is easy to install. Much harder to maintain one that is safe and secure.

    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.