There are four “roles” that plug-ins can fulfill, which will be configured in our who.ini:

• IIdentifier: After a user submits their credentials, this plug-in is responsible for stripping the information and retrieving the info–such as a username/password from a log in page, or retrieving a single sign-on (SSO) key. This is then used by the…
• IAuthenticator: After a user’s information has been retrieved, the authenticator will determine whether or not the presented information is correct. For example, if it was a SSO key, this plug-in would be used to verify that it is still valid. If it were a username and password, this would verify that the information is correct.
• IChallenger: When a user is either not logged in–or has failed to login–the challenger will present the user with a page allowing them ao authenticate.
• IMetadataProvider: When logged in, this plug-in retrieves metadata based on the IIdentifier. (optional)

For this first part, I’ll focus primarily on getting two of the built-in plug-ins configured to fulfill these. First off, lets create a blank project to get things started.

$ paster create -t pylons authapp template_engine=mako sqlalchemy=False
Selected and implied templates:
Pylons#pylons  Pylons application template
[...]
$ cd authapp
$ paster controller secret
Creating [...]

# Add to imports
from repoze.who.config import make_middleware_with_config as make_who_with_config
[...]
def make_app(global_conf, full_stack=True, static_files=True, **app_conf):
[...]
    # CUSTOM MIDDLEWARE HERE (filtered by error handling middlewares)
    if asbool(full_stack):
        # Handle Python exceptions
        app = ErrorHandler(app, global_conf, **config['pylons.errorware'])
        # Display error documents for 401, 403, 404 status codes (and
        # 500 when debug is disabled)
        if asbool(config['debug']):
            app = StatusCodeRedirect(app)
        else:
            app = StatusCodeRedirect(app, [400, 401, 403, 404, 500])
 
    # BEGIN REPOZE.WHO CODE
    app = make_who_with_config(app,
                               global_conf,
                               app_conf['repoze.who.ini'],
                               app_conf['repoze.who.log.file'],
                               app_conf['repoze.who.log.level'])
    # END REPOZE.WHO CODE

[app:main]
repoze.who.ini = %(here)s/who.ini
repoze.who.log.file = stdout
repoze.who.log.level = debug

[general]
request_classifier = repoze.who.classifiers:default_request_classifier
challenge_decider = repoze.who.classifiers:default_challenge_decider
 
[identifiers]
plugins =
 
[authenticators]
plugins =
 
[challengers]
plugins =

$ paster serve development.ini
Starting server in PID 10186.
serving on http://127.0.0.1:5000

[identifiers]
plugins = basicauth
 
[challengers]
plugins = basicauth
 
[plugin:basicauth]
use = repoze.who.plugins.basicauth:make_plugin
realm = some_unique_security_realm

andrew:2kRr2LXOu9cp6
robert:2ML8KpK./SeQI

[authenticators]
plugins = htpasswd
 
[plugin:htpasswd]
use = repoze.who.plugins.htpasswd:make_plugin
filename = %(here)s/passwd

from decorator import decorator
from pylons import  request
from pylons.controllers.util import abort
 
def user_is_authenticated():
    """ Returns True if a user is authenticated, False otherwise """
    identity = request.environ.get('repoze.who.identity')
    return identity is not None
 
@decorator
def authenticated(func, *args, **kwargs):
    """ Decorator that will use Pylons' abort method to trigger the repoze.who
        middleware that this request needs to be authenticated. """
    if not user_is_authenticated():
        abort(401)
    return func(*args, **kwargs)

As I use Linux and BSD on a day-to-day basis, there are some commands that are simply a godsend once you learn them.  Some are common but little is known about how they work; others are usually unheard of until the day someone demonstrates its use to you, and you wonder how you’ve lived so long without using that little gold nugget of knowledge.

This is a great tool for several reasons.  First off, most people use it as a way of sending information; that is, you can use it to literally cat information across the network, like so:

cat data.txt | nc host.example.com

