The Node

Posts Tagged ‘home networking’

I’ve been stuck on Ubuntu 9.10 for a year now on my desktop Ubuntu machine simply because I couldn’t get Ubuntu 10.04 or above to recognise the “Windows-only” USB wireless adaptor that Orange ships out to all it’s customers with it’s Orange LiveBox. I tried many up-to-date distributions, including Linux Mint 9 but none of these distros would recognise the USB wireless device.

It’s an Inventel UR054g model, one that Orange (formerly Wanadoo) hands out to all it’s broadband customers, so I imagine there are a fair few Ubuntu users without wireless because of this problem. Ubuntu 9.10 recognises it just fine, but when I upgraded I found to my horror that the wireless broke. Finally, I’ve found out how to fix it.

For this, you’ll need the “linux-firmware-nonfree” package. The easiest way to get it is from another Ubuntu machine (however, I have put it online here if you don’t have a spare Ubuntu box).

Go to System->Synaptic Package Manager and search for “linux-firmware-nonfree”. Select it and go to File->Generate package download script. It will generate a file which looks like: -


#!/bin/sh
wget -c http://gb.archive.ubuntu.com/ubuntu/pool/multiverse/l/linux-firmware-nonfree/linux-firmware-nonfree_1.9_all.deb


So run that script (or the wget command above) and transfer the .deb package to the Ubuntu machine which has the broken wireless. You’ll then need to install the package with: -


sudo dpkg --install linux-firmware-nonfree_1.9_all.deb


Once this is done, disconnect your Inventel USB dongle, reconnect it and you should now have working wireless in Ubuntu 10.04 or above. I hope this helps out Ubuntu-lovers who are also Orange broadband customers :-)

EDIT 02/05/2011: Rather crucial spelling error pointed out by zabius. Thank you sir!

If you’re sharing files and directories to Windows-based clients on your network, it’s probably best to use Samba. If however, you’ve got other Linux machines you’d like to share directories on your server with, you can use NFS or Network File System.

First you have to tell Linux which directories you want to share by editing the “/etc/exports” file. We’ll share a directory called “/usr/local/inst”.


/usr/local/inst *(rw,sync)


If you’d wanted this directory to be read-only, change the “rw” to “ro”. Once you’ve added this line to the exports file, you need to export the file system to make it available to the network.

exportfs -a

Lastly, you need to start the NFS service daemons if they’re not already started.


service portmap start
service nfslock start
service nfs start


Next you’ll have to configure each NFS client machine to automatically mount the server’s networked file system in a local directory each time it is accessed. So, create a directory to mount the NFS share locally: -

mkdir /mnt/inst

Before configuring automounting, check that you can access the server’s network share manually – assuming the server is on IP address 192.168.1.2: -


mount 192.168.1.2:/usr/local/inst /mnt/inst/
umount /mnt/inst


If this doesn’t work, you may need to open various ports that NFS needs in your server’s firewall. Many supposed NFS problems are really problems with the firewall. In order for your NFS server to successfully serve NFS shares, its firewall must enable the following:

ICMP Type 3 packets.
Port 111, the Portmap daemon.
Port 2049, NFS.
The port(s) assigned to the mountd daemon.

You can assign static ports to the various NFS daemons in the “/etc/sysconfig/nfs” file where you can add: -


LOCKD_TCPPORT=48620
LOCKD_UDPPORT=48620
MOUNTD_PORT=48621
STATD_PORT=48622
STATD_OUTGOING_PORT=48623
RQUOTAD=no
RQUOTAD_PORT=48624


This will assign ports for 48620 (TCP/UDP) for lockd, 48621 (TCP/UDP) for mountd (used by the “mount” command), 48622 (TCP/UDP) used by statd and 48624 (TCP/UDP) used by the rquotad daemon, although here I’ve turned remote quotas off. The next step is to open ports in your iptables firewall for these ports.


-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 48620 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 48621 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 48622 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 48623 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 48624 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 48620 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 48621 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 48622 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 48623 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 48624 -j ACCEPT


If you now try to mount the server’s shares on your Linux client, it should work. Obviously, the network share needs to be able to be written to/read from the user attempting to connect. Consult your file permissions if you get errors.

