Forums / Install & configuration / Installing eZ Publish On An Ubuntu 7.10 Server

Installing eZ Publish On An Ubuntu 7.10 Server

Next topic

Author	Message
Petter Neumann	Thursday 07 February 2008 1:34:14 pm A tutorial about installing Ezpublish 4.0 on Ubuntu 7.10 server has been published on howtoforge.com http://howtoforge.com/installing-ez-publish-on-ubuntu-7.10
Łukasz Serwatka	Friday 08 February 2008 12:58:55 am Hi Petter, Thanks for sharing this ;) Personal website -> http://serwatka.net Blog (about eZ Publish) -> http://serwatka.net/blog
Gaetano Giunta	Friday 08 February 2008 1:18:32 am Good tutorial. I think it needs to add a check in php.ini for session.gc_probability > 0. Debian has set it to zero, and ezP will never clear up expired sessions. Not sure about Ubuntu, but since it's debian based... PS: do you really have to pay to post comments on howto-forge ??? Principal Consultant International Business Member of the Community Project Board
Petter Neumann	Friday 08 February 2008 1:36:34 am You can create an account for posting comments on http://www.howtoforge.com/forums/ / Petter
Petter Neumann	Friday 08 February 2008 10:38:43 am Due to the strict permissions ; on /var/lib/php5 in ubuntu, ;session.gc_probability is disabled in php.ini Ubuntu uses in /etc/cron.d/php5 # /etc/cron.d/php5: crontab fragment for php5 # This purges session files older than X, where X is defined in seconds # as the largest value of session.gc_maxlifetime from all your php.ini # files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime # Look for and purge old sessions every 30 minutes 09,39 * * * * root [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \| xargs -r -0 rm / Petter
Gaetano Giunta	Friday 08 February 2008 1:57:30 pm <i>Due to the strict permissions ; on /var/lib/php5 in ubuntu, ;session.gc_probability is disabled in php.ini</i> Sure enough, but eZP sessions are stored in the database, not in the filesystem. So no need to touch /var/lib/php5. Unless, of course, you are running other applications on the same php install Principal Consultant International Business Member of the Community Project Board
Piotrek Karaś	Friday 08 February 2008 10:30:09 pm <i>> but eZP sessions are stored in the database</i> Slightly off topic, but I have already heard from at least two hosting providers that I should move my session storage from db to files (they claimed that was one of the reasons for poor performance). How would you comment on that? As to the tutorial, it verifies and updates what I had done for some time, especially when it comes to PHP with all those options. However, I believe it would be even better if there was a page describing performance tuning of the server ingredients. For example accelerator installation and configuration, DB tunning etc. Thanks, Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Gaetano Giunta	Saturday 09 February 2008 6:12:29 am <i>I have already heard from at least two hosting providers that I should move my session storage from db to files (they claimed that was one of the reasons for poor performance). How would you comment on that?</i> I don't have a silver bullet. But quite a few hosting providers would tell you that setting up session storage in the filesystem is prone to security problems (that's the reason why the debian guys, security minded, set up permissions that only allow a root cronjob to.delete them, instead of having php garbage-collect them). Putting sessions in the database is good if you: - have multiple front-end servers. Otherwise you risk the client not finding his session when going to page 2 (other solution, of course, is to put session files on shared storage, but if you do nfs in sw via a plain linux box your performance is going to be orders of magnitude worse than using the db, due to poor locking implementation. You should really get a solid nas/san solution then. Or you need no shared storage but a level 7 load balancer in front of your servers using session stickiness, and accept the fact that if one of the servers fails the users that where passing through it would loose their sessions by being rerouted through the other) - have a db that is not overloaded and can accommodate the requests to handle sessions, in terms of space and cpu - have other php apps running beside yours, and want to keep tight separation Putting sessions in the fs is good if you: - have good control over filesystem, process and user permissions - have an overloaded db Principal Consultant International Business Member of the Community Project Board
Piotrek Karaś	Sunday 10 February 2008 8:03:39 am Hello Gaetano, Thanks for handful of useful arguments! It all makes me believe that the argument with the provider had to be a lost (win) case because otherwise they would have to admit to having their DB overloaded, just as you illustrate. I haven't yet had a chance to manage a larger eZ deployment (like in multiple servers), but your answer also puts answers to some potential client questions into my repertoire, so double thanks! Piotrek -- Company: mediaSELF Sp. z o.o., http://www.mediaself.pl eZ references: http://ez.no/partners/worldwide_partners/mediaself eZ certified developer: http://ez.no/certification/verify/272585 eZ blog: http://ez.ryba.eu
Gaetano Giunta	Monday 11 February 2008 1:27:33 am <i>the argument with the provider had to be a lost (win) case</i> sysadmin always wins, anyway - http://members.iinet.com.au/~bofh/index.html cheers Gaetano Principal Consultant International Business Member of the Community Project Board