Ubuntu 12.10: Connect to Microsoft VPN

I recently upgraded to Ubuntu 12.10 on my main desktop machine from scratch, which means a number of things which had been installed and configured need to be re-done. One of those things is my VPN connection to work, which runs Windows 2008 Server for VPN.

If you have ever tried to configure a linux machine to connect to a Microsoft-based VPN, you know that it is not as straightforward as it could be. It is more of a voodoo ritual than a science. I figured it would be a good idea to capture the steps for future reference.

This first part is adapted from the Ubuntu Wiki for posterity. You can check out the original at https://wiki.ubuntu.com/VPN under the heading VPN setup in Ubuntu 9.10. Apparently this originates from a Ubuntu forums post by user sweisler at http://ubuntuforums.org/showpost.php?p=8261958&postcount=6. Thanks sweisler, wherever you are.

First, there was no need to install any additional packages, apparently everything needed is included by default.

• Open VPN configuration screen:
  • Click on the network icon in the upper right of the desktop
  • Go to the VPN Connections menu
  • Select Configure VPN…
• Add a new PPTP connection
• On the VPN tab, set the following:
  • Connection name (whatever you want)
  • Uncheck Connect automatically (you can change this later)
  • Gateway (this is the VPN server)
  • User name (for domain-based user accounts, use domain\username)
  • Do not set Password; do change the pulldown to Always Ask
  • Do not set NT Domain
  • Uncheck Available to all users (this works either way, but I am assuming you don’t really want your kid to have access to the VPN)
• PPTP Advanced Options (Advanced button from the VPN tab)
  • Uncheck all authentication methods except MSCHAPv2
  • Check Use Point-to-Point encryption (MPPE)
  • Leave Security set at All Available (Default)
  • Check Allow stateful inspection
  • Uncheck Allow BSD data compression
  • Uncheck Allow Deflate data compression
  • Uncheck Use TCP header compression
  • Uncheck Send PPP echo packets (this setting works either way, check it for debugging purposes)

At this point save it and test it. Once the VPN connection is working you may want to try to tweak it further as described below.

One problem with the VPN I connect to is that all traffic ends up using the VPN when I am connected. This is less than ideal if you are connecting to servers on the internet while the VPN is connected since the traffic goes through the VPN server before coming to you. The following describes the settings for routing only the proper traffic to the VPN. (Read them all the way through first to make sure you have all the necessary information.)

• On the IPv4 Settings tab
  • Set Additional DNS servers using the IP address of the DNS server for the VPN. (You may need to ask your IT guy for this; there should be a way to discover it when connecting as above but it escapes me.)
  • Set Additional search domains. Set this to the domain suffix of the machines on the VPN. For example, if the machines like dbserver.example.com then set it to example.com.
• Click the Routes button.
  • Check Use this connection only for resources on its network
  • Add a route:
    • For Address, use the internal IP address of the VPN server applied against the netmask below, e.g. if the VPN server is 10.0.0.10 and the netmask is 255.255.255.0, use 10.0.0.0 (this is different in 14.04, in the past one could just use the IP of the VPN server). Again, this should be the internal IP address for getting to the machine in the intranet, not the external IP address for getting to the machine from the internet.
    • For Netmask, use the netmask of your intranet. (If you are confused, ask your IT guy what to use for both this and the Address.) For most networks this will be 255.255.255.0, but for many it will be different.
    • For Gateway, use the external IP address of the VPN server. This should match the Gateway defined on the VPN tab. (I’m not sure what happens if you are using a server name there. I suspect you should match the names, but you may need to experiment.)
    • Do not set the Metric unless you know what you are doing.

OK, so now when you connect you should see regular traffic going directly to the internet and intranet traffic directed to the VPN server. You can test this out with traceroute (which you may need to install). You should also be able to refer to machines on the intranet using their short names (e.g. dbserver instead of dbserver.example.com).

Let me know how these instructions work for you and what type of systems you’ve been able to connect.

Ubuntu 12.10: Minidlna on Boot

A big hat tip to Asaf Shahar for this one.

I recently upgraded to Ubuntu 12.10 on my main desktop machine from scratch, which means a number of things which had been installed and configured need to be re-done. One of those things is minidlna, a lightweight DLNA server.