If you can now mount network shares manually, you can also automount these shares. This way, the server will server the network share only when the client attempts to enter that directory.

Edit your “/etc/auto.master” file and add this line: -

/mnt/inst /etc/auto.inst --timeout=300

This sets up the configuration file for the automount point at /mnt/inst on the client. The main configuration file is /etc/auto.inst and the timeout for the connection inactivity is 300 seconds. Next, you have to set up the auto.inst file. This is a “map” file for the automount. The /etc/auto.master file can hold many of these mappings and the file can be any name, although we’ve named it as the same as the directory to be mounted for clarity. The /etc/auto.inst file looks like this: -


/mnt/inst -fstype=nfs,soft,intr,nosuid,tcp 192.168.1.2:/usr/local/inst &


The first column for this entry is the mount point. The “fstype” is the file system type we’re attempting to mount. “soft” means that if the network resource is unavailable, return an error and don’t retry after the timeout period has expired (hard means that it will keep attempting to connect). “nosuid” means don’t use suid and “tcp” is the protocol. Then you list the IP address of the server and the remote absolute file path to the network share.

Last thing is to start the automount daemon.

service autofs restart

Now when you cd to that directory, the network share should be automatically mounted – and you don’t even have to be root to do it :-)

This will show you how to access your Linux machine from Windows, essentially turning your Linux server into an excellent home file server that you can access from Windows Explorer using a technology called Samba. It essentially provides file and print services over TCP/IP so that Windows machines can interact with Linux (and many other operating systems).

Now, the things you can configure with Samba is pretty long, but we’ll discuss a few scenarios. First of course, we have to install Samba. Under Fedora/CentOS, this is done with: -

yum install samba

Under Ubuntu/Debian, this is done with: -

sudo apt-get install samba

Once Samba is correctly installed, it needs to be configuring for use. Open up the /etc/smb.conf file (under Fedora, this is actually located under /etc/samba/smb.conf).

First, we’ll start off with the global settings.


[global]
hosts allow = 127.0.0.1 192.168.1.0/24
hosts deny = 0.0.0.0/0
hide dot files = YES
veto files = /.*/
workgroup = MSHOME
server string = MyLinuxServer SMB v%v
netbios name = My.Linux.Server


You can set hosts_allow and hosts_deny to accept or disallow certain IP addresses or IP address ranges. Here, I’m simply allowing any connections that come from either localhost (127.0.0.1) or from any machine on my local network. Obviously, I don’t want to allow anyone from the wider Internet to connect to my Samba server :-) Also, for Windows I’m going to hide dot files – under Linux, this are any files that begin with “.” and are usually hidden in the Linux filesystem unless you specifically request to look at them. Since these will have little relevance to Windows, I’ve opted to hide these files so they don’t show up under Windows Explorer. “Veto files” also takes a regular expression string to hide many other types of files, but regular expressions are beyond the scope of this post, so we’ll just leave these be.

Workgroup should be set to your Windows Workgroup – typically MSHOME unless it’s been changed. The next two lines simply define the server string (the %v merely shows the Samba version number) that will show up under Windows Explorer and the Windows NetBIOS name for the Linux server.

The first share that can be configured are the home directories for all the connecting users. The [homes] section is a special configuration and Samba already knows how to handle all the users different home directories, it really only needs to be specified and Samba will do the rest. This will essentially make all user’s home directories under Linux accessible with read/write access from a Windows client assuming correct login details which the Windows client will prompt for.


[homes]
comment = Home Directory for %S
read only = No
browseable = No
valid users = %S


“browseable” here states that the Linux shared directories are viewable (browseable) from something like “My Network Places” or “Network Neighbourhood” under Windows, but we’ll set this to “No” as otherwise anyone who searches for the Samba server will see every home directory available, regardless if they have the required login details to actually access it.

The “Homes” share is a special share under Samba – the “homes” share does create a share called “homes” under Windows. It tells Samba to automatically create home directories on the fly for each individual user home directory. This particular share is a special case. Normally, the “[share name] creates this share that appears to a Windows client as “share name”, whilst “[homes]” creates all shares for all home directories. The comment parameter uses the %S wildcard, which expands to the actual name of the share. This will cause the share for user “tom” to have the comment “Home directory for tom”, the “alice” share to have the comment “Home directory for alice” and so on. We use this “%S” macro in the “valid users” line too so that only the owner of the share and administrator are allowed to access it. Pretty neat, right?

