Except for being greeted by the “Partial Upgrade” dialog in Update Manager the upgrade went as smoothly as can be expected for an in-place upgrade. I had Pidgin talking to Microsoft Office Communications Server within a few minutes of completing the upgrade. Mission accomplished. Then I needed to connect to Microsoft PPTP VPN at a clients’ site and I started to experience Ubuntu upgrade woes. The VPN connection was failing with the following error:

I spent quite a bit of time trying to fix that problem with no success. I couldn’t find any helpful errors in the system logs. The PPTP client was logging the following when I tried to connect:

pppd[18079]: Plugin /usr/lib/pppd/2.4.5//nm-pptp-pppd-plugin.so loaded.
pppd[18079]: pppd 2.4.5 started by root, uid 0
pppd[18079]: Using interface ppp0
pppd[18079]: Connect: ppp0 < --> /dev/pts/2
pppd[18079]: CHAP authentication succeeded
pppd[18079]: MPPE 40-bit stateless compression enabled
pppd[18079]: local  IP address 172.30.8.180
pppd[18079]: remote IP address 172.30.8.61
pppd[18079]: primary   DNS address 172.30.3.22
pppd[18079]: secondary DNS address 172.30.3.23
pppd[18079]: Terminating on signal 15
pppd[18079]: Connect time 0.7 minutes.
pppd[18079]: Sent 0 bytes, received 0 bytes.
pppd[18079]: Child process /usr/sbin/pptp vpn.********.com --nolaunchpppd --logstring nm-pptp-service-18077 (pid 18081) terminated with signal 15
pppd[18079]: Connection terminated.
pppd[18079]: Exit.

Not much info there. The NetworkManager log offered a little bit more info:

NetworkManager: <info>  Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 15184
NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections
NetworkManager: <info>  VPN plugin state changed: 1
NetworkManager: <info>  VPN plugin state changed: 3
NetworkManager: <info>  VPN connection 'Corporate VPN' (Connect) reply received.
NetworkManager:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
NetworkManager:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
NetworkManager: <info>  VPN connection 'Corporate VPN' (IP Config Get) timeout exceeded.
NetworkManager: <info>  Policy set 'Auto eth0' (eth0) as default for routing and DNS.
NetworkManager:    SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
NetworkManager: <debug> [1283289056.002038] ensure_killed(): waiting for vpn service pid 15184 to exit
NetworkManager: <debug> [1283289056.002152] ensure_killed(): vpn service pid 15184 cleaned up

The VPN connection was timing out. A Google search for that timeout message turned up lots of problems, but few solutions and none that worked for me.

While I searched for a working solution to my problem I launched Rhythmbox to play some “thinking music”. Rhythmbox loaded and then died. I started it again and it died again. More upgrade woes. I looked in the system log and found this message:

rhythmbox[29735]: segfault at 0 ip  013e97e2 sp b43fead8 error 6 in libnss_wins.so.2[13a8000+253000]

Rhythmbox was getting a SIGSEGV and dying shortly after launching every time. A Google search for that message turned up lots of other users experiencing the same problem. A few commenters reported that the issue was related to winbind. Several suggested the problem was the order of the hosts in /etc/nsswitch.conf and that moving the wins entry to the end of the hosts line would fix the problem. I edited /etc/nsswitch.conf and changed this line:

hosts:          files wins mdns4_minimal [NOTFOUND=return] dns mdns4

To this:

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 wins

Then I launched Rhythmbox and it did not segfault. Problem solved.¹

Now that I had music again I returned to working on the VPN problem. I tried connecting the VPN again and … it worked! Sonofa! The change I made to /etc/nsswitch.conf to fix Rhythmbox also fixed my Microsoft VPN problems too. Another win for serendipity!

¹Moving wins after dns on the hosts line in /etc/nsswitch.conf effectively disables winbind and this may cause problems with Samba. It didn’t cause any problems for me, but your mileage may vary.

To save you time I’ll give you the solution first then describe how I found it: Turn off Unix extensions in your Samba server by adding the following line to smb.conf in the global settings block and then restart Samba:

unix extensions = no
 

You might also need to unmount and re-mount your Samba volumes from OS X after you make this change.
 

After installing the OS X Snow Leopard 10.6.3 update I found that I could no longer write to Samba (SMB) volumes shared from my Linux server (running Ubuntu 9.10 Karmic Koala) that I had mounted on OS X. Whenever I tried to copy a file from OS X to the mounted Samba drive I got the error message:

The operation can’t be completed because you don’t have permission to access some of the items.
 

Apparently a lot of other people are having the problem as well:

• 10.6.3 Update Breaking SMB Mounted Volume Write Access for Many
• Topic : After update to 10.6.3 copy to a Samba share fails
• Topic : No rights to write on SMB mounted volume after updating on 10.6.3

I couldn’t find the solution anywhere on Google, and I spent hours today searching. I finally found the solution serendipitously while trying to fix another Samba issue. While scouring the system and Samba logs on my Linux server to try to find a clue to the first problem I found a bunch of warnings like the following repeated over and over in the Samba log:

[2010/04/05 00:08:37, 0] param/loadparm.c:9783(widelinks_warning)
Share 'documents' has wide links and unix extensions enabled. These parameters are incompatible. Wide links will be disabled for this share.
 

This warning started logging on March 24th, the same day that Ubuntu announced and patched a vulnerability related to the Samba wide links option: Ubuntu Security Notice USN-918-1. According to Using Samba by Robert Eckstein, David Collier-Brown and Peter Kelly you should not turn off the wide links option for performance reasons. (See Appendix B: Samba Performance Tuning.) Since I use Samba for just about everything I decided that performance was more important than Unix extensions so I added the following to my smb.conf in the global settings block and restarted Samba:

unix extensions = no
 

To my amazement and delight, this had the welcome side effect of solving the Samba write access issue I was having with OS X. To verify that this is really what solved the problem I re-enabled Unix extensions and restarted Samba and the write access problem returned. Then I turned Unix extensions off again and restarted Samba and I could write to all of the Samba mounts again from OS X. So if you are having problems writing to Samba mounts from OS X ask your system administrator to turn off Unix extensions in the server’s Samba configuration.
 

I’ve had emails and comments that point out that there are advantages to having Unix extensions on. That’s true and this should be considered a workaround rather than a fix. When (if?) Apple fixes the underlying problem you should turn Unix extensions back on in your Samba server.

I put a band-aid over this problem by adding /dev/pty to /etc/fstab. After revisiting this bug report I found that the source of the problem was that I was missing a symlink in /etc/rcS.d. If you are having the same problem first check that
/etc/init.d/mountdevsubfs.sh exists and then run the following commands:

cd /etc/rcS.d/

sudo ln -s ../init.d/mountdevsubfs.sh S11mountdevsubfs.sh

However, there is no explanation for why this symlink was missing in the first place.

No RAID

This turned out to be an extremely easy problem to fix. While fixing the symlink problem above I noticed that init scripts weren't ordered correctly. The init scripts for disk mounting were happening too early, before the mdadm module and services had fully loaded. That's why my RAID volume wasn't mounting on startup but I could mount it manually after logging in. I corrected the order of the init scripts and now the RAID volume auto-mounts when booting.

No Terminal

When I tried to launch GNOME Terminal from the menu I got this message:

There was an error creating the child process for this terminal

Not good. The first thing I tried was to start Update Manager and apply any patches. Update Manager showed me a list of patches but when I tried to install the updates it failed with the message:

Error failed to fork pty

At this point I wasn't getting warm, fuzzy feelings. Googling for the error messages turned up several Ubuntu bug reports for both problems. Many commenters reported that adding devpts to the fstab resolved the problem for them. So I tried their suggestion and it solved the problem for me as well. To apply this fix you need to add the following line to /etc/fstab:

devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0

To edit /etc/fstab press ALT+F2 to bring up the Run Application dialog. Then type in either”

gksudo gedit /etc/fstab

or:

gksudo gedit /etc/fstab

After adding the entry for devpts you need to mount it. You can either reboot or you press CTRL+ALT+F1 to temporarily switch to console mode. Once in console mode, login as root and run:

mount -a

exit

After exiting console mode you should now be able to successfully launch GNOME Terminal from the menu. It worked for me anyway.

NOTE: After rebooting, GNOME Terminal would not work again. After running mount -a from console mode it started working. So the problem is only partially solved if I have to manually mount the device after each boot.

No RAID

After the upgrade my RAID volume would not mount. When I tried to mount it I got this error message:

mount: special device /dev/md0 does not exist

I ran sudo mdadm --detail --scan and it showed the RAID array, but it didn't match the entries in either /etc/mdadm/mdadm.conf or /etc/fstab. It turned out that the RAID device had changed from /dev/md0 to /dev/md/d0 in the upgrade. Fixing the problem required two steps:

• Replace the ARRAY entry in /etc/mdadm/mdadm.conf with the output from sudo mdadm --detail --scan.

  NOTE: If the output contains the phrase metadata=00.90, then delete that phrase. mdadm doesn't like metadata format 00.90 and gave me an error message:

  mdadm: metadata format 00.90 unknown, ignored.

