Problems installing Seafile in a subdirectory (shared HTTPS website)

[Vittorio Bertola]

Hello,

I have installed Seafile recently and it's a great piece of software, much needed, so first of all thanks to the developers.

My first install was the standard one, on port 8000 of an HTTP website without even using Apache (server: 3.1.6 on Debian 6; client: seaf-cli on Gentoo). It worked perfectly.

Then I decided that I would like to have my communications encrypted and tried to migrate the install to an HTTPS website. However, I only have one IP available on my remote server, and I already have other HTTPS services, and as you may know there is not a real way to have name-based virtual hosts under HTTPS, so my only option is to install Seafile in a subdirectory of my single HTTPS website, e.g. http://ssl.mydomain.com/seafile/ .

There is no real documentation for this in the manual, so I tried to fix the settings given in the manual, and this is what I came up with:

- in apache2.conf:

FastCGIExternalServer /var/www/ssl.mydomain.com/seafile/seahub.fcgi -host 127.0.0.1:8000

- in Apache's ssl.mydomain.com host configuration:

    Alias /media  /opt/seafile/seafile-server-latest/seahub/media

    RewriteEngine On

    #

    # seafile fileserver

    #

    ProxyPass /seafile/seafhttp http://127.0.0.1:8082

    ProxyPassReverse /seafile/seafhttp http://127.0.0.1:8082

    RewriteRule ^/seafile/seafhttp - [QSA,L]

    #

    # seahub

    #

#    RewriteRule ^/seafile/(media.*)$ /$1 [QSA,L,PT]

    RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteRule ^/seafile(/.*)$ /seafile/seahub.fcgi$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

- in ccnet.conf:

SERVICE_URL = https://ssl.mydomain.com/seafile/

- in seahub_settings.py:

FILE_SERVER_ROOT = 'https://ssl.mydomain.com/seafile/seafhttp'

SITE_BASE = 'https://ssl.mydomain.com/seafile/'

SITE_ROOT = '/seafile/'

This almost works... but doesn't work. I can load Seafile's web interface at https://ssl.mydomain.com/seafile/ , but though graphics (logo, header and footer) are ok, in place of my content I get the Italian equivalent a "Sorry, page not found" message. Same happens if I click on "my homepage".

If I look into my Apache's rewrite logs, the initial request for https://ssl.mydomain.com/seafile/ gets translated to

/var/www/ssl.mydomain.com/seafile/seahub.fcgi/

which apparently is ok, but then comes a series of subrequests for /, /index.html, /index.cgi etc (looking for the directory index) which of course are not picked up by the rewrite rules and end up in a page not found. Perhaps Seafile should rather do these subrequests for something under /seafile/ ?

Is what I am trying to do possible at all? Otherwise it doesn't seem possible to run Seafile under HTTPS unless you can have a dedicated IP for this service, which is not an easy requirement for personal/small office usage.

Also, there are a couple other issues that I noticed:

1) Even if I set SITE_ROOT etc, all media links in the page still point at /media rather than at /seafile/media as I'd like.

2) In several places (e.g. the reports on new uploads in the Web interface for a library, or logs/seahub_django_request.log) times are given in Chinese time rather than in my local time.

Any help for my main task would be much appreciated.

Thanks,

[Vittorio Bertola]

(sorry, I just noticed that I mistyped the URL once, it's always https://ssl.mydomain.com/seafile/ and not http://ssl.mydomain.com/seafile/ )

[selva]

I have not used subdirectory install, but I can say that name-based virtual hosting works quite well for https these days with widespread SNI support in browsers. The need for dedicated IP for ssl hosting is quickly becoming a thing of the past unless you need to support old browsers and pre-vista OSes. The seafile windows desktop client also supports SNI, and all current browsers on most modern OSes (not on windows XP, though) support SNI, so it may work for you. Works well here..

Selva

[Vittorio Bertola]

Thanks, in the end I may accept that solution, you are right that nowadays there are not so many older clients that will not support SNI. However, there may be a number of reasons for people to install Seafile in a subdirectory, so it would be useful if that was documented and made to work easily by the developers (though my #1 feature request at the moment is to have the Windows client use the system proxy settings and be able to work via port 80/443 only, to cope with office environments where all outgoing traffic from desktops has to go through the local network's proxy).

[selva]

Subdirectory install is indeed useful.  Have you looked at the documentation about this. In you config /var/www/ssl.mydomain.com the document root,  Have you looked at the documentation about this.There is a mention of setting MEDIA_URL='/seafile/media/' in  seahub_settings.py  -- will require a corresponding Alias in apache config as well.
 
As for SITE_ROOT is not applied to all urls, hopefully one of the developers can help.

[selva]

Typo correction:

> In you config /var/www/ssl.mydomain.com the document root

I meant to ask whether that is the document root?

[Thomas Harold]

I've been banging about using the documentation for this and I'm pretty sure that it is incomplete.
http://manual.seafile.com/deploy/deploy_Seahub_at_Non-root_domain.html

On one page (the "deploy with apache"), the rewrite rule is:

RewriteRule ^/(seahub.*)$ /seahub.fcgi/$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

RewriteRule ^/(seafile.*)$ /seahub.fcgi/$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

And it's not really understandable why it is written that way.

I'd like to find someone with a working sub-directory install on HTTPS behind Apache who has documented their configuration.

On Sunday, October 26, 2014 10:15:24 AM UTC-4, selva wrote: