Serendipity

Blosxom Plug-in: moreentries

The moreentries plugin for Blosxom, which gives "prev" and "next" links when an index exceeds a certain number of stories, did not work if the directory pathname contained special characters for regular expressions, such as '+' or '*' or '?'.

Steve Schwarz, steve at agilitynerd.com, did some good work on moreentries to add multiple prev/next pages, and brought the plugin up to version 0.3.

Version 0.4 (0+4i) solved the special characters bug for moreentries by quoting the regular expression it uses to select postings. It is also safe for Perl's "use warnings" and "use strict".

Version 0.4.1 (0+4.1i) correctly quoted a naked ampersand.

Version 0.4.2 (0+4.2i) added a fix where some installations of CGI.pm didn't give us the expected value of self_url, meaning that prev and next links in categories instead went to the blog top level.

Eldest Daughter wanted Vista on her emachines E520 laptop, so we shelled out the extortionate sum of 90-odd quid for a CD, a small brochure and a torn paper sticker with five groups of five letters on. Made sure I bought Vista SP1 so as to get the latest fixes and driver updates (this was before SP2 was released, of course). Oh how naïve I was imaging that to be the case ...

You might have thought that Micro$oft would ensure their flagship operating system comes with support for the most common hardware one is likely to want to install it on. Especially by the time it's had a service pack release. But no.

Have you got an Intel Mobile 4 chipset PCI, IDE or video ? Intel ? minor company, not worth Microsoft's while working with them for hardware support. Little yellow triangle with an exclamation mark, all over the hardware properties for all of them.

This is a bit of a problem if you also find that Vista doesn't support Broadcom 802.11 wireless - far too left-field mate, Vista doesn't support it out of the box. Little yellow triangles for wireless network drivers.

And Vista doesn't support the Realtek 8168 ethernet chip. Realtek, focussing on the cheap personal computer end of the market - not at all the business segment Vista Home is addressing, so little yellow triangles on the ethernet too.

So you install Vista, you have no networking at all and a fuzzy low-quality display, and you have to get this hardware into a usable state. Naturally I used a Debian live CD to go online and research what a pile of kak I'd just been handed by Microsoft.

I managed to find drivers for everything on the laptop manufacturer's website - except that the most recent Vista Broadcom 43xx wireless driver, 4.170.25.19, doesn't support European wireless channel range. The XP one is more recent and has this fixed, but not for Vista mate. If you drill right down into the driver properties you find that it offers two country settings in the Location dropdown: "US" and "Default". "US" apparently supports the US 801.11b/g channel range of 1 to 11, whereas "Default" offers the full range of .. yes, channels 1 to 11. Which is a bit stupid when you remember that everywhere outside the US and Japan actually has 13 wireless channels, so there is a 15% chance that your expensive copy of Vista will be a paperweight as far as any given wireless access point is concerned.

Having spent two weekends fighting this, it eventually turns out that the driver is properly written. You can edit the registry with the correct country code and you will get all 13 channels. It's merely the crappy installer written by Acer/eMachines/Gateway (the only people to have packaged the latest Broadcom driver as far as I can find).

To find the key use "regedit -v" and search for a Value field of "Country". Make sure you're looking at the Broadcom drivers by looking at the keys above and below it. If you're sure you are in the right place, then edit the Data field to say "GB". Repeat for as many copies of the registry key as you can find - there seem to be 3 on this machine. Reboot (we all know Windows needs to reboot every time you breathe) and you should now be able to access all 13 wireless channels.

If you stuff this up bear in mind that I know almost nothing about Vista and won't be able to help you fix it. But I hope the information is useful to anyone facing the same lack of 802.11 channel 13 with the Broadcom 802.11 Vista driver.

Blosxom Plug-in: last_modified

