Apache 2.2 authentication with mod_authnz_external

Posted by Jonathan

The last couple of hours I’ve been fighting with Apache 2.2 authentication. I must say, it is really a mess, hard to debug, and very frustrating. Many times I wished for Lighttpd to have SVN/DAV and authentication modules.

The scenario is simple, you have a server that hosts your subversion repository and you with to serve it through HTTPS for security and access control. Subversion repositories can be served through the svn+ssh access method but this is inflexible (you can not control access to certain branches of the repository at least with subversion <= 1.2) and not properly encrypted (AFAIK svn+ssh only encrypts the login/authentification but not the actual data stream) as you need SSH/shell access for every user. So there is only the HTTPS access method left. And only Apache 2 as a server.

Because you need authentication for the subversion access the simplest thing to do is to create UNIX accounts on the server and let Apache authenticate with HTTPAuth over SSL against this database. You would think that the most common UNIX web server would be able to do this out of the box or at least with just one or two configuration knobs. But this is not the case, configuring Apache 2.2 to authenticate against UNIX shadow accounts is a major pain. Quite surprising if you look how easily dovecot (a POP/IMAP mail server, very young in comparison to Apache) does this out of the box.

There are are two recommended ways to do this, PAM (mod_auth_pam2) and using an external provider (mod_authnz_external). Both modules are not core modules and have their problems.

First there is PAM, the Pluggable Authentification Modules. The nice thing about PAM is that (apart from not being under active development any longer) it is itself a pain to configure and debug. Further in order to make mod_auth_pam(2) access to the shadow files you need to either run Apache as root (BIG MISTAKE!) or give the Apache user read access to the shadow files (also not a very good idea!). So after fighting with PAM for some time, I choose to try the second auth module, mod_authnz_external.

Mod_authnz_external hooks into the Apache auth systems and allows you to define external programs that get the username/password combination and return a status code. This way Apache can outsource the authentication process to an external program that has extra privileges and Apache can keep its low security profile. The author of mod_authnz_external ships such an external program, pwauth. Pwauth authenticates against UNIX shadow files or PAM (yea!). Pwauth runs as setuid root in order to do this but this is much better than running Apache as root or give Apache access to the shadow files.

At compile time you tell pwauth which users are allowed to use it (in my case the user www) and which auth backend to use (shadow or PAM). This can be tested like this (in (t)csh):

# sudo -u www pwauth ; echo $status 
username
correct_pw
0
# sudo -u www pwauth ; echo $status 
username
incorrect_pw
1
#

On FreeBSD the PAM config for pwauth looks like this:

# cat /etc/pam.d/pwauth
auth       required     pam_unix.so debug
account    required     pam_unix.so debug

(I thought that the same configuration would work for Apache, but it didn’t.)

When this is working for you, the fun part starts. Telling Apache how to use mod_authnz_external. In theory you just need to load it and explicitly use it in a part. But in reality it depends on other authz/authn modules and conflicts with others. Again not fun to debug. After a long period of trail and error I got it working. Comment out ALL authn/authz modules and load only these:

LoadModule auth_sys_group_module libexec/apache22/mod_auth_sys_group.so
LoadModule authnz_external_module libexec/apache22/mod_authnz_external.so
LoadModule auth_basic_module libexec/apache22/mod_auth_basic.so
LoadModule authz_host_module libexec/apache22/mod_authz_host.so

Now you can use it in your virtual host definitions. An important fact is that you need to redefine the external provider in every virtual host entry as it will not be inherited from the root node.

<VirtualHost  *:80>
  DocumentRoot "/usr/local/www/example.com/htdocs" 
  ServerName example.com

  <Directory "/usr/local/www/example.com/htdocs">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>

  <Location />
    SSLRequireSSL
    AuthType Basic
    AuthName "Restricted" 
    AuthBasicProvider external
    AuthExternal pwauth
    require valid-user
    require group my_group
  </Location>

  AddExternalAuth pwauth /usr/local/bin/pwauth
  SetExternalAuthMethod pwauth pipe
</VirtualHost>

The important entries are the external provides definition with name of “pwauth” just before the closing VirtualHost and the “AuthBasicProvider external && AuthExternal pwauth” inside the Location.

