Search Results: "bap"

3 December 2005

Matthias Urlichs: Web servers are annoying

So I'm setting up a new web server. It need to be secure (no user A spying in user B's files). It needs to run PHP. Yes, you may run away now. Oh yes, it also needs to be fast...

So how to do that? I'm not going to run Apache+mod_php on the thing. :-/

I've started with Apache2, FastCGI, PHP via FCGI, installed eaccelerator for 60% speed-up.

All of this works reasonably well, except for PHP scripts that want PATH_INFO (like http://.../blog.php/2005/12/03/some_random_gunk). mod_fcgi passes the whole thing's pseudo file system path in PATH_TRANSLATED. The PHP FCGI process checks that path, sees that it doesn't exist (blog.php is a file after all), and immediately returns an unhelpful error.

I've worked around that thing with an ugly hack, but I suspect that the real fix would be to add this same hack to PHP instead.

Opinions, anybody?

NB: Oh, and if somebody could tell me why my mysql server's kernel randomly ignores incoming TCP connections for a few seconds every minute (and yes, it's the kernel), I'd be grateful. I suspect that the solution is going to be "upgrade to something newer than 2.6.12-9-686-smp (Ubuntu Breezy's kernel)"... :-/

NB2: There's also a mod_fcgid for Apache2. Hint: It's crap -- if all FCGI processes happen to be busy, I want new requests to be delayed. I do not want them to be rejected with a terse, hard-coded error message.

20 November 2005

Matthew Palmer: My First Time Mining Ruby

I'm not usually a grand fan of the latest and greatest fads'' in programming. The only C# I know is the black key next to D#, and I loathe coffee. An IDE in the hands of a poor programmer will still result in crap code. While I do think that agile methods (such as XP) can do well in certain development environments, I certainly don't subscribe to the notion that XP can solve all the world's software production ills. And so on. I do know quite a number of programming languages, and tend to pick up new ones out of intellectual curiousity (although Ada did put a severe dent in that habit) or because a bit of research tells me that the language might be particularly suitable for a particular task (although I've since learned that the actual purpose of PHP isn't dynamic websites so much as bringing the security levels of Linux boxes in line with Windows-led industry standards). I also learn languages because I want to hack on projects written in them, which is motivational, but not a particularly good way to get a deep understanding of a language. Why all of this introspection in a blog? So you have the background to understand how everything about Ruby is different for me, including how I'm getting started using it. I have no interest in hacking on a Ruby-implemented project, and -- although Rails proponents give me an impression similar to that of a horny teenager with a shiny new unlimited broadband account -- I don't have any particular use for Ruby at the moment (I want to write less webapps, FFS, not more!). So, why the hell did I fork out $90 hard-earned South Pacific pesos for a copy of "Programming Ruby: The Pragmatic Programmers' Guide"? A couple of reasons: I'm glad I got "Programming Ruby". The book is superbly organised, reads very easily, and gives you all of the love as and when you need it. Surprisingly for me and a technical book, I read the first section of the book "cover to cover". By the end of it, I came away with a real (if naturally superficial) understanding of the language, and a feeling that I was ready to tackle the world in Ruby. It is a sad state of affairs when the first piece of new programming you can sink your teeth into is some four days after finishing your initial studies into a language, but this afternoon I wrote my first Ruby program in anger. It's quite simple -- just take stdin and rewrite it all on stdout with the lines in a random order. But I wrote it in a new programming language, in about 3 minutes, with nothing more than ri (Ruby's answer to firing up python and typing help(xyzzy), more or less) and "Programming Ruby". I think I also produced a suitably reasonable result:
#!/usr/bin/env ruby
lines = []
while line = gets() do
	lines << line
end
	
while ! lines.empty? do
	idx = rand(lines.length)
	puts lines[idx]
	lines.delete_at(idx)
end
(Any Ruby afficionados out there, feel free to e-mail me and tell me what egregious sins I've committed). I think it looks reasonably neat and clean, it's certainly simple, and the use of real Object Orientation makes for a certain readability (I think the method call lines.empty? is particularly cute, although I did initially consider the use of a question mark in a method name to be a crime against humanity). So, will I be using Ruby more in the future? I think so. There are some features in Ruby which I'm hoping to get a lot more cosy with -- the idea of "blocks" looks particularly interesting, and I don't think the utility of languages that have been designed, top-to-bottom, to really live the OO ideal has been explored enough (you SmallTalk bigots can stop glaring at me now -- really, I mean it -- stop it!). It's far too early to tell whether Ruby will become my "go to" language for random development tasks, but anything that stops the nightmares (where I start thinking about using PHP as a general scripting language) cannot be all bad. And, if I continue to make new webapps, Rails will probably come in handy. Update: HTML <pre> tags don't like having < inside them unescaped. Also, Philipp Kern pointed out that the Ruby documentation browser is called ri (not ir as I originally wrote). Philipp was also kind enough to provide a much shorter version of my original script, which shows the power of Ruby so much better:
 lines = []
 STDIN.each_line    line  lines << line  
 lines.sort_by   rand  .each    line  puts line  
Now tell me that isn't a language worth using!

2 November 2005

Erich Schubert: Apache2 + FastCGI + Suexec hell

It took me hours to get FastCGI and Suexec working properly. I'm so annoyed by the horrible docs available for it only. First I tried using fcgid (which at least is DFSG-free) but wasn't able to run moinmoin properly at all. So I gave up on that quickly. So I ended up trying "non-free" libapache2-mod-fastcgi. Oh what a mess. Getting the non-suexec fastcgi working was easy. Now I tried to make it a bit more secure... The "Documentation" claims that all you need to do is enable the SuExec Wrapper. So I configured a "FastCgiServer", set -user and -group appropriately, somehow found out that I need to chown the executeable and the dir containing the executeable accordingly, and that the user and group need to be higher than 100 - ok. (Although group www-data would have been okay, I guess). Reloaded apache. And the fastcgi process is started and running with the right userid. By now I was using a mini test-fastcgi, which prints getuid() - and so I could see that despite my process runing as a different user, it still returned 33 (=www-data). Damn! The reason I found out later after manually changing URIs to find the right docs etc. was that I need to enable mod_suexec, then add the SuexecUserGroup option to my vhost. For incoming requests, FastCGI will check for a running fcgi server with the same path and the same user and group ids as the one you defined in the fastcgi config. Otherwise it will start a new dynamic server. And there is no "FastCgiUserGroup" option or something obvious to configure the user and group name for the cgi path - but you need to do that for mod_suexec. Apache config is a PITA anyway. With its pseudo-XML syntax etc. - we really need to get rid of it sometime... So here is a short howto for using suexec and mod_fastcgi on apache2:

Next.

Previous.