Saturday, 8 September 2012

Brakes Efficiency Percentages

Last week my '71 Early Bay van failed her MOT on a couple of points (both now rectified and retested - so she's through), one of which was that the parking break efficiency was only 13%. The tester gave me a report showing the figure above, which also showed:

Front Service Brake 38%
Rear Service Brake 27%
Total Service Brake 66%

I was curious about these figures and meant to ask when I went back, but forgot.  Since then I've done a little research, and here's what I found out:

Apparently the percentages are calculated by dividing the total weight of the vehicle (with everything in it) by the force required to stop it (they have a machine to test this at the test centre) and multiplying by 100%.  A little searching on the web revealed that the service brake needs to be at least 50% and parking brake at least 16% for an MOT pass.  However this left me wondering: how much better could they be?

What I found suggested that it's possible to get significantly higher percentages and, surprisingly, to even exceed 100% mark.  Sounds crazy that something can be more than 100% efficient doesn't it?  But consider the way the percentage is calculated and what would happen if you put the brakes from HGV on a moped.  :-)

Unsurprisingly such high efficiencies are not recommended and according to herbie275h on the VZi forum:
normally the limit is reached by the tyres which skid around 85-90% of the vehicle weight
Various Internet sources also suggested that 60-70% is about normal and this sounds quite reasonable to me after finding the following titbit of information that SpunkMoney posted on the motester.co.uk forum:
The Highway Code stopping distances ("A car in good condition, with good brakes in good conditions blah-de-blah-de-blah....") base their actual stopping distance (ie: NOT the reaction part) on a deceleration of 0.66g - that's 66% braking efficiency.
So I guess 70%-ish is what we ought to be aiming for and be happy with.  I guess it also makes sense that the individual front and rear efficiencies will be less, and that the handbrake (which according to herbi275h needs to be enough to hold the vehicle on a 1:6 hill), can be even less than those and still be acceptable.

Thanks also to Samba63 on VZi who pointed me in the direction of SpudMonkey's info.  ;-)

Tuesday, 21 February 2012

GIMP, Inkscape, and X11

For a few years now I've been using GIMP (GNU Image Manipulation Program) to manipulate bitmap images. I wouldn't say I'm an expert and in fact I don't use it that much because most of the time I'll crop and resize image using Preview; which loads up a lot quicker. I only fire up GIMP when I need to do something "fancy". Thus I haven't been too irritated by the fact that GIMP uses key combinations like Ctrl-C and Ctrl-V rather than Apple's Command-C and Command-V. However, I've recently begun to use Inkscape to create vector images and it makes use of the Alt key for quite a number of things... and the Mac's preassigned used of that key gets in the way. Fortunately there's a solution and I found it on the Inkscape FAQ:

Both Inkscape and GIMP make use of the X11, X window system and the FAQ describes the creation of a "keyboard modifier map and keymap table" to get the Alt and Command keys working "correctly". I'm not going to re-post the information here as we can get the details from Inkscape FAQ, however I wanted to create this post as a reminder for myself in case I ever need to set it up on another computer.

If you've found this post then I guess you were looking for a solution to the same problem. Hope it helps. :-)

Friday, 6 August 2010

End Of An Era?

I've done something I thought I'd never do: after just a little over three years of ownership, I've sold my Beetle!

Back in April my wife announced that she was moving to Wales… without me. Ironic given that we'd moved to Norfolk primarily so that she could be closer to her family, but it meant that I needed to find a new place to live. That in turn meant that I had to reconsider the future of my work in (not making very much) progress Beetle project. In truth, I'd been having second thoughts about it for a while.

Okay, so there were issues with not having a garage to work in; so the weather, in addition to my health problems and other work load, meant that I was progressing much slower than anticipated. However there was another, probably bigger problem in that this Beetle restoration lark was not what I'd anticipated:

When I looked into getting the bug I thought that given the length of time these things have been around, I'd be able to buy a book or something that told me what to do with it. As it turns out there are lots of sources of information... but with no real consensus about the best way to go about things. Just search VZi for which oil to use and you'll see that even with something as apparently simple as that, dub owners have to make their own decisions about who and what to believe.

Then there's the situation with parts, because while there's loads of stuff available, I've been astounded by the poor quality. A few months back for example I bought a stock pulley from VHW, and the centre was two millimetres off. TWO! I've had other parts that were equally useless and it would appear that needing to bend, file, re-drill, and generally adjust things to get them to fit is par for the course... and the situation is getting worse:

Having ultimately decided to sell my bug, and the plethora of parts I'd acquired to restore it, (I tried to sell them as a job lot but had no takers), I've made some very good money on the parts. Why? Because when I bought the floor panels, heater channels, rear quarter panels, and other parts that have spent the last couple of years in my shed, it was still possible to buy genuine VW, and mine were. These days they're as rare as hens teeth and I'm told the repro stuff is... erm... poop.

So rather than the Beetle being the big Lego kit with step-by-step instructions that I'd anticipated, it's a big heap of frustration with conflicting opinions about what's best for it, and parts that don't fit well into anything other than a dustbin.

The sale of my Beetle clearly represents the end of an era for me. I'm keeping my van but she's in pretty good condition and provided I protect her she should see me out. But I'm inclined to wonder whether my personal adventure might have also spanned the end of the era in which it was practical / worthwhile to undertake a major restoration.

Sunday, 21 March 2010

The Major Oil Leak That Wasn't

Last November I set off in my van to do a 200 mile trip up to Manchester. However, after 40 miles or so she sprang a major oil leak and I ended up being towed home by the RAC. It's taken me a while to find out and understand what went wrong and it turns out to be an embarrassingly stupid mistake on my part. Rather than keep it to myself however, I thought I'd write it up in some detail, in the hope that it benefits somebody else.



As you can see, my van's engine, like most, is not entirely stock. For one thing it has a progressive carb with a paper air filter, and for another the heating system is not connected up. One of the first things I did when I got my her was to block up the gaping holes in the fan shroud where heater pipes would be attached. Given that the Manchester trip was to be a significantly longer drive than I'd ever done before, I'd decided to attend to a few other things too, including blocking up the holes where said heater pipes, and a stock air filter's warm air intake hose, would go through the rear tinware.

All of the above is as it should be but I'm mentioning it here because it gives context to the mistake that I did make. The fact is that if you look around you'll see a lot of VW engines with these orifices left gaping; and they shouldn't be. The ones in the fan shroud will result in air being blown back into the engine bay rather than being sent to cool the cylinder heads. Gaping holes in the tinware will result in warm air from the lower engine being sucked back into the engine bay.

So what was my mistake?

Well, the oil filler neck has a connection which, on a stock engine, has a hose connecting it to the air filter; thus, you might think, as I did, allowing the crankcase to breathe filtered air. Replace the stock air filter (often done when a non-stock carb is used) and you might not have a place to connect this hose. Have a look at a few dub engines with non-stock carbs and you'll see that the breather on the oil filler neck is often left unconnected to anything. This did not strike me as being a good thing and in my bid to close up 'unnecessary' orifices, I put some tape over it to stop any crud getting in there.

As I discovered later, the crank case is in fact more inclined to breathe out though that tube as it takes air in through a (surprisingly to me) unfiltered opening behind the pulley wheel. The tube on the filler neck connects to the stock air filter not to supply it with filtered air but so that the oily vapour it breaths out goes into the carb; to be burned up in the engine rather than dumping it elsewhere. Block the pipe on the oil filler neck, as I did, and the crank case will breathe its oily breath out behind the pulley wheel. Result: the pulley wheel flings the oil all over the engine bay.

Combine my faux pas in closing that vent with topping up the oil to the max (she always leaks a bit so I expected to lose some on the trip) before I set off and I was all set for the incident that followed. This part of the story is worth telling because it helps to show why it took me a while to find out what went wrong. So, in a nutshell:

I pulled into a service station, smelled oil, and when I went around the back I found that there was oil sprayed all over the back of the vehicle (it must have been hitting the hot engine and vaporising) as well as all over the engine bay. In a bid to save a potentially dry engine I grabbed a can of oil and glugged it in fast. Well, most of it went in. However a good deal didn't so by the time the RAC man arrived there was additional oil, spilled by me, all over the place making things look even worse. It's also important to note (we'll see why shortly) that because I just glugged it in, there was now way too much oil in the engine.

So the RAC man arrives and a can of degreaser and a shed load of paper towels later the engine is somewhat cleaner and we're trying to work out where the oil came from. We drive down the road half a mile and take another look. This is where having glugged too much oil in the engine plays it's part in the story because of course it's immediately been forced out of the vent behind the pulley and thrown all over the engine bay.

Of course we didn't realise at the time that this is what was happening so we conclude that there's a major leak somewhere that we can't see. The greatest concentration of oil seemed to be on top of the tinware over no. 4 cylinder (where I've marked an X on the photo accompanying this post) and as we could see that it wasn't coming from the oil pressure switch or anywhere like that, we figured that the oil cooler was a likely candidate, it being hidden away, up top, on that side of the engine. Given that accessing the oil cooler is an engine out job we concluded that my trip to Manchester wasn't gonna happen and the RAC man towed me home.


I've already explained what the problem turned out to be but it took me several weeks of research to find and piece together the parts of this puzzle.

One of the first things I did was to post the photo shown above on VZi but I felt fairly sure that the oil cooler was the most likely cause of the problem and was kinda distracted by the idea of swapping the engine with the one in my (project) Beetle to get myself back on the road ASAP. So nobody thought to question my diagnosis and it wasn't until a while later, when watching the Bug Me Video on stripping/rebuilding an engine, that I began to realise that oil from the cooler is unlikely to end up on top of that tinware. Of course with hindsight it's obvious why there was a concentration of oil there. Clue: consider the direction in which the pulley wheel rotates and where most of the oil it flings/flicks is going to end up.

My first breakthrough came when I stumbled across some information about a "sand seal". For those who don't know, and to air my new knowledge, this is something that's needed on dune buggies to prevent sand from getting into the crank case through the vent behind the pulley wheel. WHAT? There's a vent behind the pulley wheel?

This in turn lead me to find an article about crankcase ventilation over at
Rob & Dave's Aircooled Volkswagen Pages which pretty much describes the problem. Oh how I wish I'd found that sooner but I have to say that when I did I was sceptical that the amount of mess I'd seen in my engine bay was down to just that. However, having cleaned up my engine, unblocked the breather, and syphoned out a litre of excess oil that I'd glugged in when I panicked, she's working just fine.


Coda:

You can get little "breather filters" (SSP part no AC115551) to go on that filler neck connection. I've heard they can leak oil but they've got to be better than nothing and certainly a hell of a lot better than what I tried. On closer examination however I found that the rectangular filter on top of my carb had a connector for a hose. The filter was fitted with this hidden away around the back; which is why I hadn't seen it before. I've turned it around however there's still an issue in that the most direct path for the hose would be at risk of fouling the fan belt. This would not be the case with a stock filter.

For now I have a long tube, taking a path over the generator and around the back of the carb to connect the breather to the filter. However I'm also investigating other possibilities ranging from returning to a stock set up, to installing twin carbs and a breather box. More about that in a future post.

Sunday, 21 June 2009

Blocking Bots

In previous posts relating to my LAMP server (see tags) I've described how I use PHP to write iptables rules so I can keep various ports closed when I'm not actually using them. Something else I use it for is to block IP addresses from which bad bots are operating. This technique is discussed and documented on various other sites so I'm not going to give details full details here. However, in a nutshell my scheme involves:

1. Using robots.txt to designate a directory into which bots should not go.

2. Inserting hidden links on various documents that link to a file in the above directory. Humans will not see these links (because they are invisible) and well behaved robots (that pay attention to robots.txt) will not follow them either. Thus the only things that will follow those links are bad bots.

3. My hidden links point to a PHP script which write a new iptables rule, thereby blocking the bot. An entry is also made in a database recording the time and request that blocked the bot.

4. Bots will often operate using addresses from pools that are used legitimately at other times, so it's important to release the blocked addresses after a suitable period. I have a cron job to run a script that checks the database and releases anything that has been blocked for longer than a specified period.

This has been working well for some time however more recently I've been seeing something else in my server reports that I wanted to do something about; attempts to access urls such as these:

//Admin//scripts/setup.php
//MyAdmin//scripts/setup.php
//admin//scripts/setup.php
//phpMyAdmin//scripts/setup.php

There's usually a great long list of them trying lots of variations. Something else I've seen quite a bit of is this kind of thing:

/index.php?gzip=0&file=/etc/passwd

Again, the usually attempt the same, or similar things with any .php they can find.

Now provided that all of your other security is in place then attempts such as these shouldn't be a problem however, they are clearly attempts to break into the server. As such whatever is generating them is making a nuisance of itself and should, in my humble opinion, be told to **** off at the first available opportunity. So I've added a few more lines to httpd.conf

RewriteRule scripts/setup.php /var/www/cgi-bin/ip_blocker.php
RewriteCond %{QUERY_STRING} /etc/passwd
RewriteRule ^(.+) /var/www/cgi-bin/ip_blocker.php

The first line looks for urls that contain "scripts/setup.php" and redirects them to my blocking script. Obviously if you use anything on you server where that would be part of a legitimate request you need to modify that, but I don't, so I can use it. The next two lines do a similar redirect on any request where the text "/etc/passwd" appears in the query string.


Note that because I wanted these rules to apply to all of the virtual sites on my server, I've put these rules such that they apply to the main server and told all of the virtual sites to inherit them using:

RewriteOptions inherit

Note however that despite them appearing before the virtual server directives in the httpd.conf file, the virtual server directives are processed first. Thus it is important that none of the virtual server rules end with [F] as this would result in a match there halting the processing of rewrite rules before these are run.

Enjoy, unless you're a bot. ;-)

Sunday, 15 March 2009

Passwords

The issue of 'having a good password' is something that comes up in conversation from time to time although I generally suggest that, even if you think you know you what that means, you should do some research (because things change), I realise that most of my friends won't bother and that it might help of few people, those that can be bothered to read it, if I were to do a write up of my current understanding of what is a good password.

The reason I say 'current understanding', and suggest that things change, is because that is my experience; and I don't just mean my own understanding, but that of the 'industry' as a whole. While there are things that have always been regarded as insecure, there are also lots of things that were regarded as secure but are now regarded as a risk. This is largely because, as the speed of computers has increased, the crackers (people who try to break into systems) have more powerful tools at their disposal. For example I have an old programing book containing code for a 'password generator' that works be randomly choosing a couple of three or four letter words and sticking them together to create a password. These days the crackers use programs that attempt to get in by trying common dictionary words, both forwards, backwards, and stuck together in combinations. These days a password that uses actual dictionary words is regarded as relatively insecure.

A Perfect Password



A perfect password would be a completely random collection of letters, numbers, and punctuation marks. Why? Because if it is truly random then the only way for somebody to crack it is to try every possible combination. This does not mean that such a password is uncrackable; but it means that of all the passwords that we could use, this is the hardest to crack.

So, if we know what a perfect password is, why don't we all use them? And the answer is that we are human and we find them difficult to remember. There's not much point having a great password for your desktop computer if it's written on a post-it note stuck to the monitor; partly because it's could be a security risk and partly because if you lose the bit of paper you are locked out.

The security risk aspect of having a post-it note on your screen depends of course on what the password is for. For example, if I had the root password for my server (at a server farm) written on the side of my monitor at home then the only person who sees it besides me is my wife and I'm pretty confident that she's not interested in hacking my server. The post-it note is inaccessible to a cracker unless they come around to my house and although I am sure there are a whole bunch of folks on the Internet who might like to gain access to my server, I doubt very much that they'll go that far.

Doing The Math



Okay, so I've said that a random collection of characters is best and while that might seem obvious it's worth taking a few moments to consider exactly why that is the case:

