Tails

#1 Updated by intrigeri 2017-04-02 06:00:58

• blocks Bug #12422: Broken Puppet status on (at least) ecours and puppet-git.lizard added

#2 Updated by bertagaz 2017-04-05 13:08:08

• Status changed from Confirmed to In Progress

intrigeri wrote:
> commit 3cc510a55fbd6f6589e73778536328f83f0e1e0d in puppet-tails forces version 3.8.5-2~bpo8+1, that’s not available anywhere anymore, so I don’t get how it can possibly get the right version of Puppet installed on a newly installed system. I guess you need to import that version into some relevant suite in our custom APT repo.

Added a the custom APT suite, but snapshot.d.o is 503 at the moment, so I’ll have to wait a bit before going on.

> Also, while doing that you’ll want to update the bits that configure the jessie-backports source on Stretch and newer systems, since it’s not needed for Puppet anymore (but it’s still needed for the kernel iirc so perhaps these lines just need to be moved somewhere else :)

I’ll try to wrap my mind around that, we’ll see.

> Setting priority > normal since in my understanding, the current state of things breaks installing new systems, which is a regression compared to the state we were in ~10 days ago.

Right, didn’t think about new system use case.

#4 Updated by bertagaz 2017-04-06 10:31:40

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

intrigeri wrote:
> Our acng might have what you’re looking for :)

Neat! Didn’t think about that. I’ve uploaded the packages in the puppet3x suite.

> Also, while doing that you’ll want to update the bits that configure the jessie-backports source on Stretch and newer systems, since it’s not needed for Puppet anymore (but it’s still needed for the kernel iirc so perhaps these lines just need to be moved somewhere else :)

Removing this jessie-backports source works, as it’s only required for lizard, which use the use_next_release option of the puppet APT module. So we should be good here.

I’ve deployed it on all hosts with commit fa05bbd in puppet-tails, works fine.

#5 Updated by intrigeri 2017-04-06 10:49:41

• Assignee changed from intrigeri to bertagaz
• QA Check changed from Ready for QA to Info Needed

> I’ve deployed it on all hosts with commit fa05bbd in puppet-tails, works fine.

Please reassign to me once the pending puppet upgrade has been applied on all hosts (not sure why there’s an upgrade at all but well). Then I’ll happily review :)

#6 Updated by bertagaz 2017-04-06 13:17:18

• Assignee changed from bertagaz to intrigeri
• QA Check changed from Info Needed to Ready for QA

intrigeri wrote:
> > I’ve deployed it on all hosts with commit fa05bbd in puppet-tails, works fine.
>
> Please reassign to me once the pending puppet upgrade has been applied on all hosts (not sure why there’s an upgrade at all but well). Then I’ll happily review :)

Fixed. I messed up in the package upload.

#7 Updated by intrigeri 2017-04-09 11:05:32

• Assignee deleted (intrigeri)
• % Done changed from 70 to 100
• QA Check changed from Ready for QA to Pass

bertagaz wrote:
> intrigeri wrote:
> > Also, while doing that you’ll want to update the bits that configure the jessie-backports source on Stretch and newer systems, since it’s not needed for Puppet anymore (but it’s still needed for the kernel iirc so perhaps these lines just need to be moved somewhere else :)
>
> Removing this jessie-backports source works, as it’s only required for lizard, which use the use_next_release option of the puppet APT module. So we should be good here.

Reviewed, ACK (assuming you meant use_backports instead of use_next_release, otherwise I don’t get your reasoning).

All systems look good now. But our process for installing new systems is still broken on Stretch, as we have a depedency cycle: we instruct d-i to install Puppet (so 4.x will be pulled from Debian) and rely on it to set up APT, which can’t work until Feature #11837 is done, so we will need to manually set up APT (or scp Puppet packages) on a newly installed Stretch system before we can run Puppet for the first time. Anyway, it was already the case since Puppet 4 made it into testing, and the solution is well tracked elsewhere, so we’re done here! :)