Okay, let’s create a slightly less complex share now that that is out of the way. How about a share that is accessible by anybody to share files? Remember we set Samba to only pay attention to the local network and not accept connections from outside our locla network, so this is good for sharing files between local users.


[Shared]
comment = Global Share - All Users
path = /mnt/shared
read only = No
guest ok = Yes
public = Yes
browseable = Yes
create mask = 0666
directory mask = 0777
security = share
guest account = nobody


The “Shared” shared that we have created above allows access to all of the files and directories within the “/mnt/shared” local directory. The resource can be written to by all guest and public users and the resource can be viewed (browseable) by workstations and clients on the network. Any new directory created in the share will be given the directory permissions of 777, and any new file will have file permissions of 666. These mask settings allow any user to save files to the shared directory, and any other user can read, write or delete the files.

Unlike the special “homes” share before, this will appear simply as “shared” under Windows clients. Now, instead of using “homes”, what about if you want just one user to access their home directory? This is simply done via the below configuration: -


[tom]
comment = Tom Samba Share
security = user
path = /home/tom
read only = no
browsable = yes
guest ok = no


You can also have even more fine-grained than simply “public” and “private” shares for users – you can add small groups of users to a share via something like the following: -


[SmallGroup]
comment = Small Share - Few Users
path = /mnt/smallgroup
read only = No
guest ok = No
browseable = Yes
create mask = 0666
directory mask = 0777
valid users = peter, paul, mary


There are several other share parameters that might be useful. Some of these are listed below.

“available=” – This is “yes” by default, but it can be an easy way to disable a share without deleting it’s configuration.
“valid users=” – By default, any authenticated user will be allowed to access a Samba share. You can refer to a valid NIS netgroup or Unix group by appending an “@” to the group name.
dont descend=” – Specifies directories in the share that Samba should not enter. This can be handy to prevent Samba from entering a directory that contains recursive symlinks, or to restrict access to irrelevant directories like /proc and /dev.
“follow symlinks=” – This normally defaults to ‘yes’ and will cause Samba to follow all symlinks even if they redirect Samba to files or directories outside of the exported directory tree. Setting follow symlinks to ‘no’ will turn off this functionality and prevent symlinks from being followed at all. Turning off follow symlinks does eliminate a potential security hole and should be done when symlinks are not needed or required.

The next thing to do is to start the Samba service.

service samba start

You can also set the Samba service to start on boot in the most common runlevels with: -

chkconfig --levels 345 smb on

You’ll also need to add the following ports to the IPTables firewall with: -


iptables -A INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
iptables -A INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT


else you won’t be able to access the Samba shares. Obviously, I wouldn’t recommend adding these ports to your router firewall unless you want to be able to access Samba from the outside world.

The absolute last thing to do is to access this share from Windows and to map a Samba share to a network drive so that it appears to be just another Windows drive letter.
Open a Windows Explorer Window and choose Tools -> Map Network Drive. Choose a suitable drive letter and enter: -


\\[your server IP address]\[your Samba share name]


NOTE: If you cannot connect to your Samba share and get an error something like “The specified domain either does not exist or could not be contacted.” and are using Windows Vista / Windows 7, either update Samba to 3.2.12 or 3.3.5. In addition to the update, the registry changes that are required in Windows Vista/7 to allow the joining of a Samba 3.2.12 or Samba 3.3.5 domain are as follows:


HKLM\SYSTEM\CCS\Services\LanmanWorkstation\Parameters
DWORD DomainCompatibilityMode 1
DWORD DNSNameResolutionRequired 0


If this doesn’t work, you’ll need to change a couple of settings: -

1. from the run command or from a cmd window run secpol.msc
2. go to “Local Policies” -> “Security Options” -> “Network Security: LAN Manager authentication level”
3. change to “LM and NTLM – use NTLMV2 session security if negotiated”
4. Press the OK button.

