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 (Matej Vadnjal)
   2. Re: Duplicate asset error message
      (Schroeder, AJ (GE Healthcare, consultant))
   3. Re: RESTful interface questions (Jos? A. Dom?nguez)
   4. Re: RESTful interface questions (Jos? A. Dom?nguez)
   5. Re: RESTful interface questions (Patrick Landry)


----------------------------------------------------------------------

Message: 1
Date: Mon, 11 Feb 2013 08:51:02 +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"

On 08. 02. 2013 23:09, 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.
>
> Unfortunately getting a list of VLANs via the RESTful interface does 
> not provide information about which subnets are associated with the VLANs.
>   (/rest/vlan)
>
> 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?
>
> So far now I am getting all subnet Ipblocks 
> (/rest/ipblock?status=subnet) and searching through those for those 
> associated with vlan 123.
>

Hellp Patrick

You can get a list of subnet IDs associated with a VALN by appending 
linked_from=1 to the request (/rest/vlan/550?linked_from=1).

I do wish however that you could search via REST on more parameters than 
you can do now.

--

Matej Vadnjal
Arnes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20130211/1d820bcb/attachment-0001.html
 

------------------------------

Message: 2
Date: Mon, 11 Feb 2013 14:22:51 +0000
From: "Schroeder, AJ (GE Healthcare, consultant)"
        <[email protected]>
Subject: Re: [Netdot-users] Duplicate asset error message
To: "Jos? A. Dom?nguez"         <[email protected]>,
        "[email protected]"  <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Jose,

Thank you for the help. I was able to track down the duplicate asset using the 
methods you described. It ended up being a couple of FEX that netdot somehow 
felt were tied to the same Nexus switch. These have been on the network quite a 
while and have not changed much.

Either way, things are fixed now.

Thank you for your help,

AJ Schroeder

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of "Jos? A. Dom?nguez"
Sent: Wednesday, January 30, 2013 3:41 PM
To: [email protected]
Subject: Re: [Netdot-users] Duplicate asset error message

On 1/30/13 11:13 AM, Schroeder, AJ (GE Healthcare, consultant) wrote:
> 
> ERROR- Error while updating Asset: Can't update 662: DBD::mysql::st 
> execute
> failed: Duplicate entry '12971' for key 2 [for Statement "UPDATE asset
> SET    physaddr = ? WHERE  id=? " with ParamValues: 0='12971', 1='662'] at
> /usr/lib/perl5/site_perl/5.8.8/DBIx/ContextualFetch.pm line 52.  at 
> /usr/local/netdot/bin/updatedevices.pl line 201
> 

Hi AJ, yeah, we have run into similar issues. It looks like you have two 
devices/assets that have the same key information. Do you know what that 
particular assets are? You should be able to direct sql query for some of the 
details. You can attempt to run updatedevices.pl with debugging turned on (-d) 
and that should point you in the right direction. Basically you have a new 
device that seems to want to use the same asset information as an existing 
device. You can also attempt some direct sql queries on the asset and device 
tables for the referenced ids.

In the end you want to determine which two devices are colliding and see 
whether it is an issue with the way that netdot is handling the assets or a 
misconfiguration on the devices or lingering old data in netdot.

Jos?.




------------------------------

Message: 3
Date: Mon, 11 Feb 2013 06:57:09 -0800
From: "Jos? A. Dom?nguez" <[email protected]>
Subject: Re: [Netdot-users] RESTful interface questions
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

On 2/8/13 2:09 PM, 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.
> 
> Unfortunately getting a list of VLANs via the RESTful interface does not
> provide information about which subnets are associated with the VLANs.
>   (/rest/vlan)
> 
> 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?
> 
> So far now I am getting all subnet Ipblocks (/rest/ipblock?status=subnet)
> and searching through those for those associated with vlan 123.
> 

Hi Patrick, using "/rest/ipblock?vlan=123" is actually look for the VLAN if
DB table record id=123 rather than the VLAN with VLAN id 123. The beauty of
relational databases :-)

You could make two calls to get this done. You can ask for
"rest/vlan?vid=123" then pick up the actual 'id' from that result and then
issue "rest/ipblock?vlan=<id>" where <id> is the id on the previous query
(not the vid).

I think there is another way to do this too but let me look at it in more
detail.

Jos?.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 268 bytes
Desc: OpenPGP digital signature
Url : 
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20130211/42ccf18b/attachment-0001.bin
 

------------------------------

Message: 4
Date: Mon, 11 Feb 2013 10:48:29 -0800
From: "Jos? A. Dom?nguez"       <[email protected]>
Subject: Re: [Netdot-users] RESTful interface questions
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

On 2/10/13 11:51 PM, Matej Vadnjal wrote:
> 
> Hellp Patrick
> 
> You can get a list of subnet IDs associated with a VALN by appending
> linked_from=1 to the request (/rest/vlan/550?linked_from=1).
> 
> I do wish however that you could search via REST on more parameters than
> you can do now.
> 

Matej, that still have the issue that the responses are references to
record ids. If Patrick can handle record id (e.g. you are doing this
programatically) you could issues something like:

/rest/vlan/?vid=123&linked_from=1

and then look at <subnets> and proceed to extract those records.

If your provisioning system uses perl you can take a look at the
Netdot::Client::REST perl module in CPAN and review the help
(https://nsdb.uoregon.edu/help/?page=MANUAL#restful-interface).

And there is a python client here:

https://github.com/frgray/netdot-client-python

Jos?.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : 
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20130211/933396d4/attachment-0001.bin
 

------------------------------

Message: 5
Date: Mon, 11 Feb 2013 13:43:12 -0600 (CST)
From: Patrick Landry <[email protected]>
Subject: Re: [Netdot-users] RESTful interface questions
To: [email protected]
Message-ID:
        <18630762.1912.1360611792302.JavaMail.javamailuser@localhost>
Content-Type: text/plain; charset="utf-8"

----- Original Message -----

> Hi Patrick, using "/rest/ipblock?vlan=123" is actually look for the
> VLAN if
> DB table record id=123 rather than the VLAN with VLAN id 123. The
> beauty of
> relational databases :-)

> You could make two calls to get this done. You can ask for
> "rest/vlan?vid=123" then pick up the actual 'id' from that result and
> then
> issue "rest/ipblock?vlan=<id>" where <id> is the id on the previous
> query
> (not the vid).

> I think there is another way to do this too but let me look at it in
> more
> detail.

Thank you very much! Now that you point it out it makes sense. That will help a 
lot. 

By putting together the responses from here as well as a few references I found 
online I think I can now perform all of the tasks I need. (I am using perl and 
Netdot-Client-REST by the way.) 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. 

I will try to remember to take the time to post some full examples once I get 
everything figured out. 

-- 

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/8219e0a8/attachment.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/8219e0a8/attachment.bin
 

------------------------------

_______________________________________________
Netdot-users mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-users


End of Netdot-users Digest, Vol 51, Issue 2
*******************************************

Reply via email to