HOWTO: Upgrade from Lucid to Precise

UPDATED 12/06/2012. I have had reason to attempt this on two more systems and both times  it was successful.

The Ubuntu distribution continues its rapid decline with the Precise release.

The Internet is teeming with examples of people who have discovered that upgrading to Precise is difficult at best, and near impossible at worst.

It doesn't appear that upgrading from the last LTS, 10.04 Lucid is possible at all.

Well, not easily anyway.

Attempting to upgrade a server from Lucid to Precise will most likely result in an error;

E: Could not perform immediate configuration on 'python-minimal'.Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)

Searching the Internet might lead you to a suggested fix such as this one;

sudo apt-get install -o APT::Immediate-Configure=false -f python-minimal

Apparently, sometimes that doesn't work either, forum post suggests adding apt to that command;

sudo apt-get install -o APT::Immediate-Configure=false -f python-minimal apt

Having got that far, I received another error;

E: Couldn't configure pre-depend multiarch-support for libnih-dbus1, probably a dependency cycle

Joy.

No help was forthcoming from the Internet on that one.

So, I tried a desperate move.

I decided to remove the offending file (libnih-dbus1) and re-install it.

Now, before I continue, I should make it absolutely clear that what follows is capital N Nasty.

The server I was working on was a scratch virtual machine that I would not care about if I accidentally toasted it.

It is entirely possible that doing this on your server may completely trash it!

You have been warned.

OK, with that out of the way, what I did was this;

apt-get remove libnih-dbus1

Apt went away and calculated a whole lot of dependencies that would be removed which resulted in it giving me a nasty warning;

You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'

Undaunted, I copy-pasted the list of files being removed into a text editor (just in case) and typed the "Yes, do as I say!" phrase as requested;

After a while apt was finished.

Note: If you are following this "procedure", do not reboot your system now!

OK, I was afraid my SSH session or network (or something) may have been broken causing me to lose my connection (yes, I was doing this remotely) but the server still seemed to be working, which was good.

So I installed everything back.

apt-get install ubuntu-minimal

This returned no errors.


Now, when we did the nasty remove of libnih-dbus1 and its dependents earlier, one of the things that was removed was the Linux kernel.

Without being to dramatic, it is fair to say that this is an extremely important package. Another important thing that was removed was openssh-server

Install them now;

apt-get install linux-image-server openssh-server


The final thing to do is to reboot and to make sure everything is truly OK

The server rebooted without problems and finally I have managed to upgrade from Lucid to Precise.

Yay, I suppose, but it really shouldn't be that hard.

Canonical should spend less time working on horrible user interfaces and more time getting the basics right.

A final note: Check your list of files that were removed to check whether anything else that may have been installed was removed. You should manually re-install anything you need.

HOWTO: Change your default user account to a system account

When you deploy a new Ubuntu installation, the first user it creates (uid=1000) will be given sudo privileges.

Sometimes it is desirable to have a specific "admin" user on your system that is separate from your normal user accounts which are located in the uid=1000+ range.

For example, if you are setting up an LDAP network.

Unfortunately, you can't set the uid manually during the initial installation process but you can change it afterwards.

Note:

If you make a mistake during this procedure it is possible to lock yourself out of the system completely. This is not such an issue if this is a freshly installed system but if it is already up and running in some sort of role, then you need to be extra careful. You have been warned!

I am working here with a fresh Lucid server install, and my uid=1000 user is called "sysadmin".

Login to a console session as root;

~$ sudo -i

Manually edit your passwd file;

~# vi /etc/passwd

At the end of the file will be the entry for the "sysadmin" account;

sysadmin:x:1000:1000:system admin,,,:/home/sysadmin:/bin/bash

Change the two "1000"'s to "999";

sysadmin:x:999:999:system admin,,,:/home/sysadmin:/bin/bash

Make the same change in the "group" file;

vi /etc/group

Change the "sysadmin" line to;

sysadmin:x:999:

Changing the uid of a user will break the permissions in their home directory;

~# ls -al /home/sysadmin
total 32
drwxr-xr-x 3 1000     1000     4096 2011-06-23 13:34 .
drwxr-xr-x 3 1000     1000     4096 2011-06-23 13:32 ..
-rw------- 1 1000     1000       48 2011-06-23 13:34 .bash_history
-rw-r--r-- 1 1000     1000      220 2011-06-23 13:32 .bash_logout
-rw-r--r-- 1 1000     1000     3103 2011-06-23 13:32 .bashrc
drwx------ 2 1000     1000     4096 2011-06-23 13:33 .cache
-rw-r--r-- 1 1000     1000      675 2011-06-23 13:32 .profile
-rw-r--r-- 1 1000     1000        0 2011-06-23 13:33 .sudo_as_admin_successful
-rw------- 1 1000     1000      663 2011-06-23 13:34 .viminfo

You can fix that by issuing the following commands;

~# chown sysadmin:sysadmin /home/sysadmin
~# chown sysadmin:sysadmin /home/sysadmin/.*

When we setup LDAP later we will want to mount /home to an NFS share. Unfortunately, when we do this we will overwrite our sysadmin's home folder! Let's move it to the root ("/") directory.

~# mv /home/sysadmin /

We will need to change the path in the passwd file;

~# vi /etc/passwd

Change it from;

sysadmin:x:999:999:sysadmin,,,:/home/sysadmin:/bin/bash

to this;

sysadmin:x:999:999:sysadmin,,,:/sysadmin:/bin/bash

Check that all is well;

~# ls -al /sysadmin
total 32
drwxr-xr-x 3  sysadmin sysadmin 4096 2011-06-23 13:34 .
drwxr-xr-x 23 root     root     4096 2011-06-24 11:29 ..
-rw------- 1  sysadmin sysadmin   48 2011-06-23 13:34 .bash_history
-rw-r--r-- 1  sysadmin sysadmin  220 2011-06-23 13:32 .bash_logout
-rw-r--r-- 1  sysadmin sysadmin 3103 2011-06-23 13:32 .bashrc
drwx------ 2  sysadmin sysadmin 4096 2011-06-23 13:33 .cache
-rw-r--r-- 1  sysadmin sysadmin  675 2011-06-23 13:32 .profile
-rw-r--r-- 1  sysadmin sysadmin    0 2011-06-23 13:33 .sudo_as_admin_successful
-rw------- 1  sysadmin sysadmin  663 2011-06-23 13:34 .viminfo

On another console, confirm that you can login as the sysadmin user.

You should get a proper bash prompt;

sysadmin@galileo:~$

Note:

If your system has a GUI login, be aware that the logon screen will not display usernames for users with a UID of less than 1000. To login using the "sysadmin" account in such a case, you would need to type the name in to the username field manually.

Managing Deluge Daemon

I use Deluge bit torrent client on a couple of headless machines. There's not much to it, you can learn how to set it up here

However up until now I've been manually bringing it up and down at the command line, it's not hard but I thought I'd streamline it a bit by making a script.

Download or copy+paste this script into a file called "torrents" and make it executable;

#!/bin/bash

FLAG="/tmp/torrents_on"
UPDATE_FIREWALL="/store/scripts/firewall"

# Checking for dependancies
if [ ! ${DELUGED=`which deluged`} ] ; then echo "ERROR : Can't find 'deluged' on your system, aborting" ; exit 1; fi
if [ ! ${DELUGE_WEB=`which deluge-web`} ] ; then echo "ERROR : Can't find 'deluge-web' on your system, web interface will be disabled" ; exit 1; fi

DELUGED_PID=`ps ax | grep "${DELUGED}" | grep -v grep | awk '{print $1}'`
if [ "${DELUGED_PID}" = "" ] ; then DELUGED_PID=0 ; fi

DELUGE_WEB_PID=`ps ax | grep "${DELUGE_WEB}" | grep -v grep | awk '{print $1}'`
if [ "${DELUGE_WEB_PID}" = "" ] ; then DELUGE_WEB_PID=0 ; fi

case "$1" in
    start)
 if [ ! $DELUGED_PID -gt "0" ] ; then 
     deluged
     nohup deluge-web > /dev/null 2>&1 &
     touch $FLAG
     $UPDATE_FIREWALL
     exit 0
 else
     echo "Deluged is already running (PID $DELUGED_PID)"
     exit 1
 fi
    ;;

    stop)
 if [ ! $DELUGED_PID = "0" ] ; then 
     kill $DELUGED_PID
     kill $DELUGE_WEB_PID
     rm $FLAG 
     $UPDATE_FIREWALL
     exit 0
 else
     echo "Deluged is not running"
     exit 1
 fi
    ;;

    status)
 if [ $DELUGED_PID -gt "0" ] ; then 
     ps ax | grep deluge | grep -v grep
     exit 0
 else
     echo "Deluged is not running"
        exit 0
 fi
    ;;

    *)
        echo "Usage: torrents {start|stop|status}"
        exit 1
    ;;
esac

The script will open/close ports on your firewall as required assuming you modify the UPDATE_FIREWALL variable with the correct location of your firewall script and modify that script to include something like this;

# Flush tables before re-applying ruleset
sudo /sbin/iptables --flush

