Hello folks
We proudly announce the first service release for the 0.9 series of Roundcube. As usual, it contains some bug fixes and improvements which didn't make it into the first stable version as well as some translation updates. After getting reports that some skin images weren't reloaded due to progressive cache settings, the packaged version now comes with unique urls of skin images referenced by templates and CSS files. If you're pulling the source directly from git you can achieve the same by running bin/updatecss.sh
It's considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from http://roundcube.net/download, see the full changelog here: http://trac.roundcube.net/wiki/Changelog
Have fun! Thomas
On 2013-05-18 02:47, Thomas Bruederli wrote:
Hello folks
We proudly announce the first service release for the 0.9 series of Roundcube. As usual, it contains some bug fixes and improvements which didn't make it into the first stable version as well as some translation updates. After getting reports that some skin images weren't reloaded due to progressive cache settings, the packaged version now comes with unique urls of skin images referenced by templates and CSS files. If you're pulling the source directly from git you can achieve the same by running bin/updatecss.sh
It's considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from http://roundcube.net/download [1], see the full changelog here: http://trac.roundcube.net/wiki/Changelog [2]
Have fun! Thomas _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev [3]
Way to go Thomas. I'm ready to install it. :)
Links:
[1] http://roundcube.net/download [2] http://trac.roundcube.net/wiki/Changelog [3] http://lists.roundcube.net/mailman/listinfo/dev
db.inc.php.dist still speaks about PEAR and has no word in context PDO means is worng and outdated ______________________________________
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
** give us a option to NOT touch any session setting ** ______________________________________
[20-May-2013 16:34:14 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772 [20-May-2013 16:34:17 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772 [20-May-2013 16:34:17 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772
Am 17.05.2013 20:47, schrieb Thomas Bruederli:
Hello folks
We proudly announce the first service release for the 0.9 series of Roundcube. As usual, it contains some bug fixes and improvements which didn't make it into the first stable version as well as some translation updates. After getting reports that some skin images weren't reloaded due to progressive cache settings, the packaged version now comes with unique urls of skin images referenced by templates and CSS files. If you're pulling the source directly from git you can achieve the same by running bin/updatecss.sh
It's considered stable and we recommend to update all productive installations of Roundcube with this version. Download it from http://roundcube.net/download, see the full changelog here: http://trac.roundcube.net/wiki/Changelog
On 05/20/2013 04:39 PM, Reindl Harald wrote:
db.inc.php.dist still speaks about PEAR and has no word in context PDO means is worng and outdated
DSN string we use is compatible with MDB2 format. I slightly modified description in db.inc.php file.
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
We use custom session handler for a reason and we'll not change that. I'd say it's PHP/MariaDB issue. The warning message is misleading, session.save_path setting is irrelevant in Roundcube.
Am 20.05.2013 21:03, schrieb A.L.E.C:
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
We use custom session handler for a reason and we'll not change that
and the reason is?
why does RC need a custom session handler if much more complex applications are not rely on such hacks
I'd say it's PHP/MariaDB issue
i would say since RC is the only application not running in this setup it is clearly a roundcube issue
The warning message is misleading, session.save_path setting is irrelevant in Roundcube
i know that but since RC does lot log anything else and the setup is running as all of my production servers with error_reporting E_ALL there is not much to debug
On 05/20/2013 09:18 PM, Reindl Harald wrote:
We use custom session handler for a reason and we'll not change that
and the reason is?
- security
- scalability
- we can store session in memcached too
- no session file locking (parallel requests do not wait)
Am 21.05.2013 08:59, schrieb A.L.E.C:
On 05/20/2013 09:18 PM, Reindl Harald wrote:
We use custom session handler for a reason and we'll not change that
and the reason is?
- security
seriously?
you think you know more about security than me and how do secure vhosts - forget it!
hint:
- sessiondata is never in open_basedir
- the application has no access to sessiondata (your concept has!)
- you can easily configure per vhsot-sessiondata
- scalability
this is a bad joke
my /var/www/sessiondata is a RAM disk since years my cleanups are outside PHP and relieable
the system would be much more scalable and is much more scalable with *not* using MySQL for storing sessions and RC is performance wise the weakest part of the whole infrastructure
(besides the fact that it does no longer work on F18/PHP5.4/MariaDB)
- we can store session in memcached too
so what
- no session file locking (parallel requests do not wait)
and no integrity and cleanups or how do you explain me the 5000 records in the session table on a server with a few users after some months?
On 05/21/2013 10:13 AM, Reindl Harald wrote:
- security
seriously?
Ok, this one was only for default PHP config. I'm not saying that PHP session is less secure in general.
you think you know more about security than me and how do secure vhosts - forget it!
No, I do not.
- scalability
this is a bad joke
but can you imagine two http servers using the same session (on another machine)? or one http server using two db servers?
- no session file locking (parallel requests do not wait)
and no integrity and cleanups or how do you explain me the 5000 records in the session table on a server with a few users after some months?
Roundcube uses PHP's session garbage collector. If you disabled it then it's your problem to clean old sessions. It of course might be a bug.
Am 21.05.2013 11:11, schrieb A.L.E.C:
Ok, this one was only for default PHP config. I'm not saying that PHP session is less secure in general.
and you take away any serious option from admins not using default php configs at all since decades because they know what they are doing
but can you imagine two http servers using the same session (on another machine)? or one http server using two db servers?
but you can imagine that such things are not the general usage and optimizing for this should be optional?
hence if a admin thinks he needs seperated session storage he would do something like below and for custom session-handlers and integration of memcache "auto_prepend_file" was invited
<Directory "/usr/share/roundcubemail"> php_admin_value session.gc_probability "1" php_admin_value session.gc_divisor "100" php_admin_value session.gc_maxlifetime "7200" php_admin_value session.save_path "/var/www/sessiondata-rc"
</Directory>
- no session file locking (parallel requests do not wait)
and no integrity and cleanups or how do you explain me the 5000 records in the session table on a server with a few users after some months?
Roundcube uses PHP's session garbage collector. If you disabled it then it's your problem to clean old sessions. It of course might be a bug
well, that happens if application developers choose to ignore the well thought configuration as default, hence that is why using a customized session handler should be *optional*
if you mangle session management outside the admins scope do it really including garbage collection or make the custom handler *optional* _______________________
this way a sane session configuration looks like for some hundret domains with webapps:
every 10 minutes: find /var/www/sessiondata -type f -mmin +30 -delete this happens in a cronjob and takes away the burden of session cleanup from the webserver and if you ever had 20000 session files you know why, this combined with /var/www/sessiondata as large enough tmpfs will outperform your mysql-sessionhandler by not produce any disk-IO for session management at all
this survives DDOS-attacks, been there, done that
[Session] session.save_path = "/var/www/sessiondata" session.save_handler = "files" session.use_cookies = 1 session.use_only_cookies = 1 session.name = "SESSION_ID" session.referer_check = "" session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = "/" session.cookie_domain = "" session.cookie_secure = 0 session.cookie_httponly = 1 session.serialize_handler = "php" session.gc_probability = 0 session.gc_divisor = 50000 session.gc_maxlifetime = 1800 session.entropy_file = "/dev/urandom" session.entropy_length = 32 session.cache_limiter = "nocache" session.cache_expire = 180 session.use_trans_sid = 0 session.bug_compat_42 = 0 session.bug_compat_warn = 0 session.hash_function = 1 session.hash_bits_per_character = 6 url_rewriter.tags = "disabled"
the system would be much more scalable and is much more scalable with *not* using MySQL for storing sessions and RC is performance wise the weakest part of the whole infrastructure
You probably have a different view of what it means to be scalable than the rest of the world. Scalable means you can add more servers to handle the load. Using a ramdisk is about the least scalable thing you can do. It's great for performance, not so great for scalability.
- no session file locking (parallel requests do not wait)
and no integrity and cleanups or how do you explain me the 5000 records in the session table on a server with a few users after some months?
I have no such issues. Our session table looks sane to me. My oldest session entries are 5 days old.
Cor
Am 21.05.2013 11:41, schrieb Cor Bosman:
the system would be much more scalable and is much more scalable with *not* using MySQL for storing sessions and RC is performance wise the weakest part of the whole infrastructure
You probably have a different view of what it means to be scalable than the rest of the world. Scalable means you can add more servers to handle the load. Using a ramdisk is about the least scalable thing you can do. It's great for performance, not so great for scalability.
what are all this discussions for?
having a customized session handler *mandatory* is dumb damned it *creates additional load* where zero load is by disk IO and by CPU cycles for php code
in the first front scaleable is how many users can i serve and with my setup i can serve much more than with a mysql session handler which prodcues IO loads
you do not need to care about my servers, the are running on a vSphere cluster and have anough ressources for the next years
- no session file locking (parallel requests do not wait)
and no integrity and cleanups or how do you explain me the 5000 records in the session table on a server with a few users after some months?
I have no such issues. Our session table looks sane to me. My oldest session entries are 5 days old
because you most likely have php default settings
RC is currently the only webapp not running sane with 100% customized environment because it does things which should not be done by the webapp and if somebody has to configure session-handlers it is the admin and nobody else PERIOD
On 05/21/2013 11:55 AM, Reindl Harald wrote:
in the first front scaleable is how many users can i serve and with my setup i can serve much more than with a mysql session handler which prodcues IO loads
Performance is not the only factor here. Did you do some tests, or you just think it's slower?
- no session file locking (parallel requests do not wait)
this one is really very important for Roundcube.
RC is currently the only webapp not running sane with 100% customized environment because it does things which should not be done by the webapp and if somebody has to configure session-handlers it is the admin and nobody else PERIOD
A webmail is a sophisticated app and it just doesn't work with every "100% customized environment" PERIOD
Am 21.05.2013 12:05, schrieb A.L.E.C:
On 05/21/2013 11:55 AM, Reindl Harald wrote:
in the first front scaleable is how many users can i serve and with my setup i can serve much more than with a mysql session handler which prodcues IO loads
Performance is not the only factor here. Did you do some tests, or you just think it's slower?
there is not much to test a disk-IO less tmpfs is faster than a MySQL DB
- no session file locking (parallel requests do not wait)
this one is really very important for Roundcube.
i doubt
RC is currently the only webapp not running sane with 100% customized environment because it does things which should not be done by the webapp and if somebody has to configure session-handlers it is the admin and nobody else PERIOD
A webmail is a sophisticated app and it just doesn't work with every "100% customized environment" PERIOD
if you change the session handler make sure that *all* params are set by the application and not only a subset and it would work
however - there is something going wrong and RC doe snot log anything useful and that RC also modifies the path to "error_log" log on machines with reporting-cronjobs for the global logfile and you have to watch it's log seperatly is also not fine
[20-May-2013 16:34:14 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772 [20-May-2013 16:34:17 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772 [20-May-2013 16:34:17 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772
in fact roundcube does not work with suhosin on PHP 5.4 (Suhosin v0.9.34-dev) while any other application here is running perfectly
BTW: what is this annoying missing plugin message from firefox on a Linux machine with no plugins enable for good reasons?
Am 21.05.2013 12:36, schrieb Reindl Harald:
Am 21.05.2013 12:05, schrieb A.L.E.C:
On 05/21/2013 11:55 AM, Reindl Harald wrote:
in the first front scaleable is how many users can i serve and with my setup i can serve much more than with a mysql session handler which prodcues IO loads
Performance is not the only factor here. Did you do some tests, or you just think it's slower?
there is not much to test a disk-IO less tmpfs is faster than a MySQL DB
- no session file locking (parallel requests do not wait)
this one is really very important for Roundcube.
i doubt
RC is currently the only webapp not running sane with 100% customized environment because it does things which should not be done by the webapp and if somebody has to configure session-handlers it is the admin and nobody else PERIOD
A webmail is a sophisticated app and it just doesn't work with every "100% customized environment" PERIOD
if you change the session handler make sure that *all* params are set by the application and not only a subset and it would work
however - there is something going wrong and RC doe snot log anything useful and that RC also modifies the path to "error_log" log on machines with reporting-cronjobs for the global logfile and you have to watch it's log seperatly is also not fine
[20-May-2013 16:34:14 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772 [20-May-2013 16:34:17 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772 [20-May-2013 16:34:17 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772
On 05/21/2013 12:51 PM, Reindl Harald wrote:
in fact roundcube does not work with suhosin on PHP 5.4 (Suhosin v0.9.34-dev) while any other application here is running perfectly
How about using stable suhosin releases?
Am 21.05.2013 13:01, schrieb A.L.E.C:
On 05/21/2013 12:51 PM, Reindl Harald wrote:
in fact roundcube does not work with suhosin on PHP 5.4 (Suhosin v0.9.34-dev) while any other application here is running perfectly
How about using stable suhosin releases?
give me one for PHP 5.4
as long as any other application like phpMyAdmin and any inhouse developed CMS and payment systems are working fine with Suhosin v0.9.34-dev i continue to blame RC
On 05/21/2013 01:07 PM, Reindl Harald wrote:
as long as any other application like phpMyAdmin and any inhouse developed CMS and payment systems are working fine with Suhosin v0.9.34-dev i continue to blame RC
It's only because they don't use broken-by-suhosin PHP functionality. See Jens-Martin's post.
On 2013-05-21 12:51, Reindl Harald wrote:
in fact roundcube does not work with suhosin on PHP 5.4 (Suhosin v0.9.34-dev) while any other application here is running perfectly
I think you should take a look at Suhosin instead of blaming RoundCube - as PHP 5.4 is not fully supported by Suhosin yet. This issue looks particularly interesting: https://github.com/stefanesser/suhosin/pull/26
/Jens-Martin
[ snipping other parts of the message, hoping that the vitriol can be scaled back a bit ]
On 05/21/2013 06:51 AM, Reindl Harald wrote:
BTW: what is this annoying missing plugin message from firefox on a Linux machine with no plugins enable for good reasons?
I want to make sure this issue doesn't get lost.
We are seeing something similar after upgrading to 0.9.1, and it seems to be related to:
.../program/resources/blank.pdf .../program/resources/blank.tif
here's a screenshot of the firefox header that comes up:
https://support.mayfirst.org/attachment/ticket/7300/devroundcubepdfnotice.pn...
Only some of our testers are seeing this behavior, though, with some versions of firefox.
is this related to http://trac.roundcube.net/ticket/1488972 perhaps?
--dkg
On 05/21/2013 12:36 PM, Reindl Harald wrote:
if you change the session handler make sure that *all* params are set by the application and not only a subset and it would work
We do set all relevant params, but maybe is there some important param that we miss.
however - there is something going wrong and RC doe snot log
indeed
anything useful and that RC also modifies the path to "error_log" log on machines with reporting-cronjobs for the global logfile and you have to watch it's log seperatly is also not fine
Some peaple would say it's an adventage. You can configure Roundcube to log to syslog, you can also set log_dir to any directory. If you disable debug_level it will not modify error_log param.
[20-May-2013 16:34:14 Europe/Vienna] PHP Warning: session_write_close() [<a href='http://at.php.net/manual/de/function.session-write-close.php'>function.session-write-close.php</a>]: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/www/sessiondata) in /usr/share/roundcubemail/program/include/rcmail.php on line 772
Putting the same message several times here will not fix the issue. Can you provide ssh access to such a box, so I could try to investigate?
Did you try to use different database engine (mysql, postgres, sqlite) with the same environment to make sure it's (or not) MariaDB-related issue? Maybe it's just PHP issue. Exactly which version of PHP 5.4 it is?
Am 21.05.2013 12:54, schrieb A.L.E.C:
anything useful and that RC also modifies the path to "error_log" log on machines with reporting-cronjobs for the global logfile and you have to watch it's log seperatly is also not fine
Some peaple would say it's an adventage. You can configure Roundcube to log to syslog, you can also set log_dir to any directory
you can do this with any application if you want / need please realize that it is a bad attitude to override admin settings on application level
if any random application would do this it leads to no longer have any predictable server setup
<Directory "/usr/share/roundcubemail"> php_value error_log "whatever_path"
</Directory>
<Directory "/usr/share/roundcubemail"> php_value error_log "syslog"
</Directory>
On 05/21/2013 12:59 PM, Reindl Harald wrote:
you can do this with any application if you want / need please realize that it is a bad attitude to override admin settings on application level
if any random application would do this it leads to no longer have any predictable server setup
<Directory "/usr/share/roundcubemail"> php_value error_log "whatever_path"
</Directory>
<Directory "/usr/share/roundcubemail"> php_value error_log "syslog"
</Directory>
There are environments where it's not possible to change PHP config this way.
Open a ticket for this. Maybe we could make so when log_dir/log_driver are not set we'll use current PHP settings.
On 05/21/2013 11:55 AM, Reindl Harald wrote:
having a customized session handler *mandatory* is dumb damned it *creates additional load* where zero load is by disk IO and by CPU cycles for php code
in the first front scaleable is how many users can i serve and with my setup i can serve much more than with a mysql session handler which prodcues IO loads
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
You say that you can serve "much more" users with your setup compared to a MySQL session handler. Can you give any indication about how "much more" users we are talking about? Do you have some test results? This discussion is getting nowhere without solid ground for such allegations.
The Roundcube dev's have made it clear why they chose to handle sessions through a database. Until now, your main complaints have been that your custom garbage collection system doesn't work for Roundcube (well, make it so then...), that it doesn't honor your PHP configuration settings and furthermore you argue that a MySQL session handler would cost a lot of performance (compared to traditional PHP session handlers), for which you haven't provided any evidence so far.
Please, do the rest of this list a favor and do provide some real evidence for the claims you raise or stop behaving like a troll. Thanks.
Geert
Am 21.05.2013 23:25, schrieb Geert Wirken:
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
and if someone wants to be taken serious in software development he implenents such things *additionally* for the few people who need it and *npt* mandatory for every setup
if it would be written really perfect it would not need a database at all and only autheticate against the IMAP server, fetch mails and in this mode simply hide the addressbook
The Roundcube dev's have made it clear why they chose to handle sessions through a database. Until now, your main complaints have been that your custom garbage collection system doesn't work for Roundcube (well, make it so then...)
you do not get it!
if every random application needs modifications and ignores global admin settings you would be unable to maintain large setups
that it doesn't honor your PHP configuration settings
which is crap
i maintain 600 domains on a server, they are all dynamic CMS systems and no single one is not confiugureable within Apache
and furthermore you argue that a MySQL session handler would cost a lot of performance (compared to traditional PHP session handlers), for which you haven't provided any evidence so far.
WTF - if you would have *little* expierience you would know that connecton to the database and queries are more expensive than touch a file on a tmpfs
Please, do the rest of this list a favor and do provide some real evidence for the claims you raise or stop behaving like a troll. Thanks
my real evidence is that it is *bullshit* to write software in a way that it is *mandatory* not controllable by Apache settings aka <Directory> because there is *no single need* and honestly it does not botehr me what sounds like a troll for you or not
most likely i have software written as you where running around a christmas tree
On 22/05/2013, at 9:37 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 21.05.2013 23:25, schrieb Geert Wirken:
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
and if someone wants to be taken serious in software development he implenents such things *additionally* for the few people who need it and *npt* mandatory for every setup
if it would be written really perfect it would not need a database at all and only autheticate against the IMAP server, fetch mails and in this mode simply hide the addressbook
If you really believe your setup is so much better than what 100s of other sysadmins are doing around the world, then good for you.
Roundcube just works for me and I use Postgresql, no modifications to any of our hosting environment needed.
If you have so much trouble with Roundcube, don't use it. Go find another product that better meets your requirements.
Am 22.05.2013 00:04, schrieb Glen Eustace:
On 22/05/2013, at 9:37 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 21.05.2013 23:25, schrieb Geert Wirken:
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
and if someone wants to be taken serious in software development he implenents such things *additionally* for the few people who need it and *npt* mandatory for every setup
if it would be written really perfect it would not need a database at all and only autheticate against the IMAP server, fetch mails and in this mode simply hide the addressbook
If you really believe your setup is so much better than what 100s of other sysadmins are doing around the world, then good for you.
it is
Roundcube just works for me and I use Postgresql, no modifications to any of our hosting environment needed
our environment turns in the first front around own development
If you have so much trouble with Roundcube, don't use it. Go find another product that better meets your requirements
stupid argumentation
give the session-handler beside 'db' and 'memcache' the option 'php' would be all i need to be satisfied and i *never* would expect from *any* webapp that this is not possible at all and usually the deafult
If you really believe your setup is so much better than what 100s of other sysadmins are doing around the world, then good for you.
it is
Well, it really isnt because it isnt linearly scalable. So maybe for your specific setup it works, but you're in a zone of users thats probably kind of small. The bulk is the group that just wants RC to work out of the box. DB sessions provide that hassle free because you already need the DB. Another large group is the one of companies or ISPs or whatever that have multiple servers running, for redundancy and scalability. The group of admins that want 1 single server, running tmp filesystems on that for sessions, is probably really really small.
// Backend to use for session storage. Can either be 'db', 'memcache' or 'php' $rcmail_config['session_storage'] = 'php';
Roundcube is an open source project. You can always provide a patch for this and submit a pull request. I can see some situations in which a php session setup could be useful. Not many though. Probably not enough to bother coding for it. But if you do, maybe they'll add it.
Cor
Am 22.05.2013 00:29, schrieb Cor Bosman:
If you really believe your setup is so much better than what 100s of other sysadmins are doing around the world, then good for you.
it is
Well, it really isnt because it isnt linearly scalable
you know *nothing* about my infrastructure you know *nothing* about my load-balancers you know *nothing* about the vSpehre cluster you know *nothing* about *real* load
hint: a webmail is not the piece of software with real load come back to this sort of discussion after your servers survived a large DDOS on a CMS site while the router in front died phyiscally and after you managed to run 600 domains on a vSphere guests with some of them having millions of requests each day with around 2% CPU load and VMware DRS not in action but waiting
On Wed, May 22, 2013 at 12:45:11AM +0200, Reindl Harald wrote:
you know *nothing* about *real* load
Claiming that Cor doesn't know anything about real load is just stupid.
Take your crazy somewhere else.
Am 22.05.2013 00:29, schrieb Cor Bosman:
If you really believe your setup is so much better than what 100s of other sysadmins are doing around the world, then good for you.
it is
Well, it really isnt because it isnt linearly scalable
you know *nothing* about my infrastructure you know *nothing* about my load-balancers you know *nothing* about the vSpehre cluster
These are definitely true. All I know is that it's VMware :) But im interested. What do you do in that infrastructure when your roundcube load exceeds the capabilities of your vmware host server? Do you buy a larger vmware host server? We have 60.000 simultaneous webmail users in peak, so these questions always interest me. In our experience it's much cheaper to scale horizontally instead of vertically.
you know *nothing* about *real* load
Well, maybe a little. Not as much as you obviously.
Anyways, we digress. You want specific functionality that isnt really in the interest of most of the roundcube community. That's ok, we have that often as well. There is two ways to go about that. Either you ask nicely and hope someone wants to help you, or you code it yourself and send a pull request through git. I think your best bet at this point in the discussion is the latter.
Regards,
ps: we colocated spamhaus amongst others, so we know just a wee bit about ddos.
Am 22.05.2013 10:17, schrieb Cor Bosman:
Am 22.05.2013 00:29, schrieb Cor Bosman:
If you really believe your setup is so much better than what 100s of other sysadmins are doing around the world, then good for you.
it is
Well, it really isnt because it isnt linearly scalable
you know *nothing* about my infrastructure you know *nothing* about my load-balancers you know *nothing* about the vSpehre cluster
These are definitely true. All I know is that it's VMware :) But im interested. What do you do in that infrastructure when your roundcube load exceeds the capabilities of your vmware host server? Do you buy a larger vmware host server?
it does not happen because webmail is not a core-business here and *if it would* be relevant the shared session thing *would be* interesting but that is *not* a good reason to have it *default*
it is a bad practice to have defaults for load-balancing if it is not used
you know *nothing* about my infrastructure you know *nothing* about my load-balancers you know *nothing* about the vSpehre cluster
These are definitely true. All I know is that it's VMware :) But im interested. What do you do in that infrastructure when your roundcube load exceeds the capabilities of your vmware host server? Do you buy a larger vmware host server?
it does not happen because webmail is not a core-business here and *if it would* be relevant the shared session thing *would be* interesting but that is *not* a good reason to have it *default*
Thank you for clarifying, it all makes sense now.
The reason for this to be default is not because of shared sessions. It's because you need a database anyways, so having database sessions is basically 'free', and thus by far the easiest for almost all smaller roundcube installations. The roundcube code takes care of it all, and you dont have to worry about it. It just so happens that for larger installations where shared sessions are relevant this turns out to be useful as well.
The downside to that is that some installations, like yours, dont quite fit. You cant win them all. So, either code it or hire a coder and get it sorted if you really want this to work.
Cor
On 21-05-13 23:37, Reindl Harald wrote:
and if someone wants to be taken serious in software development he implenents such things *additionally* for the few people who need it and *npt* mandatory for every setup
The default is good for most people. For small setups, it extra load of having a DB session handler doesn't really matter, and for large setups, you probably want the DB session handler because you would like to share session information amongst all your webserver nodes. That's quite a reasonable default. Go ahead and modify RC if you would like to use an alternative session handler, but most admins won't be interested in using it.
if every random application needs modifications and ignores global admin settings you would be unable to maintain large setups
It does honor your settings, but RC simply does not use all built-in functionality of PHP...
i maintain 600 domains on a server, they are all dynamic CMS systems and no single one is not confiugureable within Apache
Fine.
and furthermore you argue that a MySQL session handler would cost a lot of performance (compared to traditional PHP session handlers), for which you haven't provided any evidence so far.
WTF - if you would have *little* expierience you would know that connecton to the database and queries are more expensive than touch a file on a tmpfs
I do have some experience and I reckon that DB queries are probably more expensive. But the question is how much more expensive the RC approach is compared to native session handling. Why don't you run some tests? It is quite a difference whether the performance loss is ~1% or ~50%.
most likely i have software written as you where running around a christmas tree
Which is not really relevant in this discussion.
Geert
PS: Your discussion style seems very rude to me, did you know that?
On 05/22/2013 02:41 AM, Geert Wirken wrote:
The default is good for most people. For small setups, it extra load of having a DB session handler doesn't really matter, and for large setups, you probably want the DB session handler because you would like to share session information amongst all your webserver nodes. That's quite a reasonable default. Go ahead and modify RC if you would like to use an alternative session handler, but most admins won't be interested in using it.
One of the common costs of using a db is the additional disk I/O. If you're using MySQL, you could set the sessions table to use ENGINE=MEMORY:
https://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html
Or if you're using Postgres, you could use an UNLOGGED table:
http://www.postgresql.org/docs/9.1/static/sql-createtable.html#AEN67496
Both of these approaches should significantly reduce the I/O overhead for the sessions table (though at the cost of losing sessions in the event of a power failure or other unclean shutdown), while keeping the same sessions table trivially visible for all connecting web frontends, since they already all have access to the database.
Regards,
--dkg
Hi Reindl
We're running a clustered installation of Roundcube for well over 300,000 users and database load has never been an issue for us - so it seems unlikely to me that sessions are the cause of the problem. Do you have message caching enabled by any chance? If so, I strongly suggest you disable it.
The main performance problem we experienced in the past was due to the very inefficient way Roundcube's include path is configured, which we suggested a solution to in this ticket: http://trac.roundcube.net/ticket/1487849
We've now moved to storing Roundcube on the local filesystem of each server (but kept the include path fixes) and performance is excellent. We also use imap proxy on each web node.
Personally, I would be in favour of a more flexible sessions manager, but since I have no need for it I won't be writing it. The great thing about open source software is you can contribute the functionality you need, which is what I suggest you do.
Regards
Marcus
On 21 May 2013, at 22:37, Reindl Harald h.reindl@thelounge.net wrote:
Am 21.05.2013 23:25, schrieb Geert Wirken:
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
and if someone wants to be taken serious in software development he implenents such things *additionally* for the few people who need it and *npt* mandatory for every setup
if it would be written really perfect it would not need a database at all and only autheticate against the IMAP server, fetch mails and in this mode simply hide the addressbook
The Roundcube dev's have made it clear why they chose to handle sessions through a database. Until now, your main complaints have been that your custom garbage collection system doesn't work for Roundcube (well, make it so then...)
you do not get it!
if every random application needs modifications and ignores global admin settings you would be unable to maintain large setups
that it doesn't honor your PHP configuration settings
which is crap
i maintain 600 domains on a server, they are all dynamic CMS systems and no single one is not confiugureable within Apache
and furthermore you argue that a MySQL session handler would cost a lot of performance (compared to traditional PHP session handlers), for which you haven't provided any evidence so far.
WTF - if you would have *little* expierience you would know that connecton to the database and queries are more expensive than touch a file on a tmpfs
Please, do the rest of this list a favor and do provide some real evidence for the claims you raise or stop behaving like a troll. Thanks
my real evidence is that it is *bullshit* to write software in a way that it is *mandatory* not controllable by Apache settings aka <Directory> because there is *no single need* and honestly it does not botehr me what sounds like a troll for you or not
most likely i have software written as you where running around a christmas tree
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Am 22.05.2013 11:46, schrieb Marcus Don:
We're running a clustered installation of Roundcube for well over 300,000 users and database load has never been an issue for us - so it seems unlikely to me that sessions are the cause of the problem. Do you have message caching enabled by any chance? If so, I strongly suggest you disable it
you still do not get it
the argumentation was "sessions in the db are much faster" where did i say that i have a performance problem? i only said *they are not faster* in small environments they are useless overhead they are making things much more complex they are making problems you otherwise not have (Suhosin currently) ___________________
in my job i optimize any piece of software
and that is why i drive 600 CMS domains on a host with a average generate time of 0.007 seconds for a page from load index.php until the complete page is ready and have a CPU load of 2%
guess why this values are possible: because *ANY* overhead is eliminated and except RC and phpMyAdmin there is no 3rd party software involved and *any* server relevant binary is maintained in own repos and optimized for the CPU
where did i say that i have a performance problem?
I just assumed that was the reason you felt so strongly about it.
For what it's worth, I agree that the sessions management could be improved, but it makes no sense to alienate the very people who could help.
On 22 May 2013, at 10:56, Harald h.reindl@thelounge.net wrote:
Am 22.05.2013 11:46, schrieb Marcus Don:
We're running a clustered installation of Roundcube for well over 300,000 users and database load has never been an issue for us - so it seems unlikely to me that sessions are the cause of the problem. Do you have message caching enabled by any chance? If so, I strongly suggest you disable it
you still do not get it
the argumentation was "sessions in the db are much faster" where did i say that i have a performance problem? i only said *they are not faster* in small environments they are useless overhead they are making things much more complex they are making problems you otherwise not have (Suhosin currently) ___________________
in my job i optimize any piece of software
and that is why i drive 600 CMS domains on a host with a average generate time of 0.007 seconds for a page from load index.php until the complete page is ready and have a CPU load of 2%
guess why this values are possible: because *ANY* overhead is eliminated and except RC and phpMyAdmin there is no 3rd party software involved and *any* server relevant binary is maintained in own repos and optimized for the CPU
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Am 22.05.2013 12:19, schrieb Marcus Don:
where did i say that i have a performance problem?
I just assumed that was the reason you felt so strongly about it
you do not need to assume anything you simply need to follow the thread
i feel so strongly about it because it fucks up since 4 months on machines where any other web-app is running without the smallest issue which is only caused by custom session handlers
the called reasons where security and scalability which is *wrong* on most setups, in case of security the opposite is true, a sane setup does *not allow* a script running in the context of user A access session-data of user B which is true with the php-handler and open_basedir but *completly wrong* in case of session data in the database shared by all users
and the performance part is also *not* true or irrelevant for most setups and scalability should never be solved on the application layer, only few need shared sessions over different servers and they who need should know how to achieve this or at least it has not to be deafult for all setups
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Tue, 21 May 2013 08:59:05 +0200 Von: A.L.E.C alec@alec.pl An: dev@lists.roundcube.net
On 05/20/2013 09:18 PM, Reindl Harald wrote:
We use custom session handler for a reason and we'll not change that
and the reason is?
- security
- scalability
- we can store session in memcached too
- no session file locking (parallel requests do not wait)
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Mon, 20 May 2013 16:39:51 +0200 Von: Reindl Harald h.reindl@thelounge.net
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
** give us a option to NOT touch any session setting **
Ich folge nun deiner Diskussion seit Tagen. Eines sei aber von Landsmann zu Landsmann erlaubt:
Dein Stil ist unter aller SAU.
DONT'T blame others. CODE a better solution an PROVIDE patches.
where did i say that i have a performance problem?
I just assumed that was the reason you felt so strongly about it
you do not need to assume anything you simply need to follow the thread
i feel so strongly about it because it fucks up since 4 months on machines where any other web-app is running without the smallest issue which is only caused by custom session handlers
the called reasons where security and scalability which is *wrong* on most setups, in case of security the opposite is true, a sane setup does *not allow* a script running in the context of user A access session-data of user B which is true with the php-handler and open_basedir but *completly wrong* in case of session data in the database shared by all users
and the performance part is also *not* true or irrelevant for most setups and scalability should never be solved on the application layer, only few need shared sessions over different servers and they who need should know how to achieve this or at least it has not to be deafult for all setups
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Tue, 21 May 2013 08:59:05 +0200 Von: A.L.E.C alec@alec.pl An: dev@lists.roundcube.net
On 05/20/2013 09:18 PM, Reindl Harald wrote:
We use custom session handler for a reason and we'll not change that
and the reason is?
- security
- scalability
- we can store session in memcached too
- no session file locking (parallel requests do not wait)
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Mon, 20 May 2013 16:39:51 +0200 Von: Reindl Harald h.reindl@thelounge.net
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
** give us a option to NOT touch any session setting **
Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
Easy going, guys!
I agree that session handling could be nicer in RoundCube — or maybe not at all. ;-) If we wouldn't have customized session handling code we could let people configure PHP directly to use the filesystem, memcache or database. I think the least we could (or should) do is use an external library for session handling because that doesn't seem our domain (which is an email client).
Not sure if we could use something from Symfony2 or ZF2. They each provide wrappers — PHP 5.3, et all. Are people ready to move/upgrade yet?
Till
On Wednesday, May 22, 2013 at 8:38 PM, Rosali wrote:
Ich folge nun deiner Diskussion seit Tagen. Eines sei aber von Landsmann
zu Landsmann erlaubt:Dein Stil ist unter aller SAU.
DONT'T blame others. CODE a better solution an PROVIDE patches.
where did i say that i have a performance problem?
I just assumed that was the reason you felt so strongly about it
you do not need to assume anything you simply need to follow the thread
i feel so strongly about it because it fucks up since 4 months on machines where any other web-app is running without the smallest issue which is only caused by custom session handlers
the called reasons where security and scalability which is *wrong* on most setups, in case of security the opposite is true, a sane setup does *not allow* a script running in the context of user A access session-data of user B which is true with the php-handler and open_basedir but *completly wrong* in case of session data in the database shared by all users
and the performance part is also *not* true or irrelevant for most setups and scalability should never be solved on the application layer, only few need shared sessions over different servers and they who need should know how to achieve this or at least it has not to be deafult for all setups
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Tue, 21 May 2013 08:59:05 +0200 Von: A.L.E.C <alec@alec.pl (mailto:alec@alec.pl)> An: dev@lists.roundcube.net (mailto:dev@lists.roundcube.net)
On 05/20/2013 09:18 PM, Reindl Harald wrote:
We use custom session handler for a reason and we'll not change that
and the reason is?
- security
- scalability
- we can store session in memcached too
- no session file locking (parallel requests do not wait)
-------- Original-Nachricht -------- Betreff: Re: [RCD] Update 0.9.1 released Datum: Mon, 20 May 2013 16:39:51 +0200 Von: Reindl Harald <h.reindl@thelounge.net (mailto:h.reindl@thelounge.net)>
and when will sessions continue to work on machines with Apache 2.4 / PHP 5.4 / MariaDB while the error messages below make ZERO sense because RC refuses to work with a untouched session management like every other webapp
would RC use simply session_start() and not fuckup the admin settings it *would* in fact use /var/www/sessiondata and it would it use *with success*
** give us a option to NOT touch any session setting **
Roundcube Development discussion mailing list dev@lists.roundcube.net (mailto:dev@lists.roundcube.net) http://lists.roundcube.net/mailman/listinfo/dev
Roundcube Development discussion mailing list dev@lists.roundcube.net (mailto:dev@lists.roundcube.net) http://lists.roundcube.net/mailman/listinfo/dev
On Tue, May 21, 2013 at 11:25:47PM +0200, Geert Wirken wrote:
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
Which, I'd just like to say is AWESOME. Thanks for having this solved for us out of the box so we didn't have write it ourselves or rely on sharing the sessions over NFS. I find it refreshing that an open source project has this in place out of the box.
Am 21.05.2013 23:55, schrieb Kelsey Cummings:
On Tue, May 21, 2013 at 11:25:47PM +0200, Geert Wirken wrote:
I guess what Cor means here is that you can add multiple webservers to your cluster which all share the same session information (because it would be stored in MySQL and not on a local ramdisk on each separate server).
Which, I'd just like to say is AWESOME. Thanks for having this solved for us out of the box so we didn't have write it ourselves or rely on sharing the sessions over NFS. I find it refreshing that an open source project has this in place out of the box
yes, but it would be *trivial* to provide a config setting to switch it off where it is not needed and not touch the php-session managment at all
this way it would be even more powerful
- memcache out of the box supported
- *any* other implementation by a customized session handler hooked in with "auto_prepend_file" without RC need to know anything about it
- KISS principle for setups which does not need any of them
hence that is why a sane option would work like below and with setting 'php' not touch anything the admin configured in "php.ini" or per-directory settings in httpd
// Backend to use for session storage. Can either be 'db', 'memcache' or 'php' $rcmail_config['session_storage'] = 'php';
Am 21.05.2013 11:41, schrieb Cor Bosman:
the system would be much more scalable and is much more scalable with *not* using MySQL for storing sessions and RC is performance wise the weakest part of the whole infrastructure
You probably have a different view of what it means to be scalable than the rest of the world Scalable means you can add more servers to handle the load
you must live in your own world
scalability means it can handle a growing load, this *may be* done by spread the load over more servers
good and really scalable software scales also by add hardware like memory or CPU's to the same machine and in this context doing disk IO instead use a tmpfs for sessions is exactly the opposite you would want
well, finally the db-sessions become your bottleneck by mysql deadlocks if you have too much users resulting in *a lot* of concurrency on the same, shared table
been there, done that, what you *not* want is a growing amount of writing queries on a database under real load
-
A.L.E.C -
Cor Bosman -
Daniel Kahn Gillmor -
Geert Wirken -
Glen Eustace -
Jens-Martin Groenne -
Kelsey Cummings -
Marcus Don -
Muhammad Zamri Bin Muhamad Suharini -
Reindl Harald -
Rosali -
Thomas Bruederli -
till