Re: [atomic-devel] We are looking at using OSTree as a backend for sharing file systems into an OCID Container runtime

2016-10-14 Thread Colin Walters 
On Fri, Oct 14, 2016, at 02:37 PM, Daniel J Walsh wrote:

> If we block the creation of the devices when exploding a OCI Image
> Bundle, we end up with something that is different then what is
> downloaded and this could potentially cause problems with mtree checking
> of the image on disk versus the image as shipped.

https://github.com/ostreedev/ostree/pull/443
would be a good place to discuss this.

> Is there a reason OSTree does not work with Device Inodes? 

Yes, I think there's no good reason to include devices in OS or container
images.  For OS images (i.e. ostree-as-base), all modern systems
use devtmpfs. 

(Also for that matter, a bit more strictly, FIFOs either.
 OSTree very intentionally only supports regular files and
 symlinks)

For the Ubuntu Docker image, the user can't even see them
because Docker (correctly) mounts over /dev/ with
the "API devices" as systemd calls them.

So basically...my proposal would be that we
ignore them, and that's indeed what the proposed OSTree
API above does.

If we implement any other verification layer like mtree, it
should then just skip devices and FIFOs (or more generally
anything except regular files and symlinks).

Re: [atomic-devel] bubblewrap 0.1.3 (fixes CVE-2016-8659)

2016-10-14 Thread Colin Walters 


On Fri, Oct 14, 2016, at 12:53 PM, Colin Walters wrote:
> A new release of bubblewrap is available:
> 
> https://github.com/projectatomic/bubblewrap/releases/tag/v0.1.3
...

> So, expect updates to land in:
>  
>  - EPEL7

https://bodhi.fedoraproject.org/updates/bubblewrap-0.1.3-2.el7

>  - CentOS AH Alpha

Done, see:
https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel

Note this pulled in a number of other updates
as we do binary promotion of continuous -> alpha.

The atomic/skopeo train continues to rev, and
there are some smaller fixes to the ostree stack.

Changed:
  atomic 
1.13.0.4-adc8956f50a38d15b65ebf34dacee6a418524e20.c6c664b91e099b3f2078e562af19220c2ff7562d.el7.centos
 -> 
1.13.1.21-aed68da24c0db3ea7e2e3bd4de0904c6b67115e4.dd4522961a9990fd47096ad652d3b6d9059051d7.el7.centos
  bubblewrap 0.1.2.1-169db041313862c3ef03235dde30e6d3c96e2a6a.el7.centos -> 
0.1.2.5-7d035f1bbcce30a80a40fc564427ddbf7589e5f1.el7.centos
  ostree 
2016.11.1-0446cdb0d38e1e05fc51202b580e28c44993b76c.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos
 -> 
2016.11.5-a660e5650d0f460810ea75c44d044b6924659f59.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos
  ostree-grub2 
2016.11.1-0446cdb0d38e1e05fc51202b580e28c44993b76c.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos
 -> 
2016.11.5-a660e5650d0f460810ea75c44d044b6924659f59.ee3685405394f0193b77e9a9db9256cd1750e69d.el7.centos
  rpm-ostree 
2016.10.0-af23b948f12b01db99143bfab82ff60a3e4a4aee.7081d79d1a21dc196c1286ea012b740d47d68e1e.el7.centos
 -> 
2016.10.3-a15364c185df0a72d99440b2dcd210432b9da1d0.7081d79d1a21dc196c1286ea012b740d47d68e1e.el7.centos
  skopeo 
1.14-7d786d11d668f2932e524da53afb658438c8ebfc.0aa48eb05ef9b646ac444ddc878eb93dbd3d6d98.el7.centos
 -> 
1.14-66160a083bed5ec3b551eab62729c6ad5b0889aa.ec8b80abfd4d904e882bcdf340ee21a852e2f979.el7.centos
Added:
  
skopeo-containers-1.14-66160a083bed5ec3b551eab62729c6ad5b0889aa.ec8b80abfd4d904e882bcdf340ee21a852e2f979.el7.centos.x86_64

[atomic-devel] We are looking at using OSTree as a backend for sharing file systems into an OCID Container runtime