# Bittorrent traffic
if [ -f /tmp/torrents_on ] ; then
    sudo /sbin/iptables -A INPUT -p tcp --dport 58261 -j ACCEPT 
    sudo /sbin/iptables -A INPUT -p udp --dport 58261 -j ACCEPT
fi

# 

# Drop all other traffic from WAN
sudo /sbin/iptables -A INPUT -i $WAN -j DROP
sudo /sbin/iptables -A FORWARD -i $WAN -j DROP

The above firewall script is for illustraion purposes and shouldn't be used as is. Make sure you modify use a script that suits your own network.

Once installed, you can now use the script to control deluged and the deluge web interface from the command line using this syntax;

torrents {start|stop|status}

Enjoy!

HOWTO: The Five Minute VPN Guide

UPDATE: 05-06-2012, latest version: VPN v1.03

I posted some time ago a guide for setting up a PPP over SSH vpn but it was a bit clunky and I was never fully happy with it.

So, I have spent some time adding all of the hard work to a fully interactive script that has the following features;

* Automatically configure your client details in a "vpn.conf" file.

* Bi-directional routing between the server and all remote nodes is automatically configured.

* Interactive functions to stop and start the VPN

* Function to check the VPN status, attempts restart if down

* Send email to a specified administrator when the state of the VPN changes.

* Automatic setup of keys for passwordless connections.

* Zero scripting skills required

Audience:

Network admins who want to connect two or more offices using an encrypted, secure VPN over the public Internet. Clients at remote sites will access the Internet directly through their local gateway while all internal traffic is automatically routed via encrypted VPN links back to the central site.

Pre-requisites:

Two debian or ubuntu servers configured as routers, designated as SERVER and CLIENT. Both must be connected to the internet and the SERVER should have a FQDN of some sort (see www.dyndns.com if you don't have your own domain). Assuming you are running a firewall on the server you must poke a hole in it to allow SSH connections from the internet.

Authors Note:

This script started out as a simple clean up of the old one but of course that quickly blew out to a full on rewrite until I ended up with an all singing, all dancing mega-vpn management utility that I reckon is the easiest way to setup a VPN ever. Not one line of the original script remains intact!

Anyway, enough of the chest beating, let's get on with the show!

Step 1: Setting up the Server

Clients connecting to the server will do so using a local account on the server that is specifically used for this purpose.

Create a user called "vpn"

sudo adduser --system --group vpn

The --system parameter has set the vpn users shell to be /bin/false. However, because the vpn user needs to be able to log in via ssh, we must change this to /bin/bash in the /etc/passwd file.

Edit the passwd file;

sudo vi /etc/passwd

Modify the line for the vpn user so that it ends with /bin/bash;

vpn:x:110:110::/home/vpn:/bin/bash

We also need to set a password for the "vpn" account;

sudo passwd vpn

NOTE:

The vpn account password will only be used while doing the initial configuration of your VPN clients. You should choose a reasonably complex (secure) password and not be concerned about making it easy to type or remember.

The vpn user needs to be able to bring the ppp connection up and down as well as modify the system routing table. We will configure sudo to allow access to those commands.

Edit your sudoers file;

sudo visudo

Append these lines to the end of the file;

vpn ALL=NOPASSWD: /usr/sbin/pppd
vpn ALL=NOPASSWD: /sbin/route

Finally, we need to log in as the vpn and set up a few bits in its home folder.

Change to the vpn user;

sudo su vpn

Create an ssh directory;

mkdir .ssh

We need to seed an "active_networks" file with the subnet(s) that the VPN clients should be able to route to (usually the local LAN subnet that your VPN server is on but if you have a more elaborate network there may be multiple subnets. Simply add all the ones that you need remote hosts to route to). The "active_networks" file should be located in the vpn user's home folder (and owned by the vpn user)

Create an active_networks file;

vi ~/active_networks

Add a line for the servers local subnet followed by a hash and the server name.

Example:

10.1.1.0/24 # vpn-server

If you have more than one subnet then you can add them too (on separate lines)

Note:

The active_routes file holds a record of all the remote subnets (VPN network nodes) that the server is connected to. As each client gateway connects to the server it adds it's own LAN subnet to the file. If new routes are added later you can do a "vpn check" on the client gateway which will automatically update the local routing table with any new routes for any other nodes that may have been recently added to your network.

And that's all there is for the server part of this howto!

Yes, seriously.

Step 2: Configuring a Client

Configuring the client is even easier than the server, we just need to download and run my new VPN script.

On the client host, download my vpn client script

Put the vpn script file somewhere in your system path or make a link to wherever you decide to put it.

E.g. sudo ln -s /store/scripts/vpn /usr/sbin/vpn

Install dependencies;

sudo apt-get install ipcalc ppp

And finally, execute the script with the "setup" directive;

sudo ./vpn setup

This will create a default config for your VPN. If this will be the first or only client node to be connected to your VPN server then the only required value is the SERVER_HOSTNAME for the VPN server. This should be a FQDN that is pingable from the Internet. For 99% of scenarios the rest of the default settings will work perfectly fine.

Once you have finished the setup, you can start the vpn;

sudo ./vpn start
Starting vpn to vpn.tuxnetworks.net on port 22 - Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
Deflate (15) compression enabled
local  IP address 192.168.2.2
remote IP address 192.168.2.1
Setting static routes
Added route to 10.1.1.0/24
Added route to 10.48.17.0/24

Check the status of your VPN connection;

sudo ./vpn status
---------------------------------------------------------
Local network : 10.1.3.1/255.255.255.0 [eth0]
Connected to  : vpn.tuxnetworks.net
Remote IP     : 192.168.2.1
Local IP      : 192.168.2.2
PID           : 25493

To have your client check whether the VPN is up (and automatically restart it if it's not) add an entry to your system crontab;

sudo vi /etc/crontab

Add a line like so;

*  *    * * *   root    vpn check >> /dev/null 2>&1

This will run every minute, check the vpn status as well as update any new routes to new nodes that have been added since the last time it was run.

Note:

Of course the vpn script file will need to be in your system path for this cronjob to execute. (See above)

If you also configure an administrator email address (and your system is able to send emails of course) then it will email the administrator every time the VPN link goes down, and again when it comes back up.

I've tried to make the script as simple as possible to use and I hope I have covered all the possible failure scenarios gracefully.

Give it a go and let me know in the comments or send me an email to the address contained in the script header and tell me what you think.

Any and all feedback is welcome.

Cheers!

Getting Up To Speed With IPv6: Basic IPv6 Setup

This is the third in a series of articles that I hope will get you on the road to IPv6 in a relatively painless fashion.

If you arrived here from a search query, you may be interested in reading the Introduction and Setting The Stage articles first.

In order to use IPv6 our router requires a globally routable IP address. This means we cannot use one of the ubiquitous "home network gateways" in it's normal mode of operation as a NAT router as they do not offer native support for IPv6 and we cannot do IPv6 over NAT.

Fortunately, most of these devices can be configured in "bridge" mode which will allow a Debian/Ubuntu server to take over the role of our main Internet router thereby paving the way to IPv6 goodness.

Step 1: Configure A Server As An IPv4 Internet Gateway

Follow the IPv4 router guide found here to prepare your router for IPv6. Come back here when you are finished.

OK, once you have your IPv4 router setup and running we can start adding IPv6 support.

Step 2: Basic IPv6 Functionality

Creating an account with a Tunnel Broker:
The first thing you need to do is visit Hurricane Electric's Tunnel Broker page and sign up for an IPv6 tunnel account.

Once you have created your account we need to configure the tunnel on our router.

Creating an IPv6 tunnel:
Login to your tunnel account and click on "Create Regular Tunnel"

Enter the public IP address of your server in the text field called "IPv4 Endpoint (Your side): (ie: The IP address of your ppp0 adapter)

Choose a tunnel server that is closest to where you are (you can use traceroute to find one with the lowest number of hops or simply go by geographical location). Going with the default server offered is probably the best bet though.

Click on "Create Tunnel"

You should now see something like this;



And that's it, your tunnel has been created!

Configuring Your Tunnel

Now we need to configure our router to use our new tunnel.

As root, edit your interfaces file;

sudo vi /etc/network/interfaces

Add the following lines replacing the parts in [italics] with the address details as provided on your Tunnel Details Page;

auto ip6tunnel
iface ip6tunnel inet6 v4tunnel
address [Client IPv6 Address]
netmask 64
ttl 64
gateway [Server IPv6 Address]
endpoint [Server IPv4 Address]
local [Client IPv4 Address]

Note: When entering addresses, don't include the /n at the end as this is the netmask and is not part of the address. It is worth noting that, unlike IPv4, IPv6 supports only CIDR notation (bitwise) netmasks, decimal netmasks are not supported.

Once that is done, save the file and restart your router, I'll wait here until that's finished.

OK, now let's have a look around and do some tests.

In a shell console, enter;

ifconfig ip6tunnel

ip6tunnel Link encap:IPv6-in-IPv4
inet6 addr: fe80::7b02:25c5/128 Scope:Link
inet6 addr: 2001:470:c:2345::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1472 Metric:1
RX packets:170953 errors:0 dropped:0 overruns:0 frame:0
TX packets:168578 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:140703681 (140.7 MB) TX bytes:20945209 (20.9 MB)

Hopefully you will see similar output to above.

Let's try and ping the Hurricane Electric IPv6 DNS servers. The address for this server can be found on the tunnel details page.

IPv6 uses the ping6 command but it works exactly like "normal" ping;
ping6 -c 4 2001:470:20::2
PING 2001:470:20::2(2001:470:20::2) 56 data bytes
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=64 time=437 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=64 time=474 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=64 time=441 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=64 time=510 ms

--- 2001:470:20::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 437.905/465.959/510.010/29.213 ms

Awesome. Right now you are probably thinking "I can't believe it was that easy!". Well, hold on there cowboy, it's not over yet. Right now our gateway is the only host on our network that can use IPv6, and it can't even resolve names to IPv6 yet.

We can fix name resolution very easily for now by simply adding an entry for HE's IPv6 DNS server to our resolv.conf file;

sudo vi /etc/resolv.conf

Add an extra nameserver line like so;

nameserver 2001:470:d:1018::1

Let's try pinging a name this time;

ping -c 4 ipv6.tuxnetworks.com
ping: unknown host ipv6.tuxnetworks.com

Oops, don't forget we need to use ping6 instead! Let's try it again;

ping6 -c 4 ipv6.tuxnetworks.com
PING ipv6.tuxnetworks.com(2001:470:c:1004::2) 56 data bytes
64 bytes from 2001:470:c:1004::2: icmp_seq=1 ttl=63 time=227 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=2 ttl=63 time=332 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=3 ttl=63 time=230 ms
64 bytes from 2001:470:c:1004::2: icmp_seq=4 ttl=63 time=227 ms

--- ipv6.tuxnetworks.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms

That's a whole lot better but there are still some things to be done. We will cover those in the next article.

Continue on to Step 3: LAN access and autoconfiguration

P.S. Don't forget that June 8 is IPv6 Day!

HOWTO: Configure A Router

Now we get to turn our debian or ubuntu server into a router. Read on!

Prerequisites;
1) A server as per this guide.

2) A working PPPoE or PPPoA based Internet connection. Most consumer ADSL and Cable Internet is provided using one of these protocols, support for which is built into the consumer "router" I am assuming you are currently using.

3) The ISP provided username and password combo for your Internet connection. If you have a "router" that was provided by your ISP they sometimes print these on a label attached to the device, otherwise it will be written on the documentation you received when you signed up (and promptly lost I'm sure). You will have to call your ISP on the actual telephone to retrieve this information if you have lost it.

4) An Ethernet switch and sufficient cables to connect at least two devices. Your current Internet Gateway may currently have the Ethernet switch built in to it. Alternately, you may use a separate switch if you prefer.

5) If you are intending to use a discreet modem (cable or ADSL) and a separate switch then two LAN cards are required. Unless you are one of the incredibly lucky few who have access to FttH you will most likely have some form of ADSL or Cable service with speeds measured in single-figure MegaBits. This means that it is perfectly OK to reuse a discarded old 100baseT adapter (or indeed even a 10baseT if you still have one of those in the antiques cupboard) for your WAN interface. Even the slowest LAN card will be considerably faster than most current Internet connections. If you intend to go down the Router-in-bridged-mode road then a single Ethernet adapter will suffice.

OK, now that you have all the prerequisites in order, and a basic server up and running we can get on with bidness proper.

The first thing we need to do is install a few packages we will need before we disconnect ourselves from the Internet.

apt-get install pppoeconf ppp

Next we configure the LAN side of the network.

Note: I will assume that your LAN adapter is eth0 from this point onwards. If you are using two Ethernet adapters this would make your WAN interface eth1.

Because we are configuring a router, we must use a static IP address for our LAN adapter. If you followed my server guide then you have already done that, otherwise you should backtrack and configure a static IP address as per that guide.

Pro Tip: For testing purposes, I recommend that you configure some other PC on your LAN with a static IP in the 10.1.1.x subnet with a default gateway of 10.1.1.1. We will be using this PC from time to time for testing. This can be either a Linux or Windows PC.

Plug both the server and client hosts into your LAN and check that you can ping the server at 10.1.1.1 from the client.

OK. Once you can ping your server from the test PC we can continue.

The next step varies depending on whether you are using a single adapter and a router in "bridged mode" or a separate modem and 2 Ethernet adapters.

Separate modem and two adapters: You must configure eth1 as per the above instructions for eth0 using any old IP address you like. I suggest you use 192.168.254.254/24. The address will not be used for anything on your network but is required so that the pppoeconf utility in the next section can locate your modem. Make sure you plug your modem into this interface

Consumer router in "bridged" mode: You will need to configure the router in "bridged" mode[1] according to the instructions provided by the manufacturer of the device. On my DG834G it is a simple matter of browsing to http://192.168.0.254/setup.cgi?next_file=mode.htm (where 192.168.0.254 is the address of my gateway) and setting the drop-down box to "Modem Only". I found that info via a Google search here. You should do a Google search for something like my-gw-model-number +"bridged mode" or similar to find instructions on how to configure your particular router.

Once you have your router in bridge mode, we can use the pppoeconf utility to configure a PPP connection to our ISP;

sudo pppoeconf

Go through each screen choosing the default option until you get to the "ENTER USERNAME" screen. Enter the username for your ISP account here.

The next screen asks for your password, enter that too.

In the "USE PEER DNS" screen select "No"

Select the default option on all the remaining screens.

You should now have Internet connectivity on this host. You can check this with the ifconfig command;

ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:123.4.56.789 P-t-P:123.4.8.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:59687317 errors:0 dropped:0 overruns:0 frame:0
TX packets:50606162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2967668270 (2.9 GB) TX bytes:2950135549 (2.9 GB)


You should (hopefully) see a ppp0 adapter in the output similar to this. If you do, we should do a few more tests. First, lets check we can ping our DNS server. To find your DNS server type;

cat /etc/resolv.conf

There should be an entry "nameserver" with an IP address in the output.

Let's ping that IP address and see if it works;

ping -c 4 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=322 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=196 ms
64 bytes from 208.67.222.222: icmp_seq=3 ttl=55 time=281 ms
64 bytes from 208.67.222.222: icmp_seq=4 ttl=55 time=547 ms

--- 208.67.222.222 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 196.763/337.020/547.292/129.589 ms

(The IP above is for OpenDNS)

We can test that DNS is working by pinging by name;

ping -c 4 www.google.com
PING www.l.google.com (74.125.237.18) 56(84) bytes of data.
64 bytes from 74.125.237.18: icmp_seq=1 ttl=57 time=261 ms
64 bytes from 74.125.237.18: icmp_seq=2 ttl=57 time=285 ms
64 bytes from 74.125.237.18: icmp_seq=3 ttl=57 time=24.2 ms
64 bytes from 74.125.237.18: icmp_seq=4 ttl=57 time=122 ms

If you got this far then that is great, but please be aware that although our Internet connection is now up and working, we have not done enough to get our LAN clients up and on the 'net. For that we need to configure routing, NAT and a firewall.

We can configure routing by issuing editing the following file;

sudo vi /etc/sysctl.conf

Find the following line and change it from 0 to 1;

net.ipv4.ip_forward=1

To configure an extremely basic firewall, create a file in a suitable location such as /usr/sbin/ with the following contents;

sudo vi /usr/sbin/firewall
8< - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/bash

WAN=ppp0
LAN=eth0

sudo /sbin/iptables --flush

# Accept ALL packets inbound from our local networks
sudo /sbin/iptables -A INPUT -i $LAN -j ACCEPT
sudo /sbin/iptables -A INPUT -i lo -j ACCEPT

# Do NAT for LAN clients
sudo /sbin/iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

# Allow ping packets
sudo /sbin/iptables -A INPUT -p icmp -j ACCEPT

# Allow returning packets for established sessions
sudo /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all traffic out from this host and our LAN clients
sudo /sbin/iptables -A OUTPUT -j ACCEPT
sudo /sbin/iptables -A FORWARD -i $LAN -j ACCEPT

# Drop all other traffic inbound from the Internet
sudo /sbin/iptables -A INPUT -i $WAN -j DROP
sudo /sbin/iptables -A FORWARD -i $WAN -j DROP
8< - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Note: This is not a particularly secure firewall, it basically allows any host on your LAN to send anything out and only drops unwanted packets coming in via the WAN interface (ppp0).

Make the firewall script executable;

chmod +x /usr/sbin/firewall

To make the firewall start at boot simply edit your rc.local file.

vi /etc/rc.local

Add this line to the end (but before the "exit 0" line)

/usr/sbin/firewall

You should reboot your router/server now and redo the ping tests as shown above.

Now that the router has been rebooted and assuming the ping tests have worked OK, you should be able to use your LAN client with the static IP address and ping/browse to the Internet.

That's great, but we don't want to be configuring all our clients with static addresses, so we probably should configure our router as a DHCP server as well.

And while we are at it, why don't you take the next step and turn your router into a funky caching DNS server too.

Or even better, connect your sites together with encrypted VPN's using this super easy Five Minute VPN Guide

[1] AKA "modem" or "modem only" mode.

-

HOWTO: Caching Authoritative Nameserver

OK, so you have built yourself a Linux Router and now you want to add DNS support for extra goodness.

Here's what to do.

I'll be working on Debian 6.01 "squeeze" but any Debian based distro should be fine. I've also tested on Ubuntu 10.04 without problems. I am using 10.1.1.0/24 as my local network and tuxnetworks.net as my local domain. Where you see references in italics to these you should change them to suit your own network.

First we will log in as root

As root, install Bind v9 from the standard repositories;

apt-get install bind9

Now we need to tell Bind to listen for queries on our IPv4 LAN.

Open this file for editing;

vi /etc/bind/named.conf.options

add the following lines inside the "options { };" section ;

listen-on { any; };
allow-recursion { 127.0.0.1; 10.1.1.0/24; };

Note:

"Recursion" is a fancy term for "which clients can query our server". Basically, you want to enter the local loop interface (127.0.0.1) and the subnet of your LAN. You can add any other hosts or subnets as required. Also, if you are not intending to use IPv6 you can comment or remove the "listen-on-v6" line out if you like.

Now we will create a zone file for our local zone;

Note:

I prefer to keep the configuration details for zones in separate files so I am going to create a file in which I will define the details for the "tuxnetworks.net" zone. If you don't want to do this just add the following code section to named.conf.options

vi /etc/bind/named.conf.tuxnetworks-net

Adjust the following code to suit your own network and then add it to the zone file;

# This is the zone declaration for our local zone.
zone "tuxnetworks.net" {
        type master;
        file "/etc/bind/db.tuxnetworks.net";
};

# This is the zone declaration for reverse DNS
zone "1.1.10.in-addr.arpa" {
     type master;
     file "/etc/bind/db.1.1.10.in-addr.arpa";
};

Now that we have created our zone declaration file, we have to tell bind to load this file when it starts. We do this by adding an "include" line to named.conf

Edit named.conf;

vi /etc/bind/named.conf

Append this line to the end;

include "/etc/bind/named.conf.tuxnetworks-net";

Now we need to make a zone file for our domain. This is where we define the names and attributes of our zone.

Create a zone file;

vi /etc/bind/db.tuxnetworks.net

Modify these details and save them to your zone file;

$TTL    3600
tuxnetworks.net. IN SOA ns.tuxnetworks.net.   jupiter.tuxnetworks.net. (
        2011051701      ; Serial
        86400           ; Refresh
        7200            ; Retry
        3600000         ; Expire
        172800 )        ; Minimum TTL

; DNS Servers
tuxnetworks.net.        IN      NS              ns.tuxnetworks.net.

tuxnetworks.net.        IN      MX     10       mail.tuxnetworks.net.

@  IN A 10.1.1.1
ns              IN      A       10.1.1.1
www             IN      A       10.1.1.1
mail            IN      A       10.1.1.1
jupiter         IN      A       10.1.1.1

Note: Take note that several names in this file have a trailing period (fullstop). Make sure that your file matches the format of this one exactly, only changing the names and IP addresses, but where present keeping the periods intact.

We also need to make a reverse zone file. Create a new file;

vi /etc/bind/db.1.1.10.in-addr.arpa

Add this code (modified to suit your network of course);

;
; BIND reverse data file for local network
;
$TTL    604800
@       IN      SOA     jupiter. ns. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
1       IN      PTR     ns.

Finally, there is one thing more to do if we are going to be good netizens and that is to ensure that we play by the rules according to RFC 1918

After running your server for a while you might take a look at /var/log/syslog and notice lots of bind related errors saying something like "RFC 1918 response from Internet for . . . .".

If you do then this means that your server is not playing nice with the root servers and is forwarding on requests for private IP ranges. That is not something we want to do.

To fix it edit your named.conf file;

vi /etc/bind/named.conf

Add the following line to the end;

include "/etc/bind/zones.rfc1918";

This stops any requests for private IP address's (192.168 etc) from being passed on to the Internet root servers. One wonders why Bind isn't configured like this by default . . .

And that's it. Of course we need to restart bind before our changes take effect;

service bind9 restart

Also, before we can query our new DNS server, we need to configure the client to look to this server for name resolution.

To do that, edit your resolv.conf file;

vi /etc/resolv.conf

Remove any exiting lines and add these (modified to suit your own network of course);

nameserver 10.1.1.1
domain tuxnetworks.net

Optional:

If you don't wish to query against the Internet root servers, edit your named.conf.options file and configure a forwarder or two.

vi ./etc/bind/named.conf.options

Uncomment the "forwarders {" section and replace the 0.0.0.0 with the ip address of the upstream DNS server(s) you would like to use.

  forwarders {
   208.67.222.222;
   208.67.220.220;
  };

Now let's do some tests to see if it is all good with our new server;

Let's dig our domain;

dig tuxnetworks.net

; <<>> DiG 9.7.0-P1 <<>> tuxnetworks.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28277
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;tuxnetworks.net. IN A

;; ANSWER SECTION:
tuxnetworks.net. 3600 IN A 10.1.1.1

;; AUTHORITY SECTION:
tuxnetworks.net. 3600 IN NS ns.tuxnetworks.net.

;; ADDITIONAL SECTION:
ns.tuxnetworks.net. 3600 IN A 10.1.1.1

;; Query time: 1 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Tue May 17 12:09:08 2011
;; MSG SIZE rcvd: 82

We can see from this that we received an answer (ANSWER: 1) along with some other details about our domain. Also note the AUTHORITY: 1
which lets us know that this server is acting as the authority for the domain.

We can also do some ping tests.

Do a test ping to an internal name (we don't need to provide the domain name because we used the "domain" directive in resolv.conf which will automatically append our domain to any query that doesn't include a domain. Neat!;

ping -c 4 www
PING www.tuxnetworks.net (10.1.1.1) 56(84) bytes of data.
64 bytes from jupiter.tuxnetworks.com (10.1.1.1): icmp_seq=1 ttl=64 time=0.130 ms
64 bytes from jupiter.tuxnetworks.com (10.1.1.1): icmp_seq=2 ttl=64 time=0.089 ms
64 bytes from jupiter.tuxnetworks.com (10.1.1.1): icmp_seq=3 ttl=64 time=0.090 ms
64 bytes from jupiter.tuxnetworks.com (10.1.1.1): icmp_seq=4 ttl=64 time=0.091 ms

--- www.tuxnetworks.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.089/0.100/0.130/0.017 ms

Our Bind server will forward any requests that it isn't an authority for out to the Internets DNS root servers which means we no longer need to rely on our dodgy ISP's DNS servers where they are quite likely engaged in DNS Hijacking shenaningans.

Do a test ping to the outside world;

ping -c 4 www.google.com
PING www.l.google.com (74.125.237.84) 56(84) bytes of data.
64 bytes from 74.125.237.84: icmp_seq=1 ttl=57 time=57 ms
64 bytes from 74.125.237.84: icmp_seq=2 ttl=57 time=40.3 ms
64 bytes from 74.125.237.84: icmp_seq=3 ttl=57 time=59 ms
64 bytes from 74.125.237.84: icmp_seq=4 ttl=57 time=45 ms

--- www.l.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 90.384/137.973/159.187/28.004 ms

So, our DNS server is all up and running, it is acting as authority for tuxnetworks.net and passing any other requests out to the Internet. It is also caching any queries to reduce on net traffic!

OK, we are all done now, grab yourself a beverage and relax!

Now that you have built yourself a DNS server, why not build a second one and configure it as a SLAVE?

HOWTO: DHCP Server On Ubuntu

For a Debian flavoured version of this post see this article

Pre-requisites:

A working LAN where clients can ping each other from static IP address's. For more information on configuring a Debian or Ubuntu server with a static IP address see this article.

Login as root;

sudo -i

Setting up DHCP is a fairly simple affair. We start by installing dhcp-server from the repositories;

apt-get install dhcp3-server

We need to tell it which interface to listen for client requests on;

vi /etc/default/dhcp3-server

Add your (space separated) interface(s) like so;

INTERFACES=”eth0″

There is a lot of useful documentation in the default configuration file, however this tends to make things a bit cluttered. I prefer a minimalist config file so we will backup the default one for future reference;

mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.default

Now, we create a new config file;

vi /etc/dhcp3/dhcpd.conf

Add the following contents, modifying as applicable for your own network of course;

default-lease-time 600;
max-lease-time 7200;

subnet 10.1.1.0 netmask 255.255.255.0 { 
        range 10.1.1.10 10.1.1.200;
        option subnet-mask 255.255.255.0;
        option broadcast-address 10.1.1.255;
        option routers 10.1.1.1;
        option smtp-server 10.1.1.1;
        option domain-name "tuxnetworks.net";
        option domain-name-servers 10.1.1.1, 10.1.1.2;

        host earth {
                hardware ethernet 00:1f:d0:c0:3b:9d;
                fixed-address 10.1.1.10;
        }
}

Notes:
I have added a fixed address for the host "earth" identified by MAC address 00:1f:d0:c0:3b:9d. This is for illustrative purposes only and can be removed if it is not needed.

The above example assumes you have DNS servers running on the your network on hosts 10.1.1.1 and 10.1.1.2. If you want to use upstream DNS resolvers enter the addresses for your ISP DNS servers instead. Alternately you can use the servers provided by OpenDNS[1] or configure your own DNS server.

To apply the changes, restart the dhcp server daemon;

service dhcp3-server restart

Now you should refresh the IP address on a PC configured as a dhcp client and you should receive a shiny new DHCP lease.

Now that you have a DHCP server, why not improve it by adding DDNS (Dynamic DNS) updates so that your clients names are automagically added to your DNS Server?

[1] OpenDNS use error redirects (DNS Hijacking) as a way to generate income. If you are like me and don't like such shenanigans then I recommend that you configure your own DNS server.

Intellinet 150n USB WiFi key

I had some trouble getting my new "Intellinet 150n Wireless LAN Adapter" working in Ubuntu 10.04 (Lucid)

The problem is that one of the other Realtek drivers (rt2800usb) conflicts with the driver we need (rt2870sta)

To fix it you need to stop the rt2800usb driver from loading by blacklisting it.

sudo vi /etc/modprobe.d/blacklist.conf

Add this line;

blacklist rt2800usb

Reboot and you should be up and running.

HOWTO: Syncing your /home with a server

Do you have a storage server where you keep your files? Do you think it would be a neat idea to keep a copy of your user files (home directory) on that storage in case your laptop or desktop suffers some sort of a catastrophe? Would you like an approximation of Windows roaming profiles?

If you answered yes to any of the above then read on! (However you should read the disclaimer at the end of this post.)

PLATFORM :
* Ubuntu (Tested with 10.04.1 Lucid but should work with any version)

PREREQUISITES :
* You must have passwordless SSH configured between the client and server users on the two hosts.
* rsync and openssh-server are installed on both hosts.

b) On the server;

