Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Philipp Kern]

On 2018-03-27 14:29, Wookey wrote:

On 2018-03-22 22:31 +0100, Aurelien Jarno wrote:

On 2018-03-07 12:08, Hector Oron wrote:
> 2018-03-07 12:01 GMT+01:00 Philipp Kern :



To do more tests I agree that we should deploy it on more buildds. For
*this phase*, I believe enabling lingering and deploying it by hand is
the best. Is it something acceptable?


Anything is OK for _testing_, but I think it's always been a problem
that we don't use packaged code to do our build infrastrucutre,
because this makes it very hard to reproduce. And thre are lots of
reasons why people do want to have their own build infra of various
sorts.

So if we are having a re-arrange, I think we should try very hard to
use our own mechanisms and package this just like we package
everything else, not because it's easier for us, but because it's
easier for everyone else.


I relate with that. However this particular setup is not really intended 
to be reproducible by others at this point. I needed to cut the knot 
somewhere first, but wanna-build really is a pain to keep running. Once 
we are rewriting that, it might make more sense. As it stands it's 
pretty specific to our needs, unfortunately.


But as it turns out it shows rather nicely how the reality of providing 
a service and using raw packages from Debian don't really work. It works 
for the most basic case (e.g. "I just need a DNS/DHCP server"). But as 
soon as you scale that out or add some kind of high availability, you 
run into the need to orchestrate using Puppet or so, or even need to run 
your own custom-built solution on top of everything else Debian 
provides.


If you have a setup where DSA provides the VMs and does not want to give 
out root access and you have no access to the orchestration tools 
either, it's hard to keep a service running unless you run to DSA for 
each and every request. It's not surprising that they don't want that 
either if it can be avoided. Plus making changes hard by requiring that 
every change goes to testing and then backports isn't really feasible 
either.


Kind regards
Philipp Kern

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Wookey]

On 2018-03-22 22:31 +0100, Aurelien Jarno wrote:
> On 2018-03-07 12:08, Hector Oron wrote:
> > 2018-03-07 12:01 GMT+01:00 Philipp Kern :

> To do more tests I agree that we should deploy it on more buildds. For
> *this phase*, I believe enabling lingering and deploying it by hand is
> the best. Is it something acceptable?

Anything is OK for _testing_, but I think it's always been a problem
that we don't use packaged code to do our build infrastrucutre,
because this makes it very hard to reproduce. And thre are lots of
reasons why people do want to have their own build infra of various
sorts.

So if we are having a re-arrange, I think we should try very hard to
use our own mechanisms and package this just like we package
everything else, not because it's easier for us, but because it's
easier for everyone else.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Philipp Kern]

On 27.03.2018 09:22, Julien Cristau wrote:
> On 03/22/2018 10:31 PM, Aurelien Jarno wrote:
>> To do more tests I agree that we should deploy it on more buildds. For
>> *this phase*, I believe enabling lingering and deploying it by hand is
>> the best. Is it something acceptable?
>>
> Sounds ok to me, though I'd prefer if the buildd user (as in the user
> the service runs as) didn't have write access to the deployed code or
> configuration.  Maybe that's a later step though.

Does that really matter? If we were to use user sessions it's a little
hard to prevent that. Unless we tighten up the permissions to make all
service directories owned by someone else, which then makes sudo'ing to
that user a little awkward. Plus chown'ing files around. Because
otherwise someone with write access to ~buildd's home can still juggle
around things.

We could run the build as a different user in theory, but that's
somewhat hard with sbuild right now unless we "sudo -u" over when
executing sbuild. And then we need to manage files as a different user
as well.

If the threat model is that the ongoing build tampers with the files,
I'm open to constrain the build environment even further. Unfortunately
while it seems that a newer schroot version (in a branch that did not
receive any updates for years anymore) would support those, that version
has just been removed from experimental.

That all said: I'm happy to brainstorm and to implement proposed
solutions. Right now that seems to require more infrastructural changes
though and I'd rather focus on getting rid of buildd itself first.

Kind regards and thanks
Philipp Kern

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Julien Cristau]

On 03/27/2018 09:35 AM, Philipp Kern wrote:
> That all said: I'm happy to brainstorm and to implement proposed
> solutions. Right now that seems to require more infrastructural changes
> though and I'd rather focus on getting rid of buildd itself first.
> 
That's fair.

Cheers,
Julien

Re: Python buildd (was Re: let me help you with progressing bikesheds)

[Julien Cristau]

On 03/22/2018 10:31 PM, Aurelien Jarno wrote:
> To do more tests I agree that we should deploy it on more buildds. For
> *this phase*, I believe enabling lingering and deploying it by hand is
> the best. Is it something acceptable?
> 
Sounds ok to me, though I'd prefer if the buildd user (as in the user
the service runs as) didn't have write access to the deployed code or
configuration.  Maybe that's a later step though.

Cheers,
Julien