Sudo allows users to run commands as root while logging the command and its arguments.

In short, sudo first authenticates a user using their own password, then checks /etc/sudoers to see what sudo permissions (if any) the user has, then executes and logs the command if the user is allowed.

You will see that there are a variety of options, but let's look at this line which is enabled on Fedora 15 by default:

%wheel ALL=(ALL) ALL

This means that all users in the wheel group can run all commands as root on all systems that this sudoers file lives on. The sudoers file is designed so that you can have a single configuration live on various hosts and allow or disallow users by hostname.

Since this line is enabled in sudoers, quit visudo by exiting the editor and check what groups your username belongs to. In this example, my username is victor.

root# groups victor
victor : victor

In order to give the user full access to root using sudo, add the user to the wheel group.

Now, as your user, you can use sudo to run commands as root. The first time you run sudo, some warnings and advice will be printed to the screen.

bash$ sudo /usr/bin/test

Type in your password (not the root password), and you will successfully run /usr/bin/test as root. If the default configuration is kept, sudo will not prompt a user for their password until after 5 minutes from their last sudo command.

By default (on Fedora 15), sudo logs its usage into /var/log/secure by configuration of /etc/sudoers and /etc/rsyslog.conf. Normally, you need root permissions to read /var/log/secure, but now that you have sudo access, you can read the file. Read the sudo logs with something like this:

bash$ sudo grep sudo /var/log/secure

Finally, see /etc/sudoers and the SUDOERS(5) man page for syntax on how to configure access rights for users based on group, command and hostname.

Unless configured to do otherwise, most HTTP and FTP servers will supply you with identifying information in the form of a server header. Using Perl'sLWP::UserAgent, you can connect to a server and display the header information.

You can connect to a socket using Bash by using exec and redirecting to and from the pseudo-path /dev/tcp/<hostname>/<port> or /dev/udp/<hostname>/<port>. For instance, to connect to your localhost SSH port using TCP:

exec 3<>/dev/tcp/localhost/22

Then, use cat and echo to read or write to the socket. Here is an example read:

cat <&3
SSH-2.0-OpenSSH_5.6

Notice that there is no such file as /dev/tcp or /dev/udp. Bash interprets the pseudo-path.

ls -l /dev/tcp
ls: cannot access /dev/tcp: No such file or directory

ls -l /dev/udp
ls: cannot access /dev/udp: No such file or directory

As another example, maybe you want to download a webpage:

exec 3<>/dev/tcp/www.fedora.org/80
echo -e "GET /\n" >&3
cat <&3

Finally, let's say you wanted to connect to an IRC server. Here is an example:

Most digital cameras will insert metadata into images. This metadata is stored using the exchangeable image file format (EXIF) and can contain camera specifications, exposure settings, thumbnails, GPS coordinates and more. This article outlines some Linux command line tools you can use for reading, editing and removing EXIF metadata from images.

Want to be faster at the Linux command line interface? Since most Linux distributions provide Bash as the default CLI, here are some Bash tricks that will help cut down the amount of typing needed to execute commands. Feel free to comment and share your own speed tricks.

This is my most used shortcut. Hit Control-R and begin to type a string. You immediately get the last command in your Bash history with that string. Hit Control-R again to cycle further backwards in your history.

For instance, type the following and hit Enter.

grep root /etc/passwd

Then hit Control-R and begin to type 'grep'.

