Category: Ubuntu

Ubuntu Server 12.04 – Changing Network Interface from DHCP to Static

I suppose this can be followed to set a static IP on your local network in Ubuntu Desktop as well, but this is explained with the expectation that you’re using terminal on an Ubuntu Server setup.

There are plenty of explanations of how to configure the server to use a set static IP instead of getting assigned one automatically by a DHCP server, but it seems that most tend to be incomplete. For example, it’s easy to find an explanation of editing the /etc/network/interfaces configuration to change a particular interface from using DHCP to a static address, but that seems to be where most end – which many will find leaves them unable to resolve any addresses outside the LAN after a system reboot. So I’m going to explain what I do that gets around this problem.

For every command you see here, I am executing them as root – which in some cases may require you to have sudo preceding it if you’re not. You can use the following command to login as root.

sudo su

First off, you need to open /etc/resolv.conf and note the listed IP addresses for the nameservers your server is automatically using with the DHCP settings. The reason you need to record these values is because when the machine is rebooted, the /etc/resolv.conf configuration gets overwritten – and the overwritten values will be empty since there is going to be no DHCP server providing them anymore. This is done by the DHCP client that is running on the server. Another workaround is to disable or remove the DHCP client, which will then stop the configuration from being overwritten – allowing the sustained values in /etc/resolv.conf to do the job. But I didn’t want to do that just in case I ever want to resume using the DHCP client later on, or in case I wanted to still use it for a different interface. I used nano to open the configuration.

nano /etc/resovl.conf

I simply copied the values for each nameserver in an open text editor, but you could write them down by hand on a notepad if that’s what you prefer.

The next step is the same as most other explanations: opening the network configuration and setting the static IP address.

nano /etc/network/interfaces

You’ll typically see configurations for just two interfaces here: the lo (or loopback interface) and eth0 (or the primary network interface). The settings for the primary network interface are the ones we want to edit. If your machine has multiple ethernet ports, you may see more than one, but in most cases you will just see the one. By default, it should look something like this.

# The primary network interface
auto eth0
iface eth0 inet dhcp

Instead of deleting the settings, I prefer to simply comment them out by placing a hash in front of them.

# The primary network interface
#auto eth0
#iface eth0 inet dhcp

The only reason I do this is so that if I decide to revert back to using DHCP for that interface, I only have to uncomment the lines and either remove or comment out the lines that I added to configure it for a static address.

The next step varies depending on the network. If you’re doing this for a home network running on a common residential router, it’s likely that the values for netmask should be the same (255.255.255.0). However, the other values could be slightly different, but hopefully you are aware of what they are if you are configuring any network settings in your home. For me, the network used the address range of 192.168.0.0 to 192.168.0.255 (including the network and broadcast addresses). The gateway address is almost always the first address in the network and assigned to the router itself, which for me is 192.168.0.1. I chose to assign the address of 192.168.0.100 to the Ubuntu server (similar to most other examples). Lastly, I included the values for the dns-nameservers since we will not be able to get them from the /etc/resolv.conf location after the network service has been restarted with our changes.

# The primary network interface
auto eth0
iface eth0 inet static
	address 192.168.0.100
	netmask 255.255.255.0
	gateway 192.168.0.1
	network 192.168.0.0
	broadcast 192.168.0.255
	dns-nameservers 0.0.0.0 1.1.1.1 2.2.2.2

You should replace with the values you see in my example on the line for dns-nameservers with those you recorded from your /etc/resolv.conf configuration. Each entry for the dns-nameservers should be separated by a space as shown. Do not create a new line with dns-nameservers <address> for each entry or else the network service will not accept it.

After doing this, you can simply restart the network service to apply the new settings, which apparently must be done as root – gives permission errors for me when trying to do it using sudo.

/etc/init.d/networking restart

Once this is done, you can check the active network settings to make sure the server is using the new address for the interface.

ifconfig

If everything looks good now, you should restart the server – place sudo in front of the command if not executing as root.

reboot

After the server has rebooted, test that the nameserver configuration did work and you can resolve outside addresses by pinging an address such as Google.

ping www.google.com

If you do not get an error, everything should be good to go. ūüôā

Ubuntu Unity: Keyboard Shortcuts and System Monitor

The Unity launcher is nice, and, like with Windows since version 7, you can pin – or “lock” – items to the launcher by right-clicking them when they’re running. For me, locking the System Monitor to the launcher was always one of the first things I had to do after setting up a new install of Ubuntu – though it could also be accessed by simply searching “system monitor” in the Unity dash. However, since upgrading to 13.04, I decided to try keeping a cleaner system, and that also meant not having a cluttered Unity launcher.

