Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JayST]

I was wondering if there are some tips that can be shared for configuring NetXMS for a few (<10) small/smb organizations. I already found out about zoning. That's clear. Proxy functionality is also clear to me now.

Perhaps more on configuratoin topics like:

• A Template strategy
• A Policy strategy
• Mapping customers and nodes to containers/folders
• A strategy arround Event Policy rules to stay flexible and deal with per-organization requirements and/or SLA's ?
• A event strategy
• A action strategy

I know it all falls into the category "it depends", but there must be some things you ran into that made some changes happen.

Basically, any do's and dont's available for such a setup 

[Tursiops]

Indeed "it depends". In fact it depends very heavily on which part you are trying to multi-tenant.
We are monitoring > 100 SMB networks in our installation, however we do not give our customers access to it at this time.

Templates & Policies (same thing in version 3)
We wouldn't customers access. A customer writing an auto-bind rule for "their" equipment would also apply to other customers. You would have to trust the customer to add checks for their zone (or custom attributes or whatever else you wish to use to identify a customer) into their templates. I do not trust.
If you are managing this, there is probably no reason not to apply the same templates to everyone. You can always use auto-apply rules for customer specific templates.

Mapping customers/nodes to containers
Auto-bind rules allow for that. But again, I wouldn't give customers write access to that as I do not trust the customer to always do the right thing here.

Event Policy Rules
And again, I wouldn't give customers access. There are no access controls to individual rules, you either can access EPRs or you can't. You do not want your customers to be able to mess with that. If the idea is that you're handling all of the rules, it is much easier. You can apply rules based on source objects, e.g. Zones. Make sure you get your naming conventions right so you can easily identify which rules apply to whom. You can configure customer specific settings as custom attributes on zones, containers or nodes. Or use persistent storage variables. You can script this to fit your needs.

Event Strategy
You can use the same events across your customers and apply different rules in EPRs depending on the customer. You can also create customer specific events if needed for customer specific templates. Once again, I wouldn't let customers create events.

Action Strategy
You might sense a pattern here.... I wouldn't let customers configure those, but you can set them up to deal with different customers yourself.

Basically NetXMS does not lend itself to full multi-tenancy where you can give actual administrative control over a zone to a different admin with them only being able to change their own templates, policies, rules, etc.

You can use it to give customers some level of access to their own devices. This is something you should test thoroughly. You do not want to have some area where one customer can pull data from another, e.g. via scripting or other means. You will need to setup trusted nodes, rather than assuming trust between everything. That also means newly discovered devices will need to be configured with trusted nodes. I haven't checked if that can be done via NXSL as discovered nodes are being created.

For logging, you need to enable ExtendedLogQueryAccessControl (disabled by default). It will make queries for logs slower, but it means customers won't be able to see each other's logs. However, we found a little while ago that "unknown" sources will be visible to everyone. That has been raised with the developers. Having said that, enabling UseSyslogForDiscovery and UseSNMPTrapsForDiscovery might be a workaround as it would create a new node from unknown sources. From that point onwards access restrictions would apply.

As we have not actually configured our system for this, I do not have any actual experience with that kind of setup. We simply needed a locked down temporary account one day for one particular customer and the above was what we found while doing so.

[JayST]

great stuff! Thanks alot!

I'm not looking to provide access to customers, so that's not an issue. I should have put that in my post, sorry. Good to see confirmation that providing customer access is not ideal.

So we'll go for a scenario in which we are the only one configuring the software and the only with access.

So in your environment, you have EPRs for every customer? Seems logical, as actions differ between customers offcourse.

I still struggle a bit with the event strategy. for example: What would be use cases to NOT share events between customer but instead create dedicated set of events for a customer?