Tails

#1 Updated by bertagaz 2016-03-31 15:31:23

• 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 2016-04-06 12:53:30

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

#4 Updated by bertagaz 2016-04-16 03:07:10

• 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 2016-04-22 10:12:32

• Status changed from Confirmed to In Progress

#6 Updated by intrigeri 2016-04-25 04:38:31

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

> # 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 :)

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

> # 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 2016-04-26 03:30:13

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

#9 Updated by intrigeri 2016-04-26 05:36:13

• 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 2016-04-26 06:05:28

• Parent task changed from Feature #5734 to Feature #9482