[DRE-maint] Bug#852187: diaspora: current installation report

[Julian Gilbey]

Package: diaspora
Version: 0.6.0.0+debian-8
Severity: normal

Hi Pirate,

Here's a report on issues I've found trying to install the current
(0.6.0.0+debian-8) version of diaspora.

(1) The diaspora preinst reads on line 15:

    if su diaspora -s /bin/sh -c "psql  diaspora_production -c ''"

    Unfortunately, this may fail as the diaspora user is not created
    until the diaspora-common *postinst*, and the diaspora preinst may
    be run before this.  Instead, you probably want to change the user
    to be "su postgres" as the postgres user (if it exists at this
    point) will certainly be able to run this command.  (If postgres
    has not been installed, then dbexist will remain undefined.)

    I'd also add a "-" to the su command, and lose the output:
    
    su - postgres -c "psql diaspora_production -c ''" >&/dev/null

    Actually, if the diaspora package assumes that the backing
    database will be postgresql, (which may or may not be the case -
    I'm not sure), then it needs to Depends or Pre-Depends on an
    appropriate postgresql package - diaspora-common only depends on a
    choice of mysql or postgres.  And the diaspora-common package
    gives the option of psql or mysql, so this could be a problem.

(2) This is a serious bug, and renders diaspora not fit for testing;
    I'm not setting the severity right now to give the current
    unstable version a chance to enter testing, as the bug in the
    current testing version is even worse.

    The diaspora process writes to /usr, which is expressly forbidden
    by policy: /usr might be on a read-only filesystem.  See the FHS,
    very beginning of chapter 4:

        Chapter 4. The /usr Hierarchy

        Purpose

        /usr is the second major section of the filesystem. /usr is
        shareable, read-only data. That means that /usr should be
        shareable between various FHS-compliant hosts and must not be
        written to. Any information that is host-specific or varies
        with time is stored elsewhere.

    To be more precise, it stores temporary information in
    /usr/share/diaspora/tmp, rather than /var/run/diaspora.
    I *think* this can be solved by putting in a symlink
    /usr/share/diaspora/tmp -> /var/run/diaspora, but
    /var/run/diaspora would have to be created and owned by
    diaspora:nogroup before starting diaspora.  I haven't determined
    when this directory is and is not used, though - there's something
    weird going on on my machine regarding this, and I'm not convinced
    that this solution works.

    This also appears in /etc/nginx/sites-available/diaspora, where it
    listens on /usr/share/diaspora/tmp/diaspora.sock - this should be
    in /var/run.

(3) Following on from point (2), uploads I believe will be written to
    public/uploads (that's what happens on my production machine,
    running 0.6.2.0, and is implied by the nginx configuration).  So
    /usr/share/diaspora/public/uploads should be a symlink to some
    directory within /var/lib/diaspora, say
    /var/lib/diaspora/public/uploads, owned by diaspora:nogroup and
    with write permissions for diaspora.

    Again, this may need fixing in the nginx configuration, too,
    though if nginx follows the symlink it will be OK as is.

(4) /etc/diaspora/diaspora.yml still specifies: rails_environment:
    'development' rather than 'production'; this is also the case in
    /etc/diaspora/defaults.yml (which may not need modification; I
    presume that this is the defaults, and is overridden by
    diaspora.yml).

(5) I mentioned in an earlier email if I recall correctly that
    /etc/diaspora/diaspora.yml does not have url: set to the debconf
    setting; I'm unclear as to whether this is a problem as a reverse
    proxy is being used.

Best wishes,

   Julian