A hitchhikers guide to troubleshooting linux memory usage

http://techarena51.com/index.php/linux-memory-usage

Linux memory management has always intrigued me. While learning Linux, many concepts are confusing at first, but after a lot of reading, googling, understanding and determination, I learned that the kernel is not only efficient at memory
management but also on par with artificial intelligence in making memory distribution decisions..
This post will hopefully show you how to troubleshoot or at least find out the
amount of memory used by Linux and an application running on it. If you have any
doubts, do let me know by commenting.
Finding Linux System Memory usage

One of the simplest way to check Linux system memory usage is with the “free”
command.
Below is my “free -­m” command output.


The first line shows you that my free memory is only 111MB but the trick here is to
look at the second line for free memory.
The first line calculates caches and buffers along with the used memory.
Now linux does cache data to speed up the process of loading content.
But, that cached memory is also available for a new process to use at any time and
can be freed by the kernel immediately, in case any of your processes need it.
Buffers on the other hand, store metadata like file permissions or memory location of the cached data. Since this physical memory is availble for our process to use, we can subtract this information from the used memory to give us a free memory of 305MB as seen in the figure above.
Memory caching or Page cache
Linux divides memory into blocks called pages and hence the term page cache.
I will be using page cache from now on, but don’t get confused just replace page with memory if you do.
How page cache works.
Any time you do a read() from a file on disk, that data is read into memory, and
goes into the page cache. After this read() completes, the kernel has the option to
discard the page, since it is not being used. However, if you do a second read of
the same area in a file, the data will be read directly out of memory and no trip to
the disk will be taken. This is an incredible speedup.  And is the reason why Linux
uses its page cache so extensively, is because it knows that once you access a
page on disk the first time, you will surely access it again.
Similarly when you save data to a file it is not immediately written to the disk, it is
cached and written periodically to reduce I/O. The name for this type of cache is
Dirty.You can see it’s output  by running “cat /proc/meminfo”.

You can flush the cache with the following command.

echo 1 > /proc/sys/vm/drop_caches

To write cache to disk you can use the sync command

sync

Finding linux process memory usage 
Here is my HTOP output.

You need to look at the VIRT, RSS and SHR columns to get an idea of memory
consumption.

VIRT : Stands for Virtual Memory and displays the amount of memory requested
by an application. Applications often request more memory than required, however
they may not be actually using that memory and hence we can ignore this column.
RSS : Stands for Resident Set Size and displays the amount of memory used by
the process.
SHR : Stands for  Shared memory and displays the memory shared with other
processes.
The last two columns are what we need look at  to find out how much memory our
process is using.
For simple linux applications this information should suffice for you to know which
process is taking too much of your memory. But if you need to debug advance
issues like a memory leak then you need to go a step further.

The only problem with the HTOP output is that the RSS column displays used memory as Process memory + Total shared memory, even though the process is
using only a part of the shared memory.

Let’s take an analogy to understand this better.
I am a sensible spender ( I am married :) ), so sometimes I like to carpool to work.
Let’s say it takes 4$ worth of fuel from home to office.
When I go to work alone, I spend 4$ on fuel. The next day I car pool with 3 of my
friends, we pay a dollar each on fuel. So my total expenditure for the two days
would be 5$, however RSS would display it as $8.
Therefore, in order to find the exact memory usage you can you use a tool called
ps_mem.py.

git clone https://github.com/pixelb/ps_mem.git

cd ps_mem

sudo ./ps_mem.py

There you go php­fpm is hogging my memory.

Troubleshooting slow application issues in Linux.
If you look at the free output again you will see that the swap memory is used even
though we have ram free

The Linux kernel moves out pages which are not active or being used at the
moment to swap space on the disk. This process is known as
swappiness. Since swap space is on the hard drive fetching
data will be slower as compared to your ram, This may cause your application to take a hit in
terms of speed. You have the option to turn off swaping by changing the value in
 “/proc/sys/vm/swappiness” to 0. The value ranges from 0 to 100 where 100
means aggressive swapping.
Update: A good tip from karthik in comments
“I would recommend 1 more step, before changing the swappiness value. Try “vmstat -n 1″ and check the “si”, “so” field. If “si” and “so” (stands for swapin and swapout) fields are always 0, then the system is currently not swapping. Some application, has used the swap but somehow its not cleaned the swap space. At such situation a “swapoff/swapon” command would be handy.”
Update 2: Another good tool and page cache advice from reddit user zeroshiftsl
“I would add one more section though, the slab. I recently ran into an issue where a system was consuming more and more memory over time. I thought it was a leak, but no process seemed to own any of the missing memory. Htop showed the memory as allocated but it didn’t add up in the processes. This was NOT disk cached memory. Using “slabtop“, I found that a bunch of memory was stuck in dentry and inode_cache. This memory was not being freed when dropping caches like it should, and upping the vfs_cache_pressure had no effect. Had to kill the parent process (SSH session) that created all of these to reclaim the memory.”
Update: The ps_mem.py script runs only once, you may want to run it periodically to get real time memory usage, hence I recommend you read How to display a changing output like top
I tried to keep this post as simple as possible and this data should give you enough
information to troubleshoot any memory usage issues you might face on your linux
vps or server.
If there is anything I missed please do share your experiences troubleshooting linux memory usage issues in the comments below.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt
http://www.linuxhowtos.org/System/Linux%20Memory%20Management.htm
http://www.redhat.com/advice/tips/meminfo.html
http://www.thomas­krenn.com/en/wiki/Linux_Page_Cache_Basics

How to create and manage LXC containers on Ubuntu

http://xmodulo.com/lxc-containers-ubuntu.html

While the concept of containers was introduced more than a decade ago to manage shared hosting environments securely (e.g., FreeBSD jails), Linux containers such as LXC or Docker have gone mainstream only recently with the rising need to deploy applications for the cloud. While Docker is getting all the media spotlight these days with strong backing from major cloud providers (e.g., Amazon AWS, Microsoft Azure) and distro providers (e.g., Red Hat, Ubuntu), LXC is in fact the original container technology developed for Linux platforms.
If you are an average Linux user, what good does Docker/LXC bring to you? Well, containers are actually a great means to switch between distros literally instantly. Suppose your current desktop is Debian. You want Debian's stability. At the same time, you also want to play the latest Ubuntu games. Then instead of bothering to dual boot into a Ubuntu partition, or boot up a heavyweight Ubuntu VM, simply spin off a Ubuntu container on the spot, and you are done.
Even without all the goodies of Docker, what I like about LXC containers is the fact that LXC can be managed by libvirt interface, which is not the case for Docker. If you have been using libvirt-based management tools (e.g., virt-manager or virsh), you can use those same tools to manage LXC containers.
In this tutorial, I focus on the command-line usage of standard LXC container tools, and demonstrate how to create and manage LXC containers from the command line on Ubuntu.

Install LXC on Ubuntu

To use LXC on Ubuntu, install LXC user-space tools as follows.

$ sudo apt-get install lxc

After that, check the current Linux kernel for LXC support by running lxc-checkconifg tool. If everything is enabled, kernel's LXC support is ready.

$ lxc-checkconfig

After installing LXC tools, you will find that an LXC's default bridge interface (lxcbr0) is automatically created (as configured in /etc/lxc/default.conf).

When you create an LXC container, the container's interface will automatically be attached to this bridge, so the container can communicate with the world.

Create an LXC Container