The last_modified plugin for Blosxom adds an HTTP Last-Modified header to each Blosxom generated page. This reduces your bandwidth needs by permitting browsers and spiders to check for updates to older stories with an HTTP If-Modified-Since, rather than retrieving the full page each time. It also allows proxies such as Squid to cache older entries whilst refreshing correctly when newer ones are added.

By default this plugin will scan the list of stories and use the timestamp of the most recent one as the Last-Modified header.

The plugin uses the timestamps in %blosxom::files, so it is compatible with entries_index_tagged and other plugins which set the story time, as well as with standard Blosxom use of the storyfile.txt modification time.

Other plugins may if they wish place a standard Unix timestamp in $last_modified::last_modified to override the default Last-Modified time.

Blosxom is a CGI script and, in its usual configuration, it considers everything under $url as a Blosxom request. This makes it awkward to serve up static files (for instance, images, movies or tarballs) from anywhere under the Blosxom root URL. You typically receive a cryptic message such as 'Error: I'm afraid this is the first I've heard of a "mp3" flavoured Blosxom. Try dropping the "/+mp3" bit from the end of the URL.'

There are a couple of plugins which attempt to deal with this - e.g. binary and static_file - but both have the disadvantage that the Blosxom script is still invoked for each static file. Of course you can put all your static files in a /images/ directory or similar outside the weblog, but keeping track of a large number of images then becomes cumbersome.

It must be better to let your webserver handle static files, a task for which it is optimised, rather than invoking a CGI for each image. For instance, in apache httpd.conf, if your blosxom script is named /usr/lib/cgi-bin/blosxom:

Requires Apache mod_rewrite (run a2enmod rewrite). Of course this will bypass any Blosxom authentication or restrictions, and any remote user who can guess a filename under the Blosxom tree can retrieve it even if it's not linked from anywhere. You should make sure that no unwanted files are accidentally exposed in your Blosxom tree and that any source or passwords are held outside the Blosxom <Directory>.

This doesn't affect the static rendering of dynamic Blosxom pages, which are held in $static_dir and not served directly. Although if you do use static rendering, you could get even cuter with your rewrites - mail me if you have any further hints and I'll put them up.

Thanks to Gavin Carr on blosxom-users for the idea.

I wanted to give you a meaningful <title> element according to the story or category you are reading. Here's the existing storytitle plugin, which takes the page title from the current story, modified by myself to add category titles. Depending how you are accessing this story you may see the browser title bar as "Serendipity", or as some substring of "Serendipity : Software : Projects : Blosxom", or "Serendipity : Hacking on the storytitle plugin". Now before you all shout I know there are half a dozen other plugins which do this :-) This is as much an exercise in plugin documentation to keep my hand in, until I have time to attack Blosxom itself !

Igal is a jolly useful little web photo gallery generator which is easy to get started with. You run igal in a photo directory and just upload the resulting HTML and processed images. It's probably most widely recognised for the default "film strips" effect, but you can customise the appearance quite well via its generation options and CSS. At the time of writing you can see some of igal's output in varying states of customisation in the Tunnels section of this website. Igal is written in Perl.

I submitted an improvement concerning file mtimes to the author Eric Pop. He wrote, "this does seem useful, and if i do get around to releasing igal 1.5 at some point, it will definitely make it in there!" I subsequently submitted that patch and a couple of others to the Debian maintainer of igal as well.

However Eric's own igal page seems to have dropped off the net so I am mirroring the work I've done on Igal here. I am hoping that I can hack on photogallery to the point where it can replace igal for my needs, so my Igal category may become purely historical in due course except to document these changes.

Serendipity is coded in Blosxom, a lightweight text-based weblog written in Perl. I've been talking on the Blosxom Developers mailing list about taking Blosxom back on maintenance and enhancement in an organised way. In the meantime I'm also trying to get some of the content published for which I actually chose Blosxom ! Here's the result of a bit of hacking on the photogallery plugin: Shefstock 2007.

