Since I've been getting our home network a bit better organised lately, the home server is now actually accessible from both the wired and wireless networks (and could be accessible from the outside, too, once I've sorted out suitable security measures), so it's high time I started making use of it.
The first thing I've done has been to set up a home Wiki. There's various bits of information that Sarah and I share, but that one or the other of us is 'in charge of' depending on whose computer it lives, so rather than putting a bunch of text files on the shared file server area, it seems logical to do it with a Wiki.
I'd been wanting to research the current state of the art in Wiki software anywhere; the only other Wiki I run, the ARMuC Wiki, runs on UseMod, which I've never grown to love properly.
Anyway, my researches led me to PmWiki, and I'm quite sold on it - it's written in PHP so doesn't require CGIs, and it has a software design philosophy that I agree with; a simple core with modular extensibility.
So we now have a Sutton's Mill Intranet for our domestic odds and ends. And with a little bit of simple plugin writing, the home page lists the status of important household sensors - currently just the incoming mains voltage and frequency (we get a lot of mains power problems out here!) and the battery backup system status, but hopefully soon to include external temperatures too.
We're using the Wiki to store our monthly budget, our goals for each month (chosen at the New Year), our template shopping list of things we need to check we have sufficient stocks of, and our list of favourite recipies (since we have a habit of forgetting them, then one day going "Blimey! I've not cooked that lovely Thai turmeric rice in months!"), and we'll shove more stuff in as we come up with it - basically, from now on, whenever one of us has to go and look something up for the other, we'll Wiki it for posterity.
Well, having eliminated the VLANs from my network problems, I've been busily taking advantage of them again, and working around the fact that daapd and samba don't seem to talk very well to iTunes and MacOS X's smbfs.
Read more »
Ok, having eliminated all VLANs from the equation, I still see iTunes connecting to daapd giving up a few tens of seconds into each song. So it looks like the latest release of iTunes doesn't like daapd for some reason.
However, SMB performance is still dreadful, with common "server disconnected" error messages.
I've confirmed it's not the LAN at fault (unless subtly so) by doing HTTP, SCP, and telnet-to-chargen and getting good rates.
Right now I'm trying an experiment with smbclient rather than the smbfs that comes with Mac OS X - and it seems to be running fine... so it looks like there's some problem between OS X's smbfs and the version of samba I have, which is just bizarre.
Perhaps I ought to set up Appletalk sharing - at least that way Sarah can access the household music collection, anyway...
Yesterday I configured Squid on my internal network; machines on the office LAN can use it if configured to use an HTTP proxy, while machines on the wifi LAN are forced to use it as a transparent proxy via port forwarding on the router (I'm slowly making the wifi LAN more and more like a cheap ISP's network - it's an open wifi, so I'm keen to force its users to be well-behaved).
The thing is, watching Squid's logs, I was horrified at just how few pages it felt it could cache. I'd always imagined, when developing Web apps, that anything fetched with GET could be cached for a while (and might even be prefetched). So when I actually dug a little deeper, I found that just about anything dynamically generated (including quite static pages that just use a bit of PHP to automatically include the same navigation in every page, with the currently selected option highlighted, for example) is, unless the script author has made special effort, generally not cacheable.
You can check the cacheability of pages with this useful cacheability testing tool.
Blog software is terrible at this, for example, despite generally having very cacheable pages
Rather than explain the rules in detail here, I'll link to somebody who already has. In particular, read the section on writing cache-aware scripts.
Read more »
Ok, suspecting that the MTUs might be a problem, I put an fxp ethernet card into the single PCI slot in my home server (ousting the SCSI card), since that card can support the large Ethernet frames required to have a standard 1500 MTU plus 802.1Q VLAN tags.
But, alas, things were little better. From a desktop machine wired into the same switch as the server I still can't do DAAP without iTunes randomly closing the connection in mid-stream, and from Sarah's laptop on the wireless LAN, she still can't do DAAP or reliable SMB file sharing (the connection keeps getting dropped). SMB seems OK from the desktop machine, however.
So I wondered if NetBSD's 802.1Q implementation might be the problem; since the old vr interface is built into the server's motherboard, I now have two NICs, so just put the server on both internal VLANs independently (with no 802.1Q). And it's no better.
I can imagine that iTunes might just be fussy about its DAAP implementation and not like something daapd (an open-source implementation of the DAAP music sharing in iTunes) is doing; but why should SMB also be unreliable? I tried SMB from my own laptop over the wifi link, and found it workable but oddly slow. I'm going to experiment further with connecting my laptop directly to the switch (on either wifi or internal VLAN) and seeing how it responds, I think... something's fishy!