Send Netdot-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netdot-users digest..."
Today's Topics:
1. arpcache (Chip Marshall)
2. Re: arpcache (Carlos Vicente)
3. Re: arpcache (Chip Marshall)
4. Re: arpcache (Carlos Vicente)
5. CentOS 6.3 odd perl "reload" error (Todd Lyons)
----------------------------------------------------------------------
Message: 1
Date: Fri, 14 Dec 2012 09:34:59 -0500
From: Chip Marshall <[email protected]>
Subject: [Netdot-users] arpcache
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm in the process of upgrading an older 0.9 installation to
1.0.2 (from FreeBSD Ports) and found out that our arpcache and
arpcacheentry tables weren't being pruned, so they have about
120,000 and 5,500,000 entries in them respectively.
This is causing the database schema upgrade to take a long
time, so I figured I'd prune them before converting, and using
prune_db.pl is taking a long time (it's been running for 2
days now.)
Assuming I don't really care about the ARP data at this point,
would it be safe to simply truncate those tables before doing
the conversion? Or would that start me down a rabbit hole of
database issues?
--
Chip Marshall <[email protected]>
http://weblog.2bithacker.net/ KB1QYW PGP key ID 43C4819E
v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20121214/c2383501/attachment-0001.bin
------------------------------
Message: 2
Date: Fri, 14 Dec 2012 12:25:24 -0500
From: Carlos Vicente <[email protected]>
Subject: Re: [Netdot-users] arpcache
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
The script drops the tables and recreates them, which is very fast. I
imagine that it's also trying to delete old IP addresses and MAC
addresses, and since those require removing entries from the ARP and
forwarding tables, it's taking this long.
If you can wait, that would be the safest. If not, I don't think that
stopping it would cause great harm. You might have to restart mysql to
clear the any hung transactions.
Once stopped, you'll have to drop all 4 tables: arpcache,
arpcacheentry, fwtable, fwtableentry, and then create them using the
statements in the etc/schema.mysql file in your install directory. If
you don't have that file any more, you can generate it with 'make
genschema'.
Good luck.
cv
On 12/14/12 9:34 AM, Chip Marshall wrote:
> I'm in the process of upgrading an older 0.9 installation to 1.0.2
> (from FreeBSD Ports) and found out that our arpcache and
> arpcacheentry tables weren't being pruned, so they have about
> 120,000 and 5,500,000 entries in them respectively.
>
> This is causing the database schema upgrade to take a long time, so
> I figured I'd prune them before converting, and using prune_db.pl
> is taking a long time (it's been running for 2 days now.)
>
> Assuming I don't really care about the ARP data at this point,
> would it be safe to simply truncate those tables before doing the
> conversion? Or would that start me down a rabbit hole of database
> issues?
>
>
>
> _______________________________________________ Netdot-users
> mailing list [email protected]
> https://osl.uoregon.edu/mailman/listinfo/netdot-users
>
--
cv
------------------------------
Message: 3
Date: Fri, 14 Dec 2012 13:43:16 -0500
From: Chip Marshall <[email protected]>
Subject: Re: [Netdot-users] arpcache
To: Carlos Vicente <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On 14-Dec-2012, Carlos Vicente <[email protected]> sent:
> Once stopped, you'll have to drop all 4 tables: arpcache,
> arpcacheentry, fwtable, fwtableentry, and then create them using the
> statements in the etc/schema.mysql file in your install directory. If
> you don't have that file any more, you can generate it with 'make
> genschema'.
Thanks, it appears to have worked out okay. I stopped the
prune_db, executed a truncate on each table (wipe the data
without dropping the schema) and ran the upgrade process which
appeared to work well.
One small problem, the upgrades to 0.9.10, 1.0.1, and then 1.0.2
didn't add the datacache table, so I created by hand from the
schema.mysql file.
--
Chip Marshall <[email protected]>
http://2bithacker.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20121214/27f40bd8/attachment-0001.bin
------------------------------
Message: 4
Date: Fri, 14 Dec 2012 14:02:21 -0500
From: Carlos Vicente <[email protected]>
Subject: Re: [Netdot-users] arpcache
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/14/12 1:43 PM, Chip Marshall wrote:
> One small problem, the upgrades to 0.9.10, 1.0.1, and then 1.0.2
> didn't add the datacache table, so I created by hand from the
> schema.mysql file.
>
You probably have a newer SQL::Translator version.
See:
https://osl.uoregon.edu/redmine/issues/1710
- --
cv
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iD8DBQFQy3e9DADXcoYj2ZwRAqeWAJ98pATTWY9+RYbDEDsQ5S1v/7ke0QCfTDTZ
oz4rgi4oR/vX6If9XD950lY=
=WzB1
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Fri, 14 Dec 2012 11:39:49 -0800
From: Todd Lyons <[email protected]>
Subject: [Netdot-users] CentOS 6.3 odd perl "reload" error
To: [email protected]
Message-ID:
<cafg21ohqhcw+j031lnzdj7-pgizyagy_d6zkunrjgjayhta...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hello all,
I followed a recommendation in NANOG to your project and decided to
install it on a CentOS 6.3 OpenVZ container (running under Proxmox
2.2). At the end of this message, I'll go ahead and paste my entire
install script so that maybe you will spot something I did wrong.
Problem: I cannot load the main page. It doesn't get far enough in to
prompt me for a user/password. I get a 403 error, followed by
"Additionally, a 500 Internal Server Error error was encountered while
trying to use an ErrorDocument to handle the request." I think it's
obvious that the 403 is preventing the regular page to load properly.
To fix the 403 I merely have to fix either the Directory access or the
Location access (though to be honest, they look proper to me).
For the 500 ISE, I'm getting a perl error in the error_log:
[Fri Dec 14 22:22:10 2012] [error] ses_key_cookie
[Fri Dec 14 22:22:11 2012] [error] [client 10.1.99.32] failed to
resolve handler `Netdot::Mason': Attempt to reload
Netdot/Model/Ipblock.pm aborted.\nCompilation failed in require at
(eval 366) line 3.\n\t...propagated at /usr/share/perl5/base.pm line
94.\nBEGIN failed--compilation aborted at (eval 365) line 1.\nBEGIN
failed--compilation aborted at /usr/local/netdot/lib/Netdot/Model.pm
line 418.\nCompilation failed in require at
/usr/local/netdot/lib/Netdot/UI.pm line 5.\nBEGIN failed--compilation
aborted at /usr/local/netdot/lib/Netdot/UI.pm line 5.\nCompilation
failed in require at /usr/local/netdot/lib/Netdot/Mason.pm line
21.\nBEGIN failed--compilation aborted at
/usr/local/netdot/lib/Netdot/Mason.pm line 21.\nCompilation failed in
require at (eval 61) line 3.\n
I'm not quite sure what to make of that because tracing through the code:
/usr/local/netdot/lib/Netdot/Mason.pm line 21:
use Netdot::UI;
/usr/local/netdot/lib/Netdot/UI.pm line 5:
use Netdot::Model;
And of course /usr/local/netdot/lib/Netdot/Model.pm line 418 is the
closing brace of the BEGIN block. The error is at "(eval 366) ", and
since the eval begins at line 34, I skipped down to line 366+34, which
is the following that looks like the problem:
# This section will allow us to continue to say
# Table->method instead of Netdot::Model::Table->method.
# This could go away if we decide to change all our
# existing code to use the full class names
foreach my $package ( keys %tables ){
my $table = $tables{$package};
eval "package $table; use base '$package';";
if ( my $e = $@ ){
die $e;
}
}
Any suggestions? It seems like I should be able to do some kind of
check to see if something is already defined and only use base it if
it's not yet loaded/available. I do a fair amount of perl, but I'm
not a plumbing guy. Help?
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
------------------------------
_______________________________________________
Netdot-users mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-users
End of Netdot-users Digest, Vol 49, Issue 12
********************************************