This finally works as wanted. I still can not believe that UNIX auth is so hard with Apache 2.2.

With SSL and mod_dav_svn the virtual host looks like this:

<VirtualHost _default_:443>
  DocumentRoot "/usr/local/www/example.com/htdocs" 
  ServerName example.com:443

  <Directory "/usr/local/www/example.com/htdocs">
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>

  SSLEngine on

  SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

  SSLCertificateFile /etc/ssl/certs/cert.pem
  SSLCertificateKeyFile /etc/ssl/private/cert.key

  SSLOptions +StdEnvVars +OptRenegotiate

  BrowserMatch ".*MSIE.*" \
      nokeepalive ssl-unclean-shutdown \
      downgrade-1.0 force-response-1.0

  <Location />
    SSLRequireSSL
    DAV svn
    SVNPath /usr/local/svn/my_repo
    AuthType Basic
    AuthName "Restricted" 
    AuthBasicProvider external
    AuthExternal pwauth
    require valid-user
    require group my_group
  </Location>

  AddExternalAuth pwauth /usr/local/bin/pwauth
  SetExternalAuthMethod pwauth pipe
</VirtualHost>

 

Berlin Ruby User Group presentation

Posted by Jonathan

Last week I gave a short presentation on our Rails setup at MeinProf.de and Peritor and how we scale Rails at the Berlin Ruby User Group meeting.

You can get the slides here.

I was surprised to see so many people at the meeting and I look forward to the next meeting. We are also starting to build a task force that will organize some thing for the RailsConf Europe 2007 in Berlin.

OpenBSD 4.1 is there!

Posted by Jonathan

At least if you ordered the pre-release…

My OpenBSD 4.1 CD set and T-shirts arrived today.

The lyrics and the 4.1 song (MP3 4.1MB / OGG 8.3MB) are already up.

The offical release will be at the beginning of May but you can order OpenBSD 4.1 today.

A list of changes between OpenBSD 4.0 and 4.1 can be found here. One very nice addition in my opinion is hoststated(8), a host status daemon that can be used with PF to manage load-balanced servers and remove servers from the pool if they do not serve a HTTP page or your specific monitor script fails.

This is a very interesting for people like me who use OpenBSD firewalls in front of Rails applications. With OpenBSD/PF/pfsync/hoststated you can very easily have redundant firewalls load-balance your Apaches and automatically exclude a host that is down for whatever reason.

OpenBSD - Only *two* remote holes in the default install, in more than 10 years!

Posted by Jonathan

Yes, there is now a second remote hole in OpenBSD. In the last 10 years there was only one, yesterday Theo de Raadt posted the second one (discovered by Core Security Technologies) to misc@openbsd.org. The vulnerability involves a mbuf remote kernel buffer overflow in the IPv6 code.

So you should patch immediately if you use IPv6 or disable it through PF (as it is enabled by default):

block in inet6 

Apart from that the upcoming 4.1 release (“Puffy Baba & the 40 Vendors”) release is available for pre-order.

Creating FreeBSD ports for ruby gems

Posted by Jonathan

Creating FreeBSD ports for ruby gems involves creating a pkg-plist that lists all files and directories for a given port. This kind of sucks for gems that have a lot of rdoc documentation (like ActiveSupport). There are a couple of automatic solutions like pkg_trackinst but none is perfect.

While updating the ports for Rails 1.2.1 I had enough and created a small Ruby script to help with the generation of pkg-plists. Updating a Rubygem port now looks like this:

# cd /usr/ports/devel/rubygem-activesupport
# vim Makefile
(update PORTVERSION)
# make makesum

At first update the port version and create the new checksum. Now install the new version (without updating the pkg-plist, so will will get a lot of errors during deinstall).

# make install

Now run the script to generate the new pkg-plist out of the installed gem:

# /tmp/gen_plist.rb activesupport-1.4.0 > pkg-plist

The script assembles a pkg-plist of of all files and directories under /gems and /doc. Any other files like the rails executable for the Rails gem must be added by hand as they will not be installed under /usr/local/lib/ruby/gems/1.8/.

What’s left to do now is to cleanup manually the installation and test the pkg-plist through creating a package and deinstalling the port.