This will take the contents of http_data.txt and send them over the network to the specified host.  But did you know that nc can also receive data as well?  You can launch a listen-only server listening on port 8080 on localhost using the following:

# Output any incoming requests on port 8080!
nc -l 8080

If I were to telnet to port 8080, I would be able to send information over the network.  This is especially useful if you have a program sending data, but need a quick and easy way of picking up the data.  On top of all that, you can have the netcat “server” send responses from stdin–that is, if your application sends a HELO, you can respond right back.  Pretty nifty, eh?

I remember when I was younger, every time I wanted to repeatedly check something (such as, while waiting for someone to upload a file), I’d either setup a loop or repeatedly run the command.  Little did I know, there was a command that already repeated a command for you; “watch” and learn.  Say I wanted to watch a directory for new files from an interactive terminal; perhaps I’m waiting for a client to upload something, or maybe I’m waiting for a process to finished.  I could periodically type ls to see if the file is there; or I could use watch.

# Repeatedly run the ls command on /tmp
watch ls /tmp

This will, by default, run the command every two seconds.  Using -n, I can configure this time however I want.  But what if I’m watching something like memory usage, and I want to be able to look and see what’s changed between command runs?  Well, watch has that too!

# Highlight differences between runs
watch -d ls /tmp
 
# Ditto, only this time, keep the changes across ALL runs;
# So if I step away for an hour, it will show ALL new files
watch -d  --cumulative ls /tmp

Isn’t that just the best little command you never knew about?  The man page gives even more examples.

Every Linux users follows the same process.  First, they discover back ticks and use it to pipe the output of one command to another:

# If you're on 2.6.23, better hope there are less than 32k results
rm -f `find /tmp -type f`

Then, you learn about xargs, and realize the folly of your ways:

# Uhoh, better hope there aren't any spaces, quotes,
#   or other escape characters!

find /tmp -type f | xargs rm -f

Soon, you learn to use null bytes to filter results to avoid those nasty line breaks:

# Good luck trying to debug this without altering the command
find /tmp -type f -print0 | xargs -0 rm -f

And what if you try to read the output?  What followed was the result of many years of frustration with the default state of the whitespace delimiter from the command line: parallel.  As a GNU utility, its available on pretty much any *nix platform worth its salt.  It operates identically to xargs, only it uses a line-by-line algorithm to pass arguments.  That is, spaces, escape characters, etc., no longer break up your output.

find /tmp -type f | parallel rm -f

Got a quote in your filename?  No problem!  Got spaces?  Its been handled.  parallel is pretty much what most people expect when using xargs.  And, because its part of the GNU tool set (and distributed under the GPL), you have no reason to not start using it right this very moment.

Like parallel, the step-by-step learning process of killing misbehaving processes usually goes like this:

ps aux | grep java
kill

Then, you learn about killall, which means you can kill any and all processes based on their process name:

# Kill all `java' processes
killall java

But lets say you’re running several instances of Java, but you only want to kill the ones associated with tomcat6?  killall won’t work, as you’re no longer killing based on the process name.  You can go back to the first method, but this is a lot of time and overheard for something that SHOULD be automated–and easy, considering how common of a task it is.  This is where pkill comes into play; instead of a process name or a pid, pkill takes a pattern–it can be a simple line of text, or an extended regular expression–and kills any processes matching it.  That is, I can now say:

# Match anything where tomcat is in the command name;
# `java-tomcat', but NOT `java -jar tomcat6.jar'
pkill tomcat
 
# Match anything where tomcat is in the FULL command line
# `java-tomcat' <em>and</em> `java -jar tomcat6.jar'
pkill -f tomcat

pgrep serves much the same purpose, only it will return matching pids instead of sending the processes signals.

A lot of people have probably seen this command at least once in their life, but may not have given it any thought.  I know that in the times that I have had a need for it, however, I would have had no alternatives without it.  tee is a tool that allows you to copy stdout to a file or files, while not disrupting stdout itself.  That is, I can now log output while display it to the screen.  For example, lets say I want to run a find command that not only stores the logs, but allows me to look at it.  I could pipe all output to the file and then view the file, but this runs into issues where its a continuous process that may not finish immediately–and I may not want to worry about backgrounding the process. For example, lets say I have a job to restart some servers; I want to be able to check the process as its running (and maybe even give it input as it runs), but I also want the entire session to be logged.

