(11.24.09 – This post was edited to expand the discussion on the various files read by Bash for login and sub-shells — iceflatline)
This post will describe how to set up command line aliases in Free Software Foundation’s “Bourne Again Shell” (BASH) for reducing common input mistakes and improving efficiency at the terminal.
Let’s take the simple case of a command like ls –a, which prints a list of the current directory’s files, including the hidden ones. Let’s change that command to something perhaps more efficient:
1
alias lsa='ls-a'
Nice. Now we need only to type lsa to get the same results. Not enough of an improvement over simply typing ls –a? Let’s take another example. Say we use something like the following command to routinely download a specific directory from a web site: wget -nH -r -l inf ftp://ftp.somewebsite.com/directory1/directory2/. Sure we could try to remember a string like this each time we need it and debug if mistakes are made, but let’s make it easier:
1
alias getdir='wget -nH -r -l inf ftp://ftp.somewebsite.com/directory1/directory2/'
You get the idea; I’m sure you can think of other examples. The point here is that each of these aliases will start to add up after awhile to help save you time and reduce mistakes.
Now, let’s say we open up a terminal and enter a few aliases like ones above. What happens when we close and reopen the terminal? Unfortunately aliases entered like this won’t carry over to the next bash shell session. To accomplish that we need to set up something more permanent.
There are three files in your home directory that hold a special meaning to Bash, allowing you to set up your environment automatically when you log in, when you start another Bash shell, and when you log out. These files may or may not exist depending on the Linux distribution you’re using. If they’re missing, Bash defaults to /etc/profile. These files are:
.bash_profile: read by Bash when you log into the system
.bashrc: read by Bash when you start a sub-shell
.bash_logout: read by Bash when a login shell exits
Bash allows two replacements for .bash_profile: .bash_login and .profile. However, only one of these files is read when you log in. If .bash_profile isn’t there, Bash will look for .bash_login. If that file is missing, it will look for .profile. If you start a sub-shell (e,g, a new terminal or X windows), Bash will read commands from .bashrc. Most users, however, want to have the same commands run regardless of whether it is a login shell or a sub-shell. This is typically done by including a small script (similar to the one for .myaliases below) or the line source .bashrc within .bash_profile to execute .bashrc. All the commands, including aliases, are then placed in .bashrc.
Using a text editor you can add your own aliases directly to .bashrc or, in some cases, simply uncomment ones that the distribution may have added for you (Ubuntu for example does this). Another approach is to create your own file containing your aliases and then simply point to that file from within .bashrc. This might be handy if you want to easily carry your aliases from one system to another. To do this, first create the file:
1
touch.myaliases
Now, open the file in your favorite editor and enter your aliases and save it. Here’s a list of the ones I often use:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
##Dynamic window resizing
shopt-scheckwinsize
## Custom prompts
#This one shows name@host and current directory
PS1="[\u@\h: \w]$ "
## Aliases
alias cls='clear'
alias ls='ls --color=auto'
alias lsa='ls -a --color=auto'
alias lsl='ls -a -l --color=auto'
alias lsi='ls -a -i --color=auto'
alias lsr='ls -R --color=auto'
Now, open .bashrc and add or uncomment the following script, making sure to modify the file name to match the file you created for your aliases; then save the file.
1
2
3
if[-f~/.myaliases];then
.~/.myaliases
fi
Now reboot the system or simply issue the following command to have bash recognize the aliases:
1
exec bash
That’s it. Your new aliases should be ready to go. You can get a list of your aliases at anytime using the command alias without any arguments, and you can temporarily “unalias” any alias you’ve set up with the command unalias aliasname. However, this will only last for as long as the shell session does. To permanently eliminate the alias you’ll need to delete it from your alias file.
But what if we want to have these aliases available when we log in or run a session as root, or another user? To do that we need to add our list of aliases to a file that is accessible to bash on a system-wide bases. In the case of a Fedora or a Fedora-based distribution, that file is most likely going to be /etc/bashrc, and the case of Ubuntu or other debian based distribution that file is likely to be /etc/bash.bashrc. Place your aliases at the end of those files and restart the system or use the command exec bash and they will be available regardless of which user you are.
(20130205 – This post has been amended to reflect the most recent version of LogMeIn Hamachi — iceflatline)
This post will describe how to set up a secure virtual private network (VPN) to your Ubuntu home server using the Linux version of LogMeIn Hamachi. Once configured, you’ll be able to use secure shell (SSH) to access and manage your server from anywhere outside of your home network without the need to forward ports or make any other configuration changes on your home network gateway/router.
LogMeIn Hamachi is a hosted VPN service that is capable of establishing secure LAN-like links between computers, even if they’re behind Network Address Translation (NAT) devices. You can use it to create secure virtual networks on demand, across public or private networks. In order for LogMeIn Hamachi to work, a “mediation server,” operated by the LogMeIn, is required. The mediation server stores machine nicknames, statically allocated IPv4 (IP) addresses in the 25.x.x.x range and the associated authentication token of the user. An overview, including protocol-level details of the security architecture employed by LogMeIn can be found at LogMeIn Hamachi.
LogMeIn Hamachi provides three network types for flexibility in meeting diverse use case scenarios. They differ mainly in network topology. LogMeIn Hamachi clients can be members of any network; however, depending on the network owner’s LogMeIn Hamachi subscription, networks have the following limitations:
Free subscription allows you to have five members in a network
Standard subscription allows you to have 32 members in a network
Premium subscription allows you to have 256 members in a network
Multi-network subscription or a LogMeIn Central subscription allows you to have 256 members in all your networks
Further information regarding the subscription types can be at LogMeIn Hamachi.
SSH is a open source program for logging into a remote machine and, in most cases, for executing commands on that machine. It provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. It is intended as a replacement for rlogin, rsh and rcp, and can be used to provide other applications with a secure communication channel. To use SSH, you will need to install an SSH client on the computer you connect from (most Linux distributions and Unix variations include an SSH client), and an SSH server on the computer you connect to. The most popular open source SSH client and server are maintained by the OpenSSH project.
The versions for the software used in this post were as follows:
LogMeIn Hamachi (Linux) v2.1.0.86-x64 (beta)
LogMeIn Hamachi (Windows) v2.1.0.284
OpenSSH Server v1:5.9p1-5ubuntu1
PuTTY v0.62
PuTTYgen v0.62
Ubuntu server v12.04 (x64)
So, let’s get started.
Installing the SSH Server
As you may recall, the OpenSSH server is an option you have the opportunity to select when you installed and setup your Ubuntu server. If you did not select that option, you’ll need to install the OpenSSH server manually:
1
sudo apt-get install openssh-server
If the SSH server was already installed apt will let you know, otherwise the installation will proceed. When complete, the SSH server daemon will start automatically. To check to make sure it’s running, use the following command:
1
ps-ax|grep sshd
Install and Configure LogMeIn Hamachi on the Ubuntu Server
The LogMeIn Hamachi Linux client comes as a single executable binary compiled for the platform of your choice. This binary includes the Hamachi daemon, the control application, and the setup utility. However, before we can successfully install LogMeIn Hamachi on our Ubuntu Server we must first install the Linux Standard Base (LSB). LSB is a standard Linux core system that some third-party applications written for Linux, like LogMeIn Hamachi, use for successful implementation across a variety of distributions:
1
sudo apt-get install lsb
With that dependency out of the way, let’s download the 64-bit Linux version of LogMeIn Hamachi to our Ubuntu server.
Then install it:
1
2
3
tar-zxvf logmein-hamachi-*
cd logmein-hamachi-*
sudo./install.sh
After LogMeIn Hamachi is installed it will start up as a background process (daemon) automatically. However, you can stop, start or restart the Hamachi daemon manually from the command line with the following commands:
1
2
3
4
5
sudo/etc/init.d/logmein-hamachi stop
sudo/etc/init.d/logmein-hamachi start
sudo/etc/init.d/logmein-hamachi restart
When the Hamachi daemon is run for the first time it stays offline. Let’s bring it online:
1
sudo hamachi login
You can change its status back to offline at any time using the following command:
1
sudo hamachi logout
Note that the daemon remembers its state if the Ubuntu server it is shutdown or if shutdown using the sudo /etc/init.d/logmein-hamachi stop command. So if its state was online, it will automatically go online when started next time. If it was offline, it will stay offline.
Next, let’s create a nickname for our Ubuntu server so that we can identify it easily from a remote client machine:
1
sudo hamachi set-nick<your_nickname>
Now, let’s create our LogMeIn Hamachi network. In this step you’ll need to enter a unique name for your network as well as a password for it. If your network name is already in use you’ll need to keep trying until you select one that’s unique. If you’ve previously setup a LogMeIn Hamachi network and want to simply add your server to it, then substitute join for create in the following command:
That’s it. Your LogMeIn Hamachi VPN should be up and running with your Ubuntu server added as one of its member hosts. You can display the status of LogMeIn Hamachi at any time by running the command sudo hamachi without any arguments. To display a full list of all the LogMeIn Hamachi command options, use sudo hamachi -h.
Install and Configure LogMeIn Hamachi on a Linux Client
Now that we’ve installed LogMeIn Hamachi on our Ubuntu Server and created a secure VPN, it’s time to install LogMeIn Hamachi on any Linux-based machines you’d like to use to access your server remotely. You can follow the steps explained above for the Ubuntu server in order to download and install LogMeIn Hamachi on your Linux macbine. Once installed, bring the logmein-hamachi daemon online:
Let’s check to make sure we can see our Ubuntu server on our LogMeIn Hamachi VPN. The following command will your networks (and their hosts) that you are a member of:
1
sudo hamachi list
Assuming that LogMeIn Hamachi is running on your Ubuntu server, you should see the nickname you created for the Ubuntu server listed, as well as the IP address assigned to it by LogMeIn (e.g., 25.x.x.x). An asterisk next to a host indicates that corresponding machine is currently online (Note: you will not see the machine your’re running the command from listed). Now that we have our Ubuntu server and our remote Linux client machine online, let’s see if we can initiate a terminal session with the server using SSH:
You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you are indeed connecting to your Ubuntu server, accept by typing yes and you’ll be presented with the login and password prompt. The public key from your Ubuntu server is stored in ~/.ssh/known_hosts. If you don’t want to have to remember the LogMeIn Hamachi IP address each time you want to run an SSH session with your server, simply add the IP address along with a name (e.g. home-server-ssh) to your hosts file (/etc/hosts). Next time you use LogMeIn Hamachi/SSH to connect to your server, use the name instead of the IP address and the host file will resolve the IP address for you.
Install and Configure LogMeIn Hamachi on a Windows Client
Configuring a Windows machine to access your Ubuntu server remotely is easy too. Download and install the Windows version of LogMeIn Hamachi. When you fire up the application for the first time, LogMeIn Hamachi will be in the offline state. Select the Power On icon on the top left of the application). A pop-up screen will appear asking you to enter the nickname to assign to your remote machine. After it is entered, the application will go online; however, we won’t see our Ubuntu server just yet, we first must add ourselves to the network we created. Select the “Join an existing network” and fill in the name of the network and the password you created when setting up the Ubuntu Server and select “Join”. You should see the name of the LogMeIn Hamachi network we created, as well the LogMeIn Hamachi IP address and nickname for our Ubuntu server appear in the screen (See Figure 1). Once installed, the LogMeIn Hamachi application will start whenever Windows starts and the user has logged in. You’ll find various configuration settings for the application under System->Preferences.
Figure 1
We’re almost there. Now we need to download and install an SSH application (Windows doesn’t support SSH natively). There are many out there to choose from, but the one I typically use is PuTTY, a free implementation of Telnet and SSH for Win32 and Linux/Unix platforms. Download PuTTY.exe (or the Installer version if you’d prefer) and run it. Enter the LogMeIn Hamachi IP address for your Ubuntu server in the Host name field, make sure to select the SSH radio button, and then select “Open” (See Figure 2).
Figure 2
You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you are indeed connecting to your Ubuntu server, accept by selecting Yes; a terminal emulator will open and you’ll be presented with the login and password prompt.
If you don’t want to have to remember the LogMeIn Hamachi IP address each time you want to run a session with your server, then simply add the address along with a name of your choice (e.g. home-server-ssh) to your hosts file (/windows/system32/drivers/etc/hosts). Next time you use SSH to connect to your server, use the name instead of the IP address and the hosts file will resolve the IP address for you.
Additional Security
As you may have noticed, we’re using conventional password authentication in order to prove to our Ubuntu server who we claim to be. That may be an acceptable level of authentication considering we’re also authenticating over SSH and a secure VPN tunnel. However, you may want to have a more secure form of authentication. Public key authentication is an alternative means of identifying yourself to your Ubuntu server. Instead of typing a password, you generate a key pair, consisting of a public key (which your server is allowed to know) and a private key (which you keep secret and do not give out). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine. Public key authentication is more secure and more flexible, but a little more difficult to set up. We’ll walk through the steps on both a Linux and a Windows client machine in the follow examples, but in essence what is involved is generating a key pair on our remote client machine, and copying the public key to the Ubuntu server. Then, when the server asks to prove who we are, the SSH application can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in.
Linux Client
Let’s set up our remote Linux client for public key authentication. We first need to generate the public/private key pair:
1
ssh-keygen–q–trsa
By default the RSA keys are 2048 bits. You can increase this to 4096 bits if desired with the -b option:
1
ssh-keygen–q–trsa–b4096
You’ll be asked by the script where it should store the keys (~/.ssh is the default), and then asked to enter in a passphrase in order to encrypt the private key that will be stored in this machine. If you don’t want to be asked for a passphrase each time you connect, just press enter. It is up to you to decide whether or not you should password encrypt your key when you create it. However, if you don’t, then anyone gaining access to your private key will automatically have SSH access to the server. After you enter a passphrase and confirm it, or simply hit enter, your encrypted private key (id_rsa) and your public key (id_rsa.pub) are generated and stored in ~/.ssh (assuming you accepted the default directory).
Now that our keys are generated, let’s move the public key to our Ubuntu server. Ensure that LogMeIn Hamachi is running, then enter the following command:
This command will copy your public key to ~/.ssh/authorized_keys on your Ubuntu server. That’s it. Now, next time you use SSH/LogMeIn Hamachi to initiate a session with your server you’ll be asked to provide the passphrase (if you provided one when you generated the keys) for your private key instead of your server password. Congrats, you’re now using public key authentication to login to your server. Once you know your key pair works back up both the public and private keys files to an offline media, such as a USB flash drive or CD.
Windows Client
Configuring our remote Windows client for public key authentication requires a little more work. First, we need a Windows application that can generate the public/private key pair. We’ll use PuTTYgen, PuTTY’s key generation utility, to perform this task. PuTTYgen is installed automatically if you use the Windows installer version of PuTTY, else you can simply download and use the standalone version of PuTTYgen.
Start PuTTYgen and verify that “SSH-2 RSA” is selected and change the “Number of bits in a generated key” field to 2048 (or more). Select “Generate” where you’ll be asked by PuTTYgen to move your mouse over the applications blank area in order to generate “randomness.” PuTTYgen will then proceed to create your public/private key pair (See Figure 3).
Figure 3
You may now enter a passphrase for you private key and confirm it. Again, it’s up to you to decide whether or not to protect your private key with a passphrase. However, electing not to means that anyone gaining access to your private key will have SSH access to the server. You also have the opportunity to modify the “Key comment” field. The default entry is the key type and the date it was created. If you intend on creating additional keys, you may wish to populate this field with something different in order to help you differentiate between the various keys.
When complete, select “Save private key” and choose a file name and a location to save the *.ppk file. Next, carefully copy the text contained in the “Public key for pasting into OpenSSH authorized_keys file” box into a text file and save it. Using a program like WinSCP copy the text file to your user account on the Ubuntu server. Now, login to this account and append the contents of this text file to the file ~/.ssh/authorized_keys and make sure permissions are set correctly:
1
2
cat~/<your-text-file>>>~/.ssh/authorized_keys
chmod700~/.ssh&&chmod600~/.ssh/authorized_keys
We’re done with PuTTYgen so let’s exit the program. Now fire up PuTTY and navigate to Connection->SSH->Auth. Under Authentication parameters select the Browse button and select the *.ppk file you saved in the previous step (See Figure 4). Now, navigate back up to Session and enter the LogMeIn Hamachi IP address for your server in the Host name field, make sure to select the SSH radio button, and then select Open (of course, LogMeIn Hamachi should be running). You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by selecting Yes; you’ll be asked to provide the passphrase (if you created one) for your private key instead of your server password. Congrats, you’re now using public key authentication to login to your server. Once you know your key pair works back up both the public and private keys files to an offline media, such as a USB flash drive or CD.
Figure 4
Now that we have public key authentication set up, you may be wondering if you can still logon to the server without a private key? In other words, can you still use your server username and password? The answer is yes. However, that can be changed. After you’re sure that public key authentication is working on the remote machines you’ll be using to access your Ubuntu server, you may want to consider shutting down password authentication. To do that, logon on to your server and open the OpenSSH server’s config file (/etc/ssh/sshd_config). Look for the line #PasswordAuthentication yes and change it to PasswordAuthentication no (Make sure to uncomment the line). Then restart the SSH server with the following command:
1
sudo/etc/init.d/ssh restart
Conclusion
Good times eh? Using some open source tools and LogMeIn Hamachi, we set up a secure VPN between remote Windows and Linux clients, and our Ubuntu server. And, we didn’t have to touch our home gateway/router. We also improved the security of the network by using public key authentication.
(20141224 – This post has been amended to address changes in recent versions of Ubuntu, and to remove outdated instructions — iceflatline)
This post will describe how to use the Window 7 boot configuration data editor (BCDEdit) to configure a Windows 7 system that can boot to Windows 7 or a Linux distribution. The steps described in this post assume that Windows 7 and the Linux distribution will occupy the same physical hard drive. Configuring BCDEdit to recognize and boot a Linux distribution located on a second physical hard drive is beyond the scope of this post.
To help explain the steps involved, we’ll use an 320 GB SATA hard drive with Windows 7 already installed. We’ll reduce the size of the partition containing the Windows 7 operating system and re-partition the remaining unallocated disk space in order to install the Linux distribution Ubuntu. We’ll then use BCDedit to add a Windows boot menu option for Ubuntu. All steps involved assume you have a functioning CD drive (or USB drive if you’d prefer) that the system can boot from. The software versions used in this post were as follows:
Ubuntu v14.10 (x64)
Windows 7 Professional (x64)
Oh…, and while I’ve never encountered a situation where the Windows 7 Disk Management tool destroyed existing disk data, make sure you backup any critical files before you proceed.
So, let’s get started.
Reducing the Windows Partition
The first thing that we need to do is reduce the size of the existing Windows 7 partition. While you can use third-party applications like GParted, I found Windows 7’s own Disk Management tool to be the most efficient method for accomplishing this task. The Disk Management tool can be accessed by using Win+r and entering the command diskmgmt.msc.
You’ll notice that Windows 7 currently occupies all of the existing disk space using two primary partitions: one small boot partition; the other for the operating system. When finished, we’ll have five partitions in total: the two Windows 7-related partitions just mentioned, and ones for the Ubuntu operating system and Linux swap. We’ll also create a small FAT32 partition for sharing data between Windows 7 and Ubuntu. You’ll need to determine how much space you want to allocate to each of these additional partitions based on your requirements and disk size. For our 320 GB disk example, we’ll use the following partition layout:
Windows 7: ~100MB (Windows 7 boot loader)
Windows 7: ~251 GB
Ubuntu: ~31 GB
Linux-Swap: ~1 GB
FAT32: ~16 GB
Right-click on the Windows 7 volume (C:) and selected “Shrink Volume.” Then enter the amount of space (in Megabytes) that the partition should shrink (which in turn becomes the amount of space available to install our Linux distribution), which in our example is 48000 Megabytes (48 Gigabytes), then select “Shrink” (See Figure 1). When complete, exit out of the Disk Management tool and reboot the system.
Figure 1
Installing Ubuntu
Now it’s time to partition our 48 GB of unallocatd disk space and install Ubuntu. Download a copy of Ubuntu Desktop and burn it to a CD (or place it on a bootable USB drive). Boot the system using the Ubuntu disk. Select “Try Ubuntu…” and then double-click the “Install Ubuntu…” icon when the desktop appears. Continue through the installation process until you arrive at “Installation type” and select “Something else”, then select “Continue”. (See Figure 2).
Figure 2
The screen that follows is where we’ll instruct Ubuntu how to partition the unallocated disk space. Left-click on “free space” to highlight it and then select the “+” icon to create a new partition. Make the size of this partition 31000 MB. Ensure it’s a primary partition, and located at the beginning of the free space. Select the Ext4 journaling file system and, since this partition will serve as the root partition for Ubuntu, set the mount point to / from the list of choices in the drop-down lists. Now select “OK” to accept the changes (See Figure 3).
Figure 3
Now let’s create a partition for use as Linux swap space. Once again, left-click on free space to highlight it and then select the + icon to create a new partition. Make the size of this partition 1000 MB. Our disk is limited to a maximum of four primary partitions, so we’ll make this a logical partition – again located at the beginning of the free space. Select “swap area” from the list of choices in the drop-down list, then select “OK” to accept the changes (See Figure 4).
Figure 4
Using similar steps, let’s partition the remaining free space as a FAT32 file system. This too should be a logical parition, located at the beginning of the space. You may also wish to set the mount point to /media/share, or something similar. The benefit of selecting a mount point at this stage is that Ubuntu will add this partition to the file /etc/fstab so that the system automatically mounts it at boot time. No worries though, you can always select a different mount point and manually mount it and/or add it to /etc/fstab at a later time. When complete, select “OK” to accept the changes (See Figure 5).
Figure 5
The final step is critical. We need to tell the Ubuntu installer where to install the system bootloader (GRUB 2). We DO NOT want to install the bootloader on /dev/sda, as that would overwrite our disk’s master boot record, nor do we want to install it on /dev/sda1 or /dev/sda2, as that would overwrite the Windows 7 bootmanager files and boot configuration data, or the operating system itself. Instead, let’s have Ubuntu install its bootloader on the partition that will contain the Ubuntu operating system – in our case /dev/sda3. To do this, click on the drop down list under “Device for boot loader installation” and select /dev/sda3 (See Figure 6).
Figure 6
Select “Install Now” and Ubuntu will begin the installation. When it completes you’ll be asked whether you’d like to reboot or “continue testing”. You should select continue testing as the following steps require access to a terminal.
Configure Windows for Dual Boot
Now that we have our disk partitioned and Ubuntu installed, let’s set up our system to boot Windows 7 or Ubuntu. This will involve copying the boot record of our Ubuntu partition to Windows 7, and using BCDEdit to create a new entry in the BCD store that will point to that file. This way Windows 7 will display a menu at boot time that will give you a choice between Windows 7 and Ubuntu.
First, let’s make a mount point for the FAT32 partition we created. Open a terminal and enter the following:
1
2
sudo su
mkdir/mnt/share
Next, let’s mount the correct device to this directory. Recall from the partitioning steps above that the FAT32 partition is located at device /dev/sda6:
1
mount/dev/sda6/mnt/share
Write the first 512 bytes of our Ubuntu partition to a file and copy that file to our FAT32 partition:
Note: using the FAT32 partition in the aforementioned steps is optional. You may chose to use another device such as a USB drive to copy the *.bin file to.
Exit out of the Ubuntu live system and reboot to Windows 7. Along the way, you may see Windows perform a disk check (don’t worry, that’s normal, and should only occur once as a result of these procedures). Log into Windows 7 and open the FAT32 volume you created and you should see the ubuntu.bin file. Copy that file to the root of the Windows 7 volume (e.g., C:).
Now we’ll use BCDEdit to add an entry to Windows 7’s BCD store. Administrative privileges are required to use BCDEdit, so use Win+r, type cmd, and then press CTRL+SHIFT+ENTER. Let’s start by creating an entry for our Linux distribution. Note here that you are free to choose another entry name if desired:
1
bcdedit/create/d“Ubuntu”/application bootsector
BCDEdit will return an alphanumeric identifier for this entry that I will refer to as {ID} in the remaining steps. You’ll need to replace {ID} by the actual returned identifier. An example of {ID} is {d7294d4e-9837-11de-99ac-f3f3a79e3e93}. Next, let’s specify which partition hosts a copy of the linux.bin file:
1
bcdedit/set{ID}device partition=c:
The path to our ubuntu.bin file:
1
bcdedit/set{ID}path\ubuntu.bin
An entry to the displayed menu at boot time:
1
bcdedit/displayorder{ID}/addlast
and finally, let’s specify how long the menu choices will be displayed:
1
bcdedit/timeout30
That’s it! Now reboot and you will be presented with menu where you can choose to boot to Windows 7 or Ubuntu. When you choose Ubuntu, you’ll be taken to the it bootloader menu where you can choose to continue booting Ubuntu.
On a final note, if at any time you want to eliminate the Ubuntu menu option simply delete the BCD store entry you created using the following command:
1
bcdedit/delete{ID}
Conclusion
With a minimal amount time and a little Windows command line foo, you can easily set up a system that can dual boot Windows 7 and your choice of Linux distributions.
While the default XTerminal or Gnome Terminal that comes with Ubuntu is just fine, I had the occasion recently to use Xubuntu, a Ubuntu derivative that uses the Xfce desktop environment. I really fell in love with Xfce-Terminal, Xubuntu’s default terminal emulator. This article will describe how to install Xfce-Terminal and configure some of its options.
Written for the Xfce desktop environment, Xfce-Terminal is a modern, lightweight, and low memory cost terminal emulator for X11. It offers full-customization for the key bindings, the aspect ratio, the colors, and the ability to use multiple tabs with terminals within a single window. Most importantly though, it doesn’t bore you to tears looking it all the time.
Figure 1
Install and Configure
To install Xfce-Terminal on Ubuntu use apt-get:
1
sudo apt-get install xfce4-terminal
To install Xfce-Terminal on Fedora* use yum:
1
su-c'yum groupinstall xfce'
* A quick note concerning the installation on Fedora. The Xfce project site offers the source tarball for Xfce-Terminal but I simply ran into too many unresolvable package dependency problems while trying to compile it on Fedora 11. This command simply installs the Xfce desktop environment, which includes Xfce-Terminal, and you won’t have to switch to Xfce in order to use it.
After the package is installed you can find a link to Xfce-Terminal under Applications -> Accessories (Ubuntu) or Applications -> System Tools (Fedora). Of course, you can also start from the application launcher – just hit Alt-F2 and use the command xfce4-terminal (Ubuntu) or Terminal (Fedora). Xfce-Terminal will use the login shell of the user who starts the application (/bin/bash in case of a typical Linux system).
Configuration is easy. Open Edit->Preferences to bring up the Preferences dialog allowing you to tweak Xfce-Terminal to your liking. The settings are stored in ~/.config/terminalrc (Ubuntu) or ~/.config/Terminal/terminalrc (Fedora), which also stores a few hidden options for settings that are not included in the user interface.
You can also customize the behavior of Xfce-Terminal by passing along options via the command line. For example:
1
xfce4-terminal--geometry80x40--title foo
In this case, the terminal will launch with a window that is 80 columns * 40 rows and with the title “foo.”
One of the things I also find really useful is the tab feature that enables you to open several terminals within a single window. Since each tabbed terminal in the window is a separate subprocess, you can also use each terminal for a different task. For example:
1
xfce4-terminal--tab--command nano
This would result in two tabs; one terminal window open and ready with a command prompt, the other open with nano ready to go.
Just substitute Terminal for xfce4-terminal in the preceding commands when working in Fedora.
Conclusion
Terminal emulators are like your significant other – you have to be with them all the time so you might as well get the one you want. Xfce-Terminal is certainly worthy of a look for those looking for a nicer experience than the standard XTerminal or GNOME Terminal. You can find out more about Xfce-Terminal at the developer’s site.
Have a favorite terminal emulator? Leave a comment on what you use and why you like it.
(20161025 – The software versions used in this post were updated — iceflatline)
(20150902 – The steps and script in this post were amended to remove logging — iceflatline)
This post will describe how to install and configure Tobi Oetiker’s MRTG (Multi Router Traffic Grapher) on your Ubuntu server. All steps assume that the Apache http server is installed and operating correctly. Once configured, you’ll be able to use MRTG to monitor the traffic in and out of your network using the SNMP capability in your network’s gateway\router. MRTG generates static HTML pages containing PNG images which provide a visual representation of this traffic. MRTG typically produces daily, weekly, monthly, and yearly graphs. MRTG is written in perl and works on Unix/Linux as well as Windows. MRTG is free software licensed under the GNU GPL.
Software versions used in this post were as follows:
Ubuntu Server v16.04.1 x64 LTS)
mrtg v2.17.4-3ubuntu1
So, let’s get started.
Download and Install
First, update your package list:
1
sudo apt-get update
Then download and install MRTG:
1
sudo apt-get install mrtg
If this is the first time installing MRTG on your server you’ll likely be presented with the following message (See Figure 1). Answering “Yes” means that the MRTG configuration file will not be readable by others (file permissions set to 640). Answering “No” means that the file is readable by others (file permissions set to 644). In this example we’re going to accept the default Yes.
Figure 1
MRTG installs a sample configuration file /etc/mrtg.cfg used to hold the SNMP information obtained from your gateway\router. For a full listing of what MRTG installs and where, run the locate command:
1
sudo updatedb&&locate mrtg
Technically speaking, mrtg.cfg could remain in /etc, but just to keep things tidy let’s create a directory for it and move it into that directory:
That’s it for installing MRTG. Now let’s move on and configure it.
Configure
MRTG includes a script called cfgmaker that will help us populate /etc/mrtg/mrtg.cfg with the information obtained from your gateway\router. But before you run cfgmaker, you should setup the SNMP service in your gateway\router. This usually involves logging into your gateway\router and enabling SNMP. The default SNMP community name is typically “public.” If you change the SNMP community name to something else, make note of it. Now, run the following command, substituting your SNMP community name, if you’ve changed it, and adding the IP address of your gateway\router:
If you would like to add more than one gateway\router to MRTG simply append the additional URL(s) to the same mrtg.cfg file. Then, when you build the web page using the indexmaker command described below, all the gateway\routers (and their associated graphs) will be displayed on the same HTML page.
Next, open /etc/mrtg/mrtg.cfg and make sure under Global Configuration Options that the lines “WorkDir: /var/www/mrtg” (under Debian), and “Options[_]: growright, bits” (under Global Defaults) are uncommented. Finally, add the following lines to the existing line EnableIPv6: no under the Global Defaults section:
1
2
RunAsDaemon:Yes
Interval:5
What does all this do? The line RunAsDaemon: Yes will enable MRTG to…um… run as a daemon. This is beneficial because MRTG is launched only once, thus the parsing of the /etc/mrtg/mrtg.cfg file is done only once, not repeatedly as would be the case if one were to run MRTG as a cron task – another acceptable method for running MRTG. Also, when running as a daemon, MRTG itself is responsible for timing the measurement intervals; therefore, we need to add the Interval line option and assign it a value – in this example 5. This means that every five minutes MRTG will poll the SNMP service in your gateway\router and update its graphs. Finally, since many gateway\routers do not currently support SNMP over IPv6, we’ll retain the line EnableIPv6: no.
Speaking of graphs, by default MRTG graphs grow to the left, so by adding the option “growright” the direction of the traffic visible in MRTG’s graphs flips causing the current time to be at the right edge of the graph and the history values to the left. We’ve also chosen the “bits” option, which means that the monitored traffic values obtained from your gateway\router are multiplied by 8 and displayed bits per second instead of bytes per second.
Okay, now it’s time to create the web pages which display the MRTG graphs using the indexmaker command. Run the following commands:
Open /etc/apache2/apache2.conf and add the following lines in the section containing similar Directory directives:
1
2
3
4
5
6
7
Alias/mrtg"/var/www/mrtg/"
<Directory"/var/www/mrtg/">
Options None
AllowOverride None
Require all granted
</Directory>
Then restart Apache:
1
sudo service apache2 restart
When restarting Apache you may receive a warning concerning its inability to “…reliably determine the server’s fully qualified domain name…” This non-critical error can be fixed by adding the following line to /etc/apache2/apache2.conf:
1
ServerName locahost:80
MRTG has been configured. Let’s start it up and see what it displays.
Start
There’s something important to keep in mind when starting MRTG, and that is that MRTG requires the environmental variable “LANG” to be C in order to run properly. Since most Linux systems these days, including Ubuntu server, use UTF-8 (run echo $LANG to see what your system uses), let’s change LANG to C and start MRTG using the following command:
1
sudo env LANG=C/usr/bin/mrtg/etc/mrtg/mrtg.cfg
When you run MRTG for the first time you may see a lot of complaints about missing log files. No worries, this is normal for the first 2-3 times you start MRTG this way. If, however, it continues to complain you may want to look into the source of the problem.
Well, that’s it. Now point your browser to http://your-server-address/mrtg and you should see a page that resembles Figure 2. You may have more or less graphs depending on the number of interfaces reported by your gateway\router(s).
Figure 2
Because of the aforementioned option in /etc/mrtg/mrtg.cfg, you’ll see the graph starting “grow” to the right as the traffic is monitored over time, and the Y axis displayed as bits per second. If you click on any one of these graphs you’ll be taken to another page showing individual graphs for 30 minute, two hour, and daily averages, along with the maximum, average, and current bit rate in and out of that particular interface. Only interested in displaying one particular interface? Want to graph other SNMP data? No worries, just remember to run indexmaker again to update the MRTG index.html file.
Okay, so now that we have MRTG installed, configured and running let’s move on and discuss how to keep it running.
Operate
Starting MRTG by hand is not ideal in the long run. So perhaps after you’ve done some tweaking on MRTG and are satisfied with the results, you can automate the process of running MRTG by using a startup script in your system startup sequence. Here’s the script that I use:
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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
#! /bin/sh
### BEGIN INIT INFO
# Provides: mrtg
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: mrtg init script
# Description: This file is used to start, stop, restart,
# and determined status of the mrtg daemon.
# Author: iceflatline <iceflatline@gmail.com>
### END INIT INFO
### START OF SCRIPT
set-e
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="mrtg"
NAME=mrtg
DAEMON=/usr/bin/$NAME
DAEMON_ARGS="/etc/mrtg/mrtg.cfg"
PIDFILE=/etc/mrtg/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the mrtg package is not installed
[-x"$DAEMON"]||exit0
# Load the VERBOSE setting and other rcS variables
./lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
To use the script, save it to your home directory as mrtg and make it executable. Then move or copy it to /etc/init.d:
1
2
3
cd~
chmod+xmrtg
sudo mv mrtg/etc/init.d/
Now, link the mrtg script to all of Ubuntu server’s multi-user run levels (2-5):
1
sudo update-rc.dmrtg defaults
Now, let’s start MRTG using our script. If it’s currently running then substitute restart for start in the following command:
1
sudo service mrtg start
That’s it. Now if for some reason your server is rebooted, MRTG should fire up automatically. If you would like to remove the MRTG script from the server’s multi-user run levels, use the command sudo update-rc.d -f mrtg remove).
Conclusion
This concludes the post on how to install and configure MRTG on Ubuntu server. As you can see, MRTG isn’t terribly complicated and proves to be a really nice open source package for monitoring and displaying traffic in and out your network from virtually anywhere you have a web browser. For a full list of all the configuration options and other information I encourage you to visit the MRTG web site.
