I just added a script, or well finished a great deal of what I want it to do for 0.1-stable:
Please read my comment on the corrosponding ticket: http://trac.roundcube.net/ticket/1483912#comment:16
And please provide feedback either on trac, or here. I know it doesn't do a *lot*, also doesn't magically setup RoundCube, nor does it offer a step-by-step way to set it all up. It's more to be used troubleshooting. For example, you set it up (edited the config files, or maybe forgot one) and then you pull up the page and keep reloading it until it's *all* green.
Anyway - I need an IMAP check. If anyone wants to contribute that, let me know.
Cheers, Till
P.S. We are down to 8 tickets on the current milestone: http://trac.roundcube.net/query?status=new&status=assigned&status=re...
Rejoice!!! I see the light! _______________________________________________ List info: http://lists.roundcube.net/dev/
On Feb 11, 2008, at 5:30 PM, till wrote:
Please read my comment on the corrosponding ticket: http://trac.roundcube.net/ticket/1483912#comment:16
From the comment :
We have to add a note that people don't leave this file on the
server, maybe we should add something where people cannot login
when check.php is in the "root"?
A "nag" if statement is a good solution IMHO. Several web
applications I have installed either check for the existence of
troubleshooting / install scripts at the login stage to remind admins
of a possible attack vector. You might not want to prevent login, in
case the admin is in the process of testing. IMHO a big red message
is enough.
Looking through the script :
It doesn't use the DB backend chosen from the config file, it has
MDB2 hardcoded during the TZ check.
As a result I get -
Fatal error: Call to undefined function: raise_error() in /Users/ chasd/Sites/roundcube/program/include/rcube_mdb2.inc on line 104
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
On Feb 12, 2008 4:31 PM, chasd chasd@silveroaks.com wrote:
On Feb 11, 2008, at 5:30 PM, till wrote:
Please read my comment on the corrosponding ticket: http://trac.roundcube.net/ticket/1483912#comment:16
From the comment :
We have to add a note that people don't leave this file on the server, maybe we should add something where people cannot login when check.php is in the "root"?
A "nag" if statement is a good solution IMHO. Several web applications I have installed either check for the existence of troubleshooting / install scripts at the login stage to remind admins of a possible attack vector. You might not want to prevent login, in case the admin is in the process of testing. IMHO a big red message is enough.
Looking through the script :
It doesn't use the DB backend chosen from the config file, it has MDB2 hardcoded during the TZ check. As a result I get -
Fatal error: Call to undefined function: raise_error() in /Users/ chasd/Sites/roundcube/program/include/rcube_mdb2.inc on line 104
Did you just get the script or full trunk?
Full trunk contains MDB2: http://trac.roundcube.net/browser/trunk/roundcubemail/program/lib/
Since I set the include_path() in the beginning, MDB2 should therefor be available.
Personally I don't intend to "support" DB that much longer. It's old, slower and also deprecated. Which is why I hardcoded.
Let me know, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Fatal error: Call to undefined function: raise_error() in /Users/ chasd/Sites/roundcube/program/include/rcube_mdb2.inc on line 104
Did you just get the script or full trunk?
svn update to rev 1050.
Full trunk contains MDB2:
Yeah I saw the "A" s next to the added files from the version I had
before.
Since I set the include_path() in the beginning, MDB2 should therefor be available.
Yep, MDB2 is working.
Personally I don't intend to "support" DB that much longer. It's old, slower and also deprecated. Which is why I hardcoded.
Didn't know db was deprecated, I'll switch my internal testing
instance to mdb2.
I still think there is an issue.
If I put
require_once 'include/bugs.inc';
on the line before
require_once 'include/rcube_mdb2.inc';
then I get another error -
Fatal error: Call to undefined method: mdb2_error->query() in / Users/chasd/Sites/roundcube/program/include/rcube_mdb2.inc on line 234
The MDB2 error can't bubble up because bugs.inc isn't included for
some reason.
The actual error is caused by you using a MySQL-ism "unixtimestamp()"
which is not a function in PostgreSQL or SQLite.
I use PostgreSQL ;)
roundcube=# SELECT UNIX_TIMESTAMP(now()) AS tz_db; ERROR: function unix_timestamp(timestamp with time zone) does not
exist
For PostgreSQL I think you'll want to use something like
SELECT extract(epoch from date_trunc('seconds', current_timestamp))
AS tz_db;
or
SELECT extract(epoch from date_trunc('seconds', localtimestamp)) AS
tz_db;
For SQLite you'll need something like
SELECT strftime("%s",datetime('NOW'));
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
On Feb 12, 2008 8:18 PM, chasd chasd@silveroaks.com wrote:
Fatal error: Call to undefined function: raise_error() in /Users/ chasd/Sites/roundcube/program/include/rcube_mdb2.inc on line 104
Did you just get the script or full trunk?
svn update to rev 1050.
Full trunk contains MDB2:
Yeah I saw the "A" s next to the added files from the version I had before.
Since I set the include_path() in the beginning, MDB2 should therefor be available.
Yep, MDB2 is working.
Personally I don't intend to "support" DB that much longer. It's old, slower and also deprecated. Which is why I hardcoded.
Didn't know db was deprecated, I'll switch my internal testing instance to mdb2.
I still think there is an issue.
If I put
require_once 'include/bugs.inc';
on the line before
require_once 'include/rcube_mdb2.inc';
then I get another error -
Fatal error: Call to undefined method: mdb2_error->query() in / Users/chasd/Sites/roundcube/program/include/rcube_mdb2.inc on line 234
The MDB2 error can't bubble up because bugs.inc isn't included for some reason.
Nope: http://trac.roundcube.net/browser/trunk/roundcubemail/program/include/rcube_mdb2.inc
It means that you don't have a DB resource, but an MDB2-Error object instead. ;-)
How exactly do you reproduce this?
The actual error is caused by you using a MySQL-ism "unixtimestamp()" which is not a function in PostgreSQL or SQLite. I use PostgreSQL ;)
Ah, you are the one! (Just kidding.) Let me dig up if MDB2 has an abstraction.
roundcube=# SELECT UNIX_TIMESTAMP(now()) AS tz_db; ERROR: function unix_timestamp(timestamp with time zone) does not exist
For PostgreSQL I think you'll want to use something like
SELECT extract(epoch from date_trunc('seconds', current_timestamp)) AS tz_db;
or
SELECT extract(epoch from date_trunc('seconds', localtimestamp)) AS tz_db;
For SQLite you'll need something like
SELECT strftime("%s",datetime('NOW'));
Thanks!
I'll see about this!
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Feb 12, 2008 8:35 PM, till klimpong@gmail.com wrote:
(...) Ah, you are the one! (Just kidding.) Let me dig up if MDB2 has an abstraction.
http://pear.php.net/bugs/bug.php?id=13106
I opened this, let's see. I'll see if I can implement a workaround.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I use PostgreSQL ;)
Ah, you are the one! (Just kidding.) Let me dig up if MDB2 has an
abstraction.
This error happens to me if I use MySQL, so I don't think it is a
MySQL vs. PostgreSQL thing.
I use a remote machine for the database(s). The database check in
check.php works, so
$db_working = true;
There is an abstraction for the unixtimestamp() thing in rcube_db.inc
and rcube_mdb2.inc
However I think something is amiss with the rcube_mdb2.inc file.
( looked at the two side-by-side, and there are some differences
where I don't think there should be. The version in the header(s) is
different between the two [1.16 vs. 1.17], so there might be some bug
fixes in rcube_db.inc that aren't in rcube_mdb2.inc There are some
references to PEAR:: in rcube_mdb2.inc that I think should be MDB2::)
If I hardcode using db in a couple lines from check.php instead
require_once 'include/rcube_db.inc'; $DB = new rcube_db($rcmail_config['db_dsnw'], '', false);
Then it works OK with MySQL.
I think there might be some issues in the error handling code
initialized by check.php. It isn't that I'm using PostgreSQL, but
some database error I have is triggering a code path that you aren't
exercising.
You are checking the database connection with raw MDB2:: calls, but
then for the timezone checks you use the rcube_mdb2.inc functions. I
think you should use the same code path for both.
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
One fix for PostgreSQL would be to declare a function.
Something like:
CREATE FUNCTION unix_timestamp (timestamptz) RETURNS numeric AS $BODY$ BEGIN RETURN EXTRACT(EPOCH FROM $1); END; $BODY$ LANGUAGE plpgsql;
Would do the job.
Dali
-----Original Message----- From: chasd [mailto:chasd@silveroaks.com] Sent: Wednesday, 13 February 2008 10:26 To: RoundCube Dev Subject: Re: [RCD] check.php (installer-light)
I use PostgreSQL ;)
Ah, you are the one! (Just kidding.) Let me dig up if MDB2 has an abstraction.
This error happens to me if I use MySQL, so I don't think it is a MySQL vs. PostgreSQL thing. I use a remote machine for the database(s). The database check in check.php works, so
$db_working = true;
There is an abstraction for the unixtimestamp() thing in rcube_db.inc and rcube_mdb2.inc However I think something is amiss with the rcube_mdb2.inc file.
( looked at the two side-by-side, and there are some differences where I don't think there should be. The version in the header(s) is different between the two [1.16 vs. 1.17], so there might be some bug fixes in rcube_db.inc that aren't in rcube_mdb2.inc There are some references to PEAR:: in rcube_mdb2.inc that I think should be MDB2::)
If I hardcode using db in a couple lines from check.php instead
require_once 'include/rcube_db.inc'; $DB = new rcube_db($rcmail_config['db_dsnw'], '', false);
Then it works OK with MySQL.
I think there might be some issues in the error handling code initialized by check.php. It isn't that I'm using PostgreSQL, but some database error I have is triggering a code path that you aren't exercising.
You are checking the database connection with raw MDB2:: calls, but then for the timezone checks you use the rcube_mdb2.inc functions. I think you should use the same code path for both.
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
On Feb 12, 2008 10:25 PM, chasd chasd@silveroaks.com wrote:
I use PostgreSQL ;)
Ah, you are the one! (Just kidding.) Let me dig up if MDB2 has an abstraction.
This error happens to me if I use MySQL, so I don't think it is a MySQL vs. PostgreSQL thing. I use a remote machine for the database(s). The database check in check.php works, so
$db_working = true;
There is an abstraction for the unixtimestamp() thing in rcube_db.inc and rcube_mdb2.inc However I think something is amiss with the rcube_mdb2.inc file.
( looked at the two side-by-side, and there are some differences where I don't think there should be. The version in the header(s) is different between the two [1.16 vs. 1.17], so there might be some bug fixes in rcube_db.inc that aren't in rcube_mdb2.inc There are some references to PEAR:: in rcube_mdb2.inc that I think should be MDB2::)
Basically, one class extends the other. It's fine doing PEAR::isError() or MDB2::isError(). PEAR should be included since it's a direct dependency of MDB2.
You can see PEAR.php here: http://trac.roundcube.net/browser/trunk/roundcubemail/program/lib
If I hardcode using db in a couple lines from check.php instead
require_once 'include/rcube_db.inc'; $DB = new rcube_db($rcmail_config['db_dsnw'], '', false);
Then it works OK with MySQL.
I think there might be some issues in the error handling code initialized by check.php. It isn't that I'm using PostgreSQL, but some database error I have is triggering a code path that you aren't exercising.
You are checking the database connection with raw MDB2:: calls, but then for the timezone checks you use the rcube_mdb2.inc functions. I think you should use the same code path for both.
That could be it. I'll check it out tomorrow! Thanks so far.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Feb 12, 2008 10:28 PM, Dalibor Andzakovic Dalibor.Andzakovic@swerve.co.nz wrote:
One fix for PostgreSQL would be to declare a function.
Something like:
CREATE FUNCTION unix_timestamp (timestamptz) RETURNS numeric AS $BODY$ BEGIN RETURN EXTRACT(EPOCH FROM $1); END; $BODY$ LANGUAGE plpgsql;
Would do the job.
Dali,
just out of curiousity - for how long does this "persist" in PostgreSQL?
Thanks, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
If I understand you correctly, for the length of the transaction.
SELECT unix_timestamp(now());
is identical to
BEGIN; SELECT EXTRACT(EPOCH FROM CURRENT_TIMESTAMP); COMMIT;
dali
-----Original Message----- From: till [mailto:klimpong@gmail.com] Sent: Wednesday, 13 February 2008 10:51 To: Dalibor Andzakovic Cc: RoundCube Dev Subject: Re: [RCD] check.php (installer-light)
On Feb 12, 2008 10:28 PM, Dalibor Andzakovic Dalibor.Andzakovic@swerve.co.nz wrote:
One fix for PostgreSQL would be to declare a function.
Something like:
CREATE FUNCTION unix_timestamp (timestamptz) RETURNS numeric AS $BODY$ BEGIN RETURN EXTRACT(EPOCH FROM $1); END; $BODY$ LANGUAGE plpgsql;
Would do the job.
Dali,
just out of curiousity - for how long does this "persist" in PostgreSQL?
Thanks, Till
List info: http://lists.roundcube.net/dev/
On Feb 12, 2008, at 1:52 PM, till wrote:
On Feb 12, 2008 8:35 PM, till klimpong@gmail.com wrote:
(...) Ah, you are the one! (Just kidding.) Let me dig up if MDB2 has an
abstraction.
Sorry I am not as familiar with RC code, you have that in program/
includes/rcube_mbd2.inc already which I did not know about. The
function is at line 441.
Something was making
$this->db_provider
required by the switch statement empty. Actually all of
$dsn_array[ ] is empty, even though the raw MDB2:: calls work OK.
My troubleshooting didn't go deep enough I'm afraid. I'm still poking at it.
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
On Feb 12, 2008, at 3:50 PM, till wrote:
On Feb 12, 2008 10:28 PM, Dalibor Andzakovic Dalibor.Andzakovic@swerve.co.nz wrote:
One fix for PostgreSQL would be to declare a function.
Something like:
CREATE FUNCTION unix_timestamp (timestamptz) RETURNS numeric AS $BODY$ BEGIN RETURN EXTRACT(EPOCH FROM $1); END; $BODY$ LANGUAGE plpgsql;
Would do the job.
Dali,
just out of curiousity - for how long does this "persist" in
PostgreSQL?
You could put it in the schema for the database, and it would always
be there.
Put this in the PostgreSQL SQL file ( postgres.initial.sql and
postgres.update.sql )
CREATE FUNCTION unix_timestamp () RETURNS double precision AS ' SELECT extract(epoch from date_trunc(''seconds'', current_timestamp)); ' LANGUAGE SQL;
Check your work by listing the defined functions that start with "unix"
[chasd@server3 trunk]$ psql roundcube Welcome to psql 7.4.11, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms \h for help with SQL commands ? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit
roundcube=# roundcube=# \df unix* List of functions Result data type | Schema | Name | Argument data types ------------------+--------+----------------+--------------------- double precision | public | unix_timestamp |
Use it
roundcube=# select unix_timestamp() as tz_db; tz_db
1202857954
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
On Feb 13, 2008 12:17 AM, chasd chasd@silveroaks.com wrote:
(...) roundcube=# roundcube=# \df unix* List of functions Result data type | Schema | Name | Argument data types ------------------+--------+----------------+--------------------- double precision | public | unix_timestamp |
Use it
roundcube=# select unix_timestamp() as tz_db; tz_db
1202857954
I am not a PostgreSQL administrator - but do you need special privs to add functions, or can every use do that?
We also made some additions to check.php-dist today, check it out from SVN.
Let me know, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I am not a PostgreSQL administrator - but do you need special privs to add functions, or can every use do that?
Any user that can create tables, etc. can create functions.
So the SQL file that creates the empty tables could also create the
function.
The pg_dump command ( like mysqldump ) will them also output the
commands to create the function, so a backup and restore maintains
that function for that database.
We also made some additions to check.php-dist today, check it out
from SVN.
rev 1073 ? I did a svn up to 1067 earlier and saw check.php-dist was updated.
I don't have as much time today as yesterday, but I will check it out.
I didn't see any changes to rcube_mbd2.inc in rev 1067 or 1073.
Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265
List info: http://lists.roundcube.net/dev/
On Feb 13, 2008 9:55 PM, chasd chasd@silveroaks.com wrote:
I am not a PostgreSQL administrator - but do you need special privs to add functions, or can every use do that?
Any user that can create tables, etc. can create functions. So the SQL file that creates the empty tables could also create the function. The pg_dump command ( like mysqldump ) will them also output the commands to create the function, so a backup and restore maintains that function for that database.
We also made some additions to check.php-dist today, check it out from SVN.
rev 1073 ? I did a svn up to 1067 earlier and saw check.php-dist was updated.
I don't have as much time today as yesterday, but I will check it out.
I didn't see any changes to rcube_mbd2.inc in rev 1067 or 1073.
There are none right now. I'll check into that later. I am currently busy with non-RoundCube work and on RC I am wrestling a multipart/annoyance issue. If you would stick your suggestions for rcube_mdb2 in a ticket, that would be most appreciated - and not forgotten. :-)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
-
chasd -
Dalibor Andzakovic -
till