NetXMS Support Forum

Hi,

I played around a lot lately with NetXMS and here's a summary of where I have problems at the moment.
Don't know if they're caused by me or not.

- Creating a new user
  > Objects is completely empty
    > Doesn't matter if I set the permissions manually or if I add the user to an admin group
    > Checked with same permissions as admin user

- Deleting a user and recreating it with the same name
  > Always says the user already exists, but it's not in the user list anymore (also checked with refresh)
  > I need to restart the server to be able to create the user again

- Script library
  > Save button is disabled
    > The only way to save is closing the script and answer the next question with yes

- Edit agent's configuration file
  > Always get "Cannot open agent config: Access denied"
  > Appears on Linux and Windows
  > Other agent stuff works, e.g. software inventory

So that's what I remember

Thanks,
VMGuy

P.S.: Really like this product. Much easier to handle and to configure than others...

Hello.

Quote from: VMGuy on January 13, 2015, 01:33:19 AM
- Creating a new user
  > Objects is completely empty
    > Doesn't matter if I set the permissions manually or if I add the user to an admin group
    > Checked with same permissions as admin user

Login as admin, right click on any object (node / container / object root like "Entire Network" / etc.) in the tree, select properties and set permissions for the user. By default, permissions are propagated to child objects unless you implicitly disable inheritance in object's access control.

Quote from: VMGuy on January 13, 2015, 01:33:19 AM
- Deleting a user and recreating it with the same name
  > Always says the user already exists, but it's not in the user list anymore (also checked with refresh)
  > I need to restart the server to be able to create the user again

That's due to delayed write to the database. It should be synced in under a minute (usually that's just a few seconds), if it stays longer than that - you need to check value of "Database writer's request queue" metric on the server (in Last values)

Quote from: VMGuy on January 13, 2015, 01:33:19 AM
- Script library
  > Save button is disabled
    > The only way to save is closing the script and answer the next question with yes

Works fine for me (OSX). What OS you are using?
My test case was: Open script library, create new script (editor opens, icon is grayed out), type anything - icon becomes active.

Quote from: VMGuy on January 13, 2015, 01:33:19 AM
- Edit agent's configuration file
  > Always get "Cannot open agent config: Access denied"
  > Appears on Linux and Windows
  > Other agent stuff works, e.g. software inventory

Check agent's config file – server IP address should be whitelisted by using "MasterServers" option, all others ("Servers" and "ControlServers") don't have sufficient rights to edit configuration file remotely.

QuoteLogin as admin, right click on any object (node / container / object root like "Entire Network" / etc.) in the tree, select properties and set permissions for the user. By default, permissions are propagated to child objects unless you implicitly disable inheritance in object's access control.

That's the point. There's no "Entire network" or anything else. The only thing that is there is the filter box. It happens on all installations I made with 1.2.16 or 1.2.17.
Now I did a fresh installation of 2.0 and here it works.

QuoteWorks fine for me (OSX). What OS you are using?
My test case was: Open script library, create new script (editor opens, icon is grayed out), type anything - icon becomes active.

I use Windows 7 with Chrome browser.
Same test case, but the save button stays disabled.

QuoteCheck agent's config file – server IP address should be whitelisted by using "MasterServers" option, all others ("Servers" and "ControlServers") don't have sufficient rights to edit configuration file remotely.

In the config file I have (and always had) this:
Servers = 192.168.x.y
ControlServers = 192.168.x.y
MasterServers = 192.168.x.y

But it doesn't work.

Thanks, VMGuy

Quote from: VMGuy on January 13, 2015, 10:23:59 PM

QuoteCheck agent's config file – server IP address should be whitelisted by using "MasterServers" option, all others ("Servers" and "ControlServers") don't have sufficient rights to edit configuration file remotely.

In the config file I have (and always had) this:
Servers = 192.168.x.y
ControlServers = 192.168.x.y
MasterServers = 192.168.x.y

But it doesn't work.

That's new bug introduced in 2.0 - server's access level determined by first statement insted of one with maximum access. If you leave only MasterServers (which implies ControlServers which in turn implies Servers) it will work.

Best regards,
Victor

So, today I installed a new 2.0-M1 system and found out this:

- Logged on as Admin and create a new Group SuperAdmins where I set all permission flags.
- Created a new user and added this group to the user
- Changed password of user

> Logged on with this new user and Object Browser was empty

- Logged on as admin again
- Removed group SuperAdmins from the user
- Set permissions directly for the user

> Logged on with this new user and Object Browser was empty

- Logged on as admin again
- Add Built-In group Admins to this user
- Leaving direct permissions set

> Logged on with this new user and Object Browser filled as usual

Tried several times and always the same.

Thanks, VMGuy

Quote from: VMGuy on January 19, 2015, 09:37:47 PM
So, today I installed a new 2.0-M1 system and found out this:
...
Tried several times and always the same.

Thanks, VMGuy

This is correct behavior.

As Alex said:

Quote from: Alex KirhenshteinLogin as admin, right click on any object (node / container / object root like "Entire Network" / etc.) in the tree, select properties and set permissions for the user. By default, permissions are propagated to child objects unless you implicitly disable inheritance in object's access control.

So actually give access to the top level objects to the SuperUser group and then it will all work.

Ok, got it.

But this looks a bit inconsitent to me as the Built-In admin-user is not part of the Admins group. It only has directly set permissions.

User "admin" with id=0 (name doesn't matter, actually – you can change it after installation) is a special case, it have all permissions by default – and it's enforced by the server. This user also can't be deleted. However, you can disable it.