The hard part of custom environments on Fedora (or any Linux)
At one level, doing a custom X environment on top of Fedora is easy
(as I alluded to in reply to a comment on this earlier entry). I do it in a perverse way with my desktop, and people who are sane enough to use the
standard graphical login can do it by simply writing a script that
starts everything (including their window manager) and putting an
appropriately formatted file in
/usr/share/xsessions (as of Fedora
But all of that is the simple part. (As shown by the fact that I can look all of it up in about five minutes.)
The hard, complicated, and painful part of doing a custom environment on a modern Linux machine is figuring out all of the things that you need to run (and to do) to make all of the usual automatic things happen in your custom environment. Long gone are the days when a desktop environment was a window manager with a 'run some programs' menu; these days, a modern desktop environment has an ever growing number of moving parts, most of them mostly not documented and many of them needing other things as support. If you want things like automatic mounting and handling of removable disks, support for easy handling of wireless networks, and your laptop to suspend properly when you close the lid, you may be in for quite a bit of research and experimentation.
The other painful bit is due to where you usually have to get these programs from. There are independent implementations of some of what you need, but for most of it you generally have to selectively pick bits out of an existing desktop environment; you figure out what Gnome or KDE program is run to do a particular job, and then you start it in your desktop environment too. Of course these programs are not a stable, public interface that Gnome or KDE support as things that can be run outside the full Gnome or KDE environment. Instead they're internal implementation details, and such they keep changing. What program you run changes, how you run it changes, what it requires changes, and so on. Every time I upgrade Fedora, I can count on a couple of days of picking up the pieces of my custom environment again; I consider it a victory if only a few bits have to change.
(Increasingly you may also be up a creek if you are not running the standard environment. In Gnome 2, much of this functionality was provided by independent programs that you could run outside of the Gnome desktop environment. In Gnome 3 the Gnome Shell model is for 'applet' code to mostly run inside Gnome Shell itself, which means that you can't run it yourself in a different environment. So far the old 'applet' versions of various things are still being provided, but that probably won't last forever.)
How not to use Apache's ProxyPass directive
Periodically we need to set up reverse proxies with Apache's ProxyPass directive (to support our solution to the multiuser PHP problem). On the surface doing this fairly simple and straightforward; however, the important devil is in this spotlighted bit in the documentation:
If the first argument ends with a trailing
/, the second argument should also end with a trailing
/and vice versa. Otherwise the resulting requests to the backend may miss some needed slashes and do not deliver the expected results.
Since I have now stubbed my toe on this thoroughly, here are several
ways to not use
ProxyPass for this, all of which fall afoul of the
above warning (some in less than obvious ways).
To start with, the basic template of ProxyPass is '
http://somewhere/else'. When Apache sees any URL that starts with
/a/path, it removes
/a/path from the front of the URL, puts whatever
remains on the end of the second URL, and tries to fetch the resulting
In all of the following examples, we want
/url/ to be reverse proxied
as a directory; the target has a page at the top level with a relative
ProxyPass /url/ http://localhost:8080
The top level page works and the link to
a.html shows as link to
/url/a.html, but attempts to follow the link fail with Apache being
unable to fetch the URL http://localhost:8080a.html. This shows that
Apache is effectively forming the URL by text substitution and then
interpreting it later; because there is no
/ at the end of the second
argument, it simply glued the raw text of everything past
it and the result fails badly.
(This also doesn't do anything to handle a request for just '
but one can get around that with other tricks.)
ProxyPass /url http://localhost:8080
If you request
/url/ everything works. But if you request just
you still get the page (instead of a redirection to the version with a
version with a
/ on the end) and the relative link to
out as a link to
/a.html (which doesn't exist and in any case is not
reverse proxied) instead of
/url/a.html, because your browser sees
/url as a page in
/ instead of a directory.
This case is the tricky case because it's not obvious that we're
breaking the rule from the documentation; after all, everything looks
right since neither argument ends with a
/. The problem is that
when you make a bare request for http://localhost:8080, as you do
when you ask for '
/url', Apache implicitly adds a
/ on the end
(because it has to; it must
GET something from the server at
localhost:8080). This implicit
/ means you have a
/ on the end of
the second argument but not on the end of the first argument and have
thus broken the rule.
My belief is that there is no simple way for whatever is behind the
reverse proxy to fix this. Without peeking at special request headers
that Apache reverse proxying supplies, it cannot tell whether a request
/ is from someone who asked for '
/url/' (and is okay) or someone
who asked for '
/url' (and should get redirected to
ProxyPass /url http://localhost:8080/
If you ask for
/url/ or anything under
/url/, the reverse proxied
web server receives a request for the (local) URL
// or something that
starts with that. Many web servers are unhappy about this. If you ask
/url you get a page, but the relative links on the page are
broken as before because it's still not redirected to
(However, now a suitably crazy web app can actually tell the difference between the two requests.)
As far as I can tell the only proper way to use
ProxyPass in this
situation is as follows:
ProxyPass /url/ http://localhost:8080/
This follows the rules and does not result in doubled
/'s. It doesn't
handle requests for
/url at all, but I believe that you can arrange
/url to be redirected to
/url/ by having a real
in an appropriate place in your filesystem.
(In our environment most of these redirections are for user home pages,
/~user will already get redirected appropriately.)