Upstream has already accepted my patch to allow a build on NetBSD which is nice.

However, there is still a serious issue - GoAccess burns a LOT of CPU. With older versions it wasn’t too onerous, but now it uses 4 threads and CPU was going through the roof on my poor web server. Luckily it turned out it was a simple patch.

This is a good example of why we always want to check for errors. POSIX usleep documents that if a value of 1000000 or greater is given then EINVAL is returned immediately. The default value GoAccess was using for following the tail of the web log file was also defined as 1000000, which means on a POSIX compliant OS like say NetBSD, the usleep call did exactly nothing. Hence burning the CPU time. With this patch, CPU time is now barely measureable :)

But we can still make it GoFaster :D

While the CPU was being pegged I noticed it was stuck in the select state. Well, select(2) is not the greatest API ever made. Luckiy, we now have poll(2) which is a massive improvement and as it’s a POSIX standard, highly portable as well. After a few hours of work, I turned out a a fairly complex patch and it works very well! It’s been running on my web server all night and the websocket just ticks over. The web page I’m looking at constantly updated itself.

Huge win for my low powered server, now consuming less power and a great start to the New Year!

But first, let us discuss …

The POSIX Resource Limited sandbox

POSIX documents setrlimit(2). Disabling the ability to open new files, sockets, etc, or create new processes is actually pretty powerful.

Thanks to the privsep dhcpcd now has to support both Capsicum and Pledge, this turned out to be pretty easy to implement. The only issue with this is the poll(2) interface which dhcpcd makes great use of. Implementations found on Linux, OpenBSD and Solaris return EINVAL when the nfds argument is greater than RLIMIT_NOFILE where-as the other OS’s dhcpcd supports don’t. This means that on Linux, OpenBSD and Solaris an attacker could close an exiting file descriptor and try to open a new one. On OpenBSD this is not that much of a big deal because pledge should stop that from happening. On Linux and Solaris, they can’t open a file thanks to the chrooted empty directory but they can create a new one. But thanks to RLIMIT_FSIZE they can’t actually write to it. At most they could create a network socket and send arbitary data over it. For Linux, we could look into using seccomp to stop this.

For implementations such as NetBSD and FreeBSD, setting RLIMIT_NOFILE to zero with poll(2) still working means they cannot create any few file descriptor. This means that if an attacker breaches a resource limited process it can only work with the resources it has because it cannot fork another process, nor open any files, sockets, etc. It’s also running as an unpriviledged user locked in an empty directory, so there is nothing to see or do there. All the resources it currently has are:

• PF_INET, PF_LINK, etc sockets that can only query for data
• network proxy process (receives only, does not send)
• BPF processes (send and receive, the read and write filters are also locked)
• privileged actioneer (filters ioctls, validates paths and outbound traffic)

So the only way to do anything outside of what dhcpcd normally does is to use a facility that does not need to create a file or socket, or fork a process. The only remaining avenue of attack is to break the privileged actioneer process- that cannot be protected by any sandboxing as it needs to do a lot of stuff. Both OpenBSD’s and FreeBSD’s dhclient have such a privileged process as well.

The priviledged actioneer process itself doesn’t do a great deal. For example to add a route on BSD you create a RTM_ADD message. The master process will do this and instead of writing to the PF_ROUTE socket itself it will pass the message to the privilged actioneer process which in turn writes to it’s PF_ROUTE socket. Every ioctl, path accessed or network bound packet is validated by the privileged actioneer. Even though it’s generic, it’s also locked down.

So what extra to Capsicum and Pledge bring to the table?

Both bring system call filtering. For example, sysctl(2) does not need to create a new resource. Information available to the ordinal user such as uname may not be desirable to leak to these sandboxed processes. But then the question to ask is what can they do with it?

Pledge overcomes the RLIMIT_NOFILE limitation for poll(2) on OpenBSD.

Capsicum goes a bit futher by limiting rights of each resource you have in terms of what you can do with them.

What they both bring to the table though is making sandboxing easier. Here, Pledge is the outright winner. As I pointed out in my initial blog post, Pledge is really easy. But make it too easy and it’s not as secure as it could be. Capsicum is harder and the resource limited sandbox is harder still.