If you don’t know, DLNA is a protocol for sharing media to devices. In my case, I use it to stream music, video and pictures from my desktop to my Blu-Ray player. It’s not perfect, at least in that the interface on the Blu-Ray player leaves much to be desired, but it works.

Minidlna does not come standard with Ubuntu, but it is in the repositories and installation is as easy as sudo apt-get install minidlna. Afterwards you configure /etc/minidlna.conf and you are good to go. The comments inside /etc/minidlna.conf are good enough that you won’t need further guidance from me here.

While all that was relatively painless, I soon discovered that minidlna was not starting on reboot. I checked the script in /etc/init.d and the symlinks in the various /etc/rc#.d/ directories and everything was correct. It started no problem by hand after boot using sudo service minidlna start. It was time to take the fight to google.

I quickly discovered a bug report that seemed appropriate. Apparently minidlna is attempting to start before networking is up and that causes it to error out. (If you have changed to Ubuntu 12.10 you may have noticed that networking does not start until after the login screen is displayed — a curious decision.)

If you have taken a look at the bug report, you’ll see a work-around posted by Asaf Shahar. He created a script using upstart to transform minidlna into a service managed by that tool.

I wasn’t quite convinced that was the answer for me, because that solution would skip whatever set up occurs in the /etc/init.d/minidlna script. At first I thought I could change his upstart script to simply invoke the minidlna script instead of the executable, but upstart was not created with that use in mind. (When creating an upstart service, upstart expects the executable to fork 1 or 2 times; a script will fork a great number of times and there is no way to tell upstart which process is actually the server process.)

The next natural solution would be to integrate the /etc/init.d/minidlna script into Shahar’s upstart script. But that would mean keeping the script up to date whenever the /etc/init.d/minidlna script changed. That’s not really something I want to have to do; after all I might even miss the fact that minidlna was updated. So another solution was needed.

In the process of researching upstart I discovered that one can use it for more than just servers. It can also execute a task (i.e. a short-lived process expected to finish on its own). I decided to have upstart run the minidlna script once the machine booted and networking was enabled. Now this is not perfect in that minidlna is still trying to start and failing on the normal boot process, but I can live with that.

To do this, create a file called /etc/init/start-minidlna.conf with the following contents:

# Task to start Minidlna - lightweight DLNA/UPNP media server # Minidlna is not starting correctly on boot, see bug # https://bugs.launchpad.net/ubuntu/+source/minidlna/+bug/1053173 # description "Task to start minidlna" start on (local-filesystems and net-device-up IFACE!=lo) task exec service minidlna start

That’s all there is to it. Now minidlna starts on boot. Once again I want to thank Asaf Shahar for his help.

Installing Ubuntu 12.10 on an SSD, Part 3

Recently I took the plunge and put an SSD drive into my desktop. Since I needed to re-install the OS, I figured I would install the latest Ubuntu, version 12.10. I went over my trials and tribulations of getting the OS installed in part 1, and dealt with swap in part 2. Today we finish up the tweaks for the SSD.

First we add noatime and discard to the /etc/fstab options for the drive:

UUID=abc... / ext4 errors=remount-ro,noatime,discard 0 1

(Note I cut my UUID for brevity. Yours should be much longer.) The noatime option keeps the OS from updating the access time of a file every time it is read. This reduces the number of writes to the SSD drive. The discard option enables the TRIM command on the file system. There are some details to delve into for this depending on your particular SSD, read about it at https://wiki.archlinux.org/index.php/Solid_State_Drives. For most drives you’ll want it enabled.

Next we change the I/O scheduler to use the deadline algorithm instead of elevator algorithm. For a traditional hard disk drive, the data is read from the platter by a head. The head must be moved to the correct position to read the desired data. The disk spins, which means the head need only move in one dimension, radially. For this reason, the scheduling algorithms for hard disk drives are referred to as elevator algorithms.

The SSD does not have the same limitations as the HDD. There is no head to move into position in order to read or write the data. So it is not really important what order the I/O is scheduled. There is no reason to force some I/O operations to wait while others, requested later, are served as would happen in the elevator algorithm. So instead we use the deadline algorithm, where each operation is assigned a deadline.

