2wk atomic release candidate: 20170426
by Dusty Mabe
Planning to get back on track this week and also release an
Atomic Host with a fix for CVE-2017-5461.
We are going to attempt to release the 20170426 images.
These images contain the following ostree version/commit:
25.113
3492546bc1ef6bca1bc7801ed6bb0414f90cc96668e067996dba3dee0d83e6c3
The atomic host VM images are here:
https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-25-20170...
The ISO image is here:
https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-25-20170...
The AMIs are here:
Fedora-Atomic-25-20170426.0.x86_64 EC2 (ap-northeast-1) ami-cc042eab hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (ap-southeast-1) ami-27af1444 hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (ap-southeast-2) ami-4d323a2e hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (eu-central-1) ami-dbe13db4 hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (eu-west-1) ami-7f070719 hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (sa-east-1) ami-85fb96e9 hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (us-east-1) ami-4364fe55 hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (us-west-1) ami-5f9bbf3f hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (us-west-2) ami-37e37d57 hvm standard
Fedora-Atomic-25-20170426.0.x86_64 EC2 (ap-northeast-1) ami-71042e16 hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (ap-southeast-1) ami-abaf14c8 hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (ap-southeast-2) ami-a5343cc6 hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (eu-central-1) ami-1ee73b71 hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (eu-west-1) ami-22060644 hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (sa-east-1) ami-b3fb96df hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (us-east-1) ami-5c6df74a hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (us-west-1) ami-2a66414a hvm gp2
Fedora-Atomic-25-20170426.0.x86_64 EC2 (us-west-2) ami-eae7798a hvm gp2
The diff between this and the previous released version is:
ostree diff commit old: 9f0b576461f4baa2b5749003a8628fbf0a456942f37e17a9ceabdb29fc014b0e
ostree diff commit new: 3492546bc1ef6bca1bc7801ed6bb0414f90cc96668e067996dba3dee0d83e6c3
Upgraded:
NetworkManager 1:1.4.4-3.fc25.x86_64 -> 1:1.4.4-4.fc25.x86_64
NetworkManager-libnm 1:1.4.4-3.fc25.x86_64 -> 1:1.4.4-4.fc25.x86_64
NetworkManager-team 1:1.4.4-3.fc25.x86_64 -> 1:1.4.4-4.fc25.x86_64
audit 2.7.5-1.fc25.x86_64 -> 2.7.6-1.fc25.x86_64
audit-libs 2.7.5-1.fc25.x86_64 -> 2.7.6-1.fc25.x86_64
audit-libs-python 2.7.5-1.fc25.x86_64 -> 2.7.6-1.fc25.x86_64
audit-libs-python3 2.7.5-1.fc25.x86_64 -> 2.7.6-1.fc25.x86_64
bind99-libs 9.9.9-4.P6.fc25.x86_64 -> 9.9.9-4.P8.fc25.x86_64
bind99-license 9.9.9-4.P6.fc25.noarch -> 9.9.9-4.P8.fc25.noarch
gnutls 3.5.10-1.fc25.x86_64 -> 3.5.11-1.fc25.x86_64
kernel 4.10.10-200.fc25.x86_64 -> 4.10.11-200.fc25.x86_64
kernel-core 4.10.10-200.fc25.x86_64 -> 4.10.11-200.fc25.x86_64
kernel-modules 4.10.10-200.fc25.x86_64 -> 4.10.11-200.fc25.x86_64
libarchive 3.2.2-1.fc25.x86_64 -> 3.2.2-2.fc25.x86_64
libicu 57.1-4.fc25.x86_64 -> 57.1-5.fc25.x86_64
libnl3 3.2.29-2.fc25.x86_64 -> 3.2.29-3.fc25.x86_64
libnl3-cli 3.2.29-2.fc25.x86_64 -> 3.2.29-3.fc25.x86_64
libsemanage 2.5-8.fc25.x86_64 -> 2.5-9.fc25.x86_64
libsemanage-python 2.5-8.fc25.x86_64 -> 2.5-9.fc25.x86_64
libsemanage-python3 2.5-8.fc25.x86_64 -> 2.5-9.fc25.x86_64
libsss_idmap 1.15.2-1.fc25.x86_64 -> 1.15.2-2.fc25.x86_64
libsss_nss_idmap 1.15.2-1.fc25.x86_64 -> 1.15.2-2.fc25.x86_64
libsss_sudo 1.15.2-1.fc25.x86_64 -> 1.15.2-2.fc25.x86_64
libxml2 2.9.3-4.fc25.x86_64 -> 2.9.4-2.fc25.x86_64
nfs-utils 1:2.1.1-3.rc1.fc25.x86_64 -> 1:2.1.1-4.rc2.fc25.x86_64
nss-softokn 3.29.3-1.0.fc25.x86_64 -> 3.29.5-1.0.fc25.x86_64
nss-softokn-freebl 3.29.3-1.0.fc25.x86_64 -> 3.29.5-1.0.fc25.x86_64
nss-util 3.29.3-1.1.fc25.x86_64 -> 3.29.5-1.0.fc25.x86_64
pcre 8.40-6.fc25.x86_64 -> 8.40-7.fc25.x86_64
python3-libxml2 2.9.3-4.fc25.x86_64 -> 2.9.4-2.fc25.x86_64
python3-sssdconfig 1.15.2-1.fc25.noarch -> 1.15.2-2.fc25.noarch
rpm-ostree 2017.3-2.fc25.x86_64 -> 2017.4-2.fc25.x86_64
selinux-policy 3.13.1-225.11.fc25.noarch -> 3.13.1-225.13.fc25.noarch
selinux-policy-targeted 3.13.1-225.11.fc25.noarch -> 3.13.1-225.13.fc25.noarch
skopeo 0.1.17-1.dev.git2b3af4a.fc25.x86_64 -> 0.1.19-1.dev.git0224d8c.fc25.x86_64
skopeo-containers 0.1.17-1.dev.git2b3af4a.fc25.x86_64 -> 0.1.19-1.dev.git0224d8c.fc25.x86_64
sssd-client 1.15.2-1.fc25.x86_64 -> 1.15.2-2.fc25.x86_64
This includes a new version of NetworkManager so that we can better support
static networking from cloud-init, as well as a security fix for CVE-2017-5461:
https://access.redhat.com/security/cve/CVE-2017-5461
Dusty
5 years, 11 months
Storage for system containers
by Dusty Mabe
NOTE: please reply-all when responding to this message
In Fedora Atomic Host if we use system containers as advertised
we end up using `atomic pull --storage ostree` which by default
throws images into /var/lib/containers/atomic/. This is on the
root filesystem which may be undesirable.
Since in Fedora 26 the new version of container-storage-setup allows
us greater control over a "CONTAINER_ROOT" should we consider trying
to make sure both ostree storage and docker storage get placed under
that CONTAINER_ROOT?
The current default [1] is to just mount the CONTAINER_ROOT on
/var/lib/docker.
Dusty
[1] https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26...
5 years, 11 months
Re: [atomic-devel] Storage for system containers
by Dusty Mabe
On 04/24/2017 11:57 PM, Ben Breard wrote:
> The only issue I have with using the same location is that when troubleshooting, it's fairly common to wipe the storage pool. I think we'd want users to rm -rf /var/lib/docker without worrying about removing system containers.
using a symlink to /var/lib/containers/docker/ should be ok for this.
>
> Is this still an issue after the current partition scheme moves to OverlayFS?
>
Yes and no. If people choose to store their containers on a separate
partition (even though it is overlayFS on top of XFS), then yes, it is
still an issue.
If people choose to make one very large root partition and use that,
then no it is not a problem as all the storage is shared.
Dusty
5 years, 11 months
Re: [atomic-devel] Storage for system containers
by Daniel Walsh
Also rm -rf /var/lib/docker in a devicemapper world is not a good idea.
You end up in a strange world which could leak devices and resources.
atomic storage reset
Is the preferred way.
On 04/24/2017 11:57 PM, Ben Breard wrote:
> The only issue I have with using the same location is that when
> troubleshooting, it's fairly common to wipe the storage pool. I think
> we'd want users to rm -rf /var/lib/docker without worrying about
> removing system containers.
>
> Is this still an issue after the current partition scheme moves to
> OverlayFS?
>
> On Mon, Apr 24, 2017 at 12:56 PM, Dusty Mabe <dusty(a)dustymabe.com
> <mailto:dusty@dustymabe.com>> wrote:
>
> NOTE: please reply-all when responding to this message
>
>
> In Fedora Atomic Host if we use system containers as advertised
> we end up using `atomic pull --storage ostree` which by default
> throws images into /var/lib/containers/atomic/. This is on the
> root filesystem which may be undesirable.
>
> Since in Fedora 26 the new version of container-storage-setup allows
> us greater control over a "CONTAINER_ROOT" should we consider trying
> to make sure both ostree storage and docker storage get placed under
> that CONTAINER_ROOT?
>
> The current default [1] is to just mount the CONTAINER_ROOT on
> /var/lib/docker.
>
> Dusty
>
> [1]
> https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26...
> <https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26...>
>
>
>
>
> --
>
> Ben Breard
> Sr Technology Product Manager - Linux Containers
> Mobile: 972-816-9081
5 years, 11 months
Re: [atomic-devel] Storage for system containers
by Daniel Walsh
If we move the link under /var/lib/containers/docker then removing this
would not affect /var/lib/containers/ostree or /var/lib/containers/storage
On 04/24/2017 11:57 PM, Ben Breard wrote:
> The only issue I have with using the same location is that when
> troubleshooting, it's fairly common to wipe the storage pool. I think
> we'd want users to rm -rf /var/lib/docker without worrying about
> removing system containers.
>
> Is this still an issue after the current partition scheme moves to
> OverlayFS?
>
> On Mon, Apr 24, 2017 at 12:56 PM, Dusty Mabe <dusty(a)dustymabe.com
> <mailto:dusty@dustymabe.com>> wrote:
>
> NOTE: please reply-all when responding to this message
>
>
> In Fedora Atomic Host if we use system containers as advertised
> we end up using `atomic pull --storage ostree` which by default
> throws images into /var/lib/containers/atomic/. This is on the
> root filesystem which may be undesirable.
>
> Since in Fedora 26 the new version of container-storage-setup allows
> us greater control over a "CONTAINER_ROOT" should we consider trying
> to make sure both ostree storage and docker storage get placed under
> that CONTAINER_ROOT?
>
> The current default [1] is to just mount the CONTAINER_ROOT on
> /var/lib/docker.
>
> Dusty
>
> [1]
> https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26...
> <https://src.fedoraproject.org/cgit/rpms/docker.git/tree/docker.spec?h=f26...>
>
>
>
>
> --
>
> Ben Breard
> Sr Technology Product Manager - Linux Containers
> Mobile: 972-816-9081
5 years, 11 months
