[Fixed in 1.5.1] NetXMS Import

Unimus support forum
User avatar
lweidig
Posts: 31
Joined: Fri Jan 12, 2018 4:43 pm

Fri Jan 12, 2018 4:45 pm

We would like to create a user within NetXMS simply for the import process to Unimus. Can you tell me the minimum required permissions for the account so that it is able to perform the necessary functions. Thanks!
User avatar
Tomas
Posts: 1206
Joined: Sat Jun 25, 2016 12:33 pm

Fri Jan 12, 2018 4:53 pm

Hi,

The user used for sync doesn't need any System Rights at all.

It only needs access to the containers configured for sync, and all the objects in those containers which should be synced.
For the containers and objects, only "Read" access right is required.
User avatar
lweidig
Posts: 31
Joined: Fri Jan 12, 2018 4:43 pm

Sat Jan 13, 2018 4:33 am

Excellent, that is great that very little permissions are needed. Next, how do we specify the container names? We have something like:

Code: Select all

Infrastructure Services
  |
  |-Device Types
    |
    |- Access Points
      |
      |- Mikrotik
      |- Cambium
      |- Ubiquiti
    |- Routers
      |- Mikrotik
      |- Cisco
...
If we want to specify Infrastructure Services->Routers->Mikrotik how do we do this? Just putting Mikrotik would seem to give us bot the routers and the Access Points containers. Couple of options:

1. Is there a way to show this hierarchy?
2. Can we just specify the object id, which is of course unique somehow?


Thanks!
User avatar
Tomas
Posts: 1206
Joined: Sat Jun 25, 2016 12:33 pm

Sat Jan 13, 2018 12:12 pm

I would recommend creating one container in NetXMS called for example 'Unimus sync'.
For that container, setup auto-bind rules to have all devices bound to that container you want to be synced to Unimus.

Then in Unimus, simply specify the 'Unimus sync' container to sync from.

Would that be acceptable?
User avatar
lweidig
Posts: 31
Joined: Fri Jan 12, 2018 4:43 pm

Sat Jan 13, 2018 1:26 pm

That suggestion will of course work, but is a kludge at best. Now every time the auto-bind rules for the other containers change (and yes, that is infrequent) we need to remember to modify the auto-bind rule in this new container as well. Always seems when you have to maintain the same information in multiple locations they get out of sync at some point.

I would prefer either ID, GUID or something similar that could be entered in the Unimus system if there is no way to specify the hierarchy. They would of course both give the exact container and do not change over the life of the system.

Do appreciate the assistance!
User avatar
Tomas
Posts: 1206
Joined: Sat Jun 25, 2016 12:33 pm

Sat Jan 13, 2018 1:33 pm

I agree.

I suggest 2 improvements:
1) allow inputting container IDs (in "#1234" format)
2) allow inputting entire container path (using "Container A/Container B" formatting)

Would that be better?
User avatar
lweidig
Posts: 31
Joined: Fri Jan 12, 2018 4:43 pm

Sat Jan 13, 2018 1:37 pm

Those would both be awesome!
User avatar
lweidig
Posts: 31
Joined: Fri Jan 12, 2018 4:43 pm

Sat Jan 13, 2018 4:12 pm

Until this enhancement can be completed I decided to tackle it on the NetXMS side of things in a way that would not require maintaining the bind rules in two places. Here is the solution:

First, create a filter function as follows which is recursive:

Code: Select all

sub xlInContainers(myNode, containers) {
  parents = GetObjectParents(myNode);
  foreach(parent : parents) {
    foreach(container : containers) {
      if (parent->id == container) {
        return true;
      }
    }
    if (xlInContainers(parent, containers)) {
      return true;
    }
  }
  return false;
}
Then in the bind rules for the "Unimus Sync" container:

Code: Select all

use Filter::xlInclude;

sub main(){
  return xlInContainers($node, %(227));
} 
We prefix all of our includes, functions,... with 'xl' just to avoid collisions in namespace. The "227" is the id of a parent container (which includes multiple sub containers / nodes) that we want to pass over. All of the devices are now part of the new "Unimus Sync" container and it will be maintained automatically. Only maintenance is to update the container array if we create a new container that has objects we want to pass over, but nothing ongoing.

This is what we LOVE about NetXMS. I still think your enhancement is valid though and if not too much work would make a great addition.
User avatar
Tomas
Posts: 1206
Joined: Sat Jun 25, 2016 12:33 pm

Sat Jan 13, 2018 5:31 pm

I implemented the changes to the NetXMS importer.

I have also added a new article on the wiki that should explain all the details:
https://wiki.unimus.net/display/UNPUB/NetXMS+importer

I also updated the 1.6.0 Beta thread with the build that includes the importer updates:
viewtopic.php?f=4&t=264

Could you please test if it behaves as it should, and if the current behavior is sufficient for your needs?

Thanks!
User avatar
lweidig
Posts: 31
Joined: Fri Jan 12, 2018 4:43 pm

Sun Jan 14, 2018 1:09 pm

Is upgrading as simply as replacing the .jar file in /opt/unimus with the new one and restarting? Do not really see any documentation for the upgrade process. Thanks!
Post Reply