[ TriWiki ]
TriLUG's Linux Essential Knowledge wiki page is intended both as an introduction to the new *nix user and a thorough handbook for more experienced users.
Contents
|
Google is the omniscient search engine. Information on any topic you desire can probably be found there, so it's always a good idea to check with Google before you go running to another person for help on a particular topic.
Google also has a Linux specific search page http://www.google.com/linux I often find it useful to search for things both here and on the general Google page.
to be completed...
Man pages are the keys to understanding almost any new or unfamiliar unix command, but they require a different style of reading than most people are accustomed to. Specifically, man pages are feature-oriented, but with careful study of what the features are. By reading about the options or settings described in the man page, one can often deduce things not explicitly spelled out.
The man page for almost any command on a system can be accessed by typing man <command>, where <command> is the name of the command in question. For example, the man page for the command "ls", can be accessed by typing "man ls". The common notation for referring to a man page (keeping the ls example) is ls(1). The (x) refers to the "section" the man page is located in, which gives a clue to what the man page is about. This notation is also often used simply to refer to the program itself, so some confusion can result.
For example, the first man page section (1) describes most userland programs, such as ls, grep, cut, etc. The third section documents C system calls, etc, etc.
(TODO: Document each man section)
Man pages have a distinctive style. They're almost always broken down into sections, including but not limited to NAME, SYNOPSIS, DESCRIPTION, OPTIONS, EXAMPLES, SEE ALSO, BUGS, and TIPS. Each of these section names is fairly self explanatory, but reading man(1) may prove useful.
Man pages are usually extremely dense and stylized, which makes them difficult for the beginner but adds to their utility for experienced users, since the predictable style makes finding the right option faster. Solving a problem by reading the man page leads to faster and better learning of a *nix.
Once you've exhausted sources of information which may contain previously written guidance on a topic, you'll have to ask someone else for help. Being able to ask questions in a smart way, providing as much information about your predicament as is both possible and appropriate, is an important part of getting help; if you can ask a smart question, you're much more likely to get help. The canonical guide to constructing smart questions is written by Eric Raymond: ESR's guide to asking smart questions on a mailing list/IRC
This topic deserves a page of it's own. See Recommended linux books.
For those totally new to a *nix operating system, an introduction to the command line is in order. It looks like this:
tux@linux ~ $
Where "tux" is your username, "linux" is the name of the computer (or node) to which you have logged on, and the tilde (~) means that your present working directory is your home directory, /home/tux. The dollar sign means that you are a regular user. If you were to become root, you would instead see:
root@linux /home/tux #
Respect the pound sign!
If you're totally new to the command line, LinuxCommand.org is a good introduction.
Because Linux and its relatives make extensive use of text files for configuration, learning how to use a text editor is an essential skill. While beginners can make do with simple easy to learn editors such as nano, Linux users are well-advised to learn one or both of the "big two", vi and emacs. These editors are very powerful, but many users have difficulty in mastering them because they are keystroke driven and often require the user to remember not only the keystrokes, but how they interact with the editor in its current state.
But such mastery is extremely useful. One reason is that the bash shell when used in interactive mode uses a user interface for interacting with the history file which is tailored to and will be familiar to users of these two editors.
There have been Holy Wars with many casualties waged over the relative merits of vi and emacs. We will stick to a brief introduction here.
Some version of the vi text editor ships with every *nix distribution. Basic ability to edit, write to file (save) and quit in vi is a must for anyone doing serious work with a *nix operating system.
Learning basic vi also goes very well with the rest of the unix philosophy, in that it's designed for the super-efficiency of lazy typists. Bonus points for teachers who can edit things ridiculously fast in vim and wow the students with the tricks that can be done in the hands of an experienced vim user. Consult the TriLUG mailing list if you are a teacher searching for such a person. Also, to learn more about VI you might take a look at the wiki page where Rick DeNatale (a TriLUG member) attempts to learn how to use VI.
One of the more confusing aspects of vi(m) for new users is that it is a modal editor. There are two modes: command mode and edit mode. Command mode allows you to enter commands that perform actions on the text; for example: copy, paste, delete, run macros, etc. Editing mode allows you to edit text, strangely enough.
There are two types of commands, those act immediately on text, and those that require input at a prompt at the bottom of your screen. To access the prompt, type a colon (:) when in command mode. Complete the command at the prompt, and then hit enter.
The default mode when opening a file is command mode.
Another editor which has been around for quite some time is emacs. Many find it easier to get up and running with emacs than with vi, especially since emacs comes with a helpful tutorial on how to get started. Also most modern emacs implementations are written to take advantage of the X windowing system and provide pull-down menus in addition to the more traditional keystroke interface. The down side of this is that user's often fail to learn the keystrokes. Emacs also has the advantage of having content-sensitive modes for common file types such as HTML and built-in support for extending emacs using lisp.
Perhaps the most important command sequence to know is C-g (hold the control key and type a lower-case g), which will exit any keystroke sequence you may have accidentally started. There is also C-c C-x which will prompt you to save changes and then exit emacs.
Understand the standard unix user setup, /etc/passwd and /etc/group, /etc/shadow, and perhaps how /etc/skel is used in account setup. In a modern distribution, through pam and nsswitch, these concepts are extensible and can be centralized to allow centralized control and management of users, much like active directory does in windows. You won't have time to teach ldap and kerberos thoroughly, but at least make the point that it's possible. Maybe explain PAM, not in intricate detail, but gloss it and provide references.
Learn about dot-files in your home directory, and how some files share intelligent defaults from a common dotfile (.netrc, for example) and how most daemons have their own dotfile or directory (.ssh is a good one)
A working knowledge of shell scripting is essential to anyone wishing to become reasonably proficient at system administration, even if they do not anticipate ever having to actually write a script. Consider that as a Linux machine boots up, it executes the shell scripts in /etc/rc.d to restore the system configuration and set up services. A detailed understanding of these startup scripts is important for analyzing the behavior of a system, and possibly modifying it. ... Continue reading the Advanced Bash-Scripting Guide
Pick a shell and learn it well. Bash is recommended. Understand the basics of commands while being sure to know the difference between shell built-ins vs system commands (ie. cd, export and set vs. ls, cat and grep). Understand how echo can be tricky, because traditionally it is a command, but bash also has a built-in version.
Explain shell variables vs environment variables, at least at a cursory level, and also touch on inheritance of environment variables. Be sure to mention "special" variables, with some thoroughly explained, such as $PATH, $CWD, etc. Teach them some neat tricks with the shell that save them time, like a few good aliases, or one-liner simple scripts (while read line; do foo; done; # this is often a favorite).
Explain output redirection, STDIN vs STDOUT vs STDERR, and how to chain these together in the shell to take input from one place (cat) and pipe it through another place (sed) and dump it out stdout into a file (/tmp/foo).
Once you've shown them the basics of using the shell as an interactive tool, then show them how to build on that briefly to build very simple scripts to automate repetitive tasks. Be sure you at least gloss the primary programming constructs for conditionals, loops, etc (if, for, while, etc - depending on how far towards programming you want to go).
A really good combo exercise might have them do something moderately tedious in the process of learning an editor (vi), and teach them how to improve on that task in the editor (more on that in a moment), then show them how to do the entire same task in shell as an automated command, and call it from their ~/bin directory. If you can teach them to understand the shell, and show them that it is good, you'll make life-long *NIX users out of them.
In *nix, everything is a file. Hard drives are files (/dev/hda), serial ports are files (/dev/ttyS0); indeed, all devices are files, under the /dev directory, and can be read from or written to as any other file. It is good to know the difference between a block device and a character device, also.
Understand how they work, both modal (755) and verbose (o+rwx), how to read the output of ls, how to set permissions with chmod (late in a class, touch on sticky bit, setuid, setgid, and how they affect both files and directories)
Are found in /, /etc, /home, /var, /usr, /proc, /tmp Understand what's usually stored under each and why Learn some important and useful sub-dirs, such as /usr/share, /usr/share/doc/, /usr/src, /var/log, and /var/run
Explain the "special" directory structures, specifically /proc, maybe devfs, but only in the context of broader dev devices and "how it used to be" / is on most unices vs. how it is on a very modern linux.
Know the basic suite of *NIX command line tools. These are classics we take for granted that allow us to construct shell scripts. Some must-haves: cat, grep, cut, wc, sort, uniq, tr, sed, mktmp, (this list could go on forever) and some more advanced bits such as awk, or even perl one-liners, depending on time and commitment.
ps allows us to look at running processes. This is good to do in conjunction with basic shell scripting, ps -ax | grep. Explain signals, and the kill command. Explain how signals are handled, and at least SIG TERM, KILL, HUP, and why all of them but KILL and STOP are handled by the process, and the other two are handled by the kernel.
Try to give them at least a cursory understanding of how the system goes from ground zero (the bootloader), through the kernel, which starts init, which starts a single shell script, which (in most distributions, at least) fans out into a group of shell scripts and config files, eventually launching all of the programs started at bootup, including things like the login gettys. Explain how all processes are children of init, and that they all inherit certain things set early in the boot process (such as path, umask, etc). Show them that if they get lost, if they can't understand where something is coming from, starting at, etc it's only a matter of walking through the shell scripts, from beginning to end (you probably can't do it in it's entirety in the time alloted for something as large as RedHat, but the principal should at least be understood of how the system works). This lays the ground work for being able to troubleshoot _all_manner_ of system start up problems, which anyone tinkering with Linux anywhere beyond the cursory user level will inevitably run across one day.
Show their basic config files, explain a few of the common linux config file formats (key=value, apache configs, etc) and go into some more depth for some of the more common daemons they might deal with (at least a cursory understanding of Apache, Samba, and maybe BIND would be helpful). Explain cron, probably in some detail, and how it's commonly used.
Explain the TCP/IP stack. You don't have to teach a networking class, but expose them to ifconfig and route, explain how to do the common things such as set an IP on an interface, set a default route, list those back out from ifconfig and route -- maybe even teach the ip tool in addition to (not instead of) ifconfig and route. Explain network interfaces, how they're named, and the fact that they break the usual convention of being a file (there is no /dev/eth0...).
Maybe explain the resolver structures, and everything keyed out of nsswitch.conf. Specifically, how is a dns lookup handled (the machine looks in nsswitch.conf, which probably says "hosts dns", then looks at /etc/hosts, then looks at /etc/resolv.conf, then talks to your nameserver based on resolv.conf's config. Explain how the same is done for /etc/passwd lookups, by looking at nsswitch, and then possibly to an external source such as ldap, nis, etc.
Ensure they understand the myriad of remote access and file copy options. Touch on telnet, ftp, rcp, rlogin, .rlogin (that's dot rlogin), and /etc/hosts.equiv - explain why they are bad. Then introduce ssh, scp, and ssh host keys. Be sure to explain the rsa key functionality of ssh, at least in terms of what it can allow you to do with un-prompted logins, and how this can be used to do things securely while unattended, and allow for secure authentication of hosts, not just users.
Security-enhanced Linux, or SELinux, implements role-based access controls. "Root is god" doesn't really go as far in an selinux system.
Because of the unwillingness of some hardware vendors to provide support to Linux developers, some off-the-shelf PCs and notebooks may present problems when installing some or all Linux distributions. A good way to test compatibility on the target machine is to boot from a Linux LiveCD. This can also help you choose a distribution if you are a new user.
Debian GNU/Linux is an operating system based on the apt package management tool. It is not only an operating system, since it includes one of the largest collections of free software available under any system. These packages are made available through mirrors located all over the world.
Debian is not a system recommended for the novice user unwilling to spend a significant amount of time learning about linux and debian specifically.
Debian GNU/Linux strives to be completely Free and Open Source.
Ubuntu Linux and its partner projects Kubuntu and Edubuntu are all linux distributions based on debian's apt package management tool. They are distinct distributions with distinct missions. Novice linux users will find ubuntu and its kin relatively easy to install and maintain.
Issue the following:
tux@linux ~ $ cp -aR /foo /bar &
Where /foo is the directory you want to back up and /bar is the directory (hopefully on another machine or at least a second HD) to which you are backing up.
This solution requires a second computer that accepts ssh connections or two physical drives on the same machine. If you have that, then procede by booting from the LiveCD and issuing the following:
tux@linux ~ $ su root@linux /home/tux # dd if=/dev/hda | ssh user@remote.host dd of=foo.img
Remember to replace "user" with your username. The dd command usually reads from standard input, but here we set it to read /dev/hda as the input. If you are copying a specific partition, you may need to replace /dev/hda with /dev/hda6 for example. Your partitions will appear as mounted disks on the desktop when the LiveCD boots. The input is then piped across the network to another dd running on the machine to which you are backing up. The command dd normally writes to standard output, but in this case you are writing to foo.img, where "foo" is the name of your backup image file.
You can then clone the original hard drive to another drive or partition by booting with the LiveCD on the target machine and using the following:
root@linux /home/tux # ssh user@remote.host dd if=foo.img | dd of=/dev/hdaN
Where N is the partition number.
In the case where you have the backup HD in the same machine, you can skip the need for the ssh and issue:
root@linux /home/tux # dd if=/dev/hdaN | dd of=/dev/hdaM
Where N is the partition or drive you want to back up and M is the HD to which you are backing up.
The best way to install linux is to have a a printed set of instructions or HOWTO that you have read before you begin and a second computer with internet access once you start. That printed set of instructions will likely be a combination of two sets of instructions. The first and most important is the documentation that came with your distribution. Start by browsing the official website of your distribution. Make sure you get the instructions for the release that you will be installing. Next you'll want to google for your hardware. This step is not as important if you purchased an intel-based desktop tower from a major brand or purchased the parts based on compatability and assembled the computer yourself. If, however, you purchased a laptop or a bleeding-edge/non-mainstream desktop, you should definitely google for HOWTOs and patches for your hardware.
When making the transition from Windows to Linux, you'll be looking for open source applications to replace the applications that you have been using.
see also: linuxquestions.org comparison
| Windows | Linux |
| Microsoft Word | OpenOffice.org Writer, Abiword |
| Microsoft Excel | OpenOffice.org Calc, Gnumeric |
| Microsoft PowerPoint | OpenOffice.org Impress |
| Microsoft Access | MySQL, PostgreSQL, OpenOffice.org Base |
| ??? | OpenOffice.org Draw, OpenOffice.org Math |
| Microsoft Outlook | Evolution, Mozilla Thunderbird |
| Connectivity VPN Client | OpenVPN, VPNC(Cisco client) |
| MSN/Microsoft Office Communicator | Pidgin (was GAIM), aMSN, Kopete, etc. |
| Internet Explorer | IE on Linux, Firefox, Konqueror |
| NetMeeting | Ekiga, Twinkle, Wengo, Skype |
| WinZip | included functionality |
| Symantec Anti-virus | (not necessary), ClamAV |
| TOAD | SQuirreL SQL Client |
| WinCVS | Cervisia, CVS, Eclipse integrated CVS, TkCVS |
| Rational UML tools | ArgoUML, Umbrello |
| WinMerge | diff, k3diff GUI |
| Nero CDROM burner | K3B |
| Quicken,Money | GnuCash |
This site is using a modified version of the Beeblebrox Theme