To be able to create an LXC container of a particular target environment (e.g., Debian Wheezy 64bit), you need a corresponding LXC template. Fortunately, LXC user space tools on Ubuntu come with a collection of ready-made LXC templates. You can find available LXC templates in /usr/share/lxc/templates directory.

$ ls /usr/share/lxc/templates

An LXC template is nothing more than a script which builds a container for a particular Linux environment. When you create an LXC container, you need to use one of these templates.
To create a Ubuntu container, for example, use the following command-line:

$ sudo lxc-create -n -t ubuntu

By default, it will create a minimal Ubuntu install of the same release version and architecture as the local host, in this case Saucy Salamander (13.10) 64-bit.
If you want, you can create Ubuntu containers of any arbitrary version by passing the release parameter. For example, to create a Ubuntu 14.10 container:

$ sudo lxc-create -n -t ubuntu -- --release utopic

It will download and validate all the packages needed by a target container environment. The whole process can take a couple of minutes or more depending on the type of container. So be patient.

After a series of package downloads and validation, an LXC container image are finally created, and you will see a default login credential to use. The container is stored in /var/lib/lxc/. Its root filesystem is found in /var/lib/lxc//rootfs.
All the packages downloaded during LXC creation get cached in /var/cache/lxc, so that creating additional containers with the same LXC template will take no time.
Let's see a list of LXC containers on the host:

$ sudo lxc-ls --fancy

NAME  STATE    IPV4  IPV6  AUTOSTART  
------------------------------------
test-lxc   STOPPED  -     -     NO         

To boot up a container, use the command below. The "-d" option launches the container as a daemon. Without this option, you will directly be attached to console right after you launch the container.

$ sudo lxc-start -n -d

After launching the container, let's check the state of the container again:

$ sudo lxc-ls --fancy

NAME  STATE    IPV4       IPV6  AUTOSTART  
-----------------------------------------
lxc   RUNNING  10.0.3.55  -     NO         

You will see that the container is in "RUNNING" state with an IP address assigned to it.
You can also verify that the container's interface (e.g., vethJ06SFL) is automatically attached to LXC's internal bridge (lxcbr0) as follows.

$ brctl show lxcbr0

Manage an LXC Container

Now that we know how to create and start an LXC container, let's see what we can do with a running container.
First of all, we want to access the container's console. For this, type this command:

$ sudo lxc-console -n

Type to exit the console.
To stop and destroy a container:

$ sudo lxc-stop -n
$ sudo lxc-destroy -n

To clone an existing container to another, use these commands:

$ sudo lxc-stop -n
$ sudo lxc-clone -o -n

Troubleshooting

For those of you who encounter errors with LXC, here are some troubleshooting tips.
1. You fail to create an LXC container with the following error.

$ sudo lxc-create -n test-lxc -t ubuntu

lxc-create: symbol lookup error: /usr/lib/x86_64-linux-gnu/liblxc.so.1: undefined symbol: cgmanager_get_pid_cgroup_abs_sync

This means that you are running the latest LXC, but with an older libcgmanager. To fix this problem, you need to update libcgmanager.

$ sudo apt-get install libcgmanager0

How to encrypt files and directories with eCryptFS on Linux

http://xmodulo.com/encrypt-files-directories-ecryptfs-linux.html

You do not have to be a criminal or work for the CIA to use encryption. You simply don't want anybody to spy on your financial data, family pictures, unpublished manuscripts, or secret notes where you have jotted down startup ideas which you think can make you super rich.
I have heard people telling me "I'm not important enough to be spied on" or "I don't hide anything to care about." Well, my opinion is that even if I don't have anything to hide, or I can publish a picture of my kids with my dog, I have the right to not do it and want to protect my privacy.

Types of Encryption

We have largely two different ways to encrypt files and directories. One method is filesystem-level encryption, where only certain files or directories (e.g., /home/alice) are encrypted selectively. To me, this is a perfect way to start. You don't need to re-install everything to enable or test encryption. Filesystem-level encryption has some disadvantages, though. For example, many modern applications cache (part of) files in unencrypted portions of your hard drive, such as swap partition, /tmp and /var folders, which can result in privacy leaks.
The other way is so-called full-disk encryption, which means that the entire disk is encrypted (possibly except for a master boot record). Full disk encryption works at the physical disk level; every bit written to the disk is encrypted, and anything read from the disk is automatically decrypted on the fly. This will prevent any potential unauthorized access to unencrypted data, and ensure that everything in the entire filesystem is encrypted, including swap partition or any temporarily cached data.

Available Encryption Tools

There are several options to implement encryption in Linux. In this tutorial, I am going to describe one option: eCryptFS a user-space cryptographic filesystem tool. For your reference, here is a roundup of available Linux encryption tools.

Filesystem-level encryption

• EncFS: one of the easiest ways to try encryption. EncFS works as a FUSE-based pseudo filesystem, so you just create an encrypted folder and mount it to a folder to work with.
• eCryptFS: a POSIX compliant cryptographic filesystem, eCryptFS works in the same way as EncFS, so you have to mount it.

Full-disk encryption

• Loop-AES: the oldest disk encryption method. It is really fast and works on old system (e.g., kernel 2.0 branch).
• DMCrypt: the most common disk encryption scheme supported by the modern Linux kernel.
• CipherShed: an open-source fork of the discontinued TrueCrypt disk encryption program.

Basics of eCryptFS

eCryptFS is a FUSE-based user-space cryptographic filesystem, which has been available in the Linux kernel since 2.6.19 (as ecryptfs module). An eCryptFS-encrypted pseudo filesystem is mounted on top of your current filesystem. It works perfectly on EXT filesystem family and others like JFS, XFS, ReiserFS, Btrfs, even NFS/CIFS shares. Ubuntu uses eCryptFS as its default method to encrypt home directory, and so does ChromeOS. Underneath it, eCryptFS uses AES algorithm by default, but it supports others algorithms, such as blowfish, des3, cast5, cast6. You will be able to choose among them in case you create a manual setup of eCryptFS.
Like I said, Ubuntu lets us choose whether to encrypt our /home directory during installation. Well, this is the easiest way to use eCryptFS.

Ubuntu provides a set of user-friendly tools that make our life easier with eCryptFS, but enabling eCryptFS during Ubuntu installation only creates a specific pre-configured setup. So in case the default setup doesn't fit your needs, you will need to perform a manual setup. In this tutorial, I will describe how to set up eCryptFS manually on major Linux distros.

Installation of eCryptFS

Debian, Ubuntu or its derivatives:

$ sudo apt-get install ecryptfs-utils

Note that if you chose to encrypt your home directory during Ubuntu installation, eCryptFS should be already installed.
CentOS, RHEL or Fedora:

# yum install ecryptfs-utils

Arch Linux:

$ sudo pacman -S ecryptfs-utils

After installing the package, it is a good practice to load the eCryptFS kernel module just to be sure:

$ sudo modprobe ecryptfs

Configure eCryptFS

Now let's start encrypting some directory by running eCryptFS configuration tool:

$ ecryptfs-setup-private