If I ask you to pick a letter of the alphabet you have 26 choices. If I ask you to differentiate between upper and lower case that doubles to 52. If I say to include digits then you gain another 10 possibilities giving 62 options. If we add in punctuation marks then we increase it further but I am going to leave them out (I'll explain why later).

So you have 62 options for a single character. Now I ask you for a second character you have 62 choices for that one too. That's 62 options for the first one and 62 options for the second. Thus for our two character 'password' there are 62x62 options (which is 3844 possibilities). Each additional character multiplies the number of possibilities by 62 so by the time we have a 6 character password we have 62x62x62x62x62x62 which is 56,800,235,584 possibilities. Now unless our password happens to be the very last password that a cracker tries, they aren't going to have to try all of them, but with that many possibilities to go at the cracker is going to have to try a hell of a lot, or are they?

Bear in mind that our 56.8 billion possibilities include all possible 6 letter dictionary words, peoples names, and dates of birth. However these will be a relatively small percentage of the total number of options. Just for the fun of it, let's look at dates and let's say that I'm trying to guess your date of birth, wedding anniversary, child's birthday or other 'secret' date that you may have used as a password:

There are 12 months in a year, each of which has a maximum of 31 days. Chances are that your date is within the last 50 years so for a DD-MM-YY date (6 digits) I have 31x12x50 options which is 18600 possibilities. Now that's a lot for a human but a password cracking program could work through them in a matter of minutes.

Add every name and dictionary word, forwards and backwards, into the equation and our cracker program still only has to deal with a tiny fraction of the number of possibilities that it would have to deal with if we use a truly random password. Of course a cracker could write a program to try totally random passwords but they don't need to because many, many people out there will use a name, date, dictionary word or something else and a program that tries these first will give them access to a lot of systems.

How To Remember It



Okay, so now that I've (hopefully) sold you the idea that a password should be random, how do we go about remembering such a password?

Well one option that we already mentioned is to write it down and while there are a lot of cases where this would be a security risk, there are a lot where it is not a problem. I don't have my server password written on a post-it note but I do have a document on my computer that lists a whole bunch of passwords and PIN numbers that I didn't have any choice about and that I don't trust myself to always remember. The file is backed up so there's no chance of me losing it, and it's password protected (with a good password of my own devising) so to get in there a cracker would need to access my computer and crack that password. In other words, it is HIGHLY unlikely, so although the passwords are 'written' down, they are safe. Of course this still leaves me with the problem of how to remember the password that protects the file, and this is where my technique for remembering a random password comes into play, however I now have a confession to make: it isn't random!!!!!

What? Not random? Well, no, but almost. Let me explain:

My wife's name, let's call her Anne, would make a really poor password. First of all because it's only 4 letters and secondly because it's a name. However let's solve the length problem by adding letters from her surname until we have 6. Hell, let's be different and create a 7 letter password. Assuming that our surname is Jones we now have 'AnneJon'.

Now that's still pants as a password and of course if she'd been called Deborah then we wouldn't have needed the extra letters from the surname and it would be even worse. So, to improve things, let's change some of the letters to numbers that look a bit like them such that we get '4nn3J0n'. Now let's reverse it: 'n0J3nn4'.

Immediately it is looking a lot more random however that number swap is a common technique, and so is reversing a word. Plus, a name is a bad starting point in the first place. Clearly this gives us two areas that we can improve on: our seed word and our encryption' technique.

Now we still want to be able to remember this thing so rather than using one seed word, let's use three. Let's say I want a password for my account at Amazon, that my wife's name is Anne Jones and that I was born on the 04/03/64. By converting the site name to upper case and taking a character from each seed in turn we get: AA0Mn4An0Ze3OS6Nm4ith. However, I only want 7 characters so let's take the first 7 (because I can do that in my head without having to write anything down) and I get: AA0Mn4A.

Now that isn't truly random in the sense that it's been generated using two pieces of personal information and a modified (converted to upper case) site name but given the huge number of pieces of information that I could have used as 'seeds' and the huge number of ways in which I could manipulate them, it will be close to impossible for somebody else to guess at. In the example I used the site name, my wife's name, and my date of birth, in that order, and converted the site name to upper case. I could have used my fathers middle name, the registration number of the first car I ever bought, my sister's birthday, the last letter of each word in the first line of the song that was playing when I met my wife, the last 6 digits of my phone number or any number of other pieces of information as seeds. Furthermore I could have 'encrypted' them by reversing them, taking only the first and last letters of the names, using just the odd number letters, omiting vowels, or dozens of other techniques.

The important thing is that rather than using a memorable password I'm using memorable techniques to generate what is to all intents and purposes a random password. If I decide upon a set of seeds and a set of techniques and always use the same ones then I will always know how to generate my passwords. Note that by using the site name (or system name or something that I strongly associate with it) as one of the seeds, I can use the same seeds and my encryption techniques for the others and have different passwords for different sites/systems. Using the scheme above as an example, my password for eBay would be 'EA0Bn4A' and my password from GoogleMail would be 'GA0On4O'. What's more it means that if I register on any forums or shop checkout systems that store member/customer passwords in an unencrypted form, then a malicious person at the company can only see my password for their system; a password that gives them no clue about what I might be using on other systems.

Before we finish, I would just like to step back to my earlier decision to exclude punctuation characters when we were calculating how many possibilities there are for a six character password. Now that I have explained my technique for generating passwords it should be obvious why I did this: because the kind of seeds I suggest don't include punctuation symbols. You could however build in punctuation symbols at the encryption stage. Just in case you are thinking that 56.8 that we calculated before aren't enough.

Domain Names

From time to time I encounter people who need a domain name so I thought I'd share my thinking about choosing one:

Choosing a domain name is like naming a child in that you're as well to give it some very careful consideration because, although it's not impossible to change it again later, it can be rather difficult. In another way however, it's not at all like that because while there are a lot of people called, for example, Andy Slater, there is and can only be, one www.andyslater.com


Things to consider when choosing a domain name:
  1. Availability
    As stated above, every domain name has to be unique so if somebody has already registered the one you'd like, although you may be able to buy it from them for some exorbitant sum, it's probably just a case of hard luck.
    You can find out if a name is available at places like http://www.uk2.net
    On the front page of their site is a box where you can type the domain name that you're interested in registering and click a button to see if it's available. Chances are that your first choice won't be so be prepared for some disappointment and for some considerable time spent thinking up alternatives.
    Please note that if you are planning to ask me to host your website on my server that the whole thing is a lot easier if your domain name is registered via UK2 but please contact me before jumping in.

  2. www.
    Pretty much all domain names start with www. so you don't need to worry about that bit.

  3. .com? .co.uk? .net? .info?
    The bit at the end is called the extension and there are various different ones available. However:

    1. .com is the one that's best known. If people can't remember your extension, .com will probably be the first one they'll try so it's well worth having.

    2. Search engine results show your domain name including the extension. If you've ever used a search engine to find something you want to buy then you'll be aware that much of the time you end up looking at shops in the USA. Amongst the results however you will see sites that have a .co.uk extension and this is a valuable clue that the site is based in the UK. When I'm shopping, I make a beeline for the ones with a .co.uk extension. Thus if you are selling to the UK market, a .co.uk extension can be a bonus.

    There are many other extensions available. Check UK2 as described above for a list of what they have i.e. those available in the UK (you will see other country specific extensions when you're browsing which have to be registered in those countries). However, unless you have a good reason for using something other than .com or .co.uk, I'd stick with those. For a business I'd be inclined to want both.

  4. Name Length
    Short names are best. eBay, Amazon, Google, etc. Short and snappy. I used to run a business from a site called www.themodelmakersresource.co.uk and found that the domain name was too long to fit on till receipts, too long to get printed onto pens for promotional purposes, etc, etc. Doh!

  5. Hyphens and Underscores
    You can't use spaces in domain names but you can use hypens and underscores. If your desired name contains more than one word you could therefore:

    1. Join all the words together: www.themodelmakersresource.co.uk

    2. Use hypens: www.the-modelmakers-resource.co.uk

    3. Use underscores: www.the_modelmakers_resource.co.uk

    Although I said you could use underscores, I recommend that you don't. It's not common practice and is bound to cause confusion; people will mistake them for hypens and spaces.
    Note also that for business purposes it's probably wise to obtain all variants. You can for example access Games Workshop's site with:
    www.gamesworkshop.com
    www.games-workshop.com
    www.gamesworkshop.co.uk
    www.games-workshop.co.uk
    Smart move guys. Note however that eBay, Amazon, Google (businesses that were Internet businesses from day 1) and the like only need half as many domain names to cover all the options. Even smarter.

  6. Memorability
    My experience with The Model Makers Resource has shown me that on the web, unless you can become a household name, you're at the mercy of the search engines if you want people to 'stumble' across your site. Obviously the more memorable your name, the better your chances of people coming straight back to you rather than heading for the search engines. The Model Makers Resource Ltd is too long and clumsy for most folks to remember. There's also an issue about whether "model makers" should be one word, two words, or hyphenated and arguing that your choice is correct according to the dictionary is of little value if potential customers are failing to reach you because they are typing it in wrong.
    It is strange, but it is a fact that I would often hear people outside my shop saying "Oh look, The Model Makers Resource Centre". The sign did NOT have the word 'centre' anywhere on it but for some reason people just seemed to add it on the end. What chance have they got of remembering the domain name if they can't even read the company name off the sign above the shop window correctly?
    It's a bad name and more 'field testing' would have told me that before I invested in it.

  7. Spelling
    If you're a business, having a name that's easy to remember has to be a smart move. Even if you're not a business, obscure spellings, or things that people have difficulty in spelling, are best avoided. Choosing something that you have to explain or spell out every time you tell someone your domain name over the phone is a bad move. Choose something such that when you tell people your domain name, their first guess at how to spell it will be correct.

  8. Keywords
    'Keywords' are words that people type into search engines when they are looking for something. Having a keyword in your domain name can enhance it's position on the list (it's ranking). Perhaps more important, the search engines are fickle after all, is the fact that your domain name is displayed and can be used to say something about you.
    When I was setting up The Model Makers Resource, having the word 'model' in the name was on my list of priorities. Part of the trouble I had finding a domain name was that the word 'model' can be used in more than one context. You've got model kits, catwalk models, data modelling, model citizens and a huge range of other things. As a result, pretty much every domain name I though of was already in use. I did find one short one, models-uk, uk-models or something like that; however, all of the other 'variants' were taken up by competitors, model agencies and in one case a rather nasty porn site. I decided to steer clear.
    If you can slip a keyword into your name it's certainly worth considering but I believe that there are more important issues, as listed above, and I wouldn't compromise them for the sake of inserting a keyword.
    At the end of the day, Boots (the chemists) don't seem to have suffered from having an inappropriate name although one is inclined to wonder what ever became of Mr Chemist the cobbler?


That's about all I want to say on the subject of choosing a domain name. Hopefully you'll find some of it useful. Hopefully I haven't scared you off the idea of having a website altogether. The things above are things to CONSIDER. You don't have to comply with all or even any of it. If you're wanting a website for fun then you can probably ignore most of what I've said. The same is true if you wanted a website to which you can direct people as a means of answering a question that somebody has asked you. If your site is for business and you will want people to be able to find it and remember it without your jotting the name on a bit of paper for the, then the more of the above that you can take into consideration, the better.

HTML Special Characters

This document used to live on one of my websites however it doesn't really fit in there any more. I still need it though, so I've moved it here.

For the benefit of those who don't know, HTML special character codes are codes that you can use when writing HTML content and the exist for a number of reasons:
  1. Some characters don't appear on the keyboard. Special character codes provide a means of entering them.

  2. Some characters, the greater-than character for example, have a special meaning in HTML. If you want a browser to display those character rather than trying to interpret them as the part of an HTML tag, you need to use the special character code.

  3. Some characters are language and/or character set dependent (currency symbols being a good example). You need a way to force the viewers browser to display the correct character. Special character codes provide a way of doing this.

The list below is far from complete. There are many more codes to define all kinds of symbols and foreign characters with accents, umlauts and the like. The following list however shows the codes that I use the most frequently.

CodeCharacterDescription
&&ampersand
&lt;<less-than sign
&gt;>greater-than sign
&nbsp;nonbreaking space
&pound;£pound sterling
&euro;€euro
&copy;©copyright
&trade;™trademark sign
&reg;®registered trademark
&deg;°degree sign
&plusmn;±plus or minus
&sup2;²superscript two
&sup3;³superscript three
&frac14;¼one-quarter
&frac12;½one-half
&frac34;¾three-quarters
&times;×multiplication sign
&divide;÷division sign

Monday, 31 December 2007

A Brief Safari

I used Safari briefly when I first got my MacBook and also had a dabble with Camino. However I was used to Firefox from my PC days and, more importantly, had been finding FireFTP (an FTP plug-in for Firefox) very useful so I switched back to Firefox. In recent times however I've been using Webmin when I need to upload/download files to/from my servers and haven't used FireFTP in quite a long time. In fact I've shut down the FTP service on my servers as mentioned previously. I've also noticed lately that of the various pieces of software that I use, Firefox is the one that's most likely to lock up such that I have to force it to quit. (Audacity comes in second - but I don't use it nearly as much - and GIMP just bombs out occasionally when I'm rotating images). Given that Apple also claims that Safari 3 is faster than the fox I thought that maybe it was time to give it another try.

Issue number 1 was how to move all my bookmarks from Firefox to Safari but this turns out to be relatively simple. Safari's File menu has an Import Bookmarks option and although I had to search around a bit to find this out, all you need to do is navigate to Firefox's bookmarks file at
~/Library/Application Support/Firefox/Profiles/xxxxxx.default/bookmarks.html
and the job is pretty much done. At the same time I deleted most of the US biased crap that Safari had loaded by default. Grrr.

Issue number 2 was the lack of a "New Tab" button. Apple-T works as a short-cut but when I'm browsing then my hands are more likely to be on the mouse than the keyboard so the lack of a button is, to my mind, a real oversight on Apple's part.

Issue number 3: If you click on a link then under 'normal' circumstances it will open in the current window/tab. You can configure Safari such that holding down the Apple key when you click will open it as a new tab. However if the web site's author has set the link to open in a new 'window' using the target tag, that's exactly what Safari will do: open a new window. Firefox gives you the ability to force such links to open as a new tab. Safari doesn't so unless you happened to be pressing the Apple key at the same time, you end up with a new window. Grrr.

Issue number 4 is the Google search box up there on the toolbar. Now while Firefox merely defaults to Google.com but allows you to use other search engines, Safari doesn't give you any choice at all! According to what I've read on the web, this is all about money. It hadn't occurred to me before but it's fairly obvious when you think about it that sooner or later, anybody manufacturing a half decent browser with access to several search engines is going to be offered a few quid by one of them to have theirs at the top of the list.

Now while whatever arrangement Apple and Google have come to is, I'm sure, all very nice for them, it's a bit of a bummer for us. As a matter of fact I do use Google most of the time but I like to use Google.CO.UK not Google.COM and the current set up won't even let me change that. I also use Wikipedia fairly regularly and while it generally comes up with a high rank on most Google searches, that isn't really the point. Putting Google.co.uk and Wikipedia links on the bookmarks bar is probably the easiest option however, as the Customise Toolbar option presents the URL box and Search mechanism as a single entity you're pretty much forced to leave it there as a constant reminder that it's there for Google's benefit and bollocks to the rest of us. Grr.

I began to look for other options and found details of a couple of hacks (which may or may not work with version 3) for changing the search engine, and also for converting the New Bookmark button into a New Tab option, however both involved messing with the Safari code in ways that didn't appeal. Over on macupdate I found AcidSearch 0.7b4 and Safari Enhancer 3.3.1 which looked promising. The latter even offers a new tab button but on closer inspection I realised that neither of them supports version 3 of Safari. Doh!

By this point I was getting a little cheesed off with the whole thing and had pretty much decided that I was going to switch back to Firefox. Along the way however I had noticed Inquisitor 3. I hadn't paid much attention as it describes itself as "Spotlight for the Web", thus making it sound far in excess of what I was looking for. However I had already begun to draft this blog entry (so that in 6 weeks time I could remind myself why I was still using Firefox), and I figured I'd give Inquisitor a quick try for the sake of completeness.

My initial impressions of were good and if the search is your only major gripe about Safari then I suggest you check it out. However it still isn't as quick 'n' easy as the one on Firefox.

Additionally:

1. I like the error console on Firefox which has proved extremely useful on a number of occasions for solving problems with Javascript (Safari doesn't appear to have one).

2. The "View Source" option on Firefox has a nicer display. Not something I use a lot but it comes in handy.

3. I also like the Firefox option to switch off styling and get some idea of what a page looks like to a bot or a text reader.

Okay, so maybe I'm being a bit petty now, but add those niggles to my earlier gripes and it probably won't come as any great surprise when I tell you that the Safari icon is no longer in my dock and that I'm finishing off this post in Firefox.

I guess I could try Internet Explorer instead.

Ha ha.
Ha ha ha.
Ha ha ha ha ha ha ha.

Wednesday, 31 October 2007

Nobody (A Halloween Story)

A slight detour from my usual subject matter today because The Goldfish has cajoled me into writing a 'spooky' story for JackP's Halloween Story Collection. So, if you are seated comfortably, we shall begin:


It came as no surprise to Alan that nobody met him at the school gate. For a short while after mummy went to live with the angels, daddy had come instead. But life had to go on they said and he was a big boy now. Daddy had to go back to work and Grandpa John lived only just around the corner. Too far for his old legs, but near enough for a big boy like Alan to walk there on his own.

So nobody took Alan's hand at the gates and enquired about his day in school. Alan forgot to count the cedar trees at the side of the road and recalled the day's events while walking to the place where it was safe to cross. Nobody watched over him as he looked right and left, and right again, before going straight across the road.

Just a little further along, and around the corner, and there was Grandpa John looking our from the window of his house. The door was open before Alan had opened the gate and run up the garden path, and as Grandpa John welcomed him in Alan turned and waved good bye.

"See you tomorrow" he shouted.

Grandpa John looked out to the empty street. "Who are you calling to?" he asked.

"Oh, nobody" Alan replied.

Friday, 12 October 2007

Starter Motor Bush Puller

I remember my friend Tex commenting that my father "wasn't a bodger". An odd thing to say and while it wasn't a compliment, it wasn't an insult either. Merely an observation.

You see my father, in his capacity as a bench joiner had amassed an extensive collection of tools. Some of them sat in cupboards and drawers for years on end between uses however when they were used, having the right tool for the job made a world of difference. Not having the right tool, on the very rare occasions that it happened, was an intense source of frustration to him.

Tex on the other hand, though also a joiner, made his living going out and about fixing things. His need to be mobile meant that he could only carry a relatively small number of tools and he often found himself having to use things for purposes other than the one for which they were strictly intended, and having to implement less than perfect solutions in order to just get the job done - or "bodging" as he called it.

The reason this comment, which was made some 15 years ago, came to mind is that I have just installed a new starter motor in my Bay, and while the removal of the various nuts and bolts went a lot easier than I expected, the bush seemed determined to stay firmly in the clutch housing.

Not wanting to damage anything, I abandoned the job overnight in order to post on VZi asking how to remove it. Moby5153 came to my assistance as he has done before and pointed out that there's a special tool available for the job, or that I could tap into it with an M12 tap.

I didn't have an M12 tap but as the bush is copper, a high tensile M12 bolt did the job quite nicely, tapping into it and then pushing the bush out as the bolt made contact with the clutch housing. The new starter motor is now in place and all seems well.

Now, while this might be the first starter motor bush I've ever had to deal with, I dare say it won't be my last so I'm looking at that special tool in the VW Heritage catalogue and thinking that perhaps I should add the 40 quid item to my shopping list. Thus I find myself with miniature versions of my father and Tex sitting on my shoulders like angel and demon (although I'm not sure which is which), with my father reassuring me that it'll be 40 quid well spent, and Tex shaking his head in despair.

Monday, 8 October 2007

Red 9 Design EZRider - Shocks

It's taken me a couple of days longer to post this than I expected. Damned CFS. However:

In my previous post I explained my reasons for purchasing Red 9 Design's EZRider kit and my thoughts regarding the safety concerns expressed by some. In this post I'll describe what I've installed so far, namely the shocks/dampers (which I will refer to as "shocks" from here on).

The EZ Rider kit consists of 2 elements:

The first is a pair of metal bars that replace the torsion bars. These are metal rods with the necessary dimples machined into them and swivelling ends that will allow the trailing arms to pivot freely.

The second element is a pair of Spax coil over shocks.

In order to lower a van from stock height you need the rods in place or the torsion bars will continue to determine it's height, however as my intention was to raise a van that had been lowered too far it occurred to me that the shocks alone might do it. Given that they were going to be easier to fit than the rods I decided to try them on their own first and see what happened.

The only problem I encountered in fitting the shocks was that the bushes in the lower end of the dampers wouldn't go onto the spindles. I didn't measure it but we're talking about maybe a thousandth of an inch too tight, two at most. Given that this was an issue with the shocks I decided to phone Spax as opposed to Red 9 Design and they suggested, given that it was such a small amount, that I check there was no rubber fouling things and if there wasn't then maybe making the hole in the bushes a little bigger. There was no problem with rubber and I found that a 12mm drill went snugly thought the bushes. Running the drill backwards and forwards a few time removed a tiny amount of metal after which they went snugly onto the spindles. Everything was easy after that and it was unnecessary to compress the springs.

Before moving on to the results I'd just like to mention an interesting aspect of the phone call to Spax: while talking to them I found out that these shocks are made especially for Red 9, to their specification. Given that I was wanting to raise my van and was speculating that the shocks alone may be enough to do, I had wondered whether the purchase of a pair of coil over shocks alone might be enough. Indeed I asked VWHeritage about using their GAZ coil over shocks for this purpose however they doubted that their springs would be powerful enough to actually raise the van. I didn't fancy gambling 200 quid on something that might not work. Better I thought to pay 320 for something that WILL work even if it turns out that I don't need the entire kit.

So how about the results?

Here she is before:



and after the shocks were fitted:



As you can see she's now about 2.5" higher at the front than she was before; which is just what I wanted because I now have about 4.5" inches of ground clearance under the low points on the beam.

She still has low profile tyres on the front and although I'll leave them in place for now I'll change them to something bigger when they need changing. That'll take her up about another half an inch however at that point I might use the adjustments on the coils to bring her down half an inch, maybe a full inch.

She is actually about an inch higher at the front than she is at the back now but I'd like to take her up an inch at the back. At the moment you have to deflate the tyres to get them out from under the rear arches. Going up an inch will remove that hassle.

As for the ride, I can't really say at the moment. To be honest it doesn't feel much different but:

1. I haven't driven her much since doing it.

2. I haven't fitted the torsion bar replacements.

3. I haven't touched the adjustment screws on the shocks.

I'll report back on the ride in a few weeks time. By then I'll have done a few more journeys and will have Dee's opinion too. Up until now she's been complaining that if I couldn't improve it she'd have to invest in some sports bras so we'll have to see how the ol' bounceometers rate it now. I may also have twiddled with the adjusters (on the shocks, not on the bounceometers).

What I do about the torsion bars is another issue. As I said before, if I were lowering the van I'd have to swap them but given what I'm doing I can't really see much point. As I understand it, it can't improve my ride as her height is already being governed by the springs on the shocks i.e. the torsion bars ain't doin' nuffin' guv. The rubber seals on the ball joints are fubar (torn up, I've been told, as a consequence of her being lowered to much) so maybe I'll swap the bars when I deal with those rubbers. Maybe not. I haven't decided yet. At the moment I'm just chuffed that I don't have to worry about scraping the beam on every little bump in the road.

Friday, 5 October 2007

Raisin' Up The Van

My van is too low. The previous owner lowered it as much as he could and even put low profile tyres on the front. I guess there must be no bumps in the road where he lives because I managed to scrape the low points of the front beam on the ground within my first week of ownership, and not on an obviously bumpy road either.

Raising her up a bit should have been simple given that there are adjusters on the beam however when I tried to move them, they wouldn't budge. I posted about it on earlybay.com and took her to a local-ish VW garage. The conclusion is that the installation of the adjusters was probably botched such that the internal collar has been locked in place by excessive weld penetration. The garage said they could fix it by removing them and fitting new ones at a cost of 250 quid.

At about this time, somebody posted on earlybay.com asking if anybody had any experience of the EZRider kit from Red 9 Design, thereby bringing the product to my attention. This is essentially a system for lowering a bus or bug by effectively doing away with the torsion bars and installing coil over shocks. It occurred to me that if the torsion bars were made redundant then my stuck adjusters would no longer be an issue and although the kit was 320 quid, Red 9 reckon that their kit gives a much better ride than a standard lowering job.

The idea of making an improvement rather than just a fix appealed to me however opinions about the kit seem to vary. The aforementioned thread on earlybay.com quickly turned into a discussion about safety rather than ride quality. A number of posters, and some mechanics that I've asked about it, point out that the damper mountings were not designed for this purpose. On the other hand, Red 9 Design have been making these items for several years now and there don't seem to have ever been any problems. I checked with my insurance company (Adrian Flux) and they had no concerns or warnings about it and all of the doubters on the forums seemed to be simply that i.e. doubters. I could not find, and I checked several forums, a single instance of anybody having had a problem with the Red 9 kit.