Control-R
(reverse-i-search)`gre': grep root /etc/passwd

When you see the original command listed, hit Enter to execute it. Alternatively, you can also hit the Right-Arrow to edit the command before running it.

Use History Expansion

Bash's command history can be referenced using the exclamation mark. For instance, typing two exclamation marks (!!) will re-execute the last command. The next example executes date twice:

date
!!

If you are interested in more than just the last command executed, type history to see a numbered listing of your Bash's history.

history
39 grep root /etc/passwd
40 date
41 date
42 history

Since grep root /etc/passwd is command number 39, you can re-execute it like so:

!39

You can also reference Bash's history using a search string. For instance, the following will run the last command that started with 'grep'.

!grep

Note, you can set the number of commands stored in your history by setting HISTSIZE.

Bash allows for commands, or sets of commands, to be aliased into a single instruction. Your interactive Bash shell should already load some useful aliases from /etc/profile.d/. For one, you probably have ll aliased to ls -l.

Note that you can also string together commands. The follow will alias gohome as cd , then run ls. Note that running cd without any arguments will change directory to your $HOME directory.

alias gohome='cd; ls'

Better yet, only run ls if the cd is successful:

alias gohome='cd && ls || echo "error($?) with cd to $HOME"'

More complex commands can be written into a Bash function. Functions will allow you to provide input parameters for a block of code. For instance, let's say you want to create a backup function that puts a user inputted file into ~/backups.

Bash is the default command line interface for many Linux distributions and a powerful scripting language. Here are some suggestions that will keep your Bash scripts efficient and lean. Feel free to comment with your own suggestions.

Avoid Full Paths to Bash Builtins

Bash has many builtins that can be used instead of calling external commands. You should leverage the builtin commands whenever possible since it avoids calling a subcommand from the system.

Since Bash has builtins for some commands found in /bin and /usr/bin (such as echo), avoid using the full path for these commands and the builtin will be used.

# avoid this
/bin/echo "hello"

Use the Bash builtin instead:

echo "hello"

Other bash builtins include: test, read, declare, eval, let pushd and popd. See the Bash man page for a full listing of builtins.

Avoid External Commands for Integer Math

Bash also provides builtins that can be used for integer arithmetic. Only use /usr/bin/bc if you need to do floating point arithmetic. Integer calculations can be made with these Bash builtins:

four=$(( 2 + 2 ))
four=$[ 2 + 2 ]
let four="2 + 2"

Avoid using Cat

Tools like Grep, Awk and Sed will take files as arguments. There is rarely a need to use /bin/cat. For instance, the following is unnecessary:

# avoid this
cat /etc/hosts | grep localhost

Instead, use Grep's native ability to read files:

grep localhost /etc/hosts

Avoid Piping Grep to Awk

If using Awk, you can often eliminate the need for grep. Try not to pipe Grep to Awk:

# avoid this
grep error /var/log/messages | awk '{ print $4 }'

Use Awk's native ability to parse text and save yourself a command.

awk '/error/ { print $4 }' /var/log/messages

Avoid Piping Sed to Sed

Sed can take more than one command in a single execution. Avoid piping sed to sed.

Need to connect to a VNC server behind a firewall that only allows SSH traffic? With SSH access to the VNC server, you can tunnel the VNC traffic through an SSH connection. This will encrypt your VNC traffic through an SSH tunnel.

To begin, SSH to the VNC server and forward the local client's 5904 TCP port to the VNC server's port 5901.

Both the ~/.bashrc and ~/.bash_profile are scripts that might be executed when bash is invoked. The ~/.bashrc file gets executed when you run bash using an interactive shell that is not a login shell. The ~/.bash_profile only gets executed during a login shell. What does this all mean? The paragraphs below explains interactive shells, login shells, .bashrc, .bash_profile and other bash scripts that are executed during login.

Login Shells (.bash_profile)

A login shell is a bash shell that is started with - or --login. The following are examples that will invoke a login shell.

sudo su -
bash --login
ssh user@host

When BASH is invoked as a login shell, the following files are executed in the displayed order.

/etc/profile

~/.bash_profile

~/.bash_login

~/.profile

Although ~/.bashrc is not listed here, most default ~/.bash_profile scripts run ~/.bashrc.

Purely Interactive Shells (.bashrc)

Interactive shells are those not invoked with -c and whose standard input and output are connected to a terminal. Interactive shells do not need to be login shells. Here are some examples that will evoke an interactive shell that is not a login shell.

sudo su
bash
ssh user@host /path/to/command

In this case of an interactive but non-login shell, only ~/.bashrc is executed. In most cases, the default ~/.bashrc script executes the system's /etc/bashrc.

Be warned that you should never echo output to the screen in a ~/.bashrc file. Otherwise, commands like 'ssh user@host /path/to/command' will echo output unrelated to the command called.

Non-interactive shells

Non-interactive shells do not automatically execute any scripts like ~/.bashrc or ~/.bash_profile. Here are some examples of non-interactive shells.

By default, Rar is not available in Fedora 10. If all you need to do is extract files from a Rar archive, unrar from RPM Fusion's YUM repositories will work. If you need to create Rar archives, then you will have to download and install the complete Rar package from DAG. The instructions below show you how.

Passwordless SSH can be accomplished using SSH's public key authentication. To configure passwordless SSH, follow the directions below. Warning: passwordless SSH will make your systems less secure. If you are comfortable with that, the directions below will walk you through server and client configurations. Then, I'll show you how to debug SSH if you encounter problems.

SSHD Server Configuration

First, you must ensure that your SSHD server allows for passwordless authentication using public keys. If you do not have root access to the server, do not worry. By default, public key authentication over protocol 2 is enabled. Skip this step. If you have any problems, contact your System Administrator.

If you have root privileges, edit your system's /etc/ssh/sshd_config and apply the following settings. I suggest you disable protocol 1 RSA key based authentication and leave all other settings alone for now. Visit the man page SSHD_CONFIG(5) for details.

Now that the server is configured, log into your client system and examine /etc/ssh/ssh_config. This is the SSH client configuration file and you do not need to edit it.

less /etc/ssh/ssh_config

By default, public key authentication over protocol 2 is enabled for clients. You only need to make sure that it is not disabled. If it is, create an ~/.ssh/config to override the /etc/ssh/ssh_config options.

cp -a /etc/ssh/ssh_config ~/.ssh/config

Then edit it and add this to the "Host *" block:

PubkeyAuthentication yes

Create Client Key

With the client in order, you need to create a public and private key pair. The following command will build a DSA key pair. Hit for all questions asked. This will create a DSA key pair in ~/.ssh/. The private key is called id_dsa and the public key is id_dsa.pub.

ssh-keygen -t dsa

Use Key for Authentication

Now that you have a public and private key pair, put the public key on the server you wish to log into without a password. You will need to put the public key inside the server's /home/user/.ssh/authorized_keys file. This file can contain multiple keys, so you generally do not want to just copy over it. Note that the authorized_keys2 file was deprecated in OpenSSH 3.0 (2001).

Alternatively, modern releases of SSH have a command to help you copy keys.

ssh-copy-id -i ~/.ssh/id_dsa.pub user@server

Test and Debug SSH

Now, test.

ssh username@server date

If you get prompted for a password, check the server's system logs for clues. You can also enable debugging in /etc/ssh/sshd_config with the following directive.

LogLevel DEBUG

Other options are INFO, VERBOSE, DEBUG2 and DEBUG3. See the man page SSHD_CONFIG(5) for details. For the client, the exact same option can be placed inside a /etc/ssh/ssh_config's Host block. See SSH_CONFIG(5) for client debugging details.

It is paramount that you respect the user and their data. Don't steal their MP3s, don't look at their porn. When working with email, look without reading. Respect them and they will respect you.

II. Thou shalt empower the user

The user is the customer. The system is not yours, it is theirs. Provide users the tools they need to be successful and they will be happy. Give them space to experiment, learn and create. Do not hold users back.

III. Thou shalt keep it simple

Keep It Simple, Stupid. The KISS principle will keep you from building barrels to keep a bottle's worth of wine. Do not mistake over-engineering for quality. Quality work is concise and scalable.

IV. Thou shalt expect catastrophe

Expect the worst surprises. Make your resources redundant, backup your data, test your backups, and then backup the backups. The shit will hit the fan someday. Be prepared.

V. Thou shalt plan

Great work follows great plans. Stay on target by first identifying it. Plan your work carefully and surprises will be easier to handle.

VI. Thou shalt stay informed

Gather all the news, information, logs and statistics you can. Without the raw data to analyze, you cannot debug problems and you cannot forecast. Without new information, you cannot learn.

VII. Thou shalt share

No one is alone in this world. Pass your knowledge on to others. Give to others, contribute to the community and you will reap many rewards. It is not wise to horde knowledge. Don't be an asshole.

VIII. Thou shalt automate

Do more, faster by automating tasks. You are the puppet master, do not waste your time with menial work. Work smarter, not harder.

IX. Thou shalt document

Always document your work, your code and your plans. Then document their execution and maintenance. Document for others and document for yourself. Documentation should be an extension of your mind and a resource for others.

X. Thou shalt respect thy organization

Without organization, there is no system, there is no user and there is no job. Understand the organization and its business. Respect it and help it thrive.

iTunes for Windows XP can be run on Fedora 9 using Wine, an Open Source implementation of the Windows API on top of X and OpenGL. Please note that iTunes runs a bit slow over Wine and I have yet to test an iPhone or iPod with this configuration.

Irssi
Irssi is the self proclaimed client of the future and my favorite IRC client. Irssi is a terminal based, feature-rich, highly configurable, themed environment with support for Perl scripts. The project website hosts a large variety of themes and scripts that can be used with Irssi.

Pidgin
Pidgin is a Gnome based, multi-protocol Instant Messaging client with support for IRC.. With Pidgin, you can manage your instant messaging accounts and IRC connections with one, graphical client.

Do you want to catch control-c keyboard interrupts in your Bash program? Use the Bash builtin trap command to catch system signals. The following runs control_c() when a user interrupts the main() section with a Control-C (SIGINT).

The Bash & (ampersand) is a builtin control operator used to fork processes. From the Bash man page, "If a command is terminated by the control operator &, the shell executes the command in the background in a subshell".

If logged into an interactive shell, the process is assigned a job number and the child PID is displayed. The job number below is one.

bash$ sleep 30 &
[1] 3586

Note that when a process is forked, the child PID is stored in the special variable $!

One Laptop per Child (OLPC) is at Linux World 2008 this week. Founded by Nicholas Negroponte, this non-profit organization is "dedicated to research to develop a low-cost, connected laptop, a technology that could revolutionize how we educate the world's children".