The neat result is thanks to the original authors, but I've updated the documentation with suggested usages and techniques. I also added a feature to help integration by reading .caption files from the web gallery software called igal. I have quite a number of igal based photo galleries, and this will make it much easier to bring them across into Blosxom. I hope to add other useful gallery formatting options to photogallery, and to be able to preserve the igal look for existing igal galleries if it can be done easily.

From: Nick Leverton
To: blosxom-devel@lists.sourceforge.net
Subject: Re: [Blosxom-devel] Project status?
Date: Wed, 1 Aug 2007 18:03:49 +0100
Message-Id: <200708011803.53695.nick@leverton.org>
In-Reply-To: <20070801072437.GA19249@katherina.student.utwente.nl>

On Wednesday 01 August 2007 08:24, Matthijs Kooijman wrote:
> > This then gives a way to move Blosxom forward by taking the canonical
> > plugins as mainstream, so that the relevant features will work in the
> > same way for all plugin authors.
>
> Another thing that would be useful is to define some standards for how
> plugins should (roughly) do their work. In particular, it would be useful
> if plugins could define their own hooks, which yet other plugins could
> fill in. These hooks could be somewhat standardized (ie, all the
> different comment plugins calling a "spamfilter" hook that other plugins
> can use to implement blacklisting, or captcha's or stuff like that.

Certainly. In fact I've seen another plugin implementation, the one in
qpsmtpd, which has some neat ideas that I've thought about borrowing - many
of them are included in my lists below.

The following seem to me to be essential principles to help us get on top of
the plugins and base Blosxom functionality. I think they ought not to be
too disruptive to the existing code base. Some of them are things others
folk have mentioned here, which I hope I've represented fairly.

If we are going to get Blosxom more widely used, we will need both to make
packagers' jobs easier and also to make it simpler to configure a package
without editing static files, so I have tried to have regard for that as
well.

• As far as possible, any changes should be backwards compatible. If an
  incompatible change is unavoidable then consider introducing a new hook
  instead and deprecating the old one.
• All plugin hooks should work in the same fashion
• All plugin hooks should support being hooked by many plugins (and the
  plugins should cater for it too)
• The effect of having multiple plugins on one hook will be defined (and, so
  far as possible, will also be useful !)
• As far as possible, the order of plugins should not matter. Consider
  introducing new hooks where this would make logical sense.
• If ordering the plugin calls is unavaoidable, it will not require renaming
  files (though this can still be done, for backwards compatibility).
• So far as possible all dynamic information will be cached. There will be
  standard routines for accessing filestore through the cache.
• All plugin configuration will be supported via an external config file,
  without the need to edit the plugin code.
• Failure of or inside a plugin will not lead to failure of the entire
  weblog (this one has caught me so many times as I try out plugins !)

These are some thoughts about important but IMO less essential principles,
which might make it easier to implement some plugins or which address some
of the other concerns raised here:

• Plugins may choose whether to work on the semi-rendered output of the
  previous plugin, or on the un-rendered original. Default will be to
  continue on the previous output.
• Plugins may choose whether blosxom should continue processing a hook or
  whether the posting is now complete as far as this hook goes. Default will
  of course be to continue processing.
• It will be simple to define additional hooks for user requirements.
• Plugins wil lbe able to conditionally call hooks in other plugins (for
  interpolate_fancy etc).
• There will be a standard way for plugins to keep state. This will be
  cached and integrated with the dynamic information cache. It should also
  support non-cached BLOBS of some kind, for gallery plugins etc.

Any comments, additions, deletions please ?

From: Nick Leverton
To: blosxom-devel@lists.sourceforge.net
Subject: Re: [Blosxom-devel] Project status?
Date: Tue, 31 Jul 2007 13:03:54 +0100
Message-ID: <20070731120354.GC25392@leverton.org>
In-Reply-To: <A10A315B-8AD7-4FC8-8205-146494EBDDD4@barijaona.com>

On Tue, Jul 31, 2007 at 07:11:40AM +0300, Barijaona wrote:
> I'd prefer not change the spirit of blosxom, but recognize that its
> learning curve is really frustrating. So I suggest the following
> evolutions :

I very much agree that Blosxom is still a useful piece of software but
desperately needs updating in some areas. I write as someone who's set
out to evaluate several weblogs lately, including Wordpress, but who
has come back to Blosxom as by far the lightest-weight weblog for my
pathetic little 80Mb virtual hosting - not to mention having the least
complex code to hack on :)

For instance, many useful plugins are undergoing link rot as their authors
convert to other blog software and take down their Blosxom installations.
I spent ages last night looking for autoblock, textile and twikirender,
any one of which would have done to simplify my post formatting - all
have apparently dropped off the net. I can probably hack up a textile
plugin myself, it looks trivial, but I'd prefer if I didn't have to !

> - one should consider rehearsing blosxom's regarding its default
> interpolate routine and XML feed. Most users are expecting something
> more up to date in these areas, so why not give them out of the box
> the functionalities of interpolate_fancy and atomfeed ? The current
> situation makes blosxom appear really outdated.

> - there are a couple of blosxom starter kits (including a selection
> of plugins and flavours) floating around. We could encourage the
> creation of similar kits through "official" changes to the
> configuration variables in blosxom.cgi.

I agree it would be a worthwhile effort to gather together a set of
"recommended" plugins which we can then document, support, bugfix,
and accept enhancements for. Depending of course whether the plugin
authors agree, but most of them seem to have used the Raeality licence
so it ought to be a formality.

This then gives a way to move Blosxom forward by taking the canonical
plugins as mainstream, so that the relevant features will work in the same
way for all plugin authors. This will reduce the interdependency problems
I've run across, which are not always even declared in the perldoc.

I don't know if the Debian maintainer Gerfried Fuchs is here
directly ? I helped look at a security issue in the Debian version,
http://bugs.debian.org/423441, and though it's not an exploitable issue
in mainstream Blosxom I would very much like to improve the coding style
(apparently left over from Blosxom's earliest days) that let the loophole
creep in.

I have other vaguer ideas too, along the lines of overhauling XML and
interpolate() as you do, but just getting blosxom back into development
would be a great start !

Freemind: a mind mapper, and at the same time an easy-to-operate hierarchical editor

Description: A Java Program for creating and viewing Mindmaps

Taking the Concept-Mapping approach to Human-Computer Interface design. A mind mapper, and at the same time an easy-to-operate hierarchical editor with strong emphasis on folding. These two are not really two different things, just two different descriptions of a single application. Often used for knowledge and content management.

deb http://www.mirrorservice.org/sites/ftp.blackdown.org/java-linux/debian sarge non-free

Have Fun

My boss at the time bought one of these expensive high end gamer's laptops for development use, having ignored all my discussions with him about cheaper and more suitable machines. As we developed under Linux I had to try and get the hardware working before I could use it ...

Update: after this article was written, I suffered the most catastrophic filesystem corruption yet due to the Promise RAID driver bugs, and I was unable to recover from it. I gave the D870P back to my boss. After another six months, I saw him using it as a very hot, noisy and slow desktop, because the battery life had dropped to about 10 minutes ...

What Is It ?

Qmail is a modern replacement for sendmail, written by Dan Bernstein, who also has a web page for qmail. qmail is a secure package. There was a $1,000 prize for anyone who can show otherwise, which went unclaimed. Qmail is being increasingly used by savvy and security-conscious admins on the net. You can read more on qmail, including many other useful patches which work with it, on the Qmail Users' web site.

I've created a simple patch to qmail, which greatly simplifies the use of it on dial-up hosts. Until now it was not quite ideal for dial-up use, as it assumes the remote delivery path is always available, which when using dial-on-demand meant by default it would dial up straight away to deliver. This required additional software such as the use of serialmail, or else stopping and restarting qmail upon connection to pick up new parameters.

With this patch, which modifies only qmail-send, it's possible to hold and release the remote delivery queue at will, using a new parameter "holdremote", which will be re-read when qmail is kicked with a SIGHUP. Thus outgoing mail can be queued as normal, but with the holdremote flag set it will not be delivered. When going online, arrange in your ip-up script for the parameter to be unset, tickle qmail-send with a SIGHUP, and Roberta is your mother's senior sibling - all queued remote mail will be immediately rescheduled. When you go offline, set the flag again and re-SIGHUP qmail-send: any futher mail will be queued for next time.

There is also a holdlocal option for symmetry and because it virtually fell out of the code, should anyone find a use for it.

Why use this patch ?

Advantages of my method over serialmail are:

• serialmail is additional software and configuration beyond the basic qmail package which a user may download first time; with my patch there is no additional software (except the patch, obviously) or configuration.
• serialmail requires a looping call should more mail be queued whilst online; this requires installation of still another DJB package (daemontools). With my patch, further mail is delivered instantly by qmail as designed, with no extra load or complexity.
• multiple serialmail instances can end up being run at the same time (for instance if using diald set up by a naive admin) unless, again, daemontools are used, thus resulting in duplicated mail; with my patch, this cannot happen as only a qmail parameter is changed.
• using serialmail to forward to a smarthost restricts the amount of mail which can be sent at once; by sending the mail directly it can potentially be sent faster, as the full bandwidth of your outgoing link can be used by dispatching several mails at the same time.
• Using a smarthost introduces an additional Single Point of Failure into your outgoing mail. Dispatching it directly to remote hosts using their MX records avoids this.

You do not need (though may still want) this patch if:

• you have a permanent network connection for outgoing remote mail.
• you have a dial-up link but not over IP.
• you send remote mail immediately it's queued via a dial-on-demand dial-up IP link and are happy to continue to do so (typically applies to people who don't pay their own phone charges :-)).
• you send remote mail to different destinations via two or more different links (e.g. internal-to-work and net-at-large). In this case you will require serialmail, which is an excellent package for this purpose.