The main concern regarding safety seemed to be what would happen if the mounting failed however Red 9 are also able to supply lowered bump stops at an additional 47.50 per pair. I figure that having them in place is a reasonable safety precaution and added them to my shopping list. As a matter of fact I received the kit a few days ago and I fitted some of the kit today. I'll describe what I did, and report on the effect it's had, in my next post.

Friday, 21 September 2007

Fireflex Installation (Bay)

Apparently old VW engines have a tendency to catch fire!

I don't know if there's something about the design that makes them more prone to this than other vehicles or whether it's just an age thing. Whatever the reason, regular checks to make sure that the fuel lines are in good condition and carrying an extinguisher should be considered mandatory. I've already been doing both since day one, however today I took things a stage further and fitted an automatic extinguisher into the engine compartment of my Bay.

Automatic extinguishers consist of a pressurised bottle of gas, foam, or powder to which is attached a length of 'hose'. In a nutshell, you clip the hose around the engine bay and, in the event of a fire, the hose ruptures spraying the contents of the bottle all over the fire.

There are a number of decisions to be made before you buy:

1. Gas, foam or powder.

2. 0.5kg or 1.0kg bottle.

3. Horizontal or Vertical mounting for the bottle.

I initially purchased a 0.5kg upright gas bottle from VW Heritage but after seeing it for real I decided to use that one in my Bug (where I can easily mount it to the firewall) and bought a horizontal version for my Bay. In both cases I went for the 0.5kg bottle because I've been assured that it's plenty for use in the confines of the engine compartment in a Bug or a Bay. I went for gas because I liked the idea that there would be no additional clean up required as a result of it being activated. We discussed this on earlybay.com where some folks suggested that foam would also be a relatively easy clean up and less prone to dissipation. Their argument was that gas would disperse after putting out the fire which could then reignite. The counter argument is that the vehicle would have stopped by then and although there may still be fuel present, the source of ignition would have been removed (the heat of the engine is insufficient to cause petrol vapour to auto-ignite - it needs a spark).

