Hello,
PHP 5.2.6 and earlier have a bugs that prevents us from appending text to php://stdout . See [PHP 45303].
We need to open php:// file descriptors in append mode (a) when running the web installer or we have a nice error caused by the output buffer being reset [BUG 31822] fixed by [r101644].
By bumping our PHP version requirement to 5.2.7 we no more have that buffer reset issue. Maintenance scripts will throw a warning though [BUG 32325] [BUG 32263].
Debian stable provides PHP 5.3.3. I am pretty sure Mac OS X 10.6 provide a PHP version after 5.2.6.
1.17 bumped requirement to PHP 5.2.3 Can we bump it again for 1.18 ?
References: [PHP 45303] https://bugs.php.net/bug.php?id=45303 [BUG 31822] https://bugzilla.wikimedia.org/show_bug.cgi?id=31822 [r101644] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/101644 [BUG 32325] https://bugzilla.wikimedia.org/show_bug.cgi?id=32325 [BUG 32263] https://bugzilla.wikimedia.org/show_bug.cgi?id=32263
I am little bit new to this but when you do that would it mean that mw wouldn't run on that or it would only show a warning to user that their php is older than required, which user could skip? if there was that possiblity, I see no problem with that. php is freeware so upgrade shouldn't be problem for anyone
On Thu, Nov 10, 2011 at 4:42 PM, Antoine Musso hashar+wmf@free.fr wrote:
Hello,
PHP 5.2.6 and earlier have a bugs that prevents us from appending text to php://stdout . See [PHP 45303].
We need to open php:// file descriptors in append mode (a) when running the web installer or we have a nice error caused by the output buffer being reset [BUG 31822] fixed by [r101644].
By bumping our PHP version requirement to 5.2.7 we no more have that buffer reset issue. Maintenance scripts will throw a warning though [BUG 32325] [BUG 32263].
Debian stable provides PHP 5.3.3. I am pretty sure Mac OS X 10.6 provide a PHP version after 5.2.6.
1.17 bumped requirement to PHP 5.2.3 Can we bump it again for 1.18 ?
References: [PHP 45303] https://bugs.php.net/bug.php?id=45303 [BUG 31822] https://bugzilla.wikimedia.org/show_bug.cgi?id=31822 [r101644] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/101644 [BUG 32325] https://bugzilla.wikimedia.org/show_bug.cgi?id=32325 [BUG 32263] https://bugzilla.wikimedia.org/show_bug.cgi?id=32263
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Nov 10, 2011 at 10:46 AM, Petr Bena benapetr@gmail.com wrote:
I am little bit new to this but when you do that would it mean that mw wouldn't run on that or it would only show a warning to user that their php is older than required, which user could skip? if there was that possiblity, I see no problem with that. php is freeware so upgrade shouldn't be problem for anyone
The installer will not install on versions below what we support. This is the behavior we have right now when checking for 5.2.3+
-Chad
I was assuming that warning wouldn't prevent user from being able to use mw on old php, as Chad explained, in case that it would be impossible to use it there, indeed it would be problem. I think that it should be possible to create some alternative way to install mediawiki for those users (since it affects only installation process). At least some light weight installer which would only update db schema and generated config file.
On Fri, Nov 11, 2011 at 6:18 AM, MZMcBride z@mzmcbride.com wrote:
Petr Bena wrote:
php is freeware so upgrade shouldn't be problem for anyone
Upgrading is a problem for a lot of people. Shared hosting is problematic in particular.
If there are unavoidable issues (5.3.1), it's a different story, of course.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
----- Original Message -----
From: "Antoine Musso" hashar+wmf@free.fr
Debian stable provides PHP 5.3.3. I am pretty sure Mac OS X 10.6 provide a PHP version after 5.2.6.
1.17 bumped requirement to PHP 5.2.3 Can we bump it again for 1.18 ?
Centos as late as 5.7 doesn't provide a 5.3 php; you have to get it from remi.
I *think* that might be true of Centos 6 as well, but I'm not sure.
Cheers, -- jra
On 10/11/11 16:48, Jay Ashworth wrote:
Centos as late as 5.7 doesn't provide a 5.3 php; you have to get it from remi.
I*think* that might be true of Centos 6 as well, but I'm not sure.
Looking at CentOS file mirrors, it looks like:
CentOS 5.7 provide PHP 5.3.3 with package name 'php53' CentOS 6.0 seems to provide 5.3.2 by default
So under CentOS 5.7 it should be something like: yum install php53
----- Original Message -----
From: "Antoine Musso" hashar+wmf@free.fr
On 10/11/11 16:48, Jay Ashworth wrote:
Centos as late as 5.7 doesn't provide a 5.3 php; you have to get it from remi.
I*think* that might be true of Centos 6 as well, but I'm not sure.
Looking at CentOS file mirrors, it looks like:
CentOS 5.7 provide PHP 5.3.3 with package name 'php53' CentOS 6.0 seems to provide 5.3.2 by default
So under CentOS 5.7 it should be something like: yum install php53
I either didn't see that, or there was a reason (incomplete dependencies) that I didn't use it; don't remember which, it's been a busy month.
Cheers, -- jra
Centos 6.1 uses PHP 5.2.x as default,
The same goes for cPanel, what kind of means that most users that want to use it on shared hosting would get that error also.
I don't think thats a good thing,
Best,
Huib
2011/11/10, Jay Ashworth jra@baylink.com:
----- Original Message -----
From: "Antoine Musso" hashar+wmf@free.fr
Debian stable provides PHP 5.3.3. I am pretty sure Mac OS X 10.6 provide a PHP version after 5.2.6.
1.17 bumped requirement to PHP 5.2.3 Can we bump it again for 1.18 ?
Centos as late as 5.7 doesn't provide a 5.3 php; you have to get it from remi.
I *think* that might be true of Centos 6 as well, but I'm not sure.
Cheers,
-- jra
Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
My Mac OS X 10.7.2 install provides PHP 5.3.6 as well.
-- Krinkle
On Thu, Nov 10, 2011 at 4:51 PM, IAlex ialex.wiki@gmail.com wrote:
Le 10 nov. 2011 à 16:42, Antoine Musso a écrit :
I am pretty sure Mac OS X 10.6 provide a PHP version after 5.2.6.
Antoine "hashar" Musso
Mac OS X 10.6.8 provides PHP 5.3.6.
Cheers! Alexandre Emsenhuber (ialex) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
right, if I understand this, the problem is only with installer, so wouldn't it be better just to make some workaround for older versions of php for installer rather than forcing user to upgrade, while it actually doesn't have effect on mediawiki which is already installed and working?
On Thu, Nov 10, 2011 at 4:42 PM, Antoine Musso hashar+wmf@free.fr wrote:
We need to open php:// file descriptors in append mode (a) when running the web installer or we have a nice error caused by the output buffer being reset [BUG 31822] fixed by [r101644].
By bumping our PHP version requirement to 5.2.7 we no more have that buffer reset issue. Maintenance scripts will throw a warning though [BUG 32325] [BUG 32263].
On Thu, Nov 10, 2011 at 10:55 AM, Petr Bena benapetr@gmail.com wrote:
right, if I understand this, the problem is only with installer, so wouldn't it be better just to make some workaround for older versions of php for installer rather than forcing user to upgrade, while it actually doesn't have effect on mediawiki which is already installed and working?
We wouldn't be forcing anyone to upgrade unless they're attempting a fresh MediaWiki installation and using < 5.2.7.
And TBH: if we wait for CentOS to support 5.3, we'll be looking at 5.2 support for another 5 or 6 years. But we're not bumping to 5.3 support anyway, this is just a minor jump from 5.2.3 -> .7
-Chad
Wanted to note that going from 1.16.5 to 1.17.0 on CentOS 5.1 (what my org is using, and they are testing 5.5) -- I had to install PHP from remi. Even 5.5 doesn't have good enough for 1.17. I also had to recompile the UTF8 support because of a missing option.
On Thu, Nov 10, 2011 at 10:59 AM, Chad innocentkiller@gmail.com wrote:
On Thu, Nov 10, 2011 at 10:55 AM, Petr Bena benapetr@gmail.com wrote:
right, if I understand this, the problem is only with installer, so wouldn't it be better just to make some workaround for older versions of php for installer rather than forcing user to upgrade, while it actually doesn't have effect on mediawiki which is already installed and working?
We wouldn't be forcing anyone to upgrade unless they're attempting a fresh MediaWiki installation and using < 5.2.7.
And TBH: if we wait for CentOS to support 5.3, we'll be looking at 5.2 support for another 5 or 6 years. But we're not bumping to 5.3 support anyway, this is just a minor jump from 5.2.3 -> .7
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Chad innocentkiller@gmail.com [Thu, 10 Nov 2011 10:59:49 -0500]:
On Thu, Nov 10, 2011 at 10:55 AM, Petr Bena benapetr@gmail.com
wrote:
right, if I understand this, the problem is only with installer, so wouldn't it be better just to make some workaround for older
versions
of
php for installer rather than forcing user to upgrade, while it
actually
doesn't have effect on mediawiki which is already installed and
working?
We wouldn't be forcing anyone to upgrade unless they're attempting a fresh MediaWiki installation and using < 5.2.7.
And TBH: if we wait for CentOS to support 5.3, we'll be looking at 5.2 support for another 5 or 6 years. But we're not bumping to 5.3 support anyway, this is just a minor jump from 5.2.3 -> .7
It is probably even more worth to encourage upgrade to PHP 5.4: I've seen the benchmarks and it seems to run about 1.5-2 times faster and have memory footprint 2-3 times lower comparing to 5.3. Perhaps Tim Starling's discussion with PHP core developers encouraged them to improve Zend. Maybe even HipHop is not that much needed as PHP 5.4. The question is, how to encourage conservative package maintainers to push such package updates into their distributions. Because not everyone has root and even not everyone who have root are ready to compile from sources. I've seen few articles, especially about Ubuntu, that compiling is discouraged! Which is very strange, I remember it was encouraged back in late 90's early 2000's. Dmitriy
Speaking as a tarball user: fer gosh sake please keep MediaWiki working on the oldest sane version of PHP. Even though I have root, it's a pain in the backside having to put a special package on a system to get new versions working. Particularly as MW is now back on a fast enough release schedule that upgrading is necessary to have a maintained version. Thank you.
- d.
sources. I've seen few articles, especially about Ubuntu, that compiling is discouraged! Which is very strange, I remember it was encouraged back in late 90's early 2000's. Dmitriy
Compiling is easy see http://www.mediawiki.org/wiki/Extension:OpenID#cite_note-compile-php-4 if you can add prerequisites if some are missing: ( The following configure works for all extensions I am using )
How to compile PHP (directory names are shown for a standard OpenSUSE server configuration)
1. get the latest PHP version 5.3.x from http://www.php.net 2. make a backup copy of your working php binaries /usr/bin/php and apache module /usr/lib64/apache2-prefork/libphp5.so or /usr/lib64/apache2-worker/libphp5.so . Assign a meaningful name so that you can easily return to your previous version in case that something went wrong during compilation of the new PHP- 3. /./configure --prefix=/usr --datadir=/usr/share/php --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-libdir=lib64 --with-config-file-path=/etc --with-exec-dir=/usr/lib64/php/bin --with-apxs2=/usr/sbin/apxs2-prefork --with-openssl --with-bz2 --with-zlib --with-curl --with-ldap --with-mysql --enable-soap --enable-mbstring --with-xsl --enable-calendar --with-gd --with-iconv --with-pspell --with-gmp --with-mcrypt --enable-zip/ 4. if /configure/ stops prematurely because of missing modules, you need to install missing developers' libraries with header files using YaST. This can be done, usually step-by-step, until /configure/ finishes successfully without missing dependencies. 5. /make/ 6. /make install/
On Tue, Nov 15, 2011 at 1:24 PM, Thomas Gries mail@tgries.de wrote:
Compiling is easy
It is, but I think the idea is that you don't get upgrades with a simple 'apt-get update && apt-get upgrade' (or equivalent) - You'll have to upgrade them yourself. Keep track of changelogs/new releases to check for security issues in all the packages you've installed by hand. Tedious, no?
On 15 November 2011 07:54, Thomas Gries mail@tgries.de wrote:
Compiling is easy see
Why yes, it is. However, requiring it for a piece of infrastructure is a pain in the backside above and beyond what other software working at a similar level requires.
I appreciate the urge to the new shiny and to leave the old stuff behind, but ask you not to go overboard. In general, any sentence that starts "But you can just ..." is probably wrong.
- d.
----- Original Message -----
From: "David Gerard" dgerard@gmail.com
I appreciate the urge to the new shiny and to leave the old stuff behind, but ask you not to go overboard. In general, any sentence that starts "But you can just ..." is probably wrong.
+5
On Tue, Nov 15, 2011 at 2:58 AM, David Gerard dgerard@gmail.com wrote:
I appreciate the urge to the new shiny and to leave the old stuff behind, but ask you not to go overboard. In general, any sentence that starts "But you can just ..." is probably wrong.
5.2.7 is hardly "new and shiny" :)
-Chad
On 15 November 2011 21:42, Chad innocentkiller@gmail.com wrote:
On Tue, Nov 15, 2011 at 2:58 AM, David Gerard dgerard@gmail.com wrote:
I appreciate the urge to the new shiny and to leave the old stuff behind, but ask you not to go overboard. In general, any sentence that starts "But you can just ..." is probably wrong.
5.2.7 is hardly "new and shiny" :)
I had to hit the IUS repositories to get MediaWiki onto CentOS 5 ... eventually I just compiled a libphp5.so myself. CentOS 5 may be old and crusty to you, but for me that phrase means "tried, tested and reasonably robust" - it's part of the infrastructure I put other bits of infrastructure like MediaWiki onto.
(At least the new boxes are up-to-the-minute distro Ubuntu 10.04 ...)
- d.
* Thomas Gries mail@tgries.de [Tue, 15 Nov 2011 08:54:38 +0100]:
sources.
I used RedHat for years, and compiling new versions of PHP was really easy because phpinfo() displayed ./configure options stored by php build for system administrator convience. One just had to watch for outdated / new options of configure. However, they (Ubuntu or Debian) built their own custom script which removes this ./configure line from phpinfo() output, so one have to find proper options manually. However it was easier than trying to build the package on my own, anyway. Dmitriy
On 15 November 2011 09:59, Dmitriy Sintsov questpc@rambler.ru wrote:
- Thomas Gries mail@tgries.de [Tue, 15 Nov 2011 08:54:38 +0100]:
sources.
I used RedHat for years, and compiling new versions of PHP was really easy because phpinfo() displayed ./configure options stored by php build for system administrator convience. One just had to watch for outdated / new options of configure. However, they (Ubuntu or Debian) built their own custom script which removes this ./configure line from phpinfo() output, so one have to find proper options manually. However it was easier than trying to build the package on my own, anyway.
I have hand-built libphp5.so just to get MediaWiki working properly on CentOS.
It's a pain in the backside. Please don't make us have to do this.
- d.
* David Gerard dgerard@gmail.com [Tue, 15 Nov 2011 10:14:55 +0000]:
On 15 November 2011 09:59, Dmitriy Sintsov questpc@rambler.ru wrote:
- Thomas Gries mail@tgries.de [Tue, 15 Nov 2011 08:54:38 +0100]:
sources.
I used RedHat for years, and compiling new versions of PHP was
really
easy because phpinfo() displayed ./configure options stored by php
build
for system administrator convience. One just had to watch for
outdated
/
new options of configure. However, they (Ubuntu or Debian) built
their
own custom script which removes this ./configure line from phpinfo() output, so one have to find proper options manually. However it was easier than trying to build the package on my own, anyway.
I have hand-built libphp5.so just to get MediaWiki working properly on CentOS.
It's a pain in the backside. Please don't make us have to do this.
I cannot, even if I wanted to. However, if PHP 5.4 is really so good, I am going to check it out, when I'll have more free time. Dmitriy
I used RedHat for years, and compiling new versions of PHP was really
easy because phpinfo() displayed ./configure options stored by php build
my next tip: on the commandline you can use
php -i
to print the ./configure options with which this current version was built. ./configure options are printed in the very first lines.
On 15 November 2011 19:18, Thomas Gries mail@tgries.de wrote:
my next tip: on the commandline you can use php -i to print the ./configure options with which this current version was built. ./configure options are printed in the very first lines.
And, of course, this doesn't actually say anything about how your libphp5.so was built ...
- d.
On Tue, Nov 15, 2011 at 2:29 PM, David Gerard dgerard@gmail.com wrote:
On 15 November 2011 19:18, Thomas Gries mail@tgries.de wrote:
my next tip: on the commandline you can use php -i to print the ./configure options with which this current version was built. ./configure options are printed in the very first lines.
And, of course, this doesn't actually say anything about how your libphp5.so was built ...
The whole discussion is moot anyway, I fixed it this morning. We will not be requiring 5.2.7.
-Chad
Am 15.11.2011 20:29, schrieb David Gerard:
On 15 November 2011 19:18, Thomas Gries mail@tgries.de wrote:
my next tip: on the commandline you can use php -i to print the ./configure options with which this current version was built. ./configure options are printed in the very first lines.
And, of course, this doesn't actually say anything about how your libphp5.so was built ...
oh yes , it does ! .... --with-apxs2=/usr/sbin/apxs2-prefork' ....
On 15 November 2011 19:32, Thomas Gries mail@tgries.de wrote:
Am 15.11.2011 20:29, schrieb David Gerard:
On 15 November 2011 19:18, Thomas Gries mail@tgries.de wrote:
my next tip: on the commandline you can use php -i to print the ./configure options with which this current version was built. ./configure options are printed in the very first lines.
And, of course, this doesn't actually say anything about how your libphp5.so was built ...
oh yes , it does ! .... --with-apxs2=/usr/sbin/apxs2-prefork' ....
If I hand you a libphp5.so binary, that's going to tell you nothing.
I see you have never been blessed with a system on which the php binary and the libphp5.so are completely unrelated ... it's an evil, evil world out there.
- d.
On Tue, Nov 15, 2011 at 2:50 PM, David Gerard dgerard@gmail.com wrote:
I see you have never been blessed with a system on which the php binary and the libphp5.so are completely unrelated ... it's an evil, evil world out there.
If anyone ever gave me such a system I don't think I could be friends with them anymore ;-)
-Chad
* Thomas Gries mail@tgries.de [Tue, 15 Nov 2011 20:18:10 +0100]:
I used RedHat for years, and compiling new versions of PHP was
really
easy because phpinfo() displayed ./configure options stored by php
build
my next tip: on the commandline you can use
php -i
to print the ./configure options with which this current version was built. ./configure options are printed in the very first lines.
I don't think that Ubuntu / Debian will display it there, because it's been stripped out from phpinfo() data by their custom build script. I don't use Ubuntu LTS anymore, only Fedora and CentOS, so I cannot check right now. Dmitriy
Dmitriy Sintsov questpc@rambler.ru writes:
However, they (Ubuntu or Debian) built their own custom script which removes this ./configure line from phpinfo() output, so one have to find proper options manually. However it was easier than trying to build the package on my own, anyway. Dmitriy
The whole idea of using packages is to outsource the job of maintenance of those packages. Sometimes you need to wrest control, though, and take over the outsourced job.
When that time comes with Debian packages, its good to understand how the build process works. If you want to build your own package, getting the configure args is pretty straight-forward.
$ apt-get source php5 $ cd php5*/debian $ less rules # look for the configure options
You can even modify the rules file (just a glorified makefile) to update the build to your needs and then build it:
$ sudo apt-get install devscripts $ sudo apt-get build-dep php5 $ cd .. # make sure you're above the debian dir $ debuild -uc -us -b $ dpkg -i ../php5*deb
That's all,
Mark.
* "Mark A. Hershberger" mhershberger@wikimedia.org [Tue, 15 Nov 2011 11:21:34 -0500]:
Dmitriy Sintsov questpc@rambler.ru writes:
However, they (Ubuntu or Debian) built their own custom script which removes this ./configure line from phpinfo() output, so one have to find proper options manually. However it was easier than trying to build the package on my own, anyway. Dmitriy
The whole idea of using packages is to outsource the job of
maintenance
of those packages. Sometimes you need to wrest control, though, and take over the outsourced job.
When that time comes with Debian packages, its good to understand how the build process works. If you want to build your own package, getting the configure args is pretty straight-forward.
$ apt-get source php5 $ cd php5*/debian $ less rules # look for the configure options
You can even modify the rules file (just a glorified makefile) to
update
the build to your needs and then build it:
$ sudo apt-get install devscripts $ sudo apt-get build-dep php5 $ cd .. # make sure you're above the debian dir $ debuild -uc -us -b $ dpkg -i ../php5*deb
That's all,
Mark.
Thanks, but I didn't just want to build the same version of PHP from source. I've apt-get source php5 and replaced their PHP source code with the version from newer tarball from php.net. Their script probably has some patches which weren't applying to newer version, so I gave up and just compiled from php.net tarball, fiddling with configure options.
Also, they have very weird default setup for apache vhosts: instead of placing them into one includable httpd-vhosts.conf, they make lots of small separate files one for each vhost and include the whole dir with * wildcard. That might have unpredictable results, because in such way it's hard to control the sequence of vhosts inclusion, and the order of vhosts is important. Dmitriy
Dmitriy Sintsov questpc@rambler.ru writes:
Thanks, but I didn't just want to build the same version of PHP from source.
Sure, so my overview will just get you started.
The patches that Debian installs are listed in the debian/patches directory. If you want to keep a patch out, you would remove it from debian/patches/series.
For example, the patch to remove the configure options is debian/patches/052-phpinfo_no_configure.patch, so to keep the configure options, you would remove the "052-phpinfo_no_configure.patch" line from debian/patches/series and re-run debuild.
To add patches, you should read up on quilt. I suggest this howto: http://pkg-perl.alioth.debian.org/howto/quilt.html
Also, they have very weird default setup for apache vhosts: instead of placing them into one includable httpd-vhosts.conf, they make lots of small separate files one for each vhost and include the whole dir with * wildcard. That might have unpredictable results, because in such way it's hard to control the sequence of vhosts inclusion, and the order of vhosts is important.
Why would your virtual hosts be load order dependent? Things that should be loaded before any virtual hosts should go into files in /etc/apache/conf.d.
If you really don't like the use of /etc/apache2/sites-enabled and /etc/apache/conf.d, then, of course you can use anything you like. You'll have more work when you upgrade apache, but how much of the upgrade work you want to outsource to Debian is your choice.
Mark.
On 18.11.2011 19:15, Mark A. Hershberger wrote:
Dmitriy Sintsovquestpc@rambler.ru writes:
Thanks, but I didn't just want to build the same version of PHP from source.
Sure, so my overview will just get you started.
The patches that Debian installs are listed in the debian/patches directory. If you want to keep a patch out, you would remove it from debian/patches/series.
For example, the patch to remove the configure options is debian/patches/052-phpinfo_no_configure.patch, so to keep the configure options, you would remove the "052-phpinfo_no_configure.patch" line from debian/patches/series and re-run debuild.
To add patches, you should read up on quilt. I suggest this howto: http://pkg-perl.alioth.debian.org/howto/quilt.html
Thanks, your advices are really valuable.
Also, they have very weird default setup for apache vhosts: instead of placing them into one includable httpd-vhosts.conf, they make lots of small separate files one for each vhost and include the whole dir with * wildcard. That might have unpredictable results, because in such way it's hard to control the sequence of vhosts inclusion, and the order of vhosts is important.
Why would your virtual hosts be load order dependent? Things that should be loaded before any virtual hosts should go into files in /etc/apache/conf.d.
If you really don't like the use of /etc/apache2/sites-enabled and /etc/apache/conf.d, then, of course you can use anything you like. You'll have more work when you upgrade apache, but how much of the upgrade work you want to outsource to Debian is your choice.
Virtual hosts are order dependent because I have the following VirtualHost match: ServerAlias *.domain for many sites (wikifarm) but for some selected sites I need to have another VirtualHost: ServerAlias host1.domain ServerAlias host2.domain before "global" *.domain will match. Dmitriy
Debian already solves this through a rename hack. For example the default virtualhost is named 000-default so that it gets loaded first. Similarly, I've had to rename module links so they are loaded before others (dav before svn). It's fairly straight forward and once you have a lot of modules or vhosts, you'd curse every time you opened a 5,000+ line conf file.
On Fri, Nov 18, 2011 at 11:57 AM, Dmitriy Sintsov questpc@rambler.ruwrote:
On 18.11.2011 19:15, Mark A. Hershberger wrote:
Dmitriy Sintsovquestpc@rambler.ru writes:
Thanks, but I didn't just want to build the same version of PHP from source.
Sure, so my overview will just get you started.
The patches that Debian installs are listed in the debian/patches directory. If you want to keep a patch out, you would remove it from debian/patches/series.
For example, the patch to remove the configure options is debian/patches/052-phpinfo_no_configure.patch, so to keep the configure options, you would remove the "052-phpinfo_no_configure.patch" line from debian/patches/series and re-run debuild.
To add patches, you should read up on quilt. I suggest this howto: http://pkg-perl.alioth.debian.org/howto/quilt.html
Thanks, your advices are really valuable.
Also, they have very weird default setup for apache vhosts: instead of placing them into one includable httpd-vhosts.conf, they make lots of small separate files one for each vhost and include the whole dir with * wildcard. That might have unpredictable results, because in such way it's hard to control the sequence of vhosts inclusion, and the order of vhosts is important.
Why would your virtual hosts be load order dependent? Things that should be loaded before any virtual hosts should go into files in /etc/apache/conf.d.
If you really don't like the use of /etc/apache2/sites-enabled and /etc/apache/conf.d, then, of course you can use anything you like. You'll have more work when you upgrade apache, but how much of the upgrade work you want to outsource to Debian is your choice.
Virtual hosts are order dependent because I have the following VirtualHost match: ServerAlias *.domain for many sites (wikifarm) but for some selected sites I need to have another VirtualHost: ServerAlias host1.domain ServerAlias host2.domain before "global" *.domain will match. Dmitriy
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 19.11.2011 2:15, Olivier Beaton wrote:
Debian already solves this through a rename hack. For example the default virtualhost is named 000-default so that it gets loaded first. Similarly, I've had to rename module links so they are loaded before others (dav before svn). It's fairly straight forward and once you have a lot of modules or vhosts, you'd curse every time you opened a 5,000+ line conf file.
I don't think that is a good solution. Because inserting / moving a vhost in-between requires a rename chain and multiple filename renames probably are not atomic. Can one make multiple renames in one kind of transaction (locking the dir, multirename, unlocking)? I don't have any troubles opening single 350 line conf file in vim (with syntax highlighting) and after copy / cut / paste, storing the "monolithic" vhosts.conf file is atomic (like transaction). Dmitriy
On 19 November 2011 12:27, Dmitriy Sintsov questpc@rambler.ru wrote:
On 19.11.2011 2:15, Olivier Beaton wrote:
Debian already solves this through a rename hack. For example the
default
virtualhost is named 000-default so that it gets loaded first. Similarly, I've had to rename module links so they are loaded before others (dav before svn). It's fairly straight forward and once you have
a
lot of modules or vhosts, you'd curse every time you opened a 5,000+ line conf file.
I don't think that is a good solution. Because inserting / moving a vhost in-between requires a rename chain and multiple filename renames probably are not atomic. Can one make multiple renames in one kind of transaction (locking the dir, multirename, unlocking)? I don't have any troubles opening single 350 line conf file in vim (with syntax highlighting) and after copy / cut / paste, storing the "monolithic" vhosts.conf file is atomic (like transaction). Dmitriy
No, you can always create a new filename that will sort between two others without needing to rename either of the other two. And you can always change *a* filename without altering the sort order of the collection. So if you have a "000-default" file and then a set of "100-foo" files that must load after default (but it doesn't matter how they load amongst themselves), then another set of "200-foo" files that must load after the 100- files, you can always choose a name ("050-", "100-", "150-", "200-" or "250-") that will cause it to load at the time you need, without having to rename any other files.
--HM
And it should be noted that all you rename in debian-apache are softlinks in the mods-enabled and sites-enabled directories. You would keep regular non-prefixed filenames in mods-available and sites-available. Using this method you could also allow some of your users to own the files themselves (although this is a security risk, you may want to install a panel if you have many users).
If you don't need to micromanage the load order of a module, debian provides some useful commands for enabling and disabling mods and sites.
a2enmod a2dismod, a2ensite a2dissite.
They merely take the name of the module / vhost in -available directories and it creates or removes the site without having to comment out large chunks of files. And by using these soft links you can keep the configuration for the vhost while still removing it, without having to move it or rename it. It's convenient.
From what I understand all this isn't great with puppet though, and many of
those users (like wmf) just flatten the whole thing into a single configuration file, which is your prerogative.
On Sat, Nov 19, 2011 at 9:15 AM, Happy Melon happy.melon.wiki@gmail.comwrote:
On 19 November 2011 12:27, Dmitriy Sintsov questpc@rambler.ru wrote:
On 19.11.2011 2:15, Olivier Beaton wrote:
Debian already solves this through a rename hack. For example the
default
virtualhost is named 000-default so that it gets loaded first. Similarly, I've had to rename module links so they are loaded before others (dav before svn). It's fairly straight forward and once you
have
a
lot of modules or vhosts, you'd curse every time you opened a 5,000+
line
conf file.
I don't think that is a good solution. Because inserting / moving a vhost in-between requires a rename chain and multiple filename renames probably are not atomic. Can one make multiple renames in one kind of transaction (locking the dir, multirename, unlocking)? I don't have any troubles opening single 350 line conf file in vim (with syntax highlighting) and after copy / cut / paste, storing the "monolithic" vhosts.conf file is atomic (like transaction). Dmitriy
No, you can always create a new filename that will sort between two others without needing to rename either of the other two. And you can always change *a* filename without altering the sort order of the collection. So if you have a "000-default" file and then a set of "100-foo" files that must load after default (but it doesn't matter how they load amongst themselves), then another set of "200-foo" files that must load after the 100- files, you can always choose a name ("050-", "100-", "150-", "200-" or "250-") that will cause it to load at the time you need, without having to rename any other files.
--HM _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 19.11.2011 20:23, Olivier Beaton wrote:
And it should be noted that all you rename in debian-apache are softlinks in the mods-enabled and sites-enabled directories. You would keep regular non-prefixed filenames in mods-available and sites-available. Using this method you could also allow some of your users to own the files themselves (although this is a security risk, you may want to install a panel if you have many users).
If you don't need to micromanage the load order of a module, debian provides some useful commands for enabling and disabling mods and sites.
a2enmod a2dismod, a2ensite a2dissite.
They merely take the name of the module / vhost in -available directories and it creates or removes the site without having to comment out large chunks of files. And by using these soft links you can keep the configuration for the vhost while still removing it, without having to move it or rename it. It's convenient.
From what I understand all this isn't great with puppet though, and many of
those users (like wmf) just flatten the whole thing into a single configuration file, which is your prerogative.
If one wants to have their virtual hosts in separate small files, there is much better setup than Debian / Ubuntu offers: 1. Create separate small virtual hosts files as usual. 2. Include them line by line in main httpd.conf file. 3. Change of virtual hosts order is a simple line cut / paste in httpd.conf file. Enabling / disabling one virtual host is just a # character in the start of the line. 4. No symlinks, no silly numeric prefixes. 5. The utility that manages these one line includes in httpd.conf can be developed as well. 6. Single httpd.conf file read/write is atomic. 7. There is no guarantee that every FS will list the filenames in dir in ascending literal order. Although modern do, of course. etc. Dmitriy
On 19 November 2011 18:25, Dmitriy Sintsov questpc@rambler.ru wrote:
On 19.11.2011 20:23, Olivier Beaton wrote:
And it should be noted that all you rename in debian-apache are softlinks in the mods-enabled and sites-enabled directories. You would keep
regular
non-prefixed filenames in mods-available and sites-available. Using this method you could also allow some of your users to own the files
themselves
(although this is a security risk, you may want to install a panel if you have many users).
If you don't need to micromanage the load order of a module, debian provides some useful commands for enabling and disabling mods and sites.
a2enmod a2dismod, a2ensite a2dissite.
They merely take the name of the module / vhost in -available directories and it creates or removes the site without having to comment out large chunks of files. And by using these soft links you can keep the configuration for the vhost while still removing it, without having to
move
it or rename it. It's convenient.
From what I understand all this isn't great with puppet though, and
many of
those users (like wmf) just flatten the whole thing into a single configuration file, which is your prerogative.
If one wants to have their virtual hosts in separate small files, there is much better setup than Debian / Ubuntu offers:
- Create separate small virtual hosts files as usual.
- Include them line by line in main httpd.conf file.
- Change of virtual hosts order is a simple line cut / paste in
httpd.conf file. Enabling / disabling one virtual host is just a # character in the start of the line. 4. No symlinks, no silly numeric prefixes. 5. The utility that manages these one line includes in httpd.conf can be developed as well. 6. Single httpd.conf file read/write is atomic. 7. There is no guarantee that every FS will list the filenames in dir in ascending literal order. Although modern do, of course. etc. Dmitriy
"Better" here is clearly in the eye of the beholder. The system you've just described is virtually semantically identical to the Debian/Ubuntu setup: you have a load of small vhost files, create a list of them sorted however you want, and get apache to load them all in order. Having the list as symlinks is easier and safer to script, as the corresponding OS filesystem functions are very well defined, but ordering the list is a little more difficult. If you put the list in httpd.conf as a list of includes you are dependent on having a safe and effective system for editing it via script, which is substantially harder to develop; but the ordering is a little more elegant.
Personally I'd say that the list-of-includes method was the "ugly option" "reminding me of ancient programming languages" and the symlink method was the "better setup", but there's no cast-iron reason why it should be so; it's basically a personal preference. It's the sort of distinction you'd discuss over a beer or ten, not one to discuss with the expectation of a meaningful outcome.
--HM
On 19.11.2011 22:59, Happy Melon wrote:
"Better" here is clearly in the eye of the beholder. The system you've just described is virtually semantically identical to the Debian/Ubuntu setup: you have a load of small vhost files, create a list of them sorted however you want, and get apache to load them all in order. Having the list as symlinks is easier and safer to script, as the corresponding OS filesystem functions are very well defined, but ordering the list is a little more difficult. If you put the list in httpd.conf as a list of includes you are dependent on having a safe and effective system for editing it via script, which is substantially harder to develop; but the ordering is a little more elegant.
Personally I'd say that the list-of-includes method was the "ugly option" "reminding me of ancient programming languages" and the symlink method was the "better setup", but there's no cast-iron reason why it should be so; it's basically a personal preference. It's the sort of distinction you'd discuss over a beer or ten, not one to discuss with the expectation of a meaningful outcome.
My method does not require creation of symlinks and numeric prefixes, that's why it's better. Ancient languages used numeric labels for lines of code. Cut / paste of single text line is faster than renaming symlinks. Commenting line with # is better as well. These points are objective, not subjective. I would stop talking about that yesterday if you weren't insisting that it's a personal preference (it's not). Dmitriy
On 19 November 2011 16:23, Olivier Beaton olivier.beaton@gmail.com wrote:
And it should be noted that all you rename in debian-apache are softlinks in the mods-enabled and sites-enabled directories. Â You would keep regular non-prefixed filenames in mods-available and sites-available. Using this method you could also allow some of your users to own the files themselves (although this is a security risk, you may want to install a panel if you have many users).
I was interested by the fact that Wikimedia, running a config for hundreds of largely identical Apaches on Ubuntu, *does not* in fact do things the Debian way, but loads the modules in an httpd.conf file just like every other Unix/Linux distro does it.
I'd always thought the Debian way was too ridiculously fiddly to scale efficiently. I'm sure there are ways to, but it's entirely unclear how doing it the Debian way is actually better for the job than doing it with a single simple config file.
The way we do it at work, with several almost-but-not-quite-identical Ubuntu servers, is directly inspired by the way Wikimedia do it: /etc/apache2/conf.d/ has 00-httpd.conf with our standard module config in it (identical for all), 01-vhost-default.conf with box-specific details, and a series of files with names matching vhost-*.conf for each virtual host. (And since mod_jk doesn't have a Debian/Ubuntu package, I rolled one myself that adds an 01-mod-jk.conf file in the same directory to load itself and configure JkMount, for the boxes that need that.)
- d.
On 19.11.2011 18:15, Happy Melon wrote:
No, you can always create a new filename that will sort between two others without needing to rename either of the other two. And you can always change *a* filename without altering the sort order of the collection. So if you have a "000-default" file and then a set of "100-foo" files that must load after default (but it doesn't matter how they load amongst themselves), then another set of "200-foo" files that must load after the 100- files, you can always choose a name ("050-", "100-", "150-", "200-" or "250-") that will cause it to load at the time you need, without having to rename any other files. --HM_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I don't like that way. It's not aesthetically beautiful. It reminds me of ancient programming languages of early 80's. That is absolutely unnecessary complication of virtual hosts editing, comparing to cut / copy / paste in single file, when I don't need any ugly numerical prefixes at all. Dmitriy
Antoine Musso wrote:
Hello,
PHP 5.2.6 and earlier have a bugs that prevents us from appending text to php://stdout . See [PHP 45303].
We need to open php:// file descriptors in append mode (a) when running the web installer or we have a nice error caused by the output buffer being reset [BUG 31822] fixed by [r101644].
By bumping our PHP version requirement to 5.2.7 we no more have that buffer reset issue. Maintenance scripts will throw a warning though [BUG 32325] [BUG 32263].
Given that it's just a warning (I see no mention of the returned handle being wrong), why not remove it with wfSupressErrors?
wikitech-l@lists.wikimedia.org