2016-10-14 Thread Daniel J Walsh 
We are seeing the same problem that William Temple had this summer,
where OSTree refuses to store an image with devices on it.  We
understand that devices should not be in image, but sadly Ubuntu image
has them and therefore thousands of other images do as well.

If we block the creation of the devices when exploding a OCI Image
Bundle, we end up with something that is different then what is
downloaded and this could potentially cause problems with mtree checking
of the image on disk versus the image as shipped.


Is there a reason OSTree does not work with Device Inodes?

[atomic-devel] bubblewrap 0.1.3 (fixes CVE-2016-8659)

2016-10-14 Thread Colin Walters 
A new release of bubblewrap is available:

https://github.com/projectatomic/bubblewrap/releases/tag/v0.1.3

Which fixes a local privilege escalation.  Specifically relevant to Project 
Atomic,
this applies only to CentOS7/RHEL7 systems which have
bubblewrap installed as privileged code.

Notably, we *do* install it by default as /usr/bin/bwrap in
CentOS Atomic Host Alpha, but not in the primary CentOS Atomic Host
release, where it exists solely as /usr/libexec/rpm-ostree/bwrap for
use by rpm-ostree's package layering, but is not installed as
privileged and hence is not a vulnerability vector.

Fedora, because it unconditionally enables `CLONE_NEWUSER`
access, is not vulnerable to this.

So, expect updates to land in:
 
 - EPEL7
 - CentOS AH Alpha

soon.

Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-14 Thread Jason DeTiberus 
On Fri, Oct 14, 2016 at 7:40 AM, Jeremy Eder  wrote:

> On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters 
> wrote:
>
>>
>> On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote:
>>
>> Because layered products (not just OpenShift) do not want to be coupled
>> to the RHEL release schedule to update their profiles.  They want to own
>> their profiles and rely on the tuned daemon to be there.
>>
>>
>> I see two aspects to this discussion:
>>
>> 1) Generic tradeoffs with host configuration
>> 2) The specific discussion about tuned profiles
>>
>> Following 2) if I run:
>>
>> $ cd ~/src/github/openshift/origin
>> $ git describe --tags --always
>> v1.3.0-rc1-14-ge9081ae
>> $ git log --follow contrib/tuned/origin-node-host/tuned.conf
>>
>> There are a grand total of *two* commits that aren't mere
>> code reorganization:
>>
>> commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc
>> Author: Jeremy Eder 
>> AuthorDate: Tue Mar 29 10:40:03 2016 -0400
>> Commit: Jeremy Eder 
>> CommitDate: Tue Mar 29 10:40:03 2016 -0400
>>
>> bump inotify watches
>>
>> commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883
>> Author: Scott Dodson 
>> AuthorDate: Thu Feb 12 13:06:57 2015 -0500
>> Commit: Scott Dodson 
>> CommitDate: Wed Mar 11 16:41:08 2015 -0400
>>
>> Provide both a host and guest profile
>>
>> That level of change seems quite sufficient for the slower
>> RHEL cadence, no?
>>
>
> Decoupling profiles from RHEL has already been negotiated with many
> different engineering teams.  As you can imagine, it has ties into our
> channels and distribution mechanics.  Making an exception here doesn't make
> sense to me when it's working fine everywhere else.
>

Given the reboot issue gets addressed, I think I would prefer this approach
as well. We are working as best as we can to decouple the underlying host
management from the cluster management especially around upgrades. Being
able to update and ship the tuned profiles as needed would allow us to
manage it as part of the cluster management without having to query
underlying host state to determine if we need to do temporary
modifications. The other issue is that we don't require users to manage
their environments with Ansible, so our temporary modifications would also
need to be documented and implemented separately for non-Ansible users.


Particularly when one considers that something like the
>> inotify watch bump could easily be part of a "tuned updates"
>> in the installer that would live there until the base tuned
>> profile updates.
>>
>> Right?
>>
>
> ​Personally I would prefer to keep tuning centralized into tuned and not
> have 5 difference places where it's being done...but to your point around
> having two commits ... I'm losing that consolidation battle because
> Kubernetes has hardcoded certain sysctl adjustments that ideally we really
> should have carried in tuned :-/  But if we can at least avoid doing things
> in openshift-ansible at least that's one less place to track.​
>

