[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hints and problems with 0.5.5 .deb package

From: Dmitry Borodaenko
Subject: Re: hints and problems with 0.5.5 .deb package
Date: Tue, 30 Aug 2005 17:49:57 +0300
User-agent: Mutt/1.5.10i

On Sun, Aug 28, 2005 at 08:35:50PM +0200, boud wrote:
> i've tried installing samizdat-0.5.5 from the debian package on a
> sarge installation with apache-1.3.33-3 and postgresql 7.4.7-6sarge1.
> i partly succeeded, but not totally. Here is some feedback.

First of all, let me apologize for the out-of-date install.txt: there
were some changes made in the engine layout that were necessary for the
packaging, but I didn't update installation manual about these changes.
The reason is simple: once the bin/samizdat-site script is ready, it
will do all the setup work for you, at least on Debian systems, so most
of this manual configuration will only be necessary for special cases.

> 1. 

Skipped dependency resolution stuff, with current Debian/unstable and
Samizdat packages from the experimental archive it should work as
advertised. I will make a Debian/sarge backport of relevant packages
after I get Samizdat packages in shape for unstable.

> Fine. No problems.
> Samizdat object cache: disabled, see /etc/default/samizdat

It might be a good idea to enable it, just uncomment a line in the
/etc/default/samizdat. Theoretically, it should work either way, but if
it works with distributed cache and doesn't work without it, that would
help to localize a problem.

> 2.
>  * PostgreSQL Setup
>    su - postgres
>    createdb samizdat
>    createuser samizdat
> -> 
> *** What answers are recommended here?
> Shall the new user be allowed to create databases? (y/n) y
> Shall the new user be allowed to create more new users? (y/n) y

As is mentioned couple of paragraphs later, it's more secure to create
two PostgreSQL users: one for your Unix account (and use it to create
the database), and one for Web server (and only grant it a minimal
necessary access rights, as shown in *.sql scripts). That way, if e.g.
SQL injection vulnerability is found in Samizdat (or other Web engine
that you might be running in the same Web server and with the same Unix
account (www-data)), the amount of damage is somewhat reduced.

Even for your separate user, you don't have to give it database creation
right (unless you want to drop and then re-create the Samizdat database
for debug purposes), and you definitely shouldn't allow your Pg users to
create more new users, Samizdat doesn't need that, it's users are
completely orthogonal to PostgreSQL users (which in turn are orthogonal
(mostly) to Unix users).

I will update install.txt with more details about this.

> 3.
> pg_hba.conf:
> instead of:
>    local   samizdat    all                                  ident samizdat
>    local   all         all                                  ident sameuser
> i'm trying:
> local   all         postgres                                    ident 
> sameuser
> local   samizdat        all                                     ident 
> samizdat
> local   all             angdraug                                ident 
> sameuser

Right, install.txt should use your variant, it's more robust.

> 4. for the .deb installation:
>    psql samizdat -f database/create.sql
>    psql samizdat -f database/triggers.sql
> ->
>    psql samizdat -f /usr/share/samizdat/database/create.sql
>    psql samizdat -f /usr/share/samizdat/database/triggers.sql

One more thing for script to take care of.

> 5.
> >If PL/pgSQL is not enabled in the "template1" database of your
> >PostgreSQL installation, you will have to enable it in "samizdat"
> >database manually:
> >
> >   createlang plpgsql samizdat
> Maybe add: "If you don't know if it's already enabled, just do this
> anyway, it won't hurt."  i'm not a total beginner in postgresql, but
> i'm still rather new to it - i didn't figure out how to check whether
> or not "PL/pgSQL" is enabled in the template1 database. i'm sure the
> answer is easy, but at least to me it wasn't obvious. If i had known
> it was safe to do anyway, then i would have just done it and not worried.

Good point, will add that. Of course, this definitely should be done by
samizdat-site script anyway.

> 6.
> >If you use different PostgreSQL authentication method for Samizdat,
> >update Database#new method in samizdat/storage.rb accordingly.
> In /usr/lib/ruby/1.8/samizdat/storage.rb i cannot see anything
> like "Database#new method" - i don't need it, so maybe it's not needed
> anyway.

One more layout change. It should point to #db method in
samizdat/engine.rb instead.

Btw, now that libdbd-sqlite3-ruby1.8 is in unstable, it is possible to
port Samizdat to SQLite3. This will make things even more interesting :)

