Published by Jon on May 4th, 2014 in Debian | 1 Comment »
A couple of weeks ago I finally got round to doing some major surgery on iptables-persistent.
First of all it is principally now called netfilter-persistent (although the source package hasn’t been renamed) and has a plugin architecture so that it can be extended by other packages. One of those packages is iptables-persistent; others may follow. This opens the way to fixing #662743 and #697088 (patches always welcome).
There’s also a new binary to handle loading/unloading of rules, instead of having all the logic in an init script. I was therefore able to add systemd support as a first-class unit, and I’d appreciate patches for an Upstart service (as I’m largely unfamiliar with it).
Plugins are simply dropped into /usr/share/netfilter-persistent/plugins.d and must follow certain minimum conventions, detailed in netfilter-persistent(1). They can be any executable, so compiled or interpreted binaries are acceptable.
This release finally gets the magic 1.0 identifier. It reaches Jessie today, and is already in Ubuntu Utopic.
Published by Jon on August 2nd, 2013 in Debian | 4 Comments »
Some evil nasty cold callers who want to sell us windows and doors have been on the phone for a third time. Previously they have been cagey and haven’t given away any information that could identify them, except the name “Status”. They always claim to have made an appointment with the homeowner (that’s me) to call (which is a lie) but can never say who arranged the appointment because it’s “not on the file” (probably the only true thing in the conversation).
We’re listed at the Telephone Preference Service so this kind of call shouldn’t be arriving in the first place. However, the TPS gives very little recourse to subscribers when companies ignore it and call anyway.
Tonight I thought I’d got somewhere by feigning interest and getting a phone number out of them while I have a think about whether to replace our windows. That’s one piece of information I can access to make a start on finding out who they are. I was so surprised to get an answer straight away that I didn’t bother to gather anything else.
The number is for the regional branch of a well-known national children’s charity.
Published by Jon on June 19th, 2013 in Debian | 1 Comment »
Charlie’s birthday present this year, it being an important year:
I chose Wickers World for the flight, since they have sites nearby and seemed the most professional. We were lucky enough to fly on the first attempt and had beautiful weather, although there was rain behind us.
Published by Jon on February 13th, 2013 in Debian, Frivolity | 2 Comments »
From time to time it occurs that two people answer a mail in the same way where one would do – closing an unblock request, for example.
When this almost happened on debian-release the other day I amused myself by dreaming up an SMTP header that would prevent such embarrassment. I wasn’t being serious in the slightest, but nevertheless X-RaceProtection was born (and it turns out at least one resident of a certain IRC channel thought I was).
X-RaceProtection can be a message identifier or the simple value ‘yes’ and is intended to prevent duplicate replies to, for example, mailing lists. When set as a mail ID, list software should silently drop the message being delivered if the identified message has already received a reply – that is, another message quoting that ID in In-Reply-To. If X-RaceProtection is simply ‘yes’, the mail ID of In-Reply-To for the message being delivered is used, providing a shortcut.
This means you can set X-RaceProtection when replying to a mail where there is a chance of collision. If someone beat you to it, there is no embarrassment at your mail arriving with a later timestamp.
If someone fancies implementing this for smartlist/debbugs, please be my guest!
Published by Jon on October 14th, 2012 in Debian |
- It is important to rehearse your space carefully. Find a quantity of friends equal to the attendees you expect, lay out the intended room, and check that everybody has free and easy access to their chair.
- Invest in a decent access point and some power strips with a decent cord length.
- Relax. I cannot stress enough the importance of this step!
Published by Jon on August 13th, 2012 in Debian | 4 Comments »
Building things is fun, but sometimes it’s nice to have a little light relief with a sledgehammer. Saturday was one of those occasions; there
is was a ‘decorative’ wall in the corner of our lounge. It should have died about thirty years ago and I’ve hated it ever since we moved in a year ago.
First job was to remove the sockets and cable running up the side, which was a nice surprise in itself:
Looks like whoever installed it believed that mastick and wallpaper is a suitable covering to stop drill bits. Hmm.
Next we could take out the wall itself. In this case the wooden top was sealed down with more mastick and supported by piles of bricks, then the wall had been secured with concrete and not proper mortar. Fortunately a good sledgehammering soon took care of that:
Those bricks truly were hideous, and they are all around the dodgy gas fire and another similar ‘feature’ in the opposite corner of the room.
Incidentally, the newly-revealed carpet in the void should also have died in the seventies (it went straight into the skip), but at least now we have some understanding of the mysterious wallpaper we found under the stairs.
Finally we had enough room to work with surface trunking (a temporary housing until the gas pipe is removed and we can bury the cables properly):
And the final result, with the sockets moved to a more sensible level and the cable properly protected, new LightwaveRF sockets in the corner and a shiny new aerial point ready for cabinets to go into the gap:
13/08: A couple of people pointed out that in the first photo, the offending cable is in a protected zone. This is true, but it wiggles half way round the room from the CU in a similar fashion first – sometimes in trunking, sometimes clipped to the fireplace, and sometimes masticked and papered flush with the plaster surface.
Published by Jon on July 8th, 2012 in Debian |
When I first undertook the tracking of minor security fixes in point releases, I quickly out-scaled flat text files and a good memory. A Python library and sqlite database helped automate sending notifications and keeping tabs, but the manual work associated with tracking incoming bugs from the security team, applications to and responses from the release team, and the action or inaction of maintainers was still too time-consuming to be useful.
This weekend I deployed pyprsc2, with a public view at http://prsc.debian.net/tracker/<bug>. I had planned to do this at Debconf12, but given the circumstances… still, it needed doing anyway and what better time?
Result: my work now involves adding tracks where required; keeping an eye on the notified list for manual prods; and after a point release, archiving the included bugs and updating the suite version numbers. Bliss.
- automatic sync of metadata for new tracks
- automatic detection of bugs closed from unstable
- automatic notification (and unarchive if required)
- automatic, though manually triggered, prods
- automatic detection of stable/oldstable upload and RT acceptance
- public view of bug status, e.g. http://prsc.debian.net/tracker/660650
- finish the views so that bug lists work, as well as detail
- add process documentation pages
- iron out the mailing so bugs.debian.org doesn’t throttle back submissions
- add ways to permit more contributors
- refactor where required; this was a learning exercise too
- publish the code
prsc.debian.net leverages large parts of the Django MVC framework – in fact, this was really a learning exercise in disguise since I want to use Django on some more complex projects later. BTS synchronisation is handled by python-debianbts, and synchronisation with proposed-updates is through XML and lxml/objectify (thanks to the release team’s awesome XML queue viewer and Adam adding bug numbers to it). Since this was a learning exercise, some of the Python is probably questionable at best and downright wrong at worst, so it probably needs some work still.
Published by Jon on June 15th, 2012 in Debian | 1 Comment »
For two years I have been very fortunate indeed to be fully sponsored for travel and accommodation at DebConf – once on the Newbies programme, and once from normal funds. However, considering the cost this year (at least $1,000 in travel expenses) and of personal circumstances, which are not favourable, I am reliant on sponsorship this year even more than others.
However, although I have accommodation sponsorship this year I am still waiting to hear about travel. The local team have said they hope to provide details by 20th June, but it’s really too late by then – there is time off from work to arrange, flight tickets to purchase, vaccinations to have, and of course I could really do with not having to lay out that much money in the first place, even if it’s to be reimbursed later.
So at this stage at least, I am sad to say that I think it unlikely I will be there. I’m looking forward to Switzerland though; this time there might be two of us.
Published by Jon on March 3rd, 2012 in Debian |
Recently I had need to re-purpose a server and for convenience, I decided to do a complete wipe and reinstall since it had previously been used for all sorts of package testing, experiments,
dak debugging, the list goes on. I took a careful backup and then cooked up some USB installation media, but it took so long to boot (USB1.1, yay) I ran out of time before the building was locked.
Since this box has two hard disks, and not being one to back down from a challenge, I eventually reinstalled it over the weekend with nothing – no install media, no reinstall robot or intelligent hands – just a reliable internet connection and a healthy dose of courage. Here’s how.
Target: reinstalled machine with the same network settings, ssh host keys, and other minor configuration ported. The disk layout is to be RAID-1 containing LVM, with separate /var volume and separate /boot partition, also RAID-1.
- One disk in the box contained old data, so I cleared that out and wiped it (including the MBR for good measure) and partitioned it.
- I set up a degraded RAID-1 array for a small /boot partition, a large RAID-1 array for the LVM and a swap partition.
- I mounted the new partitions in the correct layout in /mnt and used
debootstrap(8) to get a very basic root set up. I also bind-mounted /sys, /proc, /dev and /dev/pts for now, they can be done properly when the root is a bit more mature.
- Next, I copied into the new root
chroot(8)ed into it. Now I could
tasksel install standardto get an almost fully-functional base system. At this point it is also sensible to install
dpkg-reconfigurethem, followed by
lvm2if required and
openssh-serverso you can get back in after rebooting. Some or all of these may already be installed by
- Time to install a kernel before leaving the chroot:
apt-get install linux-image-2.6, followed by
grub-pcwhich should detect both installations and set up menu entries for them.
- Back in the old system, I copied in the network, hosts, resolv and hostname configuration files, and set up
/etc/fstabto my liking.
grubto both hard disks if it isn’t already so (
dpkg-reconfigure grub-pc) and again check that it detects both installations and creates the right menu entries. At this stage, booting from either hard disk will allow the loading of either the new or old installations, which is exactly what we want. It’s now time to
umountthe new installation.
- Now I followed the excellent guide for remote kernel upgrades at http://ariekanarie.nl, except in this case we are using the same method to try booting the new system and fall back to the old one if it’s a disaster.
- Reboot and hope!
At this point I rebooted to find myself back in the old kernel, which was disappointing – this means the new kernel has panicked and rebooted, and grub has fallen back to the old system (exactly as planned). It turned out there was nothing in
/dev at boot time, and
udev doesn’t start early enough to populate it before panic. That’s easily solved by mounting the installation again and using
MAKEDEV as a seed.
- With a bit of luck, you’re now in the new installation and can
dpkg-reconfigure grub-pcagain to install
grubto both hard disks again. This isn’t strictly necessary, but it records this choice in debconf so future upgrades will automatically upgrade the bootloader everywhere it’s needed.
- Now I could do some tidying up, mount the old installation and copy over all the data I wanted, and after careful checking wipe the first disk clean ready to be added into the RAID arrays.
- Finally, add the old disk to the RAID arrays so they are fully redundant.