./run_some_long_task.sh | tee output.log

Now, anytime there’s output, it will be recorded to stdout AND output.log.  Amazing, right?  I find this especially useful in Hudson jobs where I want the output to be recorded in the build log, but I also want to be able to parse the output after the command has run.  It also lends itself to cron jobs, where the output can be simultaneously mailed to a user and written to disk.

There you have it, a list of five commands you’ve probably never heard of, or never took the time to investigate!  I know I would have been at a major loss for some of these commands, and I feel that these are generally not in most users’ arsenals of commands.  If you’re a hardcore console user, there’s absolutely no reason you shouldn’t always be using these.  But for those of you who are not Linux gurus, I can promise you one thing–one day, in some random situation, you WILL be thankful for having learned these commands!

You can grab a copy of the source code here, but before you do, check with your package manager of choice.  Macports, Debian (and Ubuntu flavors), OpenSUSE, etc., all have native versions for your enjoyment–most likely under the obvious package name, tmux.

Both screen and tmux provide multiple buffers, the ability to detach/reattach sessions, locking, etc..  Where tmux really shines is the ability to split itself vertically and horizontally–something the screen team has lagged behind on implementing themselves.  Fans of windows managers, however, will really appreciate the master/stacking approach to screens, allowing you to have a selection of stacked terminal windows on the side, with a primary work window in the center.

Its important that we learn the terminology in tmux, most importantly servers, clients, sessions, windows, panes, and pseudo-terminals.  It breaks down like so:

• The single server manages all sessions.
• Sessions contains one or more windows.
• Windows are a collection of panes.
• Panes are simply ways of laying out pseudo terminals.
• Clients allow the user to connect to a session.

So the hierarchy isn’t hard to follow–in fact, I personally find it very easy to grasp due to the nature of the terms (i.e., window panes).  So lets gets this party started!

First and foremost, start up your client, tmux.  Since we haven’t configured or run this at all, the client would start-up, start a server, and create a session with a single window in it.  This can be accomplished by simply typing `tmux’ in the command prompt.  Before you start mashing C-a (the default screen command key), here’s one of the quirks–in tmux, the default command key is C-b, a choice I found to be extremely awkward on the fingers.  And, there’s the muscle memory.  Fortunately, the tmux FAQ shows us how to set it to whatever we want; simply type C-b : from within tmux following in the terminal to disable C-b and use C-a (or a key of your choosing):

set -g prefix C-a
unbind C-b
bind C-a send-prefix

From here on, assume that all bolded commands listed are preceded by the command key you set above.

One of the most helpful things I’ve found about tmux is the ability to show the list of keybindings from anywhere, using ?.

There are a few common keybindings you’ll want to keep in mind.  First, lets look at the ones with similar functions in GNU screen:

Action	GNU Screen	tmux
Create new window	c	c
Split window (horizontal)	S	"
Rename window	A	,
Detach	d	d
Kill window	k, K	&
Make window fullscreen	Q	!
Access program command prompt	:	:

Layouts!

With tmux, you can take a single window (literally, one pane) and split it into several panes, forming a rudimentary layout.  Lets start by splitting the screen vertically by pressing % a few times, which should give us several panes.  Now, we can cycle through the predefined layouts by using Space.  Once we have a layout selected, lets learn how to navigate within it.

• q displays the open panes in your current window
• Up/o selects the next pane, counter-clockwise
• Down selects the Next/Previous pane
• C-o rotates the panes counter-clockwise

That’s all there is to it!  90% of tmux is learning to mentally unbind the screen shortcuts, and rebind them to tmux–which pays off.  I hope this has given GNU Linux users a new alternative to screen–or at the very least, a new toy to play around with.  Feel free to ask questions!