> 7. 
> >Unpack Samizdat into your document root (/var/www on Debian), or
> >anywhere else you want Samizdat to run from, and enable Ruby scripting
> >and URL rewriting by putting following lines into .htaccess file in that

This part of install.txt is completely irrelevant wrt Debian package.

> The 0.5.5 package still has the above line in
> /usr/share/doc/samizdat/install.txt.gz 
> after installing from .deb but in fact the apache installation
> suggested here:
> seems to only require the config.yaml file to be installed in the
> /var/www/samizdat directory or (whatever DOCUMENT_ROOT is).

Actually, it doesn't have to be DOCUMENT_ROOT, the environment variable
that matters is SAMIZDAT_BASE.

> 8.
> >In the default configuration, Samizdat will confirm email addresses for
> >new and modified accounts over email, using a sendmail program
> >configured by the email:sendmail option in the config.yaml. The same
> >From the .deb package, config.yaml is
>  /usr/share/samizdat/config.yaml
> and modifying a file outside of the /etc/ hierarchy is rather inconsistent
> with debian practice IMHO.

It probably will go to /usr/share/doc/samizdat/examples/config.yaml, I'm
just not sure whether bin/samizdat-site will use this file as a
template. It isn't used by any running Samizdat site, of course.

> But it seems to me that 
> cp -p /usr/share/samizdat/config.yaml ${DOCUMENT_ROOT}/samizdat/
> is enough.  (see point 7.)

Right. Er, almost:
cp -p /usr/share/samizdat/config.yaml ${SAMIZDAT_BASE}/

Again, that's something that will be taken care of by the
bin/samizdat-site script.

> i put in the apache config of:
> except for a few modifications of DOCUMENT_ROOT  (i use a different
> place to /var/www/samizdat)
> and i put "/samizdat" at the front of
>     AliasMatch 
>     ^/samizdat/(foci|history|index|item|login|logout|member|message|\
> moderation|pingback|query|resource)\.rb /usr/lib/cgi-bin/samizdat/$1.rb
> * same for Alias /css/ i put
> Alias /samizdat/css/ ...

Hm, I'm not sure that's correct, can you give me some context? What is
your complete vhost (it's vhost, isn't it?) setup?

> 9. OK, i get some sort of a front page :))))))))
> However, publishing with  message.rb  fails. :(  i get a new interface,
> type in some stuff in the boxes, click on preview, and then just 
> get "Sending request to... " messages in my browser but nothing changes
> in what i see in the browser (eventually i get a box with "The document
> contains no data."), and nothing appears in the apache logs.
> My guess is that the problem is something to do with authorisation 
> somewhere, file permissions, sockets, and so on?
> Any hints of what i should check?

If you redirected error logs in your vhost setup, you should actually
look at both your log and main Apache error log, some errors may happen
before your vhost enters the scene.

Also, you might want to take a look at PostgreSQL logs to check if some
connection attempts are happening.

Double-checking config.yaml also can help, check 'site:base', 'db:dsn'.

> 10. /usr/share/doc/samizdat/install.txt.gz recommends
>    ruby test/ts_samizdat.rb
> but this is not part of the .deb package

I haven't yet decided how to package the tests. For now, just grab the
source package (samizdat_*.orig.tar.gz) from the experimental archive
and use the tests from there.

> Is it a good idea to try ts_samizdat.rb from 0.5.4 on the 0.5.5 .deb
> installation?

Won't work: first check it performs is version check :)

However, ts_samizdat.rb runs the suite of non-destructive unit tests, it
won't break anything. It will just give you too many meaningless
failures if you run tests from a different version of Samizdat.

But be careful with tc_robot.rb: it is _not_ run from this suite,
because it _is_ a destructive functional test that shouldn't be run on a
production site. However, it definitely makes sense to run tc_robot.rb
on a throw-away site just to check your Samizdat setup. Just make sure
you carefully follow install.txt instructions about running it.

Dmitry Borodaenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]