The small script looks like this:

#! /usr/bin/env ruby  

package_name = ARGV[0]

raise ArgumentError if (package_name.nil? || package_name == '')

prefix = "/usr/local" 
gem_lib_dir = "#{prefix}/lib/ruby/gems/1.8/gems/#{package_name}" 
gem_doc_dir = "#{prefix}/lib/ruby/gems/1.8/doc/#{package_name}" 

pkg_plist = ["%%GEM_CACHE%%", "%%GEM_SPEC%%"]

# add lib
lib_files = `find #{gem_lib_dir} -type f`.split("\n")
lib_dirs = `find #{gem_lib_dir} -type d`.split("\n").reverse
lib_dirs = lib_dirs.collect{|d| "@dirrm #{d}"}

# add doc
doc_files = `find #{gem_doc_dir} -type f`.split("\n")
doc_dirs = `find #{gem_doc_dir} -type d`.split("\n").reverse
doc_dirs = doc_dirs.collect{|d| "@dirrm #{d}"}

# assemble
pkg_plist += lib_files + doc_files + lib_dirs + doc_dirs

# change PLIST_SUBs
pkg_plist.each do |line|
  line.gsub!(gem_doc_dir, "%%GEM_DOC_DIR%%")
  line.gsub!(gem_lib_dir, "%%GEM_LIB_DIR%%")
end

# print out pkg-plist
pkg_plist.each do |line|
  puts line
end

Mongrel and Rails behind Apache 2.2 and SSL

Posted by Jonathan

For a new project of mine we needed to operate Rails with HTTPS. Our setup is the same as I described in an earlier article about Mongrel and Apache 2.2 mod_proxy_balancer, so we have Apache 2.2 in front of a cluster of Mongrels.

After the initial plain HTTP setup was working fine we went on to configure HTTPS. The obvious way is to configure an Apache SSL virtual host, that proxies all requests to the Mongrel cluster (for more on how to setup the Mongrel cluster look here).

<VirtualHost _default_:443>
ServerName www.example.com:443
ServerAdmin webmaster@example.com
TransferLog /var/log/www/www.example.com/apache_ssl_transfer_log
ErrorLog /var/log/www/www.example.com/apache_ssl_error_log
CustomLog /var/log/www/www.example.com/apache_ssl_access_log combined

ProxyPass / balancer://mongrelcluster/
ProxyPassReverse / balancer://mongrelcluster/

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/example.crt
SSLCertificateKeyFile /etc/ssl/private.key

<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog /var/log/httpd-ssl_request.log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" 
</VirtualHost>

This setup works fine until you initiate an internal redirect in your rails code like this:

redirect_to :action => 'list'

As Rails does not know that is behind an HTTPS proxy it creates a redirection to a HTTP resource. This breaks your security and e.g. results in IE complaining about unsafe file transmission on POSTs. James Duncan Davidson has a nice solution for this annoyance.

The solution is to tell Rails that it is operated in HTTPS mode without breaking the development environment. This can be done by setting an environment variable with Apache in the request and checking for this variable in a before filter. If this variable is set, redirect to HTTPS resources. Otherwise use plain old HTTP.

In order to set an environment variable in Apache, include the following line in the SSL virtual host definition:

RequestHeader set X_ORIGINAL_PROTOCOL 'https'

Now create a before_filter in the ApplicationController that checks for this variable:

before_filter :set_ssl
...

def set_ssl
  if request.env.has_key? 'HTTP_X_ORIGINAL_PROTOCOL'
    if request.env['HTTP_X_ORIGINAL_PROTOCOL'] == "https" 
      request.env["HTTPS"] = "on" 
     end
  end
end

request.env[“HTTPS”] = “on” tells Rails to consider the request as an HTTPS request and therefore generate redirects that obey this.

One thing to watch out for is that the variable gets a “HTTP_” prefix set by Apache. So we set the variable “X_ORIGINAL_PROTOCOL” but check for “HTTP_X_ORIGINAL_PROTOCOL”.

Knowing this can save you some hours of debugging…


UPDATE:
After poking around in the ActionController sources there seems to be a much better and easier way. Just set this variable (in httpd.conf) and delete the before_filter:

