hoodwink.d enhanced


Scripting Portupgrade with Ruby #

by why in inspect

I guess it’s hard to top RubyX when it comes to an OS alliance with Ruby. However, FreeBSD’s portupgrade long ago heaved the bar up—it’s a scriptable application for updating ports. I’ve always considered it to be neck-and-neck with tDiary for being Ruby’s first killer app. And portupgrade has got tDiary beat on worldwide adoption. tDiary is hot snakes in Japan—and only.

The primary means of scripting portupgrade is with the pkgtools.conf, which is a Ruby script full of constants. For example, should you want to give make arguments for certain packages, MAKE_ARGS is a hash:

    'editors/vim' => 'NO_GUI=yes WITH_RUBY=yes',
    'shells/scponly' => 'WITH_SCPONLY_SCP=yes WITH_SCPONLY_GFTP=yes 
    'sysutils/gkrellm2' => 'GKRELLM_SERVER_ONLY=yes'

If you know Ruby, scripting portupgrade becomes really trivial. In fact, one of the first Ruby programs I wrote kept the long and winding PHP make flags I had and abstracted them into a simple array.

Like so:

  PHP_OPTS = %w[bz2 ctype imap MySQL overload pcre
    posix session sockets standard tokenizer xml 
    xmlrpc zlib]
    'lang/php4' => "BATCH=yes WITH_APACHE2=yes " +
        PHP_OPTS.collect { |o| "WITH_#{o.upcase}=yes" }.join( ' ' )

Imagine if you could script your web server in this manner. See and it seems like the budding courtship between lighttpd and Ruby would yield such scripting. (VHosts in a YAML file, anyone??)

The author of portupgrade (and portsdb), knu, has been the Ruby CVS chieftain since 2000. He has been nothing but judicious and kind. And we’ve all benefited from cvsmailer at one time or another, wouldn’t you say??

said on 18 Mar 2005 at 18:40

I don’t know much about lighttpd, but Apache and Ruby already have some tight integration. With mod_ruby dig all into apache’s data structures and you can supply hooks in various stages of handling a request.

Also on one server I setup I wrote a simple Ruby script to interact with mod_rewrite. This ruby script determines what site is loaded when it is queried on each request. It gets the data from a MySQL database. Much better than a VHosts in YAML . No need to even reboot apache when I add a new site. I simply add a record to the database and create the directories to store the website.

said on 19 Mar 2005 at 02:24

Oh, only if portupgrade could dump the list of options a given port can take (similarly to “emerge -pv” of gentoo)...

Or can it do that?

said on 19 Mar 2005 at 10:38

Eric: I’m not fond of configuration trapped in the database. Doesn’t that mean I have to work through HTML forms rather than Vim? And I can’t keep version control on those configurations.

Whenever I’ve had wikis, blogs or configuration files stored in a database, I always get seized by pangs of regret. Maybe if textarea and other controls were friendlier.

said on 21 Mar 2005 at 15:09

why: In the setup I described was for a small webhosting company I did some work for and their goal was to reduce the amount of configuration. They wanted people to be able to fill out a web-form to create an account. The accounts were more thought of as data that the configuration read not the configuration itself.

Obviously this script could also read from a YAML , XML or any other file instead of a SQL database, but a SQL database is more efficient for searching (indexes, optmizations, etc) and it can be easily manipulated by many tools. Also it is “versioned” in the fact that the databases were backed up nightly.

I agree that plain text is more accessible than SQL but SQL is quite accessible as well. As far as YAML goes I still haven’t understood why the Ruby community likes it so much. If I wanted to deal with a system where whitespace meant something I would be programming in Python. :)

But this is all kind of off-topic. My only point was that Ruby is already fairly integrated with a webserver (apache) with mod_ruby. Even if you didn’t want to go that route you can still do what you mentioned (ruby determined vhosts) with mod_rewrite. The database backend was just an unnecessary detail.

Comments are closed for this entry.