Installing smbldap-tools

If you haven’t installed LDAP yet, do so now. This will be a rather short article, where we just get smbldap-tools working. This is a collection of programs to handle Samba users (and groups) stored in an LDAP database. We will use them later when configuring Samba.

First, copy the configuration examples for smbldap-tools to your /etc directory:

zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > ~/smbldap.conf
sudo cp ~/smbldap.conf /etc/smbldap-tools/
sudo cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf /etc/smbldap-tools/
sudo chmod 0644 /etc/smbldap-tools/smbldap.conf
sudo chmod 0600 /etc/smbldap-tools/smbldap_bind.conf

Now, you should edit your new smbldap.conf to match your environment, but first we need to find the SID of the Samba server; Do this with:

sudo /etc/init.d/samba start
sudo net getlocalsid

Save it to your clipboard for now (or write it down, if you like). Then edit smbldap.conf, changing all the relevant lines. These were my changes:

SID="S-1-5-21-9999999999-587502800-999999999"
sambaDomain="GODTJOD-NT"
ldapTLS="0"
suffix="dc=godtjod,dc=net"
sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"
defaultMaxPasswordAge="365"
mailDomain="godtjod.net"
no_banner="1"

(Note: You can do a search for those attributes you want to change by pressing Ctrl+w (for where).)

Edit the /etc/smbldap-tools/smbldap_bind.conf, which defines how to bind (authenticate) to the LDAP server, and add lines like:

slaveDN="cn=admin,dc=godtjod,dc=net"
slavePw="pa$$w0rd"
masterDN="cn=admin,dc=godtjod,dc=net"
masterPw="pa$$w0rd"

The default superuser call name (cn) for a Debian install of OpenLDAP is “admin”, not “manager” (which you might’ve expected from other LDAPs).
Now, pray that everything is ok and start populating the LDAP database with entries for Samba:

sudo smbldap-polulate

You will be asked for a root password, so provide a good one here. Then check everything went in:

ldapsearch -x

That’s it for now. Soon we will be starting Samba itself, so stay tuned.

(If you follow the original guide, he talks about the Administrator (uid=Administrator) account, but in my installation it was called root, and we already changed password for that so there’s no need to change it again, huh?)

Installing LDAP

At first, I was going to wait with installing LDAP on the slug, because it isn’t really needed at this point, and I just wanted to get the file serving up and running. But then I found this great guide to LDAP/Samba installation and I thought I’d try it out. So these instructions should follow Edd Dumbill’s quite closely, but with some extra details about how I did things.

First I installed the things I needed from the apt archives:

sudo apt-get install slapd ldap-utils libnss-ldap libpam-ldap samba smbldap-tools smbclient samba-doc

I followed the advice from the guide and didn’t configure the packages at this time. Instead I configured them one at-a-time with dpkg-reconfigre, like so:

sudo dpkg-reconfigure -plow slapd

This will start the configuration for LDAP. It asks some questions, most of which should be really obvious. Some tips though: You should create a database backup, even if it will just contain rubbish, because, like it says, the old data could break your installation. If you don’t plan on using any services that need LDAPv2 (I don’t), you should disable it.
Also clean out the backup (as I said it is just rubbish):

sudo rm -R /var/backups/unknown-2.3.30-5.ldapdb

Edit your configuration for the LDAP tools with:

sudo nano -wL /etc/ldap/ldap.conf

(ldap.conf is for the client, slapd.conf is for the server) and add the following lines:

BASE dc=godtjod,dc=net
URI ldap://127.0.0.1

Now check your database with:

sudo ldapsearch -x

If it returns two entries (your domain, and your superuser) then you are ready to continue with setting up a samba database in your LDAP-service. First we copy the schema (a model for a database) for samba:

zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > ~/samba.schema
sudo cp ~/samba.schema /etc/ldap/schema/

and configure slapd to include this schema by adding the following lines to slapd.conf (right after the existing includes):

include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/misc.schema

In the same file tell slapd to use some indexes (the slug isn’t terribly fast and so could use the speed-up); In the database section add the lines (after the existing index line):

index uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq

Also in slapd.conf, change the access rules to allow your users to change their own passwords. Do this by changing the line

access to attrs=userPassword,shadowLastChange

to

access to attrs=userPassword,shadowLastChange,sambaNTPassword,sambaLMPassword

Then restart your LDAP server to load the changes and again check that everything works:

sudo /etc/init.d/slapd restart
sudo ldapsearch -x

Did it work? Good, then take a break and wait for the next part: how to use samba with ldap.

Dynamic IP with DynDNS