It will ask for a login passphrase and a mount passphrase. The login passphrase is the same as your normal login password. The mount passphrase is used to derive a file encryption master key. Leave it blank to generate one as it's safer. Log out and log back in.
You will notice that eCryptFS created two directories by default: Private and .Private in your home directory. The ~/.Private directory contains encrypted data, while you can access corresponding decrypted data in the ~/Private directory. At the time you log in, the ~/.Private directory is automatically decrypted and mapped to the ~/Private directory, so you can access it. When you log out, the ~/Private directory is automatically unmounted and the content in the ~/Private directory is encrypted back into the ~/.Private directory.
The way eCryptFS knows that you own the ~/.Private directory, and automatically decrypts it into the ~/Private directory without needing us to type a password is through an eCryptFS PAM module which does the trick for us.
In case you don't want to have the ~/Private directory automatically mounted upon login, just add the "--noautomount" option when running ecryptfs-setup-private tool. Similarly, if you do not want the ~/Private directory to be automatically unmounted after logout, specify "--noautoumount" option. But then, you will have to mount or unmount ~/Private directory manually by yourself:

$ ecryptfs-mount-private ~/.Private ~/Private
$ ecryptfs-umount-private ~/Private

You can verify that .Private folder is mounted by running:

$ mount

Now we can start putting any sensitive files in ~/Private folder, and they will automatically be encrypted and locked down in ~/.Private folder when we log out.
All this seems pretty magical. Basically ecryptfs-setup-private tool makes everything easy to set up. If you want to play a little more and set up specific aspects of eCryptFS, go to the official documentation.

Conclusion

To conclude, if you care a great deal about your privacy, the best setup I recommend is to combine eCryptFS-based filesystem-level encryption with full-disk encryption. Always remember though, file encryption alone does not guarantee your privacy.

Unix: Beyond owner, group, and everyone else

http://www.itworld.com/article/2838785/unix-beyond-owner-group-and-everyone-else.html

The standard way of assigning file permissions on Unix systems is so tied into how people think of Unix that many of us seem to forget that this scheme was expanded many years ago to accomodate more than just file owners, groups, and everyone else. The setfacl (set file access control lists) and getfacl (get file access control list) commands were designed to allow more than the traditional limited assignment of privileges. While not disturing the customary owner-group-other permissions, you could, for example, give another account holder the same permissions as the owner or allow more than one group to have special access while not giving that access to just everyone. Everything comes at some cost, however, and to use the setfacl and getfacl commands, a file system has to be mounted with a special option that allows these commands and the underlying expansion of priviledges to be used. After all, there is overhead associated with keeping track of the extra permissions, so you have to opt in by adding an option to the file system in the /etc/fstab file -- the acl option. If you don't, anyone trying to use these commands will likely be confronted with an "operation not supported" error. You may also have to check whether your kernel provides support for this feature. To mount a file system with the acl option, you will need to use a command like this:

# mount -t ext4 -o acl /dev/hdb3 /data

In the /etc/fstab, this same operation might look like this:

/dev/hdb3    /data    ext4  defaults,acl     0    1

Indications that the extended permissions are in use are rather subtle. You'll just see a + sign at the end of the normal permissions field. For example:

-rw-r-----+ 1 smitten   admins 22088 Oct 26 recipe

That little + at the end of -rw-r-----+ tells you that there are more permissions than the rw-r----- permissions string is letting on. And, if you want to know more, you just have to use the getfacl command to display the complete permissions for the file. For a file with only standard permissions, you will see something like this:

$ getfacl beerlist
# file: beerlist
# owner: smitten
# group: admins
user::rw-
group::r--
other::---

This shows us what we normally see in a long listing, but in a different format. For a file with the extended permissions, on the other hand, the getfacl command might show you any additional permissions that have been set -- like this:

$ getfacl beerlist
# file: beerlist
# owner: smitten
# group: admins
user::rw-
user:tsmiley:rw-
group::r--
mask::rw-
other::---

Notice that we now see another user (tsmiley) with read and write permissions and a new field -- the "mask" field that sets default permissions for the file. You can set extended permissions using the setfacl command. Here are some examples where we give a user read, write and execute or add write permission.

setfacl -m u:tsmiley:rwx /data/example
setfacl -m u:tsmiley:+w /data/example

The -m stands for modify. The "u" in u: stands for user. You can assign permissions to groups as well as to individuals. You would assign a group permissions with a "g" as in the examples shown below.

setfacl -m g:devt:rwx /data/testcase
setfacl -R -m g:devt:+x testcases/
setfacl -m d:g:admins:rwx /data/scripts

In the third line in this example, the d: before the g: makes the new settings (rwx) the default for this directory. When files or direcxtories are created under the /data/scripts directory, the admins group will have rwx permission to them as well. After setting a default, you can expect to see these values when you use the getfacl command in the form of an additional line that looks like this:

default:group::rwx

One of the other complexities that you are likely to run into is the idea of the effective mask setting. If the mask is more restrictive than the permissions that you grant, the mask will take precedence. In the example below, the mask is r-- and reduces the privileges given to the groups to r--.

$ getfacl /data/jumping.jar 
# file: /data/jumping.jar 
# owner: dbender
# group: users
user::rw-
group::rwx          #effective:r--
group:devt:rwx      #effective:r--
mask::r--
other::r--

To remove extended permissions for a file or folder, you can use one of these commands. Remove all ACLs from a file:

setfacl -b /data/example

Remove the default ACL:

setfacl -k testcases

The mask setting is interesting. It will be set up whenever permissions beyond those of owner, group, and other are used. As you'd read in the man page for the setfacl command, the mask is the union of all permissions from the owning group, named user and group settings. It can limit the permissions that are available but you can change the mask with a command like this:

$ setfacl -m mask:rw- /data/example

Note that mask can be spelled (mask:) out or abbreviated to m (m:). Generally, it will be set to whatever permissions are intended for the expected collections of users and groups. You can also override this setting when you assign permissions by requesting that no mask be used with the -n or --no-mask setting. The traditional Unix permissions are easy to think about, but can be seriously confining when you need more flexibility in defining what various users or groups on your servers should be able to do. The newer ACL commands give you a lot more leeway in determining who gets what permissions. You just have to work a little harder to be sure they're right.

5 Deadly Linux Commands You Should Never Run

http://www.theepochtimes.com/n3/1031947-5-deadly-linux-commands-you-should-never-run

As a Linux user, you probably have searched online for articles and tutorials that show you how to use the terminal to run some commands. While most of these commands are harmless and could help you become more productive, there are some commands that are deadly and could wipe out your whole machine.

In this article, let’s check out some of the deadly Linux commands that you should never run.
Note: These commands are really harmful, so please don’t try to reproduce them on your Linux machines. You have been warned.

1. Deletes Everything Recursively

rm -rf /

This is one of the most deadly Linux commands around. The functionality of this command is really simple. It forcefully removes or deletes (rm) all the files and folders recursively (-rf) in the root directory (/) of your Linux machine. Once you delete all the files in the root directory, there is no way that you can boot into your Linux system again.
Also be aware that the below command comes in many other forms such as rm -rf * or rm -rf. So always be careful when ever you are executing a command that includes rm.

2. Fork Bomb

:(){ :|: & };:

This weird looking command doesn’t even look like a command, but it functions like a virus which creates copies of itself endlessly, thus called as Fork Bomb. This shell function quickly hijacks all your system resources like CPU, memory, etc. and will cause a system crash which in turn may result in data loss. So never ever try this command or any other weird-looking commands for that matter.

3. Move Everything to Nothingness

mv ~ /dev/null

The functionality of this command is really basic and simple. All it does is move (mv) the contents of your home folder (~) into the /dev/null folder. This looks really innocent, but the catch is that there is no folder called “Null,” and it simply means that you are moving all your files and folders into nothingness essentially destroying all the files irrecoverably.

4. Format Hard Drive

mkfs.ext3 /dev/sda

This command is really a disaster as it formats your entire hard drive and replaces it with the new ext3 file system. Once you execute the command, all your data is lost irrecoverably. So never ever try this command or any other suspicious command that involves your hard drive (sda).

5. Output Command Directly to Hard Drive

any-command > /dev/sda

This command is much more simple; any command you execute (in the place of “any-command”) will write the output data to your first hard drive replacing all the files and folders. This in turn damages your entire file system. Once you execute this command, you will be unable to boot into your Linux machine and your data may be lost irrecoverably.
Again, don’t ever try any suspicious command that includes your hard drive (sda).

Conclusion

Using the command line is pretty interesting but don’t blindly execute all the commands you find in the internet. A single command is enough to wipe out your whole system. In addition, while some of the commands above require elevated permissions (administrator), they may be disguised in other commands and may trick you into executing them.
So always be careful while you are executing the commands and only trust reputed and trusted sources for your command line requirements. The best way is to educate yourselves on how each command works and think through before executing the command.

Integrating Trac, Jenkins and Cobbler—Customizing Linux Operating Systems for Organizational Needs

http://www.linuxjournal.com/content/integrating-trac-jenkins-and-cobbler—customizing-linux-operating-systems-organizational-need

Organizations supporting Linux operating systems commonly have a need to build customized software to add or replace packages on production systems. This need comes from timing and policy differences between customers and the upstream distribution maintainers. In practice, bugs and security concerns reported by customers will be prioritized to appropriate levels for the distribution maintainers who are trying to support all their customers. This means that customers often need to support patches to fill the gap, especially for unique needs, until distribution maintainers resolve the bugs.

Customers who desire to fill the support gap internally should choose tools that the distribution maintainers use to build packages whenever possible. However, third-party software packages often present challenges to integrate them into the distribution properly. Often these packages do not follow packaging guidelines and, as a result, do not support all distribution configurations or procedures for administration. These packages often require more generic processes to resolve the improper packaging.
From this point on, the tools and methods discussed in this article are specific to Red Hat Enterprise Linux (RHEL). These tools and methods also work with derivative distributions like Scientific Linux or Community Enterprise OS (CentOS). Some of the tools do include support for distributions based on Debian. However, specifics on implementation of the process focus on integration with RHEL-based systems.
The build phase of the process (described in "A Process for Managing and Customizing HPC Operating Systems" in the April 2014 issue of LJ) requires three pieces of software that can be filled by Trac, Cobbler and Jenkins. However, these pieces of software do not fill all the gaps present from downloading source code to creation of the overlay repository. Further tools and processes are gained by analysis of the upstream distribution's package management process and guidelines.
The application of the Fedora Packaging Guidelines and its counterpart EPEL Packaging Guidelines are good references for how to package software for RHEL-based systems appropriately. These guidelines call out specifics that often are overlooked by first-time packagers. Also, tools used in the process, such as Mock, work well with the software mentioned previously.
Fedora uses other tools to manage building packages and repositories. These tools are very specific to Fedora packaging needs and are not general enough for use in our organization. This is primarily due to technical reasons and features that I go into in the Jenkins section of the article.
The rest of this article focuses on implementing Trac, Cobbler, Jenkins, and the gaps between the three systems. Some of the gaps are filled using native plugins associated with the three systems. However, others are left to be implemented using scripts and processes requiring human interactions. There are points where human interaction is required to facilitate communication between groups, and other points are where the process is missing a well implemented piece of software. I discuss setup, configuration and integration of Trac, Cobbler and Jenkins, along with some requests for community support.

Trac

Trac consists of an issue-tracking system and wiki environment to support software development projects. However, Trac also works well for supporting the maintenance of administrative processes and managing change on production systems. I'm going to discuss the mapping to apply a software development process to the process by which one administers a production system.
I realize that talking about issue tracking and wiki software is a religious topic for some. Everyone has their favorite software, and these two kinds of systems have more than enough open-source options out there from which people can choose. I want to focus on the features that we have found useful at EMSL to support our HPC system and how we use them.
The ticket-tracking system works well for managing small changes on production systems. These small changes may include individual critical updates, configuration changes and requests from users. The purpose of these tickets is to record relevant technical information about the changes for administrators as well as management. This helps all stakeholders understand the cost and priority of the change. These small changes can be aggregated into milestones, which correspond to outage dates. This provides a starting framework to track what change happens and when on production systems.
Trac's wiki has features that are required for the process. The first is the ability to maintain a history of changes to individual pages. This is ideal for storing documents and procedures. Another feature is the ability to reference milestones from within pages. This feature is extremely useful, since by entering a single line in the wiki, it displays all tickets associated with the milestone in one simple line. These two features help maintain the procedures and outage pages in the wiki.
The administrative procedures are documented in the wiki, and they include but are not limited to software configuration, startup, shutdown and re-install. The time required to perform these administrative procedures also should be noted in the page. We also make sure to use the plain-text options for specifying commands that need to be run, as other fonts may confuse readers. In many cases, we have specified the specific command to run in these procedures. For complex systems, creating multiple pages for a particular procedure is prudent. However, cross links between pages should be added to note when one part of the procedure from each page should be followed.
Trac's plugin infrastructure does not have plugins to Jenkins or Cobbler. However, what would be the point of a plugin going from Trac to continuous integration or provisioning? Most software development models keep ticket systems limited to human interaction between the issuer of the ticket and the people resolving it. Some exceptions are when tickets are considered resolved but are waiting for integration testing. Automated tests could be triggered by the ticketing system when the ticket's state is changed. However, mapping these sorts of features to administrative procedures for managing production systems do not apply.

Cobbler

Cobbler works well for synchronizing RPM-based repositories and using those repositories to deploy systems. The RPMs are synchronized daily from Jenkins and distribution maintainers. The other important feature is to exclude certain packages from being synchronized locally. These features provide a platform to deploy systems that have specific customized packages for use in the enterprise.
The initial setup for Cobbler is to copy the primary repositories for the distribution of your choice to "repos" in Cobbler. The included repositories from Scientific Linux are the base operating system, fastbugs and security. Other distributions have similar repository configurations (see the Repositories and Locations sidebar). The other repository to include is EPEL, as it contains Mock and other tools used to build RPMs. There are other repositories that individual organizations should look into, although these four repositories are all that is needed.

Repositories and Locations

• Extra Packages for Enterprise Linux: http://dl.fedoraproject.org/pub/epel/6/x86_64
• Scientific Linux 66 Base: http://ftp1.scientificlinux.org/linux/scientific/6/x86_64/os
• Scientific Linux 6 Security: http://ftp1.scientificlinux.org/linux/scientific/6/x86_64/updates/security
• Scientific Linux 6 Fastbugs: http://ftp1.scientificlinux.org/linux/scientific/6/x86_64/updates/fastbugs
• CentOS 6 Base: http://mirror.centos.org/centos/6/os/x86_64
• CentOS 6 FastTrack: http://mirror.centos.org/centos/6/fasttrack/x86_64
• CentOS 6 Updates: http://mirror.centos.org/centos/6/updates/x86_64
• RHEL 6 Server Base: rhel-x86_64-server-6 channel
• RHEL 6 Server FasTrack: rhel-x86_64-server-fastrack-6 channel
• RHEL 6 Server Optional: rhel-x86_64-server-optional-6 channel
• RHEL 6 Server Optional FasTrack: rhel-x86_64-server-optional-fastrack-6 channel
• RHEL 6 Server Supplementary: rhel-x86_64-server-supplementary-6 channel
  
  The daily repositories either are downloaded from the Web on a daily basis or synchronized from the local filesystem. The daily repositories get the "keep updated" flag set, while the test and production repositories do not. For daily repositories that synchronize from a local filesystem, the "breed" should be set to rsync, while daily repositories that synchronize from the Web should set their "breed" to yum. This configuration, through experience, has been chosen because some RPMs do not upgrade well with new kernels nor do they have standard update processes normal to Red Hat or Fedora.
  An example of a set of repositories would be as follows:
  
