Posts Tagged 'Sysadmin'

November 11, 2013

Sysadmin Tips and Tricks - Using the ‘for’ Loop in Bash

Ever have a bunch of files to rename or a large set of files to move to different directories? Ever find yourself copy/pasting nearly identical commands a few hundred times to get a job done? A system administrator's life is full of tedious tasks that can be eliminated or simplified with the proper tools. That's right ... Those tedious tasks don't have to be executed manually! I'd like to introduce you to one of the simplest tools to automate time-consuming repetitive processes in Bash — the for loop.

Whether you have been programming for a few weeks or a few decades, you should be able to quickly pick up on how the for loop works and what it can do for you. To get started, let's take a look at a few simple examples of what the for loop looks like. For these exercises, it's always best to use a temporary directory while you're learning and practicing for loops. The command is very powerful, and we wouldn't want you to damage your system while you're still learning.

Here is our temporary directory:

rasto@lmlatham:~/temp$ ls -la
total 8
drwxr-xr-x 2 rasto rasto 4096 Oct 23 15:54 .
drwxr-xr-x 34 rasto rasto 4096 Oct 23 16:00 ..
rasto@lmlatham:~/temp$

We want to fill the directory with files, so let's use the for loop:

rasto@lmlatham:~/temp$ for cats_are_cool in {a..z}; do touch $cats_are_cool; done;
rasto@lmlatham:~/temp$

Note: This should be typed all in one line.

Here's the result:

rasto@lmlatham:~/temp$ ls -l
total 0
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 a
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 b
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 c
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 d
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 e
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 f
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 g
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 h
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 i
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 j
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 k
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 l
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 m
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 n
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 o
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 p
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 q
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 r
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 s
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 t
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 u
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 v
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 w
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 x
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 y
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 z
rasto@lmlatham:~/temp$

How did that simple command populate the directory with all of the letters in the alphabet? Let's break it down.

for cats_are_cool in {a..z}

The for is the command we are running, which is built into the Bash shell. cats_are_cool is a variable we are declaring. The specific name of the variable can be whatever you want it to be. Traditionally people often use f, but the variable we're using is a little more fun. Hereafter, our variable will be referred to as $cats_are_cool (or $f if you used the more boring "f" variable). Aside: You may be familiar with declaring a variable without the $ sign, and then using the $sign to invoke it when declaring environment variables.

When our command is executed, the variable we declared in {a..z}, will assume each of the values of a to z. Next, we use the semicolon to indicate we are done with the first phase of our for loop. The next part starts with do, which say for each of a–z, do <some thing>. In this case, we are creating files by touching them via touch $cats_are_cool. The first time through the loop, the command creates a, the second time through b and so forth. We complete that command with a semicolon, then we declare we are finished with the loop with "done".

This might be a great time to experiment with the command above, making small changes, if you wish. Let's do a little more. I just realized that I made a mistake. I meant to give the files a .txt extension. This is how we'd make that happen:

for dogs_are_ok_too in {a..z}; do mv $dogs_are_ok_too $dogs_are_ok_too.txt; done;
Note: It would be perfectly okay to re-use $cats_are_cool here. The variables are not persistent between executions.

As you can see, I updated the command so that a would be renamed a.txt, b would be renamed b.txt and so forth. Why would I want to do that manually, 26 times? If we check our directory, we see that everything was completed in that single command:

rasto@lmlatham:~/temp$ ls -l
total 0
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 a.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 b.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 c.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 d.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 e.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 f.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 g.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 h.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 i.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 j.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 k.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 l.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 m.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 n.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 o.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 p.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 q.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 r.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 s.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 t.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 u.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 v.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 w.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 x.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 y.txt
-rw-rw-r-- 1 rasto rasto 0 Oct 23 16:13 z.txt
rasto@lmlatham:~/temp$

Now we have files, but we don't want them to be empty. Let's put some text in them:

for f in `ls`; do cat /etc/passwd > $f; done

Note the backticks around ls. In Bash, backticks mean, "execute this and return the results," so it's like you executed ls and fed the results to the for loop! Next, cat /etc/passwd is redirecting the results to $f, in filenames a.txt, b.txt, etc. Still with me?

So now I've got a bunch of files with copies of /etc/passwd in them. What if I never wanted files for a, g, or h? First, I'd get a list of just the files I want to get rid of:

rasto@lmlatham:~/temp$ ls | egrep 'a|g|h'
a.txt
g.txt
h.txt

Then I could plug that command into the for loop (using backticks again) and do the removal of those files:

for f in `ls | egrep 'a|g|h'`; do rm $f; done

I know these examples don't seem very complex, but they give you a great first-look at the kind of functionality made possible by the for loop in Bash. Give it a whirl. Once you start smartly incorporating it in your day-to-day operations, you'll save yourself massive amounts of time ... Especially when you come across thousands or tens of thousands of very similar tasks.