Tomorrow the slug will be moved to Valhall* and installed there. It will then connect directly to the internet and a DHCP server over which I have no control. This means I will have no knowledge over which IP address it is assigned and I cannot login to it with SSH as I do now.

Luckily I already have an account at DynDNS, so I will set up a dynamically updated IP address here and update it using the Perl-script ddclient. I won’t go into any details about this as it is really straightforward. I added the host suttung.godtjod.net ** to my zone, with a “dynamic” type (meaning we will change it with a update client).

Next, I installed the ddclient on the slug. It is already in the Debian repository, so just run:

sudo apt-get update
sudo apt-get install ddclient

You will be asked for the name of your host (suttung.godtjod.net in this case), your login and password at DynDNS, and which interface to get the IP-address from (eth0 is the built-in ethernet on the slug). In my case this failed to work, so I went on and edited the configuration file:

sudo nano -wL /etc/ddclient.conf

with the new file looking like:

#get IP number from interface eth0
use=if, if=eth0
#run as a daemon, updating every 5 minutes
daemon=5m
#log to syslog
syslog=yes
#keep pid in this file
pid=/var/run/ddclient.pid
#default protocol is dyndns2 (the current protocol for DynDNS.org)
protocol=dyndns2
#default server to update to
server=members.dyndns.org
#login and password to the DynDNS service
login=habrok
password='pa$$w0rd'

#host specification
protocol=dyndns2 \
server=members.dyndns.org \
#this is a custom DNS service (using my own domain)
custom=yes \
#the host to update
suttung.godtjod.net

I think it might be the “custom=yes” thing that did it, but I made all the changes at once so I don’t really know.

Now try out your configuration:

sudo ddclient

Check the web-interface at DynDNS to see if it is updated correctly; If it is, you should start the daemon to get periodic updates:

sudo /etc/init.d/ddclient start

Now, you might wonder if this is really working? Maybe your IP doesn’t change all too often so you can’t sit around waiting for it to change. Don’t worry. Just run ddclient manually to set another (and faulty) IP-address:

sudo ddclient -ip 10.10.10.10

Wait for the next update (5 minutes in our case) and check that the IP is back to what it should be.

No worries, eh?

* Valhall is a mock name, there isn’t really a place called that (not that I know of at least).

** You should choose a real name for your host, not one about what it is (like ’slug’) or what it does (like ‘fileserv’). Names like these may be good for remembering, but then you can always add an alias (a CNAME record) to your DNS.

Configuring sudo

The next step in setting up a file server on the slug is an easy one: Install sudo rights for my normal user.
I use sudo as a matter of convenience; If I don’t have it installed I’m much more likely to do stuff as root (that doesn’t have to be made as root). The security aspects of sudo, where you can limit what each user (or group) can do with sudo, doesn’t really matter to me since I am the sole administrator of these boxen and I want absolute power. This means that our sudo set up will be a real simple on (you’ll see later).

But first things first; Let’s start with installing sudo to the slug.
If you haven’t logged in to the box yet, do so now:

ssh habrok@192.168.1.6

Of course you should exchange habrok for the login of the user created with the Debian installer, and the IP with the IP of your slug. Now we install sudo with apt, starting with an update of the local package list (it is always good to do an update at the start of a session, though nothing bad will happen if you forget; The packages will fail to download, that’s all):

su -
apt-get update
apt-get install sudo

Next we will configure sudo access, by editing the /etc/sudoers file. We won’t do this with the normal editor though, but run the special editor visudo instead. Visudo is used to prevent syntax errors in the /etc/sudoers file, which might otherwise lock everyone out of doing sudos. You might think that visudo has something to do with the infamous vi editor, but don’t worry, it will actually use nano for your editing session. So go ahead and type:

visudo

We will make just one change in this file. Below the “user privilege specification” comment add a line:

%wheel ALL = (root) ALL

This line means that members of the “wheel” system group (the percent sign means a group) on any host (the first “ALL”) will be able to execute any command (the second “ALL”) as root (this is the default, so it isn’t really necessary to write it out, but it is clearer this way). The reason I didn’t allow the wheel users to run command as any user (which is done by putting “ALL” within the parentheses) is that I honestly don’t know why I would ever need this (security 101: Don’t enable things you don’t know you will need).

Now save (ctrl+O) and exit (ctrl+X). Visudo will tell you if there is any syntax errors, if so press ‘e’ to correct them.

Now we need to add the users we want to run sudo to the wheel group*. First check that there isn’t already a wheel group:

cat /etc/group | grep wheel

This should return nothing (at least if you’re running a new installation of Debian like me), so go on and create this group:

addgroup --system --gid 23 wheel

The group id doesn’t have to be 23, I just find it easy to remember (you actually don’t have to specify a group id at all, if you don’t the system will assign one for you).
Now add our normal user and root (for good measure) to the wheel group:

adduser habrok wheel
adduser root wheel

Now, we have to log out and in again for our group membership to be updated, so do that now:

exit
exit
ssh habrok@192.168.1.6
groups

Now “wheel” should be listed among the groups you are member of (if not you have to su again and try to find where things went wrong), so go on and try to sudo something:

sudo apt-get update

Type your password (your password, not the root password) and see if it starts updating the package list. If it works (and it should) then you can go on lock your root account, if not you have to su to root account again and correct any errors you’ve made first.

Locking out the root user is a bit scary, you might not be able to correct mistakes if do something stupid (now or later). With the slug I can’t even use the usual recovery procedure (booting from a CD), so instead of really locking out root, I will just set a very long, random password, which I write down and keep in a secret place.

First generate a random password with your favourite password generator (I use apg, which can be found in Ubuntu’s universe). Then set the root password for the slug with:

sudo passwd root

Your slug should now be properly set up with sudo, so go on and get yourself some coffee or something.

* At this point, you may wonder why the group is called wheel (and not admins or sysops or something). This is just a tradition; The wheel group was used to restrict which users could run the “su” command (I think Berkeley might have been first with this). Now we use it to restrict sudo.

Slug installation, part 2

From the first part we inherited a slug (= a Linksys NSLU2) with a debian installer started. Now, the slug doesn’t have a console, so we need to access the installer through SSH:

ssh installer@192.168.1.6

Accept the new RSA key fingerprint (you may have to delete the previous key first, the RSA key is regenerated when you reflash), and type in the password “install”. You should be greeted by this screen:

Choose “Start menu” to be taken to the installer. Then you have to chose a mirror to download the Debian archives from. I think the list shows all servers, although we’re really only interested in those that has packages for ARM. Use the Debian mirror list to make sure the mirror you select carries packages for the ARM architecture before you continue. (I’ve had problem with ftp.sunet.se before, although when I check now I see that it actually has ARM packages. Well, maybe it was something else that didn’t work then.) The primary mirror for your country is usually a sensible choice.

Next up is choosing which modules to load for the installer. The guide I followed recommended these modules:

• ext3-modules…
• partman-auto
• partman-ext3
• scsi-core-modules…
• usb-storage-modules…

We won’t use automatic partitioning, so I don’t know if partman-auto and partman-ext3 is really necessary, but it doesn’t hurt anyway.

Then we go for partitioning the disk. I used manual partioning and created a root partition (ext3), and a swap partition on the USB memory stick. Since we will be running LDAP on this box, I figured I need some swap for caching and doubled the minimum requirement of 128MB (to 260MB). Write your partitions to disk and format them (you didn’t choose to format them at the partition screen? then go back and do it right).
Next you are told to choose a language, but I don’t know what this choice really means. It certainly doesn’t change the language (I chose Sweden, but didn’t get Swedish). Maybe it is the time settings; At least it says “configuring the clock” next. Anyway, just chose your country and continue.

Then it is time to create users. First you create a root user (you only have to give a password for him) and then you also set up a regular (non-privileged) account.

After you’ve set up users the base system will be downloaded and installed to the USB stick. Answer any questions about these packages that may come up (it shouldn’t be too difficult). After installation the tasksel dialog appears:

The “Standard system” should be enough here, we will install the packages we need for the file server later. Now it will download and install some more packages, and this should take a while (I didn’t take time, but upwards an hour perhaps). When it is done you should see the following message:

Choose “Continue”; You will then be disconnected from the slug. Wait a while (ten minutes?) and then log in with the login credentials for the user you created before (you could log in as root, but it is prudent not to).

And that’s it. You can start playing around with your new toy, as will do now with mine.

Slug installation

Our first task is to reflash the Linksys NSLU2. This box will later be used as a file server at Valhall, though it currently stands silently at Bilskirnir.

Now, I actually already reflashed it with Debian/NSLU2, but I though I’d redo it to document the process. There is already a quite good document describing the installation process. This installation guide will be more specific, however, describing how I got things to work.

A look at what we need for this task:

• A slug (not a slimy one, I mean a Linksys NSLU2)
• A installation medium for Debian (it won’t fit in internal flash); I used a 2 GB memory stick
• A computer running Kubuntu
• A switch and some network cables
• A lot of patience (the Slug isn’t very fast) and some coffee

First, we put all the equipment in place:

1. Connect the slug to a power outlet.
2. Connect a network cable from the slug to the switch.
3. Connect a network cable from the computer to the switch (I use wireless normally, but this don’t work for reflashing with upslug2).
4. Connect the memory stick to USB port 1 on the slug (port 2 probably works, but I haven’t tested so I can’t confirm this).