• Change the entry in /etc/fstab to the new device, i.e. from /dev/md0 to /dev/md/d0.

NOTE: The RAID volume does not auto-mount after rebooting. So this problem is also only partially solved.

No Sound

When anything tries to play sound I just get a crackling sound from the speakers. I'm still working on this problem…

Update: Sound problem fixed.

Final Update: All problems fixed.

After adding that range to the port forwarding table in the NAT firewall it works great. You can increase or decrease the range of the passive ports and you can move it around in the port numbering space to suit your needs.

Connection to a Microsoft VPN from Linux is normally a no-brainer but Ubuntu 8.10 Intrepid Ibix has some “out of the box” issues with connecting to a Microsoft VPN. Before fixing those issues we need to go through the motions and cover all the basics. First, you will need to install NetworkManager for Gnome and the PPTP plugin.

    sudo apt-get install network-manager-gnome network-manager-pptp

    sudo NetworkManager restart

NetworkManager Configuration

You can launch NetworkManager from either the Gnome menu under System | Preferences | Network Configuration or by clicking on the network icon on the Gnome panel and selecting VPN Connections | Configure VPN. Select the VPN tab and click the Add button. When asked to choose a VPN connection type select PPTP and click the Create button. PPTP will be the default unless you have other NetworkManager plugins installed.

Now you should have a dialog to enter the VPN information. There are only a couple of pieces of information that you need to enter on this form.

• Connection name: Name you VPN connection or keep the default name. Your choice.
• Connect automatically: Leave unchecked for now. You can change this later if you want.
• System setting: Leave unchecked.
• Gateway: Enter the host name or IP address of the VPN gateway.
• User name: Enter the NT domain, a backslash and the user name, e.g. EXAMPLE\bill. This is the first of the 8.10 issues – you must enter the NT domain with the user name here or it won't work.
• Password: Leave this blank. This is another 8.10 issue – either accessing or storing the password from NetworkManager is broken and if you enter the password here it won't work. Don't worry, there is a workaround.
• Show password: Don't check it, check it, it matters not.
• NT Domain: Leave this blank. And another 8.10 issue – the NT domain should be entered with the user name instead of here and if you do put the NT domain here it won't work.

The form should look something like this when you are done:

Click the Advanced button and when the dialog appears check Use Point-to-Point encryption (MPPE). Don't change any of the other setting on this form.

Click the OK button on the advanced settings form and then click the OK button on the VPN information form to save the settings for your new VPN. You can close the NetworkManager window now.

Fixing the NetworkManager Configuration

If you try to connect to the VPN now it will fail. By default it is trying to negotiate EAP authentication. There is no was to disable EAP from NetworkManager so you will need to disable it with gconf-editor. Launch gconf-editor from the command line.

    gconf-editor

When the editor starts browse to System | Networking | Connections. Under Connections you should see one or more numbered connection folders. You will need to find the one that has your VPN configuration in it – open each one and look for another folder named vpn. Click on the vpn folder to see the settings to verify that it is the one you need to change. On my system this was connection number 3. Right-click on the configuration list and select New key.

Name the new key refuse-eap, set its type to String and its value to yes. Then click the OK button.

Connecting to the VPN

You are finally ready to connect to the VPN. Clink the network icon on the panel and select VPN Connections | <connection name>. Enter your password in the authentication dialog. If you want your password stored in the keyring you can check that option here – that is the workaround for not being able to enter the password in NetworkManager. Click the OK button and if all goes well you will connect to your VPN.

The Bad News

Now that you've got your VPN working there's some really bad news you need to know about. Anytime you launch NetworkManager it is probably going to hork the VPN settings and your VPN will stop working once again. So don't start NetworkManager. But if you do the two things you will most likely need to fix are:

1. Edit the VPN and delete the password from the configuration form. You can re-enter it and save it again the next time you need to connect.
2. Check the refuse-eap setting on your VPN and re-add it with gconf-editor if it is missing.

Good luck!

December 3, 2008 Update:

In the comments Craig points out that the NT Domain issue has been fixed. I fired up Update Manager and installed all the latest updates which included an update to NetworkManager. After installing I verified that with the latest version of NetworkManager the NT Domain can be configured normally again. There was also an update to the Gnome Keyring which spurred me to try configuring the VPN password in NetworkManager too and that works now also. (However I do not know if the password storing problem was in NetworkManager or Gnome Keyring.) With these updates you can set up your VPN configuration in NetworkManager as follows:

These latest updates resolve half of the issues I described in the original post. You will still need to enable MPPE and add the refuse-eap key to successfully connect to a Microsoft VPN.