Mailing List Archive: Installation issues on Fedora 12, and perhaps elsewhere

Installation issues on Fedora 12, and perhaps elsewhere

Jan 1, 2010, 5:24 PM

Post #1 of 3 (584 views)

I have just installed DAViCal (and just joined this list), so apologies
in advance if I'm covering some old ground.

I installed DAViCal 0.9.7.6 as a Christmas present (family calendars!)
for my wife, and then promptly broke her present by upgrading my server
from Fedora 10 to Fedora 12. Here are the issues:

I kept getting "white screens" when trying to use the DAViCal web
interface. After considerable experimentation, I found that some of the
PHP configuration in the installation instructions at
http://rscds.sourceforge.net/installation.php didn't quite work:

php_value open_basedir 1

open_basedir takes a list of directories that the PHP scripts are
allowed to access. By experimentation, I ended up with

php_value open_basedir
"/usr/share/davical/:/usr/share/awl/:/etc/davical:/tmp"

It probably isn't great security to give the script access to /tmp, but
it seems to need it currently. I'm not sure how the old config ever
worked under Fedora 10, but it did.

The white screens didn't explain themselves because of the directive:

php_value error_reporting "E_ALL & ~E_NOTICE"

The symbolic values are available within PHP programs, but not in
configuration files. I ended up with:

php_value error_reporting 22527

which is E_ALL & ~E_NOTICE & ~E_DEPRECATED. I needed to turn off
E_DEPRECATED because the awl code was using a deprecated function, and
made the error logs too chatty.

Also, not a DAViCal problem, but since DAViCal is the only thing I have
currently using postgresql (everything else uses MySQL), I'm a
postgresql newbie. I hadn't done a Postgresql dump of my database, and
lost my database as a result of the version change in their on-disk data
structures. Fortunately, I hadn't lost much.

I started to update the wiki with the configuration stuff, but some of
the installation instructions aren't on the wiki, so thought I should
point out the problems as well.

Happy New Year!

-Jim

Installation issues on Fedora 12, and perhaps elsewhere [ In reply to ]

andrew at morphoss

Jan 3, 2010, 3:07 AM

Post #2 of 3 (572 views)

Permalink

On Fri, 2010-01-01 at 16:24 -0800, Jim Fenton wrote:
> I have just installed DAViCal (and just joined this list), so apologies
> in advance if I'm covering some old ground.
>
> I installed DAViCal 0.9.7.6 as a Christmas present (family calendars!)
> for my wife, and then promptly broke her present by upgrading my server
> from Fedora 10 to Fedora 12. Here are the issues:
>
> I kept getting "white screens" when trying to use the DAViCal web
> interface. After considerable experimentation, I found that some of the
> PHP configuration in the installation instructions at
> http://rscds.sourceforge.net/installation.php didn't quite work:
>
> php_value open_basedir 1
>
> open_basedir takes a list of directories that the PHP scripts are
> allowed to access. By experimentation, I ended up with
>
> php_value open_basedir
> "/usr/share/davical/:/usr/share/awl/:/etc/davical:/tmp"

I don't really recommend setting that at all, but some ISPs do want to,
and I think I got that setting from such a one. The reason for the /tmp
is because when you enable certain debugging it will try and dump some
information into /tmp. This is not done securely (it uses predictable
filenames) but nobody would be running it in production with all that
debugging turned on anyway, would they? :-)

> It probably isn't great security to give the script access to /tmp, but
> it seems to need it currently. I'm not sure how the old config ever
> worked under Fedora 10, but it did.

It does seem odd, unless the syntax of open_basedir has actually
changed. ISTR that it used to relate purely to the web root or
something, so maybe it was just binary.

> The white screens didn't explain themselves because of the directive:
>
> php_value error_reporting "E_ALL & ~E_NOTICE"
>
> The symbolic values are available within PHP programs, but not in
> configuration files. I ended up with:
>
> php_value error_reporting 22527
>
> which is E_ALL & ~E_NOTICE & ~E_DEPRECATED. I needed to turn off
> E_DEPRECATED because the awl code was using a deprecated function, and
> made the error logs too chatty.

If that was the 'call time pass by reference' warning then this is fixed
in AWL 0.39 which goes with DAViCal 0.9.8.

> Also, not a DAViCal problem, but since DAViCal is the only thing I have
> currently using postgresql (everything else uses MySQL), I'm a
> postgresql newbie. I hadn't done a Postgresql dump of my database, and
> lost my database as a result of the version change in their on-disk data
> structures. Fortunately, I hadn't lost much.

That sucks. On Debian when you install the new PostgreSQL version it
doesn't remove the old one - they just run side-by-side - and I had
understood that the RPM packaging person took those scripts into the
RPMs as well.

> I started to update the wiki with the configuration stuff, but some of
> the installation instructions aren't on the wiki, so thought I should
> point out the problems as well.

Thanks :-)

Andrew.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora Phone: +64(272)DEBIAN
Future looks spotty. You will spill soup in late evening.
------------------------------------------------------------------------

-------------- 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-users/attachments/20100103/bf57f6f9/attachment.pgp>
-------------- next part --------------

Installation issues on Fedora 12, and perhaps elsewhere [ In reply to ]

fenton at bluepopcorn

Jan 6, 2010, 12:00 AM

Post #3 of 3 (568 views)

Permalink

On 01/03/2010 02:07 AM, Andrew McMillan wrote:
> On Fri, 2010-01-01 at 16:24 -0800, Jim Fenton wrote:
>
>> open_basedir takes a list of directories that the PHP scripts are
>> allowed to access. By experimentation, I ended up with
>>
>> php_value open_basedir
>> "/usr/share/davical/:/usr/share/awl/:/etc/davical:/tmp"
>>
> I don't really recommend setting that at all, but some ISPs do want to,
> and I think I got that setting from such a one. The reason for the /tmp
> is because when you enable certain debugging it will try and dump some
> information into /tmp. This is not done securely (it uses predictable
> filenames) but nobody would be running it in production with all that
> debugging turned on anyway, would they? :-)
>
>
>
>> It probably isn't great security to give the script access to /tmp, but
>> it seems to need it currently. I'm not sure how the old config ever
>> worked under Fedora 10, but it did.
>>
> It does seem odd, unless the syntax of open_basedir has actually
> changed. ISTR that it used to relate purely to the web root or
> something, so maybe it was just binary.
>

I don't have any way of checking with previous versions of PHP, but I
haven't been able to find any documentation that shows open_basedir
taking a binary value. In any case, I created a new wiki page with this
info at RPM/Fedora_12 and if it turns out that the existing info doesn't
work elsewhere, it might be worth updating the other wiki pages and also
the example under "Using a Virtual Host" at
http://davical.org/installation.php

>
>
>> The white screens didn't explain themselves because of the directive:
>>
>> php_value error_reporting "E_ALL& ~E_NOTICE"
>>
>> The symbolic values are available within PHP programs, but not in
>> configuration files. I ended up with:
>>
>> php_value error_reporting 22527
>>
>> which is E_ALL& ~E_NOTICE& ~E_DEPRECATED. I needed to turn off
>> E_DEPRECATED because the awl code was using a deprecated function, and
>> made the error logs too chatty.
>>
> If that was the 'call time pass by reference' warning then this is fixed
> in AWL 0.39 which goes with DAViCal 0.9.8.
>

No, it was use of a depricated function (can't remember what). In any
case, I also put this on the Fedora 12 page on the wiki. Again, I
couldn't find any info that indicated the symbolic form ever had worked,
but I don't have a way to go back and check so I didn't change the
existing pages.

-Jim