RequestHeader set X_FORWARDED_PROTO 'https'
Rails will figure out the rest itself. The magic comes from these lines in request.rb:
def ssl?
      @env['HTTPS'] == 'on' || @env['HTTP_X_FORWARDED_PROTO'] == 'https'
end

OpenBSD 2006 Hackathon - c2k6

Posted by Jonathan

The OpenBSD c2k6 Hackathon is currently in progress in Calgary, Canada. The first outputs are

Timedelta sensors for OpenNTPD

A new SD card driver

Further KernelTrap.org has a nice introduction of some OpenBSD developers at the Hackathon. Many of the developers also talk about their goals for the Hackathon.

Some photos can be found here.

UPDATE:
HP donated gear for the Hackathon. One of the machines has 24GB RAM and is used for the SCSI development.

BSDCan 2006 slides

Posted by Jonathan

BSDCan is a BSD-centric conference in Canada. The slides from May 12 -13 2006 are now available here.

I found the following presentations very interesting:

jemalloc – A Scalable Concurrent malloc(3) Implementation for FreeBSD

Proactive Wireless Networks With OpenBSD – WLAN Support In OpenBSD

Mobile IPv6 in FreeBSD

Improving TCP/IP Security Through Randomization Without Sacrificing Interoperability

Also interesting are Robert Watson’s UPDATE:
While we are at BSD slides/taks, check out
BAFUG archive.

Scaling Rails with Apache 2.2, mod_proxy_balancer and Mongrel

Posted by Jonathan

Unitl this week we used Lighttpd and FastCGI for MeinProf.de. The setup was nearly the same as described in the must read series scaling rails (1, 2, 3, 4) from poocs.net.

We used this setup from day 1 but always had some small issues with Lighttpd. Lighttpd was crashing every couple of days. Nothing dramatic, we had a script that monitored Lighttpd and restarted it if necessary. During the last weeks Lighttpd started to crash once a day and lately even once an hour. This was unacceptable and as we knew that we were going to get some serious press coverage in Germany we looked for alternatives.

43people and Basecamp use Apache 1.3 and FastCGI so this seemed like a good alternative. Just switch the webserver and we would be done. Unfortunately Apache 1.3 cannot loadbalance the FastCGI request and there is very little documentation on Apache 1.3 and remote FastCGI processes. Apache 2.0 is no better and has problems with mod_fastcgi. We needed remote FastCGI listeners as our hardware is quite old and we have many slow machines as opposed to a few fast ones that could use local FastCGI to handle the load.

Enter Mongrel.

Mongrel is a fast HTTP library and server for Ruby that is intended for hosting Ruby web applications of any kind using plain HTTP rather than FastCGI or SCGI. It is framework agnostic and already supports Ruby On Rails, Og+Nitro, and Camping frameworks.

With Mongrel your application server becomes a webserver that speaks HTTP so you “only” need to loadbalance and proxy normal HTTP request to it. Mongrel was stable during our tests so we looked for the HTTP proxy solution. Apache had always mod_proxy and could therefore proxy HTTP requests but we needed to loadbalancer these. The are extra packages for this kind of stuff like Balance but we wanted something more integrated and didn’t want to introduce more components.

Enter Apache 2.2 and mod_proxy_balancer.

Apache 2.2 introduced a new proxy module, mod_proxy_balancer. This module does exactly this, it balances proxy requests. You can define a cluster of proxies and use this cluster in your mod_proxy statement instead of just one proxy server.

With this setup we use Apache 2.2 to handle all incoming requests. Apache 2.2 uses mod_proxy to redirect the incoming HTTP requests to the mod_proxy_balancer cluster. The cluster consists of several Mongrel processes on each application server (and now also internal web server) and distributes the requests.

mod_proxy_balancer is more configurable that Lighttpd’s mod_fastcgi. For example you can specify load factors or routes for each cluster member. See the documentation for details.

Our httpd.conf looks like this:

First you define the cluster and tell it of which members it is composed of.

