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