• phi-6-x86_64-daily — synchronizes automatically from the local filesystem using rsync once daily.
• epel-6-x86_64-daily — synchronizes automatically from the Web using reposync once daily.
• phi-6-x86_64-test — synchronizes manually from phi-6-x86_64-daily using rsync.
• epel-6-x86_64-test — synchronizes manually from epel-6-x86_64-daily using rsync.
• phi-6-x86_64-prod — synchronizes manually from phi-6-x86_64-test using rsync.
• epel-6-x86_64-prod — synchronizes manually from epel-6-x86_64-test using rsync.

To exclude critical packages from the upstream distribution, the "yum options" flags are set on the daily repository to remove them. For example, to exclude the kernel package from from being synchronized, add exclude=kernel*. It's important for administrators to consult both the Cobbler and yum.conf man pages to get the syntax right.
Setting up Cobbler in this way allows administrators to deploy systems using customized critical packages. Cobbler also is used in future phases where the repositories are used to deploy the test and production clusters. The repositories and their relationships are all Cobbler needs to support package building, the test cluster and the production cluster.

Jenkins

Jenkins is a very powerful continuous integration tool used in software development. However, from a system administration view, Jenkins is a mutant cron job on steroids. Jenkins handles periodic source code checkout from source code management (SCM) repositories and downloading of released source code, via HTTP or FTP. It then runs a series of generic jobs that build, test and deploy the resulting software. These generic interfaces work well for building and distributing RPMs to be included by Cobbler.
The use of Jenkins in a software development role is not all that different from building RPMs (see Table 1 for a comparison of the two processes). The first step in the two processes differs in that (hopefully) the software development code required for the build step is in one place. Package developers need to have, at a minimum, two locations to pull code from to continue with the build. The first location is for patches and spec files, normally kept in an SCM. The second is for released source code packages. Source code is released in a single file and usually in some container format (such as tar, rar or zip). These files do not normally belong in an SCM and are more suited to an S3 (http://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html), swift (http://docs.openstack.org/api/openstack-object-storage/1.0/content) or blob store-like interface.

Table 1. Packaging vs. Development

Software Development	RPM Packaging
Download source code from SCM.	Download released source, spec file and patches.
Run the build process.	Build the RPMs using Mock.
Run the testing suite.	Validate the RPMs using rpmlint.
Publish test results.	Save validation output for inspection.
Save source code package to repository.	Save built RPMs for later download.
Send notification to pertinent developers.	Send notification to pertinent packagers.

Jenkins is built primarily for downloading code from one and only one SCM. However, you can work around this issue by adding another build step. This means that the SCM plugin is used to download the spec file and patches while the first step in the build process downloads the source code package. After these two steps are done, the source code, patches or spec file can be patched with site-specific customization.
The next step is to build RPMs using Mock. This involves several tasks that can be broken up into various build steps (see the Mock Build in Jenkins sidebar). All these steps are done using the Jenkins execute shell build steps. Some of the Jenkins jobs we use are multi-configuration jobs that contain one axis defining the Mock chroot configuration. That chroot configuration should be generated from the daily repositories defined in Cobbler. Following these tasks can get you started on using Mock in Jenkins (Listing 1).

Listing 1. basic-mock-jenkins.sh

#!/bin/bash -xe

# keep in mind DIST is defined in multi-configuration axis
MOCK="/usr/bin/mock -r $DIST"
PKG=${JOB_NAME##*/}
# keep in mind VER could also be a multi-configuration axis
VER=${VER:-1.0}
# if you are ripping apart an RPM might have this one too
REL=${REL:-4.el6}

OUT=$PWD/output

wget -O $PKG-$VER.tar.gz 
 ↪http://www.example.com/sources/$PKG-$VER.tar.gz
rm -f $OUT/*.src.rpm
if ! $MOCK --resultdir=$OUT --buildsrpm --spec=$PKG.spec 
 ↪--sources=$PWD
then
    more $OUT/*.log | cat
    exit -1
fi

if ! $MOCK --resultdir=$OUT --rebuild $OUT/*.src.rpm
then
    more $OUT/*.log | cat
    exit -1
fi

rpmlint $OUT/*.rpm > rpmlint.log

Mock Build in Jenkins

1. Prepare the source and specs.
2. Run Mock source rpm build.
3. Run Mock rpm build.
4. Run rpm validation.
   
   Once the RPMs are built, it's important to run rpmlint on the resulting RPMs. This output gives useful advice for how to package RPMs properly for the targeted platform. This output should be handled like any other static code analysis tool. The number of warnings and errors should be tracked, counted and graphed over a series of builds. This gives a good indication whether bugs are being resolved or introduced over time.
   The generated RPMs and rpmlint output need to be archived for future use. The archive artifacts plugin works well for capturing these files. There also is an artifact deployer plugin that can copy the artifacts to directories that Cobbler can be configured to synchronize from for its part of the process.
   There is some room for improvement in this process, and I outline that in the conclusion. However, this is the basic framework to start using Jenkins to build RPMs using Mock and rpmlint. This part of the process needs constant care and attention as new updates are pushed by the distribution and package developers. Jenkins does have plugins to Trac and other issue-tracking systems. However, they are not included in this process, as we find e-mail to be a sufficient means of communication. The outlined process for building RPMs using Jenkins helps us track the hacks we use to manipulate important packages for our systems.
   

   Table 2. Software

   Role	Software Choice
   Continuous Integration	Jenkins
   Repository Management	Cobbler
   Provisioning	Cobbler
   Ticket Tracking	Trac
   Wiki	Trac
   Package Building	Mock
   Package Guidelines	Fedora Packaging Guidelines

   Conclusion

   I have discussed a method for setting up tools to develop RPMs against a custom distribution managed by Cobbler. Along with Trac, package developers can maintain updated RPMs of critical applications while managing communication. However, this process is not without gaps. First, I'll go over the gaps present in Jenkins, discussing core and plugin gaps that were not found. Then I'll discuss the gaps in Cobbler regarding repository management. These two systems are lacking in integration, although that can be worked around.
   MultiSCM is a functionality in Jenkins that would simplify the package building process. There is a MultiSCM plugin; however, it is advertised as a proof-of-concept code. The hope is that the radio button selection for SCM would turn into a set of check boxes. There are related bugs, but they have not seen traction in years. Package development is another good example of the need to download and poll for updates on code from multiple places.
   Here are links to information on the Jenkins Multiple SCMs Bugs:
   
5. https://issues.jenkins-ci.org/browse/JENKINS-7192
6. https://issues.jenkins-ci.org/browse/JENKINS-9720

Static code analysis tools are available as plugins for Jenkins, although these plugins do not include rpmlint. These plugins create graphs to track the number of warnings and errors in code over time. To perform the same task for packaging would be very helpful. However, you can work around this gap by using the generic plot plugin and another build step for each job.
Mock has a very well defined interface and workflow. A generic plugin to use Mock in Jenkins would be very useful. The plugin should include configuring the chroot configuration. Two kinds of build jobs also could be created, one using spec and source files, the other using source RPMs. A test also would need to be created to verify that Mock can be run without prompting for a user password. This plugin would be very helpful for automating this process, as we currently have to copy scripts between jobs.
There are some additions to Cobbler that would be useful for this process as well. There are no per-repo triggers. The ability to tell Trac that packages went from repo test to repo prod would be useful. Furthermore, the ability to tell Jenkins to build a package because a dependent package updated also would be useful.
The other useful addition to Cobbler would be the ability to remove older RPMs in the destination tree while synchronizing from the remote mirror. Cobbler repositories, if the "breed" is yum, build up in an append-only fashion. Processes for managing the space may be run periodically by removing the RPMs and then synchronizing the repository again. However, this leaves the repository in a broken state until the process is complete. This feature could be useful in any Cobbler deployment, as it would make sure repositories do not continue to take up space when RPMs are not needed.
Trac does not need any additional plugins to integrate better with Cobbler or Jenkins. We have found some usability issues with manipulating large tables in the wiki format. Some plugin to make editing large tables easier in the wiki format would be useful for us. Also, editing long pages becomes an issue if you cannot put comments throughout the page. We validate our procedures by having members of the group who are unfamiliar with the system read through the procedure. The reader should be able to comment on but not edit parts of the page. We have worked around or found plugins on the Trac Hacks page to resolve these issues.
The final request is for some level of certification from distribution maintainers to certify third-party packages. Many of the third-party packages we have applied to this process to do not support all distribution configurations. A certification from distribution maintainers validating that software distributed by third-party vendors have packaged their software appropriately for the distribution would help customers determine the cost of support.
This is by no means a complete solution for organizations to build customized critical applications. There are still gaps in the system that we have to work around using scripts or manual intervention. We constantly are working on the process and tools to make them better, so any suggestions to improve it are welcome. However, these tools do fill the need to support customization of critical applications for HPC at EMSL.

Acknowledgement

The research was performed using EMSL, a national scientific user facility sponsored by the Department of Energy's Office of Biological and Environmental Research and located at Pacific Northwest National Laboratory.

Amazing ! 25 Linux Performance Monitoring Tools

http://linoxide.com/monitoring-2/linux-performance-monitoring-tools

Over the time our website has shown you how to configure various performance tools for Linux and Unix-like operating systems. In this article we have made a list of the most used and most useful tools to monitor the performance for your box. We provided a link for each of them and split them into 2 categories: command lines one and the ones that offer a graphical interface.

Command line performance monitoring tools

1. dstat - Versatile resource statistics tool

A versatile combination of vmstat, iostat and ifstat. It adds new features and functionality allowing you to view all the different resources instantly, allowing you to compare and combine the different resource usage. It uses colors and blocks to help you see the information clearly and easily. It also allows you to export the data in CVS format to review it in a spreadsheet application or import in a database. You can use this application to monitor cpu, memory, eth0 activity related to time.

2. atop - Improved top with ASCII

A command line tool using ASCII to display a performance monitor that is capable of reporting the activity of all processes. It shows daily logging of system and process activity for long-term analysis and it highlights overloaded system resources by using colors. It includes metrics related to CPU, memory, swap, disks and network layers. All the functions of atop can be accessed by simply running:

# atop

And you will be able to use the interactive interface to display and order data.

3. Nmon - performance monitor for Unix-like systems

Nmon stands for Nigel's Monitor and it's a system monitor tool originally developed for AIX. If features an Online Mode that uses curses for efficient screen handling, which updates the terminal frequently for real-time monitoring and a Capture Mode where the data is saved in a file in CSV format for later processing and graphing.

 More info in our nmon performance track article.

4. slabtop - information on kernel slab cache

This application will show you how the caching memory allocator manages in the Linux kernel caches various type of objects. The command is a top like command but is focused on showing real-time kernel slab cache information. It displays a listing of the top caches sorted by one of the listed sort criteria. It also displays a statistics header filled with slab layer information. Here are a few examples:

# slabtop --sort=a
# slabtop -s b
# slabtop -s c
# slabtop -s l
# slabtop -s v
# slabtop -s n
# slabtop -s o

More info is available kernel slab cache article

5. sar - performance monitoring and bottlenecks check

The sar command writes to standard output the contents of selected cumulative activity counters in the operating system. The accounting system, based on the values in the count and interval parameters, writes information the specified number of times spaced at the specified intervals in seconds. If the interval parameter is set to zero, the sar command displays the average statistics for the time since the system was started. Useful commands:

# sar -u 2 3
# sar –u –f /var/log/sa/sa05
# sar -P ALL 1 1
# sar -r 1 3
# sar -W 1 3

6. Saidar - simple stats monitor

Saidar is a simple and lightweight tool for system information. It doesn't have major performance reports but it does show the most useful system metrics in a short and nice way. You can easily see the up-time, average load, CPU, memory, processes, disk and network interfaces stats.

Usage: saidar [-d delay] [-c] [-v] [-h]
-d Sets the update time in seconds
-c Enables coloured output
-v Prints version number
-h Displays this help information.

7. top - The classical Linux task manager

top is one of the best known Linux utilities, it's a task manager found on most Unix-like operating systems. It shows the current list of running processes that the user can order using different criteria. It mainly shows how much CPU and memory is used by the system processes. top is a quick place to go a check what process or processes hangs your system. You can also find here a list of examples of top usage . You can access it by running the top command and entering the interactive mode:

Quick cheat sheet for interactive mode:

• GLOBAL_Commands: ?, =, A, B, d, G, h, I, k, q, r, s, W, Z
• SUMMARY_Area_Commands: l, m, t, 1
• TASK_Area_Commands Appearance: b, x, y, z Content: c, f, H, o, S, u Size: #, i, n Sorting: <, >, F, O, R
• COLOR_Mapping: , a, B, b, H, M, q, S, T, w, z, 0 - 7
• COMMANDS_for_Windows:  -, _, =, +, A, a, G, g, w

8. Sysdig - Advanced view of system processes

Sysdig is a tool that gives admins and developers unprecedented visibility into the behavior of their systems. The team that develops it wants to improve the way system-level monitoring and troubleshooting is done by offering a unified, coherent, and granular visibility into the storage, processing, network, and memory subsystems making it possible to create trace files for system activity so you can easily analyze it at any time.
Quick examples:

# sysdig proc.name=vim

# sysdig -p"%proc.name %fd.name" "evt.type=accept and proc.name!=httpd"

# sysdig evt.type=chdir and user.name=root

# sysdig -l
# sysdig -L

# sysdig -c topprocs_net

# sysdig -c fdcount_by fd.sport "evt.type=accept"

# sysdig -p"%proc.name %fd.name" "evt.type=accept and proc.name!=httpd"

# sysdig -c topprocs_file

# sysdig -c fdcount_by proc.name "fd.type=file"

# sysdig -p "%12user.name %6proc.pid %12proc.name %3fd.num %fd.typechar %fd.name" evt.type=open

# sysdig -c topprocs_cpu

# sysdig -c topprocs_cpu evt.cpu=0

# sysdig -p"%evt.arg.path" "evt.type=chdir and user.name=root"

# sysdig evt.type=open and fd.name contains /etc

More info is available in our article on how to use sysdig for improved system-level monitoring and troubleshooting

9. netstat - Shows open ports and connections

Is the tool Linux administrators use to show various network information, like what ports are open and what network connections are established and what process runs that connection. It also shows various information about the Unix sockets that are open between various programs. It is part of most Linux distributions A lot of the commands are explained in the article on netstat and its various outputs. Most used commands are:

$ netstat | head -20
$ netstat -r
$ netstat -rC
$ netstat -i
$ netstat -ie
$ netstat -s
$ netstat -g
$ netstat -tapn

10. tcpdump - insight on network packets

tcpdump can be used to see the content of the packets on a network connection. It shows various information about the packet content that pass. To make the output useful, it allows you to use various filters to only get the information you wish. A few examples on how you can use it:

# tcpdump -i eth0 not port 22
# tcpdump -c 10 -i eth0
# tcpdump -ni eth0 -c 10 not port 22
# tcpdump -w aloft.cap -s 0
# tcpdump -r aloft.cap
# tcpdump -i eth0 dst port 80

You can find them described in detail in our article on tcpdump and capturing packets

11. vmstat - virtual memory statistics

vmstat stands for virtual memory statistics and it's a memory monitoring tool that collects and displays summary information about memory, processes, interrupts, paging and block I/O. It is an open source program available on most Linux distributions, Solaris and FreeBSD. It is used to diagnose most memory performance problems and much more.

More info in our article on vmstat commands.

12. free - memory statistics

Another command line tool that will show to standard output a few stats about memory usage and swap usage. Because it's a simple tool it can be used to either find quick information about memory usage or it can be used in different scripts and applications. You can see that this small application has a lot of uses and almost all system admin use this tool daily :-)

13. Htop - friendlier top

Htop is basically an improved version of top showing more stats and in a more colorful way allowing you to sort them in different ways as you can see in our article. It provides a more a more user-friendly interface.

You can find more info in our comparison of htop and top

14. ss - the modern net-tools replacement

ss is part of the iproute2 package. iproute2 is intended to replace an entire suite of standard Unix networking tools that were previously used for the tasks of configuring network interfaces, routing tables, and managing the ARP table. The ss utility is used to dump socket statistics, it allows showing information similar to netstat and its able display more TCP and state information. A few examples:

# ss -tnap
# ss -tnap6
# ss -tnap
# ss -s
# ss -tn -o state established -p

15. lsof - list open files

lsof is a command meaning "list open files", which is used in many Unix-like systems to report a list of all open files and the processes that opened them. It is used by most Linux distributions and other Unix-like operating systems by system administrators to check what files are open by various processes.

# lsof +p process_id
# lsof | less
# lsof –u username
# lsof /etc/passwd
# lsof –i TCP:ftp
# lsof –i TCP:80

You can find more examples in the lsof article

16. iftop - top for your network connections

iftop is yet another top like application that will is based on networking information. It shows various current network connection sorted by bandwidth usage or the amount of data uploaded or downloaded. It also provides various estimations of the time it will take to download them.

For more info see article on network traffic with iftop

17. iperf - network performance tool

iperf is a network testing tool that can create TCP and UDP data connections and measure the performance of a network that is carrying them. It supports tuning of various parameters related to timing, protocols, and buffers. For each test it reports the bandwidth, loss, and other parameters.

If you wish to use the tool check out our article on how to install and use iperf

18. Smem - advanced memory reporting

Smem is one of the most advanced tools for Linux command line, it offers information about the actual memory that is used and shared in the system, attempting to provide a more realistic image of the actual memory being used.

$ smem -m
$ smem -m -p | grep firefox
$ smem -u -p
$ smem -w -p

Check out our article on Smem for more examples

GUI or Web based performance tools

19. Icinga - community fork of Nagios

Icinga is free and open source system and network monitoring application. It’s a fork of Nagios retaining most of the existing features of its predecessor and building on them to add many long awaited patches and features requested by the user community.

More info about installing and configuring can be found in our Icinga article.

20. Nagios - the most popular monitoring tool.

The most used and popular monitoring solution found on Linux. It has a daemon that collects information about various process and has the ability to collect information from remote hosts. All the information is then provided via a nice and powerful web interface.

You can find information on how to install Nagios in our article

21. Linux process explorer - procexp for Linux

Linux process explorer is a graphical process explorer for Linux. It shows various process information like the process tree, TCP/IP connections and performance figures for each process. It's a replica of procexp found in Windows and developed by Sysinternals and aims to be more user friendly then top and ps.
Check our linux process explorer article for more info.

22. Collectl - performance monitoring tool

This is a performance monitoring tool that you can use either in an interactive mode or you can have it write reports to disk and access them with a web server. It reports statistics on CPU, disk, memory, network, nfs, process, slabs and more in easy to read and manage format.

More info in our Collectl article

23. MRTG - the classic graph tool

This is a network traffic monitor that will provide you graphs using the rrdtool. It is one of the oldest tools that provides graphics and is one of the most used on Unix-like operating systems. Check our article on how to use MRTG for information on the installation and configuration process

24. Monit - simple and easy to use monitor tool

Monit is an open source small Linux utility designed to monitor processes, system load, filesystems, directories and files. You can have it run automatic maintenance and repair and can execute actions in error situations or send email reports to alert the system administrator. If you wish to use this tool you can check out our how to use Monit article.

25. Munin - monitoring and alerting services for servers

Munin is a networked resource monitoring tool that can help analyze resource trends and see what is the weak point and what caused performance issues. The team that develops it wishes it for it to be very easy to use and user-friendly. The application is written in Perl and uses the rrdtool to generate graphs, which are with the web interface. The developers advertise the application "plug and play" capabilities with about 500 monitoring plugins currently available.

What are useful Bash aliases and functions

http://xmodulo.com/useful-bash-aliases-functions.html

As a command line adventurer, you probably found yourself repeating the same lengthy commands over and over. If you always ssh into the same machine, if you always chain the same commands together, or if you constantly run a program with the same flags, you might want to save the precious seconds of your life that you spend repeating the same actions over and over.

The solution to achieve that is to use an alias. As you may know, an alias is a way to tell your shell to remember a particular command and give it a new name: an alias. However, an alias is quickly limited as it is just a shortcut for a shell command, without the ability to pass or control the arguments. So to complement, bash also allows you create your own functions, which can be more lengthy and complex, and also accepts any number of arguments.

Naturally, like with soup, when you have a good recipe you share it. So here is a list with some of the most useful bash aliases and functions. Note that "most useful" is loosely defined, and of course the usefulness of an alias is dependent on your everyday usage of the shell.

Before you start experimenting with aliases, here is a handy tip: if you give an alias the same name as a regular command, you can choose to launch the original command and ignore the alias with the trick:

\command

For example, the first alias below replaces the ls command. If you wish to use the regular ls command and not the alias, call it via:

\ls

Productivity

So these aliases are really simple and really short, but they are mostly based on the idea that if you save yourself a fraction of a second every time, it might end up accumulating years at the end. Or maybe not.

alias ls="ls --color=auto"

Simple but vital. Make the ls command output in color.

alias ll = "ls --color -al"

Shortcut to display in color all the files from a directory in a list format.

alias grep='grep --color=auto'

Similarly, put some color in the grep output.

mcd() { mkdir -p "$1"; cd "$1";} 

One of my favorite. Make a directory and cd into it in one command: mcd [name].

cls() { cd "$1"; ls;}

Similar to the previous function, cd into a directory and list its content: cls [name].

backup() { cp "$1"{,.bak};}

Simple way to make a backup of a file: backup [file] will create [file].bak in the same directory.

md5check() { md5sum "$1" | grep "$2";}

Because I hate comparing the md5sum of a file by hand, this function computes it and compares it using grep: md5check [file] [key].

alias makescript="fc -rnl | head -1 >" 

Easily make a script out of the last command you ran: makescript [script.sh]

alias genpasswd="strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 30 | tr -d '\n'; echo" 

Just to generate a strong password instantly.

alias c="clear"

Cannot do simpler to clean your terminal screen.

alias histg="history | grep"

To quickly search through your command history: histg [keyword]

alias ..='cd ..'

No need to write cd to go up a directory.

alias ...='cd ../..'

Similarly, go up two directories.

extract() { 
    if [ -f $1 ] ; then 
      case $1 in 
        *.tar.bz2)   tar xjf $1     ;; 
        *.tar.gz)    tar xzf $1     ;; 
        *.bz2)       bunzip2 $1     ;; 
        *.rar)       unrar e $1     ;; 
        *.gz)        gunzip $1      ;; 
        *.tar)       tar xf $1      ;; 
        *.tbz2)      tar xjf $1     ;; 
        *.tgz)       tar xzf $1     ;; 
        *.zip)       unzip $1       ;; 
        *.Z)         uncompress $1  ;; 
        *.7z)        7z x $1        ;; 
        *)     echo "'$1' cannot be extracted via extract()" ;; 
         esac 
     else 
         echo "'$1' is not a valid file" 
     fi 
}

Longest but also the most useful. Extract any kind of archive: extract [archive file]

System Info

Want to know everything about your system as quickly as possible?

alias cmount="mount | column -t"

Format the output of mount into columns.

alias tree="ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/'" 

Display the directory structure recursively in a tree format.

sbs() { du -b --max-depth 1 | sort -nr | perl -pe 's{([0-9]+)}{sprintf "%.1f%s", $1>=2**30? ($1/2**30, "G"): $1>=2**20? ($1/2**20, "M"): $1>=2**10? ($1/2**10, "K"): ($1, "")}e';} 

"Sort by size" to display in list the files in the current directory, sorted by their size on disk.

alias intercept="sudo strace -ff -e trace=write -e write=1,2 -p" 

Intercept the stdout and stderr of a process: intercept [some PID]. Note that you will need strace installed.

alias meminfo='free -m -l -t'

See how much memory you have left.

alias ps? = "ps aux | grep"

Easily find the PID of any process: ps? [name]

alias volume="amixer get Master | sed '1,4 d' | cut -d [ -f 2 | cut -d ] -f 1"

Displays the current sound volume.

Networking

For all the commands that involve the Internet or your local network, there are fancy aliases for them.

alias websiteget="wget --random-wait -r -p -e robots=off -U mozilla"

Download entirely a website: websiteget [URL]

alias listen="lsof -P -i -n" 

Show which applications are connecting to the network.

alias port='netstat -tulanp'

Show the active ports

gmail() { curl -u "$1" --silent "https://mail.google.com/mail/feed/atom" | sed -e 's/<\/fullcount.*/\n/' | sed -e 's/.*fullcount>//'}

Rough function to display the number of unread emails in your gmail: gmail [user name]

alias ipinfo="curl ifconfig.me && curl ifconfig.me/host"

Get your public IP address and host.

getlocation() { lynx -dump http://www.ip-adress.com/ip_tracer/?QRY=$1|grep address|egrep 'city|state|country'|awk '{print $3,$4,$5,$6,$7,$8}'|sed 's\ip address flag \\'|sed 's\My\\';} 

Returns your current location based on your IP address.

Useless

So what if some aliases are not all that productive? They can still be fun.

kernelgraph() { lsmod | perl -e 'print "digraph \"lsmod\" {";<>;while(<>){@_=split/\s+/; print "\"$_[0]\" -> \"$_\"\n" for split/,/,$_[3]}print "}"' | dot -Tpng | display -;}

To draw the kernel module dependency graph. Requires image viewer.

alias busy="cat /dev/urandom | hexdump -C | grep "ca fe"" 

Make you look all busy and fancy in the eyes of non-technical people.

To conclude, a good chunk of these aliases and functions come from my personal .bashrc, and the awesome websites alias.sh and commandlinefu.com which I already presented in my post on the best online tools for Linux. So definitely go check them out, make your own recipes, and if you are so inclined, share your wisdom in the comments.
As a bonus, here is the plain text version of all the aliases and functions I mentioned, ready to be copy pasted in your bashrc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

#Productivity alias ls="ls --color=auto" alias ll="ls --color -al" alias grep='grep --color=auto' mcd() { mkdir -p "$1"; cd "$1";} cls() { cd "$1"; ls;} backup() { cp "$1"{,.bak};} md5check() { md5sum "$1" | grep "$2";} alias makescript="fc -rnl | head -1 >" alias genpasswd="strings /dev/urandom | grep -o '[[:alnum:]]' | head -n 30 | tr -d '\n'; echo" alias c="clear" alias histg="history | grep" alias ..='cd ..' alias ...='cd ../..' extract() {     if [ -f $1 ] ; then       case $1 in         *.tar.bz2)   tar xjf $1     ;;         *.tar.gz)    tar xzf $1     ;;         *.bz2)       bunzip2 $1     ;;         *.rar)       unrar e $1     ;;         *.gz)        gunzip $1      ;;         *.tar)       tar xf $1      ;;         *.tbz2)      tar xjf $1     ;;         *.tgz)       tar xzf $1     ;;         *.zip)       unzip $1       ;;         *.Z)         uncompress $1  ;;         *.7z)        7z x $1        ;;         *)     echo "'$1' cannot be extracted via extract()" ;;          esac      else          echo "'$1' is not a valid file"      fi }    #System info alias cmount="mount | column -t" alias tree="ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/'" sbs(){ du -b --max-depth 1 | sort -nr | perl -pe 's{([0-9]+)}{sprintf "%.1f%s", $1>=2**30? ($1/2**30, "G"): $1>=2**20? ($1/2**20, "M"): $1>=2**10? ($1/2**10, "K"): ($1, "")}e';} alias intercept="sudo strace -ff -e trace=write -e write=1,2 -p" alias meminfo='free -m -l -t' alias ps?="ps aux | grep" alias volume="amixer get Master | sed '1,4 d' | cut -d [ -f 2 | cut -d ] -f 1"    #Network alias websiteget="wget --random-wait -r -p -e robots=off -U mozilla" alias listen="lsof -P -i -n" alias port='netstat -tulanp' gmail() { curl -u "$1" --silent "https://mail.google.com/mail/feed/atom" | sed -e 's/<\/fullcount.*/\n/' | sed -e 's/.*fullcount>//'} alias ipinfo="curl ifconfig.me && curl ifconfig.me/host" getlocation() { lynx -dump http://www.ip-adress.com/ip_tracer/?QRY=$1|grep address|egrep 'city|state|country'|awk '{print $3,$4,$5,$6,$7,$8}'|sed 's\ip address flag \\'|sed 's\My\\';}    #Funny kernelgraph() { lsmod | perl -e 'print "digraph \"lsmod\" {";<>;while(<>){@_=split/\s+/; print "\"$_[0]\" -> \"$_\"\n" for split/,/,$_[3]}print "}"' | dot -Tpng | display -;} alias busy="cat /dev/urandom | hexdump -C | grep \"ca fe\""