cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Clift <>
Subject remove dynamic generation of routers modrewrite htaccess files?
Date Wed, 27 Aug 2014 17:50:59 GMT
So I've been digging through the code that generates the meta-data
available to vms (e.g.  http://<your-router>/latest/meta-data/local-ipv4
<> etc).  The systems design
is discussed here:
 though the implementation has evolved somewhat since then and the git
history is uh, muddled.

We recently discovered that we have been accidentally messing up the
.htaccessfile that provides the functionality for this data - inside the
router it is /var/www/html/latest/.htaccess) with a repair/live-upgrade
script that would among other things, unpack the original (current)
tarball.  What is currently in the tarball is a stub version of this file
with only one of the normally-many mod-rewrite rules...

I made a patch ( to just add all the
rules to the default one in the image, but then discovered that around the
same time someone was updating the regex in the rewrite rules to fix
another bug...  conflicts between my patch and his got me digging more.

Which mod-rewrite rules are needed are entirely dependent on the hard-coded
list of metadata files as seen in these three places:


I'm wondering if anyone knows why we currently dynamically generate
/var/www/html/latest/.htaccess or can see any compelling reasons to not
just remove the code that updates that file in  There are other
htaccess files also modified by that script that probably need to be

What would you all think of me changing to just leave that file
alone, combined with my previous patch and the recent regex change as seen

The only downside I see is that from a code-maintainability standpoint, if
you add new kinds of metadata in any of those three files then you must
also remember to update the .htaccess file.  Would a comment in those
locations be sufficient?

Fred Clift

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message