Discussion:
[rancid] Rancid 3.2 RHEL6 compatibilities with Socket module.
Brown, David M JR
2015-06-01 20:50:31 UTC
Permalink
We’ve had several requests to get the updated version of rancid on RHEL 6. However, there seems to be some issues getting that to work with the older version of the Socket module.

https://bugzilla.redhat.com/show_bug.cgi?id=1224143

The patch ftp://ftp.shrubbery.net/pub/rancid/rancid-3.2.p3.gz seems to be the supported resolution though it does prevent rancid 3.2 from running on RHEL 6, out of the box.

The patch in the bug suggests using the Socket6 module and pulling the relevant names which seems to have a working version. Would it be possible to use Socket6 instead of Socket for inet_pton()?

Thanks,
- David Brown
Robert Drake
2015-06-02 01:50:56 UTC
Permalink
Not speaking for anyone but myself.

FWIW, this is code from spamassassin:

my $ip6 = eval {
require Socket;
Socket->VERSION(1.95);
Socket->import( 'inet_pton' );
1;
} || eval {
require Socket6;
Socket6->import( 'inet_pton' );
1;
};

Normally I would say use NetAddr::IP or another library to avoid the
inet_pton call, but I found this note:

# ipaddrval(IPaddr) converts and IPv4/v6 address to a string for comparison.
# Some may ask why not use Net::IP; performance. We tried and it was
horribly
# slow.

If performance is a major concern I would make minor changes to the
existing code (sorry for the formatting):

if ($a =~ /:/) {
my($l);
($a, $l) = split(/\//, $a); # this split works even if the slash
isn't there
$l ||= 128; # if !defined is faster than if (/\//)

$norder = inet_pton(AF_INET6, $a);
return unpack('H128', $norder) . unpack('H', pack('C', $l));
}

I don't think this sacrifices readability but it improves the
performance (by about 30-40k calls/s). The regex and split string
operations are almost always the most expensive aspect and if there were
ways to get rid of them then the speed would go way up. Honestly
inet_pton is low level but it's the best way to get speed out of IP
operations (because it's just wrapping a C function).

Drawbacks: RHEL6 (or anything older than 2009 running perl5.10.x) don't
have inet_pton. Socket.pm also doesn't support MSWin32 until 2.019,
which hasn't been shipped yet with any version of perl (so inet_pton
isn't available on any windows systems without workarounds. I have no
idea if anyone runs rancid on windows though, or if that would be possible)

Suggested workarounds: It's a minor change. I'm not sure if Redhat
uses a system like Debian's quilt for maintaining downstream patches,
but I would just put together a changeset for the 3 lines and repackage
it rather than forcing the change upstream. The reason being that
although this is minor, changing it causes documentation headaches
(well.. a comment saying why it is the way it is) and doesn't give a
sunset clause to it. If it's maintained in downstream then as soon as
RHEL6 support is dropped the packages stop being produced and that is
the sunset of the changes.

Yeah, I've probably spent more time whining in this email than it would
take for whoever to fix it, but what if there are other 5.12 features
they turn on later and then need to turn off because someone still runs
5.10?

Robert
Post by Brown, David M JR
We’ve had several requests to get the updated version of rancid on
RHEL 6. However, there seems to be some issues getting that to work
with the older version of the Socket module.
https://bugzilla.redhat.com/show_bug.cgi?id=1224143
The patch ftp://ftp.shrubbery.net/pub/rancid/rancid-3.2.p3.gz seems to
be the supported resolution though it does prevent rancid 3.2 from
running on RHEL 6, out of the box.
The patch in the bug suggests using the Socket6 module and pulling the
relevant names which seems to have a working version. Would it be
possible to use Socket6 instead of Socket for inet_pton()?
Thanks,
- David Brown
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo/rancid-discuss
heasley
2015-06-05 21:07:11 UTC
Permalink
Post by Robert Drake
Not speaking for anyone but myself.
my $ip6 = eval {
require Socket;
Socket->VERSION(1.95);
Socket->import( 'inet_pton' );
1;
} || eval {
require Socket6;
Socket6->import( 'inet_pton' );
1;
};
Normally I would say use NetAddr::IP or another library to avoid the
# ipaddrval(IPaddr) converts and IPv4/v6 address to a string for comparison.
# Some may ask why not use Net::IP; performance. We tried and it was
horribly
# slow.
If performance is a major concern I would make minor changes to the
if ($a =~ /:/) {
my($l);
($a, $l) = split(/\//, $a); # this split works even if the slash
isn't there
$l ||= 128; # if !defined is faster than if (/\//)
$norder = inet_pton(AF_INET6, $a);
return unpack('H128', $norder) . unpack('H', pack('C', $l));
}
that doesn't handle /0 properly. this does:

($a, $l) = split(/\//, $a);
if (!defined($l)) {
$l ||= 128;
}

the difference in speed/efficiency is tiny (on 13M of acls). Net::IP was
utterly haneous; seemingly in perl's object handling mess.
Post by Robert Drake
I don't think this sacrifices readability but it improves the
performance (by about 30-40k calls/s). The regex and split string
operations are almost always the most expensive aspect and if there were
ways to get rid of them then the speed would go way up. Honestly
inet_pton is low level but it's the best way to get speed out of IP
operations (because it's just wrapping a C function).
Drawbacks: RHEL6 (or anything older than 2009 running perl5.10.x) don't
have inet_pton. Socket.pm also doesn't support MSWin32 until 2.019,
which hasn't been shipped yet with any version of perl (so inet_pton
isn't available on any windows systems without workarounds. I have no
idea if anyone runs rancid on windows though, or if that would be possible)
Suggested workarounds: It's a minor change. I'm not sure if Redhat
uses a system like Debian's quilt for maintaining downstream patches,
but I would just put together a changeset for the 3 lines and repackage
it rather than forcing the change upstream. The reason being that
although this is minor, changing it causes documentation headaches
(well.. a comment saying why it is the way it is) and doesn't give a
sunset clause to it. If it's maintained in downstream then as soon as
RHEL6 support is dropped the packages stop being produced and that is
the sunset of the changes.
I agree with that; if they insist upon using ancient versions, then ....
hrm.

Loading...