Download this Patch

At the time of writing, qmail is at version 1.03. There are versions of this patch for use with both qmail 1.01 and qmail 1.03. You need the qmail sources, to which you add this patch using the following command:

zcat qmail-hold-<version>.pat.gz | patch -p0

Then compile and install - simple as winking !

Using the Patch

Here are some script excerpts which illustrate how I use it.

Firstly, an extract from the script which runs when my PPP link to my ISP comes up (in my case /etc/diald/ip-up):

{ rm -f /var/qmail/control/holdremote
/usr/bin/killall -HUP qmail-send
} &

The following should be added to the PPP down script, for me that is /etc/diald/ip-down:

{ echo 1 >/var/qmail/control/holdremote
chmod 644 /var/qmail/control/holdremote
/usr/bin/killall -HUP qmail-send
} &

Finally, in order to ensure that Qmail starts up in the held (offline) state, you need to add the following to the script which starts it (for me this is /etc/rc.d/init.d/sendmail.rc, in the "start" case):

echo 1 >/var/qmail/control/holdremote
chmod 644 /var/qmail/control/holdremote

Hello! I'm Nick Leverton, and Warren was my first personal dial-up Internet host. Welcome to this archive of Warren's web pages, a copy of those originally hosted on Demon's server, to give 24 hour access to them even when Warren was off-line.

On Warren's pages here, you can read some background on its history, its family tree and its Internet software, as well as a load of useful information on configuring and using KA9Q.

Warren's History

In late 1991, the Internet was just starting to rise in profile amongst computing and networking professionals. Cliff Stanford of Demon Systems Ltd (suppliers of modems and networks to the gentry) floated the idea on CIX of a group of people clubbing together to buy their own link to the Internet, which as far as the uk was concerned was then the preserve of Academia and of a few large companies with private Transatlantic links.