For me, some things are necessary to have on the launcher, such as my browser of choice, a link to LibreOffice and the files link to my Home directory. However, keeping things like Terminal and System Monitor seemed unnecessary, especially since there is already a shortcut to Terminal by default (CTRL+ALT+T). Being someone who was primarily a Windows user up until a little over a year ago, having a shortcut to an application that managed and monitored running processes was something I was used to and therefore depended on, and CTRL+ALT+Delete has always been the sacred keyboard combination for it. Luckily, setting up a keyboard shortcut in Unity to run its System Monitor isn’t difficult and only takes a minute to do, so long as you know the command for the shorcut.

  1. Go to System Settings > Keyboard and click on the Shortcuts tab.
  2. (Optional) If you’re assigning CTRL+ALT+Delete to open System Monitor, click on the System option under the category panel, click on Ctrl+Alt+Delete beside “Log out” and, when it says “New accelerator…” hit your backspace key to disable the shortcut.
  3. Click on Custom Shortcuts under the category panel.
  4. Click on the “+” icon below the shortcut list pane.
  5. In the field titled “Name:” type in the name of your shortcut (can be anything that tells you what it does).
  6. In the field titled “Command:”, type out the command you want the shortcut to process. In the case of running System Monitor, the command is gnome-system-monitor.
  7. Click on “Disabled” beside the name of your shortcut and when it says “New accelerator…” hit the key combination you wish to use for the shorcut on your keyboard, which you should then see listed in place of “Disabled” after you’re done.

Ubuntu Server: Adding Users to the Sudoers List

If you have ever ran an Ubuntu Server installation, you may be familiar with the /usr/sbin/visudo file, which lists everyone with super-user permissions on the system. The only user that is in the file with ALL permissions by default is root, which, by default, isn’t even accessible directly in current Ubuntu versions. Though the root user can be assigned a password so that logging in as root is possible, no one would recommend it – or at least no one that I have seen.

When you install Ubuntu Server, you create an initial user. This user is automatically placed in the sudoers group, which means this user can perform actions as the root user by using the command¬†sudo su¬† and providing their password. Perhaps you’ve wanted to create an additional user and add them to the list of sudoers so that, like your initial user, they can use the¬†sudo¬† command. Well, it only takes two commands to do this.

First, you create the user using the adduser command:

sudo adduser <username>

At this point, some tutorials online explain how to add this user to the /usr/sbin/visudo file with the same permissions as the root user. If you do this, you will practically be creating a duplicate root user who can do anything on the system. Instead, it’s best to simply add this user to the sudo group:

sudo adduser <username> sudo

If you exit your current terminal session, reopen the terminal and log in as the user you just created, you’ll notice that this user can also perform actions using the¬†sudo¬† command.

You can also check to see that the user is in the sudo group by viewing the groups users:

grep sudo /etc/group

Make sure the user is listed after your initial user and any other users you may have already added.

Similarly, you can remove a user from the group using the deluser  command:

sudo deluser <username> sudo

I recommend issuing the grep sudo /etc/group  command to ensure the user was removed as well.

Also, take note that the initial user created when installing Ubuntu 12.04 is added to the following groups as well, so if you’re intention is to create a user who is an ‘administrator’ on the machine, it may be wise to add them to all of the following groups.

adm
cdrom
sudo
dip
plugdev
lpadmin
sambashare

To see the list of groups on your server, simply issue the command grep <username> /etc/group , where <username> is the user you initially created during system install. Of course, you can ignore the group with the same name as the user.

XAMPP with Ubuntu

If you want a nicely compiled web server to use for testing, nothing beats XAMPP. And if you use Windows, it’s even nicer with XAMPP Lite. It’s so convenient, you can even run the server from a USB thumb drive.

However, I’ve learned recently that Linux doesn’t have quite as many convenient options. If you wish to set up a web server on Linux, there are countless tutorials across the net on doing it. For me, I just wanted something that I could run and test some things when I needed to without having to upload it to a production web server. Not to mention, it’s faster when everything is on a local machine. I was hoping that a XAMPP Lite setup had been released for Linux, but I was unfortunately wrong. Unlike Windows, Linux would require XAMPP to be installed in the /opt/ directory, which is owned by root. This means my system user wouldn’t be able to access the directory and directly alter files/folders, at least not without steps that extend beyond the directions given on the XAMPP website.

First off, I followed the directions for installing XAMPP exactly as described on the website. At first glance, everything looks fine. However, once I tried to access FTP using the default nobody user, I realized something was wrong. It gave me a 550 permissions error. Initial searching online seemed to indicate that the error wasn’t typical with others, so I figured something must have gone wrong with the installation. I had also installed the most recent beta version. I decided to uninstall, download the latest non-beta version and install it. Everything, again, went as expected with no errors. Again, I logged in via FTP and found that I could not create directories or alter files due to insufficient permissions. Doing a little more troubleshooting, I found that the lampp/htdocs folder was actually solely owned by root, instead of being owned by the user nobody and the root group. The nobody user had no ownership of the directory or its contained files/folders and therefore no permissions to affect it. I logged into root via terminal and changed ownership of the lampp/htdocs to nobody and from there everything worked fine accessing the directory via FTP.

A different approach would have been to change ownership of the directory to my own system user, this way I could directly alter the files/folders through nautilus without even having to run the proFTPD server. Since I am using the web server for testing locally anyway, this would have been the way to go.

For reference, here are the terminal commands used.

For listing ownership of files within a directory:

ls -l <path>

If you are already within the directory for which you want to list ownership of subsequent files and folders, you can leave the <path> value empty.

For changing ownership of the htdocs directory:

chown -R <username>:<usergroup> /opt/lampp/htdocs

Using your username for both the <username>  and <usergroup>  values will be fine.

The reason I recommend XAMPP over other Linux web server packages for using as a test server is that it is the easiest to uninstall that I have seen. Deleting the /opt/lampp directory is all that has to be done for complete removal.