Entries by admin

Hi all!
This blog post should be my first to also be syndicated on blog.syscp.org, one of the new resources we SysCP devs will use to better bring news and informations to you, the user.
First, let me again thank Martin Burchert aka eremit for all the work he's done over the years and the big help and guidance he has provided to all of us, and the really fantastic work done on SysCP 1.3! Thanks Martin!
Second, as EleRas said on his previous post, we're working on SysCP 1.3, largely following the proposals of SysCP EP01. We've already implemented most of the backend changes:

• Modules versioning [CHTEKK]


• Modules dependencies (with &&, || and < =>version support, and reverse-deps) [CHTEKK]


• Modules on/off (and core modules which can't be turned off) [CHTEKK]


• Plugins (modules can plugin frontend parts into eachother basically, extending themselves) [CHTEKK]


• Validation Handler (class to validate and check user input) [EleRas]


• XML-RPC Handler (class to work with a remote XML-RPC server) [CHTEKK]

Also on the frontend side we're going pretty well:

• Modulesmanager done [EleRas]


• Languageeditor done [EleRas]


• Option to change the theme added [CHTEKK]

Also a lot of bugfixes were added, as well as the theme by me and Luca Piona (which is also default in 1.2.14 now, yay!), thanks to EleRas for porting that to the SysCP 1.3 structure!
We also should now be E_ALL and E_STRICT compliant on PHP 5.1.6 at least (that's what me and EleRas tested with, no more warnings, yay!).
The PHPBeautifier SysCP filter also was ran over the whole codebase, and yelded very good results and a much more readable and beautiful code (it's all about beauty today, isn't it? ).
And as EleRas also already announced, we're currently working on splitting up all the language files into a modular structure, it's no difficult job, but a tedious, boring one!
Plans for the future (future = SysCP 1.4 final release):

• complete the language files split


• integrate some new features (for example prodigy7's very good patches)


• convert SysCP to use Propel for database access, and use a totally new, much more modular and normalized database layout


• rewrite most of the modules to be compliant with the new database layout, while adding some features here and there, and making extensive use of the new features, like ValidationHandler, ...


• add a module to administrate Vservers (Linux-Vserver based), that's part of a project I have to complete for school, so that will probably have priority for me during the next weeks

There's also some talk about adding some type of optional LDAP support sometimes in the future, we'll see about that...
Ah, and MacOS X support is also planned, again sometimes in the future, this will probably mainly be done by flo, unless someone buys me a Mac Mini (Intel CPU, at least 1GB ram, contact me for a shipping address ).
That's it. Arrr, I wrote a little bit more than I intended to, but at least this should be a fairly complete status update and explain what we're going to do next, so... Let's do it!
Best regards, CHTEKK.

#gentoo-db has just opened it's (virtual) doors (or windows or terminals, depends on what IRC client you use ).
The new channel is intented to provide a platform for discussions, concerning both support and development, centering on Gentoo and databases.
At the moment Gentoo MySQL and PostgreSQL people hang out there, but it's my hope to see other developers and/or teams that maintain database-related packages for Gentoo (Firebird, Oracle, SQLite, BerkeleyDB, ...) join too, as well as users with experience in SQL and database management, or just people intersted in databases and their uses.
Best regards, CHTEKK.

For all those who wondered, PHP in Gentoo is definitely not dead.
Just put new revisions in the tree (dev-lang/php-4.4.2-r6 and dev-lang/php-5.1.4-r4), that fix various bugs and security issues. On that note, a big thanks to Stefan Esser from Hardened-PHP.net for all his patches and work on securing PHP (and of course the Hardened-PHP patch itself)!
The new PHP revisions also introduce a better separation between eclasses and ebuilds, making their managing and addition of new features easier. One of those new additions for now is the "concurrentmodphp" USE flag. It enables to build mod_php4 and mod_php5 in a way that both can be loaded at the same time into the same Apache2 instance, each mod_php then has it's own mime-types (application/x-httpd-php4{-source} for PHP4 and application/x-httpd-php5{-source} for PHP5) and configuration modifiers (php4_admin_value/php4_admin_flag for PHP4 and php5_admin_value/php5_admin_flag for PHP5 and so on). This feature is highly experimental, I could confirm it working on my x86 system and partially on an x86_64 system, but I'd very much like for users to try it out on systems where breakage is allowed (developement systems or test systems) and report back their results to me (chtekk@gentoo.org), thanks! To try it, do the following:
emerge --sync
echo dev-lang/php >> /etc/portage/package.keywords
USE="apache2 concurrentmodphp" emerge =php-4* =php-5*
then don't forget to "etc-update" and re-emerge ALL of your installed PHP modules/extensions (such as dev-php4/pecl-zip etc.). Also all this does not work with the "java-internal" (PHP4) and "sharedext" (PHP4/5) USE flags enabled, so be sure to disable them when you emerge php.
Best regards, CHTEKK.

A few days ago I added support for MPM-itk ("mpm-itk" USE flag) to our Apache 2.0 packages. MPM-itk is a user-switching MPM, that is, it switches to an assigned user when processing the requests, instead of processing everything as user apache (MPM-perchild, metux-MPM and MPM-peruser are other examples of this).
In it's original form it accomplishes this by doing the following:
apache process as root, interpret the request --> fork() new process and switch (setuid(unprivuid) / setgid(unprivgid)) to unprivileged user for it, process the request --> kill of the setuid/setgid process, with the next request it will redo the process
Now, this is foolproof, but provokes an immense performance hit, especially on static pages. Benchmarks done with ab2 showed that a normal Apache2 (MPM-prefork) can process about 240 PHP req/sec and 4000 HTML req/seq, while the MPM-itk patched Apache 2.0 managed about 110 PHP req/sec and 240 HTML req/sec, so you see, the peformance hit is enormous, and it's obiously due to the overhead of always having to fork() a new Apache process and then kill if off, for every request!
I managed to successfully change the way the MPM works, and thus managed to bring it's speed to normal Apache levels (patch against MPM-itk available here), by changing the "worfklow" like this:
apache process as root, interpret the request --> switch (setresuid(unprivuid, unprivuid, 0) / setresgid(unprivgid, unprivgid, 0)) to unprivileged user, process the request --> switch back to root (setresuid(0, 0, 0) / setresgid(0, 0, 0)), with the next request it will redo the process
Now this solves the performance problems, as it doesn't anymore do the extra fork(), and fully reuses the process with the next request, but it introduces a new problem: a gaping security hole. Since the processed request cannot be trusted, everything in there can simply setuid/setgid to root and do operations as root! A simple call to, for example, the posix_setuid/posix_setgid functions of the PHP POSIX extensio are enough to switch the user back to root and let the rest of the PHP script just work as root... This is totally unacceptable for security. So, now my call for help: has anyone got any idea how it's possible to realize this in a secure manner??? I can't think of any way to securely switch the process from root to unpriv user and back to root, without giving the untrusted code executed in the request processing phase the same ability (that is, to switch back to root). Ideas and comments are very appreciated.

Adieu old-style PHP (dev-php/php et all)...
One of many ways to say that, as I'm posting this, I'm cvs up'ing the affected directories to start the removal of the already masked old-style PHP packages, as announced one month ago.
For all the ones that didn't yet migrate... Well, migrate NOW!
And generally, enjoy the fact that "emerge php" will now install dev-lang/php, and you won't have to specify the directory anymore.
Best regards, CHTEKK.

The title says it all, the old PHP packages were finally masked!
Sorry for the three days delay (22 Apr instead of 19 Apr), but in the end, it's all done.
Again, thanks a lot to all the people involved in this, without their work this would have never been possible.
Best regards, CHTEKK.

I've just committed some updates to dev-lang/php, two of which may interst you:

1) the "nls" USE flag, which previously enabled the gettext extension, the mbstring extension and the sqlite-utf8 support, now only enables the gettext extension. The mbstring extension and sqlite-utf8 support were moved under the "unicode" USE flag. Affected ebuilds were already updated.

2) the EXTRA_ECONF variable was added to dev-lang/php, that way you can easily pass your own configure parameters to the ebuild if you want to try out some crazy stuff, just do:
EXTRA_ECONF="--with-whatever-I-want" emerge dev-lang/php
Two little notes: the variable doesn't get saved or remebered between emerges, so you have to add it to the command line each time, and anything you do that way is *totally unsupported*, so don't ever file bugs about it, thanks.

Best regards, CHTEKK.

UPDATE: it was now changed to EXTRA_ECONF instead of MY_CONF, to follow what a lot of other ebuilds already do.

Your friendly service announcement:

The PHP Herd announces that the old-style PHP packages, which were unsupported and deprecated for months, are finally going away.
After months of work, the team considers the new dev-lang/php package and the related dev-php[4,5]/ categories fully ready for production use, and encourage all users to upgrade.
Helpful informations can be found at the PHP project's pages, along with a HOWTO regarding the migration to dev-lang/php.
The old-style PHP packages (dev-php/php, dev-php/php-cgi, dev-php/mod_php, dev-php/PECL-*, and older dev-php/PEAR-* packages) will be package.masked on Wednesday, 19 April 2006, and removed from the Portage tree about a month later.

Best regards, CHTEKK.

As the title says, PHP 4.4.2 and PHP 5.1.2 were just added to Portage, enjoy! During the last week dev-php/PEAR-PEAR was also updated to 1.4.8 which should hopefully fix all the problems you may have been experiencing with access violations etc. when installing some PEAR packages. You can also find PHP 5.1.3RC1 in the PHP Overlay now for testing, enjoy that too.
Best regards, CHTEKK.

PHP is still going strong, you now can find PHP 5.1.2 and PHP 4.4.2 in the PHP Overlay, and the eclasses/ebuilds have seen a lot of work, they are now simpler to use and all that, and all PHP patches were moved to tarballs (which will allow you to save some bandwidth on emerge --sync's ).
Work has also started to solve bug #120088, we've got an idea and finally the time to try it out, it should work and satisfy all parties involved, but will require some good planning when the changes are introduced, more details on this as soon as I have working code to show people (just follow the Overlay's progress, should appear there in the experimental/ branch as soon as ready).
Best regards, CHTEKK.

As the title says, what would you prefer for the future of MySQL in Gentoo?
Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it).
Thanks!
Best regards, CHTEKK.

PHP in Portage is still alive!
5.1.2 and 4.4.2 should soon be ready, I'm getting a couple of vServers ready to test that and make some changes, as I was without a proper dev-machine for ~ 3 weeks now. A big thanks to the Gentoo-VPS project, setting up vServers with the ebuilds in Portage and the HowTos is really easy and works great!
As a sidenote, I added the minutes of this month's PHP herd meeting to the PHP Overlay page as well as the full IRC log, next meeting is scheduled for Tuesday, the 7th of March, 2006, at 19.00 UTC. I apologize for the delay in getting the minutes up and the new PHP versions out, but lately I was really busy with school etc., now I'll have a lot more time at my disposal during the next few weeks and I can break and test stuff much easier, thanks to the vServers.
Best regards, CHTEKK.

Just fyi: the 'pear' USE flag was deleted from the dev-lang/php packages, this was done because the USE flag was only there to provide a convenient dependency on dev-php/PEAR-PEAR (which still exists and will continue to exist, and btw: PEAR 1.4.6 was added today to the tree!). Now, this dependency needed to be so that PEAR-PEAR was emerged after dev-lang/php (as it needs dev-lang/php to work), so we used PDEPEND, which is the only depend type that gets emerged after the package specifying it at the moment in Portage. And this caused all sorts of havoc with other ebuilds that depended on both PEAR-PEAR and dev-lang/php, messing up the dependency chain, where it fex. tried to emerge dev-lang/php, then the ebuild that needed PEAR-PEAR, and after that PEAR-PEAR, this became especially obvious with the ezComponents ebuilds. So we fixed it by removing the 'pear' USE and PDEPEND from the dev-lang/php ebuilds: now all the dependency chains are generated correctly and as expected, and you can still install pear as usual with an "emerge dev-php/PEAR-PEAR".
Best regards, CHTEKK.

The minutes of the PHP Herd's January meeting are now available, including a full log if anyone needs it.
We elected herd leads, agreed on how to deal with the old-style PHP packages and discussed a number of ideas like SLOTing of PHP minor version and some eclass changes, amongst other things.
The next meeting will be on Tuesday 7th February 2006 at 19:00 UTC in #gentoo-php on irc.freenode.net. All are welcome. If anyone has a topic they'd like to see on the agenda, please let a member of the PHP herd know before the meeting.

Also, as a non-meeting-related note, we finally uploaded our official PHP Herd page, including up-to-date versions of our documentation (done by Andreask, great work and thanks!).

The first PHP Herd Meeting will be held tonight, Saturday 21 January 2006, at 19.00 UTC, in the #gentoo-php IRC channel on irc.freenode.net, for more details check MeetingAgendas.
The meeting is open to all, so if you just want to attend, if you have something to say, etc., just join the channel!

Today, after about 7 months of work, we finally opened the bugs requesting the stabilization of dev-lang/php version 4.3.11-r5, 4.4.1-r3 and 5.0.5-r5, you can follow the progress at the main bug.
PHP 5.1.1 will never go stable, we're working on getting PHP 5.1.2 in the tree as soon as possible and that one will then be (along with PHP 4.4.2) the candidate for stabling after the customary 30 days a package has to remain in the tree before being marked as stable.
PHP 4.4.2 and PHP 5.1.2 are on their way and should be available in Portage in about a week, if you want to try them out, we already have PHP 5.1.2 in our PHP Overlay.
There was also movement on the PEAR front of things: dev-php/PEAR-PEAR was updated to 1.3.6-r4 wich should fix a few bugs and be collision-protect safe. The new dev-php/PEAR-PEAR now directly includes the old dev-php/PEAR-Archive_Tar, dev-php/PEAR-Console_Getopt and dev-php/PEAR-XML_RPC packages, so there's no need to emerge them anymore, in fact you have to uninstall them (emerge -C) to be able to install the new dev-php/PEAR-PEAR-1.3.6-r4, so if Portage complains about blockers and such, just emerge -C the three packages mentioned above.
A couple of bugs were closed today too, concerning pecl-pdo-pgsql compile failures, and some new packages were added recently to the PHP Overlay: odbtp and pecl-odbtp, an alternative to freetds and the PHP mssql extension to access MSSQL databases.
The PHP Herd will also soon hold a meeting to discuss some things, I'll blog about the definitive date once it's decided.
Things are looking good for PHP on Gentoo imo, and I really wanted to thank all the PHP Herd members and all the other people involved in this, especially Stuart, Sebastian, Jakub, Andreask, Wendall911 and Kloeri, for their great help and amazing work & contribution, thanks guys!

Finally, PHP 5.1.1 and the new revisions for the other dev-lang/php versions are in the Portage tree.
Those should fix a lot of bugs and problems, especially with Hardened-PHP (updated to latest 0.4.8 release) and GCC4 (bug in the CURL extension that made the compile fail).
With those, we also now use app-admin/php-toolkit instead of app-admin/eselect-php, so you'll be required to migrate to php-toolkit (just unmerge eselect-php and emerge php-toolkit), since eselect-php will soon be removed from the tree.
The PHP Overlay was updated/cleaned accordingly.
Enjoy PHP 5.1!

Happy New Year to anyone!

This sure was an interesting year for me, with many unexpected turns, but all definitely well gone and liked on my part!
I hope for another great year with all of you and with Gentoo.
Again, I wish a great 2006 to all of you! :)

