JADDOG

Rewrote the model in loki to separate builders from slaves in attempt to support multinode support. I’ve also submitted a package request for Django-loki to fedora.

https://fedorahosted.org/loki

I got some feedback yesterday that suggested the Nushus Fedorahosted.org page could mistakenly depict the application as CLI only. The feedback also suggested that some screenshots would be a welcome addition to the trac site and would help remedy this mis-perception.

So here the are: some nushus screenshots

New version of nushus is available for download. Just a couple bug fixes.

https://fedorahosted.org/nushus
Release Notes: https://fedorahosted.org/nushus/wiki/Release

Loki is one of the projects that I started at work and open sourced. I have been giving intermittent attention to. It was recently metioned at a buildbot meeting:

There are already some configuration-generation apps out there (notably Loki),

http://buildbot.net/trac/wiki/Meeting29April2010#BuildCoordination

Also, Mozilla recorded the meeting: http://videos.mozilla.org/serv/air_mozilla/buildbot080event.ogg
Loki is referenced in this video just after the 0:28:50 mark.

Thanks for the plug!

Just uploaded a tarball of Nushus 0.12.2 to the Nushus fedora hosted site.

Docs and tickets are still being transferred out to the fedora hosted trac site.

Nushus (pronounced new shoes) is a package and file repo release management tool. It has a web interface and cli client to aid in isolating in and promoting packages through a release engineering process.

Right now you can import two types of files:

1. rpms with auto generation of yum metadata, acls management and promotion to other nushus instances on a per-repo basis
2. simple files with acls managment and promotion to other nushus instances on a per-repo basis

An instance of Nushus can be established in multiple environments. (ex: QA, Stage, Prod) The instances are then configured to talk to one another so that they can transfer files from environment to environment.

I’ve been working to open source a project I’ve been working on at work.

Pushed the code base up to FedoraHosted.org this morning. Documentation still in progress, ticket migration to FH.org trac site to come.

http://fedorahosted.com/nushus

The problem:

I was using mod_auth_kerb to authenticate and ProxyPass to pass off the request to another server. I’m trying to support Kerberos Authentication but split the infrastructure into a proxy/app tiering using ProxyPass because I needed the ProxyPassReverseCookieDomain directive. Problem is I need to pass the user that had been authenticated along with the ProxyPass (ie. the value of REMOTE_USER) and found no configs to let me do that with mod_auth_kerb and ProxyPass.

What I tried:
I found a bunch of pages that referenced using a lookahead (LA-U:REMOTE_USER) to get the value of REMOTE_USER. Take that value and set an environment variable. Then use the env var to set a header, say, X-Forwarded-User. This didn’t seem quite right since this was being implemented at the rewrite stage (pre authentication, hence the lookahead’s subrequest) and spawned the overhead of another subrequest to get the initial value. I tried all kinds of permutations of some rewrite configs that looked something like this:

RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule .* – [E=RU:%1]
RequestHeader set X_REMOTE_USER %{RU}e

http://n2.nabble.com/SSO-with-SSPI-and-SSL-LA-U-REMOTE-USER-always-null-td4086748.html et al.

In spite of the “not quite right” of the subrequest to env var to header I always got a value of (null) back from the lookahead. So this never even worked in combination with mod_auth_kerb (I’ve been told it does with basic auth or with mod_auth_kerb + RewriteRule [P]). Further it seemed inefficient to do all this subrequest to env to header stuff. I figured the most efficient thing to do (relative to processing the requests) would be to write a simple apache module that was in the module chain after auth but before proxy. Turns out that it didn’t take too long to do either.

The Solution:

I started with a tutorial at threebit.net where I just wanted to compile an apache module and insert it into the module chain. This worked like a champ (Thanks Kevin!) and I was logging to my error_log via stderr in no time at all. After reading though some apache code I figured out that r->user was the variable that mod_auth_kerb was populating the authenticated user to and that the ap_hook_handler method was inserting this module into the chain after proxypass. This location in the module chain was a problem because when I turn on proxypass the request was being proxied before the module was being executed. After a bit more docs and code reading I found ap_hook_fixups, which is in a stage between the auth and proxy modules. So that diff would look something like this:

< ap_hook_handler(mod_tut1_method_handler, NULL, NULL, APR_HOOK_LAST);
> ap_hook_fixups(mod_tut1_method_handler, NULL, NULL, APR_HOOK_LAST);

Finally, the method_hander’s code was changed from the stderr functionality to these two lines to use the r->user variable:

apr_table_set(r->headers_in, “X-Forwarded-User”, r->user);
apr_table_unset(r->headers_in, “Authorization”);

This sets the X-Forwarded-User header with the user the proxy has authenticated and strips out the Authorization header to be sure that your not passing any basic auth information (passwords in clear text!) from server to server.

I don’t have a complete set of code anywhere for you to download at this point, though, hopefully there’s enough here that all you’d have to do is swap a few pieces of code out, compile it (I had to update the automake stuff on the tutorial cuz it’s kinda old) and install it according to the tutorial’s directions.

