Entries Tagged 'development' ↓

I had to make a couple of diff's lately and I always forget what switch to use

So here is it:

On v2 of my website I wrote a post on configuring a webserver for testing/developing purposes. In that post I explained how to adjust the umask of Apache. I did that by changing the Apache startup script. But, of course, when apache is updated/upgraded, you custom mod will dissapear. In coincidence I stumbled upon a post that explained how to add environment variables to apache without modding the distribution scripts.

All you do is adding the desired variables to "/etc/apache2/envars". That's it!

I've installed puppet recently and I'm know trying to understand how it works and make use of it

If that's not difficult enough, I encountered this weird behaviour that the --noop argument didn't do anything. After an hour of searching I realized it was my own stupid fault!

I had to puppet configuration files: /etc/puppet/puppetd.conf (old way) and /etc/puppet/puppet.conf (new way). I browsed throught the source code and it looks like puppet first checks the old file, if it is found it parses that one. If it's not found, the new file is parsed. I don't know why, but if the old file is used, the --noop argument isn't parsed by puppet. So removing /etc/puppet/puppetd.conf was all I had to do. Pffff....

But why did I create the puppetd.conf file? Because I'v read the "Pulling strings with puppet"-book. And althought it's fairly new, puppet is advancing at a very high rate. So the book is becoming out-of-date already.

At Tim_online we have several webservers and each of them have apache2 installed running php with fcgid (a fastcgi implementation). Why this configuration and not mod_php? Because it is reasonably fast (at leaster faster than plain cgi) an secure (because it doesn't run under the apache user).

For it to run php scripts as the website owner, you need suexec.

Suexec is a mechanism supplied with Apache that allows to execute CGI scripts as the user they belong to, rather than Apache's wwwrun user. This improves security in situations where multiple mutually distrusting users have the possibility to put CGI content on the server.

So when u visitor requests one of the webpages of one of my customers the proces looks like this:

request -> apache -> fastcgi -> suexec -> proxy -> php file

I don't exactly know anymore why the proxy is required, but it is
Know the problem is: suexec (by default) can't execute the proxy file, because it isn't owned by the php file owner. So you have to hack suexec to make this work.

I did this. And everything worked. The webservers were happy to serve al these requests untill one day apache get updated. The automatic ubuntu updates push a new version of apache with a new suexec binary. Problem!

So when you come at work there are 16 "missed incoming calls" and you co-workers are going mad with all the dissapointed customers. You look at the apache logs: hmzzz, suexec is giving 120 errors... What could that be? !Ping! Suexec ofcourse. Let's see, how did I solve this problem the last time. First let's download the apache sources. ./configure. Yes. now where's suexec.c? Ah, cd support. Now,  make suexec. Wait, missing headers. Let's install those first. Make suexec. Arrgh. It doesn't work! Suexec -v. Wait, forgot to adjust the ap_httpd_user, ow, and comment out the offending lines. Yes, this should work. Ok. Copy it to /usr/lib/apache2. Ok, it works!

But at that time, an hour has past. If you can find the right files at once. So I decided to write down the steps I took to download, configure and compile suexec the quickest and simplest way. Here we go:

That's it! Test it by doing: sudo ./suexec -V
That should output:

Basically what I did:

1. I installed the necessary headers
2. Got the latests suexec code from the apache svn repo
3. Downloaded the suexec patch from my blog
4. Patched suexec to disable the file owner check
5. Compiled suexec with the default ubuntu options

I the release post of com_resized there was asked the question why one should use com_resize. There are three reasons to use it:

1. The generated images aren the size you want them to be. So they're smaller of size than the original images.
2. You won't get any ugly resized images (see the example below).
3. It works with remote images. So you can link to an image one someone else's blog and they get resized to the size you want + cached. So that way they get loaded from your own server: so faster.

No more ugly resized images:

The one on the left is without com_resize. The one on the right is _with_ com_resize. If you don't see any difference. Your browser is probably doing some fancy stuff with the image. In that case you don't need com_resize. But maybe the readers of your blog do!

For the people who don't see any difference (leave a comment with your OS + browser, please!) I have attached a screenshot. Made in IE6, so the font is ugly too

Hi all! I've released my first project on rubyforge. The sourcecode is on github though. For the  simple reason that my git repository on rubyforge doesn't work (yet). I hope they will fix it soon.

I've setup the project with the wonderful bones of Tim Pease.

I've got some reasonable documentation about it, a kick-ass website (stolen from Dr. Nic's newgem) and some nice unit tests. I'm now integrating the gem in one of my own projects. If that's succesfull I'm gonna release a version 0.1. The version after 0.1 will have new features.

The website ws generated with webby. A really nice way to create static websites in ruby. Maybe I'll dedicate a post/tutorial to webby.

So please look at the website, install the gem and give me some feedback. It will be very appreciated!

I'm now working on a project that is hosted on github AND rubyforge. And lazy as I am, I don't want to do:

That's why I create a handy shortcut for it and placed it in my ~/.bashrc:

What it does: it lists all remote repositories linked to that git project and pushes them all. Usage:

Don't get confused with "git-push --all"! That's something completely different!

I saw the MountainWest Ruby conference video: code generation: safety scissors of metaprogramming. And the speaker (Giles Bowkett) used vi from inside irb. And I've never liked Vi, but using an editor from within irb is nice! Especially if you're testing a big chunk of code.

So I began crawling the Internet for how he did this and I found the utility_belt gem. The utility belt contains the file I needed. So I installed the gem, edited my .irbrc and now I can use nano/gedit (or any other editor) from withing IRB!

These were the steps:

My .irbrc:

Now to use nano in irb, just type: nano

And the bonus: a nice screencast that shows this feature in action. I tried to edit it with pitivi. But that really sucked. After I finally found it out how I could cut pieces I tried to save it and the whole program crashed. "apt-get remove pitivi"!

Nice: blog.html.it/layoutgala

I'm not a designer _at_all_ but this post on designing a blog theme is very nice. I really like the copyblogger theme I have now. But maybe I'll try and create something myself. Because a unique theme for a blog is so much nicer.

Also here a post on typography and five principles of effective web design.