Managing security permissions for large teams in Opsview
Hindsight is a wonderful thing.In hindsight, Opsview would have always had access controls for objects at the role level - since roles also define which parts of the Opsview application you can get to, it would make sense to...
In hindsight, Opsview would have always had access controls for objects at the role level - since roles also define which parts of the Opsview application you can get to, it would make sense to also put all the host and service objects into this definition.
(In our defence, we wanted to make it as obvious as possible for a contact when you were changing access information.)
The downside of our design decision many years ago is that Opsview administrators who have lots of their users - or contacts in Opsview terms - with the same sort of access and were having to change each user individually. This was painful and error prone if you had 40 “similar” users.
So Opsview Enterprise 3.12.0 now has access information in the role definition. You change access at the role level and it automatically affects all users of that role. Even better, we ensure that a user’s notification profile only has references to the objects they are allowed - change the role definitions and object references will be automatically removed from all aspects of that contact.
Now you can administer users in a much simpler way.
Hindsight - we wish we had more of it.
But the next best thing to hindsight - migratability.
The Opsview configuration database is normalised and models the data as it is. Some application designers like to use key-value pairs to describe their data, which is nice from an expandable point of view, but rubbish when it comes to actually accessing that data in a meaningful way. When it comes to modelling our data, we model it - we don’t “meta-model” it.
We care a lot about people’s data because we build up a trust with our users that they can upgrade and bring their platform right up to date with the latest versions of Opsview. So we spend a lot of time getting the upgrade scripts just right.
If you are upgrading to Opsview 3.12, here’s what the upgrade scripts do:
for each contact, it will see if this contact’s role has access information applied
if it hasn’t, it will use this contact’s access information to populate the role
if the role already has access information (from another contact), then it will compare all the current roles with their access information and if there is a match, this role is used
if it isn’t exactly the same, then a new role is created called “old role name - contact”
So for example, let’s say you have 4 contacts - John, Paul, George and Ringo - all using the “Liverpool administrators” role.
The first three have their access information the same, but Ringo has missed out theProduction - Slicehost Servers host group he should have had access to.
After the upgrade, the first three would still have the role of Liverpool administrators, but Ringo would have the role of a newly created Liverpool administrators - ringo. You could easily tell from this that Ringo should belong to the Liverpool administrators, so you can set him to this. Otherwise, maybe he is different after all, so you can rename the role toLiverpool drummers.
This means that most of the configuration for this new functionality is done for you automatically and you can think of your users in their role groups, rather than individually. Another step to making Opsview easier to use.