Seatbelts and Transporting Computers

November 26, 2009 | etbe

I’ve just read an interesting post at Making Light about seat-belts [1].

In Australia seat-belt use is mandatory, you can be fined for failing to wear one – and the police (who help clean up the mess when someone dies on the road) are apparently quite aggressive about enforcement. Even aside from the legal requirement the use of seat-belts is fairly ingrained in Australian culture, people tend to use them even when they won’t get caught.

One of the things I like to do in my spare time is to take unused computer gear from IT companies (which they regard as rubbish) and give it to home users for recreational and educational use. Due to that and my work for some smaller IT companies I’ve helped many people load computer gear into their private cars and observed that most people will not take adequate care unless I coerce them.

A CRT monitor tends to be large and heavy, you wouldn’t want to get hit in the back of the head with one at 60Km/h. With some combinations of monitor and car you can fit a monitor in the front passenger foot-well, but usually the only place a monitor will fit is the back seat. The correct thing to do is to use the seat-belt to strap the monitor in place. It’s most likely that the monitor stand (the only part that allows a seat-belt to be attached) would snap off in the event of a serious crash – but this would at least slow the monitor down. Also don’t put the monitor directly behind your seat if you can avoid it, put it behind the passenger seat. In a collision monitor might be able to push through your seat and cause you a back injury.

Between 1992 and 2006 there were 78,000 acute computer-related injuries treated in US hospital emergency rooms [2]. The number of injuries caused by monitors peaked at 37% of the total in 2003 – this was largely due to monitors falling on people. Even without the speed of a car a monitor can be a dangerous projectile.

Hard drives have a lot of potential to cause damage, they are dense, hard, and the corners often aren’t rounded. Storing them above the back seat behind the driver’s head (as a friend once tried to do) is a really bad idea. Mythbusters showed that a box of tissues isn’t going to kill you in a crash, but a hard drive is much more dangerous. The typical car glove box can store a few drives. If you need to transport a box full then the front passenger foot well is a reasonable place. If your car rolls then that would suck, but it seems that people usually die when they roll their car anyway so just try not to do that.

A serious server (EG 2RU or bigger rack-mount) typically weighs 30Kg or more and is solidly constructed. The size and mass of such a machine makes it extremely difficult to safely store inside a car. The ideal place is the boot, but if that isn’t an option then behind the passenger seat is the next best option.

One final issue that I’ve been wondering about is the safest option for laptops that are in use in a moving car. A 3Kg Thinkpad would have to hurt if it hit you in the back of the head at 60Km/h. The child-seat attachments are solid anchor points that can be used for other things. I wonder if a laptop security cable could be attached to one of the child seat points. According to an exhibit at a science museum I can throw a tennis ball at 115Km/h, so I presume that laptop security cables are designed not to break when someone swings the laptop at that speed. Therefore if a car was driving at a legal speed in Australia before crashing then a laptop security cable should be able to stop the laptop. Preventing the cable from injuring the passenger on the way would be the difficult part.

Computer Security and Political Censorship

November 25, 2009 | etbe

I’ve just been disappointed to read about the DNI (Defence in the National Interest) web site closing down [1]. The final blog post says “In the meantime, Iâ€™ll leave everything up unless we start having more security problems“, but unfortunately they have had a number of security problems in the past. I doubt the ability of a WordPress installation to remain unscathed on the Internet if it’s not upgraded regularly. So I think it’s only a matter of time before a new bad WordPress bug is discovered and DNI goes offline for good.

In the past I did idly consider volunteering to help them run their site, but apart from a lack of spare time there is the issue that a number of their policy positions are things that I strongly disagree with. I can agree with paleo-cons on a number of issues, but there are also significant areas of disagreement.

So it seems that the combination of a lack of skilled system administrators and a lack of good security in their software is reducing their ability to spread their message. While the site content is going to be mirrored on other sites the URLs will break and Google will give it a lower rank. In many ways losing Google ranking is a way of being silenced.

