Hosting by IP
Søren Enevoldsen
17 November 2010, 00:39
Hiawatha version: 7.4
Operating System: Linux Mint 9 (Debian)
I followed the howto's here and the suggestion with setting the default server to a blank using 127.0.0.1.
However when I add a virtual host using 127.0.0.1 too I get a warning and the default configuration is used even though I though I thought it tried to match any other before resorting to the default.
Am I correct, that in my situation, you are just to use the default as it was the virtual server and use some dummy hostname for the virtual?
Thanks
Hugo Leisink
17 November 2010, 15:50
A hostname (for both default host and virtual host) can be used only once. If you use the same hostname for multiple host configurations, how should Hiawatha know which host configuration to use for a specific request?
Can you tell me what you are trying to achieve? Posting your configuration can also help me understand what you are trying to do.
Søren Enevoldsen
17 November 2010, 18:58
I was trying to get Hiawatha to work locally on my laptop before installing it on my VPS.
I followed the advice in the HowTo, where it says to point the default hostname to a blank page. Then I needed the actual website which has the same ip (no domain name on my laptop) so they ended up being the same. I guess in that situation you would just want to use the the default hostname for the "actual" site? Then what if you actually were to deploy something, however without using DNS hostnames?
This problem was nonexistent on my VPS since I could use the IP and direct to a blank page and use my domain name as the hostname of the virtual host which directed to the actual site. Then again what if I didn't have a DNS name and only IP's? I would have to give up this "redirect to blank"-security?
Slightly off topic:
I tried installing the Fossil version control and set it up using CGI. I got a 404 (yes I was using the correct), however with another test CGI script which basically just wrote back some plain/text it worked, so I guess this is an issue with Fossil and Hiawatha can be ruled out as to the blaim?
Thanks.
Hugo Leisink
18 November 2010, 09:44
If you are using it on your laptop for testing purposes only, you can simply use the default host. The security risk of vulnerablity scanners finding your laptop is zero (assuming that you don't allow incoming traffic from the internet to your laptop).
If you don't have a hostname for your server (you only have an IP address) than the 'redirect to blank page' security trick can not be done. But domainnames aren't expensive and there is always the option of using a free hostname (via dyndns.org for example).
Can it be possible that this Fossil application is generating the 404 error? Try adding 'TriggerOnCGIstatus = no' to your host configuration block.
Søren Enevoldsen
18 November 2010, 11:55
I tried adding that command and restarted the server same result. This works fine:
//test2.cgi
#!/bin/bash
echo "Content-Type: text/plain"
echo ""
echo "Hello world wide web."
Works fine, however:
//test.cgi
#!/usr/bin/fossil
repository: /var/www/fossil/test.fossil
Gives the 404 error and, instead of viewing
domain/test.cgi
i'm now viewing the 404 at
domain/test.cgi/index.
My guess is that fossil is the problem, is there any other configuration option that I should try?
Søren Enevoldsen
20 November 2010, 15:19
I talked to the Fossil guys (actually the developer) and he came to the conclusion that by me using this cgi script:
#!/bin/bash
echo "Content-Type: text/plain"
echo ""
echo "Hello world wide web."
env | sort
The result from:
http://www.my-domain.com/test.cgi
Is:
------------------------------------------
Hello world wide web.
DOCUMENT_ROOT=/var/www/html
GATEWAY_INTERFACE=CGI/1.1
HTTPS=off
HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_ENCODING=gzip,deflate
HTTP_ACCEPT_LANGUAGE=da,en-us;q=0.7,en;q=0.3
HTTP_HOST=www.my-domain.dk
HTTP_RETURN_CODE=200
HTTP_SCHEME=http
HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 6.0; da; rv:1.9.2.12)
Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729)
PWD=/var/www/html
REDIRECT_STATUS=200
REMOTE_ADDR=my-ip
REQUEST_METHOD=GET
REQUEST_URI=/test.cgi
SCRIPT_FILENAME=/var/www/html/test.cgi
SCRIPT_NAME=/test.cgi
SERVER_ADDR=0.0.0.0
SERVER_NAME=www.my-domain.dk
SERVER_PORT=80
SERVER_PROTOCOL=HTTP/1.1
SERVER_SOFTWARE=Hiawatha v7.4
SHLVL=1
_=/usr/bin/env
-----------------------------------------
However, the result from
http://www.my-domain.com/test.cgi/index is 404 he concluded that either something is wrong with Hiawatha or my configuration of Hiawatha since PATH_INFO is not set to /index.
Assuming he is correct and it is the latter of the two suggested reason what can I do?
Søren Enevoldsen
20 November 2010, 15:20
Oh btw here is the mailing list where I posted my problem: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg02948.html
Søren Enevoldsen
20 November 2010, 15:41
I solved the problem by
EnablePathInfo = yes
In the configuration for my virtual host.
What are the security implications of enabling this since it is not enabled by default?
Thanks for the help
Hugo Leisink
20 November 2010, 15:53
EnablePathInfo is indeed the solution.
The reason why it is not enabled by default is because it requires some extra disk activity and thus makes it slower. Writing an application which works via PATH_INFO is an 'antique' method if you ask me. A better and modern way is by using URL rewriting. But that's something for the Fossil developer to worry about.
Søren Enevoldsen
20 November 2010, 16:21
CGI and URL rewriting is very new to me. However I'm not sure how url rewriting would work for a program like Fossil. Basically Fossil is just a single binary. The repositories themselves are a single sqlite database (.fossil) or something similar. My guess is that the binary uses the PATH_INFO to determine what data to load from the .fossil (sqlite database).
Again I new to this, so I might me lacking even the most basic knowledge necessary to explain why it can be done using url rewrites.
Hugo Leisink
20 November 2010, 16:46
Well, I can tell you of course a lot about CGI, PATH_INFO and URL rewriting. But, the internet is filled with it and Google is a good start. I suggest you start reading. If you have a specific question to which you can't find a proper answer on the internet, I'll be more than willing to help you.
This topic has been closed.