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.
Monday 31 December 2007
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.
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.
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.
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.
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.
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.
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...
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.
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:
I can then close it again by deleting the rule with:
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).
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:
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.
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:
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:
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.
/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:
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:
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:
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:
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.
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.
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:
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:
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.
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.
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.
Tuesday 19 June 2007
Thoughts About Paint
Car paint is pretty tough stuff and readily stands up to the range of temperatures and humidities thrown at it by our British weather. The reason that paintwork needs maintenance is because it gets chipped, scratched, and defecated upon by birds (which, if you judge by the effects of their excrement, live on a diet of battery acid and paint strippper). Thus we need to repair damaged paintwork before rust takes a hold on the metal beneath.
Maintaining paintwork would be easy if we were happy to just rub off (note that any wax and dirt should be removed BEFORE you start with the abrasives) the damaged paint, and any rust, and blob on a couple of coats of paint. So why the hell are we so hung up on the idea that a car has to have a super-smooth, high-gloss, paint job that's a really pain in the ass to achieve and even harder to repair? Metallics are even more difficult to patch up, and even more popular!
Of course this is really good for the manufacturers because it means that most people simply won't bother, the car will rot, and the owner will be back to buy a shiny new one a heck of a lot sooner than if maintenance of old one had been easier. Given that maintainability is my number one priority with the ol' bug I'm determined not to go down that route. On the other hand, the rat look isn't to my taste either so I needed an alternative solution. Thus I began to consider things like camouflage and other patterns that would allow me to divide the surface a the car into smaller areas.
To be honest, the Beetle isn't that difficult to divide into small areas. All four wings can be unbolted. Hood, decklid and doors can all be removed or treated seperately. However, as I don't have a garage or suitable shed in which to paint panels and will have to work outside, dealing with areas of this size would still be very difficult. It's also the case that no matter how hard you try to match them, newly painted panels tend to look different to the others.
Having considered lot's of different patterns I've decided upon a cubist inspired (check out Picasso's analytical cubist works) pattern of rectangles and shapes in shades of pinky blue. Here's a mock up that I did on the computer:
I intend to apply the paint with a brush because it will be easier to get the effect that I want and using a variety of shades means that I won't be tied to any particular colour that may prove difficult and/or expensive to obtain at a later date.
Note that the patterns will not hide the shape of the car as much as they do in the mock-up because they'll be following the curves of the surface. I'll also be doing the painting a bit at a time, so the pattern will gradually spread accross the car, rather than trying to do it all at one.
Having come up with a plan for the outside/top of the car, I also needed a plan for the rest and in fact it's the other areas that are more prone to rust. While water runs off the exterior of the car it can get into cavities and get's held onto the underside of the car in a mud poultice. When rust does begin to form, the porous nature of the rust means that it holds moisture thus furthering to rot. Clearly this is something I want to prevent.
The first thing I've done is to buy a can of Weld-Thru Zinc Rich Primer Aerosol from Frost and I'll be applying this to all cleaned up metal that I intend to weld.
The next thing is that I've bought tins of smooth black and smooth silver Hammerite paint for use on underbody areas including wheel arches and steering/suspension components. I'll may also be use some other colours under and inside the car before I install carpet and such.
Now I've heard a lot of criticism of Hammerite but it strikes me that most of the problems are caused because people don't use it correctly. Many years ago I used it on with a wrought iron gate and was disappointed to find that the gate started to rust again a couple of months later. It was only afterwards that I realised just how many mistakes I'd made:
Firstly, I cleaned the loose rust off the workpiece. But more than that, I'd cleaned it back to bright shiny metal. I had failed to realised that Hammerite paint is designed to bond to rust. If you're painting bright shiny metal, you should be be using Hammerite Anti-Rust Primer and not the 'normal' Hammerite paint.
Then I shook the tin. This was also a mistake because it introduces air which takes a long time to come out of something as thick as Hammerite. Hammerite, unlike Mr Bond's martinis, should be stirred and NOT shaken.
Then I set about painting by dipping my brush into the tin. Wrong again as this will contaminate the paint in the can as you move the brush from workpiece to can. What you should do is to pour the paint you intend to use into another container and if there is any left over it should be discarded and NOT returned to the tin.
Then I left it to dry overnight and applied a second coat the following day. It seems I really was determined to screw this up because, for it to do it's job, you MUST apply a second coat of Hammerite within four hours of the first such that it does all the chemical bond stuff that it needs to do in order to work. Leave it for more than four hours you're just wasting your time because the second coat won't 'react' with the first coat.
As I say, I've seen a lot of criticism of Hammerite, and the critics generally advocate alternative products that are harder to find and are generally somewhat more expensive. Having done a bit of research, I'm inclined to believe that the main reason that people have any more success with these 'more exotic' products is that they read the instructions and follow them whereas they assume they can use Hammerite like ordinary paint. Hammerite is NOT like ordinary paint and if you treat as such, you will fail to achieve the desired result.
Note that I've chosen to go for the smooth finished stuff (as opposed to the hammered effect) because I want to be able to inspect it for damage on a regular basis and it'll be easier to spot stone chips and the like on a smooth finish.
While Hammerite should protect the areas where I can apply it with a brush, spraying it into cavities seems a bit hit and miss. On the other hand, products like Waxoyl and Dinitrol are designed for the purpose. These products can also be use to apply a waxy coating the underside of the car.
Bitumen based products are another option for 'undersealing' however the are frowned upon in car restoration circles. In this case I am inclined to agree as it seems that the problem with the bitument based products is that they tend to harden with age and that when they get damaged, water gets behind them, and the metal rots away out of sight behind the coating. Of course the only way to check for this would be by scraping the stuff off, and of course removing something to see whether it's still doing it's job properly is undesireable.
It strikes me that the same is true for the wax based products, many of which are brown or black. How are you supposed to tell if that uneven black/brown surface is still doing it's job or hiding rot? Thus my plan is not to use underbody seal but to paint these areas with Hammerite which I can then inspect and maintain. It has been suggested that I could use 'clear' Waxoyl however I am told that this is really a light brown/yellow colour as opposed to clear and it also presents the additional problem of having to clean it off in order to replain any damage that does go through to the paint. Better methinks to forget it and concentrate on maintaining the paint.
Of course the cavities are a different kettle of fish because I can't see inside heater channels and other seriously enclosed spaces to inspect/maintain them. Thus I figure that the colour of the protective wax is insignificant in these areas. The blurb in the Frost catalogue about Dinitrol Corromax 3125 says "A specially forumulated wax which penetrates rust and dirt preventing further corrosion." That sounds like just the ticket to me, even if it is brown.
The final consideration is that there are a few places where special paints are needed. Exhausts and engine blocks need paint that will stand the heat and while I have no immediate plans to paint the engine block I do need to do something about the rust on my exhaust pipework. I've also obtained (from Frost) some special paint for painting brake calipers and drums.
Having formulated a plan, all I need to do now, is to get painting.
Maintaining paintwork would be easy if we were happy to just rub off (note that any wax and dirt should be removed BEFORE you start with the abrasives) the damaged paint, and any rust, and blob on a couple of coats of paint. So why the hell are we so hung up on the idea that a car has to have a super-smooth, high-gloss, paint job that's a really pain in the ass to achieve and even harder to repair? Metallics are even more difficult to patch up, and even more popular!
Of course this is really good for the manufacturers because it means that most people simply won't bother, the car will rot, and the owner will be back to buy a shiny new one a heck of a lot sooner than if maintenance of old one had been easier. Given that maintainability is my number one priority with the ol' bug I'm determined not to go down that route. On the other hand, the rat look isn't to my taste either so I needed an alternative solution. Thus I began to consider things like camouflage and other patterns that would allow me to divide the surface a the car into smaller areas.
To be honest, the Beetle isn't that difficult to divide into small areas. All four wings can be unbolted. Hood, decklid and doors can all be removed or treated seperately. However, as I don't have a garage or suitable shed in which to paint panels and will have to work outside, dealing with areas of this size would still be very difficult. It's also the case that no matter how hard you try to match them, newly painted panels tend to look different to the others.
Having considered lot's of different patterns I've decided upon a cubist inspired (check out Picasso's analytical cubist works) pattern of rectangles and shapes in shades of pinky blue. Here's a mock up that I did on the computer:
I intend to apply the paint with a brush because it will be easier to get the effect that I want and using a variety of shades means that I won't be tied to any particular colour that may prove difficult and/or expensive to obtain at a later date.
Note that the patterns will not hide the shape of the car as much as they do in the mock-up because they'll be following the curves of the surface. I'll also be doing the painting a bit at a time, so the pattern will gradually spread accross the car, rather than trying to do it all at one.
Having come up with a plan for the outside/top of the car, I also needed a plan for the rest and in fact it's the other areas that are more prone to rust. While water runs off the exterior of the car it can get into cavities and get's held onto the underside of the car in a mud poultice. When rust does begin to form, the porous nature of the rust means that it holds moisture thus furthering to rot. Clearly this is something I want to prevent.
Weld-Thru Primer
The first thing I've done is to buy a can of Weld-Thru Zinc Rich Primer Aerosol from Frost and I'll be applying this to all cleaned up metal that I intend to weld.
Hammerite
The next thing is that I've bought tins of smooth black and smooth silver Hammerite paint for use on underbody areas including wheel arches and steering/suspension components. I'll may also be use some other colours under and inside the car before I install carpet and such.
Now I've heard a lot of criticism of Hammerite but it strikes me that most of the problems are caused because people don't use it correctly. Many years ago I used it on with a wrought iron gate and was disappointed to find that the gate started to rust again a couple of months later. It was only afterwards that I realised just how many mistakes I'd made:
Firstly, I cleaned the loose rust off the workpiece. But more than that, I'd cleaned it back to bright shiny metal. I had failed to realised that Hammerite paint is designed to bond to rust. If you're painting bright shiny metal, you should be be using Hammerite Anti-Rust Primer and not the 'normal' Hammerite paint.
Then I shook the tin. This was also a mistake because it introduces air which takes a long time to come out of something as thick as Hammerite. Hammerite, unlike Mr Bond's martinis, should be stirred and NOT shaken.
Then I set about painting by dipping my brush into the tin. Wrong again as this will contaminate the paint in the can as you move the brush from workpiece to can. What you should do is to pour the paint you intend to use into another container and if there is any left over it should be discarded and NOT returned to the tin.
Then I left it to dry overnight and applied a second coat the following day. It seems I really was determined to screw this up because, for it to do it's job, you MUST apply a second coat of Hammerite within four hours of the first such that it does all the chemical bond stuff that it needs to do in order to work. Leave it for more than four hours you're just wasting your time because the second coat won't 'react' with the first coat.
As I say, I've seen a lot of criticism of Hammerite, and the critics generally advocate alternative products that are harder to find and are generally somewhat more expensive. Having done a bit of research, I'm inclined to believe that the main reason that people have any more success with these 'more exotic' products is that they read the instructions and follow them whereas they assume they can use Hammerite like ordinary paint. Hammerite is NOT like ordinary paint and if you treat as such, you will fail to achieve the desired result.
Note that I've chosen to go for the smooth finished stuff (as opposed to the hammered effect) because I want to be able to inspect it for damage on a regular basis and it'll be easier to spot stone chips and the like on a smooth finish.
Dinitrol
While Hammerite should protect the areas where I can apply it with a brush, spraying it into cavities seems a bit hit and miss. On the other hand, products like Waxoyl and Dinitrol are designed for the purpose. These products can also be use to apply a waxy coating the underside of the car.
Bitumen based products are another option for 'undersealing' however the are frowned upon in car restoration circles. In this case I am inclined to agree as it seems that the problem with the bitument based products is that they tend to harden with age and that when they get damaged, water gets behind them, and the metal rots away out of sight behind the coating. Of course the only way to check for this would be by scraping the stuff off, and of course removing something to see whether it's still doing it's job properly is undesireable.
It strikes me that the same is true for the wax based products, many of which are brown or black. How are you supposed to tell if that uneven black/brown surface is still doing it's job or hiding rot? Thus my plan is not to use underbody seal but to paint these areas with Hammerite which I can then inspect and maintain. It has been suggested that I could use 'clear' Waxoyl however I am told that this is really a light brown/yellow colour as opposed to clear and it also presents the additional problem of having to clean it off in order to replain any damage that does go through to the paint. Better methinks to forget it and concentrate on maintaining the paint.
Of course the cavities are a different kettle of fish because I can't see inside heater channels and other seriously enclosed spaces to inspect/maintain them. Thus I figure that the colour of the protective wax is insignificant in these areas. The blurb in the Frost catalogue about Dinitrol Corromax 3125 says "A specially forumulated wax which penetrates rust and dirt preventing further corrosion." That sounds like just the ticket to me, even if it is brown.
Hot Spots
The final consideration is that there are a few places where special paints are needed. Exhausts and engine blocks need paint that will stand the heat and while I have no immediate plans to paint the engine block I do need to do something about the rust on my exhaust pipework. I've also obtained (from Frost) some special paint for painting brake calipers and drums.
Having formulated a plan, all I need to do now, is to get painting.
Monday 18 June 2007
Urethane Parts for Beetles
Progress with the Beetle is slow but everybody warned me that I'd discover more problems than I could see initially and that it'd take longer than I'd anticipated to do the work; so while the nature of the extra problems and work is a surprise, the discover of it isn't. I'll say more about that in another post (it's about time I posted a progress report) because in this post I wanted to say something about urethane parts.
I'd seen them on sale in a number of places and was tempted by their pretty red colour. Of course I wasn't about go changing everything just because of the colour but when one of the rear bump stops broke off in my hand, such that new brackets and 'rubbers' were added to my shopping list, I thought I might give them a try.
Before diving in however I did a search on the VZi forum and was surprised to see that hardly anybody had a good word for urethane. I started a new thread to try to get to the bottom of it (click here) and based on this, plus a little reading elsewhere, I came to the following conclusions:
Most of the urethane parts for Beetles are for use in places where they will be flexed and/or squashed (as opposed to having mechanical movement against them). These inclide bump stops, suspension bushings and gearbox mounts. My research indicates that urethane parts are harder than their rubber equivalents so while they will hold a gearbox more firmly, they will also transmit more vibration into the car. This seems even more counter productive in the case of bump stops and suspension components where they will transmit more vibration, and shocks in the case of bump stops, to the metal components they are supposed to be cushioning. I've been lead to understand that this has benefits in off-road vehicles like dune buggies (where you're expecting a rough ride anyway) because they will last longer. It would appear however that the additional life of the component is little compensation for the loss of ride comfort and protention of other parts in a road car.
There is one major deviation from the flex/squash use of urethane parts in a Beetle and that is in the form of urethane bushings for the front beam where they are used as replacements for the original metal roller bearings and rubber seals. It seems however that they have only one advantage over the original parts: they're cheaper. They will (apparently) wear out much faster and the only argument that I've seen that held any water was that if you're using them in an off road car where you might anticipate knackering and having to replace bearings on a regular basis because of the way you are using the car as opposed to through normal wear and tear...
Thus I will be replacing my bump stops, and any other relevant bits, with rubber as I've concluded that while urethane parts might be of use on an off road vehicle or one whose primary purpose is to look pretty, they have no place on a road car intended for daily use.
I'd seen them on sale in a number of places and was tempted by their pretty red colour. Of course I wasn't about go changing everything just because of the colour but when one of the rear bump stops broke off in my hand, such that new brackets and 'rubbers' were added to my shopping list, I thought I might give them a try.
Before diving in however I did a search on the VZi forum and was surprised to see that hardly anybody had a good word for urethane. I started a new thread to try to get to the bottom of it (click here) and based on this, plus a little reading elsewhere, I came to the following conclusions:
Most of the urethane parts for Beetles are for use in places where they will be flexed and/or squashed (as opposed to having mechanical movement against them). These inclide bump stops, suspension bushings and gearbox mounts. My research indicates that urethane parts are harder than their rubber equivalents so while they will hold a gearbox more firmly, they will also transmit more vibration into the car. This seems even more counter productive in the case of bump stops and suspension components where they will transmit more vibration, and shocks in the case of bump stops, to the metal components they are supposed to be cushioning. I've been lead to understand that this has benefits in off-road vehicles like dune buggies (where you're expecting a rough ride anyway) because they will last longer. It would appear however that the additional life of the component is little compensation for the loss of ride comfort and protention of other parts in a road car.
There is one major deviation from the flex/squash use of urethane parts in a Beetle and that is in the form of urethane bushings for the front beam where they are used as replacements for the original metal roller bearings and rubber seals. It seems however that they have only one advantage over the original parts: they're cheaper. They will (apparently) wear out much faster and the only argument that I've seen that held any water was that if you're using them in an off road car where you might anticipate knackering and having to replace bearings on a regular basis because of the way you are using the car as opposed to through normal wear and tear...
Thus I will be replacing my bump stops, and any other relevant bits, with rubber as I've concluded that while urethane parts might be of use on an off road vehicle or one whose primary purpose is to look pretty, they have no place on a road car intended for daily use.
Tuesday 12 June 2007
Tightening Security on SSH & Webmin
I haven't finished moving everything over to my new servers yet however I am getting a few opportunities to look into new things and today I made a couple of changes to tighten up security.
In the greater scheme of things I'm not what you'd consider to be a prime target. I'm not mega-corp and I doubt there's anybody out there who hates my guts or wants to get into my systems in the hope of finding secrets. On the other hand, the fact that I am small-fry implies that I probably won't have paid too much attention to security issues and may be an easy target for being turned into a spam relay or similar i.e. the attraction of my server to a cracker is not what they might find on it, but what they might be able to use it for if they can get in.
A few days ago for example I awoke to a Logwatch report that telling me that another server at the farm where mine lives had made 400+ attempts to log into my server using SSH. I emailed tech support and got a reply about 15 minutes later saying that they'd checked it, shut it down, and emailed the owner. Now it's hardly likely that the owner of that server had instigated the attack, however they would be left with the big pain in the ass problem of finding out how their server was hacked and dealing with it. Obviously I want to do everything I reasonably can to make sure the same thing doesn't happen to me.
I am fortunate (by design) that I'm the only person who needs to log into my server. Thus I don't need to worry about other users having inadequate passwords or installing problematic scripts/programs. I have a firewall, and have shut down any services that I don't use (like telnet and ftp), so you might think I'd be happy to sit back an relax. However, as I am the only person who needs to use SSH or Webmin, (pretty powerful tools), I figuered that there were probably a few ways that I could make it harder for anybody to abuse them.
The most important line of defence is of course to have good passwords and if you don't know what I mean by 'good passwords', you need to do some research. If you are 99% sure that you do know: that's not good enough and you still need to do some research. If you are 100% sure then you are being way too arrogant and you still ought to do some research. The things is that this stuff changes and what we thought was a good password 10 years ago is mediocre by today's standards because the knowledge and tools available to the crackers is more powerful. Unless you did it just last week, do a search and read half a dozen current documents about passwords. If you find anything in any of them that you didn't know, read half a dozen more. My own current thinking on the subject can be found here.
Starting with SSH then:
It's fairly normal for my Logwatch reports to show a few hundred (occasionally a few thousand) failed attempts to log in via SSH. These are generally split between a dozen or so IP address (that change on a daily basis so there's little point trying to block the addresses), and several dozen common names. Amongst all the toms, dicks and harrys who don't even exist on my server (but are fairly common user names generally) there are also a good number of attempts to log in as apache, root, mysql, and other names that are pretty much always present on any LAMP server.
A fairly simple but substantial increase in security therefore is to create a user with a really weird name (that looks like a password), give them an equally cryptic password, and make them the only user with access to SSH. While brute force attempts to log in via SSH will regularly try lists of common names, they are highly unlikely to try 'random' collections of characters. You've now made it just as hard for someone to guess a user name as it is for them to guess a password. Of course this also means that when you log in via SSH you have to use the weird user name and su to root before you can do anything. A small price to pay and it also means of course that anybody who did guess your weird username and the weird password now needs to guess your root password too. That's "something blooming difficult" three times in a row and probably equates to something pretty near to impossible.
Of course that doesn't stop the failed attempts from bloating my Logwatch reports (something I'm looking into and will report on later) but it does mean that I can safely ignore them.
Having now made SHH a heck of a lot more secure, my other concern was Webmin. Again, I'm the only person who needs to use it but when I do I go in as root so there's 'only' a password between me any somebody else getting in there.
I did some searching and found this document (amongst others) that had some interesting information about securing Webmin. My setup was already doing things like using it with SSL however I did opt to go into Webmin: Webmin Configuration: Authentication and change the number of failed logins required before a host is blocked and the time for which it is blocked. These were set at 5 and 60 seconds but I reckon anybody who gets their password wrong five times in a row shouldn't be allowed anywhere near a server in the first place. As we're blocking IP addresses (as opposed to users) however we don't want an attacker who's accessing the server via somewhere like Tiscali or AOL causing an IP address that's been temporarily allocated from a pool being blocked for long periods of time either. As I'm the only one who should be using Webmin on my server I changed the values to 2 and 600.
In the greater scheme of things I'm not what you'd consider to be a prime target. I'm not mega-corp and I doubt there's anybody out there who hates my guts or wants to get into my systems in the hope of finding secrets. On the other hand, the fact that I am small-fry implies that I probably won't have paid too much attention to security issues and may be an easy target for being turned into a spam relay or similar i.e. the attraction of my server to a cracker is not what they might find on it, but what they might be able to use it for if they can get in.
A few days ago for example I awoke to a Logwatch report that telling me that another server at the farm where mine lives had made 400+ attempts to log into my server using SSH. I emailed tech support and got a reply about 15 minutes later saying that they'd checked it, shut it down, and emailed the owner. Now it's hardly likely that the owner of that server had instigated the attack, however they would be left with the big pain in the ass problem of finding out how their server was hacked and dealing with it. Obviously I want to do everything I reasonably can to make sure the same thing doesn't happen to me.
I am fortunate (by design) that I'm the only person who needs to log into my server. Thus I don't need to worry about other users having inadequate passwords or installing problematic scripts/programs. I have a firewall, and have shut down any services that I don't use (like telnet and ftp), so you might think I'd be happy to sit back an relax. However, as I am the only person who needs to use SSH or Webmin, (pretty powerful tools), I figuered that there were probably a few ways that I could make it harder for anybody to abuse them.
The most important line of defence is of course to have good passwords and if you don't know what I mean by 'good passwords', you need to do some research. If you are 99% sure that you do know: that's not good enough and you still need to do some research. If you are 100% sure then you are being way too arrogant and you still ought to do some research. The things is that this stuff changes and what we thought was a good password 10 years ago is mediocre by today's standards because the knowledge and tools available to the crackers is more powerful. Unless you did it just last week, do a search and read half a dozen current documents about passwords. If you find anything in any of them that you didn't know, read half a dozen more. My own current thinking on the subject can be found here.
Starting with SSH then:
It's fairly normal for my Logwatch reports to show a few hundred (occasionally a few thousand) failed attempts to log in via SSH. These are generally split between a dozen or so IP address (that change on a daily basis so there's little point trying to block the addresses), and several dozen common names. Amongst all the toms, dicks and harrys who don't even exist on my server (but are fairly common user names generally) there are also a good number of attempts to log in as apache, root, mysql, and other names that are pretty much always present on any LAMP server.
A fairly simple but substantial increase in security therefore is to create a user with a really weird name (that looks like a password), give them an equally cryptic password, and make them the only user with access to SSH. While brute force attempts to log in via SSH will regularly try lists of common names, they are highly unlikely to try 'random' collections of characters. You've now made it just as hard for someone to guess a user name as it is for them to guess a password. Of course this also means that when you log in via SSH you have to use the weird user name and su to root before you can do anything. A small price to pay and it also means of course that anybody who did guess your weird username and the weird password now needs to guess your root password too. That's "something blooming difficult" three times in a row and probably equates to something pretty near to impossible.
Of course that doesn't stop the failed attempts from bloating my Logwatch reports (something I'm looking into and will report on later) but it does mean that I can safely ignore them.
Having now made SHH a heck of a lot more secure, my other concern was Webmin. Again, I'm the only person who needs to use it but when I do I go in as root so there's 'only' a password between me any somebody else getting in there.
I did some searching and found this document (amongst others) that had some interesting information about securing Webmin. My setup was already doing things like using it with SSL however I did opt to go into Webmin: Webmin Configuration: Authentication and change the number of failed logins required before a host is blocked and the time for which it is blocked. These were set at 5 and 60 seconds but I reckon anybody who gets their password wrong five times in a row shouldn't be allowed anywhere near a server in the first place. As we're blocking IP addresses (as opposed to users) however we don't want an attacker who's accessing the server via somewhere like Tiscali or AOL causing an IP address that's been temporarily allocated from a pool being blocked for long periods of time either. As I'm the only one who should be using Webmin on my server I changed the values to 2 and 600.
Sunday 27 May 2007
Fedora - The Wrong Hat
I've come to realise that I've made a mistake in moving to Fedora after somebody posted on http://www.fedoraforum.org/ about the imminent release of Core 7 and I asked how people go on for upgrading/reinstalling on servers when they can't afford much down time. The bottom line is that I shouldn't be using Fedora on such a machine.
It was explained to me (heaven knows how I'd missed it) that the whole idea of Fedora is that it is where all the front line cutting edge development is taking place and that while it's great for those who want to be involved with that, it's not the right choice for somebody who want's an as stable as it's possible to be platform on which to host business websites.
I was even more surprised to find that the guys on the forum suggested that I'd be much better off using CentOS i.e. the very OS that I've just moved away from (because I've always found it difficult to get information about it). Once again however, I've been making a big mistake in that my previous server was set up with CentOS and Blue Quartz and I failed to differentiate between the two. It seems that I must have done my searching on Blue Quartz because the only resource of any significance that I was aware of was bluequartz.org which is pretty useless. Had I gone looking for CentOS instead I would have found centos.org and two minutes reading the FAQ would have told me that CentOS is almost exactly the same as Red Hat Enterprise Linux so any book on RHEL would have told me what I wanted to know IF it were not for the Blue Quartz interface. Doh! It seems therefore that what I should have done, rather than moving to Fedora, was to move to another server with CentOS but without Blue Quartz and bought myself a book on RHEL.
Now that I'm here, and tied into a 12 month lease, I guess I'll just have to live with it however this shouldn't be too much of a problem. Since moving to Fedora I've learned quite a bit about the command line and that should stand me in good stead for moving back to CentOS (or indeed any other flavour of Linux) at the end of the lease.
I have to say however that once again I find myself being a little bit miffed at the company from whom I hire the server because, given the nature of Fedora as I now understand it, I'm inclined to question whether or not it is appropriate for them to be offering it as an option.
It was explained to me (heaven knows how I'd missed it) that the whole idea of Fedora is that it is where all the front line cutting edge development is taking place and that while it's great for those who want to be involved with that, it's not the right choice for somebody who want's an as stable as it's possible to be platform on which to host business websites.
I was even more surprised to find that the guys on the forum suggested that I'd be much better off using CentOS i.e. the very OS that I've just moved away from (because I've always found it difficult to get information about it). Once again however, I've been making a big mistake in that my previous server was set up with CentOS and Blue Quartz and I failed to differentiate between the two. It seems that I must have done my searching on Blue Quartz because the only resource of any significance that I was aware of was bluequartz.org which is pretty useless. Had I gone looking for CentOS instead I would have found centos.org and two minutes reading the FAQ would have told me that CentOS is almost exactly the same as Red Hat Enterprise Linux so any book on RHEL would have told me what I wanted to know IF it were not for the Blue Quartz interface. Doh! It seems therefore that what I should have done, rather than moving to Fedora, was to move to another server with CentOS but without Blue Quartz and bought myself a book on RHEL.
Now that I'm here, and tied into a 12 month lease, I guess I'll just have to live with it however this shouldn't be too much of a problem. Since moving to Fedora I've learned quite a bit about the command line and that should stand me in good stead for moving back to CentOS (or indeed any other flavour of Linux) at the end of the lease.
I have to say however that once again I find myself being a little bit miffed at the company from whom I hire the server because, given the nature of Fedora as I now understand it, I'm inclined to question whether or not it is appropriate for them to be offering it as an option.
Thursday 17 May 2007
Planning To Go Topless
It may seem premature to be thinking of taking the roof off my Beetle however I need to replace the heater channels and there would be a lot of mileage in installing carbiolet sill strengtheners at the same time. Of course there's absolutely no point in going to all that expense unless I'm pretty certain that I'll want to take the roof off at a later date. Obviously the idea has some appeal or I wouldn't even be considering it but while I like the idea of cruising around in the sunshine with the top off, our UK weather isn't all sunshine and my car has to spend most of it's time on the drive at the side of our house as we don't have a garage.
To be honest, the 'normal' cabriolet option doesn't appeal to me. I don't like the way the folded down hood perches on the back of the car making it look like a big pram and I don't think they have nothing at all going for them with the hood up. Clearly I've just blown my chances of ever being offered honorary membership of the Cabriolet Owners Club but I don't care. Each to his own and all that, I just don't like cabriolet bugs.
However there are other options. VW produced Beetles (referred to as 'ragtops') with a large cloth panel on the top and although it appears that some of the bits are no longer available, Paris Beetles do kits for some pretty huge 'sunroofs', the biggest of which is as huge 38" x 31" inches and ends up looking to all intents and purposes like a VW ragtop. Paris also do three smaller sizes and of course there are 'normal' type sunroofs available with 'glass' panels. Sunroof and ragtop options benefit over the full cabriolet conversion in that they are a heck of a lot simpler and cheaper to install, largely because you don't need all the strengthening. Thus, if I were planning to go down that route, I wouldn't need to be thinking about installing sill strengtheners.
There is however another option: the targa, which involves having a removable section of roof between the A and B posts i.e. the bit above the driver and front passenger seats. The tops of the door frames are also made removable too.
Apparently there are only about half a dozen of targa beetles in the UK, most of which are the work of a company called Thump Thump and although they are no longer doing conversions, their website at thumpthump.co.uk is dedicated to a number of rather splendid examples of this rare and somewhat love it or hate it style. Clearly I love it but something that wasn't immediately apparent until somebody told me and I did a bit of measuring to check, is that because of the bugs body shape, the removable panel will fit down behind the driver and passenger seats when it's not in use. Thus, if done right, and properly maintained such that the seals aren't allowed to become leaky with age, you have all the benefits of a top down head turner when the sun shines and all the benefits of a hard top when it rains. Of course there's a little more strengthening and other work required than just installing sill stengtheners but that's for later. The important thing for now is that the sill strengtheners ARE on my shopping list.
To be honest, the 'normal' cabriolet option doesn't appeal to me. I don't like the way the folded down hood perches on the back of the car making it look like a big pram and I don't think they have nothing at all going for them with the hood up. Clearly I've just blown my chances of ever being offered honorary membership of the Cabriolet Owners Club but I don't care. Each to his own and all that, I just don't like cabriolet bugs.
However there are other options. VW produced Beetles (referred to as 'ragtops') with a large cloth panel on the top and although it appears that some of the bits are no longer available, Paris Beetles do kits for some pretty huge 'sunroofs', the biggest of which is as huge 38" x 31" inches and ends up looking to all intents and purposes like a VW ragtop. Paris also do three smaller sizes and of course there are 'normal' type sunroofs available with 'glass' panels. Sunroof and ragtop options benefit over the full cabriolet conversion in that they are a heck of a lot simpler and cheaper to install, largely because you don't need all the strengthening. Thus, if I were planning to go down that route, I wouldn't need to be thinking about installing sill strengtheners.
There is however another option: the targa, which involves having a removable section of roof between the A and B posts i.e. the bit above the driver and front passenger seats. The tops of the door frames are also made removable too.
Apparently there are only about half a dozen of targa beetles in the UK, most of which are the work of a company called Thump Thump and although they are no longer doing conversions, their website at thumpthump.co.uk is dedicated to a number of rather splendid examples of this rare and somewhat love it or hate it style. Clearly I love it but something that wasn't immediately apparent until somebody told me and I did a bit of measuring to check, is that because of the bugs body shape, the removable panel will fit down behind the driver and passenger seats when it's not in use. Thus, if done right, and properly maintained such that the seals aren't allowed to become leaky with age, you have all the benefits of a top down head turner when the sun shines and all the benefits of a hard top when it rains. Of course there's a little more strengthening and other work required than just installing sill stengtheners but that's for later. The important thing for now is that the sill strengtheners ARE on my shopping list.
Monday 14 May 2007
Engine Oil For Beetles
For me, oil changes used to be something that happened at the garage when I took a car in for service. Why, how, and what oil was used was none of my concern. Given that the whole point of the Beetle is that I want to maintain it myself, I had some learning to do. Before you read on please note that what follows are my own conclusions based one what I found out. I wrote it down to help me make a decision and so that I can refer back to it at a later date when I've forgotten why I made it. I'm making no promises that I've come to the right decision so don't come hammering on my door if you decide to apply my thinking to your own car and it turns out I got it all wrong okay?
As far as a 'modern' car is concerned you can look in the owner manual, a Haynes manual, or ask a retailer and get the same answer; although the retailers will of course want to sell you whatever brand they happen to stock (but we'll return to the the subject of brands later). With an old car like a Beetle it seems that everybody has a different opinion. For starters, the owner manual will be at least 30 years old and quite a bit has changed since then. The main problem however is that most folks are just not used to dealing with vehicles that are more than 10 or 20 years old. For example, I asked the guy I bought mine from what oil he was using and he didn't know because the garage put it in at the last service. He assured me however that it was being done properly as the car had a 'new' engine 7000 miles ago and he showed me the guarantee/service booklet which showed that it had an oil change at 500, another at 5000, and was due another at 10000. Now you don't have to read much about Beetles to know that everybody, but EVERYBODY, says that they should have the oil changed every 3000 miles. Clearly neither the previous owner nor the garage he was using knew much about Beetles.
Incidentally, while we're on the subject of "how ofen?", as I've come to understand it, the reason for this increased frequency (apparently 3000 miles was failrly standard for most cars before the development of modern lubricants and filters) is that: a) the oil plays a bigger part in cooling a bugs air-cooled engine than it does in a water-cooled engine and 'wears out' faster and b) the bug has an oil strainer as opposed to the type of filter that you get in more modern cars and it's better for this to be removed and cleaned out more regularly.
Thus I began to ask around (a lot) and although at first it seemed that everybody had a different answer I eventually saw that they fell into three groups regarding the specification of the oil.
The first group, and these are generally people who are into Beetles, suggest SAE 30 mono-grade. This seems to be largely because VW originally specified SAE 30 for "general driving" but my research indicates that VW said this at a time when multi-grade oils (recommended for pretty much every modern engine) were in their infancy and (apparently) not very good. However, when you consider that some of the guys who swear by mono-grade have been running their dubs for donkeys years then you have to wonder if they might have a point. It also occurred to me however, that for many people, their bug is a summertime play thing that'll rarely suffer the indignity of being rained on never mind being used to haul groceries back from Tesco in the depths of winter.
The reason that climate and season are important is because an engine oil needs to be 'runny' enough to be pumped through the system when the engine is cold and 'sticky' enough to adhere to the parts when it's hot. The two extremes occur when you're starting up on a cold winter's morning and when you're on a long journey on a hot summer's day; so how cold it gets in winter and how hot it gets in summer in the climate where the engine is being run are factors in choosing engine oil.
This is why VW specified SAE 30 for "general driving" because they also suggested other 'weights' for hot and cold climates. In fact in the days when mono-grade oils were standard it was fairly common practice to use one grade in the summer and another in the winter. The engine oil FAQ over at Morris Lubricants says that "it used to be the practice to put a thin monograde, such as a SAE 30, in the engine during the winter and a heavier monograde, such as a SAE 50". So I guess SAE 30 should be just fine for use in the UK.
The second group of people you will encounter suggest the use of a multi-grade oil. Multi-grade oils are specified with two numbers e.g. SAE 10w/40 (the w means "winter") and what it means is that the oil behaves like a 10 weight oil at the cold temperature and like a 40 weight oil would at the hot temperature. Aparently they define 'cold' as 0° Fahrenheit (-18°C), while 'hot' is 212° Fahrenheit (100°C). "They", just in case you are wondering are the Society of Automotive Engineers which is what the "SAE" bit means.
Now this is where it starts to look really complicated because what you need to do is to figure out which of the myriad variations are right for your engine and climate. Life would be a lot simpler if a single product covered the whole range however it seems that multi-grade oils are made possible by the addition of polymers and to get a range that would suit all possibilities you'd end up with more polymers than oil (and it's the oil that does the actual lubricating).
Just about the best way to get yourself really confused is to ask or look on the Internet because you'll be asking people from lots of different climates so what is right for them will not necessarly be right for you (something that may or may not occur to them when they answer). It's also important to realise that even if you ask around UK forums, not everybody will be wise to the need to consider climate and may well have based their own decision upon information gleaned from inappropriate sources. (See my previous post about tyre pressures for an illustration of people on forums thinking they know their stuff when in fact they don't.)
The good news for those of us in the UK however is that we don't have to deal with the really hot or really cold weather. The lower figure stated for a multi-grade will be 0, 5, 10, 15 or 20 but when you consider that this figure describes the viscocity at -18°C it's probably not something that we need worry about too much here in the UK. The higher figure on the multi-grade spec is generally 30, 40 or 50 and again, here in the UK it's not something that we need to worry about as much as somebody in the Mediterranean.
Having said that, we still have to use something and rather than just closing my eyes and reaching towards the shelf I made the following observations:
Rick Higgins of Bug Me Video (as you already know I'm something of a fan and have a high regard for his opinion) generally reaches for a can of 20w/50 but he's in Florida and as he said when I got the opportunity to ask him: "20w50 works good here since it is never very cold and real hot in the afternoon". He suggested that "In the heat of summer in UK you could likely use 20w50 there." He didn't comment on the UK winter and I didn't feel inclined to press him as he'd already said that "I am not really an authority on oil so what I can share is just my experience and what I have learned from others", but the implcation is clear that something thinner may be more appropriate in the winter.
My Haynes manual also suggests 20w/50 but makes no mention of climate and although it's printed on the UK the nice picture of a left hand drive Beetle on the front cover makes me wonder. VWHeritage, Volkspares, Halfords and a number of other suppliers in whom I have some faith suggest 15w/40 and from what I've seen the 15w/40 will be better at lower temperatures than the 20w/50 making this sound like the answer to my needs. However the 15w/40 is generally to be found sitting on the shelf right next to the 10w/40 which presumably would be even better?
In his "Rap On Oil" in "How To Keep Your Volkswagen Alive", John Muir says that "the multi-grade oil's ability to lubricate is not as good as the mono-grade oil's ability at the high temperatures at which an air-cooled engine runs." Rick Higgins also told me that "I like to stay as thick (sticky) as reasonable so the cylinders retain some lube after the motor is shut down." In both cases they're talking about the behaviour of the oil when hot i.e. the difference between the 40 and the 50 bit of the spec as opposed to the 10, 15, or 20 bit.
John Muir is actually an advocate of SAE 30 and also states a strong bias towards the Castrol brand when he says that it "lays a load on my back to carry my own oil wherever I go because this oil is found only in racing and hotrod stores" This raises the question of availability and I figure, given that our mild UK climate appears to give me some flexibility on the weight of the oil, it probably makes sense to consider some of the other factors before I opt for something that's a swine to get hold of for the sake of what may well be a negligible difference in oil's weight.
If the weight of the oil is the most confusing issue, then the brand name is surely the most controversial with those who believe that the well know brands are a rip off facing off against those who believe that you get what you pay for (and arguing amongst themselves about which of those name brands is the best).
The argument in favour of the well know brands is that you're paying extra for the superior quality of the addititives that they put in to make the oil do its job better. Of course you're also going to be paying more for the name but consider this: it's a name they want to protect so they're unlikely to use it to sell product that would get them a bad reputation are they? We'll discuss a few of those additives in a minute but as far as the brand name versus cheap stuff debate is concerned, the bottom line for me is that the price difference generally works out to be less than five quid on the cost of an oil change. Given the amount that I anticipate spending on petrol and other car related expenses I figure that if I can't afford an extra twenty quid a year to err on the side of caution I ought to sell the car and get a bus pass.
As for which brand then: John Muir has (as we've already seen) a very strong bias towards Castrol. Rick Higgins also told me that he "started using Castrol when I had a friend that worked on these million dollar racing boats here. He said that the Castrol would handle whatever beating they gave it and he swore by it."
Other things that we need to condsider are the differences between mineral oils and those with synthetics, and the difference between oils with and without detergents.
When I asked around, the consensus of opinion was that bug engines are better running on mineral oils but very few people had any idea why and even when an explanation was offered it didn't always make a much sense. Along the way it was suggested that the whole point of synthetics was to make the oil keep working for longer but as you should change a bug's oil every 3000 miles (because of the filter if not the oil itself), then there isn't a whole lot of point paying extra for a longer lasting oil. I've also been told that the heat transfer characteristics of mineral and synthetic oils are different and the bug engine, with it's increased reliance on the oil for cooling, needs mineral oil.
Regarding detergents, John Muir says that the VW community was originally dubious about detergents but now favours them. The point of the detergents is that help keep the engine clean by carrying the 'soot' in suspension. If you use an oil with detergents then the old thinking about brown oil being due for a change whereas black oil needs changing, goes right out the window because the oil will go black due to the soot long before it's in desperate need of a change.
The argument against detergents is that the oil strainer in the bug isn't good enough to filer out all the small particles of crud that get cleaned out of the engine. Thus they will circulate causing damage. I don't like the sound of that however the other side of the coin i.e. if the detergents are not putting that crud into suspension, is that they stay stuck in the engine. Is that really a better option?
From what I've learned I think the most important thing about detergents is probably that you shouldn't suddenly switch from non-detergent to detergent oil. In his book John Muir tells of an occasion when he bought a bus from a guy who had been running on non-detergent oil so he had to stick with it until the next engine rebuild. Had he changed suddently, the detergents would have immediately set about cleaning up what was probably a relatively dirty engine thus putting a whole heap of crud into suspension all at once.
Given that my engine is only 7000 miles since the last rebuild I figure that I'm probably safe to use detergent even though the previous owner couldn't tell me what was in there.
Now, I did say way back at the start that the folks I asked fell into three groups and thus far I've only covered two. That's because the third groups are the ones who will direct you to this weeks special offer or whatever they happen to stock. If they are way too cocky and you're in the mood for listening to some bullshit, try asking them how often you should change it and use some of the information given above to see how long they're prepared to carry on talking through their arses before they finally admit that they haven't a clue; otherwise just feel sorry for them for having such a crap job and walk away.
So what did I buy? Well, availability had quite a lot to do with it but by the time I started checking out what I could get my hands on without too much trouble I'd concluded that I wanted a name brand multi-grade mineral oil but I was still wavering between 15w/40 (because of the 15w bit) and 20w/50 (because of the 50 bit).
The local garage (5 mins walk) have Castol GTX High Mileage 15w40 (£16.96/4l) and Duckhams Q Classic Engine Oil 20w50 (£10.99/4.5l). VWHeritage (somebody I can see myself ordering stuff from on a fairly regular basis) have VW Quantum 15w/40 (£16.95/5l) but as it'd have to be posted, and they calculate postage according to order value, I'd have to add a couple of quid onto the cost of that for postage. The only VW specialist within reasonable travelling distance is GSF - who sell Fuchs Titan HD 15w40 (£11.95/5l) - but they're in a town that I rarely visit and I'd have to go past Halfords and my local garage to get there. The Halford's candidate were Halfords own brand 15w/40 Enhanced Mineral Oil (£12.99/5l) or the Castrol GTX High Mileage 15w40 (£16.99/5l).
In the end I went for the Duckhams Q 20w50 for three reasons:
1. I like to support local businesses where I can (use them or lose them). I already buy my petrol from the guy around the corner even though I could get it a couple of pence a litre cheaper if I went to the one 5 miles away. I figure that if I don't I'll have no right to complain if he shuts down and I'm forced to travel 5 miles for petrol. Thus I wanted to buy from him if he had something suitable.
2. I decided in the end that I was more concened about the oil's performance when it's hot that when it's cold. Health problems mean that I'm forced to sponge off the state rather than work for a living so I'm never obliged to go out when the weather is bad. I decided therefore to go for a 20w50 as opposed to a 15w40. I will however be monitoring it when the weather gets cold and if it starts to look a bit thick, I'll let you know.
3. The Duckhams Oil is a pretty green colour like my car. Only kidding. ;-)
So there we have it, Duckhams Q 20w50 is my oil of choice but as I said at the start, these are my conclusions based on what I found out and I make no promises about them. If you want to read more then check out http://www.carbibles.com/engineoil_bible.html which was one of the more comprehensive documents that I found on the subject of car engine oil, while perhaps the best (my opinion again) summarisation of oil issues relating to VW Beetles that I found was in the Vehicle & Part Information section at VW Heritage.
As far as a 'modern' car is concerned you can look in the owner manual, a Haynes manual, or ask a retailer and get the same answer; although the retailers will of course want to sell you whatever brand they happen to stock (but we'll return to the the subject of brands later). With an old car like a Beetle it seems that everybody has a different opinion. For starters, the owner manual will be at least 30 years old and quite a bit has changed since then. The main problem however is that most folks are just not used to dealing with vehicles that are more than 10 or 20 years old. For example, I asked the guy I bought mine from what oil he was using and he didn't know because the garage put it in at the last service. He assured me however that it was being done properly as the car had a 'new' engine 7000 miles ago and he showed me the guarantee/service booklet which showed that it had an oil change at 500, another at 5000, and was due another at 10000. Now you don't have to read much about Beetles to know that everybody, but EVERYBODY, says that they should have the oil changed every 3000 miles. Clearly neither the previous owner nor the garage he was using knew much about Beetles.
Incidentally, while we're on the subject of "how ofen?", as I've come to understand it, the reason for this increased frequency (apparently 3000 miles was failrly standard for most cars before the development of modern lubricants and filters) is that: a) the oil plays a bigger part in cooling a bugs air-cooled engine than it does in a water-cooled engine and 'wears out' faster and b) the bug has an oil strainer as opposed to the type of filter that you get in more modern cars and it's better for this to be removed and cleaned out more regularly.
Thus I began to ask around (a lot) and although at first it seemed that everybody had a different answer I eventually saw that they fell into three groups regarding the specification of the oil.
The first group, and these are generally people who are into Beetles, suggest SAE 30 mono-grade. This seems to be largely because VW originally specified SAE 30 for "general driving" but my research indicates that VW said this at a time when multi-grade oils (recommended for pretty much every modern engine) were in their infancy and (apparently) not very good. However, when you consider that some of the guys who swear by mono-grade have been running their dubs for donkeys years then you have to wonder if they might have a point. It also occurred to me however, that for many people, their bug is a summertime play thing that'll rarely suffer the indignity of being rained on never mind being used to haul groceries back from Tesco in the depths of winter.
The reason that climate and season are important is because an engine oil needs to be 'runny' enough to be pumped through the system when the engine is cold and 'sticky' enough to adhere to the parts when it's hot. The two extremes occur when you're starting up on a cold winter's morning and when you're on a long journey on a hot summer's day; so how cold it gets in winter and how hot it gets in summer in the climate where the engine is being run are factors in choosing engine oil.
This is why VW specified SAE 30 for "general driving" because they also suggested other 'weights' for hot and cold climates. In fact in the days when mono-grade oils were standard it was fairly common practice to use one grade in the summer and another in the winter. The engine oil FAQ over at Morris Lubricants says that "it used to be the practice to put a thin monograde, such as a SAE 30, in the engine during the winter and a heavier monograde, such as a SAE 50". So I guess SAE 30 should be just fine for use in the UK.
The second group of people you will encounter suggest the use of a multi-grade oil. Multi-grade oils are specified with two numbers e.g. SAE 10w/40 (the w means "winter") and what it means is that the oil behaves like a 10 weight oil at the cold temperature and like a 40 weight oil would at the hot temperature. Aparently they define 'cold' as 0° Fahrenheit (-18°C), while 'hot' is 212° Fahrenheit (100°C). "They", just in case you are wondering are the Society of Automotive Engineers which is what the "SAE" bit means.
Now this is where it starts to look really complicated because what you need to do is to figure out which of the myriad variations are right for your engine and climate. Life would be a lot simpler if a single product covered the whole range however it seems that multi-grade oils are made possible by the addition of polymers and to get a range that would suit all possibilities you'd end up with more polymers than oil (and it's the oil that does the actual lubricating).
Just about the best way to get yourself really confused is to ask or look on the Internet because you'll be asking people from lots of different climates so what is right for them will not necessarly be right for you (something that may or may not occur to them when they answer). It's also important to realise that even if you ask around UK forums, not everybody will be wise to the need to consider climate and may well have based their own decision upon information gleaned from inappropriate sources. (See my previous post about tyre pressures for an illustration of people on forums thinking they know their stuff when in fact they don't.)
The good news for those of us in the UK however is that we don't have to deal with the really hot or really cold weather. The lower figure stated for a multi-grade will be 0, 5, 10, 15 or 20 but when you consider that this figure describes the viscocity at -18°C it's probably not something that we need worry about too much here in the UK. The higher figure on the multi-grade spec is generally 30, 40 or 50 and again, here in the UK it's not something that we need to worry about as much as somebody in the Mediterranean.
Having said that, we still have to use something and rather than just closing my eyes and reaching towards the shelf I made the following observations:
Rick Higgins of Bug Me Video (as you already know I'm something of a fan and have a high regard for his opinion) generally reaches for a can of 20w/50 but he's in Florida and as he said when I got the opportunity to ask him: "20w50 works good here since it is never very cold and real hot in the afternoon". He suggested that "In the heat of summer in UK you could likely use 20w50 there." He didn't comment on the UK winter and I didn't feel inclined to press him as he'd already said that "I am not really an authority on oil so what I can share is just my experience and what I have learned from others", but the implcation is clear that something thinner may be more appropriate in the winter.
My Haynes manual also suggests 20w/50 but makes no mention of climate and although it's printed on the UK the nice picture of a left hand drive Beetle on the front cover makes me wonder. VWHeritage, Volkspares, Halfords and a number of other suppliers in whom I have some faith suggest 15w/40 and from what I've seen the 15w/40 will be better at lower temperatures than the 20w/50 making this sound like the answer to my needs. However the 15w/40 is generally to be found sitting on the shelf right next to the 10w/40 which presumably would be even better?
In his "Rap On Oil" in "How To Keep Your Volkswagen Alive", John Muir says that "the multi-grade oil's ability to lubricate is not as good as the mono-grade oil's ability at the high temperatures at which an air-cooled engine runs." Rick Higgins also told me that "I like to stay as thick (sticky) as reasonable so the cylinders retain some lube after the motor is shut down." In both cases they're talking about the behaviour of the oil when hot i.e. the difference between the 40 and the 50 bit of the spec as opposed to the 10, 15, or 20 bit.
John Muir is actually an advocate of SAE 30 and also states a strong bias towards the Castrol brand when he says that it "lays a load on my back to carry my own oil wherever I go because this oil is found only in racing and hotrod stores" This raises the question of availability and I figure, given that our mild UK climate appears to give me some flexibility on the weight of the oil, it probably makes sense to consider some of the other factors before I opt for something that's a swine to get hold of for the sake of what may well be a negligible difference in oil's weight.
If the weight of the oil is the most confusing issue, then the brand name is surely the most controversial with those who believe that the well know brands are a rip off facing off against those who believe that you get what you pay for (and arguing amongst themselves about which of those name brands is the best).
The argument in favour of the well know brands is that you're paying extra for the superior quality of the addititives that they put in to make the oil do its job better. Of course you're also going to be paying more for the name but consider this: it's a name they want to protect so they're unlikely to use it to sell product that would get them a bad reputation are they? We'll discuss a few of those additives in a minute but as far as the brand name versus cheap stuff debate is concerned, the bottom line for me is that the price difference generally works out to be less than five quid on the cost of an oil change. Given the amount that I anticipate spending on petrol and other car related expenses I figure that if I can't afford an extra twenty quid a year to err on the side of caution I ought to sell the car and get a bus pass.
As for which brand then: John Muir has (as we've already seen) a very strong bias towards Castrol. Rick Higgins also told me that he "started using Castrol when I had a friend that worked on these million dollar racing boats here. He said that the Castrol would handle whatever beating they gave it and he swore by it."
Other things that we need to condsider are the differences between mineral oils and those with synthetics, and the difference between oils with and without detergents.
When I asked around, the consensus of opinion was that bug engines are better running on mineral oils but very few people had any idea why and even when an explanation was offered it didn't always make a much sense. Along the way it was suggested that the whole point of synthetics was to make the oil keep working for longer but as you should change a bug's oil every 3000 miles (because of the filter if not the oil itself), then there isn't a whole lot of point paying extra for a longer lasting oil. I've also been told that the heat transfer characteristics of mineral and synthetic oils are different and the bug engine, with it's increased reliance on the oil for cooling, needs mineral oil.
Regarding detergents, John Muir says that the VW community was originally dubious about detergents but now favours them. The point of the detergents is that help keep the engine clean by carrying the 'soot' in suspension. If you use an oil with detergents then the old thinking about brown oil being due for a change whereas black oil needs changing, goes right out the window because the oil will go black due to the soot long before it's in desperate need of a change.
The argument against detergents is that the oil strainer in the bug isn't good enough to filer out all the small particles of crud that get cleaned out of the engine. Thus they will circulate causing damage. I don't like the sound of that however the other side of the coin i.e. if the detergents are not putting that crud into suspension, is that they stay stuck in the engine. Is that really a better option?
From what I've learned I think the most important thing about detergents is probably that you shouldn't suddenly switch from non-detergent to detergent oil. In his book John Muir tells of an occasion when he bought a bus from a guy who had been running on non-detergent oil so he had to stick with it until the next engine rebuild. Had he changed suddently, the detergents would have immediately set about cleaning up what was probably a relatively dirty engine thus putting a whole heap of crud into suspension all at once.
Given that my engine is only 7000 miles since the last rebuild I figure that I'm probably safe to use detergent even though the previous owner couldn't tell me what was in there.
Now, I did say way back at the start that the folks I asked fell into three groups and thus far I've only covered two. That's because the third groups are the ones who will direct you to this weeks special offer or whatever they happen to stock. If they are way too cocky and you're in the mood for listening to some bullshit, try asking them how often you should change it and use some of the information given above to see how long they're prepared to carry on talking through their arses before they finally admit that they haven't a clue; otherwise just feel sorry for them for having such a crap job and walk away.
So what did I buy? Well, availability had quite a lot to do with it but by the time I started checking out what I could get my hands on without too much trouble I'd concluded that I wanted a name brand multi-grade mineral oil but I was still wavering between 15w/40 (because of the 15w bit) and 20w/50 (because of the 50 bit).
The local garage (5 mins walk) have Castol GTX High Mileage 15w40 (£16.96/4l) and Duckhams Q Classic Engine Oil 20w50 (£10.99/4.5l). VWHeritage (somebody I can see myself ordering stuff from on a fairly regular basis) have VW Quantum 15w/40 (£16.95/5l) but as it'd have to be posted, and they calculate postage according to order value, I'd have to add a couple of quid onto the cost of that for postage. The only VW specialist within reasonable travelling distance is GSF - who sell Fuchs Titan HD 15w40 (£11.95/5l) - but they're in a town that I rarely visit and I'd have to go past Halfords and my local garage to get there. The Halford's candidate were Halfords own brand 15w/40 Enhanced Mineral Oil (£12.99/5l) or the Castrol GTX High Mileage 15w40 (£16.99/5l).
In the end I went for the Duckhams Q 20w50 for three reasons:
1. I like to support local businesses where I can (use them or lose them). I already buy my petrol from the guy around the corner even though I could get it a couple of pence a litre cheaper if I went to the one 5 miles away. I figure that if I don't I'll have no right to complain if he shuts down and I'm forced to travel 5 miles for petrol. Thus I wanted to buy from him if he had something suitable.
2. I decided in the end that I was more concened about the oil's performance when it's hot that when it's cold. Health problems mean that I'm forced to sponge off the state rather than work for a living so I'm never obliged to go out when the weather is bad. I decided therefore to go for a 20w50 as opposed to a 15w40. I will however be monitoring it when the weather gets cold and if it starts to look a bit thick, I'll let you know.
3. The Duckhams Oil is a pretty green colour like my car. Only kidding. ;-)
So there we have it, Duckhams Q 20w50 is my oil of choice but as I said at the start, these are my conclusions based on what I found out and I make no promises about them. If you want to read more then check out http://www.carbibles.com/engineoil_bible.html which was one of the more comprehensive documents that I found on the subject of car engine oil, while perhaps the best (my opinion again) summarisation of oil issues relating to VW Beetles that I found was in the Vehicle & Part Information section at VW Heritage.
Sunday 13 May 2007
Tyre Pressures & Karma
Although I haven't posted about it before, one of the first things I wanted to do when I got my Beetle was to check the tyre pressure.
Strangely, neither John Muir's book nor my Haynes manual seems to contain the necessary information. In the end I asked on the VZi forum and the results were rather surprising, not just because of the numbers (a mere 18psi on the front and 27psi on the rear) but because of the number of other VZi members who responded to the information with posts along the lines of "Really? Are you sure?"
Laurence Fletcher, the guy who posted the info, said it came "straight out of VW's own dealer service manual" and indeed I've since found some stickers over at VWHeritage (click here to see them) that are reproductions of a sticker that VW (apparently) used to stick inside the glovebox. The sticker says 19psi and 27psi but either way it's a lot lower, especially on the front, than a lot of the folks over at VZi had been using. Indeed my own bug was at about 30psi all round and after dropping them down to what they should be, the ride is quite a bit smoother.
While we're on the subject of tyres, the Haynes manual suggests swapping the wheels around every 6000 miles such that they wear evenly however John Muir is quite emphatic, he even puts it on bold text, that you should not do this. Mr Muir says "it takes about 500 miles for a tire to get used to its position on a car, and changing it around just messes with its head. It will last as long or longer right where it is." I'm with Mr Muir on this one because I'd be pretty pissed if somebody swapped the soles of my shoes everytime I got them all worn in and comfy, and I don't need any bad karma for messing with my tyre's heads. ;-)
Strangely, neither John Muir's book nor my Haynes manual seems to contain the necessary information. In the end I asked on the VZi forum and the results were rather surprising, not just because of the numbers (a mere 18psi on the front and 27psi on the rear) but because of the number of other VZi members who responded to the information with posts along the lines of "Really? Are you sure?"
Laurence Fletcher, the guy who posted the info, said it came "straight out of VW's own dealer service manual" and indeed I've since found some stickers over at VWHeritage (click here to see them) that are reproductions of a sticker that VW (apparently) used to stick inside the glovebox. The sticker says 19psi and 27psi but either way it's a lot lower, especially on the front, than a lot of the folks over at VZi had been using. Indeed my own bug was at about 30psi all round and after dropping them down to what they should be, the ride is quite a bit smoother.
While we're on the subject of tyres, the Haynes manual suggests swapping the wheels around every 6000 miles such that they wear evenly however John Muir is quite emphatic, he even puts it on bold text, that you should not do this. Mr Muir says "it takes about 500 miles for a tire to get used to its position on a car, and changing it around just messes with its head. It will last as long or longer right where it is." I'm with Mr Muir on this one because I'd be pretty pissed if somebody swapped the soles of my shoes everytime I got them all worn in and comfy, and I don't need any bad karma for messing with my tyre's heads. ;-)
Wednesday 9 May 2007
php-gd - As Easy As Tea
I remember hearing a story about a guy who went to an airport in order to have a five minute conversation with another guy who was about to board a plane. Apparently the guy boarding the plane charged the first guy a hundred quid a minute for his time. A lot of dosh, especially twenty years ago when I heard this story, but according to the story the information was worth a lot more than that to the guy doing the asking.
Alas my endeavours with Fedora are not going quite so swimmingly as I had hoped. The whole point of switching to a server with Fedora was that it appeared to be much more widely documented than the CentOS Linux on my old server (see note [1]). Unfortunately, now that I'm trying to use that information I'm find it difficult to find the bits that I actually need amongst the masses of information that's out there. If you want a run through on how to install it you can take your pick but if you want to know something about a particular issue with regard to using it...
A good example is the fun I've had with the GD Library for PHP. Some of my scripts make use of functionality from the GD Library for manipulating images and while this was already set up on my old server it was not set up on the new one. The information on how to get it working was very difficult to track down. My books had nothing to say on the subject (or at least I couldn't find it) and the relevant websites (php.net, libgd.org and fedoraproject.org) assumed that I knew things about installing and configuring that I don't and in some instances made references to files and directories that are not on my server (presumably because the information relates to a differnent version of Linux).
In the end I put in a call to tech support at the company from whom I lease the server and was told to enter the following at the command line:
yum install php-gd
/etc/init.d/httpd restart
It was as simple as that. Yum installs the package and then you restart the apache server. Pretty obvious really, but things always are when you know. It also occurred to me this morning for example that there is nothing on the box of tea bags that says to put the bag into the cup and add boiling water as opposed to tearing open the bag and tipping the tea into the cup. Pretty much anything else would require us to empty out the contents from the 'sachet', but not the ol' tea bag. Obvious WHEN you know.
It seems therefore that until I become a lot more familiar with Fedora (and I'm only going to achieve that by using it) I'm destined to spend hours of my time digging through mountains of information in order to find the snippets that I need. I'm not saying that I could justify a hundred quid a minute but I'm very grateful to tech support right now.
Notes:
[1] See this post for why I've realised that this was a mistake.
Alas my endeavours with Fedora are not going quite so swimmingly as I had hoped. The whole point of switching to a server with Fedora was that it appeared to be much more widely documented than the CentOS Linux on my old server (see note [1]). Unfortunately, now that I'm trying to use that information I'm find it difficult to find the bits that I actually need amongst the masses of information that's out there. If you want a run through on how to install it you can take your pick but if you want to know something about a particular issue with regard to using it...
A good example is the fun I've had with the GD Library for PHP. Some of my scripts make use of functionality from the GD Library for manipulating images and while this was already set up on my old server it was not set up on the new one. The information on how to get it working was very difficult to track down. My books had nothing to say on the subject (or at least I couldn't find it) and the relevant websites (php.net, libgd.org and fedoraproject.org) assumed that I knew things about installing and configuring that I don't and in some instances made references to files and directories that are not on my server (presumably because the information relates to a differnent version of Linux).
In the end I put in a call to tech support at the company from whom I lease the server and was told to enter the following at the command line:
yum install php-gd
/etc/init.d/httpd restart
It was as simple as that. Yum installs the package and then you restart the apache server. Pretty obvious really, but things always are when you know. It also occurred to me this morning for example that there is nothing on the box of tea bags that says to put the bag into the cup and add boiling water as opposed to tearing open the bag and tipping the tea into the cup. Pretty much anything else would require us to empty out the contents from the 'sachet', but not the ol' tea bag. Obvious WHEN you know.
It seems therefore that until I become a lot more familiar with Fedora (and I'm only going to achieve that by using it) I'm destined to spend hours of my time digging through mountains of information in order to find the snippets that I need. I'm not saying that I could justify a hundred quid a minute but I'm very grateful to tech support right now.
Notes:
[1] See this post for why I've realised that this was a mistake.
Subscribe to:
Posts (Atom)