08-15-2018 08:41 AM
How does a system and local install differ? Apart from the location of files, are there differences in how NSO is working, as we appear to be seeing failures on some test cases when run against a system install, which work on a local install.
08-15-2018 09:09 AM
Hi Martin
I'm sure you've read the installation guide (?) eg. nso_installation_guide-4.7.pdf
it describes the differences and requirements. likely your authentication is changed (you must follow the procedures enabling users and auth).
(aside from the file locations as you mentioned).
08-15-2018 10:19 PM
Hi,
In many such cases, the issue is with NACM rules (or lack thereof).
For example, if you've been using code that open sessions towards CDB and had hardcoded users and user groups (mainly groups), then it now might be failing to authorise.
local install has default user defined (most notably, admin) and couple of default user groups defined (most notably group admin which has the admin user associated with it).
System install on the other hand, has no user defined and has couple of different user groups defined (e.g. ncsadmin).
Moreover, default NACM configurations in local install are much more permissive comparing to system install. If you look into configs such as 'nacm write-default', 'ncam read-default', etc., you'd see that they are configured with value 'permit' by default in local install. This is not the case with system install.
So, if for example, your code is using user admin hardcoded somewhere, then it will work on any default local install setup. However, it will not work on a default system install setup.
You'd need to either change the code, or define the relevant user groups in your NACM configs.
Another option, if you have test cases that rely on some APIs (e.g. REST), then they are enabled by default in local install, but disabled by default on system install.
08-15-2018 10:37 PM
So in essence, the differences are around the defaults, but all of this could be aligned by modifying the config. There is no fundamental differences between how the processes run in a system vs local install.
The issue we are seeing is more subtle, and looks to be timing related, fairly sure it is not a permission issues, but we will double check. Events within our service model were happening in a slightly different order, which meant that some activity was not triggered in the system install.
08-15-2018 10:52 PM
I believe your summary is accurate.
If the system is relatively empty, try comparing the configs between the systems.
Also if things are not being triggered correctly, it might be that you're missing some configurations (e.g. kickers), or that the code that is being triggered is not being authorised properly.
Search for the word 'admin' in your code. In many cases, people were using hardcoded user/group without realising it until they move to system install, which doesn't have this user configured by default.
08-16-2018 01:29 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide