Adventures in Cisco IOS Land: A Route For “Unknown” Internal Networks

 Cisco, Computing, Working Notes  No Responses »
Jan 262013
 

First defining the problem. Let us say that I have a network with plenty of space for subnets (perhaps 10/8) and I am only using a very small number of the possible subnets – for this example, perhaps 10.0/16, 10.1/16, 10.2/16. What happens when I ping something like 10.52.1.3? Or perform a network scan of 10/8 ?

Well logically if a packet is destined for an unknown network, it will get routed to the default gateway (or “gateway of last resort” in Cisco’s rather gloomy terminology). Given that in most cases, the default gateway is going to be pointed in your ISP’s direction, this is probably not a sensible choice. In most circumstances it probably doesn’t matter, but there are a number of scenarios where it could be an issue :-

  • If the default gateway thinks that the route to 10/8 is back down to the router, then you’ll have packets bouncing back and forth for a while. This may not be a major issue … or it could be if someone tries to flood all your unknown networks as quick as possible.
  • Your default gateway could be a firewall of some kind which helpfully blocks such packets itself. However it may also helpfully log all these in your log files as problems which unhelpfully conceals other issues. You do inspect your log files, don’t you?

There are quite possibly other problems I cannot think of on a lazy Saturday, but it’s also the case that preventing packets destined for unknown packets leaking is the right thing to do.

So how to do it ? With a static route of course :-

conf t
> ip route 10.0.0.0 255.0.0.0 Null0 254
> ipv6 route 2001:db8:beef::/48 Null0 254

The choice of the device Null0 is a bit problematic; it should really be a “device” that returns a ICMP destination unreachable immediately. However it’s better than nothing.

The choice of the “metric” 254 (or “administrative distance”) is specifically chosen to allow any other route learnt by any mechanism to overrule this route.

Having a route to Null0 that covers all your internal subnets may seem alarming, but it seems to work – at least for my network. It is also documented that routing will choose the most specific route in preference to the least specific route – or in other words a route to 10.0/16 is used in preference to the route to 10/8.

Of course if some Cisco routing guru comes along, I’d be more than willing to be corrected. I’ve also tried to check this against Cisco’s “routing for dummies” document.

Getting Started With Awesome

 Computing, Linux, Working Notes  No Responses »
Dec 312012
 

This has been updated for Awesome 3.5

I have long been interested in tiling window managers, which would seem to offer the flexibility I crave. But switching is painful when you want your machine to be as functional as much as possible. On at least two occasions I have switched … and very quickly switched back when problems were encountered.

So just for the fun of it, I have decided to give it another go … in a way that can be gradually worked into functionality.

But first, what exactly is a tiling window manager? Well a conventional window manager works with overlapping windows where windows can stack on top of each other and overlap. A tiling window manager on the other hand uses tiling to maximise the size of every displayed window.

Or in other words, if you want to make the maximum use of space on your screen, a stacking window manager usually asks you to manually move and resize windows yourself whereas a tiling window manager does it all automatically. Although with a tiling window manager, you will need to rotate amongst different tiling layouts to suit.

Tiling window managers tend to be keyboard driven rather than mouse driven, but this is merely an aspect of their implementation.

A Testing Environment

The key to setting up any window manager gradually over time without losing an existing working environment, is to create a separate display which a new window manager can control. This can be quite easily accomplished with a nesting X server, which is provided by the xserver-xephyr package.

As to the choice of window manager, the title of this post gives away the secret – Awesome. Of course the same method works for other window managers too.

The first step is to install the required packages :-

sudo apt-get install xserver-xephyr awesome awesome-extra

The next step is to create a simple shell script to start the nested X server. This basically starts the nested X server with a sensible screen size, and sets the $DISPLAY environment variable so that any further X programs are directed to communicate with the nested X server. The nested X server simply starts up as a standard window within which Awesome operates. The script looks like :-

#!/bin/sh

