Pages

Thursday 29 January 2015

More fun with the pix

Now that I'm getting more familiar with the pix, there's one simple rule that I hadn't known before. It's to do with access control lists.

There's three interfaces, inside, dmz and outside. It's pretty obvious what those mean. But there's two directions, incoming and outgoing. You might think that anything going to one of your servers on the inside, must be incoming. But the pix doesn't see it that way.

You have to look at it from the point of view of the pix. If packets are moving from the pix inside interface card, to your inside server, then they're "outgoing", because from the point of view of the pix, that's what they are. And likewise with the other five combinations of inside/dmz/outside and incoming/outgoing. That had me badly confused for a very long time (years and years, actually). But I think I have it clear now.

So I cleared off all the rules that I've been setting up over the last two weeks, and started again. And I now have a much simpler, and (I think) better, configuration. Since the eta for the new line is weeks or months away (because of needing to dig up the road) I can experiment like this.

One of the things that the pix does that makes things easier, is you can define names for things. So, instead of having to refer to 10.12.13.14 I can define that as "mail1". Even better, I can set up groups, so I can define a group "allmails" as being "mail1, mail2, mail3, scrofula and heartburn". Because I know that these are the servers that will be receiving email, so I can set up my access rule with one line instead of five.

Likewise Samba. Samba needs access on  ports 139 and 445. So I've defined "Samba" as being those two, which means that whenever I want a rule about Samba, it's just one rule and not two.

But life wouldn't be complete without a "gotcha", and today's has had me foxed for over a week. It's to do with writing the pix configuration out to a file. One way is display it at a terminal, then cut-and-paste it to a file. But that's getting tedious. And there's a quicker way, tftp, the "trivial ftp" service. I have a tftp server set up, that was easy (courtesy of yum), but I just couldn't make the pix write to it.

Eventually, I discovered two things. The first is that tftp will only overwrite an existing file. It won't create a new file ... unless you change the server_args in the xinetd.d file to be like this:

server_args        = -c -s /home/drsolly/firewall

The -c tells it that it can create a file, and the -s tells it where.

So then you tell the pix what server to write to, which is easy, and then the pix wants to know the path. So, of course, I told it "/home/drsolly/firewall/pix.conf"

Because to me, "path" means the whole thing. But that isn't what is wanted here. The correct reply is "pix.conf"

Once I'd finally understood that, I can now write the configuration to a file. I also wrote the asdm program out to a file ... I wonder if I can send that to the pix515e that doesn't have one?


Wednesday 28 January 2015

Chopped liver

One of life's major pleasures, up there with chopped liver, hot salt beef sandwiches and configuring a pix, is bicycle maintenance. Here I differ from Jerome K Jerome, who opined that if anyone offered to maintain you bike, your should chase him away with a cudgel and terrible threats. Today was bike maintenance day.

The most urgent issue was the back tire, which had grown a nasty-looking wear around the sidewalls, and a bulge at a couple of places. I don't want to take the bike out for a 24 mile run with that threatening to end my fun at whatever moment it decides is most inconvenient (see Murphy's second law; when something does go wrong, it will do so at the worst possible time).

So, first I changed the back tire. I'm proud to say that I got the old one off without using a tire lever, just my thumbs. And I got the new tire on the same way. Then I spent ages wrestling with the gear shifter to get the back wheel back on, but eventually I got it right. Then I noticed that the front tire had the same problem, so I changed that too, This bike has only done 500 miles since I put new tires on it (I had to use tire levers for the front). I think the problem is that when it gets jammed up with mud and grit, that abrades the tire. I don't think there's much I can do about it - the mud is inevitable with the cross-country riding I'm doing, and I can't get it all off until I get home and give the bike a shower with the pressure washer. But a pair of new Schwalbe Blackjack Kevlar-reinforced tires is only £20 (I just ordered a pair on Ebay to replace the ones I just fitted) and 500 miles is 20 rides or more. The cost of these tires is totally dwarfed by the cost of the petrol I use to get to where I'm caching.

While I had the bike out for maintenance, I had a look at the pedals. They've been a bit stiff to turn. Nothing too bad, but they should rotate freely. The answer turned out to be a couple of drops of oil on the bearings.