The take-away point from this is while Capsicum and Pledge are nice, they don’t beat a good design.

Capsicum is hard to develop for

It’s either on or off. You can limit each FD with capabilites mode off, but I’m not sure what that gains as it’s mainly there to allow the FD to be used in the restricted world so we can treat it as either on or off really.

Pledge is granular, you can turn areas on or off. For example, you can allow full file access while restricting various ioctls. Ideally, the only thing you want to pledge is stdio, which is kinda needed for the Privilege Separation IPC to work. However, we end up pledging dns inet and route as well.

So why is Capsicum harder? Well, the short answer is that it’s not. The long answer is that it’s perceived to be harder because you have to do all the work up front to get your code working whereas Pledge allows you do it it piece meal.

Pledge is as secure as Capsicum

As I said in my prior post, I’m not a security expert, but here’s my findings:

You can make Pledge as secure as Capsicum, but you don’t have to.

As a user on OpenBSD I can see lots of processes marked with p to indicate they have pledged something. What that something is though is a black box. You can use ps-o pledge-p $pid to show the promises a process has pledged. The more promises you see the more that process is allowed to do. Short list good, long list bad.

As a user on FreeBSD I can see lots of processes marked with ‘C’ to indicate they are in Capsicum Capabilites Mode. Because this is just on or off, I know exactly what this process can and cannot do.

Armed with this knowledge I would trust a Capsicum enabled application more than a Pledge enabled application. But to fully trust either you still need to audit the code.

They both have limitations

With a Pledged process you cannot change a BPF filter with the bpf pledge. This is unfortunate, a possible solution could be to spawn a process AND filter for every address you want to monitor for DaD or ARP pinging. That could be a lot of resources wasted as BPF is neither infinite nor cheap.

With a Capsicum Capability Mode enabled process you cannot call sendto(2) that is not connected. Unlike the above, there is no easy solution. I can’t spawn off another process because unlike normal communication, because I need to bind to the bootpc and dhcpv6-client ports so I can dictate which source port is used to send the message. The binding would then fail because the network proxy process is already using the port. A possible solution is to call RTM_GET to work out which host I send to on the local network, craft the packet by hand and send it out using a BPF socket.

I strongly feel that both should be fixed upstream:

• the bpf Pledge should allow changing the BPF filter.
• Capsicum should allow sendto unconnected if bound to a priviledged port or another capability created to grant to the socket.

As it stands, dhcpcd does not Pledge for BPF processes and does not run the generic network proxy process in Capsicum Capabilites mode. However, both processes are using the unprivileged user and chrooted to an empty directory. Neither do any processing of data coming in, they just ferry it back to the master process via IPC which runs under the same restrictions but is also sandboxed with Pledge or Capsicum so I’m confident that it’s good enough.

The good news is that basic Capsicum support has been enabled in this commit by ensuring all the file descriptors of the network facing processes are limited in their capability. The bad news is that capability mode is only enabled for the BPF processes- the end goal is that the master process is at least placed in capability mode.

So what’s the problem? Well, the first problem is that Capsicum is really hard to use, a lot of this is not helped by the documentation. It took a long time to work out how it works and how to use it. The second problem is that capability mode is really hard core- it stops a lot of stuff working dead in it’s tracks by killing access not capability limited in the global namespace.

From dhcpcds perspective the big issue is that gethostname(3) and getifaddrs(3) won’t work. This is the biggest show stopper, hard to IPC.

EDIT: gethostname(3) does work in Capsicum capabilities mode.

Let’s just take a moment to talk about getifaddrs(3)- it’s a really powerful interface to work out what interfaces are available to work with. In some OS it’s the only mechanism to get the hardware address assigned to an interface. Also, it’s possible for the route(4) (or netlink(7)) socket to overflow so it’s required to re-learn the system state which means it cannot be cached. Not that FreeBSD supports reporting route(4) overflow, but that’s another story.

Due to the getifaddrs(3) show stopper, I decided to look into OpenBSDs pledge(2). While the documentation is still very technical, it’s easier to read and understand compared to Capsicum. It’s also really really really easy to implement in comparison as you only pledge features rather than each file descriptor. Because of this, it’s also very granular. The initial commit to enable pledge is mainly allowing the current ioctl IPC framework to pass data back again.

