Excerpts from Chris Jones's message of 2014-10-07 13:27:07 -0700:
> Hi
>
> > On 7 Oct 2014, at 20:47, Clint Byrum wrote:
> >>
> >> I don't think it should import those files wholesale, IMO that's making
> >> way too many assumptions about the similarity of the two builds.
> > Disagree on the gr
Hi
> On 7 Oct 2014, at 20:47, Clint Byrum wrote:
>>
>> I don't think it should import those files wholesale, IMO that's making way
>> too many assumptions about the similarity of the two builds.
> Disagree on the grounds that the point of this is to deal with people
> who already have images an
Excerpts from Chris Jones's message of 2014-10-07 12:23:20 -0700:
> Hi
>
> > On 7 Oct 2014, at 18:49, Clint Byrum wrote:
> > * Create an element which imports /etc/passwd and /etc/group from local
> > disk into image. This will have an element-provides of uid-gid-map
>
> I don't think it should
Hi
> On 7 Oct 2014, at 18:49, Clint Byrum wrote:
> * Create an element which imports /etc/passwd and /etc/group from local
> disk into image. This will have an element-provides of uid-gid-map
I don't think it should import those files wholesale, IMO that's making way too
many assumptions about
On 8 October 2014 06:49, Clint Byrum wrote:
> Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:
>> AFAICS, the only risk left at that point, is elements that other people are
>> maintaining. If we consider that to be a sufficient risk, we can still build
>> the mechanism for inj
Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:
> Hi
>
> > On 6 Oct 2014, at 17:41, Clint Byrum wrote:
> > We have to be _extremely_ careful in how we manage this. I actually think
> > it has potential to really blow up in our faces.
>
> Yes, anything we do here has the potenti
Hi
> On 6 Oct 2014, at 17:41, Clint Byrum wrote:
> We have to be _extremely_ careful in how we manage this. I actually think
> it has potential to really blow up in our faces.
Yes, anything we do here has the potential to be extremely ruinous for
operators, but the reality is that any existing
Excerpts from Gregory Haynes's message of 2014-10-06 07:06:02 -0700:
> Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +:
> > Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
> > > If we really want to go with this type of aproach we could also just
> > > copy the
Excerpts from Clint Byrum's message of 2014-10-02 14:15:30 +:
> Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
> > If we really want to go with this type of aproach we could also just
> > copy the existing /etc/passwd into the image thats being built. Then
> > when users a
> On 3 Oct 2014, at 02:57, James Polley wrote:
>
>
>
>
>
>> On 3 Oct 2014, at 00:25, Clint Byrum wrote:
>>
>> Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
>>> All three of the options presented here seem to assume that UIDs will
>>> always be allocated at image-bu
> On 3 Oct 2014, at 00:25, Clint Byrum wrote:
>
> Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
>> All three of the options presented here seem to assume that UIDs will always
>> be allocated at image-build time. I think that's because most of these UIDs
>> will be used
Excerpts from Sullivan, Jon Paul's message of 2014-10-02 02:08:26 -0700:
> > -Original Message-
> > From: Clint Byrum [mailto:cl...@fewbar.com]
> > Sent: 02 October 2014 02:51
> > To: openstack-dev
> > Subject: [openstack-dev] [TripleO] a need to ass
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: 02 October 2014 15:16
> To: openstack-dev
> Subject: Re: [openstack-dev] [TripleO] a need to assert user ownership
> in preserved state
>
> Excerpts from Gregory Haynes's message
Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
> All three of the options presented here seem to assume that UIDs will always
> be allocated at image-build time. I think that's because most of these UIDs
> will be used to write files into the chroot at image-create time - if I
Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
> Excerpts from Clint Byrum's message of 2014-10-02 01:50:33 +:
> > Recently we've been testing image based updates using TripleO, and we've
> > run into an interesting conundrum.
> >
> > Currently, our image build scripts cr
> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: 02 October 2014 02:51
> To: openstack-dev
> Subject: [openstack-dev] [TripleO] a need to assert user ownership in
> preserved state
>
> Recently we've been testing image based updates u
Excerpts from James Polley's message of 2014-10-02 05:37:25 +:
> All three of the options presented here seem to assume that UIDs will always
> be allocated at image-build time. I think that's because most of these UIDs
> will be used to write files into the chroot at image-create time - if I
All three of the options presented here seem to assume that UIDs will always be
allocated at image-build time. I think that's because most of these UIDs will
be used to write files into the chroot at image-create time - if I could think
of some way around that, I think we could avoid this proble
On 02/10/14 12:26, Mike Spreitzer wrote:
> I do not understand the problem statement. Unfortunately, I am not
> familiar with image based updates using TripleO. What is updating what?
> If the UIDs are not asserted, what UIDs shift by one? Is this because
> some files keep owner UID while the so
Clint Byrum wrote on 10/01/2014 09:50:33 PM:
> Recently we've been testing image based updates using TripleO, and we've
> run into an interesting conundrum.
>
> Currently, our image build scripts create a user per service for the
> image. We don't, at this time, assert a UID, so it could get any
Excerpts from Clint Byrum's message of 2014-10-02 01:50:33 +:
> Recently we've been testing image based updates using TripleO, and we've
> run into an interesting conundrum.
>
> Currently, our image build scripts create a user per service for the
> image. We don't, at this time, assert a UID,
Recently we've been testing image based updates using TripleO, and we've
run into an interesting conundrum.
Currently, our image build scripts create a user per service for the
image. We don't, at this time, assert a UID, so it could get any UID in
the /etc/passwd database of the image.
However,
22 matches
Mail list logo
