chtekk b10g

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.