The server part is pretty simple. First we will login as the root user;

sudo -i

We need a place to store the copies of the home folders. Create a folder;

mkdir -p /store/homes

Go back to the client;

Now assuming that we have keyless access to our server from the client we just need a script to do the syncing.

Create a script in /etc/init.d

root@hack:~# vi /etc/init.d/homesync
#!/bin/sh
### BEGIN INIT INFO
# Provides: homesync
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: sync homes at startup and shutdown
# Description:
### END INIT INFO

MODE=$1
TARGET="root@zen:/store/homes/"
EXCLUDE="/root/excludes.rsync"

case $MODE in

start)
rsync -parv --inplace $TARGET /home/
;;

stop)
rsync -parv --inplace --exclude-from=$EXCLUDE --delete /home/ $TARGET
;;

esac


Note: Of course you need to change TARGET= to suit your own environment. Also, if your SSH server is listening on a non standard port you will need to modify the rsync command as per this post

Make the script executable;

chmod +x /etc/init.d/homesync

If you look carefully, you will notice that the script will refer to /root/excludes.rsync for any files or folders that it should avoid syncing. We should create that file;

touch /root/excludes.rsync

Now, there are no files on the server yet so we should do an initial sync.

WARNING: If this is not the first (ie primary) client that you are setting this up on then don't run the following command as is or else it will wipe out the "backup" that is already on the server. In such a case you need to replace the "stop" in the command with "start" in order to retrieve the primary files from the server instead.

Perform an initial sync;

/etc/init.d/homesync stop

Note: Depending on how much stuff you have in your user homes this may take some time. You should also ensure that you have enough space to fit everything!

OK, assuming everything is working, the final step is to make sure the homesync script executes when the system stops and start. We do that with the update-rc.d command;

sudo update-rc.d -f homesync defaults

That's it. You can test your setup by adding or altering a file in your home folder and then shutting down your system. If you check the server you should see your changes appear there after it shuts down. If you delete or alter the file again on the server the change should appear on the client after reboot.

If you want to exclude particular files or directories then you may list them in the exludes.rsync file we created earlier.

Here is a sample list;

Junk*
oops*
.pulse*
.cache*
tmp*
temp*
gvfs*
.gvfs*
.Trash*
Trash*
*~
Thumbs.db*
desktop.ini*
lost+found*


DISCLAIMER: Be very careful using this setup in a multiuser environment where there is more than one PC (in use) at any one time. If a user is logged in on more than one PC then it is possible that they could lose data. Be sure you understand the limitations of this system before proceeding down such a path. Also note that the script only executes at startup and shutdown so if the PC is rarely restarted then this system will be of little value. I recommend using it for a simple home network only. It is not flexible or robust enough for use in a corporate network. And one final note, this does not work if you connect to the server using a wifi connection due to the way Ubuntu connects and disconnects after the user logs in. Any script such as this one that runs at boot time will not be able to connect to the network in order to do the sync. In such scenarios you could consider using a cron job or syncing manually.

VMware remote console + Firefox 3.6 (updated)

Firefox 3.6 is the default browser on Ubuntu since Karmic but unfortunately it no longer works when attempting to launch a VMWare server remote console session from within the web gui. This is one of the reasons I decided to move away from VMware to Virtualbox headless, with mixed results.

My virtualbox experiment is over and I have decided to go back to VMware. It is a shame but vbox just has too many ways to get itself tangled up and lacks the "management polish" that you get with vmware server.

That being said, there is still the problem that new versions of Firefox refuse to work with the remote console plugin and that is a show stopper. It forces me to keep Jaunty on my laptop just so I can get a console session when needed.

The good news is that I have just discovered a workaround for this problem.

Apparently, there is an undocumented* feature in vmware player that enables it to connect to a remote host!

I have long been wondering why such a feature was not available and now I find out it actually is! Yay!

Anyway, assuming you have installed vmware player, if you type the following at a shell prompt;

vmplayer -h

you will be presented with a dialog that looks like this;



Enter your server details (including the port which is 8333 by default)



Click OK and you will see a list of the guest machines on that host, like so;



Click on a host and open to create a remote console session and you are done!

I can't tell you how excited I am to discover this trick. Now I have no more reasons to avoid changing my main browser to Chrome.

[UPDATE]

I having been playing about and you can streamline the process by adding the host and login details to the command line.

vmplayer -h jupiter -u brettg -p mypassword

* It is not mentioned when you type vmplayer --help at the console.

HOWTO: SAMBA + LDAP on 10.04 Lucid Part 1

Wow, it has taken me weeks to get this to the point that it seems to be working. The official documentation is horribly broken, but I have finally got what i think is a working solution. I will probably need to tweak this guide as time goes on (see the end of the post for revision history)

PLATFORM:
* Ubuntu Server 10.04 LTS (Lucid)

PREREQUISITES:
* A standard vanilla Ubuntu 10.04 server install.
* Set your admin user as a system user.
* Mount our user home directories to an NFS server

Network overview;
* domain name: tuxnetworks.com (change this to suit your own)
* ldap-server 10.1.1.5 (change this to suit your own)

Installing Samba

We will start by configuring samba.

Download this samba config file;

~$ wget http://www.tuxnetworks.com/configs/smb.conf

Note:

Edit this file to suit your own network. You need to change the "ldap suffix" & "ldap admin" values, but you will probably also want to change "workgroup" and "netbios name" as well.

Create a samba directory;

sudo mkdir /etc/samba/

Copy the new smb.conf file into place;

~$ sudo cp smb.conf /etc/samba/

Install Samba;

~$ sudo apt-get install samba samba-doc smbclient

Install the LDAP server

Next we want to install the OpenLDAP server daemon slapd and ldap-utils, a package containing LDAP management utilities;

~$ sudo apt-get install slapd ldap-utils libpam-smbpass smbldap-tools

Notes:

By default slapd is configured with minimal options needed to run the slapd daemon.

The configuration example in the following sections will match the domain name of the server. For example, if the machine's Fully Qualified Domain Name (FQDN) is ldap.tuxnetworks.com, the default suffix will be dc=tuxnetworks,dc=com.

OpenLDAP uses a separate directory which contains the cn=config Directory Information Tree (DIT). The cn=config DIT is used to dynamically configure the slapd daemon, allowing the modification of schema definitions, indexes, ACLs, etc without stopping the service.

The backend cn=config directory has only a minimal configuration and will need additional configuration options in order to populate the frontend directory. The frontend will be populated with a "classical" scheme that will be compatible with address book applications and with Unix Posix accounts. Posix accounts will allow authentication to various applications, such as web applications, email Mail Transfer Agent (MTA) applications, etc.

* For external applications to authenticate using LDAP they will each need to be specifically configured to do so. Refer to the individual application documentation for details.

Remember to change "dc=tuxnetworks,dc=com" in the following examples to match your LDAP configuration.

First, some additional schema files need to be loaded. In a terminal enter:

~$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
~$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
~$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif

Download this LDIF file

~$ wget http://www.tuxnetworks.com/configs/backend.ldif

Edit the file to change "dc=tuxnetworks,dc=com" and "mypassword" to suit your own domain details.

TIP:

A quick way to do this is to use sed;
sed -i s/dc=tuxnetworks,dc=com/dc=example,dc=net/g backend.ldif

Now add the LDIF to the LDAP directory:

~$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f ~/backend.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"

adding new entry "olcDatabase=hdb,cn=config"