At the same time, I checked the back and front brakes (it's deeply disappointing if they don't work when they're needed), made sure that the gears change as they should. And I oiled the place where the handlebars come out for folding, that was looking a tad rusty.

So now the bike is fettled and ready for her next outing.

Tuesday 27 January 2015

Port forwarding

While I was out, I was thinking. When I'm caching, there's several minutes between caches when all I'm doing is biking along, so there's plenty of spare brain to do some serious thinking with. And no possibility of interruption, which I fond very inconducive to deep thoughts.

Here's what I thought. Port forwarding. With a pix, you can tell it "if someone tries to access 10.0.0.1 on port 81, redirect that to 10.1.1.1 on port 80". So if I access 10.0.0.1 with my browser (but telling it to use port 81) I'll actually be browsing 10.1.1.1. That becomes very useful in the following scenario.

I have four remote rebooters; using those, I can reboot the attached computers from anywhere in the world. I've been thinking that I'll need four ip addresses for them, but if I use port forwarding, I only need one. The fact that they are accessed using weird ports, doesn't matter because Im the only person who will be using them!

And then I thought some more. I could put my mail server on the same IP address, and port-redirect it to the actual mail server. Likewise various other things. It all adds up to an economy in the use of IP addresses. Why is this good?

Because ip addresses are  in the form a.b.c.d, where abcd are each a number in the range 0 to 255. So there's only 4 billion possible IP addresses, and that might sound like a lot (and when they devised this scheme a couple of decades ago it was a lot) but it isn't. And the world has run out of IP addresses.

And, like any scarce resource, they'll get increasingly expensive. They say that god only made so much land and that's all there is (except if you're Dutch). Well, god only made 4 billion IP addresses, and you can't make more even if you are Dutch.

What's happening now, is that people are paying for IP addresses - my current colocation charges me £2 per month per IP. So you can see there's a real incentive to economise on the number that you're using.

And port forwarding can help do that.


More Essex Way

Today the weather looked good, so I dropped my pixification and went out caching. I'm slowly working my way along the new Essex Way series.

Today was Flower Day. Here's the first snowdrops of the year. I'd probably have seen some sooner, but I've been pixifying.


And also these:


And the daffodils are very early.


I did 25 miles today, on the bike, in  two segments, getting back to te car in between them for food and fresh batteries. I cached from 10 am till 6 pm, and managed 79 caches, and no DNFs. The track was good the whole way, although a bit muddy in places.

When I started off, I noticed an nasty-looking bulge in my rear tire. It's become very worn on the sides, and I don't know how that happened. I can only think that it was scraping against the build-up of mud that did it. Anyway, I decided to risk going out on the tire, but I'll be replacing that tire tomorrow.


I love this Pix 525

What's so nice about it is A) ASDM, the web-based user interface, which is *so* much easier than struggling with unfamiliar (to me) pix command line syntax, and B) the packet tracer, which lets me set up a set of access rules and NATs, and then lets me test to see if they work, without actually having to do it for real. Of course, I don't fully trust this simulation, but it certainly has helped me find a whole bunch of wrong thngs that I've done. And it's helped me understand the pix a lot better.

Of course, I can't use this 525 for real - that's why I got a couple of Pix 515E boxes. But the pix 515E that I have, doesn't have ASDM, and since it's no longer supported by Cisco, I don't think I'll be able to get ASDM for it.

Still - there's a workaround. I'm using the pix 525, via ASDM, to set up my configuration. And when it's ready, I can do a "conf term" to blurt out a text file, which I can then paste into the pix 515E to give me the same configuration.

So why can't I  use the pix 525 and forget the 515E? Because of the licensing. The unit I got, has a Failover licence. When I bought it, I didn't realise the implication of that - and that's probably part of the reason it was so cheap. The problem is that it reboots ever 24 hours. That's because Cisco don't want me to use it as my main firewall, they want me to shell out a lot more money for an "unrestricted" licence.

But I had a think. Yes, it reboots every 24 hours, but after the reboot, it's working fine. And I timed it, a reboot takes less than a minute. So out of every 1440 minutes, it's unavailable for 1 minute. That's better than 99.9% availability!

On the downside, when it reboots, all the connections are ended. So if I'm logged on to a remote computer, when the pix reboots, I'm suddenly not logged on, which might be annoying - I just have to log on again, no big deal. But since most of what I'm doing doesn't rely on continuous connection, maybe that won't matter. The 24-hourly reboot would be very unacceptable to a corporate IT center; they'd get a *lot* of complaints. But I think it might well work fine for me.

Still, I have the pix 515E, I'll use it. But it's nice to know that I can actually use the 525 as a fallback.



Monday 26 January 2015

Moving the robot arm

The Geocaching Robot Arm has always been popular. It's always been a maintenance problem, and now I had a new problem to solve. The problem is this. When I start using the new firewall, things like this should be on the DMZ; accessible to the public (but only via the web). The problem is, the Arm is upstairs in a cupboard, where I can keep an eye and ear on it. I can hear when it's being used, because I hear the whirr of the motors. And there's a light that switches on. Sometimes I hold up encouraging notices in front of the Arm. All great fun.

The problem is, the house network will not be on the DMZ, it'll be on the "inside". Because the servers on the "inside" should have no access at all from the world outside.

I thought of moving the Arm to where the other DMZ computers are, but that would be a significant effort; the cameras are all taped in place, the whole thing is a bit delicate, and anyway, then it wouldn't be near me while I work.

So I came up with a neat idea. The Arm is controlled by a Raspberry Pi called robotarm.drsolly.com. I Samba-mounted the Arm directory onto anotherRaspberry Pi called ffiop.drsolly.com, which is where all the other geocaching stuff resides, things like the Night Mail. And that computer is where the other DMZ computers are.

But it isn't just a question of making the data available, there's also the issue of controlling the lighting (which is done via a relay controlled over the USB port) and the Arm itself (controlled via a Pololu microcontroller that is talked to over a serial port). That's all now being done via an ssh tunnel. So, for example, to switch the lights on, it used to be:

hidwrite 0x12bf 0xff03 128

But I can't do the same thing from ffion, it's a different computer. I need ffion to give a command to robotarm.drsolly.com. And here's how:

ssh drsolly@robotarm '/home/drsolly/engine/hidwrite 0x12bf 0xff03 128'

Normally, ssh would prompt for a password before doing anything. But you can set things up so that you don't need to give the password each time.

And now the Robot Arm works, and I can put the computer controlling it (ffiop) into the DMZ where it will have the right firewall protections.

Messages from Mars

It isn't possible to use IP addresses like 10.x.y.z across the internet - those are used by companies internally. And anyone can use them. Likewise 192.168.x.y and some other ranges. But it is possible for someone outside my network to construct a packet claiming to come from such an address, and send to to my network. These are called Martian packets because packets can't actually come from there. This can be a symptom of an attack, or maybe of just a misconfigured system. Anyway, I don't want them. So I told my pix to deny them access.


Samba or nfs

There's two ways to share directories over a network, Samba and NFS. There's probably lots of other ways, but those are the common ones. The question is, which to use?

If your network includes Windows boxes, then you'll need at least some Samba, because Samba is the native Windows file sharer. So, for example, to access Dropbox, I use a Windows machine to handle the Dropbox, and share that across the network using Samba. And NFS is the native Unix file sharer.

I'm mostly Linux, with a couple of Windows boxes for the places that Windows really is needed (for GSAK, for example, and yes, I know you can run GSAK under Wine, but have you actually tried that? Not everything works).

Setting up the Pix firewall, brought this question back to my attention. Because it's a bit fiddly running NFS across a firewall, there's two ports to allow (111 and 2049), usng both TCP  and UDP. And then there's several other ports that need to be allowed, and you can't predict which ports get used. You can fix most of them, but even after doing that, the Pix reported attempts to use another port, and the port number was variable. Bah! With Samba, there's only two ports (139 and 445), and only TCP. So much easier to allow.

Finding a fix for the bug that was stopping me from using Samba on Fedora core 9, means that I can now use Samba wherever I want; before, I was forced to use NFS in the places Samba didn't work.

But then there's the question of speed. I googled, of course, and opinions are a bit mixed, but mostly come down in favour of NFS being a bit faster. So I did a speed test. I copied a 670 mb file from a shared directory to the local machine, and timed it. NFS ran at 10 megabytes/sec (which is pretty much the speed of my internal network, 100 mbit). Samba ran at 8 mb/sec, so NFS is 25% faster. This isn't a big deal. If there's something else going on at the same time on my network, that would impact the file transfer speed a lot more.

So I'm going to use Samba for most things, and NFS when that last ounce of speed is actually useful.

Saturday 24 January 2015

Fun with the pix

I had a flash of inspiration - I need a manual! The pix manuall, which I have as a PDF, is 1014 pages long, so I'm not going to print it out. And although I dare say it's a comprehensive reference, it isn't very easy to read and learn from. So I bought two books.

Cisco Networking for Dummies. Only a small part of this book is about firewalls, and it assumes that you have an ASA 5505. Which I don't.

Cisco Pix Firewalls. This is *much* better. For example, I'm finally convinced that "incoming" means from the point of view of the pix. So stuff that's travelling from my "inside" interface to the outside world via the "outside" interface, is "incoming" from the point of view of the "inside" interface, and "outgoing" from the point of view of the outside interface. Whereas access to my server from the world, is incoming from the point of view of the "outside" interface, but outgoing frmo the point of view of the "inside" interface.

So, I'm making some slight progress. But it's two steps forward, one step back,

For example. With Fedora Core 9 (which I run a lot of), is you want to mount a shared directory from the server "donor" to the server "recipient", the syntax is:

mount -tcifs -o user=niceguy,password=letmein //donor/usefulstuff /home/niceguy/stuff

But you don't want the world to know that your password is "letmein". So you make a file called "credentials", which looks like this:

username=niceguy
password= letmein

And you make that file readonly,  and only readable by niceguy. So now it's secure against prying eyes. This works well on many of my servers, but not on Fedora 9, and it took me a very long time to find this out. First, I was assuming that it was something to do with the firewall. Then I found that using the "mount -tcifs -o user=niceguy,password=letmein //donor/usefulstuff /home/niceguy/stuff" worked. So I went a-googling. And eventually I found something that inspired me to think that the answer was to leave the final byte (which is a newline) off the credentials file. but how to do that? A text editor wouldn't, I tried two hex editors that I couldn't work out how to reduce the file size by one byte, and eventually I used this:

echo  "username=niceguy" > credentials
echo -n "password=letmein" >> credentials
The -n says to echo "don't put a newline at the end".

And it worked!

But now I've encountered a nasty Pix problem. I'm going to need to be able to mount shared directories across the firewall. So I was doing just that, and nounting and unmounting happily, when suddenly it stopped working, and I hadn't changed the pix configuration. I was getting:

 %PIX-3-201011: Connection limit exceeded 10/10 for outbound packet from up-works/0 to vampire/38589 on interface  inside

vampire is a server in the "dmz", up-works is a server in the "inside".

So what's going on?

There's a limit on the number of connections that can be made from one server to another. I've set that at 1000 for these servers, so why is it thinking there's a limit of 10? So I googled the error message, and that led me to Cisco bug CSCsg52106. To read about it, you have to register. So I registered, although when I gave it the serial number of my pix, it said "Never heard of it", which I think might be because it's obsolete. But at least it let me read about the bug. They say that there's no permanent fix, and since it's obsolete (the expression they use is "end of life"), I don't think there ever will be a fix. They said that a temporary fix is to remove and add the static, but when I tried that, it didn't work. I had to reboot the pix with "reload in 1".

This is very unsatisfactory. If it happens again, I'm going to get worried about whether I can actually use this box.

One small plus - this happened on the pix 525, which isn't going to be the production pix, just the test pix. I'm hoping that the 515e doesn't give this problem.


Thursday 22 January 2015

Two more pixes

Two more pixes arrived, bought second hand on Ebay, delivered by Parcelforce. Some people have the plural as "pixen", but that's just too twee. These are pix 515e boxes, and I'm in the middle of copying the configuration that I've been setting up on the pix 525, onto the new pix. And it seems to be transferring without any difficulties.

The pixes came as a pair, costing £80, which is still a very good buy. The reason they're a pair, is failover. The idea is that if one of them stops working, for whatever reason, the other one picks up the load without a pause. On the other hand, I've been running the pixes I already have, non-stop for several years without a single failure. They are just that well made.

Unlike the Sonicwall. You don't want to hear about the sonicwall.

The pix I'm working on now, has six ports. One for inside, one for outside and one for the dmz. And three that I don't think I'll use (although one might be useful for the failover communication). It has 64 mb of memory, which might not sound like much, but the one I'm using to pass through 100 mbits is currently using only 16 mb of its 32 mb total, so I'm thinking that 64 mb will be plenty.

But I notice that the failover pix only has two network ports, which means I don't see how it can be used as a failover - there's no dmz. But I'm wondering if I can take one of the four-port cards out of the pix525 and install it in the pix515. It's worth a try!

The pix 525 will continue to the useful, even though it automatically reboots every 24 hours. I'll use it as a test bed for trying out configurations - you don't want to do experiments on a system that working full blast, because if you mess up the configuration of a firewall, you can suddenly cut off all communications.

Yum yum yum

I love yum. I really do. It makes life so easy.

In the windows world, you have to jump through all sorts of hoops to install software. Sometimes you need "activation keys", sometimes you need drivers that you need to go find. And always you need licenses to run the software, and woe betide you if you use it on more computers than you've licensed. And so it goes on.

Today, I needed a teminal program to run on a computer that didn't have one. So I did "yum install minicom" and a few minutes later, minicom was up and running. It's free software, so no license needed. Pretty much all software is free on linux.


I like to draw bandwidth use graphs, but I'm not going to do it with graph paper and coloured pencils. I use a program called "GD" to do it. I started using it so long ago, I can't remember what GD stands for. And it's archaic, but if I changed to use something else, I'd have to rewrite all my programs that rely on it.

So I needed to install GD on another computer. Um ...  yum to the rescue! yum install 'perl(GD)' and a few minutes later, there it was. And another program uses telnet from inside perl, so I needed Net::Telnet. yum install 'perl(Net::Telnet) - you get the idea.

Wednesday 21 January 2015

A bump in the road

I spoke to Talktalk today about the progress of my order, and it's bad news. Openreach (what you and I think of as BT) think that there might be a blockage in the pipe carrying lines along my road. To investigate this, they have to open a manhole and poke about. To open the manhole, they have to temporarily block the road, because the manhole is in the middle of the road. To temporarily block the road, they have to apply to the Buckinghamshire Highways Authority. And that could take weeks.

Worse - if there is a blockage, then it's a bigger job, and they'll have to apply again, to close the road for some while. And that could take months.

On the other hand, some very good news.

I had a small bleeding patch on my leg, which, after some months, wouldn't heal properly. Eventually, I took it to the doctor, who referred me to a clinic. There, I allowed a dab of cotton wool to be applied - this will be shown to a dog that's being trained to detect cancer. They don't know if this is going to be a useful test, but it's clearly worth trying, given the cost of the expreiment and the huge benefit if it's useful.

Then on to a surgical nurse, who said she was going to take a sample. And she gave me a local anasthetic, then carved off what I thought was an unnecessarily large chunk of skin, and sent it away for testing.

The test came back today, it's a "clear cell acanthoma" and is completely benign. The treatment, according to the web, is you give it a bit of a scrape and then it heals naturally, which is what has happened. Very good news!


Tuesday 20 January 2015

Not so pixie

Maybe that pix wasn't such a great buy. It has only a Failover licence, and today I found out what that means. It reboots every 24 hours. So you can't use it as the main firewall.

Oh well. It was pretty cheap, and I can still use it as a non-production firewall. I mean, I can use it to practice setting up rules, without messing up the main firewall in action.

It has a very nice web-based user interface, which has been very helpful to me in learning how to set it up. And setting it up isn't easy. It's the sort of thing where, until you have everything set up right, nothing works, and you have no idea why.

I have learned this - you have to look at the world from the point of view of a packet. So, suppose I have:

Server I that will be inside the firewall (inside means high securiry, computers I don't what the outside world to see).
Server D that will be in the DMZ interface (DMZ means lower securiry - the outside world can access them, for delivering email, for eample).

How do I allow server D to send data to server I?

Well. The inside network has servers with IP addresses like 10.x.y.z, and so the inside interface on the pix will be on 10.0.0.1 I will be 10.0.0.2

I'm putting the DMZ servers all on addresses like 192.168.y.z. So the DMZ interface will be on 192.168.0.1. D will be 192.168.0.2

A packet starts out on I, and I tell it to get to D.  So I tell it that it's trying to get to 192.168.0.2. And off it goes on its journey. And it says to itself ...

I want to go to 192.168.0.2. But I'm on 10.0.0.2, and when I look at my netmask (which is 255.0.0.0) that tells me that I can get to any other server 10.x.y.z, but to go to anywhere else, I have to go to my gateway.

The gateway on I is set to 10.0.0.1, so the packet trundles over to the pix, and the pix takse it under its wing. It notices that it comes from "inside" and is trying to get to DMZ, so it's going from a high security place to a lower security place, and that's cool - it's the other way round that the pix is mostly trying to stop (although you can set up rules to bar that). So the pix moves the packet from the inside interface, to the DMZ interface, and it also tells it that instead of coming from 10.0.0.2, it has to claim that it's from 192.168.111.2 (this is called NAT, network address translation) and lets it go on its merry way. Now the packet can see a server labelled 192.168.0.2, so it swims down the ethernet cable to get there.

But what if it's the other way round - suppose I send a packet from D to I. Now the packet is coming from 192.168.0.2, and trying to get to 10.0.0.2. The netmask is 255.255.0.0, which tells it that it can talk to anything that starts with 192.168, but for anywhere else, it has to go to the gateway. The gateway is set as 192.168.0.1, and that's the DMZ interface on the pix. So the packet goes there.

And now the pix gives it a thorough scrutiny. Where did you come from (source IP)? Where are you going (destination IP)? What to you plan to do when you get there (port address)? There's a set of rules that the pix applies, and only if the packet passes all the tests, is it allowed to proceed. If it fails any test, then it's killed. This might seem harsh, but  it's a cruel world.

If it does pass all the tests, then it's given a new identity. It is now called "10.0.0.1" - it's pretending to be from the pix, which in a way it is, and wearing this disguise (NAT again) it looks for its final destination 10.0.0.2.

And when it gets there, server I might be running firewall software that puts it through another set of scrutinies. But eventually, it makes it to where it was sent, and does whatever it was told to do.


So - what to do about the pix525? I've just bought a pair of 515E pixes for £80; one "unrestricted" and one "failover". And I'll just move the work I've done setting up the 525, over to those. The 515E isn't quite a beefy as the 525, but it should be beefy enough for me; the 525 has a throughput of 330 mbps, and the 515E is 190. Since my line will be only 100, the 515E should be enough. And I'll use the 525 for testing.

Saturday 17 January 2015

The punching pope

The pope announced that anyone who insults his mother can expect a punch. Well, naturally, I forgive him for his sin, but I'm quite surprised that he would say such a thing, even as a joke, because some people will take him seriously. Whatever happened to turning the other cheek?

If someone smote the pope on his right cheek, he's supposed to "turn to him the other also".
 But, of course,  in practice, the pope is just a fallible human like the rest of us, and says stupid stuff without thinking, just like the rest of us.

In the pope's opinion, "one cannot make fun of faith". In a sense, he's right - it's too easy a target. Making fun of someone dressed as the pope does, would be like making fun of someone dressed like a clown. There's no point - we can already see the absurdity.

But in another sense, he's deeply wrong. It would be wrong to poke fun at someone on account of their height, or hair colour. But it's fine to criticise ideas. If you think that an idea is wrong, it's perfectly fine to say so, and if it's so wrong as to be absurd, that that's worth pointing out.

And if you don't think that religion can be absurd, have a look at  Scientology for example, or Mormonism. 

Or the Church of the Flying Spaghetti Monster
 

Friday 16 January 2015

The Pix arrived

A big van pulled up and I was halfway to the door before the driver got out.

The box was a lot heavier that I expected. I have a pix 515, and I thought that the 525 would be the same thing, with a faster CPU, a bit more memory and more advanced software. But it isn't, it's a big heavy box (32 pounds), It has four 80mm fans cooling the inside; which is total overkill, but on a device as crucial as a firewall, overkill is very good.

First I looked at the documentation, and to my dismay, it was for a Juniper Router. Oh no! But a quick check of the box said "Cisco" and it has ten ethernet ports, as I expected.

So I powered it up, connected a serial cable to a computer (9600 baud), and up it came! It displayed its banner, and I learned that it has version 7.2 of the software. So I ran setup and gave it an IP address, and told it the IP address of the computer I'll use to manage it. And it wouldn't ping. Ugh.

After a lot of fumbling around (and it could have been far worse), I found, pretty much by accident, that it was thinking of itself as a standby device, not as the primary. And after a lot more fumbling, I hit on "FAILOVER ACTIVE" which made it come alive to my pings. Maybe there's a way to make it assume that on power-up?

It was set up with factory defaults, so I knew the passwords, which I changed immediately, and they're written down on a label on the pix, on the grounds that if someone gets close enough to steal the pix, I'm stuffed anyway.

A bit of bad news - the old "conduit" command (which is what I'm used to) has been replaced by "access-list", but the syntax is actually the same. And I found a manual for the software version 7.2

Since it has ten ethernet ports, I was going to use some of them. Port 0 is for the outside to connect to, that will go to the router when the new line arrives. Port 1 is "inside", that will go to the house network, and will have the highest security level (100), because no-one outside should have access to that. Next is port 2, security level 80, that's for servers that collect important data, but which the outside world needs limited access to (so they can send that data). Then level 50, which will be all the utility servers (email, DNS etc) that the outside world needs some access to (otherwise I don't get any email), and finally level 10, which will be the servers that will be heavily used by the outside world, and which don't have any important (to me) data on. So of the ten ports available, I'll only be using five, but that's fine.

The really good news, is that there's a very fine web-based system for setting things up, so I don't have to strain my brain working things out, and yet there's also a command line interface, so that once I've seen how to do a command (by setting it up with the web interface) I can just copy it for other servers that need a similar command. Very nice.

So, altogether, I'm very pleased with this Pix 525 that cost £45 and is worth twenty times as much. I checked on Amazon, a new pix 525 is $15,000.

Now I have a watch set on Ebay to get another one!

Wednesday 14 January 2015

Infrastructure upgrade

With the 100 mbps line arriving in the next few weeks (I hope) I've been thinking thoughts about infrastructure.

On firewalls - I like the Cisco Pix; there's a whole range of them, they're obsolete, and once you're used to programming them, they're easy to program.

I use a Pix 506e both here, and at my colocation in Cheltenham. Here, it's only having to handle 2mbps, but at Cheltenham it sits on a 100 mbps link, and it copes fine. But the specs for a 506e says "up to 100 Mbps throughput", and I'm always a bit nervous about that "up to" phrasing. So if it could only handle 50 mbps, that would still be "up to 100"?

So I'm thinking, maybe I should think about getting something beefier. I have a pix 515, that's capable of "up to 147 mbps" which sounds adequate.

But then I had a forage through Ebay, and I found a Pix 525 for £40. It can transfer 330 mbps. And, even better, it has 10 ethernet ports! What's the use of 10 ethernet ports? DMZ!

One is for inbound packets, and one is for outbound. So you always need at least two ports on a firewall, let's call them INSIDE and OUTSIDE. But if you have a third, then you can have less security on it.

So let's consider web access. You might want outsiders to have access to some of your servers, but not to others. The ones that you allow outsiders to access via the web, could be put on that third ethernet port, usually called "DMZ - demilitarised zone". And it means that you have a whole separated network, with no access from DMZ to INSIDE, so that even if (heaven forbid) someone hacked into a DMZ computer, they still don't get access to the INSIDE computers.

And the other seven ports? Most likely, I won't use them. If I were buying new, I wouldn't want them. But since they're alreeady there, I don't care. And maybe I can use them for something; I've found that often when I get something with more capabilities that I really need, I find a use for those extra capabilities.

And that's the great thing about buying obsolete corporate-type equipment. If you know what you're doing, you can buy fantastic bargains. No corporate IT department would buy an obsolete Pix as their firewall, they'd get something brand new from Cisco costing £500. Or £5000. Or £120,000.

But how obsolete is this? It can handle three times as much bandwidth as I actually have, it will give me a DMZ (and seven more DMZs if I want them) and if it should break down, I can always slide on my old Pix 515 or 506e until I get a replacement.

Or I could build my own firewall. I know I can do that, because I did; you just have three ethernet ports in a linux PC, and program the iptables. But with a Pix 525 costing only £45, I'd rather use that.

Sunday 11 January 2015

Upgrading my HP iPAQ 4700

I have an HP iPAQ 4700. It's essentially the same device as the Fujitsu Loox, which is my preferred caching handheld; far better than any Garmin/Etrex/Montana, because it has better screen resolution, uses CF cards that can store 16 gb (maybe more, I haven't tried), has replacable batteries ... anyway, I like it a lot. The trouble is, it's been a while since you can buy them, even on Ebay, because they stopped making them 10 years ago.

I'm OK for now - I have one that works fine, another that's pretty good, and a couple more in various states of "works well enough but not perfectly". So I had a sniff around, and it turns out that the Dell Axim X50V and HP Ipaq 4700 are essentially the same device with minor variations. So I bought one of each a while back (obsolete PDAs are pretty cheap), and today, I brought them out to have another look at them.

The Dell, which worked when I got it, doesn't seem to start up now. The HP starts up just fine ... but it's in German. My German isn't too good. So I went to the HP site to get a ROM in English.

They have them. But if you have a German ROM, they won't let you switch to English. It's a licensing issue, they say.

I tried. It wouldn't. I tried various ways to trick it into doing it, none worked. Eventually, I gave up, and I'll just memorise the German phrases that I need.

  ... update ...

I got the Dell Axim X50V working! I'll try it out tomorrow.

Friday 9 January 2015

I love rsync

I often find myself needing to copy an immense number of files, or an immense amount of data, from one place to another. A good example, is for backup. Until now, I'm been writing my own software to do this. But, as is so often the case, this is a problem that's faced a lot of people, and Andrew Tridgell (the man who made Samba, and if you don't know Samba, then you've never needed to network Windows and Linux computers together) has written a most excellent solution called rsync

It almost looks to me as if I've been wasting my time writing this backup software. Almost, but not quite, as I'll explain in a minute. But first, rsync.

The only thing it isn't obvious how to do, is copy files created only in the last few days, ignoring the great mass of files created years ago. But there's a way to do that, using find. Once you correct the slight error (+3 should be -3) it works a treat. I'm going to be using rsync in conjunction with find a lot in future.

But I hadn't been completely wasting my time. The way that this method works, means that you're pushing the files from the source to the destination. So, you're logged into the source, and your copying the files from there. And I want to do it the other way round; I want to pull the files from the source. I want to be logged into the destination, and copy files from the source.

This sounds like the same thing, what's the difference? The difference is bandwidth. I use three broadband connections for this. Broadband is cheap (but, I'm told, unreliable) bandwidth; in my area, you get 6 mbps for £15/month - my puny 2 mbps line costs me  £400/month. If I shopped around, I could get broadband even cheaper, when I see the ads on TV, they're almost giving it away. Plusnet offer "up to 17 mbits" (meaning 6 mbit where I am) for £2.50/month, if I switch to them for my phone. And when fibre eventually reaches the remote region in which I live, Plusnet offer "up to 76 mbit" (which means that they guarantee that it will never be better than that, not really a useful guarantee) for £20/month (plus £16 line rental). I'll have some of that as soon as it comes to the wild and woolly area I inhabit.

Because I'm pulling the files, I have a choice of three channels to pull the down, and, of course, I use all three. I have a little routine that means I can use all three at once. If I were logged on to the source computer and pushing the files, I couldn't do that.

Well, I probably could, by writing some clever software to run on the destination and issue commands to the source. But that's what I did in the first place.

In the longer run, I'm planning to replace my puny 2mb line (and three broadband DSLs) with a mighty 100mb line. This, I think, might arrive within a month or so, and I've been reorganising my infrastructure to get ready for it. And because there's been a falling trend in bandwidth costs over the last couple of decades, that 100mbit line is going to be cheaper that using a colocation service.

Thursday 8 January 2015

Month names

I've just noticed; the twelve months names start with letters in the range a to o. Nothing in the later 40% of the alphabet. That seems unfair to me; discrimination against the later letters. So I started thinking; maybe we could rename December to Xmasmonth, or something like that. But then I thought, no, there's a bigger problem. The months aren't in alphabetical order.

The month names are pretty weird. "July" is named after Julius Caesar, "September" is named as the seventh month. We could rationalise this.

The first month should start with an A, the second with a B, and so on. But then we get right back to the discrimination issue, so let's make that A, C and so on.

But there's 26 letters in the alphabet, and only 12 months. So let me close this with an interesting problem.

Should we have one more month, or two fewer letters?

A big file

I've got a big file. It's 26 gigabytes; it's part of a database system I wrote. To write it, I invented 40-bit integers - you don't want to know about it. Even the indices are indexed.

Anyway - I wanted to copy this big file, becasue the drive it's currently living on is reporting deterioration to an extent that I think it might fail within a year. I've got backups, of course. But I don't want to wait until it actually fails, because it'll fail at the most inconvenient time possible, because computers do that.

So I installed a 2tb drive, formatted it, and tried to copy the file. I tried with cp. I tried with scp. I tried with lftp. In all cases, the copy bombed out at 17 gigabytes, and I couldn't think what the problem might be.

Then I realised - it isn't 17 gb, it's 16 gb. It looks like 17 because I'm looking at it in decimal. And then I realised, I'd formatted that 2tb drive with 1kb blocks, because I was also expecting to store a lot of small files. But on an ext3 file system, if you have 1kb blocks, them maximum file size is 16gb. Bingo. So I'm formatting it to 4kb blocks, and then my maximum file size will be 2048 gb and I'll be a happy bunny.

Oh, and I also discovered something else. When I tried to scp that big file from another computer, it was copying at a rate of 9mb/second, which sounds great, except that I'm running a 100 mbit network, and 9mb/sec is 90 mbit. So that file copy was saturating my network, and nothing else could happen.

So when I tried to log into another server, nothing happened. And this was a server I've just upgraded in memory, so I thought it had crashed with a memory problem. In the machine room, I connected a monitor to that server, and the screen was blank. And I hit the keyboard a couple of times in case it was the screen-blanker, but it stayed blank.

So then I spent an hour swapping out memory, putting heat spreaders on memory, and putting the server back on the shelf.

Later (the next day) I noticed that the keyboard cable had come unplugged, so my hitting the keyboard wasn't deactivating the screen blanker. The computer had been working fine all along, it was just my self-imposed network saturation that made me worry, and the break in the keyboard cable confirmed my worries. Wrongly.

So in future, to avoid that problem, when I scp a huge file that's going to saturate my network for a long time, I'll use the -l option, as in -l 50000 so that the copy uses less than half my network capacity.

Wednesday 7 January 2015

The only way is Essex again.

This time I started at Chipping Ongar. Where do they get these names? Parking was a bit easier, but I still had to cruise round for a while to find free all-day parking.

I did one long segment of about 30 caches, and then back along the roads. Then a shorter segment that include the "pie" caches. And a couple of multis.

A lot of the route was along a river. The nice thing about cycling along a river is that A) there's no gradients and B) there's no muddy fields to cross. The not nice thing about cycling along a river is if you fall in. I didn't fall in.

