00:27 < jmbsvicetto> antarus: if we could get 8+ GB RAM that would be great If we do the bugzilla db migration it is my impression that harrier and hen will be free. Otherwise we can try to do a 4 core, 8GB ram VM on the dells at the OSL. This request has actually been discussed for months. I'd like to get it moving. The OSL dells are blocked on me ordering RAID cards. I have no idea what is blocking the bugdb migration, I'll file a separate bug for it. -A
CC doesn't work with restricted bugs
(Sorry, hit enter too fast.) The real blocker is such that we have no clean way to give out root and retain "infra control" releng needs some hardened features disabled, I recall this from previous convo. No further details. So, the options are: a) releng refactors such that they don't need root access. Eg, they give us scripts to run and we run them. Possible but I don't see that happening soon with the current releng staffing levels. b) We reinstall a machine and give releng full access. Possible but I don't think they want this again. Discuss.
(In reply to comment #2) > (Sorry, hit enter too fast.) The real blocker is such that we have no clean way > to give out root and retain "infra control" I do this with thousands of workstation at work, so I have some experience in this area. I agree our existing cfengine tree does not lend well to it. What I really want on the box is: syslogging to loghost. Infra managed identities (AuthN) Infra managed login policies (AuthZ) Infra managed login software and configs (ssh, its dependencies...) Infra managed security updates (aka if infra deploys a GLSA for a package installed on the box it will get it.) Any other monitoring aspects that we deem necessary. I think in terms of package and configuration management, those are things we could manage for them; but at least for me it isn't necessary. > > releng needs some hardened features disabled, I recall this from previous > convo. No further details. Ok well those details are obviously a blocker. > > So, the options are: > a) releng refactors such that they don't need root access. Eg, they give us > scripts to run and we run them. Possible but I don't see that happening soon > with the current releng staffing levels. I am not convinced that limited sudo access is also not an option. I'm curious what they need root for and if we can meet their needs with some obvious sudo rulesets. Then perhaps we can just build up a cf.releng class for them and they can use the sudo rules for operational management of releases. > b) We reinstall a machine and give releng full access. Possible but I don't > think they want this again. I don't want this either :) > > Discuss.
I'm adding Andrew and Raúl to the bug so they can provide input as well. The hardened features we need to be lifted are the following: # Jorge Manuel B. S. Vicetto # 21 Oct 2011 # Lift chmod restrictions echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod echo 0 > /proc/sys/kernel/grsecurity/linking_restrictions I do it on my box through the local init script. As you can see above, there's no workaround as we need to be able to chroot, create device nodes and symlinks for the stages. catalyst was designed to be run as root. It needs to be reviewed, but at this point we shouldn't expect that to happen any time soon, unless someone decides to take up that task. We (releng) have no desire to have root on the boxes, we just need to be able to run catalyst, we have some scripts to help with that, and at times may need some tweaking of installed packages.
We will tentatively give you peacock for builds. jmbsvicetto, armin76 has elected you to work with me on the setup, can we schedule 30 minutes to work out the details? -A
We've been talking about the move and I've added the catalyst config files to the repo. I still need to add the scripts to the repo. http://git.overlays.gentoo.org/gitweb/?p=proj/releng.git
We gave releng skimmer. I updated the server-specs. We need to engage puppet on this machine (in concert with cfengine.. :))
I think everything was set up on skimmer properly. -A
Sorry to reopen... Remember that poseidon also acts as a central host for the other build boxes to push the stages/livecds. I have no idea what skimmer is doing right now(apart from building the stages), is it even using poseidon to push the stages? To fully retire poseidon we need to have a host for pushing the stages. If skimmer is a full replacement of poseidon, then that host should be skimmer. Right now poseidon has an rsync server serving the files to get pushed, and dipper connects to it to fetch them. The other arches that build stages push the stages to poseidon using rsync over ssh using a unique ssh user(buildsync).
Following up with that, I see skimmer has built stages 3 days ago but they haven't been pushed, so I understand this is not fully configured.
(In reply to comment #10) > Following up with that, I see skimmer has built stages 3 days ago but they > haven't been pushed, so I understand this is not fully configured. Yes, the work on skimmer is not yet complete. To be clear, this is pending on me and no one else in the infra or releng teams.
(In reply to comment #11) > (In reply to comment #10) > > Following up with that, I see skimmer has built stages 3 days ago but they > > haven't been pushed, so I understand this is not fully configured. > > Yes, the work on skimmer is not yet complete. > To be clear, this is pending on me and no one else in the infra or releng > teams. I've gone ahead and finished the remaining work. Everything is setup, only waiting for infra to switch the sync from poseidon to skimmer in masterdistfiles. Infra please proceed
files/usr/local/bin/mastermirror/sync-autobuilds.sh updated to use skimmer instead of poseidon now.
