Tuesday, 29 September 2009

Mounting Samba shares

Install smbfs;

sudo apt-get install smbfs

Put something like this in your fstab;

//ntserver/share /mnt/samba smbfs username=myusername,password=mypassword 0 0

Mount the drive;

sudo mount /mnt/samba

Your drive should now be accessible at /mnt/samba

Friday, 25 September 2009

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


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;


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


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;

sudo route add -net gw
sudo route add -net gw

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

# 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:

# 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)

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

# ...and on the client, this address:

# 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.


## required commands...


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
# 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}
route add -net netmask gw $SERVER_IFIPADDR
# route add -net netmask gw $SERVER_IFIPADDR
# route add -net gw $SERVER_IFIPADDR

# 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."
echo "Failed to find PID for the connection"


echo "Usage: vpn {start|stop|config}"
exit 1
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



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

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!


Mixed Systems

I have a system that requires the 2.6.3x kernel because it is the only one that supports the motherboards onboard NIC.

I tried it with karmic alpha but unsurprisingly I ran into stability problems so I am going back to Jaunty.

However, I still need to run the newer kernel. I could of course compile it myself but I really prefer not to. I could manually download the deb and then install it and all it's dependencies myself but that would probably cause as many instability problems as just nursing Karmic along.

So, a mixed system it is.

On Debian systems, this is simply done by adding "APT::Default-Release "version";" to your apt.conf file and sticking "stable". "testing" or whatever in as the "version".

We can't do this on Ubuntu because they use a different naming system to Debian. If we were to set "version" to "jaunty" then we would no longer receive security updates because in Ubuntu Land these come from ubuntu-security instead.

Fortunately, there is a way around this and here it is.

Firstly, we copy our existing "jaunty" sources.list to /etc/apt/sources.list.d
sudo cp /etc/apt/sources.list /etc/apt/sources.list.d

Next, we change it to point to the "karmic" repositories.
sudo sed -i 's/jaunty/karmic/g' /etc/apt/sources.list.d/sources.list

Create a Ubuntu style preferences file
sudo vi /etc/apt/preferences

Here is the contents of my preferences file, it should be fairly self explanatory;
Package: *
Pin: release a=jaunty
Pin-Priority: 900

Package: *
Pin: release a=karmic
Pin-Priority: 500

Package: *
Pin: release a=jaunty-updates
Pin-Priority: 900

Package: *
Pin: release a=karmic-updates
Pin-Priority: 500

Package: *
Pin: release a=jaunty-backports
Pin-Priority: 900

Package: *
Pin: release a=karmic-backports
Pin-Priority: 500

Package: *
Pin: release a=jaunty-security
Pin-Priority: 900

Package: *
Pin: release a=karmic-security
Pin-Priority: 500

Package: *
Pin: release a=jaunty-proposed
Pin-Priority: 900

Package: *
Pin: release a=karmic-proposed
Pin-Priority: 500

Finally, we update aptitude
sudo apt-get update

To install the kernel package from the karmic repository we first need to know what version we want
apt-cache search linux-image

The one I'm interested in is "linux-image-2.6.31-10-386"
I can just install this kernel using its full name
sudo apt-get install linux-image-2.6.31-10-386

To install packages from the Karmic repository I can use the -t distribution parameter
sudo apt-get -t karmic install packagename

Or I can specify a package version
apt-get install nautilus=2.2.4-1

Wednesday, 23 September 2009

Graphing router traffic with MRTG

Systems tested; Ubuntu Hardy

NET-SNMP configured on each target (Ubuntu,FreeBSD)

Install required packages
sudo apt-get install apache22 gcc make g++

Install MRTG
sudo apt-get install mrtg

Edit the mrtg configuration file
sudo vi  /etc/mrtg.cfg

# Global Settings

RunAsDaemon: yes
EnableIPv6: no
WorkDir: /var/www/mrtg
Options[_]: bits,growright
WriteExpires: Yes

Title[^]: Traffic Analysis for

Now we use cfgmaker to create a profile for each snmp target
sudo :q!cfgmaker public@targetname > /etc/mrtg.cfg

Finally, we create an index file for the webserver using indexmaker
sudo indexmaker /etc/mrtg.cfg > /var/www/mrtg/index.html

You can take a look at the graphs by pointing your browser to


Setting up SNMP

Systems tested; Ubuntu Hardy

install packages
apt-get install snmp snmpd

I'm not sure why there are two config files but there are and we have to edit both. The first file configures the daemon itself
vi /etc/default/snmpd

Ensure these two lines exist
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'

Change the localhost address on the 2nd line to the address of the interface you will listen on (remove it completely to listen on all interfaces)
The second file contains the snmp details such as access rights & community names
vi /etc/snmp/snmpd.conf

Find this section;
#       sec.name  source          community
com2sec paranoid default public
#com2sec readonly default public
#com2sec readwrite default private

and change it to;
#       sec.name  source          community
#com2sec paranoid default public
com2sec readonly default public
#com2sec readwrite default private