Xephyr -ac -reset -screen 1280x1000 :1 &
export DISPLAY=:1.0
sleep 5
awesome --config ~/src/site/etc/awesome/config.lua

The sleep command in there is to wait until X has settled down before trying to manage it … without this, it is possible that awesome will fail to open the display (on a slower laptop it worked without; on a faster desktop it did not). The parameter to awesome is to set the preferred location for the configuration file (which I will describe next), although you can leave it out to use the default.

Don’t start it yet! Before doing that, copy the default configuration file to the specified location so you have something to work with :-

cp /etc/xdg/awesome/rc.lua ~/src/site/etc/awesome/config.lua

It’s All In The Repository

The custom configuration file I specified just happens to point to a directory and file within the working copy of a Subversion repository. Using a repository for configuration files has all sorts of benefits; not least of which is to reverse “poor” choices made along the way. Whilst describing how to get one set up is beyond the purpose of this post, it is well worth doing.

Of course if you are working with a repository, it is important to remember to commit changes at every stage :-

% svn add ~/src/site/etc/awesome 
A         /home/mike/src/site/etc/awesome
A         /home/mike/src/site/etc/awesome/config.lua
% svn commit ~/src/site/etc/awesome -m "Awesome: Initial Configuration from default"
Adding         src/site/etc/awesome
Adding         src/site/etc/awesome/config.lua
Transmitting file data .
Committed revision 166.

I won’t be documenting every single commit, but they are all in there!

It is also helpful (at this stage) to create a symlink between the default configuration directory (~/.config/awesome) and the working copy of your repository. The configuration directory can probably be changed, but one thing at a time!

Status Bar Size

One of the annoyances I remember from the last time I played with Awesome, was the tiny size of the status bar. It is all very well maximising the size of the main screen area, but some of us have high resolution screens and tired old eyes! Within the config.lua file (or whatever you named your file), look for :-

mywibox[s] = awful.wibox({ position = "top", screen = s})

And change it to add a height parameter :-

mywibox[s] = awful.wibox({ position = "top", screen = s, height=32 })

The exact choice of size is of course down to personal preferences! However changing the size also means changing the font would be wise :-

awesome.font = "LMSans10 10"

Making the font too much larger will result in some display oddities … at least for now.

Adding A Title Bar

In theory, there is no need for a title bar with a tiling window manager, but I guess I am a little too conventional as a window without a title bar still looks a little weird to me. Plus my shell prompts stick useful bits of information into the window title bar and I would really rather hang on to that extra information. Still, drawing title bars on windows turns out to be really simple … just find the existing code to do so and :-

local titlebars_enabled = true

Some appearance tweaks and indeed messing around with the unnecessarily large number of buttons could be usefully accomplished, but for now this is fine.

 

Themes

Of course messing around with the appearance of a window manager is probably best dealt with using themes (if they are supported). The default configuration file I worked with included enabling beautiful via :-

require("beautiful")
beautiful.init("/usr/share/awesome/themes/default/theme.lua")

It is easier to tinker with themes with a configuration file you can edit, so I copied this theme.lua to the configuration directory named as default-theme.lua, and changed the configuration :-

-- beautiful.init("/usr/share/awesome/themes/default/theme.lua")
beautiful.init(awful.util.getdir("config") .. "/default-theme.lua")

I also removed the previous section’s font setting and set the same font within the new configuration file :-

theme.font = "LMSans10 10"

To cope with the larger font, I also increased the width of each menu item :-

theme.menu_width  = "300"

Although this width does depend on having an appropriately sized screen, and not having too many levels to your menu (if it gets too wide, the extra levels don’t appear neatly).

And finally I commented out the command used to set the background … having a background image for a tiling window manager (which is designed to utilise the whole screen) is a touch unnecessary. And I don’t particularly like the default image :-

--theme.wallpaper_cmd = ...

For now I will leave the colours alone … the defaults may not be perfect but are not sufficiently irritating to spend time on right now. But the details of how to change colours of various components can be found in the theme file we have created.