But can we do better? Can we operate with the same Pledges that OpenBSDs dhclient(8) uses? The answer is of course YES! By caching some initial data that does not change such as utsname and machine uuid AND moving all file IO to privsep, this commit allows almost perfect Pledge support. We could go better if privsep gains support for the SIOCGIFGROUP ioctl as this would allow the inet pledge to be dropped. It’s not quite perfect because a Pledged process cannot change a BPF filter. We would need to space a BPF process per address which is then limited by the number of BPF instances you are allowed. I’m not sure this a good thing, and ironically BPF processes are the one thing we have in Capsicums capability mode. This is also a massive improvement over the initial dhcpcd-9 release because it means we no longer need any files in the chroot directory and /var/empty can be used again. This alone should make current and new FreeBSD users of dhcpcd quite happy. It will also go some way to enabling capabilities mode for the master dhcpcd process in the future.

Now, I can’t say which technology is more secure- that’s really not my field of expertise. I can’t even say if either are really needed or actually make security worse because Privilege Separation IPC adds more code, complexity and as such could make it more prone to bugs some of which could be a security attack vector in itself.

But what I can say is that Pledge is much easier to develop for because it’s really granular unlike Capsicum which is either on or off or per fd limited.

I’ll continue working on Capsicum support in dhcpcd just to see if I can enable Capabilites Mode in the master process. When that’s finished I will do a more in-depth comparison of these two technologies.

Since I was the main protagonist in bringing terminfo to NetBSD, I had a reasonable grasp on how our curses worked and I had looked at this bug before, but left scratching my head over it.

Since I looked at it, Valery Ushakov added a simple test case to demonstrate the issue.

#include <curses.h>
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main()
{
	const char *errmsg = NULL;
	int err;

#define CHECKERR(_msg)					\
	do {						\
		if (err != OK) {			\
			errmsg = _msg " failed";	\
			goto out;			\
		}                                       \
	} while (0)


	WINDOW *scrw = initscr();
	if (scrw == NULL)
		errx(EXIT_FAILURE, "initscr failed\n");

	if (!has_colors()) {
		errmsg = "no colors";
		goto out;
	}

	err = start_color();
	CHECKERR("start_color");

	err = init_pair(2, COLOR_WHITE, COLOR_RED);
	CHECKERR("init_pair");

	int maxy, maxx;
	getmaxyx(stdscr, maxy, maxx);

	WINDOW *lborder = newwin(maxy- 1, 1, 0, 0);
	if (lborder == NULL) {
		errmsg = "newwin failed";
		goto out;
	}

	wbkgdset(lborder, COLOR_PAIR(2));

	werase(lborder);

	mvwaddstr(lborder, 0, 0, "A");
	mvwaddstr(lborder, maxy- 2, 0, "Z");

	wnoutrefresh(stdscr);
	wnoutrefresh(lborder);
	doupdate();

	sleep(5);
out:
	endwin();

	if (err != OK) {
		if (errmsg == NULL)
			errmsg = "unknown error";
		fprintf(stderr, "%s\n", errmsg);
		return EXIT_FAILURE;
	}

	return EXIT_SUCCESS;
}

He then noted that using wbkgd instead of wbkgdset makes it work.

Now, the difference between the two is that wbkgd forces new attributes on the whole window background, whereas wbkgdset sets new attributes for new actions on the window. Keen observers will notice that the following function called is werase, which does what it says on the tin and erases the window but also resetting the attributes of the contents. So, I looked at this function and noticed the attribute checking code was faulty and a simple fix was enough to solve it!

Valery then pointed out that wclrtoeol probably needed fixing to and as it turned out, wclrtobot likewise. As it transpired, all 3 had different logic in working out when to erase something! We went through a few iterations of patches to harmonise the code and have settled on a macro that all 3 now share, so hopefully no more erasing issues in our curses.

As a follow on task, I should go through the NetBSD bug backlog and see if this fixes any other reported issues.

Infact, such a terminfo description was imported where colour pairs for screen-256color went up to 65536 which exposed a bug in the existing implementation where it was set to zero. Because the number might mean something more than a range, we need to be able to store it accurately.

This requires a version bump because whilst the API hasn’t changed thanks to C int promotion, the ABI has. Also the underlying database structure has changed as well- we now store the numeric parameter inside a uint32_t field rather than a uint16_t one. Whilst this change can still read the old style database, the old one cannot read the new one and thus we now maintain the database as terminfo2.cdb, leaving the old library and database alone so old programs still work fine.

libcurses, libfrom, libmenu and libpanel have also been bumped to accomoate this change.

So far, my structures in dhcpcd are long lived- or rather the scope is design to live outside of where it was created. As such they are created on the heap and are at the mercy of malloc. Generally I use calloc so that the whole area is inited to zero as uninitialised memory is bad.

So I decided to start out and see if I can just create the structures I need on the stack. Turns out I could! Yay! Now, how to you initialise a structure on the stack to all zeros? First let us consider this structure:

struct ps_addr {
	sa_family_t psa_family;
	union {
		struct in_addr psau_in_addr;
		struct in6_addr psau_in6_addr;
	} psa_u;
#define	psa_in_addr		psa_u.psau_in_addr
#define	psa_in6_addr	psa_u.psau_in6_addr
};

The first way is memset:

struct ps_addr psa;

memset(&psa, 0, sizeof(psa));
psa.psa_family = AF_INET;

But what if you could avoid memset? Luckily the C standard allows setting any member and will zero all other members. So we can do this:

struct ps_addr psa = { .psa_family = AF_INET };

Wow!!! So simple. This reduces binary size a fair bit. But then I turned on the Memory Sanitiser and boom, it crashed hard. Why?

The answer is simple- padding. Eric S Raymond gives a very good writeup about the problem. Basically, the standard will initialise any unintialised members to zero- but padding added for alignent isn’t a member! So we need to ensure that our structure requires zero padding.

Here is the new struct:

struct ps_addr {
	sa_family_t psa_family;
	uint8_t psa_pad[4- sizeof(sa_family_t)];
	union {
		struct in_addr psau_in_addr;
		struct in6_addr psau_in6_addr;
	} psa_u;
#define	psa_in_addr		psa_u.psau_in_addr
#define	psa_in6_addr	psa_u.psau_in6_addr
};

And it allows the former structure initialisation to work and memory sanitisers are happy- so happy days :) Now, if anyone can tell me what I can use instead of the magic number 4 in the above I’d be even happier!

Now, to be clear, you have been able to do this since forever using fopen, writing to the file and then allocating your area based on the final file size. Still, it requires some memory management still but more importantly it writes to a file. Writing to a file is slow and reduces the life span of the disk you’re writing to. It’s only been fairly recently that tmpfs was a thing, but even today not all OS’s have /tmp mounted as tmpfs. Requiring this isn’t exactly ideal for a generic program to do- the setup and install should be easy. Because of all these reasons, most programs worked the string length needed and either allocated an area or string and then finally write the string. However, while saving the disk, it’s also a lot more error prone because you need to work out the length of everything and that’s not always trivial, especially for things like a DHCP client which is always building strings based on the information given by the DHCP server.

Here’s an example of open_memstream in action:

/*
 * Example program which manages an area of environment strings
 * to send to child programs.
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static const char *foo = "foo";
static const char *bar = "bar";

int main(void)
{
        char *argv[] = { "/usr/bin/env", NULL };
        char *buf, *ep, *p, **env, **envp;
        size_t buflen, nenv, i;
        FILE *fp = open_memstream(&buf, &buflen);

        fprintf(fp, "FOO=%s", foo);
        fputc('\0', fp);
        fprintf(fp, "BAR=%s", bar);
        fputc('\0', fp);

        /* We could keep fp around as our area and just rewind it. */
        fclose(fp);

        /* execve relies on a trailing NULL */
        nenv = 1;
        for (p = buf, ep = p + buflen; p < ep; p++) {
                if (*p == '\0')
                        nenv++;
        }

        /* reallocarray(3) should be standard really */
        envp = env = malloc(nenv * sizeof(char *));
        *envp++ = buf;
        for (p = buf, ep--; p < ep; p++) {
                if (*p == '\0')
                        *envp++ = p + 1;
        }
        *envp = NULL;

        execve(argv[0], argv, env);
}

As you can see, we only manage the environment array handed to to execve. open_memstream is managing our string area and fprintf is working out the length each string needs to be for us. This vastly reduces the complexity and increases the security and reliabilty of creating large environment strings, which most DHCP clients do. We could also write a helper function to write the string AND the trailing NULL terminator for the string to be more efficient. You’ll get to see this in dhcpcd-8 which should be released later this year.

• Very low extra memory needed for it’s implementation
• Fast at insertion and removal operation- both are O(1)

However, it’s just a list. And like any list, to find something we need to pick a starting point and then search in a single direction and match each item until we find it. This is described as O(N) and it’s performance roughly corrolates to the Number of objects in the list. If you need to insert at an arbitary point (for example to order the list) you need to search it, so this is O(N) also.

But is this slow?

Typically for dhcpcd, the answer is no because on a desktop, tablet, phone or SOHO router you only have a handful of objects in all the lists. However, someone ran dhcpcd on a switch with millions of routes and dhcpcd was taking minutes of CPU time for routing table modifications. So in this corner case … yes! dhcpcd is slow! A suggestion to improve matters was given in that report- use a Red-Black Tree instead of a Linked List. A RB tree guarantees O(log N) performance for searching. A patch was even submitted based on OpenBSD’s tree implementation! This reduced the dhcpcd runtime from minutes to seconds in his situation.

Now you can’t just swap in a RB Tree for a Linked List. Each object within an RB Tree has to have a unique key. Also, you need to have comparison function to define an order to the objects within the tree. Only then can you start to implement it. To find an object within the tree, you just need to know it’s key and off you go. I settled on using NetBSD’s rbtree(3) implementation instead of the initial suggestion to use the generic BSD tree(3). This mainly to reduce the binary size of dhcpcd because it’s in libc on NetBSD and on other systems it will creates a smaller binary due to the complexity of the tree(3) macros. Testing also showed it was slightly faster and also easier to actually develop with.

So should you replace all LinkedLists with RB Trees? No! That would be silly :) After all, sometimes you don’t actually need to search or order a list- a lot of the time, lists are used for push/pop operations and thus gain nothing from RB Tree.

You’ll get to see this in dhcpcd-8 which should be released later this year.

But this came with some issues:

• There is a window where the IP address doesn’t exist, and the kernel may wipe out the subnet route at that point also.
• DHCP renews didn’t come through to the right interface.
• Some kernels didn’t like the address moving interfaces.

Still, to the best of my knowledge, no other product has this feature and for the most part, it did work well allowing almost seamless switching of wired-> wireless and back again with both using the same IP address. But that wasn’t good enough - I was challenged to do better!

So I took up the bat and changed the behaviour to this:

• Each applicable interface will have the shared ip address.
• Whenever the address is added, the most preferred address will be ARP announced.

And lo - IT WORKS!!! The changeover when plugging/removing the wired interface is 100% seamless for me. ssh, ping, etc get zero interuption. Of course, YMMV ;)
But there are some costs:

• Thanks to ARP, only the primary interface will receive DHCP unicast messages for other interfaces.
  As such we need to re-direct them to the correct interface by examining xid and chaddr.
  This means we have to relax the BPF filters to allow more through.
• Kernels supporting RFC5227 will double ARP announce the address.
• NetBSD-8 kernels needed some love to get it to work and there’s still an issue with it not working when an address is deleted from the interface.

Only the last bullet is really important, which is mainly why the changeset hasn’t hit the master branch yet. But that should be fixed soon. The other points can be fixed as and when.

Summary of changes since dhcpcd-6.11.5:

• source file locations reworked: dhcpcd source is in src dhcpcd hooks are in hooks compat is in compat
• README split into README.md and BUILDING.md
• internal routing is now protocol agnostic
• avoid using __packed and use compile time asserts instead
• addresses some alignment issues
• disable some ARP code on kernels which support RFC5227
• BSD IPv6 kernel settings are now updated to reflect dhcpcd config
• custom logger has been removed, syslog handles everything as such, the --logfile option has been removed as well. If you need better/earlier logging, get a better syslogger!
• distinfo and signed distinfo files are now available alongside release taraballs from this point onwards
• default DBDIR has changed from /var/db to /var/db/dhcpcd
• /etc/dhcpcd.duid moves to DBDIR/duid
• /etc/dhcpcd.secret moves to DBDIR/secret
• lease file names have dhcpcd removed from them as they are now inside a directory of the same name
• fixed issues with reject routes not working on some platforms
• improved nl80211 support on Linux for working out the SSID
• no longer request NTP by default in dhcpcd.conf
• fix detecting IPv6 DAD on OpenBSD
• remove custom Solaris DLPI filtering in favour of BPF (note there seems to be a kernel issue where the DHCP fd receives ARP’s as well, the only side effect is a noisy syslog)
• BPF filtering vastly improved so dhcpcd only wake up on ARP or DHCP packets destined for it
• support for MUD URL (draft-ietf-opsawg-mud-05)
• if the kernel isn’t doing DAD, don’t insist on waiting for it to actually do it
• fix a potential crash where the DHCP or ARP states could be freed before the packet processing loop naturally breaks
• removed gateway and nogateway options (these can be controlled by the nooption directive which works for more than just gateways)
• removed ipv6ra_own and ipv6ra_own_default options (these can be controled by the ipv6rs/noipv6rs directive)
• fix a memory leak on systems where posix_spawnattr_init allocates memory by calling posix_spawnattr_destroy afterwards
• fix a crash receiving SIGUSR1

I’ve not done everything I’ve wanted to, but I feel that many issues have now been addressed and on the whole dhcpcd is in a very good state right now.

Let me know of any issues you find!

So, to get myself on GitHub (as a mirror only), there needs to be a bridge between Fossil and Git. Fossil documentation implies this is quite easy. Sadly, this isn’t the case as the <=Fossil-1.37 releases (note there is no guaranntee that future versions of follow will not have these flaws- my branch may not be comitted to trunk) have the following flaws:

• Branch and Tag name mangling (dhcpcd-6 becomes dhcpcd_6)
• Silent master branch renaming into trunk on inport, but not on export
• No tag comments (Fossil lacks the feature) which means syncing tags back and forth results in tag conflict due to signature change

I submitted some initial patches the the Fossil mailing list and I now have a Fossil commit bit! You can find my branch here to fix the Fossil Git bridge.

But that’s not the end of the story. A bridge has two ends. With my initial setup, the Git end was bare bones repository which I pushed to GitHub. This is no longer the case- I now need a staging repository to pull both ends. And this requires a script because Git needs a little more hand-holding to completely track a remote. The below script is tailored for my needs, yours may differ. It also reflects the above initial design and the subsequent change- as such it it may need editing if you need to create a git clone from fossil. This comes with no support, just as an idea of how you might implement such a bridge.

#!/bin/sh

fossildir=/var/fossil
# Cannot be a bare directory for git as we cannot write to the host directly.
# So we have a staging directory instead.
# This requires a bit of hand-holding to track all the branches.
gitdir=/var/git-staging

marksdir=/var/scm-marks

# Respect default naming at either end
fossil_export_opts="--rename-trunk master"
fossil_import_opts="--rename-master trunk"

# Only used when creating a git bare bones repo from Fossil.
export_fossil_to_git_new()
{

        rm-f "$fossilmarks" "$gitmarks"
        git init
        fossil export--git \
--export-marks "$fossilmarks" \
                $fossil_export_opts "$fossildir/$fossilrepo" | \
                git fast-import \
--export-marks="$gitmarks"
}

export_fossil_to_git()
{

        fossil export--git \
--import-marks "$fossilmarks"--export-marks "$fossilmarks" \
                $fossil_export_opts "$fossildir/$fossilrepo" | \
                git fast-import \
--import-marks="$gitmarks"--export-marks="$gitmarks"
}

export_git_to_fossil()
{

        git fast-export--all \
--import-marks="$gitmarks"--export-marks="$gitmarks" | \
                fossil import--git--incremental \
--import-marks "$fossilmarks"--export-marks "$fossilmarks" \
                $fossil_import_opts "$fossildir/$fossilrepo"
}

pull_git()
{
        local remote

        git fetch--all
        # Track all remote branches
        git branch-r | grep-v '\->' | while read remote; do
                if [-z "$(git branch--list "${remote#origin/}")" ]; then
                        git branch--track "${remote#origin/}" "$remote"
                fi
        done
        git branch--list | sed-e 's/^\* //' | while read branch; do
                git checkout "$branch"
                git merge--ff-only
        done
}

push_git()
{

        git push--all
        git push--tags
        # Reset the current branch checkout.
        # If we don't, the next run will complain about unstashed changes.
        # This maybe a bug in git, but maybe not because the live checkout
        # *is* behind at this point as we just fast-imported.
        git reset--hard
}

echo "Syncing git and fossil."
for repo in "$fossildir"/*.fossil; do
        fossilrepo=${repo#${fossildir}/*}
        repo=${fossilrepo%.fossil}
        gitrepo="$repo"
        fossilmarks="$marksdir/$repo.fossil.marks"
        gitmarks="$marksdir/$repo.git.marks"

        # We just sync old fossil repos to new phab clones
        if [-d "$gitdir/$gitrepo" ]; then
                cd "$gitdir/$gitrepo"
                pull_git # staging only
                export_git_to_fossil
                export_fossil_to_git
                push_git # staging only
# Enable the below if pusing to a bare git repo from fossil
#       else
#               export_fossil_to_git_new
        fi
done

Direct download to script

Tech

My old blog was powered by Serendipity. Before that, it was Trac and before that it was Drupal

Now, Drupal was very …… well, blocky. It worked, and worked well to start. But my poor server at the time could not cope with the resource demands it had, alongside my existing Trac instances to host my project’s wiki and ticketing systems. So I migrated it to the Trac FullBlog Plugin. This was amazing! Where Drupal was complex, Trac was simplicity. Life was good.

But slow. As it turns out Trac itself was getting slower and slower. So I changed from Apache Pre-Fork to Lighttpd. This didn’t work too great for me. Too complex, too crash. So I changed to nginx. and used uWSGI to bridge my fcgi’s. Wow, my multi-purpose server had free memory! Amazing! I used this setup for about 5 years, maybe longer. However, Trac still got slower and slower.

So I migrated it all to Serendipity (the blog that is). I was also getting fed up with using git as my source code repo alongside Trac so I changed that to Fossil. No more Trac? And nginx and uwsgi working great! Life was good, my server now had over 1G free memory … which did slowly get used up as a cache I guess. But swap was never ever hit. Even when compiling the server software. Tech did not get this good.

But then it stopped. Serendipity refused to let me log in to the admin panel. But Life got in the way at this point. So I didn’t blog.

Fast forward to now and my DSPAM filter stopped working. Full stop. No-one knew why, myself and a few NetBSD devs spent a few hours looking at the problem. It only worked outside of my procmail filter, but my setup required it to work inside as I have email lists on the same box that required unfiltered mail to hit their informational funcions. And I hate SPAM. So I installed SpamAssassin as a replacement. It turned out the pkgsrc package needed a small bit of love, but now it’s working as well as DSPAM ever did, but more importantly working. As a result of this, I had to prune spam from my hosted mailing list archives and it turns out hypermail doesn’t allow you to do this, short of manually rebuilding the archive. So I ditched that and rebuilt my mail archives around mhonarc. I also took the time to theme it like my Fossil projects for consistency, which is fine.

Now, a lot of mail archives have a nice search function too so I decided to brush off my PHP skills which I’ve not used since the 1990’s. It turned out my skills weren’t that great as I thought and my first attempt failed. But no error was posted OR logged. It turned out that I couldn’t get uWSGI or NGINX to actually log my PHP errors! I’m sure there was a way, but frankly the setup was hard to manage so instead of bashing my head, I looked to find an easier solution.

Apache had gained a new event MPM which promised the same low memory use as NGINX. It also had really improved mod_fcgid and mod_proxy so it’s very useable easily. PHP had integrated PHP-FPM. As I no longer needed Trac, NGINX or uWSGI i said bye bye to them all and installed Apache. So full circle on the web server, but I now had easy to find PHP error reporting, so my archives search page worked fine after a quick fix!

In summary everything on my server was back to normal, fully working nicely, easily and well reported and diagnosed. Except my blog. I spent more time looking at it, didn’t like it, nor the hard upgrade I was looking at the to latest version. So, after changing all my software, why not my Blog?

After migrating a few times, I know the score. It’s Tricky (TM). So how to make life better? After a lot of research, I have settled on using GRAV for a few reasons listed here:

• Does not force MySQL database (I prefer PostgreSQL)
• No SQL database requirement, uses folders and Markdown files with embedded meta data
• The default theme already looks good
• Can self upgrade
• Because everthing is in markdown files it should be easier to manage and migrate away from later
• I want to self host- this is my data, not someone else’s
• It’s in PHP (so no need to install Node.JS, Ruby or whatever flavour of the month is)
• MIT license (close enough to my favoured 2 clause BSD)

So, this is the first post in a new blog, a new start where my Tech is currently ….. working without issue! This has got to be a first for me :)

Code

I write code. I like to think I’m quite good at it :) And like most people, I have an opinion on what makes good code and bad code …. I hate bad code, even my own! So how did code get in the way?

I mentioned earlier that for some reason I my Serendipity admin login stopped working. Well, I looked at the code …. and it was not nice. (My install was an old version compared to their current 2.0 so this may have changed) There were little comments, there was poor seperation between Model, Controller and View. Now, the actual code in question looked like it should be working …. it hashed my paswsword, compared the hash to the saved DB entry. I even went as far as adding debug code. It all looked perfect, yet it did not work. No-one knew where the error was.

I was also pretty annoyed with Serendipity for other reasons I discovered only after using it, so I decided to ditch it entirely and move on. As you can tell above, I have no problem changing out software I no longer believe in, or fares poorly compared to others. I also enjoy when the software I originally chose makes great strides to tempt me back in the fold, like Apache. I don’t claim to understand web server code, but I did peruse their codebase a while ago and it looks cleaner compared to when I did in the early 90’s trying to make it work on Windows for $DAYJOB.

I’ve also spent a lot of time on my pet coding projects, dhcpcd, dhcpcd-ui, resovlconf and NetBSD.

Anyway, enough ramblings about code. There will be a lot more about that in the future anyway now that I have a working blog again. Well, almost working. I need to write some code to import from Serendipity to here, which will be nice as I enjoy coding and want to preserve the content I’ve lovingly created- alongwith you in the comments- over the years and I would hate to lose that! Speaking of comments, there is currently no comment system on this blog. So Tweet me about it for the time being until I integrate something like ISSO commenting or maybe find a Grav plugin. I also need to find a way of providing top links to my project pages.

Life

So in the past few years, my Family has been very stable and loving :) But a new child got in the way! Ethan Thomas Marples was born 2nd December 2015, so he’s one year old tomorrow! That has taken a lot of my time, and all my children still take a lot of my time, so it’s a very enjoyable getting in the way :D

There’s also been some changes at work. My old company Logos Technologies was bought by Instem. I’m still doing the same job, working on the same product, but the inner dealings of the buy out, company politics and day to day integration have certainly been eye opening.

Playing games got in the way. Far too much time playing MMO’s …. I’m now off that bandwagon. But I don’t regret it, it was a lot of fun :)

I’ve also been on a health roller coaster. I’ve taken the nice Doctors Orders and have invested in a FitBit Charge and FitBit Aria Scales which keep track of my steps, calories burned, sleep and weight. There is no more hiding. The good news is that I’m a lot fitter- I now enjoy walking and take a 40 minute walk each day minimum as well as walking the kids too and from school. I’m drinking a lot lot less, but still enjoy (probably a little too much still) a weekend tipple.

I’ve lost over a stone (21 pounds to be precise) as a result! My resting BPM as dropped from a $HIGHNUMBER to 58, which is healthy :D I should keep track of my blood pressure more, but maybe in the new year ….. but

** GO ME!! **

I’m fitter, stronger, more alert and ready to blog! Although probably shorter blogs next time ;)