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. Re: RESTful interface questions (Anton Berezin)
2. Re: RESTful interface questions (Patrick Landry)
3. Re: RESTful interface questions (Matej Vadnjal)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Feb 2013 21:36:03 +0100
From: Anton Berezin <[email protected]>
Subject: Re: [Netdot-users] RESTful interface questions
To: Patrick Landry <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Patrick,
On Fri, Feb 08, 2013 at 04:09:02PM -0600, Patrick Landry wrote:
> I am working on integrating Netdot into my provisioning system. When a
> machine is provisioned each network interface is assigned to a VLAN. I
> would then like to use the RESTful interface to obtain an IP address for
> each interface.
> So I can go the ipblock route (/rest/ipblock). Unfortunately when I try to
> select only ipblocks associated with a certain vlan
> (/rest/ipblock?vlan=123) I get "Not Found" and I know VLAN 123 is
> associated with a subnet. Should this work?
Jos? has already explained why this does not work.
It looks like this kind of thing requires coding an explicit support for it.
The patch below is a first try at implementing support for /rest/ipblock?vid=123
requests. It works for me.
Cheers,
\Anton.
diff --git a/lib/Netdot/Model/Ipblock.pm b/lib/Netdot/Model/Ipblock.pm
index 12e01af..9828bba 100644
--- a/lib/Netdot/Model/Ipblock.pm
+++ b/lib/Netdot/Model/Ipblock.pm
@@ -134,6 +134,7 @@ sub search {
my $statusid = $class->_get_status_id($args{status});
$args{status} = $statusid;
}
+ my $build_sql = 0;
if ( defined $args{address} ){
if ( $args{address} =~ /.+\/\d+$/ ){
# Address is in CIDR format
@@ -149,30 +150,40 @@ sub search {
$class->throw_user(sprintf("Address %s does not match valid IP
v4/v6 formats", $args{address}));
}
}
- if ( $class->config->get('DB_TYPE') eq 'mysql' ){
- # Deal with mysql bug
- # http://bugs.mysql.com/bug.php?id=60213
- # We have to build our own query
- my @keys = keys %args;
- my @vals = values %args;
- my $q = join(' AND ', map { "$_=?" } @keys);
- my @cols = ('id');
- my %essential = $class->meta_data->get_column_order_brief;
- push @cols, keys %essential;
- my $cols = join ',', @cols;
- my $dbh = $class->db_Main();
- my $sth = $dbh->prepare_cached("SELECT $cols FROM ipblock WHERE
$q;");
- for my $i (1..scalar(@keys)){
- if ( $keys[$i-1] eq 'address' ){
- # Notice that we force the value to be a string
- $sth->bind_param($i, "".$vals[$i-1], SQL_INTEGER);
- }else{
- $sth->bind_param($i, $vals[$i-1]);
- }
+ # Deal with mysql bug http://bugs.mysql.com/bug.php?id=60213 if needed
+ $build_sql = 1 if $class->config->get('DB_TYPE') eq 'mysql';
+ }
+ $build_sql = 1 if defined $args{vid};
+
+ if ( $build_sql ){
+ # We have to build our own query
+ my @keys = keys %args;
+ my @vals = values %args;
+ my @parts;
+ for my $k (@keys) {
+ if ($k eq "vid") {
+ push @parts, "vlan in (select id from vlan where vid = ?)";
+ } else {
+ push @parts, "$k=?";
+ }
+ }
+ my $q = join ' AND ', @parts;
+ my @cols = ('id');
+ my %essential = $class->meta_data->get_column_order_brief;
+ push @cols, keys %essential;
+ my $cols = join ',', @cols;
+ my $dbh = $class->db_Main();
+ my $sth = $dbh->prepare_cached("SELECT $cols FROM ipblock WHERE $q;");
+ for my $i (1..scalar(@keys)){
+ if ( $keys[$i-1] eq 'address' ){
+ # Notice that we force the value to be a string
+ $sth->bind_param($i, "".$vals[$i-1], SQL_INTEGER);
+ }else{
+ $sth->bind_param($i, $vals[$i-1]);
}
- $sth->execute;
- return $class->sth_to_objects($sth);
}
+ $sth->execute;
+ return $class->sth_to_objects($sth);
}
return $class->SUPER::search( %args, $opts );
}
--
Our society can survive even a large amount of irrational regulation.
-- John McCarthy
------------------------------
Message: 2
Date: Mon, 11 Feb 2013 16:45:57 -0600 (CST)
From: Patrick Landry <[email protected]>
Subject: Re: [Netdot-users] RESTful interface questions
To: [email protected]
Message-ID:
<21451306.2261.1360622753784.JavaMail.javamailuser@localhost>
Content-Type: text/plain; charset="utf-8"
----- Original Message -----
> The patch below is a first try at implementing support for
> /rest/ipblock?vid=123
> requests. It works for me.
Thanks for that. I'll give it a try.
I ran into another issue. When I attempt to create a new DNS record with a
fixed IP address where there is already another DNS record using that IP
address I get an error.
File does not exist: Bad request: Address XX.XX.XX.XX is not available at
/usr/local/share/perl5/Netdot/Client/REST.pm line 203
If I use the web interface to do the same thing th ere is no error.
Again, I am using perl with the Netdot-Client-REST module.
--
patrick
Patrick Landry
University of Louisiana at Lafayette
Director, University Computer Support Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20130211/4c4b19aa/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Landry, Patrick.vcf
Type: text/directory
Size: 11870 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20130211/4c4b19aa/attachment-0001.bin
------------------------------
Message: 3
Date: Tue, 12 Feb 2013 09:58:10 +0100
From: Matej Vadnjal <[email protected]>
Subject: Re: [Netdot-users] RESTful interface questions
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 11. 02. 2013 20:43, Patrick Landry wrote:
> One thing I did find was that in order to update a host you need to
> include the 'name' parameter in the data portion of the POST. Unless
> this is a requirement of the Netdot-Client-REST module only, the
> manual is incomplete in this regard.
Thats odd. It works for me. I tried this:
use Data::Dumper;
use Netdot::Client::REST;
my $netdot = Netdot::Client::REST->new(
server => $location,
username => $user,
password => $pass,
);
my $dev = $netdot->post("device", {
id=>274,
community => 'public2',
});
print Dumper $dev;
Prints:
$VAR1 = {
'id' => '274',
'community' => 'public2',
'monitor_config' => '0',
'monitored' => '0',
'snmp_privkey' => '',
'bgplocalas' => '',
'snmp_bulk' => '1',
'snmp_authprotocol' => '',
'name_xlink' => 'RR/569',
'monitor_config_group' => '',
'snmp_target' => 'xx.xx.xx.xx',
'os' => '',
'bgpid' => '',
'snmp_down' => '0',
'auto_dns' => '1',
'layers' => '',
'sysdescription' => '',
'monitoring_path_cost' => '0',
'canautoupdate' => '0',
'last_updated' => '2013-02-12 09:52:39',
'snmp_privprotocol' => '',
'date_installed' => '2013-02-11 13:42:53',
'stp_enabled' => '0',
'name' => 'testmv4.arnes.si',
'down_until' => '',
'collect_fwt' => '0',
'monitorstatus' => '0',
'rack' => '',
'oobnumber' => '',
'stp_mst_rev' => '',
'syslocation' => '',
'collect_stp' => '0',
'snmp_securitylevel' => '',
'used_by' => '0',
'snmp_target_xlink' => 'Ipblock/18328',
'ipforwarding' => '0',
'owner_xlink' => 'Entity/26',
'room' => '0',
'customer_managed' => '0',
'snmp_polling' => '0',
'sysname' => '',
'stp_mst_digest' => '',
'stp_mst_region' => '',
'last_arp' => '1970-01-02 00:00:01',
'info' => '',
'collect_arp' => '0',
'owner' => 'ARNES',
'extension' => '',
'snmp_authkey' => '',
'snmp_version' => '2',
'down_from' => '',
'stp_type' => '',
'snmp_managed' => '1',
'snmp_securityname' => '',
'site' => '0',
'snmp_conn_attempts' => '0',
'oobname' => '',
'asset_id' => '0',
'aliases' => '',
'last_fwt' => '1970-01-02 00:00:01'
};
--
Matej Vadnjal
Arnes
------------------------------
_______________________________________________
Netdot-users mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-users
End of Netdot-users Digest, Vol 51, Issue 3
*******************************************