You should now be able to access your Samba shares under Windows Vista/7. You don’t need to do anything like this for Windows XP, it should just work right out of the box.

That’s it, really. There are plenty of other things you can do with Samba and these are just basic examples to get you started – you can, for example, share printers over Samba if you wish, but refer to the official Samba documentation for this.

Like many other people, I use GMail with alarming frequency. So imagine my joy when I got my shiny new Sony Ericsson W715 phone last year and discovered that it had a built in GMail client. Now, like many Linux users, my system’s root account regularly gets updated with e-mails from cronjobs, system status updates and the like. It’s also incredibly easy to write scripts and programs to mail users various alerts. So I wanted to find out how I could route the e-mails sent to root (or any other local Linux system account) elsewhere, like my GMail account. That way, anything my Linux system had to report could get sent directly to my mobile phone without spending any money on fancy equipment.

Sendmail might seem an unnecessary service to leave running on a home server, especially with most home broadband customers having an SMTP server account with their ISP. Besides, sendmail is not set up to receive e-mails outside of it’s local network and that’s not really something I know how to do. However, sendmail is quite an important service to leave running on any Linux system that is being used in a server environment as it’s used as a messaging service to alert the root user of various things that might be happening to the system. This remains true even if you’re running it as a standalone server at home.

You’ll need the following packages installed: -


sendmail
sendmail-cf


Install using your favourite package manager.

So, how to send these system alerts to my GMail address? Well, for this to work, you will need several things – a valid hostname for your system and an account on your ISP’s SMTP server (you know, the server you used to use for e-mail in Outlook before WebMail became all the rage :-)). I talked about how to set up DynDNS for a static hostname for your home server here. So assuming you have these two things, there is no reason why you can’t route these system mails to your WebMail account. Let’s assume your Linux server is called my.server.org and your ISP mail server is called my.smtp.server.net.

First you’ll need to edit the /etc/aliases file.

vi /etc/aliases

You’ll see something similar to the below: -


postmaster: root
# General redirections for pseudo accounts.
bin: root
daemon: root
adm: root
lp: root
sync: root
shutdown: root
...


The aliases file is essentially like a mailing list file. The first column has the mailing list name (sometimes called a virtual mailbox), and the second column has the members of the mailing list separated by commas. To start, sendmail searches the first column of the file for a match. If there is no match, then sendmail assumes the recipient is a regular user on the local server and deposits the mail in their mailbox. If it finds a match in the first column, sendmail notes the nickname entry in the second column. It then searches for the nickname again in the first column to see if the recipient isn’t on yet another mailing list. If sendmail doesn’t find a duplicate, it assumes the recipient is a regular user on the local server and deposits the mail in their mailbox. If the recipient is a mailing list, then sendmail goes through the process all over again to determine if any of the members is on yet another list, and when it is all finished, they all get a copy of the e-mail message.
We need to add the web e-mail address as a mailing list to the root user so that any e-mails sent to root@localhost actually get sent to a e-mail address somewhere else on the Internet.

root mywebmailaccount@gmail.com

You will also notice an associated /etc/aliases.db that is not readable with vi (or emacs if you prefer). This is the file that is actually used by sendmail, but it is encrypted (no, I don’t know why – security?). To compile the /etc/aliases file into the /etc/aliases.db file, issue the command: -

newaliases

Once this is done, we need to configure sendmail to use our ISP’s SMTP mail server. This is because our server isn’t actually a mail server itself, but will pass the e-mails along to our Service Provider’s mail server for transportation to the wider Internet, hence the need to have an account on this SMTP server. Basically, we’re going to use sendmail here almost like Outlook or Thunderbird, simply passing the e-mails along to another SMTP server for actual transportation :-)

First we need to provide login and server details for the SMTP server at our ISP. Create a new file under /etc/mail called “authinfo”.

vi /etc/mail/authinfo

and add the following text, substituting values for your actual details where needed: -


AuthInfo:my.smtp.server.net "U:myusername" "I:myusername" "P:mypassword" "M:LOGIN PLAIN".


Like the /etc/aliases file, this needs to be compiled before sendmail will be able to read it. Do so with: -

