iproute2 is a suite of tools developed to unify the functions provided by the traditional tools in one place under the ip command. Interface configuration, routing and tunnelling can now all be configured and managed using the ip command.

Interface configuration

Historically, interfaces are managed using the ifconfig command, and to get an overview of the interfaces you’d type ifconfig -a. With iproute2, interfaces addressing is managed through the address subcommand – which, like the rest of the subcommands for iproute2 can be shortened Cisco IOS-style, as long as it’s unique. In theory this means you can use ip a, but the manual page refers to it as ip addr, which I’ll use here for clarity. So, the equivalent of ifconfig -a is the self-explanatory ip addr show, which if we’re not specifying a specific interface can be shortened to simply ip addr:-

[root@example ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth0

Most of this should be self-explanatory, and everything you would see with ifconfig -a you’ll see with ip addr.

Bringing up eth0 on a Linux box would usually consist of doing the following:-

[root@example ~]# ifconfig eth0 up
[root@example ~]# ifconfig eth0 192.0.2.1 netmask 255.255.255.0

With iproute2, control of interfaces themselves – both physical and logical – is through the link subcommand. Bringing up eth0 can be done with:-

[root@example ~]# ip link set eth0 up

Managing the addresses on an interface is through the aforementioned addr subcommand, so using our example again, we’d do something like this to add an IP to eth0:-

[root@example ~]# ip addr add 192.0.2.1/24 dev eth0

I’ve used CIDR notation in this example, but you can use the normal dotted quad format for the netmask if you wish.

This also makes adding multiple IP addresses to interfaces really easy. To add 192.0.2.2 to our example eth0 interface, you’d just do:-

[root@example ~]# ip addr add 192.0.2.2/24 dev eth0

Showing the addresses on our eth0 interface only will show that both the addresses are now there:-

[root@example ~]# ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

Removing an IP from an interface is also straightforward:-

[root@example ~#] ip addr del 192.0.2.2/24 dev eth0

Querying the interface again shows that 192.0.2.2 is no longer assigned to eth0:-

[root@example ~]# ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1

Routing

Using netstat -rn is pretty much burned into the brains of most UNIX engineers, but luckily the iproute2 method is just as snappy. Routing management is handled with the route subcommand, and in line with addr and link, it can be shortened – ip r will work, but I usually settle for ip ro. The full command for showing the routing table is ip route show, but as with ip addr you can drop the show if you want to show the entire routing table:-

[root@example ~]# ip ro
192.0.2.0/24 dev eth0  proto kernel  scope link  src 192.0.2.1
default via 192.0.2.254 dev eth0

Adding and removing routes is accomplished with ip ro add and ip ro del respectively:-

[root@example ~]# ip ro add 10.0.0.0/16 via 192.0.2.253
[root@example ~]# ip ro del 10.0.0.0/16 via 192.0.2.253

One useful feature of ip route is the get function, which we can use to query the routing table for a particular network or address. In our example, querying for an address not on our local network shows that the route to it goes via our default gateway:-

[root@example ~]# ip ro get 1.2.3.4
1.2.3.4 via 192.0.2.254 dev eth0  src 192.0.2.1
    cache  mtu 1500 advmss 1460 hoplimit 64

Neighbours

arp -na is the traditional way you’d query the ARP table on a UNIX machine. You can accomplish this with iproute2 using ip neighbor (or ip neighbour for us not from the US), with ip n being the shortened extreme:-

[root@example ~]# ip neigh
192.0.2.3 dev eth0 lladdr 00:02:a5:1f:cb:2d REACHABLE
192.0.2.254 dev eth0 lladdr 00:09:43:bc:aa:80 REACHABLE

I’ll skip the example for this, but needless to say you can add and remove entries with ip neigh add and ip neigh del respectively.

A little helping hand

If you’re stuck, then the help argument can come in handy. If you specify help as an argument to ip itself, or to one of the subcommands, it’ll give you a quick overview of the options available. For example, for ip neighbor:-

[root@example ~]# ip neigh help
Usage: ip neigh { add | del | change | replace } { ADDR [ lladdr
          LLADDR ] [ nud { permanent | noarp | stale |
          reachable } ] | proxy ADDR } [ dev DEV ]
       ip neigh {show|flush} [ to PREFIX ] [ dev DEV ] [ nud STATE ]

Not forgetting IPv6…

I’ve purposely neglected to show any configuration of IPv6 addresses in this post, not because iproute2 can’t handle it, but for the exact opposite reason – the iproute2 suite will handle IPv6 addresses in exactly the same way as IPv4 addresses. All the commands used above can be used for both IPv4 and IPv6 configuration without any issues.

If there’s a reason you want to force the behaviour one way or the other, you can use the -4 and -6 switches. This isn’t needed normally, because when adding or removing an address, for example, iproute2 will happily recognise an IPv6 address instead of an IPv4 one. Where it does come in useful is if you want to limit the data returned in a query to just IPv6, or just IPv4. A real-world example of this is on one of my Linux machines, where ip -6 ro shows:-

[root@daedalus ~]# ip -6 ro
2001:470:XXXX:1::/64 dev eth0  proto kernel  metric 256  mtu 1500
  advmss 1440 hoplimit 0
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440
  hoplimit 0
default via 2001:470:XXXX:1::1 dev eth0  metric 1  mtu 1500 advmss
  1440 hoplimit 0

…which comes in handy if you’re only interested in the IPv6 routing table.

What next?

This post only really scratches the surface of iproute2 – I’ve just covered the iproute2 equivalents of the most-used commands. It’s capable of much, much more, such as setting up tunnels, managing multiple routing tables and configuring interfaces for multicast to name a few. I’ll be covering some of these in more depth in future posts.

Further reading

• The Linux Advanced Routing & Traffic Control HOWTO, which is probably the definitive guide when it comes to iproute2
• iproute2 on Wikipedia
• The Linux Foundation’s iproute2 page

I’m from a UNIX (mostly Linux) background, so I’m more at home using UNIX-alike platforms. That said, there’s a few things that Microsoft do that are particularly useful, and in my opinion AD is one of them (quiet at the back, there). Handily, there’s a project that can marry the two, and it goes by the name of Likewise.

Likewise Enterprise is Likewise Software’s commercial offering, but they also provide an open-source edition in the form of Likewise Open, which is what I’m going to focus on here. Conceptually, using Likewise is equivalent to binding a Windows machine to a domain, and the method of doing it is similar. The code is somewhat related to Samba, so some parts of it may be familiar to anyone who’s meddled around with Samba in any depth.

Starting out

First off, you’ll need the Likewise Open installer, which you can get from here (signup required). Grab the installer for your particular distro or operating system – for this example I’m using a fresh Debian (lenny) GNU/Linux install, but the process is essentially the same for others, such as Solaris. One you’ve got it, installing it is just a matter of running it:-

adtest:~# chmod +x ./LikewiseIdentityServiceOpen-...-linux-i386-deb-installer
adtest:~# ./LikewiseIdentityServiceOpen-...-linux-i386-deb-installer

Follow the prompts, and after a few seconds you’ll be returned to a prompt. Assuming the install completed successfully, in the case of Debian (or Ubuntu), running ‘dpkg -l | grep likewise‘ will show a few new packages have been installed (for RedHat/CentOS, replace ‘dpkg -l‘ with ‘rpm -qa‘).

Before going any further, make sure your resolvers are set up correctly, and that the local machine’s time is synchronised – either against an external NTP source, or one of the domain controllers. You can check that DNS resolution is working correctly by running:-

adtest:~# host test.example.com

…and all being well, you’ll see something like this:-

test.example.com          A     10.1.1.1
test.example.com          A     10.1.2.1

If you’re okay so far, configuring the machine to use AD requires one command:-

adtest:~# /opt/likewise/bin/domainjoin-cli join test.example.com andys

After a few seconds, providing the local machine can see the domain controllers, you should be prompted for your domain password. As when binding a Windows machine to a domain, the account you use must have the right privileges, which usually means that it’s in the Domain Admins group or similar. So:-

Joining to AD Domain:   test.example.com
With Computer DNS Name: adtest.test.example.com

andys@TEST.EXAMPLE.COM's password: <domain password>

…wait a few seconds…

Warning: System restart required
Your system has been configured to authenticate to Active Directory
for the first time. It is recommended that you restart your system
to ensure that all applications recognize the new settings.

SUCCESS

Now, in my experience you don’t strictly need to reboot, however it’s a good idea to, so go ahead and reboot the machine.

The basics

Assuming the box rebooted, we can now test that AD integration is working. Log in, and at a prompt type:-

adtest:~# id TEST\\andys

…replacing ‘TEST\\andys‘ with your domain and username. The double backslash is important, because most UNIX shells use ‘\’ for escaping characters. If you want, you can also use the ‘user@domain‘ syntax. If all is well, you’ll see something like this:-

uid=2096628820(TEST\andys) gid=2096628225(TEST\domain^users)
groups=2096628225(TEST\domain^users),2096628224(TEST\domain^admins)

At this point I should offer a word of caution: Because the machine is now bound to the domain, it means users on the domain can log into it. Obviously this is the whole point, but it’s something to be mindful of, especially if the domain is used by many people.

The UIDs and GIDs may look ridiculously large, but don’t worry – UIDs under most UNIXen are 32-bit, so this will be fine. There’s also a good reason for it – Likewise guarantees that the IDs will be unique and consistent across all machines bound to the same domain. You’ll also notice that the user’s primary group is set to the primary group from AD, which is usually ‘Domain Users‘.

The domainjoin-cli command also makes some changes to /etc/nsswitch.conf and the PAM configuration. On my example Debian box, having a peek at /etc/pam.d/common-auth reveals:-

auth    sufficient    /lib/security/pam_lsass.so
auth    required    pam_unix.so nullok_secure try_first_pass

pam_lsass.so is the PAM shared library for the lsass – or Local Security Authority Subsystem Service – part of Likewise. The example above is simple enough, and accepts domain users, falling back to standard UNIX users if the given username isn’t a domain user.

Making changes

Likewise installs its configuration files in /etc/likewise. The one that’s probably of most interest is lsassd.conf, which controls how the lsass daemon lsassd handles users. Before going into any detail, you’ll notice that lsassd.conf is split into two sections – the first being for domain users (the [auth provider:lsa-activedirectory-provider] section), and the second being for ‘local’ users (under [auth provider:lsa-local-provider]). The local users are usually just ‘COMPUTER\Administrator‘ and ‘COMPUTER\Guest‘ (where COMPUTER is the name of the local machine), and are synonymous to the Administrator and Guest accounts on Windows machines. Chances are you won’t need to touch the local users section, so we can safely ignore it.

There’s quite a few options to play with in lssasd.conf, but the main ones we’re interested in are:-

• login-shell-template, which allows us to set the default shell for domain users. This is (by default) set to /bin/sh, so in many cases you might want to change it to /bin/bash.
• homedir-template, which specifies where domain users’ home directories will be created. The default for this is %H/local/%D/%U, which in our example would expand to /home/local/TEST/andys for my account. Personally, I prefer to drop the ‘local’ bit and use %H/%D/%U, which would change my home directory to /home/TEST/andys.
• require-membership-of, which lets us specify which groups are allowed to authenticate against this machine in a comma-separated list.

It’s important to note that if you use the last option, any domain user which isn’t a member of one of the specified groups will fail any PAM configuration that calls pam_lsass.so. This means that if you wanted to allow certains groups SSH access, whilst allowing a larger set of groups access to FTP, you don’t want to omit the FTP user groups from here. If you’re building this kind of setup, you’ll want to allow all the groups in lsassd.conf, and then build your PAM configuration to conditionally allow access based on group membership using pam_group.

Once you’ve finished making your configuration changes, you’ll need to tell Likewise to reload the configuration:-

adtest:~# /opt/likewise/bin/lw-refresh-configuration
Configuration successfully loaded from disk.

It also doesn’t hurt (and I’ve sometimes found it neccessary) to clear the local AD cache:-

adtest:~# /opt/likewise/bin/lw-ad-cache --delete-all
The cache has been emptied successfully.

…and that’s it! You should now have AD authentication working through PAM.

Useful commands

Likewise installs quite a few tools in /opt/likewise/bin (many of which are symlinks to lw-lsa), some of which come in handy for testing:-

• lw-refresh-configuration, which as mentioned above reloads the lsassd configuration from lsassd.conf.
• lw-ad-cache (also partly mentioned above), which lets us manipulate the local AD cache. For example, lw-ad-cache –enum-users will list the users’ details currently stored in the cache.
• lw-enum-users/lw-enum-groups, which predictably list all the users and groups in the domain.
• lw-get-status, which shows quite a bit of information about the domain itself.

These are just a few, so it’s useful to have a poke about in /opt/likewise/bin and see what there is.

Hints

Because Likewise integrates itself via PAM, pretty much everything which can work with normal UNIX users can cope fine with domain users. For instance:-

• You can use the tilde (~) shortcut to go to a domain user’s home directory, for example cd ~andys@TEST. For some reason, the backslash notation doesn’t work here, and you may also notice that tab completion doesn’t work either.
• With most things, you can refer to domain users as either TEST\\andys, TEST.EXAMPLE.COM\\andys, andys@TEST or andys@TEST.EXAMPLE.COM, including when logging in on the console or via SSH. There are exceptions (such as the previous point), but they’re few and far between.
• Sudo happily works with domain groups – just remember to double-backslash.
• You can use chown and chgrp in the ways you’d normally expect, using either the domain group names, or their GIDs.
• ACLs (under Linux) also work, so if you’ve mounted a partition with the ‘acl‘ option, you can use setfacl as normal.

If it all goes wrong…

Sometimes things go wrong. With Likewise, it’s usually straightforward. If you’re getting errors when binding to the domain with domainjoin-cli, it’s usually because it’s having problems connecting to the domain controller. If your domain controllers are on a different network, check that any firewalls inbetween aren’t dropping SMB traffic. The domainjoin-cli command should give you a definitive list of ports it needs open to communicate with the domain controller.

Once up and running, I’ve found Likewise Open to be very stable, but on the odd occasion that something has gone awry, it’s often enough to just restart the lsassd daemon. Failing that, try emptying the cache (with lw-ad-cache –delete-all). If you’re still getting odd errors, it might be worth checking out the documentation or the forums.

Where to from here?

Because the PAM magic happens with pam_lsass, in theory anything which uses PAM can be made AD-aware. I’ve personally used it with Pure-FTPd to provide company-wide access to an fileserver, and it works flawlessly with gdm, so you can use it on your desktop. Again, because it’s PAM-based, it can be stacked with other modules such as pam_securid (for RSA’s SecurID tokens) or pam_opie (for one-time password sets).

Ironically, one thing that does require a little bit more configuration is Samba – something I’ll cover in a future post.

Update: Yvo van Doorn comments below with a handy hint if you only need access to one domain, which should save on keyboard wear for some users