Working Notes – Page 12 – More Zonkyness

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

Reconfigure Exim by sending it a HUP signal.
Check the paniclog file to make sure it is still running.
Run through a manual submission of a mail through the SMTP interface.
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 :-

Don’t panic. Just because it won’t boot doesn’t mean everything is lost.
Write down the error message exactly as it appears on screen. A small mistake here can make searching for the error almost impossible.
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.
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.
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.

Password Security & Cracking ‘Em

Computing, Security, Working Notes No Responses »

Sep 182011

This blog entry is of the form of some working notes to help me get to grips with this area of security. Would welcome corrections!

There are two basic forms of password cracking :-

Brute force cracking where every possible password combination is tried.
Dictionary cracking where the password cracker uses a list of possible passwords to try … and optionally some algorithms for varying each word in the dictionary.

I’m more interested in brute force cracking for now, so I’ll just say a few words about dictionary cracking …

Password Hashes

Some people are under the mistaken impression that it is possible to protect against password cracking by preventing multiple login attempts – try to login more than 5 times in a minute, and the account is locked.

People trying to break into systems know about this of course, so they rarely if ever try it (the exception is multiple attempts against equipment that does not perform account lockouts). What they do is obtain the encrypted password in some way – grabbing the /etc/shadow file from a Unix system, dumping Windows password hashes, etc.

Once you have a password hash, or a number of password hashes, it is possible to attempt to crack the passwords. Not by trying to reverse the password encryption – that should be impossible, but by using the same algorithm for encrypting the password in the first place.

For instance if someone sets their password to “bad”, the password hash that gets stored in ActiveDirectory or in a Unix system’s /etc/shadow file may look something like “bae60998ffe4923b131e3d6e4c19993e” (actually it won’t but we’ll gloss over that detail for now). The password cracker starts encoding 1 character passwords, moving onto all possible 2 character passwords, 3, etc.

Eventually he or she finds one that matches that “hash” at which point they will have the account’s password.

Dictionary Cracking

Brute force password cracking has historically been thought of as too computationally intensive to try, so people resorted to restricting the amount of passwords to search through by observing that most people use either simple words, or words made slightly more obscure through some method.

For example, the following are some passwords picked from a list of frequently found passwords (but before getting smug about your password being nowhere near as this simple, you may want to check first) :-

password
letmein
xxxxxxxx
qwerty
123456

In addition, people often take a simple word like “monday” and make it more complex by replacing certain letters with digits – l33t speak – so “monday” becomes “m0nday”. There is no point to this at all – it is one of the most common algorithms for supplementing a dictionary. Similarly adding digits to the end of a word, etc.

Brute Force Cracking

The option of brute force cracking is the process of going through every single password combination and trying each one in turn. This would seem to be a very slow process, but computers are becoming quicker and quicker. For example, with a GPU password cracker, my workstation can tackle around 380 million passwords a second … and it is not an especially quick GPU!

As to how fast password cracking could be today, it is hard to say … some of the more interesting hardware out there doesn’t come with benchmarks, and there’s some guesswork involved. But it is probably safe to say that nothing quite comes up to the 100 billion password attempts a second mark … yet.

It is relatively easy to calculate the number of possible passwords for any particular length … take the size of the character set used in the password, which can usually be assumed to be 96 (all ASCII without the control set) and raise to the power of the length of the password.

Length	Passwords	Time (380M/s)	Time (100 billion/s)
2	9216	<1s	<1s
3	884736	<1s	<1s
4	84934656	0.2s	<1s
5	8153726976	23s	<1s
6	782757789696	37m	8s
7	7.5E13	59h	12m
8	7.2E15	5725h	20h
9	6.9E17	62 years	1916h
10	6.6E19	6035 years	20 years
11	6.4E21	577,845 years	2028 years
12	6.1E23	55473145 years	193297 years

There are several points to learn from this table :-

The numbers of passwords gets very large very quickly. But not quickly enough to keep up with password crackers.
Any password of less than 7 characters is trivial to crack … even with relatively modest hardware.
Any password of less than 9 characters is trivial to crack if you have access to a large network of machines to work with.
If you want to be safe for another decade or so (and policies can last quite a while), you will probably want to pick 12 characters as the minimum password length.
These are the times to search the whole password space … it is not necessary to search through every single possible password to find the password you are looking for. That password might be found in 1/10 of the maximum time, or 3/4 of the maximum time. As long as the person generating the password has not been spectacularly dumb, it will still take a significant proportion of the total time to find the password.

If you look at the different brute force password cracking software out there, it quickly becomes apparent that there are simplistic password crackers that attempt each password combination in turn, and there are more sophisticated password crackers that attempt to tackle the most likely password combinations first. They do this by looking at passwords consisting of words, parts of words, pronounceable sequences that could be words, etc.

However good they are, all they do is increase the likelihood of obtaining the password in less than the maximum time. And possibly not by very much; let’s be generous and suppose that an intelligent brute force password cracker can produce the password on average after processing 25% of the possible passwords rather than 50% of the possible passwords. So for example for a 10 character password, an intelligent brute force password grabber could be expected to find the password after 1,500 years rather than 3,000 years (with a worst case scenario of 6,000 years in either case) … helpful, but not enough to make password cracking practical for 10 character passwords.

Poor Passwords

Everyone is obsessed with telling everyone what makes a strong password, so there’s no need for me to do likewise. But here’s my thoughts on what makes a weak password :-

Contains a single word in any language however it may have been deformed.
Common sequences of digits (i.e. “31415926”) or letters (“qwerty”) … they are effectively the same as words and appear in dictionaries of words to try for dictionary attacks.
Where letters have been changed into digits is no stronger than the password with the letters would have been – the classic “monday” -> “m0nday”.
Appending simple digits or symbols.
Anything short; an otherwise strong password is weak if it is too short (less than 10 characters; preferably 12).

In fact the list of what makes a password weak is so long that it’s always a good idea to test how strong your password is. Preferably with a hacking tool; and not with one of those web forms where they probably don’t test too well to avoid irritating potential customers.

Passwords Suck!

Ha! Yes you’re right … passwords are now a pretty poor way of demonstrating identity. However whilst there are many alternatives, none are universal so until someone comes up with a suitable replacement we are kind of stuck with them.

Older Entries Newer Entries