makemap hash /etc/mail/authinfo < /etc/mail/authinfo

So now we have the e-mail address where root mails will be sent and the login details for the SMTP server which wil be used to send the mails. All that remains is to configure sendmail to pull everything together. Edit /etc/mail/sendmail.mc and add the following lines where indicated: -


dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
# --- MY MAIL SETTINGS --------------------
define(`SMART_HOST',`my.smtp.server.net')dnl
FEATURE(`authinfo',`hash /etc/mail/authinfo.db')dnl
dnl MASQUERADE_AS('my.server.org')dnl
MASQUERADE_AS(my.server.org)dnl
FEATURE(`masquerade_envelope')dnl
LOCAL_DOMAIN(`my.server.org')dnl
# -------------------------------------------


We’re using hostname masquerading here, so that sendmail knows that we’re not just pulling a hostname out of our ass here (although we kinda are :-)). If you want to check if your hostname has a valid MX record, issue the command: -

dig mx my.server.org

If you get valid DNS records back, you should be fine.

Remember to replace my.server.org with the hostname of your machine and my.smtp.server.net with the SMTP server name from your ISP. Like the aliases and authinfo file, this file needs to be compiled before sendmail will read it.

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Restart sendmail:

service sendmail restart

…and you’re done. You can test sending a mail using sendmail using something like: -

echo "Testing" | mail -s "Test" mywebmailaccount@gmail.com

You can check the sendmail system log to see if it reports any errors.

tail -200 /var/log/maillog

Keep in mind that the /var/log/maillog file isn’t actually written to by sendmail itself, it’s written by the rsyslogd daemon. If you’re not getting anything in your mail log, it’s probably because rsyslogd isn’t running. Start it with: -

service rsyslog start

If you do get any errors, try playing around with your authinfo file settings, but the above works for me. It seems by default that sendmail will always try and resolve the SMTP host via it’s MX record. If you just have an internal IP address for your SMTP server (common enough in business networks), you’ll need to add the following to your /etc/hosts file.


xxx.xxx.xxx.xxx my.smtp.server.org


…replacing the “xxx.xxx.xxx.xxx” with the IP address of the SMTP mail server and the name to whatever you want. This must be the same hostname you use in the SMART_HOST directive in your “/etc/mail/sendmail.mc” file. If your maillog still isn’t resolving your server, create the file “service.switch” under /etc/mail and add the following lines: -


hosts files
aliases files


Restart network and sendmail services with: -


service network restart
service sendmail restart


…and you should be golden.

You might also add separate e-mail addresses for all the users on your Linux system in the /etc/aliases file. It would be nice if each user could assign their own e-mail address without having to get the root user to do it and if I figure out how to do that, I’ll post about it. Have fun!

If you’re like me, you’ve got a residential broadband ISP. This is all great, but this really limits what you can do with your home Linux box. Why is this? Well, while some residential ISPs will assign your router an unchanging IP address, residential ISP routers don’t usually have a static IP address on the Internet – your ISP will periodically change your home router’s IP address to another free one in their IP block – presumably to keep their limited address range free at peak times as there are usually more users than free IP addresses going around. Some Service Providers will allow you to have a static IP address for your router, but you’ll be paying a premium for it.

So this means that, even if you fiddle around with your broadband router settings and firewall and set up NAT routing certain traffic from the outside world to your Linux box, eventually all this will be for naught when your router IP changes and suddenly, no Linux box on the Internet! Wouldn’t it be nice to be able to access your home Linux server from anywhere in the world? Maybe upload photos to your server from Thailand or SSH into your home Linux server from work? Yes, that would be awesome! :-)

Here’s where DynDNS comes in. If you sign up for a free account, you can link your dynamic IP address to a static hostname and access it from anywhere on the Internet. The downside of the free account is that you cannot have just any old hostname, you can only choose from several preset hostnames like xxxx.kicks-ass.org or xxxx.dyndns.org where “xxxx” is the name of your machine. But that’s okay….the service is free after all and we’re not running a business here.

Okay, I’m sold and now have a username and password. What’s next?

Great – now login to DynDNS’s website and go to “My Services” -> “My Hosts”. Setup a new hostname for your Linux machine. The next thing to do will be to poke around your router’s configuration screens (most are web-based) and look for something that mentions dynamic DNS or something similar. The reason for this is that many home routers have support for DynDNS and similar services built in. Why is this important? Well, because when your non-static IP address changes on your router, your router has to tell DynDNS that your IP address has changed so that it can match up your new IP address to your DynDNS hostname (DNS in general is simply a bunch of hostname/IP address pairs).
If you find such a setting, you’ll have the opportunity to enter your hostname, DynDNS account username and password and basically you’re done and can skip to the last section. If, on the other hand, you’re unlucky enough to have a router that doesn’t support such dynamic DNS services or can’t find it, you’ll have to get a wee bit more technical…

My Router doesn’t have that built in!

Not to worry….ddclient to the rescue! “ddclient”, like it’s name suggests, is a small dynamic DNS client written in Perl that you’ll run on your Linux box that will poll your router periodically and update your DynDNS account hostname when your IP address changes. Under Fedora linux, you can install it (as root) with: -

yum install ddclient

Under Ubuntu, you’d use: -

sudo apt-get install ddclient

Now edit your /etc/ddclient.conf file. This might be under /etc/ddclient/ddclient.conf for CentOS. Remember to use Sudo if using Ubuntu.

vi /etc/ddclient.conf

Now, setting up the configuration might take a bit of trial and error – but the main directive you want to look at is “use=”. As you can see from the commented out defaults, lots of router models are supported directly to get the current IP address:


...
#use=netgear-rt3xx, fw=192.168.0.1:80 # via Netgear's internet FW
#use=linksys, fw=192.168.1.1:80 # via Linksys's internet FW
#use=maxgate-ugate3x00, fw=192.168.0.1:80 # via MaxGate's UGATE-3x00 FW
...


However, once again, you might be unlucky enough to have a router not directly supported by ddclient. That’s okay, all it’s really trying to do is to access your router’s web admin screen on port 80 to get the current IP address. Before I realised that my router supported DynDNS directly in it’s webadmin screen, I coded my way out of it :-)