<Proxy balancer://myclustername>
  # cluster member 1
  BalancerMember http://192.168.0.1:3000 
  BalancerMember http://192.168.0.1:3001

  # cluster member 2, the fastest machine so double the load
  BalancerMember http://192.168.0.11:3000 loadfactor=2
  BalancerMember http://192.168.0.11:3001 loadfactor=2

  # cluster member 3
  BalancerMember http://192.168.0.12:3000
  BalancerMember http://192.168.0.12:3001

  # cluster member 4
  BalancerMember http://192.168.0.13:3000
  BalancerMember http://192.168.0.13:3001
</Proxy>

Then you proxy the location or virtual host to the cluster:

<VirtualHost *:80>
  ServerAdmin info@meinprof.de
  ServerName www.meinprof.de
  ServerAlias meinprof.de
  ProxyPass / balancer://meinprofcluster/
  ProxyPassReverse / balancer://meinprofcluster/
  ErrorLog /var/log/www/www.meinprof.de/apache_error_log
  CustomLog /var/log/www/www.meinprof.de/apache_access_log combined
</VirtualHost>

The slash at the end of the ProxyPass directive is very important.

Mongrel itself is startet on the cluster nodes like this:

# mongrel_rails start -d -e production -p 3000
# mongrel_rails start -d -e production -p 3001

Another nice feature of mod_proxy_balancer is the balancer-manager. It is a web interface to the configuration of the mod_proxy_balancer cluster through which you can query or edit your cluster nodes without the need to restart Apache.

In order to use balancer-manager include this in your configuration:

<Location /balancer-manager>
  SetHandler balancer-manager
</Location>

Of course you should protect this location through Apache’s require valid-user or Allow from directives.

So far this solution has proven much more stable (at least on FreeBSD) and was able to handle our peak traffic of 350.000 page request per day. In practice we use up to 8 Mongrel processes on each cluster node and it seems that Apache is the bottleneck and not our application servers as before. The next step for us is to introduce another web server that handles the incoming HTTP requests and has it’s own Mongrel cluster.

Stop the BLOB!

Posted by Jonathan

Finally here:

OpenBSD 3.9


UPDATE:
OpenBSD 3.9 is now officially released and avaliable through FTP.


Rails 1.1.1 and script.aculo.us 1.6.1 released

Posted by Jonathan

Rails 1.1.1 was just released!

I was waiting with upgrading the FreeBSD port as Rails 1.1 had some issues and 1.1.1 was in the planning. I hopefully have the port updated be the end of the weekend. The upgrade to Rake 0.7 is already submitted.

Further script.aculo.us 1.6.1 was also released some minutes ago. It includes Protoype 1.5.0_rc0 and fixed some ugly IE bugs.

Have fun with all the upgrades.

Rails on FreeBSD

Posted by Jonathan

I’ve updated the Rails port to include optional dependencies on ruby-fcgi and memcache-client:

In order to get a Rails installation with FastCGI, MemCache-Client and native MySQL/PostgreSQL/SQLite support just do:

# cd /usr/ports/www/rubygem-rails
# make install clean

That’s it!

Better Support for ActiveRecord in the Ports Tree

Posted by Jonathan

Roderick van Domburg sent me a patch for the ActiveRecord FreeBSD port that lets you choose to depend on the native MySQL bindings.

I’ve updated the patch to support PostgreSQL and SQLite3 too. When you now install ActiveRecord or Rails through the FreeBSD ports tree you will see this screen:

You can choose support for the native bindings. The ports tree will install them for you and will remember the dependencies. If you want to change these settings just re-configure the port:

# cd /usr/ports/databases/rubygem-activerecord
# make config

I’m thinking about adding such options for www/rubygem-rails so that it can depend on www/ruby-fcgi. My goal is to get installing Rails on FreeBSD very easy.

Upgrading ports and preserve make options

Posted by Jonathan

FreeBSD uses make options while building ports in order to build a certain extension or (de)activate certain features.

MySQL 4.1 for example can be build with the following options:

WITH_CHARSET=charset
WITH_XCHARSET=list
WITH_COLLATION=collate
WITH_OPENSSL=yes
WITH_LINUXTHREADS=yes
WITH_PROC_SCOPE_PTH=yes
BUILD_OPTIMIZED=yes
BUILD_STATIC=yes
WITHOUT_INNODB=yes
WITH_NDB=yes

