Doug Kavendek's questions

Our previous web server was Windows based, and it hosted multiple domains. As a result, if a user with name "username" wanted to log in via FTP to "example.com", they'd provide their username as "[email protected]".

We've modified things since then; our web server is now using CentOS 6, and our app no longer relies on FTP for anything. However, there may still be some stragglers out there who haven't updated, and I was curious if it's possible to set up some FTP users to emulate the old behavior, sort of as a little backwards compatibility until we know that no one's relying on it anymore. Trying to create a user with an '@' in their name results in the somewhat predictable:

useradd: invalid user name '[email protected]'

It's probably not possible to coerce the system to accept a name like that, but I don't know if there's any system for something like those "virtual domains" when users log in that's anything similar to what we were doing on Windows.

I am using mod_rewrite in an .htaccess file in our root web directory so that we can use cleaner URLs for some specific cases. For example, we want to translate:

http://example.com/Topic/ABCD/Type/Description

into

http://example.com/Topic.php?l=ABCD&e=Type&t=Description

This seemed easy enough; the .htaccess file consists of:

RewriteEngine on
RewriteRule ^Topic/([^/\.]+)/([^/\.]+)/([^/\.]+)/?$ /Topic.php?l=$1&e=$2&t=$3 [L]

However, all the page's content (.CSS files, images, etc.) ends up 404'ing because instead of, say, loading "/Common.css" from the directory relative to the rewritten URL:

http://example.com/Common.css

it loads it from the un-rewritten URL's directory:

http://example.com/Topic/ABCD/Type/Description/Common.css

which obviously does not exist. However, I've found countless tutorials all over the web that advocate some variant on what I'm doing (one example here), but make no mention of this problem I'm having, so I'm wondering if there's just some configuration I'm overlooking. They can't all rely on having these 'virtual' directories exist and contain the page's content. I also really don't want to make everything into absolute paths.

I have tried adding rules earlier in the .htaccess file to try to short-circuit content requests, such as:

RewriteRule \.(css|jpe?g|gif|png)$ - [L]

but it seems to have no effect. Regardless, I wouldn't have thought such content would even match the original rule, as the regex in that rule does not allow for anything following the (optional) trailing slash.

If I change the rule such that its flag is set to redirect ([R,L] instead of just [L]), then it all works fine -- except now the browser displays the rewritten php parameter string, which is what we were trying to avoid. In the past, we've just accepted this as a work-around, but now I'm trying to understand why it's working this way, and what I can do about it.

In case it's relevant, I'm using CentOS 6.2, and Apache/2.2.15.

We've got two sites with two IPs using only port 80, and an SVN repository using 443 on one of those IPs. When I try to set up SSL for one of the two sites (with the IP that is not in being used by SVN), it refuses to start up because it claims 443 is already in use, even though it should be using an entirely separate IP.

We've got a web server with Windows Server 2003 x64, running IIS 6. We've got two domains that each map to their own IP. Let's say site A maps to 1.1.1.1 and site B maps to 2.2.2.2. SVN is set to listen on 1.1.1.1:443, while sites A and B listen on 1.1.1.1:80 and 2.2.2.2:80, respectively. This works just fine, until I try to set up site B to listen on 2.2.2.2:443, in which case site B will fail to start, as mentioned above. If I stop SVN, then I can start up the web services (including the one on 2.2.2.2:443) but then when trying to start up SVN again, it gives the same basic "already in use" error. But while they're both listening to port 443, they're doing so on separate IPs, which I thought should work.

I've used netstat, and see that SVN is indeed listening at 1.1.1.1:443, instead of 0.0.0.0:443 (which would mean it's listening to all IPs, I think?). It was previously configured to listen on "any" IP, and I thought I would have solved my problem by setting it to only listen at 1.1.1.1, but making that change had no effect. Nothing else is listening to 443. Similarly, the two sites set up in IIS are set to only look for their respective IPs, instead of "any unassigned", and when I set site B to use SSL at port 443, I similarly restrict it to just IP 2.2.2.2.

Considering I can get either the web service or SVN to run just fine, but not at the same time, it seems pretty straightforward that they're conflicting with each other. But shouldn't their separate IPs resolve that conflict?