I can understand why Kubernetes wouldn't want to require tuned, but maybe
we can drive changes upstream to make sysctl management optional. Then we
would be able to add the tuned requirement in our packaging and handle it
there without forcing tuned upstream.



>
>
>
>> Before we go the layered RPM route I just want to make sure you're
>> onboard with it, as I was not aware of any existing in-product users of
>> that feature.  Are there any? If we're the first that's not an issue, just
>> want to make sure we get it right.
>>
>>
>> In this particular case of tuned, I'd argue that Atomic Host should come
>> out of the box with these profiles,
>> and that any async updates could be done via the openshift-ansible
>> installer.
>>
>
> Realistically speaking -- we may want to use AH with another
> product...we've developed
> ​realtime and ​
> NFV profiles which again exist in another
> ​
> channel and there is no such thing as openshift-ansible there.
> ​
> What would be your approach if the openshift-ansible option did not exist?
> (back to scattered tuning)​
> ​​
>
>


-- 
Jason DeTiberus

Re: [atomic-devel] How to apply non-atomic tuned profiles to atomic host

2016-10-14 Thread Jeremy Eder 
On Wed, Oct 12, 2016 at 10:29 AM, Colin Walters  wrote:

>
> On Tue, Oct 11, 2016, at 02:45 PM, Jeremy Eder wrote:
>
> Because layered products (not just OpenShift) do not want to be coupled to
> the RHEL release schedule to update their profiles.  They want to own their
> profiles and rely on the tuned daemon to be there.
>
>
> I see two aspects to this discussion:
>
> 1) Generic tradeoffs with host configuration
> 2) The specific discussion about tuned profiles
>
> Following 2) if I run:
>
> $ cd ~/src/github/openshift/origin
> $ git describe --tags --always
> v1.3.0-rc1-14-ge9081ae
> $ git log --follow contrib/tuned/origin-node-host/tuned.conf
>
> There are a grand total of *two* commits that aren't mere
> code reorganization:
>
> commit d959d25a405bb28568a17f8bf1b79e7d427ae0dc
> Author: Jeremy Eder 
> AuthorDate: Tue Mar 29 10:40:03 2016 -0400
> Commit: Jeremy Eder 
> CommitDate: Tue Mar 29 10:40:03 2016 -0400
>
> bump inotify watches
>
> commit c11cb47c07e24bfeec22a7cf94b0d6d693a00883
> Author: Scott Dodson 
> AuthorDate: Thu Feb 12 13:06:57 2015 -0500
> Commit: Scott Dodson 
> CommitDate: Wed Mar 11 16:41:08 2015 -0400
>
> Provide both a host and guest profile
>
> That level of change seems quite sufficient for the slower
> RHEL cadence, no?
>

Decoupling profiles from RHEL has already been negotiated with many
different engineering teams.  As you can imagine, it has ties into our
channels and distribution mechanics.  Making an exception here doesn't make
sense to me when it's working fine everywhere else.

Particularly when one considers that something like the
> inotify watch bump could easily be part of a "tuned updates"
> in the installer that would live there until the base tuned
> profile updates.
>
> Right?
>

​Personally I would prefer to keep tuning centralized into tuned and not
have 5 difference places where it's being done...but to your point around
having two commits ... I'm losing that consolidation battle because
Kubernetes has hardcoded certain sysctl adjustments that ideally we really
should have carried in tuned :-/  But if we can at least avoid doing things
in openshift-ansible at least that's one less place to track.​



> Before we go the layered RPM route I just want to make sure you're onboard
> with it, as I was not aware of any existing in-product users of that
> feature.  Are there any? If we're the first that's not an issue, just want
> to make sure we get it right.
>
>
> In this particular case of tuned, I'd argue that Atomic Host should come
> out of the box with these profiles,
> and that any async updates could be done via the openshift-ansible
> installer.
>

Realistically speaking -- we may want to use AH with another
product...we've developed
​realtime and ​
NFV profiles which again exist in another
​
channel and there is no such thing as openshift-ansible there.
​
What would be your approach if the openshift-ansible option did not exist?
(back to scattered tuning)​
​​