Disabling Layouts

Personally I believe that you can have too much of a good thing, and choosing between the rather large number of different possible layouts that Awesome makes available is one of those. To reduce the number of possibilities, simply comment out some of the possibilities when setting the “layouts” variable in the configuration file :-

layouts =
{
    awful.layout.suit.floating,
    awful.layout.suit.tile,
    --awful.layout.suit.tile.left,
    --awful.layout.suit.tile.bottom,
    --awful.layout.suit.tile.top,
    awful.layout.suit.fair,
    --awful.layout.suit.fair.horizontal,
    awful.layout.suit.spiral,
    --awful.layout.suit.spiral.dwindle,
    awful.layout.suit.max,
    --awful.layout.suit.max.fullscreen,
    --awful.layout.suit.magnifier
}

Which you command out does not matter so much, and indeed you may very well change you mind at a later point.

A Menu

Whilst the menu built into Awesome has undoubtedly many advantages, I already have a somewhat adequate menu built up over years that relies on myGtkMenu. Whilst changing this menu could well be sensible, it does also seem sensible to keep it around during the transitional period. To do so is simply a matter of replacing certain bindings :-

 -- {{{ Mouse bindings
 root.buttons(awful.util.table.join(
-    awful.button({ }, 3, function () mymainmenu:toggle() end),
+    --awful.button({ }, 3, function () mymainmenu:toggle() end),
+    awful.button({ }, 3, function () awful.util.spawn("/opt/bin/myGtkMenu /home/mike/lib/root.menu") end),
     awful.button({ }, 4, awful.tag.viewnext),
     awful.button({ }, 5, awful.tag.viewprev)
 ))

If you hadn’t guessed, I’ve started using diffs to show the changes where it makes sense; if you cannot read diffs, this page is probably not for you.

That bit replaces the root window, but not the status bar menu :-

 mylauncher = awful.widget.launcher({ image = image(beautiful.awesome_icon),
-                                     menu = mymainmenu })
+--                                     menu = mymainmenu })
+                                       command = "/opt/bin/myGtkMenu /home/mike/lib/root.menu" })

My own menu has some issues in that it doesn’t yet have anything to control awesome itself. But is good enough to get started with.

Final Word … Or Not!

And that is it! Or at least it is enough to be getting on with.

Debian: Booting Floppy Images

 Working Notes  No Responses »
Oct 152012
 

It is very convenient to be able to boot floppy disk images or CD images directly from Grub without having to write the images to their associated media … not least because floppy disk drives are getting quite long in the tooth. And in fact I haven’t had a floppy disk drive installed for a while now. As it happens it is very easy to do :-

sudo zsh
apt-get install grub-imageboot
mkdir /boot/images
# Move any images (CD or floppy) to /boot/images
# With either the extension .img (for floppies) or .iso (for CDs)
update-grub2

… and if you use this to update your BIOS, it is worth writing down all the key settings before upgrading!

Exim: Setting Up A Smarthost Router With SMTP AUTH

 Working Notes  No Responses »
Mar 072012
 

When I discovered that yet again a certain ISP had blocked my ISP’s smarthost (grr … hotmail), I needed to come up with something for my server’s Exim configuration to automatically route mail through an alternative route. For various reasons I wanted only specific domains to be routed through this domain (I run this other server and it is kind of handy to have an independent mail server that isn’t dependant on it).

This is a slightly unusual setup for Exim.

I started off with setting up a couple of authenticators so that once everything else worked, Exim could actually login :-

myloginMD5:
  driver = cram_md5
  public_name = CRAM-MD5
  client_name = USERNAME
  client_secret = PASSWORD
myloginPLAIN:
  driver = plaintext
  public_name = PLAIN
  client_send = ^USERNAME^PASSWORD

