Ubuntu 12.04 – How to Reset Iptables to Default Without Locking Out

This would be an I/O-related issue, as the disks and all write activity stops. The kernel and networking stack are running in RAM, thus the server is pingable.

The main things I would check are the system's BIOS/firmware, and the firmware revision of the Smart Array controller on the system. This is a an old ProLiant DL380 G4 (circa 2005), so you either have the onboard Smart Array 6i controller, a Smart Array 641 controller or a Smart Array 6400-series controller.

Can you tell us more?

The rapid load rise is due to processes being blocked waiting for I/O. You don't say what type of application is running on the system, but it seems like you probably have, say, 380+ processes waiting for disk :)

-- edit --

So, I deployed lots of those servers over the years. Do you have access to the firmware? Are you running the HP Management Agents? This will give you more insight into what you need here and get proper drivers in place.

And finally... this is reallllly old gear... Would you consider an upgrade?

See: HP Proliant DL380 G4 - Can this server still perform in 2011?

-- edit --

Try # modinfo cciss and post the result.

[root@MDMarra ~]# modinfo cciss
filename:       /lib/modules/2.6.32-279.14.1.el6.x86_64/kernel/drivers/block/cciss.ko
license:        GPL
version:        3.6.28
description:    Driver for HP Smart Array Controllers
author:         Hewlett-Packard Company
srcversion:     712C176F5D360D8C1166F22

To fully understand how the module work look in the $module_path/firewall/lib/puppet/{type|proider}/* It's all written in Ruby. Even if you don't know the language it's quite straight forward to interpret.

As mentioned in the comment the additional code in your manifest it's a work around so the module works properly. I guess they had some issue to implements all the code directly in the type/provider via ruby. Makes sense to use the default iptables-save functionality, because it's much easier to reload the firewall setting after the restart and it works for most popular linux distributions.

Even if you copy/paste that code it shouldn't affect your current configuration, as long you don't use the resource type in the node default or in the node configuration. For test purpose include this code directly in the testing node. Should produce the same result. Above it's an example:

    Firewall {
      notify => Exec["persist-firewall"],
      before  => Class['my_fw::post'],
      require => Class['my_fw::pre'],
    }

    Firewallchain {
      notify  => Exec['persist-firewall'],
    }

    resources { "firewall":
      purge => true
    }

    firewall { '100 ssh 22':
      port => '22',
      proto => 'tcp',
      action => 'accept',
    }

    firewall { '100 www 80':
      port => '80',
      proto => 'tcp',
      action => 'accept',
    }

    firewall { '100 sql 5436':
      port => '5436',
      proto => 'tcp',
      action => 'accept',
    }

    firewall { '100 sql 5438':
      port => '5438',
      proto => 'tcp',
      action => 'accept',
    }

    firewall { '100 sql 5440':
      port => '5440',
      proto => 'tcp',
      action => 'accept',
    }

    exec { "persist-firewall":
      command => $operatingsystem ? {
        "debian" => "/sbin/iptables-save > /etc/iptables/rules.v4",
        /(RedHat|CentOS)/ => "/sbin/iptables-save > /etc/sysconfig/iptables",
      },
      refreshonly => 'true',
    }

In this example I am allowing 22, 80. 5436, 5438 INCOMING TCP connection.