NOTE: Using the default community "public" is not recommended for security reasons. You should change it to a custom community name. It is left as default for simplicities sake. To change it just comment out all lines and add a new one. For example;
#       sec.name  source          community
#com2sec paranoid default public
#com2sec readonly default public
#com2sec readwrite default private
com2sec readonly default MyCommunity

Checking your configuration from the local host
snmpwalk -Os -c public -v 1 localhost system

This should return a bunch of lines relating to various parts of your system. You can execute the same command from another host (snmp package is required), changing "localhost" to the name of the system.


Friday, 11 September 2009

Installing Request Tracker in Hardy LTS

Tested in Ubuntu Server 8.04 LTS

Your system should be able to send and receive email
You should have the universe repo enabled in /etc/apt/sources.list

Installing the packages;
sudo apt-get install request-tracker3.6 rt3.6-apache2 \
rt3.6-clients mysql-server apache2

The mysql-server installer will ask you to create a root password during the package configuration process. Don't forget to jot it down!

Configuring Request Tracker;

The RT configuration file located at /etc/request-tracker3.6/RT_SiteConfig.pm
vi /etc/request-tracker3.6/RT_SiteConfig.pm

Make the appropriate changes to the config file for email address, domain, database and timezone for your particular network.

Add the following two lines to the database section.
Set($DatabaseHost , ‘localhost’);
Set($DatabaseRTHost , ‘localhost’);

Here is a sample config;
Set($rtname, 'support.example.com');
Set($Organization, 'example');

Set($CorrespondAddress , 'support@example.com');
Set($CommentAddress , 'comments@example.com');

Set($Timezone , 'Australia/Melbourne'); # obviously choose what suits you


Set($DatabaseType, 'mysql'); # e.g. Pg or mysql

# These are the settings we used above when creating the RT database,
# you MUST set these to what you chose in the section above.

Set($DatabaseUser , 'rtadmin');
Set($DatabasePassword , 'password');
Set($DatabaseName , 'rtdb');
Set($DatabaseHost , 'localhost');
Set($DatabaseRTHost , 'localhost');


Set($WebPath , "/rt");
Set($WebBaseURL , "http://support");


Configure the database

Log in to the db (you did write down the root password, right?)
mysql -u root -p

Create a database user

Exit mysql

Configure the database;
sudo /usr/sbin/rt-setup-database-3.6 --action init --dba rtadmin --prompt-for-dba-password

This is what you should see;
Now creating a database for RT.
Creating mysql database rtdb.
Now populating database schema.
Creating database schema.
Done setting up database schema.
Now inserting database ACLs
Done setting up database ACLs.
Now inserting RT core system objects
Checking for existing system user...not found. This ap perlpears to be a new installation.
Creating system user...done.
Now inserting RT data
Creating Superuser ACL...done.
Creating groups...
Creating users...10.12.done.
Creating queues...1.2.done.
Creating ACL...2.3.done.
Creating ScripActions...
Creating ScripConditions...
Creating templates...
Creating scrips...
Creating predefined searches...1.2.3.done.
Done setting up database content.

Enable the apache2 RewriteEngine
sudo ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/

Enable the apache perl module
sudo a2enmod perl

Reload apache
sudo /etc/init.d/apache2 force-reload

The Request Tracker login screen can be found at;

Thursday, 10 September 2009

Making apps start at boot

Sometimes you install an application which doesn't configure itself to automatically start and stop with the OS.

To make it start you need to do two things.

Firstly, we need to make a symlink to the app in /etc/init.d
ln -s /usr/local/myapp/bin/myapp /etc/init.d/myapp

Secondly, we need to update the system startup and shutdown scripts using update-rc.d
update-rc.d myapp start 20 2 3 4 5 . stop 20 0 1 6 . 

You should see the following output.
Adding system startup for /etc/init.d/myapp ...
/etc/rc0.d/K20myapp -> ../init.d/myapp
/etc/rc1.d/K20myapp -> ../init.d/myapp
/etc/rc6.d/K20myapp -> ../init.d/myapp
/etc/rc2.d/S20myapp -> ../init.d/myapp
/etc/rc3.d/S20myapp -> ../init.d/myapp
/etc/rc4.d/S20myapp -> ../init.d/myapp
/etc/rc5.d/S20myapp -> ../init.d/myapp

The numbers in the update-rc command correspond to the start/stop position of the app during the boot process and the run levels to apply the command to.

To remove them again type
update-rc.d -f myapp remove

Wednesday, 2 September 2009

Background and Foreground processess

I work a lot of the time in a console. Sometimes I will start a long running process and want it to run as a background process. There are a coupla ways to do this.

1) Add an ampersand ("&") to the end of the command line.
$ bgcommand &

2) Use nohup
$ nohup bgcommand

However, if you are anything like me, you will constantly forget to do this so in such cases you will want to move your process to a background process.

We can do this using CTRL+z to suspend the command and then "bg" to move it to the background.
$ bg

Now your command continues executing but you are able to enter new commands on the console.

However, if you close or lose that console for whatever reason then the background process will be killed. To avoid this you need to detach the process using the disown command.
$ disown -a