#8 Updated by intrigeri 2017-04-09 11:05:44

• Status changed from In Progress to Resolved

#9 Updated by intrigeri 2017-04-16 07:46:43

• Status changed from Resolved to In Progress
• Assignee set to bertagaz
• % Done changed from 100 to 80
• QA Check changed from Pass to Dev Needed

commit fa05bbd6f2bafdde3408a3395adf7cb35f16bcc6 in puppet-tails stops managing jessie-backports.list, but it leaves it around (unmanaged) on Stretch and newer systems. Please clean it up there.

#10 Updated by intrigeri 2017-04-18 16:45:53

• blocked by deleted (Bug #12422: Broken Puppet status on (at least) ecours and puppet-git.lizard)

#11 Updated by bertagaz 2017-04-19 09:05:17

• Assignee changed from bertagaz to intrigeri
• QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:
> commit fa05bbd6f2bafdde3408a3395adf7cb35f16bcc6 in puppet-tails stops managing jessie-backports.list, but it leaves it around (unmanaged) on Stretch and newer systems. Please clean it up there.

Erf, good catch! I forgot the ensure => absent dance… Cleaned it on all systems, apart from the Jessie ones so it should be good now.

#12 Updated by intrigeri 2017-04-19 09:55:39

• Assignee changed from intrigeri to bertagaz
• QA Check changed from Ready for QA to Dev Needed

> Erf, good catch! I forgot the ensure => absent dance… Cleaned it on all systems, apart from the Jessie ones so it should be good now.

I see no such thing in Puppet, so I assume you did it by hand? Sadly, the manual way doesn’t solve such problems on all managed systems, it only works for the subset that you thought about (e.g. some *.sib systems still have the problematic file that was deployed by Puppet in the past, and never cleaned up; and we should assume that other wannabe contributors either already manage systems with our Puppet code, or will soon be doing so). In other words: what was deployed with Puppet, and is now obsolete, shall be cleaned up with Puppet too, otherwise we’ll be hitting our head against such consistency problems.

Thankfully, it’s straightforward way to fix that with Puppet, so please go ahead and try to remember next time that taking a shortcut might actually increase the total amount of work you have to do, if the shortcut happens not to be 100% correct.

Thanks in advance.

#13 Updated by bertagaz 2017-04-19 13:55:43

• Assignee changed from bertagaz to intrigeri
• QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:
> I see no such thing in Puppet, so I assume you did it by hand? Sadly, the manual way doesn’t solve such problems on all managed systems, it only works for the subset that you thought about (e.g. some *.sib systems still have the problematic file that was deployed by Puppet in the past, and never cleaned up; and we should assume that other wannabe contributors either already manage systems with our Puppet code, or will soon be doing so). In other words: what was deployed with Puppet, and is now obsolete, shall be cleaned up with Puppet too, otherwise we’ll be hitting our head against such consistency problems.
>
> Thankfully, it’s straightforward way to fix that with Puppet, so please go ahead and try to remember next time that taking a shortcut might actually increase the total amount of work you have to do, if the shortcut happens not to be 100% correct.

Done in puppet-tails:4ed72a8898aafeb084d51d313bd6fb771e64fd45. Applied everywhere apart from *.sib. Please do.

#14 Updated by intrigeri 2017-04-19 17:46:31

• Target version changed from Tails_2.12 to Tails_3.0~rc1

(2.12 was released)

#15 Updated by intrigeri 2017-04-20 06:05:57

• Status changed from In Progress to Resolved
• Assignee deleted (intrigeri)
• % Done changed from 80 to 100
• QA Check changed from Ready for QA to Pass

Thanks!

#16 Updated by intrigeri 2017-06-29 09:57:45

• blocks Feature #13232: Core work 2017Q2: Sysadmin (Maintain our already existing services) added