I’ve catched some terrible flu last week (around 39.5 of fever most of the week, and all sort of problems that come together with that), so development was going not that fast as I hoped. I finally got better around Friday, and managed to go to Iron Maiden’s show in São Paulo (biggest Iron Maiden show EVER – about 100000 people watching! Amazing!), and also finish some long-time pending tasks.
One of such tasks was the drakfirewall support for NFS. This one was a bit tricky, because it required modifications to nfs-server and nfs-common to enable NFS to listen on fixed ports. My initial idea was to simply put it into nfs-utils configuration files, but this approach was not well-received on cooker list 
. So I went to the second solution – implementing on-the-fly configuration of such ports in drakfirewall. This required some additional (transparent) steps in firewall configuration, but the resulting structure became quite flexible. Right now, drakfirewall configures NFS to use fixed ports automatically, and also detects custom user changes and adapts itself accordingly.
The funniest part of this is that it was the oldest bug in my queue (#7689), dating back to 2004. A blast from the past .
Besides this fix, there were lots of other bugfixes in drakx-net over the last few weeks (14 bugfixes at all, according to the changelog). And also some fixes for pre-historic draknetprofile bugs. The draknetprofile is still horribly broken, and not updated since about 2004 I think, so at some point it will receive the same treatment as msec had.
Speaking of msec, I also moved all pam-related code to pam plugin, continuing the modularization. I also added some ideas for msec for Mandriva’s google SoC page. There is not much left to do to implement everything I had in mind for 2009.1, and probably I’ll finish it over the next few weeks.
On a not-so-bright sight, my assigned bug count right now is of 325 (I also started maintaining iptables, kexec-tools and imagemagick). About 80% of those bugs are related to drakx-net, and about 50% of those drakx-net bugs require specific hardware to test a possible fix for them. As I don’t have the required hardware, nor know anyone who has it, I am still trying to figure out a way to work on them. The most annoying of those bugs is the support for b43-based wireless cards, which require loading two different kernel modules just to be able to see the device. If anyone has any such card, and is able to provide a remote ssh access to a cooker installation, this would be just amazing . Otherwise, I’ll do some guessing on what must be done, and pray for the Holy Penguin to be right .
We have some HPs with b43 here in cwb.
Hi, Great to hear about the NFS support in drakfirewall.. I wrote something similar which basically just run rpcinfo and extracts whatever ports (tcp & udp) are been used by nfs from there and changes a shorewall configuration file (e.g. rules.nfs) accordingly..
It is a shell script run via cron but is capable of dynamically tracking and enabling the NFS server ports..
Please drop me a line if you want to have a look at the script..
ehio: sure, send it to me! I was thinking on doing it this way, but we must use fixed ports for NFS to make sure it works after a reboot. Or we should rewrite the shorewall rules on each boot, possibly twice (shorewall could start before nfs services, and this no ports will be registered in rpcinfo, so shorewall will first open old ports, then we rewrite its config with current settings).
So I just thought that saving those settings the first time NFS firewalling is configured is easier. If the ports are already configured, we just use the values the user specified.