cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1130
Views
0
Helpful
5
Replies

System vs local install

martmitc
Cisco Employee
Cisco Employee

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.

5 Replies 5

gschudel
Cisco Employee
Cisco Employee

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

yfherzog
Cisco Employee
Cisco Employee

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.

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.

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. 

I can add that there is absolutely no difference in the *NSO code* for these cases. It's the same build. It's just different packaging form factors, install script and default configs, as mentioned.