Words of Warning:
1. Secure your app!
If you open your app up to accept X-Forwarded-User and trust that header as a source of an already authenticated user you must make sure that the only host that can pass that header to your app is your proxy! It would not be hard to install this custom module elsewhere (or use the lookahead stuff), slap basic auth on it and pass the header to your app completely ignoring your authoritative authentication infrastructure.

2. This will be applied to every request on your proxy.
There is nothing in this module that will only apply this to a specific vhost or anything. Every request that your proxy processes will get your custom header.

Future?
A nice addition to this would to let you configure the header name in your vhost config (ProxyUserHeader “X-Custom-Header-Name”) or even to submit a patch to mod_proxy so it’s not a separate module but built into mod_proxy (ProxyPassUserHeader “X-Custom-Header-Name”). Seems intriguing to do a bit more with it.

I’m working on a feature for a project that I’m getting ready to open source. (more to come on it being open sourced when it happens) I’ve never taken the time to try and use pdb to debug a python program. I fell into a situation that seemed plausible to try it.

Found this post and was quite delighted to be able to dive right into debugging my app. Also of worth to note, the post references this link which once you have the basics of using pdb expands a little on what else you can do.

<3 pdb

I started a project a while ago that was managing buildbots. It was a cli application that used sqlalchemy and func to manage buildbots across multiple machines. After some experience at work with build systems I realized that this setup was far to complex to expect someone to setup and use and it was fairly tied to a fedora/redhat infrastructure.

Well, I’ve started over. The new application is based on django and for now only installs bots on a single machine. I have plans to support a distributed configuration in the future. For now I just needed a decent interface to get some bots up and running fast.

I also have recorded a screencast to so a simple quick start. The screencast assumes you have some basic buildbot knowledge.

You can get more information, docs, the screencast and the code at https://fedorahosted.org/loki

*** UPDATE ***
This hack is probably unnessesary, I found that wp-mu has a sites framework that is not exposed, there is a plugin that’s trying to accoplish the same thing I am. Just google ‘wordpress mu sites’
*******

I need to have multiple wordpress instances installed, but I want them each to have their own vhost, I also want an easy way to maintain them (upgrades and such). I thought wordpress mu could do this… but out of the box it only supports wildecards on a single domain. (blog1.example.com and blog2.example.com and blog3.example.com) Turns out you can change 2 lines (3 if you want to clean up a view cosmetically) and you seemingly can use wordpress-mu to host multiple domains. www.blog1.com and www.blog2.com and www.blog3.com

I’ve not deployed this yet… so use at your own risk. I’ll post again later with results after I’ve migrated a couple sites to it.

The problem: wp-mu assumes in vhost mode that all your blogs are of convention {something_here}.example.com. It does this by concatenating the domain you configure at install time onto the name of any new wordpress site you setup.

The solution: tell it not to append your installed time configured domain when you setup a new site. No special magic seems to happen with a new wordpress site’s configured domain after install time.

To show how this works this we’ll setup an example.com instance of wordpress mu and replace the wildcard magic so that not-example.com is hosted by the same code base.
1. download and and install wp-mu just as they tell you to, use example.com (set a hosts record to point example.com to your localhost) You’ll now have a fresh new wp-mu blog at example.com.
2. patch the files to remove the wildcard vhost magic
a. This change will remove the hardcoded base domain and will assume the domain name you’re accessing wordpress with is the current domain. Without amking this dynamic the authentication would fail on some or all of the configured sites.

wp-config.php
@@ -38,7 +38,7 @@
-define(‘DOMAIN_CURRENT_SITE’, ‘example.com’);
+define(‘DOMAIN_CURRENT_SITE’, getenv(‘HTTP_HOST’));

b. This is the concatenation magic that we want to prevent from happening. It undoes the “force append install-time configured domain” or in our example case, don’t force .example.com on the back of my new blog.

wp-admin/wpmu-edit.php
@@ -147,7 +147,7 @@
if( constant(‘VHOST’) == ‘yes’ ) {
-                       $newdomain = $domain.”.”.$current_site->domain;
+                       $newdomain = $domain;

c. This last one is optional. It’s just removes the domain name below the test box on the form for a new blog. This is a pure cosmetic change.

wp-admin/wpmu-blogs.php
@@ -582,7 +582,7 @@
<?php if ( constant( “VHOST” ) == ‘yes’ ) { ?>
-                                                       <input name=”blog[domain]” type=”text” title=”<?php _e(‘Domain’) ?>”/>.<?php echo $current_site->domain;?>
+                                                       <input name=”blog[domain]” type=”text” title=”<?php _e(‘Domain’) ?>”/>

3. Add a new wp site at not-example.com (add the hosts record that points to localhost again to test)
4. use the dashboard -> tools -> export to get an xml dump of a single instance blog that you can import into a wp-mu managed blog.

Like I said I’ve not actually deployed this yet, but authentication in and out of the two domains dashboard and frontend seem happy. I’ll be sure to update this post with any other issues I come across. let me know if you try it and if it works!