Power on the slug and set it to receive a IP address via DHCP. (Information about this can be found in the manual, I think.) When done, power off the slug again.

Ok, let’s download all the programs we need to the laptop. The binary image for the Debian Installer (with Intel’s proprietary network driver) can be found at slug-firmware.net. At the time of writing the most up to date image is Etch RC2, so I grabbed that one. You have to accept Intel’s license before you download. I don’t think there’s any indecent stuff there, but then I just skimmed it (and I’m certainly not a lawyer). We also need the upslug2 tool which I downloaded with apt (for Kubuntu, it is in the Universe repository, be sure you enable this first):

sudo apt-get install upslug2

Next, put the slug in upgrade mode:

1. Press and hold the reset button with a metal clip (the hole is quite deep, so a pen won’t do)
2. Power on the slug without releasing the reset button
3. The top diode () shines yellow for approximately 10 seconds – keep the reset button down.
4. When the top diode turns to amber (the change is quite subtle, be sure to do this in a dark room) immediately release the reset button (you have at least a second I think).
5. The diode should now flash amber. If not, restart the process.

As far as I can tell, the slug will stay in upgrade mode until you reboot it, so you don’t have to hurry starting the reflash.

Now go back to the Konsole window you should have started, and type:

cd
mkdir slug
mv download/debian-etch-rc2-20070308.zip slug/
cd slug
unzip debian-etch-rc2-20070308.zip

Now run the upslug2 tool to reflash (upslug2 has to be run as root because of how it interacts with the network interface):

sudo upslug2 -i di-nslu2.bin

The installation process should begin. The upslug2 tool will report the MAC address for the slug. Use this to set up a static lease for it. I set it to 192.168.1.6 for this.
When the installation finished (it says “Rebooting… done”) you have to wait a while (5 minutes perhaps) before you can log on to your debian installation via SSH.

Coming up, the Debian Installer….

The beginning

First, let’s see what we’ve got to work with. This project won’t build a network from scratch, but rather build upon the things that already are there. Much of the existing equipment will be rebuilt however to make things more streamlined. Today, it’s just one step away from chaos, and a lot of work will be devoted to shaping things up, with a proper network layout.

The current network is spread across four different locations, which will be called Bilskirnir, Trudvang, Glitner and Valhall. Bilskirnir has internet access through a wireless link to Trudvang, the other locations (including Trudvang) has direct access to the internet.

At Bilskirnir we have the following equipment:

• A laptop running Kubuntu (this is where I’m writing this from)
• An old desktop PC running Ubuntu server (and nothing else really)
• An even older desktop PC running Kubuntu (I think, haven’t started it for a while)
• A somewhat newer desktop PC running Debian (this was my main box before the laptop came along)
• A network attached printer
• A Linksys wireless AP to connect to Trudvang
• A Linksys NSLU2 (commonly called a slug)
• A switch, some network cables and other stuff

At Trudvang there is:

• A desktop PC running Windows (this box won’t really be used in this project, it just shares the internet connection with the other boxen)
• A laptop running Windows (this won’t be used on the network either for now, but possibly later)
• A Linksys router (WRT54G) running DD-WRT
• Some cabling and stuff

I’m not quite sure what equipment there is at Valhall, but something like this:

• A laptop running Windows
• Another laptop running Windows (this computer belongs to another company and can’t really be used in the network)
• An old desktop PC running Windows
• A hub to connect these boxen to the Net (they will thus have separate public IPs)
• A local printer
• Network cables all over the place (since there is no wireless) and some small stuff not worth mentioning

At Glitner there is also some uncertainty about what equipment there is, but it should be:

• A laptop running Mac OSX
• Another laptop running Windows (won’t be used on the network I think)
• A wireless router of unknown model (I know it isn’t a Linksys)
• Cables and stuff of course

Well, I think that’s it. I probably forgot some stuff, but nevermind. We can cover that later.

Statement of intent

I will use this blog to try and document my setting up of a network for a small company. Mostly so I can remember what I was doing myself (or rather not remember, but still knowing), but possibly (hopefully) someone else will benefit from my experiences as well.

The good thing about publishing stuff this way, is that I will be forced to write proper sentences and stuff. My usual notes I can’t understand myself, a couple of weeks after they’ve been written (this is quite common, I think). Please pardon if it isn’t really good writing anyway, I never was a good writer and I don’t seem to have acquired any talent just now either.

To keep things private (and so as not to help the criminals of the Net), all names and other data about the network will be changed to names from Norse mythology. The network will use the domain godtjod.net. This domain does not exist, so don’t try to access it, all right?

All right, let’s get to it…