40 caches found today.

Monday 5 January 2015

Pane is dead

I was setting up a couple of new servers. Usually, I just put the Fedora DVD in a DVD drive answer a few simple questions and it goes on, no problems. But lately I've been getting a problem.

This might be caused by the very old computers I'm using - I bought a batch of motherboards some years ago, and they were just right for what I wanted for a server, and I've been using them ever since.

The problem I get, is when I try to install Linux, Anaconda (the Linux installer) reports "Pane is dead" and dies.

The cure for this took me a few minutes to find, and it turns out to be quite simple. You can install Linux in text mode; when the opening screen comes up you hit the "esc" key, and at the prompt, you type "linux text". Now you install linux in text mode, and that works. But it's a bit tedious compared with graphics mode. So there's a better way.

You type "linux vnc".

That hums to itself for a bit, and then gives you a code, like 10.23.45.67:1

What's happened here, is it got an IP address from a DHCP server, and it's giving you its address. So you go to another computer running Linux, and run vnc, and when the box pops up to ask the code, you give it 10.23.45.67:1 (or whatever you were given by the computer you're installing).

After that, it's just like installing in graphics mode - all very easy and convenient.

But what I don't understand, is why it can do that, but not use graphics mode on the computer you're installing. Because it used to.

Saturday 3 January 2015

Weight report 85

Christmas is always bad for my weight. I weighed in at 15 stone 13 today, so not as bad as it might have been.

Friday 2 January 2015

The only way is Essex

A couple of weeks ago, hundreds of new caches appeared! These are along the Essex Way, a 81 mile combination of existing footpaths, bridleways and roads. I don't know why they do this; taking a bunch of existing tracks and claiming that they're something new.

But the caches - they're new. About 400 of them. Not to be attempted in one day!

The problem with caches like this, is that they're in one long line, unlike the circuits that I usually do, which take me round in a circle and get back to the car. So how to attempt these?

There's three ways. The first, and most horrible, is to walk several miles of caches, and then retrace your steps. Horrible because the walk back will be boring, unless you cleverly did every other cache on the way out. Even so, you're walking twice as far, and you're walking twice down a poor surface.

The second way is the way that many people use. They team up with another cacher, put a car at each end, then walk the route. That works well. I have a variation on this, where I leave the bike at the far end, walk the route, then bike back.

The third way is the way I went today. I took the bike along the route, and cycled back on tarmac roads, So although the way out was muddy, squishy and difficult, the way back was a piece of cake.

I had an immediate problem. The PDA claimed that it didn't have any map files. I don't know why, but it does this occasionally. But I have the solution - a spare PDA. Unfortunately, the buttons on the spare don't work, but that's only a mild inconvenience, because the touch screen does work.

I started at number 1; that's often a good place to start.  I finished at number 28, and cycled back on the roads to get back to the car for lunch. Then I relocated the car and did another 20 caches; out on the tracks, back on the roads.

I also had another go at "Toot Hill Trivial Pursuit", which ladysolly and I did a couple of years ago. Sadly, I didn't manage to find two of the caches, or the bonus (I guessed a couple of numbers). Today, I failed again on the two caches "Chicken pie" and "Pork pie", but I did find the bonus, which made me very happy.

The Essex Way track, I have to report, is muddy. Very muddy. Muddy and soft, not a good surface for biking, and parts of it are pretty poor for walking. Although it's not as muddy as it was this morning, because I brought quite a lot of mud home with me.

49 caches done today, and two DNFs

Thursday 1 January 2015

Vat done

To my surprise, I was called back by the Vat tech support people the very next day, but having been told that it would take a week, I didn't wait and registered as best I could. I think I've got it right. But they agree that the web pages for resistering for VAT MOSS are not easy to navigate.

And I've finished doing the software development. So now I know, for each of 28 countries, how much sales I make in each one, so in three months time, I should be able to use the VAT MOSS service and pay the right amount of VAT, which, I think, will be within a few percent of what I'd pay under the old rules (all at the UK 20% rate).

So why bother?

I think they've done this to get people like Amazon and Google. They're based wherever they say they're based, maybe in some low-tax country, and pay the taxes at that low rate. Under this new rule, they'll have to pay VAT on sales in the EU, even if they're based outside the EU. And if an EU country offers a low VAT rate (which is sort of against the EU rules, but you can have some things getting a special rate, like newspapers (why, I don't know)) then they'll still be paying the normal VAT rate on sales outside that low-rate country.

Anyway, as far as I'm concerned, I thnk it's done and dusted. Except I have a tough question to ask of my accountant - why didn't he tell me about this a couple of months ago?