I wonder whether the apparent lack of moderate-right political expression on the Internet is partly due to that demographic having less IT skills than the groups who have centrist to left-wing political views and those who have extreme-right views. Naturally anyone can pay to have someone run their web site, but having to pay raises the barrier to entry and eliminates some of the potential contributors. I think it’s a bad thing for democracy if the only people who get their voices heard are those who have significant amounts of money or technical skill.

One of my hopes for the SE Linux project was that it would increase the longevity of servers while also decreasing the amount of money required to run them. But of course if you have buggy PHP code then there’s not much SE Linux can do to help you.

[1] http://www.d-n-i.net/dni/2009/11/23/dni-to-close-update/

SCO Unix and Proftpd

November 25, 2009 | etbe

I recently had the misfortune to be compelled to install Proftpd on SCO Unix. There’s nothing wrong with Proftpd of course, but everything is wrong with SCO.

LDFLAGS=-L/usr/ucblib ./configure –libdir=/usr/ucblib --enable-builtin-getnameinfo

To get it to compile the above ./configure line is needed. It uses /usr/ucblib because having the basic BSD sockets API residing in a non-default directory makes things more exciting. The --enable-builtin-getnameinfo option is needed because the getnameinfo library call in SCO Unix doesn’t work properly. On a real OS I would have downloaded the source to libc to figure out where the problem might be, but on SCO I had no option other than to disable that functionality.

Then once I got it working I had to put UseIPv6 off in the configuration file, otherwise I got the error No Route to Host (from memory) when I tried to start proftpd.

