[mortis@voicenet.com: Re: [Pas-dev] install stuff]

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

----- Forwarded message from "Kyle R . Burton" <mo...@vo...> -----

Date: Fri, 17 May 2002 09:52:25 -0400
From: "Kyle R . Burton" <mo...@vo...>
To: Mental <me...@ne...>
Subject: Re: [Pas-dev] install stuff
Reply-To: "Kyle R . Burton" <mo...@vo...>
X-Mailer: Mutt 095 us
In-Reply-To: <1021641569.14626.27.camel@warpath>; from Mental on Fri, May 17, 2002 at 09:19:28AM -0400

> Hello. I seem to have a little time to help out with some stuff. :)
> 
> I helped Doug get pas all set up. He got bit by file permissions. Apache
> couldnt write to the psp-cache nor the session-cache. I added a note to
> the quick start INSTALL file. Hopefully I wasn't overly verbose :)

Great!  I did write about this issue in the administrators guide.  The
admin's guide talks about the differences between a development install 
(where it's probably ok to have those directories writable) and a production 
install (where it is probably _not_ ok for those directories to be writable).

The text I'm referring to is in section 3.2.1 and 4 & 4.3 (as the section
numbering curently stands):

  3.2.1 Filesystem Permissions

  If you are installing a development server you will likely want to
  set some permissions based on your system configuration. To give the
  software access to the log file, you should set the ownership of the
  $PAS_BASE/logs directory to the user and group of the web server. The
  same should be done for the psp-cache and session-cache directories.

 and:

  4 Production System Recommendations

  Most of the configuration examples detailed in this document are
  targeted for setting up Pas for development use. Production
  environments often have very different concerns from development
  environments. Not the least of which revolve around security.

  4.1 Build System

  The build system was created to help with security concerns. The build
  system allows an administrator to explicitly compile the PSP pages so
  that they are ready to be used by Pas. This allows you to set the
  psp-cache directory up with read only permissions. Thus eliminating
  the possibility of the webserver writing to the psp-cache directory.
  For production use, you will also want to set pas.psp.dynamicRecompile
  to 'no'.

  4.2 Sessions

  The file based session system is not recommended for production
  systems. File based sessions will not perform as well, or scale as
  well as database based sessions. Not using file based sessions also
  allows you to have one less directory writable by the uid/gid of the
  webserver.

  4.3 Development and Deployment

  Our best practices for development revolve around the use of a
  versioning system, like CVS. The easiest way to perform development is
  to keep your Page objects in a directory structure sepearate from your
  PSP pages. The directory structure for your PSP pages should match
  that used on your website. In fact, we recommend that the location of
  your PSP pages be your document root for dynamic content. Static
  content can be included into the same directory, or located seperatly.
  Sites wishing to acheive higher levels of performance and redundancy
  may wish to keep static content (like images, PDF files, and static
  HTML files) on a seperate web server tuned and dedicated to serving up
  static content.

  Keeping your Page objects in a hierarchical directory structure also
  allows you to add that directory directly to Perl's include path. This
  makes it easy to set up Apache. It also makes it easy for multiple
  developers to work independantly the same server.

  Organizing your development tree in this way will also greatly
  simplify deployment to your testing and production environments. Using
  CVS, you can do an export of your codebase, build the PSP pages and
  then create a tar and gzip archive of your website's codebase. That
  archive can then be deployed to your testing and production systems.

  Alternativly, using CVS directly to perform your deployment can be
  even simpler. If your development tree matches your website's document
  root, then deployment with CVS can be as simple as performing a cvs
  update command. Rolling back to a previous version of your website, if
  you make use of tags within CVS, is just as simple.

I'm not yet settled on Lyx as the documentation tool, it just looked
like it'd be a wysiwyg editor that could output to the formats I wanted
(which I have yet to be able to get it to do).  I'm thinking of DocBook
(it's what O'Reilly uses), but it seem really complicated and I haven't
gotten it to work yet either.

Perhaps this means we should consider an install program that verifies
the environment?  It could be as simple as a tool that reports on the
environment...shouldn't be too hard.

Maybe I'll take a crack at something.

> That said, I'm writing a PostgreSQL backend piece. Looking over the
> MySQL stuff, I'm going to be re-implementing a lot of stuff. I'm already
> using postgres for imp and I'd rather not use mysql also. I'm a little
> short on ram :)

Thanks for doing that.  It'll be a useful thing to have.

> Would it be better to have an abstract class(es) for what MySQL.pm is
> doing today? Rather than calling it MySQL.pm, call it SQL.pm. Set what
> db to use in the config file... 
>
> I'm still thinking about stuff. It just seems like I'm going to be
> duplicating a lot of code. I'd like to find a better way to leverage DBI
> and abstract the database stuff a little more. 
> 
> In my mind, what would be ideal is a generic SQL class that could be
> easily subclassed for whatever DBD driver you're using. 
> 
> I guess I just need to think about it more. I just have a nagging
> feeling that I'm needlessly duplicating code. 
> 
> Feedback would be welcome as I'd like to cleanly support postgres, mysql
> and others... 

I like the idea of abstraction.  Unfortunatly you're about to learn about
some of the significant differences between the database systems.  MySQL
implicitly supports BLOBs, and so does Oracle.  PostgreSQL does not.  You
can support BLOBs, but you can not do it through SQL statements and bind
parameters.  You have to use a api custom to PostgreSQL.  Some of the
other differences betwen MySQL and Oracle are how you interact with 
autonumber columns and sequences.  MySQL doens't support explicit sequences,
though Oracle and PostgreSQL do.  And how you interact with sequences
differs betwen each of these databases.

See DBD::Pg, and look for blob_read(), also see the PostgreSQL documentation
for more information on the API.  You should have access to a session style
object I wrote that uses BLOBs in PostgreSQL on the project we both worked on.

If we can find alot of common behavior between the RDBMS session 
implementations, then I'm all for teasing out the inheritence hierarchy.
There are just some behavioral differences in the databases that we'll
have to account for.

Also, you're not forced to implement all the stuff the mysql driver does,
you only have to implement these functions:

    read_from_storage
    write_to_storage
    get_timestamp
    update_timestamp

The rest of the stuff in the MySQL.pm driver are functions I wrote
to try to keep the code clean.

Thanks for discussing this...

k

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

----- End forwarded message -----

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------