Apple's software update server has the ability to offer the "correct" catalog to a client that requests simply "index.sucatalog". This ability was first added with OS X Server 10.6.6, and involved the use of Apache mod_rewrite.

Lion Server has a similar capability, but this is done via a CGI instead.

Since Reposado doesn't handle the web-serving part of offering Apple software updates, Reposado itself cannot provide a similar feature: instead you must configure your web server to do URL rewrites, or write your own CGI to provide this functionality.

I wanted to do URL rewrites, but also wanted to keep things modular. Since I'm using Apache2 as my web server, it seemed that using an .htaccess file at the root of my Reposado repo would do the trick.

I'm currently testing these .htaccess file rewrite rules at the root of my reposado repo:

RewriteEngine On
Options FollowSymLinks
RewriteBase  /
RewriteCond %{HTTP_USER_AGENT} Darwin/8
RewriteRule ^index(.*)\.sucatalog$ content/catalogs/index$1.sucatalog [L]
RewriteCond %{HTTP_USER_AGENT} Darwin/9
RewriteRule ^index(.*)\.sucatalog$ content/catalogs/others/index-leopard.merged-1$1.sucatalog [L]
RewriteCond %{HTTP_USER_AGENT} Darwin/10
RewriteRule ^index(.*)\.sucatalog$ content/catalogs/others/index-leopard-snowleopard.merged-1$1.sucatalog [L]
RewriteCond %{HTTP_USER_AGENT} Darwin/11
RewriteRule ^index(.*)\.sucatalog$ content/catalogs/others/index-lion-snowleopard-leopard.merged-1$1.sucatalog [L]
RewriteCond %{HTTP_USER_AGENT} Darwin/12
RewriteRule ^index(.*)\.sucatalog$ content/catalogs/others/index-mountainlion-lion-snowleopard-leopard.merged-1$1.sucatalog [L]

(Note that the format for these rules is specific for use in an .htaccess file. The rules would need to be changed if in the main Apache config file.)
(Other web servers such as Nginx support URL rewriting; the specifics are slightly different, but the general concepts are similar.)

These RewriteRules for Apache2 seem to do the job. I can set the CatalogURL on a client to "http://my.sus.example.com/index_testing.sucatalog" and the correct OS-specific branch catalog is returned.

To help verify that the catalog file I was getting via URL rewrites was the correct one, I made a small change in reposado. When catalogs are written out to disk, a key named "_CatalogName" is added to the plist with the base filename of the catalog. This allows you to verify that the catalog being returned is the one you expect.

For example, I want to test that I'm getting the Lion catalog:

% curl --user-agent "Darwin/11.4.0" http://su.example.com/index_testing.sucatalog > /tmp/testing
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024k  100 1024k    0     0  25.1M      0 --:--:-- --:--:-- --:--:-- 32.2M

% tail -5 /tmp/testing
        </dict>
        <key>_CatalogName</key>
        <string>index-lion-snowleopard-leopard.merged-1_testing.sucatalog</string>
</dict>
</plist>

The _CatalogName is "index-lion-snowleopard-leopard.merged-1_testing.sucatalog", which is what I expect.

I can repeat the test for Snow Leopard:

% curl --user-agent "Darwin/10.8.0" http://su.example.com/index_testing.sucatalog > /tmp/testing
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  912k  100  912k    0     0  29.7M      0 --:--:-- --:--:-- --:--:-- 31.8M

% tail -5 /tmp/testing
        </dict>
        <key>_CatalogName</key>
        <string>index-leopard-snowleopard.merged-1_testing.sucatalog</string>
</dict>
</plist>

You'll need to git pull or otherwise get the latest reposado code from GitHub to get this change.

-Greg

Here's a corresponding configuration snippet for lighttpd. The "mod_rewrite" module needs to be loaded in the server:

I'm having trouble implementing URL rewrites as described above and in the documentation on git. I'm sure it's something simple but here's the steps I took so far:

Mallory,

--

Wow, that was an embarrassing number of typos. Hopefully the "meat" of the idea still made it across the wire!

--

Looks like it's an issue with apache so I'll keep looking through their docs. Thanks