Don't do work a computer should do!

-Lee

September 16, 2013

Sysadmin Tips and Tricks - Using strace to Monitor System Calls

Linux admins often encounter rogue processes that die without explanation, go haywire without any meaningful log data or fail in other interesting ways without providing useful information that can help troubleshoot the problem. Have you ever wished you could just see what the program is trying to do behind the scenes? Well, you can — strace (system trace) is very often the answer. It is included with most distros' package managers, and the syntax should be pretty much identical on any Linux platform.

First, let's get rid of a misconception: strace is not a "debugger," and it isn't a programmer's tool. It's a system administrator's tool for monitoring system calls and signals. It doesn't involve any sophisticated configurations, and you don't have to learn any new commands ... In fact, the most common uses of strace involve the bash commands you learned the early on:

  • read
  • write
  • open
  • close
  • stat
  • fork
  • execute (execve)
  • chmod
  • chown

 

You simply "attach" strace to the process, and it will display all the system calls and signals resulting from that process. Instead of executing the command's built-in logic, strace just makes the process's normal calls to the system and returns the results of the command with any errors it encountered. And that's where the magic lies.

Let's look an example to show that behavior in action. First, become root — you'll need to be root for strace to function properly. Second, make a simple text file called 'test.txt' with these two lines in it:

# cat test.txt
Hi I'm a text file
there are only these two lines in me.

Now, let's execute the cat again via strace:

$ strace cat test.txt 
execve("/bin/cat", ["cat", "test.txt"], [/* 22 vars */]) = 0
brk(0)  = 0x9b7b000
uname({sys="Linux", node="ip-208-109-127-49.ip.secureserver.net", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=30671, ...}) = 0
mmap2(NULL, 30671, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f35000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000_\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1594552, ...}) = 0
mmap2(NULL, 1320356, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7df2000
mmap2(0xb7f2f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13c) = 0xb7f2f000
mmap2(0xb7f32000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f32000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7df1000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7df0000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7df1b80, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f2f000, 8192, PROT_READ) = 0
mprotect(0xb7f57000, 4096, PROT_READ) = 0
munmap(0xb7f35000, 30671) = 0
brk(0)  = 0x9b7b000
brk(0x9b9c000) = 0x9b9c000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("test.txt", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57, ...}) = 0
read(3, "Hi I'm a text file\nthere are onl"..., 4096) = 57
write(1, "Hi I'm a text file\nthere are onl"..., 57Hi I’m a text file
there are only these two lines in me.
) = 57
read(3, "", 4096) = 0
close(3) = 0
close(1) = 0
exit_group(0) = ?

Now that return may look really arcane, but if you study it a little bit, you'll see that it includes lots of information that even an ordinary admin can easily understand. The first line returned includes the execve system call where we'd execute /bin/cat with the parameter of test.txt. After that, you'll see the cat binary attempt to open some system libraries, and the brk and mmap2 calls to allocate memory. That stuff isn't usually particularly useful in the context we're working in here, but it's important to understand what's going on. What we're most interested in are often open calls:

open("test.txt", O_RDONLY|O_LARGEFILE) = 3

It looks like when we run cat test.txt, it will be opening "test.txt", doesn't it? In this situation, that information is not very surprising, but imagine if you are in a situation were you don't know what files a given file is trying to open ... strace immediately makes life easier. In this particular example, you'll see that "= 3" at the end, which is a temporary sort of "handle" for this particular file within the strace output. If you see a "read" call with '3' as the first parameter after this, you know it's reading from that file:

read(3, "Hi I'm a text file\nthere are onl"..., 4096) = 57

Pretty interesting, huh? strace defaults to just showing the first 32 or so characters in a read, but it also lets us know that there are 57 characters (including special characters) in the file! After the text is read into memory, we see it writing it to the screen, and delivering the actual output of the text file. Now that's a relatively simplified example, but it helps us understand what's going on behind the scenes.

Real World Example: Finding Log Files

Let's look at a real world example where we'll use strace for a specific purpose: You can't figure out where your Apache logs are being written, and you're too lazy to read the config file (or perhaps you can't find it). Wouldn't it be nice to follow everything Apache is doing when it starts up, including opening all its log files? Well you can:

strace -Ff -o output.txt -e open /etc/init.d/httpd restart

We are executing strace and telling it to follow all forks (-Ff), but this time we'll output to a file (-o output.txt) and only look for 'open' system calls to keep some of the chaff out of the output (-e open), and execute '/etc/init.d/httpd restart'. This will create a file called "output.txt" which we can use to find references to our log files:

#cat output.txt | grep log
[pid 13595] open("/etc/httpd/modules/mod_log_config.so", O_RDONLY) = 4
[pid 13595] open("/etc/httpd/modules/mod_logio.so", O_RDONLY) = 4
[pid 13595] open("/etc/httpd/logs/error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 10
[pid 13595] open("/etc/httpd/logs/ssl_error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 11
[pid 13595] open("/etc/httpd/logs/access_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 12
[pid 13595] open("/etc/httpd/logs/cm4msaa7.com", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 13
[pid 13595] open("/etc/httpd/logs/ssl_access_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 14
[pid 13595] open("/etc/httpd/logs/ssl_request_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 15
[pid 13595] open("/etc/httpd/modules/mod_log_config.so", O_RDONLY) = 9
[pid 13595] open("/etc/httpd/modules/mod_logio.so", O_RDONLY) = 9
[pid 13596] open("/etc/httpd/logs/error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 10
[pid 13596] open("/etc/httpd/logs/ssl_error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 11
open("/etc/httpd/logs/access_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 12
open("/etc/httpd/logs/cm4msaa7.com", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 13
open("/etc/httpd/logs/ssl_access_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 14
open("/etc/httpd/logs/ssl_request_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 15

The log files jump out at you don't they? Because we know that Apache will want to open its log files when it starts, all we have to do is we follow all the system calls it makes when it starts, and we'll find all of those files. Easy, right?

Real World Example: Locating Errors and Failures

Another valuable use of strace involves looking for errors. If a program fails when it makes a system call, you'll want to be able pinpoint any errors that might have caused that failure as you troubleshoot. In all cases where a system call fails, strace will return a line with "= -1" in the output, followed by an explanation. Note: The space before -1 is very important, and you'll see why in a moment.

For this example, let's say Apache isn't starting for some reason, and the logs aren't telling ua anything about why. Let's run strace:

strace -Ff -o output.txt -e open /etc/init.d/httpd start

Apache will attempt to restart, and when it fails, we can grep our output.txt for '= -1' to see any system calls that failed:

$ cat output.txt | grep '= -1'
[pid 13748] open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/tls/i686/sse2/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/tls/i686/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/tls/sse2/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/tls/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/i686/sse2/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/i686/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/sse2/libperl.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/libutil.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/etc/gai.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 13748] open("/etc/httpd/logs/error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)

With experience, you'll come to understand which errors matter and which ones don't. Most often, the last error is the most significant. The first few lines show the program trying different libraries to see if they are available, so they don't really matter to us in our pursuit of what's going wrong with our Apache restart, so we scan down and find that the last line:

[pid 13748] open("/etc/httpd/logs/error_log", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0666) = -1 EACCES (Permission denied)

After a little investigation on that file, I see that some maniac as set the immutable attribute:

lsattr /etc/httpd/logs/error_log
----i-------- /etc/httpd/logs/error_log

Our error couldn't be found in the log file because Apache couldn't open it! You can imagine how long it might take to figure out this particular problem without strace, but with this useful tool, the cause can be found in minutes.

Go and Try It!

All major Linux distros have strace available — just type strace at the command line for the basic usage. If the command is not found, install it via your distribution's package manager. Get in there and try it yourself!

For a fun first exercise, bring up a text editor in one terminal, then strace the editor process in another with the -p flag (strace -p <process_id>) since we want to look at an already-running process. When you go back and type in the text editor, the system calls will be shown in strace as you type ... You see what's happening in real time!

-Lee

December 1, 2011

UNIX Sysadmin Boot Camp: Permissions

I hope you brought your sweat band ... Today's Boot Camp workout is going to be pretty intense. We're focusing on our permissions muscles. Permissions in a UNIX environment cause a lot of customer issues ... While everyone understands the value of secure systems and limited access, any time an "access denied" message pops up, the most common knee-jerk reaction is to enable full access to one's files (chmod 777, as I'll explain later). This is a BAD IDEA. Open permissions are a hacker's dream come true. An open permission setting might have been a temporary measure, but more often than not, the permissions are left in place, and the files remain vulnerable.

To better understand how to use permissions, let's take a step back and get a quick refresher on key components.

You'll need to remember the three permission types:

r w x: r = read; w = write; x = execute

And the three types of access they can be applied to:

u g o: u = user; g = group; o = other

Permissions are usually displayed in one of two ways – either with letters (rwxrwxrwx) or numbers (777). When the permissions are declared with letters, you should look at it as three sets of three characters. The first set applies to the user, the second applies to the group, and the third applies to other (everyone else). If a file is readable only by the user and cannot be written to or executed by anyone, its permission level would be r--------. If it could be read by anyone but could only be writeable by the user and the group, its permission level would be rw-rw-r--.

The numeric form of chmod uses bits to represent permission levels. Read access is marked by 4 bits, write is 2, and execute is 1. When you want a file to have read and write access, you just add the permission bits: 4 + 2 = 6. When you want a file to have read, write and execute access, you'll have 4 + 2 + 1, or 7. You'd then apply that numerical permission to a file in the same order as above: user, group, other. If we used the example from the last sentence in the previous paragraph, a file that could be read by anyone, but could only be writeable by the user and the group, would have a numeric permission level of 664 (user: 6, group: 6, other: 4).

Now the "chmod 777" I referenced above should make a little more sense: All users are given all permissions (4 + 2 + 1 = 7).

Applying Permissions

Understanding these components, applying permissions is pretty straightforward with the use of the chmod command. If you want a user (u) to write and execute a file (wx) but not read it (r), you'd use something like this:

chmod Output

In the above terminal image, I added the -v parameter to make it "verbose," so it displays the related output or results of the command. The permissions set by the command are shown by the number 0300 and the series (-wx------). Nobody but the user can write or execute this file, and as of now, the user can't even read the file. If you were curious about the leading 0 in "0300," it simply means that you're viewing an octal output, so for our purposes, it can be ignored entirely.

In that command, we're removing the read permission from the user (hence the minus sign between u and r), and we're giving the user write and execute permissions with the plus sign between u and wx. Want to alter the group or other permissions as well? It works exactly the same way: g+,g-,o+,o- ... Getting the idea? chmod permissions can be set with the letter-based commands (u+r,u-w) or with their numeric equivalents (eg. 400 or 644), whichever floats your boat.

A Quick Numeric chmod Reference

chmod 777 | Gives specified file read, write and execute permissions (rwx) to ALL users
chmod 666 | Allows for read and write privileges (rw) to ALL users
chmod 555 | Gives read and execute permissions (rx) to ALL users
chmod 444 | Gives read permissions (r) to ALL users
chmod 333 | Gives write and execute permissions (wx) to ALL users
chmod 222 | Gives write privileges (w) to ALL users
chmod 111 | Gives execute privileges (x) to ALL users
chmod 000 | Last but not least, gives permissions to NO ONE (Careful!)

Get a List of File Permissions

To see what your current file permissions are in a given directory, execute the ls –l command. This returns a list of the current directory including the permissions, the group it's in, the size and the last date the file was modified. The output of ls –l looks like this:

ls -l Output

On the left side of that image, you'll see the permissions in the rwx format. When the permission begins with the "d" character, it means that object is a directory. When the permission starts with a dash (-), it is a file.

Practice Deciphering Permissions

Let's look at a few examples and work backward to apply what we've learned:

  • Example 1: -rw-------
  • Example 2: drwxr-x---
  • Example 3: -rwxr-xr-x

In Example 1, the file is not a directory, the user that owns this particular object has read and write permissions, and when the group and other fields are filled with dashes, we know that their permissions are set to 0, so they have no access. In this case, only the user who owns this object can do anything with it. We'll cover "ownership" in a future blog, but if you're antsy to learn right now, you can turn to the all-knowing Google.

In Example 2, the permissions are set on a directory. The user has read, write and execute permissions, the group has read and execute permissions, and anything/anyone besides user or group is restricted from access.

For Example 3, put yourself to the test. What access is represented by "-rwxr-xr-x"? The answer is included at the bottom of this post.

Wrapping It Up

How was that for a crash course in Unix environment permissions? Of course there's more to it, but this will at least make you think about what kind of access you're granting to your files. Armed with this knowledge, you can create the most secure server environment.

Here are a few useful links you may want to peruse at your own convenience to learn more:

Linuxforums.org
Zzee.com
Comptechdoc.org
Permissions Calculator

Did I miss anything? Did I make a blatantly ridiculous mistake? Did I use "their" when I should have used "they're"??!!... Let me know about it. Leave a comment if you've got anything to add, suggest, subtract, quantize, theorize, ponderize, etc. Think your useful links are better than my useful links? Throw those at me too, and we'll toss 'em up here.

Are you still feeling the burn from your Sysadmin Boot Camp workout? Don't forget to keep getting reps in bash, logs, SSH, passwords and user management!

- Ryan

Example 3 Answer

November 15, 2011

UNIX Sysadmin Boot Camp: User Management

Now that you're an expert when it comes to bash, logs, SSH, and passwords, you're probably foaming at the mouth to learn some new skills. While I can't equip you with the "nunchuck skills" or "bowhunting skills" Napoleon Dynamite reveres, I can help you learn some more important — though admittedly less exotic — user management skills in UNIX.

Root User

The root user — also known as the "super user" — has absolute control over everything on the server. Nothing is held back, nothing is restricted, and anything can be done. Only the server administrator should have this kind of access to the server, and you can see why. The root user is effectively the server's master, and the server accordingly will acquiesce to its commands.

Broad root access should be avoided for the sake of security. If a program or service needs extensive abilities that are generally reserved for the root user, it's best to grant those abilities on a narrow, as-needed basis.

Creating New Users

Because the Sysadmin Boot Camp series is geared toward server administration from a command-line point of view, that's where we'll be playing today. Tasks like user creation can be performed fairly easily in a control panel environment, but it's always a good idea to know the down-and-dirty methods as a backup.

The useradd command is used for adding users from shell. Let's start with an example and dissect the pieces:

useradd -c "admin" -d /home/username -g users\ -G admin,helpdesk -s\ /bin/bash userid

-c "admin" – This command adds a comment to the user we're creating. The comment in this case is "admin," which may be used to differentiate the user a little more clearly for better user organization.
-d /home/username – This block sets the user's home directory. The most common approach is to replace username with the username designated at the end of the command.
-g users\ – Here, we're setting the primary group for the user we're creating, which will be users.
-G admin,helpdesk – This block specifies other user groups the new user may be a part of.
-s\ /bin/bash userid – This command is in two parts. It says that the new user will use /bin/bash for its shell and that userid will be the new user's username.

Changing Passwords

Root is the only user that can change other users' passwords. The command to do this is:

passwd userid

If you are a user and want to change your own password, you would simply issue the passwd command by itself. When you execute the command, you will be prompted for a new entry. This command can also be executed by the root user to change the root password.

Deleting Users

The command for removing users is userdel, and if we were to execute the command, it might look like this:

userdel -r username

The –r designation is your choice. If you choose to include it, the command will remove the home directory of the specified user.

Where User Information is Stored

The /etc/passwd file contains all user information. If you want to look through the file one page at a time — the way you'd use /p in Windows — you can use the more command:

more /etc/passwd

Keep in mind that most of your important configuration files are going to be located in the /etc folder, commonly spoken with an "et-see" pronunciation for short. Each line in the passwd file has information on a single user. Arguments are segmented with colons, as seen in the example below:

username:password:12345:12345::/home/username:/bin/bash

Argument 1 – username – the user's username
Argument 2 – password – the user's password
Argument 3 – 12345 – the user's numeric ID
Argument 4 – 12345 – the user group's numeric ID
Argument 5 – "" – where either a comment or the user's full name would go
Argument 6 - /home/username – the user's home directory
Argument 7 - /bin/bash – the user's default console shell

Now that you've gotten a crash course on user management, we'll start going deeper into group management, more detailed permissions management and the way shadow file relates to the passwd usage discussed above.

-Ryan

November 11, 2011

UNIX Sysadmin Boot Camp: Passwords

It's been a while since our last UNIX Sysadmin Boot Camp ... Are you still with me? Have you kept up with your sysadmin exercises? Are you starting to get comfortable with SSH, bash and your logs? Good. Now I have an important message for you:

Your password isn't good enough.

Yeah, that's a pretty general statement, but it's shocking how many people are perfectly fine with a six- or eight-character password made up of lowercase letters. Your approach to server passwords should be twofold: Stick with it and Be organized.

Remembering a 21-character password like ^@#*!sgsDAtg5t#ghb%!^ may seem daunting, but you really don't have to remember it. For a server, secure passwords are just as vital as any other form of security. You need to get in the habit of documenting every username and password you use and what they apply to. For the sake of everything holy, keep that information in a safe place. Folding it up and shoving it in your socks is not advised (See: blisters).

Want to make your approach to password security even better? Change your passwords every few months, and make sure you and at least one other trusted colleague or friend knows where to find them. You're dealing with sensitive material, but you can never guarantee that you will be available to respond to a server-based emergency. In these cases, your friends and co-workers end up scrambling through bookshelves and computer files to find any trace of useful information.

Having been one of the abovementioned co-workers in this situation, I can attest that it is nearly impossible to convince customer service that you are indeed a representative of the company having no verification information or passwords to provide.

Coming soon: Now you've got some of the basics, what about the not-so-basics? I'll start drafting some slightly more advanced tips for the slightly more advanced administrator. If you have any topics you'd like us to cover, don't hesitate to let us know in a comment below.

-Ryan

August 29, 2011

UNIX Sysadmin Boot Camp: Your Logs and You

We're a few exercises into UNIX Sysadmin Boot Camp, and if you're keeping up, you've learned about SSH and bash. In those sessions, our focus was to tell the server what we wanted it to do. In this session, we're going to look at the logs of what the server has done.

Logs are like an overbearing mother who sneakily follows her teenage son around and writes down the addresses of each house he visits. When he realizes he lost a really important piece of baseball history at one of those houses, he'll be glad he has that list so he can go desperately search for the soon-to-be-noticed missing bat. Ahem.

MAKE BEST FRIENDS WITH THIS DIRECTORY: /var/log/

When something goes wrong – when there's hitch in the flux capacitor or too many gigawatts in the main reactor – your logs will be there to let you know what's going on, and you can pinpoint the error with educated vengeance. So treat your logs with respect.

One of the best places to start harnessing this logged goodness is /var/log/messages. This log file reports all general errors with network and media, among other things. As you add to and learn your server's command line environment, you'll see specific logs for applications as well, so it's a very good idea to keep a keen eye on these. They just might save your life ... or server.

Some of the most commonly used logs (may vary with different Linux distributions):

  • /var/log/message – General message- and system-related info
  • /var/log/cron.log – Cron job logs
  • /var/log/maillog – Mail server logs
  • /var/log/kern.log – Kernel logs
  • /var/log/httpd/ – Apache access and error logs
  • /var/log/boot.log – System boot logs
  • /var/log/mysqld.log – MySQL database server logs
  • /var/log/secure – SSH authentication logs
  • /var/log/auth.log – Authentication logs
  • /var/log/qmail/ – Qmail log directory (more files inside this directory)
  • /var/log/utmp or /var/log/wtmp – Login records file
  • /var/log/yum.log – Yum log files

There are plenty more in-depth logs – particularly involving raw system components – and others that act similarly to logs but are a bit more active like tcpdumps. Those are a little more advanced to interpret, so I'll save them for another guide and another day.

At this point in our UNIX workout series, you're familiar with the command line, you know the basics of how to tell your server what to do and you just learned how to let the server tell you what it's done. There's still a bit of work to be done before you can call yourself a UNIX ninja, but you're well on your way. In our next installment, we're going to take a step back and talk about p455w0rd5.

Keep learning.

-Ryan

August 15, 2011

UNIX Sysadmin Boot Camp: bash

Welcome back to UNIX Sysadmin Boot Camp. You've had a few days to get some reps in accessing your server via SSH, so it's about time we add some weight to your exercise by teaching you some of the tools you will be using regularly to manage your server.

As we mentioned earlier in this series, customers with control panels from cPanel and Parallels might be tempted to rely solely on those graphical interfaces. They are much more user-friendly in terms of performing routine server administration tasks, but at some point, you might need to get down and dirty on the command line. It's almost inevitable. This is where you'll use bash commands.

Here are some of the top 10 essential commands you should get to know and remember in bash. Click any of the commands to go to its official "manual" page.

  1. man – This command provides a manual of other bash commands. Want more info on a command? Type man commandname, and you'll get more information about "commandname" than you probably wanted to know. It's extremely useful if you need a quick reference for a command, and it's often much more detailed and readable than a simple --help or --h extension.
  2. ls – This command lets you list results. I showed you an example of this above, but the amount of options that are available to you with this command are worth looking into. Using the "manual" command above, run man ls and check out the possibilities. For example, if you're in /etc, running ls -l /etc will get you a slightly more detailed list. My most commonly used list command is ls -hal. Pop quiz for you (where you can test your man skills): What does the -hal mean?
  3. cd – This command lets you change directories. Want to go to /etc/? cd /etc/ will take you there. Want to jump back a directory? cd .. does the trick.
  4. mv – This command enables you to move files and folders. The syntax is mv originalpath/to/file newpath/to/file. Simple! There are more options that you can check out with the man command.
  5. rm – This command enables you to remove a file or directory. In the same vein as the mv command, this is one of those basic commands that you just have to know. By running rm filename, you remove the "filename" file.
  6. cp – This command enables you to copy files from one place to another. Want to make a backup of a file before editing it? Run cp origfile.bla origfile.bak, and you have a backup in case your edit of origfile.bla goes horrendously wrong and makes babies cry. The syntax is simply: cp /source /destination. As with the above commands, check out the manual by running man cp for more options.
  7. tar – On its own, tar is a command to group a bunch of files together, uncompressed. These files can then be compressed into .gzip format. The command can be used for creating or extracting, so it may be a good idea to familiarize yourself with the parameters, as you may find yourself using it quite often. For a GUI equivalent, think 7-zip or WinRAR for Windows.
  8. wget – I love the simplicity of this little command. It enables you to "get" or download a target file. Yes, there are options, but all you need is a direct link to a file, and you just pull one of these: wget urlhere. Bam! That file starts downloading. Doesn't matter what kind of file it is, it's downloaded.
  9. top – This handy little binary will give you a live view of memory and CPU usage currently affecting your machine, and is useful for finding out where you need to optimize. It can also help you pinpoint what processes may be causing a slowdown or a load issue.
  10. chmod – This little sucker is vital to make your server both secure and usable, particularly when you're going to be serving for the public like you would with a web server. Combine good usage of permission and iptables, and you have a locked down server

When you understand how to use these tools, you can start to monitor and track what's actually happening on your server. The more you know about your server, the more effective and efficient you can make it. In our next installment, we'll touch on some of the most common server logs and what you can do with the information they provide.

Did I miss any of your "essential" bash commands in my top 10 list? Leave a comment below with your favorites along with a quick explanation of what they do.

-Ryan

August 12, 2011

UNIX Sysadmin Boot Camp: An Intro to SSH

You've got a 'nix box set up. For some reason, you feel completely lost and powerless. It happens. Many a UNIX-related sob has been cried by confused and frustrated sysadmins, and it needs to stop. As a techie on the front lines of support, I've seen firsthand the issues that new and curious sysadmins seem to have. We have a lot of customers who like to dive head-first into a new environment, and we even encourage it. But there's quite a learning curve.

In my tenure at SoftLayer, I've come across a lot of customers who rely almost entirely on control panels provided by partners like cPanel and Parallels to administer their servers. While those panels simplify some fairly complex tasks to the touch of a button, we all know that one day you're going to have to get down and dirty in that SSH (Secure Shell) interface that so many UNIX server newbies fear.

I'm here to tell you that SSH can be your friend, if you treat it right. Graphical user interfaces like the ones used in control panels have been around for quite a while now, and despite the fact that we are in "the future," the raw power of a command line is still unmatched in its capabilities. It's a force to be reckoned with.

If you're accustomed to a UNIX-based interface, this may seem a little elementary, but you and I both know that as we get accustomed to something, we also tend to let those all-important "basics" slip from our minds. If you're coming from a Windows background and are new to the environment, you're in for a bit of a shell shock, no pun intended. The command line is fantastically powerful once you master it ... It just takes a little time and effort to learn.

We'll start slow and address some of the most common pain points for new sysadmins, and as we move forward, we'll tackle advanced topics. Set your brain to "absorbent," and visualize soaking up these UNIX tips like some kind of undersea, all-knowing, Yoda-like sea sponge.

SSH

SSH allows data to be exchanged securely between two networked devices, and when the "network" between your workstation and server is the Internet, the fact that it does so "securely" is significant. Before you can do any actual wielding of SSH, you're going to need to know how to find this exotic "command line" we've talked so much about.

You can use a third-party client such as PuTTY, WinSCP if your workstation is Windows-based, or if you're on Linux or Mac, you can access SSH from your terminal application: ssh user@ipaddress. Once you've gotten into your server, you'll probably want to find out where you are, so give the pwd command a try:

user@serv: ~$ pwd
/home/user
user@serv: ~$

It's as easy as that. Now we know we're in the /home/user directory. Most of the time, you'll find yourself starting in your home directory. This is where you can put personal files and documents. It's kind of like "My Documents" in Windows, just on your server.

Now that you know where you are, you'll probably want to know what's in there. Take a look at these commands (extracted from a RedHat environment, but also usable in CentOS and many other distributions):

    user@serv: /usr/src $ ls    
This will give you a basic listing of the current directory.

    user@serv: /usr/src $ ls /usr/src/redhat    
This will list the contents of another specified directory.

    user@serv: /usr/src $ ls ./redhat    
Using a "relative pathname," this will perform the same action as above.

    user@serv: /usr/src $ ls redhat    
Most of the time, you'll get the same results even without the "./" at the beginning.

    user@serv: /usr/src $ cd /usr/src/redhat/    
This is an example of using the cd command to change directories to an absolute pathname.

    user@serv: /usr/src $ cd redhat    
This is an example of using the cd command to change directories to a relative pathname.

    user@serv: /usr/src/redhat $ cd /usr/src    
To move back on directory from the working directory, you can use the destination's absolute path.

    user@serv: /usr/src/redhat $ cd ..    
Or, since the desired directory is one step down, you can use two dots to move back.

You'll notice many similarities to the typical Windows DOS prompts, so it helps if you're familiar with navigating through that interface: dir, cd, cd .., cd /. Everything else on the other hand, will prove to be a bit different.

Now that you're able to access this soon-to-be-powerful-for-you tool, you need to start learning the language of the natives: bash. In our next installment, we'll take a crash course in bash, and you'll start to get comfortable navigating and manipulating content directly on your server.

Bookmark the SoftLayer Blog and come back regularly to get the latest installments in our "UNIX Sysadmin Boot Camp" series!

-Ryan

April 21, 2011

Standing Cloud: Tech Partner Spotlight

This is a guest blog from Dave Jilk of Standing Cloud, a SoftLayer Tech Marketplace Partner specializing in automating cloud application deployment and streamlining management.

Standing Cloud's Application Layer for the SoftLayer Cloud

When we first came across the SoftLayer Cloud, we were impressed by the breadth of what it allowed the user to do through a web browser. Beyond the basic infrastructure capabilities of provisioning servers and storage (that you can find from other providers), the SoftLayer console and API allow full access to the networking, security, and server console capabilities of the system. It's as though you can take over the mind of a network administrator and have him or her do your bidding.

A host of networking features that come with the offering with the offering were especially exciting to us (see the end of this post for details). Now, when I say "us," I mean our Founding System Architect, Joel Wampler. Joel breathes network protocols, eats open source technology stacks for most of his meals and speaks in Linux command line. I, in contrast, wouldn't have the first idea how to make good use of those network features, but his amazement was enough to be contagious. I'm a software developer by trade, not a systems or network architect, and increasingly I'm mostly a business user ... And as I've transitioned to more of a business-centric focus, I've become the target demographic for Standing Cloud. The distinction between business users in a technical company and technical users in a business are why the Standing Cloud service is so powerful on the SoftLayer Cloud.

For business users and application developers, what we call the "dark cloud" (IaaS without an application layer) is not very useful and relatively intimidating. Business users primarily want SaaS - the ability to use applications without any consideration of the mechanics. Developers want APaaS or PaaS - the ability to customize existing applications or build them from scratch, without any (or much) consideration of the underlying technology stack or infrastructure.

Standing Cloud delivers all of this, the way it ought to be, on the SoftLayer Cloud. An end user can deploy a pre-packaged application in minutes with just a few clicks. We incorporate best practices so you take advantage of all the Standing Cloud and SoftLayer capabilities without having to know about them. As a developer, you can deploy one of these applications and then customize the code without having to think about system security configuration, memory parameters or other system administration issues. Just sync with your repository on Github or Subversion and the code will be uploaded and ready to run.

These "startup" benefits are just the beginning, though. Standing Cloud makes it easy to "move" your application - to a different server if you need more (or less) capacity, to a shared server if you are a solution provider and want to reduce the cost to your clients, or to a "test drive" if you want to experiment with an upgrade or code changes but don't want to affect the production deployment. We monitor the application and its status 24x7, and you receive notifications if it is down or performing slowly - and optionally, we can automatically revive it on a new server if the situation warrants.

If you want to open the hood, you can. Because of the way Standing Cloud deploys and manages applications, an adventurous end-user can easily access the application code and the PaaS layer. And a developer who has a special need can dive into the infrastructure layer through our browser based terminal window. Unlike most SaaS and PaaS systems, Standing Cloud keeps these details out of your hair but does not prevent you from accessing and changing them.

If you are just getting started with the SoftLayer Cloud, and you are not a system administrator, I highly recommend that you explore the Standing Cloud Application Network. Instead of being faced with the "dark cloud," you'll have more than 80 application choices (and we take requests if your favorites aren't included yet!). For developers, we offer language support for Java, Ruby, PHP, and Python.

If you are a system administrator and an existing SoftLayer customer, you may want to consider Standing Cloud as a time saver. There are so many powerful (and challenging!) capabilities to manage on SoftLayer for your complex, mission critical applications. Is deploying and locking down a server running Drupal or SugarCRM the best use of your time?

Finally, we would love to hear from you. Send an email to support@standingcloud.com, and tell us what you need, how you want to use the cloud, and what we could do better. Our users drive our product evolution, so please tell us what you think!

And for those of you who are curious about the network features I mentioned Joel salivating over at the start of the post, here are a few highlights:

  • Up to Gigabit speeds both internally and to the Internet
  • Private IP blocks are assigned as a VLAN so that other customers cannot access them
  • IPv6 capable
  • Free inbound bandwidth, and 1000GB of outbound bandwidth included
  • Ability to share an IP address across multiple machines (excellent for high availability solutions)

-Dave Jilk, Standing Cloud

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
April 20, 2011

3 Bars | 3 Questions: SoftLayer Managed Hosting

I know you expected to see a video interview with Paul Ford the next time a 3 Bars | 3 Questions episode rolled across your desk, but I snuck past him for a chance in the spotlight this week. Kevin and I jumped on a quick video chat to talk about the Sales Engineering team, and because of our recent release of SoftLayer Managed Hosting, two of the three questions ended up being about that news:

You should be seeing a blog from Nathan in the next half hour or so with more detail about how we approached managed hosting, so you'll have all the background you need to springboard into that post after you watch this video.

If you've heard everything you need to hear about managed hosting and want to start the process of adding it to servers on your account, visit http://www.softlayer.com/solutions/managed-hosting/ or chat with a sales rep, and they can help you get squared away. If you're not sure whether it's a good fit, ask for a sales engineer to consult ... They're a great group with a pretty awesome manager. :-)

Paul, sorry for stealing your spot in the 3 Bars | 3 Questions rotation! I'm handing the baton back over to you to talk about TechWildcatters and the Technology Partners Marketplace in the next episode.

-Tam

Subscribe to sysadmin