Today I resigned from the Debian project. The following packages are up for adoption:
I'll remove myself from Planet Debian tomorrow, assuming the keyring revokation isn't swift and merciless.
ObQuote: This space is intentionally blank.
Entries from April 2011.
Today I resigned from the Debian project. The following packages are up for adoption:
I'll remove myself from Planet Debian tomorrow, assuming the keyring revokation isn't swift and merciless.
ObQuote: This space is intentionally blank.
So I've succumbed and joined twitter. I'm pretending I'm a photographer, rather than a techie/geeky/random person, whether that persists is anybodys guess.
At the very least I don't feel any real need to write/post/ask about Linux, development, or similar. I can do that here or elsewhere. (Not least because length-restrictions are annoying; yes it is true. Size is important.)
So far I've been posting semi-random pictures, I guess that is one way to pass the time, while I play with my camera.
ObQuote: "Please, please, please drive faster!" - Wanted.
thttpd is a simple, small, portable, fast, and secure HTTP server which supports both IPv4 & IPv6.
However one noticable omission in the handling of requests for thttpd is support for the X-Forwarded-For header - which is even noted upo nthe thttpd wikipedia entry.
There is a simple patch floating around which claims to fix this; but as I belatedly noticed tonight it only works for IPv4.
If you look at libhttpd.h of the thttpd source you'll see this:
typedef union {
struct sockaddr sa;
struct sockaddr_in sa_in;
#ifdef USE_IPV6
struct sockaddr_in6 sa_in6;
struct sockaddr_storage sa_stor;
#endif /* USE_IPV6 */
} httpd_sockaddr;
As a quick hack I updated this structure to add the following member:
char real_ip[200];
Now I could update that member when a client connects and later update it as a result of any X-Forwarded-For: headers which might be present in incoming requests. Finally I updated the logging to use this field rather than anything else and the job was complete.
Without this work if you're running as a proxy and you receive an IPv6 connection you'll see it reported as 127.0.0.1.
I'm sure my approach isn't as clean as it could be - due to the extra member- but it will suffice for now.
ObQuote: "This gun you're holding belonged to your father; he could conduct a symphony orchestra with it. " - Wanted
Today I made a couple of small tweaks to my systems. First of all I updated my email handling to allow further restrictions to be applied to incoming mail.
Generally the way I handle incoming mail is to first of all test the recipient, then apply spam checks. To allow mail for a new localpart to be received I'll run this:
cd /srv/example.com/users/valid touch localpart
The result of the file /srv/example.com/users/valid/localpart existing is that mail is accepted for localpart@example.com.
As of today that still works - any file beneath users/valid allows the appropriate localpart to receive email. But now a directory indicates an ACL. So I can create:
rm /srv/example.com/users/valid/root mkdir /srv/example.com/users/valid/root/ touch /srv/example.com/users/valid/root/1.2.3.4 touch /srv/example.com/users/valid/root/2.3.4.5
Now only the named IP addresses may mail root@example.com.
Finally I updated the proxy which is handling incoming access to my websites, so that I actually take advantage of the regular expression support.
'(xen-hosting.net|www.xen-hosting.net)': {
'rules': {
'^/': 'http://kvm-hosting.org/'
},
},
'(xen-hosting.org|www.xen-hosting.org)': {
'rules': {
'^/': 'http://kvm-hosting.org/'
},
},
Using regular expressions meant that I didn't have seperate matches for xen-hosting.org and www.xen-hosting.org. (Obviously I could have combined all four hosts into one regexp, but it looks cleaner this way.)
ObQuote: "Nobody likes a perky goth" - Blood Ties.