Several problems (v2.0-M1)

[VMGuy]

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...

[alk]

Hello.

@vmguy said in Several problems (v2.0-M1):

• 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.
 

@vmguy said in Several problems (v2.0-M1):

• 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)

@vmguy said in Several problems (v2.0-M1):

• 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.

@vmguy said in Several problems (v2.0-M1):

• 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.

[VMGuy]

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.

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.

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.

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

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.

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

[victor]

@vmguy said in Several problems (v2.0-M1):

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.

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

[VMGuy]

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

[tomaskir]

@vmguy said in Several problems (v2.0-M1):

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:

@alk said:

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.

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

[VMGuy]

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.

[alk]

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.