Particularly deployment automation, in my case something like capistrano. It goes further than just the application, however. It goes into being able to ensure that the deployment environment, including the database and the application container all behave nicely. I have failed in this aspect, as my rails app is no longer behaving, and I’ve been reduced to updating things in the hopes that one of the things will fix it :(

Continue reading »

 

Blarg. Gcc.

I kept having a horrible error building collectd 4.10.x on my Source Mage servers:

libiptc.c:85: error: redefinition of ‘struct xt_error_target’

The internets couldn’t really help me with the error, I think I was searching for the wrong words. There was also issues regarding warnings that gcc now treats as errors.

I ended up spending probably about an hour cloning their git repo, cherry-picking a few commits into the 4.10.3 tag, and then submitting the patches to the bug I created.

End result is that collectd-4.10.3 now builds on gcc 4.4.3 and 4.6.1. The fix is in the Grimoire on Source Mage, and should trickle out to stable eventually. I think I’m the only one who uses collectd, so it’s not all that important, heh.

 

Lighttpd does a much better job generating an index page for lots of files. 12,049 files to be precise, at time of writing. I had set up a long time ago my website to be a fallback mirror for Source Mage, so if a source file got moved, lost, deleted, or the site hosting it went down, away forever, whatever. I remember disabling Apache’s Indexes option on that file list because it would take foreverto get anything rendered, as well as consuming plenty of CPU and resources.

Well, I was using an internal lighttpd to render the same thing internally, and I didn’t disable its directory listing at all. Whilst I was working on setting up collectd to monitor my Apache scoreboards, I noticed that it could also monitor the lighttpd scoreboard. So I was going about the config to set that up, and I noticed that the Apache wasn’t proxying it’s requests through to lighttpd, and was taking a lot of time and resources to do something simple.

Welp, having ADD like I do, I got sidetracked on doing that instead and started to rewrite my configs to not serve files directly, but proxy it to the lighttpd internally.

Originally, I had two aliases set up “/sourcemage” and “/sourcemage/fallback” which both pointed to the same spot on disk, This way you could reference things using “/sourcemage/file.tar.bz2″ or “/sourcemage/fallback/file.tar.bz2″. The reasoning behind this is simple: I set up my fallback mirror before Source Mage standardized on a fallback URL, and I wanted to keep both paths functional. Easy to do with aliases. Oh, and I also have an alias to “/sourcemage/codex” for all my local codex needs.

Switching to a proxied setup was a bit more complicated than I anticipated. The alias stuff doesn’t work the same way everything else does, in that what it finds first it goes with. I needed to have mod_rewrite rules wired in to properly redirect things and manipulate the URL sufficiently. But I have two special cases. I can’t simply redirect everything “/sourcemage/*” to “/sourcemage/fallback.” Also, I wanted to be able to continue to use “/sourcemage/file.tar.bz2″

My solution is relatively simple and follows:

#aliases
Alias /sourcemage/codex    "/srv/webMirrors/sourcemage.org/codex"
#rewrite /sourcemage/ to /sourcemage/fallback
#some very fancy rewrite rules to keep the old alias functionality
RewriteEngine On
RewriteRule ^/sourcemage/?$ /sourcemage/fallback/ [R]
RewriteRule ^/sourcemage/codex/?$ - [L]
RewriteRule ^/sourcemage/([a-zA-Z0-9.i_\-+]+)$ /sourcemage/fallback/$1 [R]
# do the actual passing through to the lighttpd (which handles huge
# directory listing much much better
ProxyPass /sourcemage/fallback http://fallback.shlrm.org/
ProxyPassReverse /sourcemage/fallback http://fallback.shlrm.org/

# old notes kept here for reference as to what the above rewrite
# rules are doing -- dkowis 2011-09-07
# going to proxy these to the lighttpd
#Alias /sourcemage/fallback "/var/spool/sorcery/"
#Alias /sourcemage          "/var/spool/sorcery/"
# directories!
#<Directory "/var/spool/sorcery/" >
#       Options none
#    AllowOverride None
#    Order allow,deny
#    Allow from all
#</Directory>

<Directory "/srv/webMirrors/sourcemage.org/codex/" >
        Options Indexes
        Order allow,deny
        Allow from all
</directory>

# vi: set ft=apache:

The rewriting rules are the most complicated part of this. The trick was getting it not to try to rewrite anything when the url matched “/sourcemage/codex” After that, the rest was really easy. Some matching logic to pick up on “/sourcemage/file.tar.bz2″ and redirect that to “/sourcemage/fallback/$1″ and everything worked as it did before, except way faster.

 

Given the “end of IPv4″ I decided I shouldset up IPv6 on my network and see if I can’t start doing things over that instead. Unfortunately, however, it appears that my DNS server internal to my network, maradns, sucks at IPv6 until version 2.0. Fedora has it at 1.3.something. Debian has it at 1.4. WTF Fedora?

I’ve been working on building MaraDNS 2.0 RPMs for Fedora 13 and 14, but I don’t know the RPM SPEC structure very well. The 2.0 version of MaraDNS has separated the authoritative resolver from the recursive resolver, which is wise. But it means I need to build a spec file that produces two RPMs. I suppose I could build a separate spec file for each one, but that doesn’t seem like the right way to do things.

 

I have a plugin called Broken Links Checker that I have used in the past to find broken links within the wordpress postings. I’ve used it in the past without consequence. It would dutifully go through my posts and report back to me the links that no longer work. Pretty handy, I can go and disable those links, make them strike-through, etc.

I updated it along with updating wordpress to 3.0.3 the other day. I fired off the Broken Links Checker, and as it usually takes a while, I ignored it and went on playing Eve and writing some ruby code (a simple little project to organize a whole lot of files into 4.7GB disks and include manifests and md5s of all the files for an archive. Still doesn’t work yet.) The next morning, I woke up to a large amount of email. I figured it was just spam or something that was significantly different than the normal spam. Unfortunately it was notifications from my Nagios telling me that the box doesn’t respond to ssh or http anymore. Uh oh.

Luckily, I’m running Xen, so it is trivial to get to the console over ssh. I connect to the console and try to log in. The box is totally wedged. OOM Killer had gone crazy with httpd, and anything else that was on that box. So xm destroy. Fire it back up again, wait for it to replay all the transactions, and it had decided to check the disks, since they haven’t been checked in 214 days. All came back up fine. Nagios was again satisfied. However, none of the sites worked. “Error: Cannot access database.” Oh noes. Started the normal debugging process, looking through logs and what not. Found a bunch of local requests from Broken Links Checker checking links. It appears that it caused a DOS to myself. Wonderful. Still no luck with MySQL, so I tried to connect to the mysql server via the command line, I had already determined that it was up, and it’s on a different box, so it didn’t get oom killed when apache killed the box. I get an error telling me that MySQL was denying connections from this host due to too many errors. So a flush-hosts later, and it all works again. Fun.

Guess I should set up some kind of resource limits for Apache on that box. Also, I’m removing that Broken Links Checker plugin, I don’t need to find my broken links that badly…

© 2011 Shlrm.org Blag Suffusion theme by Sayontan Sinha