Installation on Archlinux/Lighttpd

[joel-porquet]

Hi,

I struggled a little bit to have php-remote-storage on Archlinux with lighttpd but it works now and I thought I could share.

At first, I wanted to host it as a subdirectory on my main domain name (eg https://toto.org/php-remote-storage/) but the webfinger thing makes it difficult since something has to answer to "https://toto.org/.well-known/..." (took me a while to understand the concept). I then opted for creating a subdomain where php-remote-storage is hosted directly at the root (eg https://storage.toto.org) to make things easier.

For archlinux, I started by creating a new package on AUR for the 1.0.4 release: https://aur.archlinux.org/packages/php-remote-storage/. I spent all morning debugging because I couldn't figure out how to have lighttpd pass a non-empty query string, which made things like $request->getUrl()->getQueryParam("resource") fail, and I had to patch the php-url-lib code for it to work. It's only later that I realized that the git version didn't have these issues because it refers to fkooman/php-url-lib >= 2.0.0 which already corrects the query string issue by manually parsing the request_uri instead (basically the same trick I had started implementing).

So I created another package on AUR which takes the git version instead of the latest release (https://aur.archlinux.org/packages/php-remote-storage-git). And now it works.

Here is a snippet of my lighttpd configuration:

## storage subdomain configuration
$HTTP["host"] == "storage.toto.org" {

    var.remotestorage_path = "/usr/share/webapps/php-remote-storage/web"
    var.remotestorage_etc = "/etc/webapps/php-remote-storage"

    # use this path instead of the normal document-root
    server.document-root = remotestorage_path

    # new index file
    index-file.names = ("index.php")

    # rewriting rule
    url.rewrite-if-not-file = (
                    "^/([^?]*)" => "/index.php/$1",
                    )

    # special configuration for php
    fastcgi.server = (
                    ".php" => (
                            "localhost" => (
                                    "bin-path" => "/usr/bin/php-cgi",
                                    "socket" => "/var/lib/php-fastcgi-remotestorage.socket",
                                    "max-procs" => 1,
                                    "broken-scriptfilename" => "enable"
                                    )
                            )
                    )
}

Let me know if you have any question! Cheers, Joël

[fkooman]

Would it help to create a 1.0.5 release that has the new php-lib-http? I didn't release so far because i'm afraid the reverse proxy stuff that's used by IndieHosters would break. But maybe I should just release and see what happens ;)

[fkooman]

Oh, and there is also RPM packaging stuff available and some more deploy stuff in this repo.

[anmol26s]

@joel-porquet I am having same problem for nginx configuration. Do you know solution for nginx?

[joel-porquet]

No, I've never used nginx. However, there is a link to another ticket above (#44) which seems to explain, in length, how to configure php-remote-storage for nginx. Good luck!

[raucao]

@joel-porquet That's from where I directed @anmol26s here, because I saw https://github.com/Laverna/laverna/issues/515#issuecomment-277011225 where you link here and say you got it working.

@anmol26s The issue description above contains this:

It's only later that I realized that the git version didn't have these issues because it refers to fkooman/php-url-lib >= 2.0.0 which already corrects the query string issue by manually parsing the request_uri instead (basically the same trick I had started implementing).

So I created another package on AUR which takes the git version instead of the latest release (https://aur.archlinux.org/packages/php-remote-storage-git). And now it works.

So basically an outdated dependency, which is already up to date in newer version of the software it seems. Not sure if that applies to you, but it's what was linked in the original Laverna issue, so at least worth considering.