Having made my choice the next job was to fit it. As I said, I originally purchased a vertical bottle but although there is plenty of space in the Bay's engine compartment there are not many suitable vertical mounting points. On the other hand there are plenty or opportunites for horizontal mounting, including the roof of the compartment.

The roof is covered with hardboard, which has holes in it, and glass fibre insulation behind above that. The hardboard is fixed to an arrangement of beams which support the metal floor of the luggage compartment above.

Now I have seen bays with the hardboard and glass fibre removed and although I don't like the idea of hardboard in the engine bay, I figure that it's been doing it's job of keeping noise and heat out of the interior for the last 36 years so why remove it now?

My reason for mentioning it at all is that I figured that one of the beams to which the hardboard is attached would make a good mounting for the extinguisher bottle. You can tell where the beams are by looking at the fixing points for the hardboard and if you look at the floor of the luggage area you'll also see where they are spot welded.

The image below shows the roof of my engine compartment with a pencil line drawn between two of the fixings in preparation for drilling holes for the extinguisher bracket.



Holes were drilled and self tapping screws used to fix the bracket in place. Then, after clipping the cylinder in place and tightening the large cable tie (supplied) I moved on to the job of fixing the hose.

I'm not the first person to write on the web about installing one of these things and if you look around you'll find that everybody, and I do mean EVERYBODY, who has ever done so says that there are not enough cable ties supplied with the kit. Why the manufacturer has not taken notice and put a few more into the kit I can't imagine. I can't accept that doubling the number included would seriously affect their profitability however, forewarned is forearmed: get some more cable ties because you will need them.

As far as the installation in my Bay was concerned that hardboard ceiling with it's pattern of holes was a blessing because it gave me loads of places to attach the ties without having to drill holes or attach sticky pads. Given that I'd made sure I had extra ties available it was no big deal when I decided that some were in the wrong place. I also made a point of attaching them loosely at first so I could slide the hose around until I was completely happy with the layout. As you can see from the final picture I spiralled the hose over the engine i.e. around the area where a fire is most likely to break out.

Monday, 20 August 2007

Panel Van - Day 1

If you're in the UK and reading this within a short time the date on which I'm writing, then you will be well aware of how unhelpful the weather has been recently, and given that I have no garage, you will understand why I've made little progress with the Beetle. My server and MacBook are doing nicely, hence the recent lack of blog entries, however another factor with the Beetle is that I still haven't managed to get my hands on a replacement heater channel for the right hand side. VWHeritage have been telling me that "we should have some in a week or two" for a couple of months now however I'm inclined to stick with them a) because they've given me good service on all the other stuff I've needed and b) that if they have none I reckon my chances of finding one anywhere else are probably so low as to make it hardly worth looking.

The relevance of the right hand heater channel, given that it's the left hand side of the car that failed the MOT, is that the one on the car has been welded to the floorpan by a previous owner. Thus I cannot lift the body to sort out the left hand side without also replacing the right hand side. The Beetle is therefore off the road until I get that heater channel and although there are things that I could have been getting on with, on the odd days when it hasn't been raining, I've been more inspired to work on erecting a summer house Dee and I can now sit 'in the garden' enjoy the English summer without getting wet.

However, faced with the prospect of being grounded for an as yet unknown length of time I began to look for alternative solutions, and when my dear old dad announced that a savings policy had matured and that he'd like to by me a prezzy, like another car maybe?

Now while I wouldn't really want another car, even as a stop gap, it is a fact that when I was reading through all those back issues of VolksWorld magazine as part of my research for buying the Beetle, I also found myself looking at vans and wondering about the advantages of such a vehicle. I'll post more about it later but the bottom line is this:



i.e. I now own a 1971 Bay Panel Van as well as a 1969 Beetle.

Sunday, 15 July 2007

Look Ma: No Engine!

I took my engine out for the first time yesterday. It's not that hard actually but don't tell Dee because she's under the impression that my voice is a little deeper and my underwear a little less roomy today.

Vol 3 of Bug Me Videos shows how to do it but Rick fails to mention what to do when you're up to your elbow trying to undo one of the top nuts that hold the engine into the car and your other arm gets attacked by the world's most determined horse-fly. The little bastard had me dancing all around the garden trying to escape it before I eventually managed to clap my gloved hands on it - a shame really because in my new found masculinity I might have mounted it's head on a plaque in the hall had it been in one piece.

Another small problem was that the same top nut was a little reluctant to come all the way off the bolt. It came far enough that the head of the bolt would release from it's locked position and turn with the spanner. Most irritating, but with my right hand reaching up through the wheel arch to push the bolt back and my left hand on the spanner I eventually got it loose.

The final problem of the day was the when I came to lower the engine onto the dolly that I got from VW Heritage and discovered that the wheels of my 3-tonne jack were too wide to go between the wheels of the dolly. It hadn't occurred to me to check. Luckily the rear valance on my bug is bolted into place as opposed to being welded so I didn't need to raise the car up as much as Rick does in the video before pulling the engine back and was able to use my 2-tonne jack to lower the engine the necessary few inches onto the dolly.