This very quick and dirty PHP script sits on my Linux web server. My router’s web admin screen (before you have to login) includes the current router IP address, so I wrote this quick script to isolate the IP address from the HTML admin page and echo it out.


< ?php
$routerPage = file_get_contents("http://configuration.adsl/");
$routerPage = str_replace("\t", "", $routerPage);
$routerPage = str_replace("\n\r", "", $routerPage);
$routerPage = str_replace("\n", "", $routerPage);
$indexOfConnectedStringStart = strpos($routerPage, "Connected");
$ipAddress = substr($routerPage, $indexOfConnectedStringStart + 11, 15);
$ipAddress = ereg_replace('[<]', '', $ipAddress); echo $ipAddress; ?>


So in the ddclient.conf file, you can use “use=web” rather than a specific router model. I guess you could even use a free web service like WhatsMyIP if you wanted…


use=web, web=whatismyip.org


…but I’m going to use my script as it’s taylored to my router. So the “use” directive simply has to be a web address that simply prints out your current IP address as seen by other machines on the Internet. The next important directives are: -


use=web, web=localhost/myip.php
login=<DynDNS username>
password=<DynDNS password>
protocol=dyndns2
server=members.dyndns.org
custom=no, <DynDNS hostname>


Login and password are self-explanatory. The server at members.dyndns.org is the server at DynDNS to contact with your new IP address details. Leave the protocol as the default. Once you’re satisfied that ddlclient is configured correctly, you’ll need to start the ddclient service. Under Fedora or RedHat-based systems, this is: -


chkconfig --add ddclient --level 345
service ddclient start


Under Debian or Ubuntu, this is: -


update-rc.d ddclient defaults
service ddclient start


Done! If you go back to your DynDNS member page, you’ll now see next to your hostname your current router IP address. Job done. I’ll talk about what you can do now with the power of Linux on your home network in future, but remember if you want to host your own blog or website to configure your router firewall and Network Address Translation (NAT) tables to allow traffic to your Linux server’s private IP address (192.168.1.xxx probably) from the wider world. Don’t forget about security! I’ll let you figure out the rest…