Samba needs us to tell it the LDAP admin password which we can do with this command;

~$ sudo smbpasswd -W
Setting stored password for "cn=admin,dc=tuxnetworks,dc=net" in secrets.tdb
New SMB password:
Retype new SMB password:

Note:

Use the password you entered in the backends.ldif file earlier.

And finally, we restart samba again;

~$ sudo service smbd restart

You can test that samba works by using the samba-client (when it asks for roots password just press Enter);

~$ sudo smbclient -L localhost

You should see something like this;

~$ sudo smbclient -L localhost
Enter root's password: 
Anonymous login successful
Domain=[SAMBA] OS=[Unix] Server=[Samba 3.4.7]

 Sharename       Type      Comment
 ---------       ----      -------
 print$          Disk      Printer Drivers Share
 shared          Disk      
 archive         Disk      
 IPC$            IPC       IPC Service (Samba 3.4.7)
Anonymous login successful
Domain=[SAMBA] OS=[Unix] Server=[Samba 3.4.7]

 Server               Comment
 ---------            -------
 MYSAMBASERVER        Samba 3.4.7

 Workgroup            Master
 ---------            -------
 MYSAMBAWORKGROUP     MYSAMBASERVER

Note:

If you don't see the expected output, then you should stop right now and repeat the process. Having Samba incorrectly configured at this point will cause the rest of the procedure to fail.

OK, now that that we have the basic part done you should proceed to part 2.

HOWTO: SAMBA + LDAP on 10.04 Lucid Part 2

This is Part Two of my SAMBA + LDAP howto. You must successfully complete Part One before attempting this procedure.

OK, with Part one done we must now provide our samba users with profile and netlogon directories, let's create them now;

~$ sudo mkdir -v -m 777 /var/lib/samba/profiles
~$ sudo mkdir -v -p -m 777 /var/lib/samba/netlogon

Next we must add the samba schemas to the LDAP server. These schemas are part of the samba-doc package that we installed in Part One.

Copy the schemas to the appropriate location;

~$ sudo cp /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz /etc/ldap/schema/
~$ sudo gzip -d /etc/ldap/schema/samba.schema.gz

These schemas must be converted to the "ldif" format before we can use them.

Create a file called schema_convert.conf

~$ vi ~/schema_convert.conf

and paste in the following lines;

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/samba.schema

Next, use slapcat to convert the schemas;

~$ slapcat -f ~/schema_convert.conf -F ~ -n0 -s "cn={12}samba,cn=schema,cn=config" > ~/cn=samba.ldif

slapcat will generate a file "~/cn\=samba.ldif". Edit this file;

~$ vi ~/cn\=samba.ldif

and change the following attributes:

dn: cn={12}samba,cn=schema,cn=config
...
cn: {12}samba

to

dn: cn=samba,cn=schema,cn=config
...
cn: samba

Also, remove all these lines from the bottom of the file.

structuralObjectClass: olcSchemaConfig
entryUUID: 99e797a8-07cb-102f-8c5c-739a8467e607
creatorsName: cn=config
createTimestamp: 20100609043122Z
entryCSN: 20100609043122.188753Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20100609043122Z

Add the schema to the server;

~$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f ~/cn\=samba.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=samba,cn=schema,cn=config"


You should see the following line with no errors reported.

adding new entry "cn=samba,cn=schema,cn=config"

Let's check how things are going with the following query (use an empty password);

~$ sudo ldapsearch -Y EXTERNAL -H ldapi:/// -D cn=admin,cn=config -b cn=config -W olcDatabase={1}hdb

You should see a metric shedload of output with this at the end;

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

If you see output like above then your LDAP server is working, but we still need to finish configuring samba.

Unpack the samba-ldap-tools (we downloaded this earlier)

~$ sudo gzip -d /usr/share/doc/smbldap-tools/configure.pl.gz

Now we are going to execute a perl script which will set up samba for us. For almost every prompt you should just press Enter. There are a few of exceptions however. When asked for "logon home" and "logon path" enter a "." (fullstop) and nothing else. When asked for a password (ldap master/slave bind password) use the password for the "admin" account that you entered earlier. Remember, leave the default value for everything else!

Run the script;

~$ sudo perl /usr/share/doc/smbldap-tools/configure.pl

Now that the script has created our configuration, we can use it to populate the server;

~$ sudo smbldap-populate
Populating LDAP directory for domain TUXNETWORKS (S-1-5-21-3403240416-131340500-4256605436)
(using builtin directory structure)

adding new entry: dc=tuxnetworks,dc=net
adding new entry: ou=Users,dc=tuxnetworks,dc=net
adding new entry: ou=Groups,dc=tuxnetworks,dc=net
adding new entry: ou=Computers,dc=tuxnetworks,dc=net
adding new entry: ou=Idmap,dc=tuxnetworks,dc=net
adding new entry: uid=root,ou=Users,dc=tuxnetworks,dc=net
adding new entry: uid=nobody,ou=Users,dc=tuxnetworks,dc=net
adding new entry: cn=Domain Admins,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Domain Users,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Domain Guests,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Domain Computers,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Administrators,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Account Operators,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Print Operators,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Backup Operators,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: cn=Replicators,ou=Groups,dc=tuxnetworks,dc=net
adding new entry: sambaDomainName=TUXNETWORKS,dc=tuxnetworks,dc=net

Please provide a password for the domain root:
Changing UNIX and samba passwords for root
New password:
Retype new password:


Note:

The "UNIX and samba passwords for root" can be anything, you don't need to use the LDAP admin password here.

The final touches;

~$ sudo /etc/init.d/slapd stop
~$ sudo slapindex

WARNING!
Runnig as root!
There's a fair chance slapd will fail to start.
Check file permissions!

Ignore the warning!

