[Pdx-pm] anyone using IPTables::IPv4?

Roderick A. Anderson raanders at acm.org
Fri Jun 2 08:58:41 PDT 2006


Michael Rasmussen wrote:
> Chris Dawson wrote:
> 
>>Is anyone on this list using the iptables interface for perl?  Or,
>>anyone who prefers just shelling out to the iptables binary?  If you
>>have preferences, I would like to hear them.

Well I've been thinking of getting fut installed on the systems that 
currently use 'denyhosts.py'

This was the kick I needed so I tried.  IPTables::IPv4 fails to install 
on two Fedora Core systems -- 1 and 4.  Most ( all? ) of the tests fail. 
  I attempted using perl -MCPAN -e shell.
    I doubt installing from the tarball will have better results.

> I am. I implemented it as a point of pride, "Real Men Don't Shell Out When
> They Have a Module To Use," kind of thing.

Typically I try ( for awhile anyway ) to beat the process into 
submission using a brute force method.  This hurts!  So what would be a 
_more sophisticated_ procedure to get this done?

FYI the start of the tests looks like this

make[1]: Leaving directory `/root/.cpan/build/IPTables-IPv4-0.98/modules'
PERL_DL_NONLAZY=1 
IPT_MODPATH=/root/.cpan/build/IPTables-IPv4-0.98/modules /usr/bin/perl 
"-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 
'blib/arch')" t/*.t
t/00save_current_ruleset....Useless use of a variable in void context at 
/root/.cpan/build/IPTables-IPv4-0.98/blib/lib/IPTables/IPv4.pm line 5.
Use of uninitialized value in <HANDLE> at 
/root/.cpan/build/IPTables-IPv4-0.98/blib/lib/IPTables/IPv4/Toplevel.pm 
line 50.
readline() on unopened filehandle at 
/root/.cpan/build/IPTables-IPv4-0.98/blib/lib/IPTables/IPv4/Toplevel.pm 
line 50.
Use of uninitialized value in ref-to-glob cast at 
/root/.cpan/build/IPTables-IPv4-0.98/blib/lib/IPTables/IPv4/Toplevel.pm 
line 52.
skipped
         all skipped: no reason given


And ends like this

Failed Test        Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/01simple_manip.t    1   256    14   27 192.86%  1-14
t/03admin.t           1   256    45   89 197.78%  1-45
t/03modules.t         1   256    11   21 190.91%  1-11
t/04append.t          1   256    20   39 195.00%  1-20
t/05insert.t          1   256    28   55 196.43%  1-28
t/07flush.t           1   256     9   17 188.89%  1-9
t/08replace.t         1   256    10   19 190.00%  1-10
t/14badtarget.t       1   256     7   13 185.71%  1-7
t/15manyrules.t       1   256    29   57 196.55%  1-29
t/16manyrules2.t      1   256    20   39 195.00%  1-20
t/18rename.t          1   256    17   33 194.12%  1-17
t/19listports.t       1   256     7   13 185.71%  1-7
t/24delete.t          1   256    19   37 194.74%  1-19
t/56speed.t           1   256     7   13 185.71%  1-7
t/59numberproto.t     1   256     2    3 150.00%  1-2
2 tests skipped.
Failed 15/17 test scripts, 11.76% okay. 245/245 subtests failed, 0.00% okay.
make: *** [test_dynamic] Error 255
   /usr/bin/make test -- NOT OK
Running make install
   make test had returned bad status, won't install without force

I have my big stick out and I'm going to use it for a bit longer.  If 
anyonw has suggestions or ideas please let me know.

Rod
-- 
> 
> Both can work, the iptables interface is arguably more trouble than it's worth
> - for instance you need to go to the iptables API documentation to understand
> how to do some things.  On my todo list is proving out a suspected memory leak in it.
> 
> You may recall my PLUG AT presentation from February, the iptables interface
> was the thing that "didn't work".  After that talk I did complete (and correct, 
> and debug) the program I talked about that night.  The same program that had
> been working in a shell-out-to-the-binary method for over a year. 
> 



More information about the Pdx-pm-list mailing list