FreeBSD News

I have some good FreeBSD news to report. FreeBSD 5.4-RC3 was announced Monday. Although the schedule still calls for a 26 April release date, I believe we will not see the RELEASE until the first week in May. According to the announcement:

"Due to one major issue that crops up on large (4-processor) systems under heavy load that is still being debugged there will be at least one more RC added to the schedule. Timing for the extra RC and the new Release date have not been set yet."

I am hoping that FreeBSD 5.4 will be the release that convinces 4.x users to upgrade. I have not had any problems running FreeBSD 5.3 since it arrived last November, but others are more cautious.

There's an interesting freebsd-stable thread with several hints on updating systems. This post by Aristedes Maniatis recommends using the following command to preserve access to a system when you accidentally lock yourself out while modifying firewall rules.

echo "ipfw add 1 pass all from any to any" at now +10 minutes

He continues with "Then if all goes OK, use atq to remove the queue item. If not, wait 10 minutes..."

That is great advice. I have heard of "people" locking themselves out of systems while modifying firewall rules.

David Talkington offered an alternative method to avoid lockout -- using IPFW's set 31 feature. From the manual:

set set_number
 Each rule is associated with a set_number in the range 0..31.
 Sets can be individually disabled and enabled, so this parameter
 is of fundamental importance for atomic ruleset manipulation.  It
 can be also used to simplify deletion of groups of rules. 
 If a rule is entered without specifying a set number, set 0
 will be used.
 Set 31 is special in that it cannot be disabled, and rules in set
 31 are not deleted by the ipfw flush command (but you can delete
 them with the ipfw delete set 31 command).  Set 31 is also used
 for the default rule.

Here is how a normal IPFW rule (numbered 5000) is added, say to disable ICMP.

drury:/root# ipfw add 5000 deny icmp from any to any
05000 deny icmp from any to any
drury:/root# ipfw list
05000 deny icmp from any to any
65535 deny ip from any to any

If I flush the rules, only the default allow rule at bottom remains:

drury:/root# ipfw flush
Are you sure? [yn] y

Flushed all rules.
drury:/root# ipfw list
65535 deny ip from any to any

Now I add a set 31 rule. The syntax would be something like this:

drury:/root# ipfw add 10000 set 31 allow ip from 192.168.1.0/24 to any
10000 allow ip from 192.168.1.0/24 to any
drury:/root# ipfw list
10000 allow ip from 192.168.1.0/24 to any
65535 deny ip from any to any

This adds rule number 10000 with set 31. It allows any traffic from a defined subnet. Now I flush the rules and check the results.

drury:/root# ipfw flush
Are you sure? [yn] y

Flushed all rules.
drury:/root# ipfw list
10000 allow ip from 192.168.1.0/24 to any
65535 deny ip from any to any

I can rid myself of the set 31 rule using this method.

drury:/root# ipfw delete 10000 disable 31
drury:/root# ipfw list
65535 deny ip from any to any

On a different subject, Jean Simon mentioned the nextboot utility to specify an alternate kernel after performing an upgrade.