<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Thoughts Electrique &#187; Debian</title>
	<atom:link href="http://www.sebastian.himberger.de/blog/tag/debian/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sebastian.himberger.de/blog</link>
	<description>Sebastian Himbergers blog about technology and software development</description>
	<lastBuildDate>Thu, 08 Jul 2010 17:05:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>The Ubuntu LTS default repository problem</title>
		<link>http://www.sebastian.himberger.de/blog/2009/11/08/the-ubuntu-lts-defaultrepository-problem/</link>
		<comments>http://www.sebastian.himberger.de/blog/2009/11/08/the-ubuntu-lts-defaultrepository-problem/#comments</comments>
		<pubDate>Sun, 08 Nov 2009 04:25:20 +0000</pubDate>
		<dc:creator>Sebastian</dc:creator>
				<category><![CDATA[Technology]]></category>
		<category><![CDATA[Debian]]></category>
		<category><![CDATA[Opinionated]]></category>
		<category><![CDATA[Sysadmin]]></category>
		<category><![CDATA[Ubuntu]]></category>

		<guid isPermaLink="false">http://www.sebastian.himberger.de/blog/?p=580</guid>
		<description><![CDATA[I&#8217;ve often seen Ubuntu being chosen instead of Debian because the LTS version offers support and security-fixes for five years. This kind of SLA is often a critical argument. But while Ubuntu is happily claiming to be enterprise-ready they yet enable the universe and multiverse software repositories per default even in the LTS server edition. [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve often seen <a href="http://www.ubuntu.com">Ubuntu </a>being chosen instead of <a href="http://www.debian.org" target="_blank">Debian </a>because the LTS version offers support and security-fixes for five years. This kind of SLA is often a critical argument. But while Ubuntu is happily claiming to be enterprise-ready they yet enable the <em>universe </em>and <em>multiverse </em>software repositories per default even in the LTS server edition. Since <a href="http://www.ubuntu.com/community/ubuntustory/components" target="_blank">these two repositories are not included in the SLA</a> you might end up with software that is not provided with patches and therefore the whole security guarantee get&#8217;s thrown out of the window. While I&#8217;m not saying community backed security is bad it basically sets Ubuntu into the same mode of operation as Debian and this even without a specific warning or even notice. To be on the safe side you should disable the <em>universe</em> and <em>multiverse</em> repositories after installation or at least be aware of this fact.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.sebastian.himberger.de/blog/2009/11/08/the-ubuntu-lts-defaultrepository-problem/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Runkit with PHP on Linux (Debian Etch)</title>
		<link>http://www.sebastian.himberger.de/blog/2008/11/23/runkit-with-php-on-linux-debian-etch/</link>
		<comments>http://www.sebastian.himberger.de/blog/2008/11/23/runkit-with-php-on-linux-debian-etch/#comments</comments>
		<pubDate>Sun, 23 Nov 2008 20:26:27 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Technology]]></category>
		<category><![CDATA[Debian]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[PECL]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Runkit]]></category>
		<category><![CDATA[Server]]></category>
		<category><![CDATA[Tutorial]]></category>

		<guid isPermaLink="false">http://www.sebastian.himberger.de/blog/?p=19</guid>
		<description><![CDATA[The forbidden fruit
I recently discovered runkit for PHP and thought it could be a solution for a few problems I ran into during my work on various projects.
At heart runkit allows you do to stuff with PHP you shouldn&#8217;t, but eventually want to, do. In my case this is basically Sandboxing and redefining (even PHP-internal) [...]]]></description>
			<content:encoded><![CDATA[<h3>The forbidden fruit</h3>
<p>I recently discovered <a title="runkit PHP extension" href="http://de.php.net/runkit" target="_blank">runkit </a>for PHP and thought it could be a solution for a few problems I ran into during my work on various projects.</p>
<p>At heart runkit allows you do to stuff with PHP you shouldn&#8217;t, but eventually want to, do. In my case this is basically <a href="http://en.wikipedia.org/wiki/Sandbox_(computer_security)" target="_blank">Sandboxing</a> and redefining (even PHP-internal) functions. It really adds some cool stuff to your PHP toolbox. Have a look at the <a href="http://en.php.net/runkit" target="_blank">function reference</a> for the complete list.</p>
<p>Sadly enough the runkit PECL package does not work on Debian Etch (because Etch uses PHP 5.2.0+) so I had to build the package myself. Read on to find out how to build and install runkit on Debian etch and things to keep in mind when using runkit.</p>
<p><strong>Important:</strong> If you are unsure of using runkit have a look at The sections <em>The Caveat</em> and <em>Final Remarks</em> before you walk through the hassle of installing it.</p>
<p><span id="more-19"></span></p>
<h3>Install &amp; Configure runkit</h3>
<h4>Obtain the sources from the runkit CVS</h4>
<p>Obtaining the sources is pretty easy. Just open a terminal and enter the following commands (leave the password empty when prompted for it)</p>
<pre class="terminal">cvs -d:pserver:cvsread@cvs.php.net:/repository login
cvs -d:pserver:cvsread@cvs.php.net:/repository co pecl/runkit</pre>
<p>This will checkout the runkit codebase into your current working directory.</p>
<h4>Building the Debian package from the PECL source</h4>
<p>You need some tools for building the package so I installed them using aptitude.</p>
<pre class="terminal">sudo aptitude install dh-make-php php5-dev</pre>
<p>Then I created a kind of fake PECL package from the CVS sources to use it with the <a title="dh-make-pecl manual (I know.. it's Ubuntu)" href="http://manpages.ubuntu.com/manpages/intrepid/man1/dh-make-pecl.html" target="_blank">dh-make-pecl</a> tool. dh-make-pecl is a Debian tool which helps you building .deb from a PECL package. The PECL package is just a .tar.gz archive having the following structure:</p>
<div id="attachment_185" class="wp-caption alignnone" style="width: 193px"><a href="http://www.sebastian.himberger.de/blog/wp-content/uploads/2008/11/runkit-pecl-package.png"><img class="size-full wp-image-185" title="The runkit PECL package structure" src="http://www.sebastian.himberger.de/blog/wp-content/uploads/2008/11/runkit-pecl-package.png" alt="The runkit PECL package structure" width="183" height="361" /></a><p class="wp-caption-text">The runkit PECL package structure</p></div>
<p>I assembled this package by using simple mv and mkdir inside the CVS then I used tar to create the archive. I called it <em>runkit-cvs-&lt;date&gt;.tar.gz</em> but the name is basically irrelevant.</p>
<pre class="terminal">mkdir -p package/runkit-0.9
mv pecl/runkit/package*xml package/
mv pecl/runkit/* package/runkit-0.9/
cd package/; tar cfz ../runkit-cvs-`date +%Y%m%d%H%M`.tar.gz *; cd ..</pre>
<p>After I had the fake PECL package I could start creating the .deb from it. This was fairly simple.</p>
<pre class="terminal">dh-make-pecl --only 5 runkit-cvs*tar.gz
cd php-runkit-0.9
dpkg-buildpackage -rfakeroot</pre>
<p><em>dpkg-buildpackage</em> puts the created .deb parallel to the <em>php-runkit-0.9</em> directory. The <em>&#8211;only 5</em> parameter requests the dh-make-pecl command to only create a Debian source package for the PHP 5 module. Have a look at the manual for more information.</p>
<h4>Installing the package</h4>
<p>Installing runkit is now just a matter of typing <em>sudo aptitude install php5-runkit_0.9-1_i386.deb</em> and letting APT do it&#8217;s work. After that you have to create a configuration file under <em>/etc/php5/apache2/conf.d</em> called <em>runkit.ini</em> with the following contents:</p>
<pre class="file">extension=runkit.so

# comment out the following line to disable the overloading
# of PHP internal functions.
runkit.internal_override=1</pre>
<p>After that restart your Apache server and you are done with the installation. You can check if runkit was installed sucessfull by just creating a <em>phpinfo()</em> file and look if runkit is listed in the modules section.</p>
<div id="attachment_186" class="wp-caption alignnone" style="width: 510px"><a href="http://www.sebastian.himberger.de/blog/wp-content/uploads/2008/11/runkit-phpinfo.png"><img class="size-full wp-image-186" title="The runkit phpinfo() section" src="http://www.sebastian.himberger.de/blog/wp-content/uploads/2008/11/runkit-phpinfo.png" alt="The runkit phpinfo() section" width="500" height="124" /></a><p class="wp-caption-text">The runkit phpinfo() section</p></div>
<h3>The Caveat (Renaming PHP internal functions)</h3>
<p>I was quite happy to have all this stuff running but as we all know nothing is less predictable than solutions in information technology (apart from visiting relatives appearing out of nowhere). My first little project was to add some logging to the PHP built in <em>mail()</em> function. This may be useful to track down the spam sending contact form one of your customers build for his website on your server. I wrote a small script for testing purposes and just threw it in my public_html directory.</p>
<pre class="file">// Simple function to ouput a log message
function do_log($message) {
  echo 'LOG:'.$message;
}
// Wrapper for the PHP mail() function.
// Logs the mail parameters.
function logging_mail($to, $subject, $message, $headers = null, $params = null) {
  do_log('Sending mail to '.$to.' by '.__FILE__);
  php_mail($to, $subject, $message, $headers, $params);
}

// Interchange the built in function with my own
runkit_function_rename('mail','php_mail');
runkit_function_rename('logging_mail','mail');

mail('mymail@nodomain.xyz','Subject','message');</pre>
<p>It all seemed nice and logical but when I first opened my webbrowser and accessed the page I got a blank screen. My Apache error log revealed a <em>child pid 10051 exit signal Segmentation fault (11)</em> and commenting out the <em>mail()</em> and a quick page refresh even added a <em><strong>Fatal error</strong>:  Cannot redeclare do_log()</em> to the table. This looks really bad. It seems that renaming PHP internal functions and replacing them doesn&#8217;t work with runkit and the resulting crash of the PHP interpreter left the library of this interpreter in a corrupted state (user-defined functions where not removed because the script didn&#8217;t exit properly).</p>
<p>So as always: The part of a library you really need has a nasty bug. Although renaming user defined functions works great with runkit the part I really wanted doesn&#8217;t work out of the box.</p>
<p>I already have a solution in mind but this will be the topic of another blog post.</p>
<h3>Final remarks</h3>
<p>Runkit in theory is really great stuff. The problem with this library in realty is that it&#8217;s still beta (even after several years) and doesn&#8217;t seem to be actively maintained. Just a short look at the CVS repository and the bugtracker revealed that there hasn&#8217;t been much activety in the last year or so. This is a pitty because having the additional flexibilty that runkit provides really would be a killer feature for PHP developers. Other scripting languages (Python, Groovy and more) already bring these features to the table natively which allows you to write extremly elegant code.</p>
<p>If you are willing to dig into this extension prepare to do some work and be eventually disappointed because the solution you had in mind won&#8217;t work because of bugs. If you are willing to take this risk and invest some time and energy go for it. Maybe future versions of PHP will make runkit obsolete or a good-willing developer will take care of the bugs. Till then runkit remains black magic, it can make you incredibly powerful but also is a serious risk for your mental stability.</p>
<h3>More information</h3>
<ul>
<li><a title="An alternative way to build runkit" href="http://gabriel.e-radical.ro/blog1.php/2008/09/25/runkit" target="_blank">http://gabriel.e-radical.ro/blog1.php/2008/09/25/runkit</a> &#8211; An alternative way to build runkit</li>
<li><a title="Runkit function reference" href="http://en.php.net/runkit" target="_blank">http://en.php.net/runkit</a> &#8211; The runkit function reference</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://www.sebastian.himberger.de/blog/2008/11/23/runkit-with-php-on-linux-debian-etch/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
