Project

General

Profile

Feature #11282

Feature #5734: Monitor servers

Feature #9482: Create a monitoring setup prototype

Set up personal login for each sysadmin on icingaweb2

Added by intrigeri about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
03/25/2016
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

It seems confusing to have 2+ people discussing there if all of them comment as the same user, no?

History

#1 Updated by bertagaz about 2 years ago

  • Assignee changed from bertagaz to intrigeri

intrigeri wrote:

It seems confusing to have 2+ people discussing there if all of them comment as the same user, no?

Sure. I think then we can create our login by hand, using the icingaadmin one. I don't think it's worth modifying our icingaweb2 manifest for that. What's your opinion?

#2 Updated by intrigeri about 2 years ago

  • Assignee changed from intrigeri to bertagaz
  • Type of work changed from Discuss to Sysadmin

bertagaz wrote:

Sure. I think then we can create our login by hand, using the icingaadmin one. I don't think it's worth modifying our icingaweb2 manifest for that. What's your opinion?

Agreed, as long as the need for this manual step is documented (as part of what's needed when adding someone to the sysadmin team) => please go ahead, create our two logins and add a tiny bullet point about it in some relevant onboarding documentation (that you may have to create).

#3 Updated by intrigeri about 2 years ago

I've created a user for myself, but failed at adding it to the admins role via the web interface (" The file /etc/icingaweb2/roles.ini couldn't be stored. (Error: "file_put_contents(/etc/icingaweb2/roles.ini): failed to open stream: Permission denied")" => I'll wait for you to do it in another, documented way.

#4 Updated by bertagaz about 2 years ago

  • Assignee changed from bertagaz to intrigeri
  • QA Check set to Info Needed

intrigeri wrote:

I've created a user for myself, but failed at adding it to the admins role via the web interface (" The file /etc/icingaweb2/roles.ini couldn't be stored. (Error: "file_put_contents(/etc/icingaweb2/roles.ini): failed to open stream: Permission denied")"

Yeah, I haven't allowed icingaweb2 any write access to /etc/icingaweb2/* (which is the per default config, as the php code is running as www-data, and Icingaweb2 files are owned by its own user). I thought it is a bad idea for a public php Webapp to have this kind of access. It results in this kind of errors, but it's relatively rare.

=> I'll wait for you to do it in another, documented way.

Well, it seems you found the way I intended to do it. But also a minor step I didn't think about yet. To workaround this write access error, we have three ways:

  1. Give write access to this file to the www-data user. Precisely what I tried to avoid. Could be made manually just for the time of this role modification though.
  2. As described in the error message, edit this file by hand and add the users to the role once the user is created. That's all the form you were editing is doing in fact.
  3. Add a bit of puppet code to have our users added to this file in the correct role, even if they don't exists.

I think I'd prefer the second option, with proper documentation, the first isn't really optimal in term of security, and the third being a bit inconsistent if we don't want to manage our users with Puppet.

#5 Updated by bertagaz almost 2 years ago

  • Status changed from Confirmed to In Progress

#6 Updated by intrigeri almost 2 years ago

  • Assignee changed from intrigeri to bertagaz
  • QA Check changed from Info Needed to Dev Needed

Yeah, I haven't allowed icingaweb2 any write access to /etc/icingaweb2/* [...]

Good.

  1. Give write access to this file to the www-data user. Precisely what I tried to avoid. Could be made manually just for the time of this role modification though.

No, please :)

  1. As described in the error message, edit this file by hand and add the users to the role once the user is created. That's all the form you were editing is doing in fact.

Worst case we can do that.

  1. Add a bit of puppet code to have our users added to this file in the correct role, even if they don't exists.

That sounds dangerously racy: if some day a bug or misconfiguration allows anyone to create a user account for themselves, they could possibly race against us and create themselves a privileged account. So, no.

I think I'd prefer the second option, with proper documentation, the first isn't really optimal in term of security, and the third being a bit inconsistent if we don't want to manage our users with Puppet.

OK.

#7 Updated by bertagaz almost 2 years ago

  • Assignee changed from bertagaz to intrigeri
  • % Done changed from 0 to 70
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:

I think I'd prefer the second option, with proper documentation, the first isn't really optimal in term of security, and the third being a bit inconsistent if we don't want to manage our users with Puppet.

OK.

So I've added our accounts to the Admin role in Icingaweb2 manually by modifying the roles.ini file.

I've also pushed a processes/onboarding.mdwn document in the sysadmin Git repo. I may have forgot some bits of the onboarding process, but that's a first iteration. We'll see when this really happens. Still if you see things I forgot, don't refrain yourself to add them. :)

#8 Updated by bertagaz almost 2 years ago

bertagaz wrote:

So I've added our accounts to the Admin role in Icingaweb2 manually by modifying the roles.ini file.

But when I ran puppet agent on ecours, the change has been rolled back. That's because the upstream puppet-icingaweb2 module is in fact taking care of this file, so I had to add a parameter to our t::m::master and t::m::icingaweb2@ classes so that we can configure this role. By default it is set to icingaadmin, and I've added us as admins using this parameter.

This way, we can just add a user in this role only once it has been created.

I've also updated our onboarding documentation.

#9 Updated by intrigeri almost 2 years ago

  • Subject changed from Consider having personal login on icingaweb2 to Set up personal login for each sysadmin on icingaweb2
  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • Target version changed from Tails_2.4 to Tails_2.3
  • % Done changed from 70 to 100
  • QA Check changed from Ready for QA to Pass

Looks great, thanks!

#10 Updated by intrigeri almost 2 years ago

  • Parent task changed from #5734 to #9482

Also available in: Atom PDF