~$ sudo chown openldap:openldap /var/lib/ldap/*
~$ sudo /etc/init.d/slapd start

Make "root" the domain adminstrator;

~$ sudo smbldap-groupmod -m 'root' 'Administrators'
adding user root to group Administrators

If this returns;

adding user root to group Administrators

with no errors then you are looking good!

Now, we need to allow clients to authenticate via LDAP. To do this we need to install a package.

~$ sudo apt-get --yes install ldap-auth-client

During this process enter the following details;

ldapi:///127.0.0.1:389/

dc=tuxnetworks,dc=com

3

Yes

No

cn=admin,dc=tuxnetworks,dc=com

mypassword

We also need to tell PAM and the "Name Service Switch" (NSS) service to use LDAP for auth;

~$ sudo auth-client-config -t nss -p lac_ldap
~$ sudo pam-auth-update ldap

If all has gone well, you should now be able to add a user to the database;

~$ sudo smbldap-useradd -a -m -P brettg
Cannot confirm uidNumber 1000 is free: checking for the next one
Changing UNIX and samba passwords for brett
New password:
Retype new password:

Note:

You will notice the above command returns "Cannot confirm uidNumber 1000 is free: checking for the next one" and your LDAP user ends up with UID of 1001. If you are an OCD type like me and want all your users on LDAP and starting at 1000, then you might want to consider changing the UID of the default Ubuntu system user to a number below 1000 before issuing this command. If you do that, then make sure that you can log in and get sudo privileges before you go any further of course.

You can check your new user by issuing this command;

~$ ldapsearch -xLLL -b "dc=tuxnetworks,dc=com" uid=brettg
dn: uid=brett,ou=Users,dc=tuxnetworks,dc=net
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaSamAccount
cn: brett
sn: brett
givenName: brett
uid: brett
uidNumber: 1001
gidNumber: 513
homeDirectory: /home/brett
loginShell: /bin/bash
gecos: System User
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
displayName: brett
sambaSID: S-1-5-21-3403240416-131340500-4256605436-3002
sambaPrimaryGroupSID: S-1-5-21-3403240416-131340500-4256605436-513
sambaLogonScript: allusers.bat
sambaLMPassword: 157FBB24ACBE1A68AAD3B435B51404EE
sambaAcctFlags: [U]
sambaNTPassword: 8462E3FFE0BA1C8CED841873EC989A29
sambaPwdLastSet: 1308795478
sambaPwdMustChange: 1312683478
shadowLastChange: 15148
shadowMax: 45

If you get output like this then congratulations, you have successfully configured a combined Samba/LDAP server!

Next, you should go ahead and configure a client

Revisions:
13/7/2010- Karan Pratap Singh pointed me to another howto which does some things in a better way than mine did. I have merged the parts that I like into my document (see comments)

23/6/2011- Retested, confirmed the process still works. Some parts were cleaned up and extra output from some of the commands was added. Also I split the post into 2 parts as it was getting quite long.

HOWTO: VirtualBox "headless" on Lucid Lynx

As of karmic koala, Vbox 3.x is provided via the standard Ubuntu repositories. Unfortunately, this is the OSE version and it does not appear to work headless.

So, we have to download the "free as in beer" version from the Oracle website, which is currently here

At the time of writing the current build for Lucid is virtualbox-3.2_3.2.4-62467~Ubuntu~lucid_i386.deb

Before we can install the deb, we will also need to install some dependencies.

sudo apt-get install libcurl3 dkms libqt4-network libqtgui4 libxslt1.1 libasound2 \
libdirectfb-1.2-0 libgl1-mesa-dri libgl1-mesa-glx libqt4-opengl libsdl1.2debian \
libsdl1.2debian-alsa libsysfs2 libts-0.0-0 libxcursor1 linux-headers-`uname -r` \
libxdamage1 libxfixes3 libxmu6 libxxf86vm1 tsconf libqtcore4 libaudio2 libmng1

Now we can install the virtualbox deb that we downloaded earlier.

sudo dpkg -i virtualbox-3.2_3.2.4-62467~Ubuntu~lucid_i386.deb

Next, add your user account to the vboxusers group

sudo adduser brettg vboxusers

Virtualbox machines that you create will by default go in your home directory

/home/brettg/.VirtualBox/

Ensure vboxusers have appropriate permissions to the kernel, create the file;

sudo vi /etc/udev/rules.d/40-permissions.rules

/etc/udev/rules.d/40-permissions.rules

KERNEL=="vboxdrv", GROUP="vboxusers", MODE="0660"

That's it, Virtualbox should be installed and ready to go.
Now we can move on to creating a virtual machine
Create a machine named "io"

VBoxManage createvm -name io --ostype Ubuntu -register

Configure it with a nic bridged to eth0, 256Mb RAM, enable acpi and set to boot from DVD

VBoxManage modifyvm io --memory 256 --pae on --acpi on --boot1 dvd --nic1 bridged --bridgeadapter1 eth0

Create a virtual IDE controller

VBoxManage storagectl io --name IDE0 --add ide

Create a virtual HDD

VBoxManage createvdi -filename ~/.VirtualBox/Machines/io/sda.vdi -size 48000 -register

Attach the virtual HDD

VBoxManage storageattach io --storagectl IDE0 --port 0 --device 0 --type hdd --medium ~/.VirtualBox/Machines/io/sda.vdi

Create and attach a virtual DVD drive to the controller and insert the DVD image

VBoxManage storageattach io --storagectl IDE0 --port 1 --device 0 --type dvddrive --medium /store/archive/ISO/ubuntu-10.04-server-i386.iso

The default vrdp port for machines is 3389, however, if you intend to run more than one guest then each one will need to listen on a different port. I use the 3xxx range with the xxx being the last octet of the machines IP address. For example, 192.168.0.1 would be 3001.

VBoxManage modifyvm io --vrdpport 3001

And thats it, your machine has been created. Time to start it up and give it a test drive!

Using the virtual machine

Start the machine

nohup VBoxHeadless -startvm io &

On a GUI workstation, establish a remote desktop connection to the machine. In my case, the host server is called "jupiter" so I type;

rdesktop -a 8 jupiter:3001

After you have installed the OS, you need to tell the machine to boot from the hdd.

VBoxManage modifyvm io --boot1 disk

You can also deregister the dvd image if you don't intend to use it again.

VBoxManage unregisterimage dvd /store/archive/ISO/ubuntu-10.04-server-i386.iso

Here are some other useful commands;

VBoxManage showvminfo io
VBoxManage list hdds
VBoxManage list runningvms
VBoxManage controlvm io poweroff
VBoxManage unregistervm io --delete
VBoxManage controlvm io savestate
VBoxManage closemedium disk UUID
VBoxManage modifyhd UUID --type immutable

HOWTO: LDAP Client on 10.04 Lucid Lynx

This is essentially the same as my previous Hardy Heron LDAP howto but with some steps removed. Rather than edit the old article I thought I'd just reproduce it with the appropriate parts omitted. This howto is also relevant to Jaunty and Karmic. The LDAP Server howto can be found here.

PLATFORMS TESTED: Ubuntu 10.04 LTS (Lucid), Ubuntu 11.04 LTS (Natty)

PREREQUISITES:
* A vanilla Ubuntu 10.04 (or later) desktop or server install.
* You have shared your user home directories from an NFS server
* You have successfully installed a working LDAP server

Network overview;
* domain name: tuxnetworks.com
* Servername/IP: ldap.tuxnetworks.com 10.1.1.5
* The user "brettg" is a valid LDAP user on your server.

We are going to set up a Lucid client connected to an LDAP server. We should aready have our home directories mounted via NFS.

~$ sudo apt-get install libpam-ldap libnss-ldap nss-updatedb libnss-db nscd ldap-utils

You will again be asked a bunch of questions;

LDAP server Uniform Resource Identifier: ldap://ldap.tuxnetworks.com
Distinguished name of the search base: dc=tuxnetworks,dc=com
ldap://ldap.tuxnetworks.com 3
Make local root Database admin: Yes
Does the LDAP database require login? No
LDAP account for root: cn=admin,dc=tuxnetworks,dc=com
LDAP root password: (The server LDAP root password)


Now we need to edit the following files;

~$ sudo vi /etc/ldap.conf

and edit these lines to look like this;

bind_policy soft

pam_password crypt

Find the line that begins with uri ldapi:// . . .

Comment the line out and replace it with a line like so;

uri ldap://ldap.tuxnetworks.com/

Edit this file;

~$ sudo vi /etc/ldap/ldap.conf

Edit it to look like this;

BASE    dc=tuxnetworks,dc=com
URI     ldap://ldap.tuxnetworks.com 

SIZELIMIT       0
TIMELIMIT       0
DEREF           never

Edit nsswitch.conf

~$ sudo vi /etc/nsswitch.conf

Enter the following lines;

passwd:         files ldap
group:          files ldap
shadow:         files ldap

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

Now update nss to use ldap.

~$ sudo nss_updatedb ldap
passwd... done.
group... done.


Note:

If you get an error . . .
Failed to enumerate nameservice: No such file or directory

. . . then check that your uri line in /etc/ldap.conf is correct and the address is pingable.

You should now be able to check the server with;

~$ ldapsearch -x

That command should output a tonne of stuff from the server LDAP directory.

getent passwd

You should now be able to login to the client via ssh using the user "brettg"s credentials

brettg@jupiter:~$ ssh brettg@galileo
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Fri Jun 24 14:13:05 2011 from 10.1.1.80
brettg@galileo:~$ 

Take a look at your passwd file to make double sure you are not logging in using local auth;

grep brettg /etc/passwd

If that returns a line then you are probably logged in using a local user. Remove that line from /etc/passwd and try again.

For Gnome Desktop users.

Assigning users to the correct groups at login, create a new file called group.conf and place the following line in it;

vi /etc/security/group.conf

gdm;*;*;Al0000-9000;floppy,audio,cdrom,video,plugdev,scanner

We also need to tell pam to use the group.conf settings;

vi /etc/pam.d/gdm 

Add this line;

auth optional pam_group.so

Reboot your PC and you should be able to login to gnome using ldap!

Network monitoring with ntop

Install ntop

sudo apt-get install ntop

Create the directories that for some reason are not created by the installer

sudo mkdir /var/lib/ntop/rrd
sudo mkdir /var/lib/ntop/rrd/graphics
sudo mkdir /var/lib/ntop/rrd/flows
sudo mkdir /var/lib/ntop/rrd/interfaces
sudo mkdir /var/lib/ntop/rrd/interfaces/eth0
sudo mkdir /var/lib/ntop/rrd/interfaces/ppp0
sudo chmod -R 775 /var/lib/ntop

Start ntop on selected interface ppp0 (you will be asked to create an admin password, don't forget it!)

sudo ntop -i ppp0

browse to the ntop web interface at

http://router.example.com:3000

To manually start as a daemon, use

sudo ntop -i ppp0 --daemon

You can use the usual init scripts to start ntop;

sudo /etc/init.d/ntop start

In my case I need to monitor ppp0 so I need to edit /var/lib/ntop/init.cfg

vi /var/lib/ntop/init.cfg

and change the interface to ppp0.

Network lockup during heavy load

Since karmic, the Realtek drivers for the 8169 card have become borked. If you try and copy large amounts of data your machine will hang and require a hard reset.

I got this solution from here;

1) Check to see if the r8169 module is loaded

lsmod | grep r816
r8168 41104 0
-> lspci -v
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
Subsystem: ASRock Incorporation Device 8168
Kernel driver in use: r8169
Kernel modules: r8169

2) Download the official Realtek driver
Realtek RTL8111/RTL8168

Update: I'm using the 8.017 driver but the current driver on that website is 8.018. It is possible that this version contains the same regression fault that causes this lock up behaviour as I experienced trouble after installing it. If you have trouble, download the older driver from here and add a comment to this post.

3) Remove the r8169 module

rmmod r8169
mv /lib/modules/`uname -r`/kernel/drivers/net/r8169.ko ~/r8169.ko.backup

(Note: the ` is a backtick, it is not an apostrophe or single quote )

4) Build the new r8168 module for the kernel

bzip2 -d r8168-8.009.00.tar.bz2
tar -xf r8168-8.009.00.tar
cd r8168-8.009.00
make clean modules
make install

5) Rebuild the kernel module dependencies

depmod -a
insmod ./src/r8168.ko

6) Remove the r8169 module from initrd

mv /initrd.img ~/initrd.img.backup
mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r`

7) Add r8168 module to /etc/modules

echo "r8168" >> /etc/modules

Reboot, You are done!

Lucid Window Controls

The upcoming release of the next Ubuntu LTS release, "10.04 Lucid Lynx" has seen the developers suffer some sort of brain explosion causing them to move all of the Window Controls to the left, al la apple OS/X.



To put them back as they were before do the following;

Open a console or hit ALT-F2 and enter "gconf-editor"

navigate to Apps/Metacity/general

Change the "Button Layout" field to be;

:minimize,maximize,close

The menu buttons should now be back in the top right hand corner.

Bootnote: I have just realized that the new default themes are somewhat broken by putting the controls back into their correct order



Notice how the pretty rounded graphics are now messed up because we have the square minimise button in the "wrong" position?

Another yuck. What are they thinking?

As far as I can tell, the only way to "rectify" this is to use a theme such as the old "Human" or "Clearlooks" or just about any theme other than the new themes that are specially designed for Lucid.

HOWTO: Setting up a vpn using ssh and pppd

For this we need two systems, one is designated as the server, the other the client. The server needs to have a static IP address or dynamic dns name from a free service such as https://www.dyndns.com/. Also, ensure that all firewalls are turned off or port 22 forwarding is enabled for both hosts.

Configuring the SSH accounts;

On the "server" machine;

Firstly, if you have not already installed ssh server do so now.
sudo apt-get install openssh-server

I use port 443 for VPN connections because this is usually the easiest port to get through a firewall that you don't control.

Edit your ssh server config;

sudo vi /etc/ssh/sshd_config

Change the line;

Port 22

to

Port 443

and restart your SSH server;

sudo /etc/init.d/ssh restart

Now, we create a user called "vpn";

sudo adduser --system --group vpn

The --system parameter sets vpn's shell to /bin/false but because the vpn user needs to log in via ssh, we must change this to /bin/bash in the /etc/passwd file.

sudo vi /etc/passwd

Here is an example;

vpn:x:110:110::/home/vpn:/bin/bash

The account password will only be used during this howto. You can choose a complex (secure) one now or a simpler temporary one and change it later.

Creating a password;

sudo passwd vpn

You should be able to login to the account from the client now;

ssh vpn@hostname

The next step is to create a ssh keypair for the root user on the client machine and place that public key in the vpn users authorized_keys file. Use this guide to configure passwordless ssh but remember to use the vpn user on the server instead of the root user as is shown in that guide.

Once you have passwordless SSH properly configured between root@client and vpn@server you should change the password to a more secure (random) one if you haven't already done so it will no longer be needed.

Time to set up the actual VPN.

Configuring the VPN;

The pppd daemon we will use needs to run as root, but we don't want to give our vpn user complete access to the system. To do that we configure sudo to give minimal access rights.

On the Server, open the visudo editor

visudo

Add these three lines to the end of the file

vpn ALL=NOPASSWD: /usr/sbin/pppd
vpn ALL=NOPASSWD: /sbin/iptables
vpn ALL=NOPASSWD: /sbin/route


This allows our vpn user to execute the pppd command to start the vpn and use the "route" command to set the return routes (if required).
If you are setting up a router<->router connection you will need to set the appropriate return routes to the client on the server.

To do this, create a script in the vpn user directory on the server.

vi /home/vpn/returnroutes.sh

Place the appropriate route commands to the subnet(s) at the clients end. If you don't want return routes then just don't enter any route commands. Here is mine;

#!/bin/sh
sudo route add -net 10.48.0.0/16 gw 192.168.0.1
sudo route add -net 10.0.0.0/16 gw 192.168.0.1


This script must be executable

chmod +x /home/vpn/returnroutes.sh

and owned by the vpn user

chown vpn:vpn /home/vpn/returnroutes.sh

We can also check that the pppd permissions are set up properly by logging in as the vpn user and issuing this command;

sudo /usr/sbin/pppd noauth

You should see a bunch of hieroglyphics such as this.

~�}#�!}!}!} }4}"}&} } } } }%}&����}'}"}(}"��~

You can kill the process from another terminal or just wait 30 secs or so for it to finish on its own.

Now we can configure the client (logged in as root)
Firstly, we need to use a script to connect to the server. You can locate the script anywhere you like, I put it in /usr/local/bin

You can download a copy of the connect script or simply
copy and paste this text into a file


#!/bin/sh
# SCRIPT: vpn-connect version 2.2
# LOCATION: /usr/local/bin/vpn-connect
# DESCRIPTION: This script initiates a ppp-ssh vpn connection.
# see the VPN PPP-SSH HOWTO on http://www.linuxdoc.org
# for more information.
# NOTES: This script uses port 443 so your VPN server should be
# configured to listen for ssh on Port 443
#
# revision history:
# 1.6 11-Nov-1996 miquels@cistron.nl
# 1.7 20-Dec-1999 bart@jukie.net
# 2.0 16-May-2001 bronson@trestle.com
# 2.2 27-Sep-2009 brettg@tuxnetworks.com
#
# You will need to change these variables...
#
# The host name or IP address of the SSH server that we are
# sending the connection request to:
SERVER_HOSTNAME=tuxnetworks.homelinux.net

# The username on the VPN server that will run the tunnel.
# For security reasons, this should NOT be root. (Any user
# that can use PPP can intitiate the connection on the client)
SERVER_USERNAME=vpn

# The VPN network interface on the server should use this address:
SERVER_IFIPADDR=192.168.3.2

# ...and on the client, this address:
CLIENT_IFIPADDR=192.168.3.1

# This tells ssh to use unprivileged high ports, even though it's
# running as root. This way, you don't have to punch custom holes
# through your firewall.
LOCAL_SSH_OPTS="-P"

PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11/:

## required commands...

PPPD=/usr/sbin/pppd
SSH=/usr/bin/ssh
RETURNROUTES=/home/vpn/zenroutes.sh

if ! test -f $PPPD ; then echo "can't find $PPPD"; exit 3; fi
if ! test -f $SSH ; then echo "can't find $SSH"; exit 4; fi

case "$1" in
start)
# echo -n "Starting vpn to $SERVER_HOSTNAME: "
${PPPD} updetach noauth passive pty "${SSH} -p 443 ${LOCAL_SSH_OPTS} ${SERVER_HOSTNAME} -l${SERVER_USERNAME} -o Batchmode=yes sudo ${PPPD} nodetach notty noauth" ipparam vpn ${CLIENT_IFIPADDR}:${SERVER_IFIPADDR}
${SSH} -p 443 ${SERVER_HOSTNAME} -l ${SERVER_USERNAME} ${RETURNROUTES}
route add -net 10.1.0.0 netmask 255.255.0.0 gw $SERVER_IFIPADDR
# route add -net 10.2.0.0 netmask 255.255.0.0 gw $SERVER_IFIPADDR
# route add -net 192.0.0.0/8 gw $SERVER_IFIPADDR
;;

stop)
# echo -n "Stopping vpn to $SERVER_HOSTNAME: "
PID=`ps ax | grep "${SSH} -p 443 ${LOCAL_SSH_OPTS} ${SERVER_HOSTNAME} -l${SERVER_USERNAME} -o" | grep -v ' passive ' | grep -v 'grep ' | awk '{print $1}'`
if [ "${PID}" != "" ]; then
kill $PID
echo "disconnected."
else
echo "Failed to find PID for the connection"
fi
;;

config)
echo "SERVER_HOSTNAME=$SERVER_HOSTNAME"
echo "SERVER_USERNAME=$SERVER_USERNAME"
echo "SERVER_IFIPADDR=$SERVER_IFIPADDR"
echo "CLIENT_IFIPADDR=$CLIENT_IFIPADDR"
;;

*)
echo "Usage: vpn {start|stop|config}"
exit 1
;;
esac
exit 0


You need to change the SERVER_HOSTNAME variable in the above script. You may also need to change SERVER_IFIPADDR and CLIENT_IFIPADDR depending on your existing network landscape.

Now we need to make the script executable

chmod +x /usr/local/bin/vpn-client

To start the vpn, at the client type

/usr/local/sbin/vpn-client start

You can check if it is up using the "ifconfig" command

ifconfig ppp0

Note: if you already have a ppp connection, such as to your ISP, then you may need to do "ifconfig ppp1". To see all your current ppp connections enter

ifconfig | grep ppp

If you want the vpn connection to be permanently up you can create a script to check the status and restart it if required.

vi /usr/local/sbin/vpn-check

Code;

#!/bin/sh
EMAIL=brettg@tuxnetworks.com
DAEMON=pppd

if [ "$(/bin/pidof $DAEMON)" = "" ]; then
/usr/local/sbin/vpn-client start
wait
if ! [ "$(/bin/pidof $DAEMON)" = "" ]; then
echo "VPN restarted $(date +%m-%d-%Y)"
fi
fi


Now, add an entry to the system crontab to run the script every minute

vi /etc/crontab

Add this line

* * * * * root /usr/local/sbin/vpn-check

Cron will automatically restart so we don't need to do that.

Now, assuming all has gone well if you issue the command

/usr/local/sbin/vpn-client stop

and wait for about a minute the vpn client should automatically reconnect!

Source:
http://www.faqs.org/docs/Linux-mini/ppp-ssh.html#AEN237