P.S.: I hope to be able to add PHP 5.1.1 to the Portage tree during the next week, just waiting on bug 116975 to be fixed.

Well, a bit of time passed since the last Gentoo+PHP related blog entry, so I'll update you about it's status with this one.

dev-lang/php is updated and works well, 5.1.1 is ready for Portage, indeed we're adding new and updated PECL etc. packages to the Portage tree lately, but we have to wait until bug 115887 is fixed before we can add the new dev-lang/php packages and eclasses themselves to Portage, so I hope this will happen really soon! After that we'll leave the new-style PHP packages about one week still in ~ARCH, and start stabling them, beginning with x86 (we'll open a bug about that), probably on the first/second of the new year.
I hope you all appreciate the new PHP packages, they work very well here, and if you appreciate the work we're doing on them, here's my Amazon wishlist if anyone's intersted.

Best regards, merry christmas and a happy new year, CHTEKK.

Well, PHP 5.1.0 is finally out!
And no, you won't see this in Portage very soon. It has a couple of problems that are being discussed over at the php-dev mailinglist and it seems 5.1.1 will come out soon, we'll wait for 5.1.1 before considering it's addition to the Portage tree. For the ones who really want the bleeding-edge, try out the PHP 5.1.0 ebuild we have in our PHP Overlay:
PHP 5.1.0 ebuild
But don't complain if it breaks stuff, it's still in testing!
Also, thanks to Stuart we finally have php-select, the replacement for eselect-php, wich will be part of the php-toolkit package.
The next days will see a massive update of all new-style PHP related packages (dev-php4/* is already done), and new revisions of dev-lang/php to fix a minor security problem and update to use php-toolkit instead of eselect-php.
That's all for now, cu later!