On Mon, 2009-09-21 at 23:34 +0200, Leigh Smith wrote:
> First off, thanks everyone for a great CalDAV server!
>
> Running davical on a non VHOSTed server:
>
> To host davical on a cPanel hosted server I found I had to modify
> davical source to deal with the security restrictions that are in
> place. Virtual hosting and superuser access are not possible on such a
> server.
>
> This required reorganising the layout of the include files when it is
> not possible to create the directory /etc/davical. One solution would
> be to simply place the "inc" directory within "htdocs" so the relative
> path "inc/always.php" can be loaded. Until I verified that this would
> be secure with the mail list, I wanted a little more security by
> placing the inc files outside of the directory that hosts the htdocs
> (renamed "calendar" in my case). So I created a "davical" directory
> next to my "calendar" directory holding the htdocs. The include files
> sit there in "davical/inc" subdirectory and the configuration file
> davical/servername-conf.php. Since I wanted to simplify the location
> of all source, I simply copied all the files in awl/inc into davical/
> inc. This leaves me with a directory structure as:
>
> calendar/caldav.php
> ...
> calendar/index.php etc.
> davical/servername-conf.php
> davical/inc/*.php
>
> The patches to the source are fairly minimal to help locate the
> configuration file:
Hi Leigh,
Thanks for your comprehensive review of the installation on CPanel. This
is definitely information we could do with in the wiki, and it would be
great if we can improve the user experience for such installations too.
A lot of your proposed changes sound to me like the sort of activity
that would often be applied by a distribution maintainer (i.e. move
files around, make some small systematic adjustments to paths, chunk
stuff together), and if you (or someone else :-) want to maintain a
'CPanel distribution' of DAViCal that does this that would be a nice
thing to have available.
Anything like 'including a copy of AWL within every release of DAViCal'
smells like a hack to me, however, and I don't want to do that as a part
of the *standard* distribution.
> and changing all the require_once("../inc/always.php"); entries to
> require_once("../davical/inc/always.php"); in htdocs/*.php:
I think it would be good if you could come up with a better way of
handling this issue. Something that would work for everyone, and not
just for the hosted environment.
For example, can you just do something like:
php_value include_path /path/to/davical/inc
in your .htaccess, at which point "../inc/always.php" should find the
correct file?
I'm afraid I'm not very familiar with the problems of running in an
environment without root access, so I don't actually use .htaccess files
anywhere - perhaps that's not possible, or wouldn't work as I imagine.
> This seems to work very well and I have been hosting many calendars
> for several months on a third party hosted server. May I suggest
> adding the $c->config_directory entry simplifies the installation of
> davical and makes it possible to manage on servers without super user
> access?
I don't understand how $c->config_directory gets set to something
without finding a configuration file first which sets it.
Also, DAViCal already also looks in ../config/config.php for the
configuration file, if there is no configuration in /etc/davical. What &
where that is found would depend on the PHP include path setting too, I
would think.
> Also would it be secure to move the "inc" directory (with the files
> from awl) within htdocs, so that it is easier to install the PHP files
> into a single directory tree, rather than two source directories which
> must sit next to each other? The patches above would still be required
> to find the configuration file, unless that would still be secure to
> be live inside a "htdocs/config" directory? This is actually the
> strategy used by drupal, for example.
I think this is something better addressed within some kind of 'CPanel
distribution' which could be built by a script from the raw .tar.gz
files made available with each release.
> 2. PostgreSQL database usernames are fixed.
> On cPanel hosted servers, postgreSQL database and user naming must
> meet a certain format, for example username_databasename and
> username_dbuser respectively. For example leighsmi_davical and
> leighsmi_davicalapp (no underscores are allowed in the username after
> the unix username. The PostgreSQL databases are created using a web
> admin application (phpPgAdmin), not using the shell script.
DAViCal doesn't require the database to be called 'davical', though the
helper scripts do tend to implement that default. The database name is
the first parameter to the create-database script, and for my regression
testing the database is called 'regression', so it definitely works fine
with the database named something else!
> 3. Requires a shell for running configuration shell scripts.
> Since most of these scripts simply execute SQL queries, could this
> also be done with an install PHP script which are run from a browser?
Yes, it could be done from a PHP script. The shell script is really
just something that is there because that's easiest for me, but if you
wanted to write an install script in PHP then that would be awesome.
You know how these things grow: first it's a five line shell script, and
then a 20 line one. Sprinkle a few subroutines through it to 'simplify'
it and suddenly you've given birth to a monster! Of course it's a
monster that 'does the job', and so it's 'good enough' until someone
like you, with a different set of itches, comes along and wants some
scratching :-)
Installation should be separate from upgrading because installation will
often need to write something to the filesystem, which it would be
(very) desirable to make read-only after creation.
> 4. You need to be super user to create the plsql procedural language.
Hopefully newer installations of PostgreSQL have PL/PgSQL configured in
the template1 database from which all databases are created. There are
good performance reasons for using in-database functions for some
things.
> It would be great to give the user the option of using MySQL or other
> DB's
Unfortunately MySQL (and some "other DB's") have significant drawbacks
in comparison to PostgreSQL. Nevertheless some changes are slowly
creeping into DAViCal to allow for the ability to write support for
other databases.
> 5. Requires Perl
> However, other than the initial configuration, this isn't required for
> normal running of the system. Could this be replaced with PHP scripts?
It's mainly the upgrade process that uses Perl, but since that's also
called from within the create database script that is kind of moot :-)
I'm sure it could be rewritten in PHP though, if anyone is keen.
> 6. Requires Perl DBD::Pg and DBD::YAML
> Most systems should have these, but on the cPanel server I was working
> with, it doesn't come installed (for security), requiring begging the
> sysadmin to install it for you. So it's easier if this was done in PHP.
I fail to see why these would not be installed 'for security', though
obviously they might not be installed for plenty of other reasons.
Remove the dependency on Perl, however, and these would also not be
needed.
Please bear in mind that although on a couple of occasions people have
actually paid me to make some specific changes to DAViCal, the
development of the software is basically unfunded.
* I definitely enjoy working with PostgreSQL more than with MySQL (i.e
from this programmer's perspective 'MySQL is teh suck' as some of my
friends would put it).
* I am finding that I tend to prefer the client/server interaction parts
of the code to the writing of admin web pages.
* I sometimes have other things which DAViCal takes second priority to
in order to earn some money, or the goodwill of my family, friends and
business partners.
So while I enjoy writing and supporting it, some parts are more likely
to see my attention than others. I have no plans to stop working on
DAViCal (and I'm even hoping to increase the time I spend on it) but
there is a lot more to do than the tasks outlined in this e-mail.
At this stage, too, it's definitely me that is doing most of the work,
though I do get contributions from others from time to time, and there
are some signs that the project is starting to see activity from a wider
range of developers, which I do definitely welcome.
I should probably blog something like the above, and maybe also about
how much I love receiving nice, incremental, easily understandable
patches in my mailbox, too :-)
Cheers,
Andrew.
PS. I've CC'd the davical developers mailing list in case someone wants
to discuss technical issues around implementing any specific parts of
this on there.
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Good day for a change of scene. Repaper the bedroom wall.
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20090922/42872dff/attachment.pgp>
> First off, thanks everyone for a great CalDAV server!
>
> Running davical on a non VHOSTed server:
>
> To host davical on a cPanel hosted server I found I had to modify
> davical source to deal with the security restrictions that are in
> place. Virtual hosting and superuser access are not possible on such a
> server.
>
> This required reorganising the layout of the include files when it is
> not possible to create the directory /etc/davical. One solution would
> be to simply place the "inc" directory within "htdocs" so the relative
> path "inc/always.php" can be loaded. Until I verified that this would
> be secure with the mail list, I wanted a little more security by
> placing the inc files outside of the directory that hosts the htdocs
> (renamed "calendar" in my case). So I created a "davical" directory
> next to my "calendar" directory holding the htdocs. The include files
> sit there in "davical/inc" subdirectory and the configuration file
> davical/servername-conf.php. Since I wanted to simplify the location
> of all source, I simply copied all the files in awl/inc into davical/
> inc. This leaves me with a directory structure as:
>
> calendar/caldav.php
> ...
> calendar/index.php etc.
> davical/servername-conf.php
> davical/inc/*.php
>
> The patches to the source are fairly minimal to help locate the
> configuration file:
Hi Leigh,
Thanks for your comprehensive review of the installation on CPanel. This
is definitely information we could do with in the wiki, and it would be
great if we can improve the user experience for such installations too.
A lot of your proposed changes sound to me like the sort of activity
that would often be applied by a distribution maintainer (i.e. move
files around, make some small systematic adjustments to paths, chunk
stuff together), and if you (or someone else :-) want to maintain a
'CPanel distribution' of DAViCal that does this that would be a nice
thing to have available.
Anything like 'including a copy of AWL within every release of DAViCal'
smells like a hack to me, however, and I don't want to do that as a part
of the *standard* distribution.
> and changing all the require_once("../inc/always.php"); entries to
> require_once("../davical/inc/always.php"); in htdocs/*.php:
I think it would be good if you could come up with a better way of
handling this issue. Something that would work for everyone, and not
just for the hosted environment.
For example, can you just do something like:
php_value include_path /path/to/davical/inc
in your .htaccess, at which point "../inc/always.php" should find the
correct file?
I'm afraid I'm not very familiar with the problems of running in an
environment without root access, so I don't actually use .htaccess files
anywhere - perhaps that's not possible, or wouldn't work as I imagine.
> This seems to work very well and I have been hosting many calendars
> for several months on a third party hosted server. May I suggest
> adding the $c->config_directory entry simplifies the installation of
> davical and makes it possible to manage on servers without super user
> access?
I don't understand how $c->config_directory gets set to something
without finding a configuration file first which sets it.
Also, DAViCal already also looks in ../config/config.php for the
configuration file, if there is no configuration in /etc/davical. What &
where that is found would depend on the PHP include path setting too, I
would think.
> Also would it be secure to move the "inc" directory (with the files
> from awl) within htdocs, so that it is easier to install the PHP files
> into a single directory tree, rather than two source directories which
> must sit next to each other? The patches above would still be required
> to find the configuration file, unless that would still be secure to
> be live inside a "htdocs/config" directory? This is actually the
> strategy used by drupal, for example.
I think this is something better addressed within some kind of 'CPanel
distribution' which could be built by a script from the raw .tar.gz
files made available with each release.
> 2. PostgreSQL database usernames are fixed.
> On cPanel hosted servers, postgreSQL database and user naming must
> meet a certain format, for example username_databasename and
> username_dbuser respectively. For example leighsmi_davical and
> leighsmi_davicalapp (no underscores are allowed in the username after
> the unix username. The PostgreSQL databases are created using a web
> admin application (phpPgAdmin), not using the shell script.
DAViCal doesn't require the database to be called 'davical', though the
helper scripts do tend to implement that default. The database name is
the first parameter to the create-database script, and for my regression
testing the database is called 'regression', so it definitely works fine
with the database named something else!
> 3. Requires a shell for running configuration shell scripts.
> Since most of these scripts simply execute SQL queries, could this
> also be done with an install PHP script which are run from a browser?
Yes, it could be done from a PHP script. The shell script is really
just something that is there because that's easiest for me, but if you
wanted to write an install script in PHP then that would be awesome.
You know how these things grow: first it's a five line shell script, and
then a 20 line one. Sprinkle a few subroutines through it to 'simplify'
it and suddenly you've given birth to a monster! Of course it's a
monster that 'does the job', and so it's 'good enough' until someone
like you, with a different set of itches, comes along and wants some
scratching :-)
Installation should be separate from upgrading because installation will
often need to write something to the filesystem, which it would be
(very) desirable to make read-only after creation.
> 4. You need to be super user to create the plsql procedural language.
Hopefully newer installations of PostgreSQL have PL/PgSQL configured in
the template1 database from which all databases are created. There are
good performance reasons for using in-database functions for some
things.
> It would be great to give the user the option of using MySQL or other
> DB's
Unfortunately MySQL (and some "other DB's") have significant drawbacks
in comparison to PostgreSQL. Nevertheless some changes are slowly
creeping into DAViCal to allow for the ability to write support for
other databases.
> 5. Requires Perl
> However, other than the initial configuration, this isn't required for
> normal running of the system. Could this be replaced with PHP scripts?
It's mainly the upgrade process that uses Perl, but since that's also
called from within the create database script that is kind of moot :-)
I'm sure it could be rewritten in PHP though, if anyone is keen.
> 6. Requires Perl DBD::Pg and DBD::YAML
> Most systems should have these, but on the cPanel server I was working
> with, it doesn't come installed (for security), requiring begging the
> sysadmin to install it for you. So it's easier if this was done in PHP.
I fail to see why these would not be installed 'for security', though
obviously they might not be installed for plenty of other reasons.
Remove the dependency on Perl, however, and these would also not be
needed.
Please bear in mind that although on a couple of occasions people have
actually paid me to make some specific changes to DAViCal, the
development of the software is basically unfunded.
* I definitely enjoy working with PostgreSQL more than with MySQL (i.e
from this programmer's perspective 'MySQL is teh suck' as some of my
friends would put it).
* I am finding that I tend to prefer the client/server interaction parts
of the code to the writing of admin web pages.
* I sometimes have other things which DAViCal takes second priority to
in order to earn some money, or the goodwill of my family, friends and
business partners.
So while I enjoy writing and supporting it, some parts are more likely
to see my attention than others. I have no plans to stop working on
DAViCal (and I'm even hoping to increase the time I spend on it) but
there is a lot more to do than the tasks outlined in this e-mail.
At this stage, too, it's definitely me that is doing most of the work,
though I do get contributions from others from time to time, and there
are some signs that the project is starting to see activity from a wider
range of developers, which I do definitely welcome.
I should probably blog something like the above, and maybe also about
how much I love receiving nice, incremental, easily understandable
patches in my mailbox, too :-)
Cheers,
Andrew.
PS. I've CC'd the davical developers mailing list in case someone wants
to discuss technical issues around implementing any specific parts of
this on there.
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Good day for a change of scene. Repaper the bedroom wall.
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20090922/42872dff/attachment.pgp>