At this point I was able to remove the louvered panel attached to my firewall and unclip the wiring that runs behind it. Although that was mission accomplished (the whole reason for doing it was that I needed to get to those wires) I obviously had a good look around and while I was at it I found the bits shown below inside the clutch/flywheel housing on a little ledge next to the gear from the starter motor:



Obviously I was shocked because no way should there be any bits of loose metal flying about in there and judging by the little marks on the inside of the casing, they had indeed been flying around at some point. I posted about it on VZi and Moby5153 identified the clips as being transit clips for the clutch pressure plate that should have be removed after clutch installation. I already had evidence that the garage who fitted the engine didn't really know what they were doing and this merely compounds it.

As for how the hell a spade connector got in there...

Friday, 13 July 2007

Rust Sandwiches

Although I've made a number of posts relating to my research and planning, I haven't said much about the actual work in progress on my Beetle. Alas things are not going too well. Bad health, bad weather, and a need for out of stock parts have all played their part in delaying things however the largest factor has been that I keep discovering even more bits that need replacing.



I knew when I bought her that the left hand heater channel was in poor condition. I was quite pleased with myself at the time for spotting it because it wasn't glaringly obvious and in a matter of weeks, I'd gone from knowing almost nothing about cars to knowing enough about Beetles to spot it. However I failed to spot that during a previous repair, the heater channel had been welded to the floor pan. It's really obvious when you see it but I just didn't notice and the fact is that it's the same on the right hand side meant that both sides looked the same and didn't alert me to it.

That in itself is not a huge problem but in the process of removing the left hand heater channel and floor pan half I've also come to realise that the corner of the front-head base-plate is rotted away, along with the end of the front chassis support, where they bolt to the heater channel. At the back, the outer part of the rear cross member is rotten and there were so many bad areas lurking beneath thick layers of underseal in the rear wheel arch (covered by glued on carpet on the inside) that it probably makes more sense to replace the rear quarter rather than repair it.

Now while all of that is possible, it would be a heck of a lot easier with the body off. However, while I've got replacement floor pans for both sides and a new heater channel for the left hand side, the heater channel for the right hand side is out of stock. Remember that the one on my car is welded to the floorpan and you'll relised that I can't get the body off and make the car roadworthy again before I get my hands on a new right hand heater channel.

Vol 7 of the Bug Me Videos shows them removing a heater channel in one piece, and while that makes a lot of sense for demo purposes (and let's face it the new one is going to have to go in in one piece) it's not necessarily the most practical way to do it if there are 'unknowns'. I've already said that mine was welded to the floorpan but in the video they say that there are no welds along the top of the channel where it meets the front wheel arch on the inside of the car; just spotwelds on the outside. There clearly was a weld on the inside of mine and things became even more interesting when I started to cut it out. It turned out that there were four, yes four, layers of metal.

On top of the original, rusted to bits, heater channel was a patch. Presumably this had also started to rust at the bottom at some point because there was another patch on top of that, and another patch on top of that.

Now that I've got it out of there I can see that the bottom part of the front wheel arch also has a patch on the outside, plus a patch on the inside, and the original rusted piece of metal is sandwiched between the two. Clearly that's going to need replacing too.

Apparently there's a saying in VW circles about having replaced the bottom six inches of the car. I seem to be discovering what that means.

Tuesday, 3 July 2007

Opening Ports With PHP

In my previous post I described how I'd set up iptables. The important thing to note about that is that I set my default INPUT policy to DROP anything that isn't specifically accepted by a rule. This means that I can easily open and close ports using the iptables command to add or delete rules. For example, the following can be used to open the port for webmin:

/sbin/iptables -A INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT


I can then close it again by deleting the rule with:

/sbin/iptables -D INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT


Note that:

1. Webmin is always running, and listening, even when the port is closed, so I don't have to issue commands to start and stop it. I just need to open and close the port.

2. I don't have to leave the rule in place for the entire session as the commands above allow and disallow NEW sessions. Other rules in my iptables setup allow established sessions to continue. (Although in fact Webmin tends to stop and start the session as you use different elements of it so it's as well to leave the port open until you are done.)

3. The iptables command can only be used by root.


Now I'd like to be able to do the same thing with SSH but of course there's a catch: if I close port 22 then I can't SSH in to issue the command to open it. Don't get caught out by that one!

However, as mentioned in a previous post, my intention was to use a secret backdoor by getting one of my .php web pages to watch out for a special input and use exec() to run the iptables command. However there is a catch here also: the PHP script runs as apache but the iptables command can only be run by root.


Now there are a couple of ways around this and what I've chosen to do is to use the sudo command. This allows a user to run a command as another user however they have to be given permission in the /etc/sudoers file. I did this by adding the following line to the file (using visudo to edit it - as it tells you that you must in the file itself).

apache ALL = (root) NOPASSWD: /sbin/iptables


This gives apache the ability to run the iptables command without the need for a passwork. Shock! Horror! Isn't that a security problem?

Well, not really, the addition allows apache to run iptables, and that's it, nothing else. It's also important to realise that on my server, you cannot log in as apache, and in fact I am the only user allowed to log into my server at all. I am also the only person who can upload .php files to my server so I am the only person who could install a .php script that uses exec to run iptables as apache. Now even if somebody else did figure out a way to get around that, 'all' they would have achieved is the ability to open and close ports. They'd still need to crack other passwords before they could do anything useful/nasty. Furthermore, the instructions being issued to iptables are reported in my Logwatch report so I'd be made aware of it.

Of course if you don't have the luxury of being the only person who needs access to your server then you may be better to consider another approach. For example you could use your php script to create a file or change a setting in a database to act as a flag for a cron job. You would then create a cron job, which you set to run every couple of minutes, to check the flag and run the iptables command when the flag is set. The downside of course is that after setting the flag you have to wait for the cron job to run before you can get in. The upside is that apache no longer needs the ability to run the iptables command. Apache just sets the flag and the cron job (which you run as root) issues the iptables command.

Incidentally, there's a heap of info about the sudoers file available by typing 'man sudoers' at the Linux command line with loads of examples down at the bottom of the man page. Check it out and you will see that you have a heck of a lot of control over what you do and do not allow sudo to be used for. Given the various other restrictions on my server, I'm happy to allow apache to use sudo to run iptables and can therefore use the following PHP to open and close a port for SSH when I tell it to:


// create an iptables rule to allow access on port 22
exec('/usr/bin/sudo /sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT')

// delete the iptables rule to allow access on port 22
exec('/usr/bin/sudo /sbin/iptables -D INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT')


Note that my iptables setup (as I described a my previous post) is such that port 22 is open when my server boots, and I leave it that way.

Under normal circumstances, after rebooting the server, I would tell my PHP script to close port 22 and would then leave it closed when I'm not using it. However, I leave it so that the default after a reboot is to have it open. This means that if something should go wrong such that I can no longer access my PHP script to open the port (which I would need to do to change the PHP script), I can get it open again by requesting a reboot.

Watch out for this:



Perhaps the biggest headache that I had in setting this up was that initially I couldn't 'sudo' via exec(). I spent hours looking for the problem and it was driving me crazy because everything I found on the subject indicated that what I was doing was absolutely spot on. The breakthough came when it was suggested that I try this:

echo exec('/usr/bin/sudo /usr/bin/whoami 2>&1');


The result should be 'root' but what I got, courtesy of the bit on the end, was this: 'sudo: sorry, you must have a tty to run sudo'

A search on that told me that the issue related to a setting in /etc/sudoers which is used in Fedora Core 6 namely:

Defaults requiretty


I didn't get entirely to the bottom of why it's there. Something to do with there being circumstances when the password you are entering for sudo can be visible on the screen. Apparently it's a new thing in FC6 and all the advice I saw suggested that the solution was to comment it out (which leaves me wondering if that setting will still be present in FC7). Either way, I'm using sudo in such a way that I'm not typing a password so I don't see that it's an issue.

Monday, 2 July 2007

