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.
Ask Slashdot is not a place to get advice on how to do your job. Use Google. Teach yourself. Whatever. Just don't Ask Slashdot. All it tells your employer is that you're lazy and stupid.
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.
I'd try to teach them the logic behind Unix, that means explaining how the filesystem works, and doing alot of basic console excercices. Teach them the how to use pipes effectively, bash shortcuts, what you can do with ssh to remote admin lots of servers, how to find the info they need...
Try to teach them cool things so they'll be happy and curious enough to dig more into it later. If it's a pain for them, they'll quickly forget it... And i'd stick at the console, show them how X works and what you can do with it, but have them use a console all the time. There's no way you can understand Unix by using graphical managment apps...
Anyhow, 3 days is of course not enough to learn evrything, so I think you should really learn them how to think the Unix way, and stick to that.. then show them that using this way of thinking, they can resolve the problem themselves most of the time (and google helps alot too...)
I don't see much sticking in 3 days. I could see an installfest of sorts
Give them a big fat Linux book and tell them to go home and read.
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.
That said, a few words here and there to put to rest some of the myths about the GPL can be quite useful. Also, sometimes a little history is needed to put things in context. Just a few words, though.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
A programmer that doesn't know anything about Linux... What kind of programmer is he, and what "programming" school did he go to? That's just sad.
If they know how to find information they can learn and solve problems without you.
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.
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
Kernel Panic &
Segmentation Fault
Kids today are tyrants. They contradict their parent, gobble their food, and tyrannize their teachers. - Socrates 400 BC
-- learn what to do when you reboot and your ReiserFS comes up read only
-- research hardware problems (yes, of course i knew i had to unplug my PCMCIA NICs, load the appropriate modules, and then repeat the procedure later...)
not that i'm bitter.... had to go back to Win2k due to some work arriving in but i will return gentoo and dammit you will work!!!
*grovelling* tho if someone could explain the filesystem problem for me that would be great...
Morale seems good, considering, although high spirits are just no substitute for eight hundred rounds a minute
I don't mean creating and enforcing ridgid doctrine, though.
Here's an example -- if you've never done this or need a refresher;
The tool(s) used are up to the admin and training in them should be direct and simple. The people who are new to the tools should be given resources (books, notes, and someone experienced to talk to). That the tasks are being performed at all should be easily verifiable. Keep it simple as possible so that it actually gets done, though have it just formal enough that someone else can figure out what should be done -- not necessarily be told how they should do the job.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
I know they are lame books, but when I wanted to start learning Linux, I picked up "Linux Administration for Dummies" I read the thing through and it helped a ton. I would also agree with an earlier post to relate things to what ever OS they are used to. It took me weeks to figure out that there was no C: and D: trees. Thirdly I would make sure to cover the basics, and get them used to the command line. good luck.
Have them make backspace and delete do the right things on all linux machines, including when connecting from one to another and inside mc, vi, and emacs. Then write that up and post it somewhere where I can find it.
http://www.google.ca/search?hl=en&ie=UTF-8&q=progr am+equivalents+linux+windows&btnG=Google+Search&me ta=/
After all, it is mostly about the applications right?
Mystika
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.
Its real nice to point and say 'please consult the excellent documentation', but a total newbie probably doesn't even know what they are looking *for*
Teach them:
File system stuff- where, how- make a new directory, find a file, check permissions
- permissions- look at and change
-mounting devices (start above with 'Linux sees everything as a file system'), unmounting devices, names of devices
- text editors. vi, emacs, whatever. start from the gui of your choice and show them the equivalent of notepad (Kate, gedit whatever)
- equivalent apps- openoffice, firefox, thunderbird whatever you use.
All this will make them comfy on the desktop. then:
-review network basics, and show them the basic utilities- how to look at and reconfigure a network connection
- show them top, ps , grep, awk and df/du, DD, cp,
After that, go teach them about more specific stuff. nothing else will make much sense to a Linux newbie...philosphy and pedagogy is important, but should take a back seat unless it relates directly.
And yes, show them the docs, the forums etc, and hand them a book and show them where stuff is.
'RTFM' is just rude and arrogant.
Skip "Breathe in, breathe out...the rest is easy"
As a sysadmin I've had the opportunity to work with, or closely observe the work of, about 30 other admins. The ones who do well are those that have a healthy respect for the system. I try to keep my setups as default as possible. Any change must have a good reason. This keeps things more stable (defaults are better tested) and easier for my replacement. The "problem" admins are the ones that can't resist tweaking everything. Yes, they might get a 1% performance boost, but they're also more likely to generate system instability.
In terms of priorities, there are a few basic rules: #1 priority is security, #2 is stability, and #3 is performance or other user requirements.
Finally, there's the concept of structuring the environment. Think about dependencies. Try to consolidate services so there's a single point of failure. This means not having multiple fileservers with crossmounts. Running a single OS/distribution will make your life a lot easier, assuming your shop doesn't require the diversity.
As others have said, there's a lot you can teach them about how to read manpages and use google, but without the basic philosophy of how to be an admin, all their knowledge will probably just lead them to manage unstable systems.
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.
You mean a course on when Linux crashes? Perhaps a boot disk HOWTO, or suggestion on configuring grub with mulriple kernels....
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
One resource you should check out and possibly incorporate is the Infrastructures.Org practices for reproducable configuration management.
I concur. Helped me greatly, even just admin'ing my own machine. Has questions at the end of each chapter. (Better than O'Reilly's "Running Linux")
Written by Steven Graham & Steve Shah; published by McGraw-Hill Osborne (www.osborne.com). ISBN 0-07-222562-9
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
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.
there used to be an o'reilly book - essential system administration. billed as the book you need when your admin isn't around. dunno if they maintain it, but it was great back in 1995.
to encourage them to learn, show them the intro man pages - man 1 intro; man 2 intro; man 3 intro; etc.
US Citizen living abroad? Register to vote!
This would be useful, give the link to them to check out.
Whether it's Linux, Solaris, BSD, etc. etc. they all have some very fundamental similarities which are fairly important to know if you're going to be using a UNIX-like OS.
Also check out this awesome selection of Linux books/material, especially the newbie-geared books. They would be very beneficial to anyone looking to learn about Linux.
Speaking as someone who is fairly new to world of linux based operating systems, I would suggest the courses on www.linux.org. They are based on a debian system, but most of the basics for all linux systems are there. I learned more from that then any other information I have come accross so far. First take a look at yourself and see what you would like to stress as important and go over those sections in the time you have with them. Then you can give them some homework by having them go over the courses at home.
along with your course, I think you would be smart to send each student home with a copy of Knoppix so they can play around on their own time. If they're like most tech people, their computer use won't stop when they leave work, and knoppix would be an easy way for them to explore linux on their own. as most computer users will tell you, exploration is the best way to learn
Essential System administration is in fact still availabel, recently (2003?) updated even...and its a *great* resource, very thorough but I wouldn't recemmend it to just anyone. its very dense and dry, and it goes into pretty good detail on a lot of things.
S
Skip "Breathe in, breathe out...the rest is easy"
Apparently, cd.. is a shell built-in or something on Windows that does the same thing as "cd ..". I recently got my coworkers to try Knoppix at home, and they said it took them a while to figure out what was "wrong". Either wean them off it quickly, or show them how to alias it in .bash_profile.
-insert a witty something-
1) If you have a programmer and a technician in the year 2004 who have absolutely no experience of open source, then you, and they, have a problem. The best way to "learn" "open source" is to have an interest in it, without interest, you cannot learn. Seeing as open source is a logical progression from just about any IT platform around, this should not be a problem. How you can be a programmer or a technician in this day and age without ever having used linux (at least once) completely escapes me.
2) 3 days to "learn" "open source"?!!? This is just not going to happen for those who have never shown the inclination until now. The philosophy and practices of every open source platform and language in 3 days?!?!?
conclusion) Open source can and should ALWAYS be your starting point for any IT related endevour. If it is not, then why not? Further, "open source" cannot be "taught" in three days, in the context of a presumably proprietary monoculture. Heres what you do:- find an open source tool that solves at least one problem, or streamlines at least one task that your IT team is experiencing. The merits of open source will be made clear by the ease and practicality of the utility its self. The open source expertise will come by using the utility over and over agian to successfully solve the same problem and save valuable development time. This will make your staff open source experts.
Forget the 3 day seminar- it wont work. Use those 9 man days on something useful
I think perhaps the single most handy (and most used) program on my Linux box, INCLUDING INIT, is PS, specifically PS AUX, and it's partner KILL -9.
.bashrc (if you're a bash-head like I am), and ifup and ifdown. Oh, and PING. Oh, and the terminal and how to call one up under X.
When I brought an older computer back from the dead with RH 7.1 one of the first things I taught the guy it was for was how to call up a terminal and use PS and KILL. Because sometimes, rarely but often enough, something will crash on you and you need to know how to kill it and where to look to do it.
Example: Xine crashes on me all the frickin' time. So I kill it about every 3rd time I use it.
The other thing that I pass on about *nix in general (and, really, computers in general) is one of the first things *I* was taught: everything on the computer is a file. Right there, it turned the computer from being a monolithic and enigmatic device into something I could actually use. All I had to do then was understand the parts and how they worked together.
Others have mentioned the file system, and they're right, you should teach them about it. Help them understand INIT.D,
There are about a million things you could teach someone in this course, all of them valid. If I could only teach someone a handful of things before setting them loose these would probably be at the top of the list.
Honestly, I don't know how you're going to teach people enough admin knowledge to do a decent job in just 3 days. It took me at least 6 months of personal instruction to really get the hang of it. Good luck, though!
Useless opinions, worthless observations, and more!
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
http://www.google.com/linux That should help them out a lot. Also, be sure to teach them the basics of networking and how to set that up. For example, if these are clients on a network, be sure to explain the difference between Static IP and DHCP, as well as how to set each type up.
Basic Linux Training Course
The Basic Linux Training Course is an online introductory level course written specifically for those coming from a DOS/Windows background, without any knowledge of Unix or programming.
http://www.basiclinux.net/
I have read many good suggestions, having come from stricly Windows myself sometime ago, 3 things were indispensable to me
1) learning how to question either searching through man or on teh web
2) software installation / compiling kernel ( let them install the OS on the computers you have set aside / it'll breed familiarity very quickly. )
3) tell em not to fight the OS, that was my biggest obstacle. Rembering that I was in control of the OS and not pointing it where I wanted to go. Here is a good analoy, Windows is like a horse, you direct it to where you want it to go, but it won't do it precisely how you want. *nix is more like a car. You can steer it precisely where and how you want it to go.
I am Bennett Haselton! I am Bennett Haselton!
The biggest problem I've had in indoctrinating myself in Linux isn't finding out how to do something but in seeing the larger picture of how things interrelate. I'm also a big fan of the whole O'Reilly series, what would be cool would be a Linux Cookbook with scripts that analyze configs or monitor potential problems. I can always turn to the web and geek out on JFS internals or bash commands but that only answers the small questions. I'm not a kernel geek but things like how to recompile your kernel with a built in module, then how to remove the configs for the old linked module would be a life saver. I fear I have many unused configs or some conflicting ones at the very least.
Midnight Commander is an indespensible utility. Especially when it comes to editing config files.
I first found out about it back when I was using Red Hat 4.2 and I have loved it ever since.
A friend of mine was taking a Linux/Unix administration class at the local community college and had a few linux questions for me. He logged on to his box and let me take the keyboard.
He was floored when he saw how convienent mc was. He actually showed his professor and HE had never used it before.
Especially for old school DOS users, mc can help make linux administration less alien and more efficient.
I have a few courses that I teach here in the Netherlands, feel free to browse them online (I have the slides freely available).
http://www.schabell.com/course
Good luck and feel free to contact me,
erics
Hey bright people,
I'm sure it's all fine and dandy that you all come with little do's and don'ts, but a few of us would like to know what that little gimmick actually does, *in plain english*.
My "shell-fu" is practically nonexistent, and I don't have cygwin (the app, the source, the need or the skill).
Please, could someone post a two-liner about what the devil that bunch of parentheses do, and why it would be dangerous to do the obvious and copy/paste it?
Thanks.....
"Good news, everyone!"
...and when the puny user has typed those three characters and punched ENTER, he may find himself locked into a Wordperfect-style textual GUI with no obvious way out. ESC doesn't work. CTRL-C/BREAK doesn't work. CTRL-X doesn't work.
I can type "man thingamabob" to find out how something works, but from there I don't know how to look for the next thing. And, how the devil do you scroll up?
No, the most important comment to go with the "man" command is the information that a simple single "Q" gets out out of it again. (This at least, is my story.)
"Good news, everyone!"