At this point, you have a secret in your configuration file, so protect it! There also seems no obvious way to use particular authenticators with particular servers … not to say that this is impossible (it’s hard to find something to do with mail that is impossible with Exim), but I didn’t see a method to do this.

The next step is to run through your test procedure when making changes. Mine was :-

  1. Reconfigure Exim by sending it a HUP signal.
  2. Check the paniclog file to make sure it is still running.
  3. Run through a manual submission of a mail through the SMTP interface.
  4. Check the main log file to see it worked as expected.

And if you need help running through that test procedure, this would probably be a good time to read up a good deal more about Exim as you probably should not be doing this until you understand a little more.

You don’t really need two authenticators here – you just need one authenticator that matches that offered by the SMTP servers you plan to authenticate to.

The next step is to modify the SMTP driver. Search for the string “driver = smtp”, and change it to look like :-

remote_smtp:
  driver = smtp
  hosts_require_auth = LIST-OF-HOSTS
  hosts_require_tls = LIST-OF-HOSTS

What we are doing here is using the normal driver with two extra options that come into play for the list of hosts (colon separated of course) – one that requires that authentication be used, and another that requires that TLS be used.

The next step of course is to run through the test procedure again.

The final step is to create a new “smarthost” router that applies for a specified list of domains :-

smarthostplusauth:
  # Deal with SMTP hosts but specifically through an authenticated SMTP server
  driver = manualroute
  domains = LIST-OF-DOMAINS
  transport = remote_smtp
  route_list = * "server1::587 : server2::587"

This of course applies to only emails that matches your list of domains. If it gets used, the mail is routed through either of “server1” or “server2” on port 587. I used two servers in here, so that Exim would happily deal with a server that was unresponsive, but you might prefer to use a single server.

And of course it’s time to run through the test procedure again.

 

grub rescue Error : the symbol ‘grub_xputs’ not found.

 Linux, Working Notes  No Responses »
Oct 202011
 

So there I was, installing a Linux distribution on my new laptop. Got to the end of the installation when it refused to install grub in the master boot record. Opted to try another partition, and rebooted. At which point the infamous error “Error: the symbol ‘grub_xputs’ not found” was shown with a “grub rescue” prompt.

At which point I had a laptop that wouldn’t boot of course.

To cut a long story short, because it’s only the fix I’m interested in recording for posterity, I sorted this out by booting off an emergency USB stick (unetbootin is a good tool for writing one … if you have a working system). Once booted, I setup an environment where chroot would function well. This is basically where you start a shell whose root directory is a directory under the normal root directory. This allows commands to be run almost as if the non-bootable system was booted.

mount /dev/sda5 /mnt # Mount the root filesystem of the unbootable system under /mnt
mount /dev/sda1 /mnt/boot # And the /boot filesystem
mount -o bind /proc /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
chroot /mnt

Once that is done, there are quite a few things that can be done to repair a broken system, but I just needed to re-install grub to the MBR of /dev/sda :-

grub-install /dev/sda

Once that was done, everything booted fine.

Of course all that comes with the experience of a lot of time with Linux. Those who have not used it since the 1990s will not be as lucky, but there’s a few key points there :-

  1. Don’t panic. Just because it won’t boot doesn’t mean everything is lost.
  2. Write down the error message exactly as it appears on screen. A small mistake here can make searching for the error almost impossible.
  3. Get a rescue USB stick. Ideally before you break a system, but afterwards is usually possible even if you don’t have another working system – you have friends, or there are ways to write a USB stick at work.
  4. Search the Internet for the problem. You may have to spend quite a while reading other people’s problems that may or may not relate to your problem. You may have to improve your search methodology. Putting the error message in quotes is usually a good method.
  5. And if you find a solution to your problem online, check the date of the solution. Something that worked 5 years ago may not be the best solution today. And that applies to this page just as much as any other.
Oh! And to those who would jump and down screaming about this wouldn’t happen with Windows or OSX, please grow up. Such problems occur with any operating system – and I’ve seen them.
 Older Entries  Newer Entries