iptables

iptables is something that I've steered clear of until recently. Partly because it looks blooming complicated (and why bother when scripts such as system-config-securitylevel will set up a firewall without getting involved in the nitty-gritty), but also for fear of locking myself out of the server (which is 100+ miles away at a server farm and doesn't have a screen and keyboard attached). When I became interested in port-knocking however, it seemed that the time had come to do a little research.

The first bit of good news came when I discovered that you can 'mess' with iptables without making the changes permanent. When the server boots and iptables sets up the firewall, it loads rules from /etc/sysconfig/iptables however you can then change those rules from the linux command line using the iptables command. In fact you can create a script to delete the current rules and load a new set. The crucial thing here is that you do not edit /etc/sysconfig/iptables directly. Firstly because it's 'system generated' and secondly because if things go wrong, you can reinstate the original set of rules by rebooting the server. While I can't get physical access to my server, there's a mechanism by which I can request a reboot. Of course when you have a set of rules that work you will want the server to use them when it boots and you do this by issuing the following command causing the rules that are currently in memory to be written to the /etc/sysconfig/iptables file:

service iptables save


Safe in the knowledge that we can dabble, it's time to look at creating the script that will install our rules. The first three lines look like this:


#!/bin/sh
/sbin/iptables --flush
/sbin/iptables --delete-chain


Obviously the first line starts our shell. The next two lines clear out any existing iptables rules and user defined chains (of rules) that are currently in memory.

iptables works by looking at packets that are wanting to cross the firewall. These could be packets coming into the computer from the network, going from the computer out to the network, or being forwarded (if the computer is also being used as a router). Because of this it is normal for a set of iptables rules to start with a set of default policies such as:


/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT


I've seen examples sets that work on the basis of accepting anything that doesn't get blocked by a later rule, and I've seen others that block everything unless it's accepted by a later rule. I've gone for a mixture. Nothing comes in unless a later rule allows it. My server is not being used as a router so all packets for forwarding are dropped. All outgoing packets are allowed.

It might seem odd that you would want to do anything other than allow all outgoing packets however in a scenario where the computer is allowing a number of machines on a LAN to connect to a WAN, you may want to implement restrictions.

The next thing is to set up the loopback interface:


/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT


This allows local traffic such that daemons running on our computer can send packets to other daemons running on our computer via the firewall. Stricly speaking, we only need the first of the above lines in our script because our default policy for output already allows outgoing packets from our daemons.

With the default policies set up and our daemons able to talk to each other, our computer can see out, but nothing can see in. If this were a home computer being used to access the web, we could stop right here, however I'm creating rules for a web server and there's no point having a server if nothing can access it.

Before we create a few rules to open things up, it's important to understand that we can split and packets reaching the interface into one of two groups: those initiating a connection, and those that are part of an established connection. This simplifies things because we can allow packets for established connections to pass through unhindered because we already did all our checks before we allowed the initial connection.


/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


The first line says that all new TCP connections must start with a SYN packet i.e. that they must start properly. The second line says that packets for established or related connections are allowed through. If we stop there then we will still be blocking all input because we haven't allowed anything to establish a new connection yet.


/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT


The three lines above allow new connections by accepting packets coming in on ports 22, 25, and 80 i.e. SSH, SMTP and HTTP. Note that this does not mean that anybody can connect via SSH. The still have to be on the list of allowed users and they have to know a password. The above simply means that the port it 'open' such that it is possible to connect.

We're almost done now although there are lots of other things that could be done with our rules and that you will see in other suggested iptables setup scripts. Sometimes you may need other ports open and sometimes you may want to do things like blocking traffic from IP addresses that are being a nuisance. You can also do things like locking out an IP (for a period of time) that has made more than a given number of connection attempts in a given amount of time. In a later post I'll describe describe a technique that I've implemented to greatly enhance the security of my server using iptables rules but in the meantime I want to make just one final addition:


/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT


This accepts incomming type 8 ICMP messages and allows people to ping the server. If this were a desktop computer from which I wanted to issue the traceroute command then I should also allow type 11 ICMP messages. However it isn't, so I won't, and our final script looks like this:


#!/bin/sh

# Flush old rules, old custom chains
/sbin/iptables --flush
/sbin/iptables --delete-chain

# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

# Enable free use of loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Accept inbound TCP packets
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT


Of course the final steps are to save our script, make it executable, and run it as root. We then need to check that everything works as we expect. Most especially that we can still initiate new SSH connections to our server. When we are happy we use the 'system iptables save' command to write our configuration to /etc/config/iptables and we're done.

Sunday, 1 July 2007

Thinking About Port Knocking

In a previous post I described how I'd tweaked my server's security with respect to SSH and Webmin however I really wanted to make it more difficult for a potential abuser to get anywhere near them. I also wanted, if possible, to rid my Logwatch reports of the hundreds (sometimes thousands) of lines reporting failed attempts to log in via SSH.

Using a non-standard port for these services is a commonly suggested 'solution' but while this may throw most of the current crop of bots off the scent, any half-serious hacker can easily do a port scan first. You can also be fairly certain that if the bots aren't currently doing a preliminary scan, it's only a matter of time before they will. Thus using a non-standard port is little more than a temporary side-stepping of the problem. Should you opt to try it, don't forget to open the new port in your firewall first or you'll lock yourself out of your server.

Secure Authentication - setting things up so that your computer authenticates itself to the server rather than logging in with a password - means you can then disable the ability to make connection by logging in with a password and this is very cool option so long as you don't find yourself away from home, needing to log into your server from another machine, and without your authentication keys on a memory stick.

Other solutions that I've seen use programs like fail2ban or denyhosts to scan logs and act upon what they find. Typically they'll scan the logs at a 20 minute intervals and block any IP address that has tried and failed to log in more than a specified number of times. As I see it, the problems with this type of approach is that you'll still see numerous attempts taking place because the IP address isn't blocked until the log scan takes place.

pam_abl, an addition to PAM, looks for repeated failures to log in and if a given IP address fails more than X times in Y seconds, it gets banned. This has a more immediate effect however the info I saw suggested that the bans were permanent and that's not what I want. Any defence mechanism that blocks IP addresses should also ensure that they are unblocked a short while later because if the attacker is logged into the web via an IP addess allocated from a pool at AOL or attacking via a hacked server, then you could end up blocking legitimate traffic when the address has been reallocated, or the server being sorted out. I guess using a cron job to unblock them would be an option.

Port knocking - a scheme by which you have to 'knock' on a number of prespecified ports in a set sequence in order to open another port - had an immediate appeal because the knock cab be carried out with something as commonly available as Telnet so getting access while away from your normal machine merely requires that you remember the port numbers. Wikipedia has a good article on port knocking with links to an article explaining how to do it using iptables (although you need to have the ipt_recent module loaded to do it).

However, while discussion port knocking over at the Fedora project forums (click here to see the topic), sej7278 suggested that you could use something on a webpage to trigger the opening an closing of a port. Further to that it occurred to me that you could use a url that was normally used for something else. For example, if the front page of my site were:

http://www.luntaticatics.com/index.php

I could use:

http://www.luntaticatics.com/index.php?open_port=22

to open SSH. All I'd need to do is to make the index.php script look for the additional parameters and use exec() to issue the command to open the port.

I'll explain how that works in a later post however for now I would just like to say to any crackers who may be reading this:

1. The front page of my site is not index.php and I'm not using a page at lunaticantics.com so you'll have to start by guessing the name an location of the .php file that I'm using. Note that there's no reason for the page to be linked into the rest of the site so you'll have to guess.

2. I wouldn't be so stupid as to use something as simple as open_port=22 and publish it here. So if you do manage to find the .php file, you'll need to guess what parameters are needed to trigger it. Note that there's no need for the parameter name and value to make any sense to anybody or anything other than myself and the .php script that's watching for it.

3. Probably your best bet for finding the above to monitor the network traffic to my server but even if you do find it, you will then need to figure out my SSH user login name, password, and root password (as described in my earlier post you can't just log in as root), and any failed attempts will be show up in my Logwatch report thus alerting me that you've found my port opener, and prompting me to change it.