Since we have a mixed environment, we cannot just set it system wide via grub kernel options. That is, we can’t just use the elevator or deadline algorithm for all disks since we have both HDDs and SSDs. In order to use the correct algorithm with the proper drive type, create a file in /etc/udev/rules.d with contents:

# set deadline scheduler for non-rotating disks ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline" # set cfq scheduler for rotating disks ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

I named mine 99-scheduler.rules. The files in this directory are automatically processed by udev, the device manager for the kernel. Note that cfq, or Completely Fair Queuing, is the default. For more information, go to http://en.wikipedia.org/wiki/CFQ.

The next tweak to make is to do something about the /tmp directory. This is another change that is designed to reduce writes to the SSD (an overblown concern) but you might appreciate the effects on your system in any case. I decided to mount the /tmp directory in RAM. Add the following to /etc/fstab (or replace any existing mount for /tmp):

none /tmp tmpfs defaults 0 0

By default this uses about half the RAM for /tmp. If you want more control, you can use a line like:

tmpfs /tmp tmpfs nodev,nosuid,size=7G 0 0

Keep in mind that certain operations that write large files to /tmp might be adversely affected; for example, burning a large DVD.

Resources:

• https://wiki.archlinux.org/index.php/Solid_State_Drives
• http://forums.fedoraforum.org/showthread.php?t=256068
• https://help.ubuntu.com/community/Boot-Repair
• http://en.wikipedia.org/wiki/BIOS_Boot_partition
• https://help.ubuntu.com/community/SwapFaq
• http://www.kernel.org/doc/Documentation/sysctl/vm.txt

Installing Ubuntu 12.10 on an SSD, Part 2

Recently I took the plunge and put an SSD drive into my desktop. Since I needed to re-install the OS, I figured I would install the latest Ubuntu, version 12.10. I went over my trials and tribulations of getting the OS installed in part 1, today we are going to talk about some changes I made afterwards to support the SSD.

First things first: dealing with the swap partition. I had a swap partition on the old HDD but what is the point of having all your programs load quickly if swap is going to be on the old, slow disk? I decided to deactivate the swap partition and go with a swap file moving forward for maximum flexibility.

Everything I read said that modern linux kernels will perform just as well with a swap file as a swap partition. The only documented drawback I found was that the Ubuntu hibernate implementation (that’s the OS hibernate function not the Java Hibernate persistence engine) does not work with a swap file and requires a swap partition. Since I never use that functionality, I was good to go:

# Create the swap file as an empty, 8GiB file sudo fallocate -l 8g /mnt/8GiB.swap # The swap file should not be readable by normal users, otherwise they # could snoop on the memory of other user's processes sudo chmod 600 /mnt/8GiB.swap # Format the file as swap sudo mkswap /mnt/8GiB.swap # Tell the OS about the new swap file sudo swapon /mnt/8GiB.swap # Check if it worked cat /proc/meminfo # Determine old swap partition device sudo fdisk -l /dev/sdb # Decommission the old swap partition (your specific partition will vary) sudo swapoff /dev/sdb6

At this point there is some housekeeping to do in /etc/fstab file to ensure the changes persist on the next boot. Remove the line for the old swap partition and add the following for the new swap file:

/mnt/8GiB.swap none swap sw 0 0

Now we want to balance the fact that the swap file is on the SSD with the desire to reduce writes to the SSD to prolong the life of the drive. (Although I am of the opinion that such concerns are overblown, I like the effect of this change anyway.) We will tell the system to prefer RAM over swap using the swappiness setting. Add (or edit) the following in /etc/sysctl.conf

vm.swappiness=1 vm.vfs_cache_pressure=50

If you are interested in the technical details as to what these settings do, check out the documentation at http://www.kernel.org/doc/Documentation/sysctl/vm.txt.

With the swap configuration complete, we turn our attention to a couple of other tweaks for the SSD performance. However, that will have to wait for the next entry.

Resources:

• https://wiki.archlinux.org/index.php/Solid_State_Drives
• http://forums.fedoraforum.org/showthread.php?t=256068
• https://help.ubuntu.com/community/Boot-Repair
• http://en.wikipedia.org/wiki/BIOS_Boot_partition
• https://help.ubuntu.com/community/SwapFaq
• http://www.kernel.org/doc/Documentation/sysctl/vm.txt

Installing Ubuntu 12.10 on an SSD, Part 1

Recently I took the plunge and put an SSD drive into my desktop. Since I needed to re-install the OS, I figured I would install the latest Ubuntu, version 12.10.

I had hoped things would go smoother. When running the installer it would hang after the second screen the first time through (unfortunately I ended up installing a couple of times). This is the screen where they tell you to verify the computer has enough space and is connected to the internet (see http://www.debianadmin.com/wp-content/gallery/quantal/3.png). Aftering clicking Continue I would just get the spinning mouse icon. Fortunately the Quit button worked and dropped me into the sample desktop. From there running the install again worked more smoothly.

I kept my old installation around on the old disk for reference. For example, it would make re-configuring my NFS shares easy. So I had three disks: my large HDD for /home, my old OS HDD disk mounted on /u1204 and the new SSD which would contain 12.10. The installation completed and I rebooted.

And was promptly dropped back into my old installation. Must be a BIOS issue, I figured. I rebooted and went into the BIOS set-up. It took me a while to realize that my BIOS was a little different from what I had been used to (a few months ago I upgraded from an ASUS to a BIOStar mainboard). For boot order you first set the categories of disks (e.g. DVD-ROM, SATA drives, removable media) then you set the individual disks within the categories. This is obfuscated by using the first disk of the category when setting the category. The upshot was after examining all of this it sure seemed like the BIOS had been correctly configured all along (which turned out to be the case).

Next I figure I would go to the boot menu and select the SSD disk explicitly. OK, reboot and watch for the key to enter the boot menu. Oops, there doesn’t seem to be one. I finally figured out that the BIOS set-up contains the boot menu within it. One more mystery solved. Unfortunately selecting the SSD drive in the boot menu did not help.

OK, I’ll boot into my old OS and starting googling the problem. I log in and am immediately treated with an error message concerning updating the .ICEauthority file and then dropped back to the login screen. I use Ctrl-Alt-F1 to get to the terminal and log in that way. Fortunately that works. I fix the permissions on the .ICEauthority file (which looked fine to begin with) and no luck. I delete the .ICEauthority file and no luck. Finally I think to check the permissions on the /home/<user> directory. That was the problem: I had created myself first on this installation whereas in the old OS I had created a different user first. The 12.10 changed the owner of the home directory which to the 12.04 is a different user (that is, the UIDs were different for the two users and the file system only tracks the UID). I fixed the ownership and that did the trick.

Onto the boot issue. The consensus on google appears to be to try the Boot Repair utility (https://help.ubuntu.com/community/Boot-Repair). So I booted the Ubuntu Live USB, install Boot Repair, fix the settings and run it. I got an error message to the effect of: The disk is GPT and the BIOS is non-EFI, so create a Boot BIOS partition on the disk (<1MB, unformatted, with the bios_grub flag).

A little googling and I find that wikipedia actually has the information I need (http://en.wikipedia.org/wiki/BIOS_Boot_partition). I run GParted from the Live USB, resize the existing partition on the SSD (take space from the end, since it doesn’t matter where the BIOS boot partition is) and add an unformatted partition at the end. GParted wouldn’t let me add the bios_grub flag at creation time, I had to save the partition changes first.

At this point I figure I would run through the installation again, so I can fix my user issue and get grub installed correctly in one swoop. This time everything goes well and grub is installed.

Doing research afterwards for this write up, it looks like there were a couple of other potential solutions. I could have looked in the BIOS to see if it supports EFI and enable it. I also could have used GParted to use a different partition table than GPT. (GPT is apparently the default used by the Ubuntu installer, it never gave me the option for anything else.)

I ended up filing a bug report on this, we will see what happens: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1080726

Next up, for part 2, we get into some of the details for configuring the system for the SSD.

Resources:

• https://wiki.archlinux.org/index.php/Solid_State_Drives
• http://forums.fedoraforum.org/showthread.php?t=256068
• https://help.ubuntu.com/community/Boot-Repair
• http://en.wikipedia.org/wiki/BIOS_Boot_partition
• https://help.ubuntu.com/community/SwapFaq
• http://www.kernel.org/doc/Documentation/sysctl/vm.txt