Forum

Hi Hugo,

thank you for Hiawatha!

I'm trying to use Hiawatha as secure proxy server for seafile[1] however I'm not sure if I've done it right - I'm a bit confused as the seafile people use two different options (fastcgi_pass, proxy_pass) for nginx. Whilst the proxy to :8000 (seahub web interface) works flawless the requests to :8082 (httpserver to pull/push media files) always return an empty response. Maybe you can have a quick look at it? Accessing both services without proxy works fine.

My Hiawatha:

VirtualHost {
	Hostname = www.server.name
	ReverseProxy /seafhttp http://127.0.0.1:8082
	ReverseProxy .* http://127.0.0.1:8000
	WebsiteRoot = /srv/http/www.server.name/public
	RequireSSL = yes
	SSLcertFile = /etc/hiawatha/www.server.name.pem
}

Recommended NGINX [2]:

...
location / {
	fastcgi_pass    127.0.0.1:8000;
	...
}
location /seafhttp {
	rewrite ^/seafhttp(.*)$ $1 break;
	proxy_pass http://127.0.0.1:8082;
	client_max_body_size 0;
}
...

[1] https://github.com/haiwen/seafile
[2] https://github.com/haiwen/seafile/wiki/Enable-Https-on-Seafile-web-with-nginx

Hiawatha version: Hiawatha v9.2, cache, IPv6, reverse proxy, SSL (1.2.8), URL toolkit, XSLT
Operating System: Archlinux

Thanks for your help!

Side note: while I obviously don't need a webroot it seems to be a mandatory element ("websiteroot is missing") in hiawatha configuration. Did'nt find that in hiawatha manual.

What do you mean by 'empty response'? Is the response a valid HTTP response (valid HTTP header), but with no content (emtpy body)? Or no response at all?

A valid response with no content.

As seafile works without proxy and it generally should work with a proxy (apache+nginx confirmed by developers) my guess is that there are not enough informationen passed to the :8082 port service, i.e. missing parameters ($1) or something like that.

I really don't want to bother you with my specific usage of your great webserver, it would be of great help to me if you just could confirm that the translated configuration looks OK to you.

If it's a valid response but there is no HTTP body, my guess is that the problem lies in the application. Perhaps the application requires something specific that Apache and Nginx do, but Hiawatha doesn't. I have no idea what that might be.

This is just a wild guess, but have you tried to use a separate hostname for the file server? Because then the rewrite which the nginx sample config uses and which does not seem possible in hiawatha is not necessary.
Also you are using a reverse proxy for the web interface, but have you tried the fastcgi version, which seems far more appropriate for this kind of application? I am asking, because I am planning to use hiawatha as the seafile frontend, too.

I tried this myself now and a separate hostname for the fileserver works just fine.
However I could not get the FastCGI version of seahub running, it just repeatedly redirects to the login page until the browser stops due to too many redirects.
The apache config looks like this:

FastCGIExternalServer /var/www/seahub.fcgi -host 127.0.0.1:8000
# in virtual host:
RewriteRule ^(.*)$ /seahub.fcgi$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

It looks like seahub extracts the path from the script-name or something? At least it does not finds its way into seahub.

I am running seafile 2.0.1 on debian wheezy.

My configuration for the working reverse-proxy version: (omitting log files)

VirtualHost { # seahub proxy
    Hostname = cloud.domain.tld
    WebsiteRoot = /home/website/cloud.domain.tld/www
    SSLcertFile = /etc/hiawatha/cert/cloud.domain.tld/cloud.domain.tld.pem
    RequireSSL = true
    ReverseProxy .* http://127.0.0.1:8000
}

And the currently not working Fast-CGI version: (you have to start seahub using ./seahub.sh start-fastcgi)

VirtualHost { # seahub fastcgi
    Hostname = cloud.domain.tld
    WebsiteRoot = /home/website/cloud.domain.tld/www
    SSLcertFile = /etc/hiawatha/cert/cloud.domain.tld/cloud.domain.tld.pem
    RequireSSL = true
    UseToolkit = seahub
}

FastCGIserver {
    FastCGIid = seahub
    ConnectTo = 127.0.0.1:8000
}

UrlToolkit {
    ToolkitID = seahub
    Match .* UseFastCGI seahub
}

The file server is the same in both cases:

VirtualHost { # seahub files
    Hostname = files.cloud.domain.tld
    WebsiteRoot = /home/website/cloud.domain.tld/www
    SSLcertFile = /etc/hiawatha/cert/files.cloud.domain.tld/files.cloud.domain.tld.pem
    RequireSSL = true
    ReverseProxy .* http://127.0.0.1:8082 3600
}

The Apache configuration tells me that port 8000 speaks FastCGI. I find it strange that using a reverse proxy (which speaks HTTP, not FastCGI) to forward requests to that port works.

The 'currently not working Fast-CGI version' is the correct Hiawatha translation of the Apache configuration. The only thing missing is the rewrite of the URL. You can try using this UrlToolkit rule:

UrlToolkit {
    ToolkitID = seahub
    Match ^/(.*) Rewrite /seahub.fcgi/$1 Continue
    Match .* UseFastCGI seahub
}

Seahub supports both FastCGI and HTTP, depending on how you start it:
<pre>
./seahub.sh start-fastcgi [port] # fcgi server
./seahub.sh start [port] # http server
</pre>

Thanks for the tip with the rewrite, I somehow missed the Match-Continue rule. I will try this tomorrow!

Klemens - thank you for your work to get seafile running. I'm still stuck with the empty response; trying your solutions with the two hostnames doesn't work for me.

As far as I can see the fileserver still would require the rewrite "Match ^seafhttp(.*)$ Rewrite $1" - seahub will give you a URL like https://files.cloud.domain.tld/seafhttp/files/id/sample.jpg - which gives an empty response. Calling https://files.cloud.domain.tld/files/id/sample.jpg (without the /seafhttp) manually works fine. So if the rewrite would be done before the proxy everything would be fine.

I'm running seafile 1.8.1 under Archlinux, you 2.0.1 under Wheezy - maybe that makes a difference too - I'll try to upgrade over the weekend...

I think you should take this issue to the Seafile author. I think they are using some Apache-only feature.

@Martin: You have to change the url in the seahub config as described in the wiki. (HTTP_SERVER_ROOT = 'files.cloud.domain.tld') Then the right url is generated.

I did not have time to do further tests, but since everything is working fine for me, the not working fastcgi is only a minor issue. (especially for the seahub developers)

I missed the protocol, it obviously should read: HTTP_SERVER_ROOT = 'https://files.cloud.domain.tld'

And I don't think the version makes a difference. Apart from the new crypto system and the fsck tool, they only changed minor things: https://seacloud.cc/group/3/wiki/server-changelog/ (the install instructions did not change either)

@Klemens - thanks for the crucial hint. In fact I did already change the seahub config, but stupid me left the /seafhttp postfix Sometimes you can't see the wood for the trees...

Changed
HTTP_SERVER_ROOT = 'https://files.cloud.domain.tld/seafhttp'
to
HTTP_SERVER_ROOT = 'https://files.cloud.domain.tld'
and it works now

(Note: no backslash at the end of URL in HTTP_SERVER_ROOT - will break it)

As for the FCGI I really don't care about it, as you said it's working one way. I'm using seafile-admin to start/stop, I don't even know if the script supports FCGI mode. Also thank you Hugo for your support!