I was one of the Founder Members of Cliff's "Tenner a Month" service, being one of the 130-odd people who paid a year's subscription in advance to get Britain's first public link to the Internet off the ground. It was a brave venture: at the time of taking the decision to go ahead, Cliff had fewer than half of the commitments he needed to break even.

As it turned out, Warren remained in daily service after the fledgling Demon Internet - hosted on a single Apricot 486 with eight modems and connected via what was then Pipex's transatlantic leased line - answered its first phone calls in June 1992, right up until I changed ISPs around year 2000.

Why "Warren" ? Well, an old friend used to call me "Leveret", and I rather liked the nickname. And I used to live on Warren Avenue, so the lapine connection amused me when I had to choose a demon.co.uk hostname. Unfortunately I'd forgotten at the time that hares actually live in scrapes, not warrens ... but only one person has ever pointed out the error !

Warren's Family Tree

1992 - Warren the First

An ICL PWS Model 80 - a 20MHz 386DX with 8Mb of 32-bit memory and two slow 80Mb ST506 disc drives. This machine still exists, and is still configured, albeit it has no permanent modem and only one working drive and indeed is rarely powered up nowadays.

1993 - Warren II

An AST Premium 386 - also a 20MHz 386DX with 8Mb of RAM, but a nice fast 100Mb ESDI disk, which made it much faster than Warren I despite both having the same processor speed. Unfortunately this machine no longer exists as some bastard stole it in an office break-in, so Warren Mk.I was pressed back into service.

1994 - Warren III

An ICL 486SX25, my desktop PC at the site where I was working (I'm a contract programmer). Using this machine I could keep myself up to date with software and hardware developments. I learned a lot of information about the powerful range of Unix utilties and I made a lot of use of them for my job. Withdrawn when I left, naturally, and once again Warren 1st was resuscitated.

1995 - Warren IV

An ICL 486DX2/50. Not much to say about it, it worked, until it was upgraded to ...

1996 - Warren v

a Fujitsu/ICL ErgoPro x Pentium, 75MHz, 16Mb RAM, 519Mb PCI disc, built-in 16-bit sound card and pci-bus ati Mach64 video. All plug-and-play, which seems to work surprisingly well. a nice little machine - if only it was my own ! (And if only I could persuade the boss to pay the very reasonable cost of OS/2 Warp version 4 for it ...)

Warren's Software

For most of its life, Warren has been running ms-dos, connecting to the Net via Phil Karn's shareware KA9Q package, as heavily customised for use at Demon. This provides good, fast, reliable Usenet, email, telnet and ftp and is excellent for use on machines of any class or age. I've always run it under Windows, using an old freeware version of wincron to dial automatically and collect news and mail in the small hours, thus minimising phone bills and maximising transfer rates on lightly loaded systems.

Warren Mk.I was also configured for Windows access via winsock, until the drive with Windows on it went west ...

Warren Mk.3 ran OS/2, v2.11, which I found to be an excellent operating system, and which knocks Windows (even Windows 95) into a cocked hat in terms of speed and reliability. OS/2 had all the features of Win95 over two years earlier, yet the computer press is only now raving over their inclusion in Microsoft products. And suddenly everyone who pooh-poohed their utility in OS/2 finds that after all they are useful, even essential, features. Unfortunately W95 users still don't get the stability, the memory management, the object orientation, the built-in Java, the integrated voice recognition or the performance that users of OS/2 Warp are used to. But hey, that's the power of Microsoft marketting for you. Prime candidates for being first against the wall when the revolution comes ...

KA9Q

When I used KA9Q for dial-up Internet access, I wrote a few notes based on my and other people's experience with configuring and running KA9Q.

Where Else ?

Please also see my current personal home page. I no longer maintain the Unofficial Uk.Singles Home Pages or the uk Railrover Ticket Summary.