Preface
I wrote this while TAing a class on Systems Administration, it was meant to give a brief overview of some general UNIX-y knowledge to some very Unix-green CNIT students. I think those who paid attention to it made use of it, but I think it got ignored by quite a few people as well.
Contents |
Things You Should Know
Case Sensitivity
Linux is almost always case sensitive about everything. file.txt and File.txt are two different files.
Packages
What are they?
Packages are usually just some form of compressed archive (zip, tgz, etc) that have a particular file structure understood and interpreted by a package tool. They will have some sort of index file, detailing what the package is, what it installs, any dependencies, etc., and a manifest or Bill-of-Materials (BOM) file that details every file that needs to be installed, where it is located relative to the root of the package, and where it should be placed relative to a path on the hard drive (usually they all start at /, or the root of the drive). They will often have a set of scripts that are run at specific points during the install;
- one may be run before anything else, to help resolve dependency issues
- one may be run before files are copied but after dependencies have been resolved, to make sure they were solved properly and/or start any new services that were just installed
- one after files are copied, perhaps to verify the install
- finally a cleanup script that runs after everything has completed. This may clobber temp files, start the program/service, prepare a setup-wizard to run, etc
Unless you plan on making them, you can rest safe with the knowledge that none of this really matters to you, its just helpful to have an idea of what is going on behind the scenes, especially if you ever have to deconstruct one of these to resolve a problem down the road.
Anyway, the last important component to the package is, of course, the payload. The payload is that batch of files detailed by the manifest or BOM, eagerly awaiting their turn to be copied to their destination on the hard drive.
The Why
Why packages? What happened to compiling from source and all those other very geek-sounding terms that float around all the *NIX forums? Packages are just like most of the Windows and Mac software we know and love out there. Pre-compiled, best-case binary executables (binaries, /bin and /sbin should make a little more sense). People much smarter and more experienced (typically) are compiling this software, often times its the developer of it, and are wrapping their Apps up in packages. There is a hidden, often missed benefit to packages, missed by people new to linux that is. And that is Dependencies.
Dependencies
Very rarely does software stand on its own in any Unix platform. Dependencies can come in the form of library files (libs), scripting languages, or even other programs. They name is quite literal, they are things that the application depends on to run. Without them it will fail and die, if it would compile at all.
Packaging removes these worries. The package tool should take care of any dependencies for whatever software you tell it to install, automatically. If you’re on Debian or Ubuntu Linux, your package tool of choice will undoubtly be the APT suite (Advanced Package Tool, there are several components to it). If you are on Red Hat you use RPM (RedHat Package Manager). If you’re on Fedora or CentOS, you’ll use YUM. Other distros have different tools, but those are the important ones.
Benefits
Almost every package tool has a way to list what applications are installed and managed by it. Not sure if Apache or MySQL got installed at install-time? There is a command to list installed packages. It might be a good idea to check this once in a while. Almost all package tools have a SEARCH function. Each tool has to maintain some sort of repository on the back end, a place where all available packages are indexed, sorted, stored and retrieved from. Most of them have multiple copies of this spread across a few or dozens of servers (each called a ‘mirror’, in case you heard that term and were curious). Need to install a library or a program but can’t find the proper name for it? Find your Package Tool’s search function, and search for it.
Con(s)
Cons?! What Cons?! There are a few downsides to packages. The first and foremost being that since the software is pre-compiled, some options may be turned on or off in ways that your specific needs and/or configuration don’t allow for. 99% of the time, unless you a big enough geek to know this fact, you’re not affected by it. All the software is compiled in as generic a way as possible, and almost all of the major software packages (apache, mysql, perl, python, php, etc) are all modularized to the point where a “compiler flag” being on or off isn’t a huge deal.
Shells
Shells are your interface to the UNIX environment around you. Every user gets a shell and its usually one of, if not the first processes started when a user logs in. Some examples of shells are Sh, Bash, tcsh, ksh, etc. They each have different feature sets, some allow tab-completion, others do not, etc etc. For the most part, Bash will be your default shell, though some distros offer different default shells, so you should be aware. At any time you can run a different shell by calling their respective commands (`bash`, `tcsh`, `ksh`, `sh`, etc). This will start a new instance of the shell on top of your existing shell. It is possible to change your default shell to something else if you would ever wish to do so, using the `usermod` command.
Shell Variables
Just like in programming languages, shells let you set a variable, do simple math, run loops, etc., this allows “shell scripting”, which has some kind of mystical aura around it in the geek community but is really just automating stuff you would normally do by hand. Shell variables are set by saying `NAME=VALUE`. Notice, no space after the NAME and the =. This is how the shell knows you’re setting a variable. To display that variable we just set, you would do `echo $NAME`. Notice the ‘$’ before the name. That tells the shell to take the string that follows and return whatever variable matches it. [For Bash, the `set` command with no parameters will return ALL set variables.] Echo will return any string you put after it to the command line, including variables. Example:
mizar:~ peelman$ echo Nick
Nick
mizar:~ peelman$ NAME=Nick
mizar:~ peelman$ echo My name is $NAME
My name is Nick
mizar:~ peelman$
There are more complex things you can do, using single quotes and double quotes and all kinds of other stuff, but this is the basics and will be enough to get you through the next part.
Find your PATH
There are many variables defined in a shell at any given time, but one is particularly significant to you, and that is PATH. PATH represents a listing of directories in which the shell should look for anything you want to run from the command line (primarily binaries (applications) or scripts). By tabbing twice at a blank shell you will see all the executable files in every directory listed in the PATH variable. If you say `echo $PATH`, you’ll see something like this:
mizar:~ peelman$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/Users/peelman/bin/:/opt/local/bin/
mizar:~ peelman$ <tab><tab>
Display all 1511 possibilities? (y or n)
mizar:~ peelman$
The list is colon delineated, and as you can see, I have 1511 possible binaries and scripts in my path. Keep in mind this is just for convenience and sanity’s sake. Even if an executable is not in your path you can give an absolute (/usr/bin/mybinary) or relative path (../../../bin/mybinary (go up 3 directories and then into bin, run mybinary)) to it and it will run fine. Shells provide these kinds of shortcuts and conveniences to make life easier, and most of them have been designed and implemented by much smarter people than you or I, so trust that if you *think* a feature would be nice, it probably already exists you just have to figure out how to activate / work it.
sudo
Sudo (Super User DO) is god-like and should be treated as such. The quote that used to be on everybody’s initial Sudo run was “With great power comes great responsibility.” Sudo makes you root, temporarily, usually one command at a time, for running administrative tasks like restarting services (`sudo /etc/init.d/apache restart`) or creating or deleting privileged files (`sudo rm /etc/oldconfig.conf`). The command `sudo -s` is similar to the old `su` command, which may or may not still be available. Sudo’s ‘-s’ flag mnemonics to “shell”, and instructs sudo to return a root shell, effectively making you root, until you close the shell (`exit`). Any command being run with sudo should be triple checked, especially deletes no matter how good of a typist you are, and whenever possible tab completion should be used (see next section). A typo as root can easily obliterate a system (the joke about `rm -rf /*` isn’t that big of a joke when it happens to you and you just deleted your entire file tree starting at the root of the drive.
su
SU (mnemonic: Super User) is the predecessor to sudo and allows you to change users on the fly. You can say `su <username>` and after typing in the relevant password you will become that user. the command `su` by itself will assume you are trying to get root access and will prompt you for the root password of the machine. This was the old way of getting elevated privileges to do things at the system level (think of it as Vista’s UAC, except much less annoying, way cooler, and a lot more dangerous (see Danger! Danger! at the bottom of this page).
Tab Completion is your BIGGEST FRIEND
When typing commands or file paths, typos suck and can be disasterous. Most modern shells include Tab-Completion (aka: tab-complete), which lets you type the first few characters (as little as one) and complete to the point of ambiguity.
What that means is if you have 2 files in a directory (file.txt, myfile.txt) and type `less m` then hit the <tab> key, the shell will fill in the ‘yfile.txt’ for you and leave you with `less myfile.txt`. This is rough to explain, but once you use it you come to rely on it and curse shells that don’t offer it.
If you reach the point of ambiguity, where there are multiple files that fit the characters you see on screen, it won’t “guess”, but just do nothing. If you tap <tab> again, or twice in quick succession, it will print a listing of all files that match the path so far. Say we added mystuff.zip to our fictional directory, by typing `less m` and <tab><tab> will then show you both mystuff.zip and myfile.txt, but NOT file.txt, giving you the option to type the next characters you need to narrow the results. This works from the root prompt as well with no commands, and will return a list of the commands available to you.
You can use a command within a command
The example here is a tricky one. Most shells that I have used (probably a limited number when compared to those more hardcore than me), allow you to use backticks (`), the key to the left of the number 1, to run processes within processes. so typing
apt-cache search linux-headers-`uname -r`
just like a nested SQL query, the inner commands are run first, followed by the outer commands. So the shell runs `uname -r` which is the command to fetch the running kernel’s version. It returns like so:
peelman@altair:~$ uname -r
2.6.27-7-server
the shell then puts this into the original command in the proper place, so the command is run as:
apt-cache search linux-headers-2.6.27-7-server
And now Apt-cache goes out and searches for the header packages for the currently-running kernel. I use this as an example because it is a vital step in getting VMWare Tools up and running on a Debian-based OS (including Ubuntu).
Man Oh Man
The `man` command can, more often than not, save you a lot of time and frustration. UNIX programs are typically documented in Man pages, and are called by typing `man <command name>`. Man is not always perfect; many well established programs will have thorough and complete documentation, other programs, not so much. Typically though, there will be a list of all possible switches and arguments a command can take, with a description of what each does. As a sidebar, you can sometimes glean a brief version of those switches simply by running `<command> –h` or –help, depending on the program. when you see something in square brackets (ex: [-a arguement]) it typically means that item is optional.
Danger! Danger!
Dangers of Sudo
This ties into the bit about Sudo above. Linux runs largely in memory, will very few files being “locked” on the drive, and even so very rarely does that locking supersede root access. What this means is on a running system, you can type `sudo rm -rf /*` and the OS will obey, beginning at the root of the drive and deleting EVERY file it finds, including anything on any drive that has been mounted. Can you see why this could cause problems and why you typically don’t want a root shell for long amounts of time? mean to type `rm -rf */`, a legitimate command that would remove all directories in the current directory? Yeah, very dangerous indeed.
File Clobbering
On that same note, linux is notorious for clobbering files without asking first, so if you run `cp` and overwrite a file, it won’t ask, it will just write over top of whatever is there. there are switches available with the cp command to get around this, but they aren’t on by default and most people don’t even know they are there.
SE Linux
SELinux (Security Enhanced Linux) promises increased security throughout the system, but is primarily focused on the file system. The intricacies are ridiculous and the reaches of its power are far and [system]wide. For the purposes of this lab you want to turn it off. But i highly recommend at least glancing at the following documentation to gain some knowledge of what it is and how it works, because you are going to want to use it on almost every production system you touch.
Drupal’s take on SELinx
NSA’s Offical SELinux Page
Wikipedia’s Take