There are two ways of utilizing these options. If the port uses OPTIONS in the Makefile, you can configure the options with

# cd /usr/ports/databases/mysql41-server
# make config

You will get an ncurses screen from which you can choose your options. Your configuration will be saved in /var/db/ports/PORTNAME/options and each time you build this port you get the same options. Reconfiguration is done through calling make config in the port directory again.

But many ports do not use the OPTIONS framework in their Makefiles. MySQL for example does not.

If you want to use some of the build options you have to do it like this:

# cd /usr/ports/databases/mysql41-server
# make -DBUILD_OPTIMIZED install clean

The problem is that you build options are not saved. So when you have to update MySQL, you can’t just use portupgrade -a because your options will be lost. You have to upgrade MySQL yourself (make && make deinstall && make install clean) and remember to use all your options again.

The author of portupgrade though of this problem and introduced /usr/local/etc/pkgtools.conf. With pkgtools.conf you can specify arguments that portupgrade uses while upgrading a port.

MAKE_ARGS = {
# a) Separate them with the space
‘databases/mysql41-’ => ‘WITH_LINUXTHREADS=1 BUILD_STATIC=1’,

# b) Specify them using an array
‘databases/mysql41-
’ => [
‘WITH_LINUXTHREADS=1’,
‘BUILD_STATIC =1’,
],
}

So you just edit all your ports with the correct build options here and you’re done right? No.

Only portupgrade will use this file so if you happen to build any of the ports yourself, your options are not used. And worse, if a port gets updated THROUGH portupgrade as a dependency of another port, the options will NOT BE USED by portupgrade.

So the only solution left is to use /etc/make.conf. In /etc/make.conf you can specify global make options.

CPUTYPE?= pentium3
CFLAGS= -O2 -mmmx -msse -pipe
COPTFLAGS= -O2 -pipe
WITHOUT_X11=yes
WITHOUT_GUI=yes

The problem with this approach is that these options will be set in every make invocation. So all my ports are build without a GUI and without X11 if this options exists in their Makefiles.

So the correct solution is to conditionally set the make variables in /etc/make.conf because I want BUILD_STATIC only set if the mysql port is compiled. You can do this with checking the CURDIR make variable that points to the current directory:

.if ${.CURDIR:M/databases/mysql}
BUILD_STATIC=yes
BUILD_OPTIMIZED=yes
WITH_LINUXTHREADS=yes
.endif

Now every time make is called in databases/mysql41-server (or better in databases/mysql* so that if I compile the client or decide to move to MySQL 5, the options are still set) make will have my options set. Even if you use portupgrade everything works as portupgrade just calls make.

Not pretty but the only real solution if you want to preserve make options through upgrades automatically.

FreeBSD news

Posted by Jonathan

Variant Symlinks

Andrey V. Elsukov ported the variant symlinks from DragonFlyBSD to FreeBSD. Variant symlinks are symlinks with variables in them and when you access the symlinks the variables are replaced with their contents. The variables can be set per-process, per-user, or per-system.

An example can be found here and the patchset for CURRENT can be found here. This is not commited yet.

New malloc commited to CURRENT

libc’s malloc(3) implementation has been replaced with Jason Evans’ newer version that should be faster for SMP systems. For now, all debugging, sanity, and statistics gathering options are enabled in order to find any problems. So your programs will run slower and willl have a larger memory footprint until debugging is disabled.

Ruby 1.8.4 testers wanted

The update to Ruby 1.8.4 is pending and testers are wanted. The patch (get it here) requires some testing as the last update (to Ruby 1.8.3) was rolled back due to plist issues. After the 1.8.4 update, Pav Lucistnik wants to phase out Ruby 1.6 support.

Security Advisories

Four security advisories were released (1,2,3,4). The most serious one affects ipfw as ICMP IP fragments can crash the firewall.

(There are also two security fixes and two reliability fixes for OpenBSD, check the errata for details)

Call for FreeBSD Status Reports

Max Laier called for the FreeBSD status reports. The reports are due on January 20th and the report will be published shortly afterwards.


UPDATE:
Ruby 1.8.4 is now in the tree.


UPDATE 2:
There is another security advisory for FreeBSD about a IEEE 802.11 buffer overflow. Details here.