Finally the process was dying from an unhandled SIGALRM every 10 seconds. According to truss (a vastly inferior equivalent to strace) the sigaction() system call was being entered four times to handle SIGALRM (as was reported for every time the application code called sigaction() but the default action of terminating the application remained in place. I ended up running proftpd from inetd which removed the need for the alarm handling code. Then it all worked.

SCO sucks.

Last month Darl McBride was terminated from his position with the SCO group [1]. It’s unfortunate that Darl wasn’t terminated a lot earlier, if so then maybe SCO could have focussed on improving the quality of their products and delivering value for stock holders. Hopefully Darl will be sued by some of the people who lost money when SCO went bankrupt.

It would be good if Darl could also be sued by companies that lost money due to the poor quality of SCO Unix – that means every company that runs SCO servers or that writes software for it. The truly awful nature of SCO Unix is in large part due to the fact that all of SCO’s money was spent on litigation that was well known to be baseless.

[1] http://en.wikipedia.org/wiki/Darl_mcbride

Car Drivers vs Mechanics and Free Software

November 24, 2009 | etbe

In a comment on my post about Designing Unsafe Cars [1] Noel said “If you donâ€™t know how to make a surgery, you donâ€™t do it. If you donâ€™t know how to drive, donâ€™t drive. And if you donâ€™t know how to use a computer, donâ€™t expect anybody fix your disasters, trojans and viruses.” Later he advocates using a taxi.

Now I agree about surgery – apart from corner cases such as medical emergencies in remote places and large-scale disasters. I also agree that it’s good to avoid driving if you aren’t very good at it (that would be much better than the current fad of sub-standard drivers buying large 4WD vehicles).

But I don’t think that people who lack computer skills should avoid using computers.

When cars were first invented everyone who owned one was either a mechanic or employed one. Driving a car often involved being well out of range of anyone else who might know how to fix it, so either the car owner or their chauffeur had to be able to fix almost any problem. As the car industry evolved the level of mechanical knowledge required to own and operate a car has steadily decreased. I expect that a significant portion of drivers don’t know how to top up the oil or radiator water in their car and probably don’t know what is the correct pressure for air in their tires. To a large extent I don’t think this is a problem, owning a car involves regularly taking it to be serviced where professionals will (or at least should) check every aspect of the car that is likely to fail. If I used my windscreen-washer less frequently I could probably avoid opening the bonnet of the car between scheduled services!

When budgeting for car ownership you just have to include regularly spending a few hundred dollars to pay for an expert to find problems and fix them – with of course the occasional large expense for when something big breaks.

When the computer industry matures I expect that the same practice will occur. Most people will buy computers and plan to spend small amounts of money regularly to pay people to maintain it. Currently most older people seem to plan to have a young relative take care of their PC for them – essentially free mechanic services. The quality of such work will vary of course, and poorly designed OSs that are vulnerable to attack may require more support than can be provided for free.

Due to deficiencies in city design it is almost essential to drive a car in most parts of the US and Australia – as opposed to countries such as the Netherlands where you can survive quite well without ever driving. When a service is essential it has to be usable by people who have little skill in that area. It would be good if driving wasn’t necessary, I would be happy if I never drove a car again.

The need to use computers however will continue to increase. So we need to make them more available to users and to support users who can’t disinfect computers etc. The only skill requirements for using a computer should be the ability to use a keyboard and a mouse!

This requires a new industry in supporting PCs. Geek Squad in the US [2] seems to be the organisation that is most known for this. I expect that there will be multiple companies competing for such work in every region in the near future, just as there are currently many companies competing for the business of servicing cars.

We need support for free software from such companies. Maybe existing free software companies such as Red Hat and Canonical can get into this business. One advantage of having such companies supporting software is that they would have a strong commercial incentive to avoid having it break – unlike proprietary software vendors who have little incentive to do things right.

The next issue is the taxi analogy. Will software as a service with Google subsidising our use of their systems [3] take over any significant part of the market?

Of course the car analogy breaks down when it comes to privacy, no-one does anything remotely private in a taxi while lots of secret data is stored on a typical home computer. Google is already doing some impressive security development work which will lead towards low maintenance systems [4] as well as protecting the privacy of the users – to the extent that you can trust whoever runs the servers.

My parents use their computer for reading email, browsing the web, and some basic wordprocessing and spreadsheet work. The mail is on my IMAP server so all I need is to have some way to store their office documents on a server and they will pretty much have a dataless workstation. Moving their collection of photos and videos of their friends and relatives to a server will be a problem, transferring multiple gigabytes of data on a cheap Australian Internet access plan is a problem.

Designing Unsafe Cars

November 24, 2009 | etbe

The LA Times has an interesting article about problems with Toyota and Lexus cars [1]. Basically there are problems where the cars have uncontrolled acceleration (there seems to be some dispute about whether it is due to engine management or the floor mat catching the accelerator pedal). When that happens the brakes don’t work (due to the vacuum power-assistance for brakes going away when the engine is at full power) and a terrible crash seems inevitable.

There are suggestions that the driver should shift the car to neutral and discussion about how the Toyota gear selection makes that difficult. Some years ago I was driving an automatic car on a freeway at 100Km/h and the engine stalled (due to a problem with the LPG system). I had become used to never touching the gear lever while driving so the possibility of moving the gear lever one notch to neutral didn’t occur to me. With a dead engine in gear the car slowed rapidly which is quite dangerous when surrounded by 100Km/h traffic. Fortunately I was able to swerve into the emergency lane (across one lane of active traffic) before the car slowed much. That was in a relatively controlled environment with a gear shift mechanism that is a lot simpler than that which is common in some of the more expensive cars.

According to Wikipedia the maximum speed limit in the US is 80M/h [2]. It seems to me that Toyota is being irresponsible by selling cars that can sustain 120M/h, while the probability of surviving a crash at 80M/h is quite low, it seems likely to be a lot greater than the probability of surviving a crash at 120M/h. Also if a car is out of control at 80M/h then the driver will have a lot more time to work out how to put the engine in neutral or turn it off – the lower speed will extend the time available by more than 50% because bends in the road can be better handled at 80M/h.

It seems to me that it would be a feature for the car owner to have the car limited to a speed that is not much greater than the speed limit. According to Wikipedia the highest speed limit in Australia is 130Km/h (in NT), but it’s 110Km/h in all places where I have driven. If my car had a governor to limit the speed to 115Km/h and a switch to change the limit to 135Km/h in case I ever drive to the NT then it would not affect my driving patterns (I rarely drive on roads with a 100Km/h limit and almost never drive on roads with a 110Km/h limit) – but it could reduce the probability of things going horribly wrong. Also one thing to note is that last time I checked car tyres sold in Australia were only required to operate safely at speeds below 190Km/h (118M/h), so a Lexus that went out of control at 120M/h in Australia might risk a tyre blow-out – which admittedly would only make things marginally worse.

A governor for the reverse gear would also be a good feature. Some time ago a granny got her foot stuck on the accelerator in a car park and caused serious damage to her car and a parked car – after passing close by where I was standing. I don’t think that there is a real need to do more than 5Km/h in reverse, limiting the speed would give pedestrians a better chance of escaping parking accidents.

One serious problem with some of the Toyota and Lexus vehicles is that it apparently takes 3 seconds to turn the engine off in an emergency! I’ve been driving for almost 20 years and experienced a number of dangerous situations, all of which were essentially resolved (for better or worse) in significantly less than 3 seconds. A 3 second delay is as good as a 1 hour delay for safety critical systems.

Also if the accelerator and brake pedals are pressed at the same time then the brake should take precedence. It seems quite obvious that whenever both pedals are pressed hard then the driver would probably prefer hard braking to hard acceleration.

If you look at industrial machinery (robots, lathes, etc) you will always see big red buttons (or whatever color is used for emergency stop in your region) that are clearly marked and obvious – to the workers and to bystanders. Escalators have less obvious red buttons but they can still be shut down in an emergency. It seems to me that there are potential benefits to having an emergency shutdown button in a car, maybe in a position that is accessible to the front-seat passenger in case the driver is incapacitated. Such a shutdown button wouldn’t do anything extreme such as fully activating the brakes (which would be very bad on a road that has high-speed traffic), but would prevent acceleration (with some sort of hardware control to avoid software problems) and maintain power to the brakes and the steering.

One thing that needs to be considered is that people tend not to do the most logical things when in an emergency situation. It needs to be possible to do whatever is necessary to save your life without any great deal of thought. Pushing a big red button is easy, holding down the “on” button for 3 seconds or even navigating a gear shift to an uncommon setting is a lot more difficult.

It seems to me that there is also an issue of driver training. If putting an automatic car into neutral and cruising to a stop was part of the test for new drivers then the results of such car problems might not always be so bad.

But I don’t expect there to be any serious changes to driver training or car design. People are too accepting of road deaths.

Don Marti has expressed a plan to never buy a vehicle with an automatic transmission because of this issue [3]. But the number of new vehicles being sold with a manual transmission is steadily reducing. An automatic transmission allows better performance (F1 cars have used them for ages), better fuel efficiency (you could never make a manual Prius), a more comfortable ride (the Hybrid Lexus keeps winning the Australian Luxury Car of the Year award), and allows less skillful drivers. Unless Don wants to ride a moped or drive an old car then I expect that he will be forced to get an automatic transmission. Then of course he will still be at risk of other people having car problems (the LA Times article mentions a third party being killed after an out of control car hit them).

Also I expect that the extra safety features that are implemented in luxury vehicles such as the Lexus would save a few lives, they should save enough to outweigh the number that are lost on the rare occasions when the car goes out of control. Other luxury cars such as the Mercedes S class have great safety features and don’t have a history of going wrong in a newsworthy way. A second-hand S Class Mercedes was surprisingly cheap in the UK last time I checked, cheap enough to make it worth considering the importation of one to Australia.

But my solution to these problems is to try and minimise my driving. A 1.5 ton Lexus driving out of control at the maximum speed possible in urban streets won’t do much damage to a 20 ton tram.

Laptop Reliability

November 23, 2009 | etbe

Update: TumbleDry has a good analysis of the Square Trade report [0]. It seems that there are significant statistical problems in Square Trade’s analysis and a possible conflict of interest.

Square Trade did a survey of laptop reliability and wrote an interesting article about the results [1]. One thing to keep in mind when reading them is that the usage patterns vary greatly by type of product (netbook vs laptop) and probably by brand.

Their statistics indicate that netbooks are less reliable than laptops, but I think that my actions in taking my EeePC to places such as the beach are probably not uncommon – a netbook is ideal when you might need access to a computer at a moment’s notice. I expect that the reliability of my laptop has increased because I bought a netbook!

Their statistics show that Lenovo is far from the most reliable brand, I wonder what the usage scenarios for such machines are. I’ve been using Thinkpads happily for over 11 years. I have had many warranty repair jobs, I lost count long ago. But I don’t think that this indicates a problem with Thinkpads, my use is very demanding, I have done a lot of traveling, and done coding in planes, trains, trams, and taxis in many countries. So instead of criticising IBM/Lenovo for having their machines break, I praise them for repeatedly repairing them no matter how they wear out in my use. The speed and quality of the repair work is very impressive. Based on this I have been strongly recommending Thinkpads to everyone I know who seems likely to wear laptops out through basically doing everything that a laptop is designed to do all day every day! Among people I know the incidence of laptop warranty repairs is probably about 100% as the number of systems that are never repaired are outweighed by the systems that are repaired multiple times.

Generally Thinkpads seem fairly well built to me, I’ve been surprised at how many times they didn’t break when I expected them to.

When articles like the one from Square Trade are discussed people usually cite personal anecdotes. My above anecdote covers just over 11 years of intensive use of four different Thinkpads. Of course it doesn’t prove much about the inherent reliability of Thinkpads (I could have received through random selection either four Thinkpads that were significantly more or less reliable than average). But having dealt with the IBM/Lenovo service in a few countries I can confirm the quality of their repair work. Every time they have returned my machine rapidly, they never complained about my policy of giving them a system with the hard drive removed, and in all but one case they completely solved the problem on the first try. One time they forgot to replace a broken rubber foot and to make up for this they sent me a complete set of spare parts by courier – they had repaired the other two faults without problem.

Now comparing the reliability of rack-mount servers would be a lot easier. The vast majority of such systems are stored safely in racks all the time and tend not to be mishandled. My experience with servers from Dell, HP, IBM, and Sun is that apart from routine hard drive failures they all run well if you keep them cool enough. But of course as I haven’t run more than a few dozen of any of those brands at one time I don’t have anything near a statistically significant sample.

Planning Servers for Failure

November 22, 2009 | etbe

Sometimes computers fail. If you run enough computers then you encounter failures regularly. If the computers are important then you need to plan for the failure.

An ideal situation is to have redundant servers. Misconfigured clusters can cause more downtime than they can prevent and it requires more expensive hardware to properly implement a cluster (you need at least two servers and hardware to allow a good node to kill a bad node) as well as more time (from people who may charge higher rates).

Most companies don’t have redundant servers. So if you have some non-redundant servers there seem to be two reasonable options. The first one is to use more expensive hardware on a support contract. If a server is really important to you then get a 24*7 support contract – it only takes an extra mouse click (and a couple of thousand dollars) when ordering a Dell server. I am not going to debate the relative merits of Dell vs IBM vs HP at this time, but I think that most people will agree that Dell offers significant advantages over a white-box server, both in terms of quality (the low incidence of failure) and support (including 24*7 part replacement).

The second option is to have a cheap server that can be easily replaced. This IS appropriate for some tasks. For example I have installed many cheap desktop systems with two IDE disks in a RAID-1 array that run as Internet gateway systems for small businesses. The requirements were that they be quiet, use little power (due to poorly ventilated server rooms / cupboards), be relatively reliable, and be reasonably cheap. If one of those systems suddenly fails and no replacement hardware is available then someone’s desktop PC can be taken as a replacement, having one person unable to work due to a lack of a PC is better than having everyone’s work impeded by lack of Internet access!

This ability to swap hardware is dependent on the new hardware being reasonably similar. Finding a desktop PC in an office today which can support two IDE disks and which has an Ethernet port on the motherboard and a spare PCI slot is not too difficult. I expect that in the near future such machines will start to disappear which will be an incentive for using systems with SATA disks and USB keyboards as routers.

This evening I had to advise someone who was dealing with a broken server. The system in question is mission critical, was based on white-box hardware, and had four SATA disks in a LVM volume group for the root filesystem. This gave a 600G filesystem with less than 10G in use. If the person who installed it had chosen to use only a single disk (or even better two disks in a RAID-1 array) then there would have been a wide range of systems that could take the disks and be used to keep the company running for business tomorrow. But finding a computer that can handle four SATA disks is a little more tricky.

Of course running a mission critical server that doesn’t use RAID is obviously very wrong. But using four disks in an LVM volume group both increases the probability of a data destroying disk failure and makes it more difficult to replace the computer itself. Some server installations are fractally wrong.

Some Tips for Shell Code that Won’t Destroy Your OS

November 20, 2009 | etbe

When writing a shell script you need to take some care to ensure that it won’t run amok. Extra care is needed for shell scripts that run as root, firstly because of the obvious potential for random destruction, and secondly because of the potential for interaction between accounts that can cause problems.

One possible first step towards avoiding random destruction is to start your script with “#/bin/sh -e” instead of “#/bin/sh“, this means that the script will exit on an unexpected error, which is generally better than continuing merrily along to destroy vast swathes of data. Of course sometimes you will expect an error, in which case you can use “/usr/local/bin/command-might-fail || true” to make it not abort on a command that might fail.
#!/bin/sh -e
cd /tmp/whatever
rm -rf *
#!/bin/sh
cd /tmp/whatever || exit 1
rm -rf *
Instead of using the “-e” switch to the shell you can put “|| exit 1” after a command that really should succeed. For example neither of the above scripts is likely to destroy your system, while the following script is very likely to destroy your system:
#!/bin/sh
cd /tmp/whatever
rm -rf *
Also consider using absolute paths. “rm -rf /tmp/whatever/*” is as safe as the above option but also easier to read – avoiding confusion tends to improve the reliability of the system. Relative paths are most useful for humans doing typing, when a program is running there is no real down-side to using long absolute paths.
Shell scripts that cross account boundaries are a potential cause of problems, for example if a script does “cd /home/user1” instead of “cd ~user1” then if someone in the sysadmin team moves the user’s home directory to /home2/user1 (which is not uncommon when disk space runs low) then things can happen that you don’t expect – and we really don’t want unexpected things happening as root! Most shells don’t support “cd ~$1“, but that doesn’t force you to use “cd /home/$1“, instead you can use some shell code such as the following:
#!/bin/sh
HOME=`grep ^$1 /etc/passwd|head -1|cut -f6 -d:`
if [ "$HOME" = "" ]; then
echo "no home for $1"
exit 1
fi
cd ~

I expect that someone can suggest a better way of doing that. My point is not to try and show the best way of solving the problem, merely to show that hard coding assumptions about paths is not necessary. You don’t need to solve a problem in the ideal way, any way that doesn’t have a significant probability of making a server unavailable and denying many people the ability to do their jobs will do. Also consider using different tools, zsh supports commands such as “cd ~$1“.
When using a command such as find make sure that you appropriately limit the results, in the case of find that means using options such as -xdev, -type, and -maxdepth. If you mistakenly believe that permission mode 666 is appropriate for all files in a directory then it won’t do THAT much harm. But if your find command goes wrong and starts applying such permissions to directories and crosses filesystem boundaries then your users are going to be very unhappy.
Finally when multiple scripts use the same data consider using a configuration file. If you feel compelled to do something grossly ugly such as writing a dozen expect scripts which use the root password then at least make it an entry in a configuration file so that it can be changed in one place. It seems that every time I get a job working on some systems that other people have maintained there is at least one database, LDAP directory, or Unix root account for which the password can’t be changed because no-one knows how many scripts have it hard-coded. It’s usually the most important server, database, or directory too.

Please note that nothing in this post is theoretical, it’s all from real observations of real systems that have been broken.

Also note that this is not an attempt at making an exhaustive list of ways that people may write horrible scripts, merely enough to demonstrate the general problem and encourage people to think about ways to solve the general problems. But please submit your best examples of how scripts have broken systems as comments.

First Dead Disk of Summer

November 20, 2009 | etbe

Last night I was in the middle of checking my email when I found that clicking on a URL link wouldn’t work. It turned out that my web browser had become unavailable due to a read error on the partition for my root filesystem (the usual IDE uncorrectable error thing). My main machine is a Thinkpad T41p, it is apparently possible to replace the CD-ROM drive with a second hard drive to allow RAID-1 but I haven’t felt inclined to spend the money on that. So any hard drive error is a big problem.

Fortunately I had made a backup of /home only a few days ago. I use offline IMAP for my email so that my recent email (the most variable data that matters to me) is stored on a server with a RAID-1 as well as on my laptop and my netbook. The amount of other stuff I’ve been working on in my home directory is fairly small, and the amount of that which isn’t on other systems is even smaller (I usually build packages on servers and then scp the relevant files to my laptop for Debian uploads, bug reports, etc.

The first thing I did was to ssh to one of my servers and paste a bunch of text from various open programs into a file there. That was the contents of all open programs, the URLs of web pages I was reading, and the contents of an OpenOffice spread-sheet which I couldn’t save directly (it seems that a read-only /tmp will prevent OpenOffice from saving anything). Then I used scp to copy 600M of ted.com videos that I hadn’t backed up, I don’t usually backup such things but I don’t want to download them twice if I can avoid it (I only have a quota of 25G per month).

After that I made new backups of all filesystems starting with /home. I then used tar to backup the root filesystem.

The hard drive in the laptop only had a single bad sector, so I could have re-written it so that it would be remapped (as I have done before with that disk), but I think that on a 5yo disk it’s probably best to replace it. I had been thinking of installing a larger disk anyway.

On restore I restored the root filesystem from a month-old backup and then used “diff -r” to discover what had changed, it took me less than an hour to merge the changes from the corrupted root filesystem to the restored one.

Now I have lots of free disk space and no data loss!

I am now considering making an automated backup system for /home. My backup method is to make an LVM snapshot of the LV which is used and then copy that – this gets the encrypted data so I can safely store it on USB devices while traveling. I could easily write a cron job that uses scp to transfer a backup to one of my servers at some strange time of the night.

The next issue is how many other disks I will lose this summer. I have installed many small mail server and Internet gateway systems running RAID-1, it seems most likely that some of them will have dead disks with the expected record temperatures this summer.

Debian SSH and SE Linux

November 17, 2009 | etbe

I have just filed Debian bug report #556644 against the version of openssh-server in Debian/Unstable (Squeeze). Â It has a patch that moves the code to set the SE Linux context for the child process before calling chroot. Without this a chroot environment on a SE Linux system can only work correctly if /proc and /selinux are mounted in the chroot environment.

deb http://www.coker.com.au squeeze selinux

I’ve created the above APT repository for Squeeze which has a package that fixes this bug. I will continue to use that repository for a variety of SE Linux patches to Squeeze packages, at the moment it’s packages from Unstable but I will also modify released packages as needed.

The bug report #498684 has a fix for a trivial uninitialised variable bug. The fix is also in my build.

Also I filed the bug report #556648 about the internal version of sftp being
incompatible with SE Linux (it doesn’t involve an exec so the context doesn’t change). The correct thing to do is for sshd to refuse to run an internal sftpd at least if the system is in enforcing mode, and probably even in permissive mode.

deb http://www.coker.com.au lenny selinux

Update: I’ve also backported my sshd changes to Lenny at the above APT repository.

etbe – Russell Coker

Linux, politics, and other interesting things

Author Archives: etbe