[atomic-wg] Issue #290: Make fedora-minimal base image generally available

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
scratch is not a "base" image, it is just a special name that tells buildah to 
create a layer with nothing in it.  Dockerfile has the same concept.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/290
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Schedule for Container Policy VFAD

[Daniel J Walsh]

Sounds good.


On 03/09/2017 11:02 AM, Josh Berkus wrote:
> On 03/09/2017 07:50 AM, Daniel J Walsh wrote:
>> Sure I can help on this depending on the date.
>>
> Tommorrow.  Can you dial in at 2pm?
>
>
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #233 `Container guidelines for systemd based containers`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
Not sure here is the best place, but I would start by saying

1. Easily move applications from VM to container, using standard scripts.  IE
FROM fedora-init
RUN dnf -y install httpd; systemctl enable httpd
ADD MYPHP /var/www/html
...
2. Proper Logging.  Journalctl and syslog actually work
3. Cleaning up Zombies
4. Multi Service containers.
5. Other systemd features like checking status, eventually additional cgroup 
(Requires CGROUPV2)

``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/233
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #233 `Container guidelines for systemd based containers`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
BTW Even if we got oci-systemd-hook into debian, we would still need to get 
projectatomic/docker in since docker rejected the patch to run hooks directly.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/233
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
Sure, our teams policy is that we don't update docker package until k8s and 
OpenShift support it.  But it is likely that this would change during the 13 
months of a Fedora release.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
I don't believe Fedora has such a capability.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
@vinzentm I tend to agree with you the thought was to put it in 
updates-testing, without ever releasing it so is is easy to get a hold of for 
those that want it.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
None have been created yet.  I will attempt to get one built as soon as we have 
docker-1.13 in updates-testing.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
I find ROOT confusing.  ROOT means /root or / or the rootfs of the container.  
But I am bike shedding.  I think we pick one and then put an explanation in the 
config file and be done with it.  BTW This discussion should have gone on in 
the pull request.  :^(

``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
Lets go with

CONTAINER_LV_NAME
CONTAINER_LV_MOUNT_PATH

That makes it clear this is a logical volume, and we need to put examples into 
the configuration.


``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
User edits /etc/sysconfig/docker-storage-setup which should include 
documentation on what can be changed.

Uwe edits /etc/sysconfig/ocid-storage-setup which should include documentation 
on what can be changed.

container-storage-setup will output /etc/sysconfig/docker-storage and 
/etc/sysconfig/ocid-storage.

The ocid-storage.spec and docker.storage.spec will be executing something like

container-storage-setup --input /etc/sysconfig/docker-storage-setup --output 
/etc/sysconfig/docker-storage

container-storage-setup --input /etc/sysconfig/ocid-storage-setup --output 
/etc/sysconfig/ocid-storage
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #197 `Change size of Root, Docker partitions in F26 Atomic Host storage setup`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
Nit> Can we change this from Docker partition to Container Image partition.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/197
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
A couple of things here.  We plan on renaming docker-storage-setup -> 
container-storage-setup.  We want to allow contianer-storage-setup be able to 
setup multiple container runtimes.  Docker, CRI-O, perhaps others.

So having magic tools that figure out mount points like /var/lib/docker need to 
stop.  We already are hacking up the script in order to support docker-latest.  

So naming the mount points and the volume name should not be much of a 
hardship. Also the distribution has full ability to hard code this into the 
config file.

docker package can setup a unit file that sets the LABELS appropriate for 
docker and CRI-O/OCID can set up the defaults for it.

But we end up with just one container-storage-setup package.

DON'T Hard code "dockerisms" into any more tools.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #196 `moving to docker 1.13 in Fedora 25`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
I think we should get docker-1.13 into Rawhide right away.  The problem with 
putting it into Fedora 25 is it has not been fully vetted with OpenShift and 
Kubernetes yet.  I don't believe we should swap out the docker version their 
until OpenShift is ready.

Putting it into updates-testing and leaving it there until OpenShift says it is 
ready to consume it the best option.  I think we should also create a system 
container for Fedora 25 with the docker-1.13 runtime in it which would allow 
Fedora Atomic Host users to consume it.  We really need to start getting some 
play time with system containers, and this is probably the best time.

@gscrivano Has done some nice work on this, and it is time to get it exposed.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/196
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: docker-latest in Fedora

[Daniel J Walsh]

On 01/13/2017 08:38 AM, Antonio Murdaca wrote:
> Hi, 
>
> Seems like no people are really using docker-latest in Fedora. I
> realized that because the version in F25 is old and nobody adds karma
> to the updates in bodhi there. Is there any real user of docker-latest
> in Fedora? Just asking because it's a maintenance cost to always
> rebuild that as well (even if I automated it a bit). To my knowledge,
> openshift guys aren't really using it either. Should we spread the
> voice about it? What do you think? 

The only time to care about it, would be when docker is way behind
docker-latest.  For example docker-1.10 versus docker-latest-1.12.

I would hope with system containers we could start to get away from
docker-latest, It would probably be more effective to ship a system
container that openshift could use in Rawhide and then support that then
continue with docker-latest.  Then we would just ship the current docker
for a run of fedora.  Updating the docker system container as OpenShift
needs change.

The way I see it, docker-1.12 shipped with Fedora 25, we would never
update it except for minor release.  docker-1.12.6 for example.  But if
docker-1.13 ships, then we just package that for Rawhide and make a
rawhide system container available with it.  If users want to run
docker-1.13 they would need to run it in a system container.

This would get us experience in handling of system containers.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
Exported containers get written by default to /var/lib/atomic/migrate, this can 
be overwritten with the `--dir` option.

Should re `atomic storage reset` do the atomatic space recaptor of the 
docker-root-lv?  @vgoyal ?



``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
@jberkus The tools will work fine if you just want to start fresh and blow away 
your container images.

```
atomic storage reset
```
Should delete everything, then you change your default backend using

```
atomic storage modify --driver ...
```

Only time you would need extra space would be if you wanted to export/import 
your images.  

Without using separate partitions, I end up having to reinstall the system in 
order to setup separate partitions.

If you are using containers correctly, destroying your images, should not be 
too painful. :^)

``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #186 `switch to overlay2`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
I disagree with 2.  

We have tools that allow you to switch back to devicemapper if their is 
partioning, which is why we want to keep partitioning.  If this was easy to 
switch from no partioning to partitioned, then I would agree with just default 
to overlay without partitions.

``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/16/2016 03:16 AM, Marius Vollmer wrote:
> Vivek Goyal  writes:
>
>> [...] And if overlayfs does not work for a user, switching back to
>> devmapper should be easy.
>>
>> - atomic storage reset
>> - edit /etc/sysconfig/docker-storage-setup and set
>>   STORAGE_DRIVER=devicemapper
>> - restart docker
> Should we have a button in Cockpit to do this?
>
Yes I think have cockpit provide mechanisms to switch from one store to
another.  And to preserve
state while doing it would be nice.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/15/2016 12:18 PM, Josh Berkus wrote:
> Dan, Dusty, Vivek:
>
> So far nobody has defined (technically) the exact problem with overlayfs
> and how it affects applications which want to write data inside the
> container.
>
> Note that just saying "don't use Overlay for persistent data" really
> isn't good enough.  Apps in containers frequently write data to places
> users aren't aware of, such as writing port information to /var/run.
> While this data may not be important to the user, the app will fail if
> it errors out.
>
> Pushing a change which will cause 30% of a user's containers to start
> failing for reasons which are opaque to them is not something we should
> do lightly.
>
Josh.  More likely this will cause .0001% of users to fail.  But it is
not a Posix
compliant database, so their could be issues. 

Only other issues I know of now are the handling of "special" files things
like sock_files, character devices etc.  But these should almost always
be on
tmpfs places like /dev and /run.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/14/2016 10:38 AM, Dusty Mabe wrote:
>
> On 12/14/2016 07:51 AM, Daniel J Walsh wrote:
>> I have heard that the issue with yum/rpm is being worked on in the kernel.
>> For those that to not know the issue is for programs that open a file twice
>> once for readonly and then later for read/write.  In the first open the file 
>> is
>> on the lower file system.  When you open the second time for read/write,
>> Overlay does a COPY/UP which creates a separate file.  The program thinks
>> that it has the same file opened twice, but it actually has two different 
>> files
>> open.
> That is great information. Is there an issue somewhere where we can
> track the progress of the "fix"?
>
> Dusty
Vivek do you have an answer to this?
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/13/2016 02:18 PM, Dusty Mabe wrote:
>
> On 12/13/2016 01:02 PM, Colin Walters wrote:
>> On Tue, Dec 13, 2016, at 12:45 PM, Clayton Coleman wrote:
>>> Are the POSIX issues in applications running on overlay mostly resolved 
>>> now?  I.e. if we flipped the default would be reasonably able to support a 
>>> diverse range of Linux workloads without the risk that previously existed?
>> overlayfs will never be fully POSIX compatible, but I think that's OK,
>> because remember - you shouldn't use overlayfs for persistent data,
>> or really anything that's not code/config files (and we want to get
>> to where that's overlayfs-type semantics for builds, and read-only
>> for deployment).  Data should be in Kube persistent volumes etc.
>>
>> I think the thing to focus on is tools that are run during builds - the
>> yum-in-overlayfs bug is a good example, because the RPM database
>> *is* a database which is the type of workload that's going to
>> be sensitive to the overlayfs semantics.  How many of those
>> are there?  Probably not many, I suspect most of the compat
>> issues with userspace have been shaken out by now.
>>
>> (But long term we may end up in a situation where people
>>  who want to run e.g. rhel5's yum in a container need to
>>  somehow fall back to devmapper)
>>
> So if we were to propose the "overlayfs as default" change for all of
> Fedora, would you consider that to be problematic considering your 
> "you shouldn't use overlayfs for persistent data," stance. In the case
> of a user running pet containers on their local desktop environment,
> what is the sentiment?
>
> Dusty
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Yes I might hesitate to run PET Containers in Overlay.  I hope to
get to the point where you can run different container workloads
on different backends.  It might be better to run a PET Container on
OSTree using runc and not going through the client server operation
of docker.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

Yes I plan on writing a blog on this once we have an update to
docker-storage-setup to handle setting up /var/lib/docker on a separate
partition.

https://github.com/projectatomic/docker-storage-setup/pull/175


Once we get this merged, we could easily move to overlayfs as default on
atomic host, but still allow a user to switch from overlay back to
devicemapper.

On 12/13/2016 12:23 PM, Chris Murphy wrote:
> On Tue, Dec 13, 2016 at 8:01 AM, Daniel J Walsh <dwa...@redhat.com> wrote:
>> The only way to change from one storage to the other is to use
>>
>> atomic storage export
>> change the config
>> atomic storage reset
>> atomic storage import
> Nifty.
>
> A migration tool would have to juggle the potential for insufficient
> space in /var for the export; or sufficient space for export but then
> not importing. And then there's cleanup of otherwise dead space used
> by device mapper. So possibly more than one fs resize is necessary.
> I'd say probably leave things alone for upgrades, but documenting a
> strategy for migrating to overlay is OK.
>
>
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/12/2016 05:53 PM, Josh Berkus wrote:
> On 12/12/2016 02:24 PM, Dusty Mabe wrote:
>
>> I think the rationale is that we'd like to not have a much different
>> experience whether you are using docker on atomic host or not. My
>> thoughts are that overlay is where we want to be in the future and
>> Fedora is the first place we should try that out.
>>
>> DM would still be supported via configuration of docker-storage-setup,
>> just like overlay is supported today in the same way.
> I'd the impression from the Docker hackers that overlayfs was their
> future platform.
>
Docker is moving to a default of Overlay2, I think we should follow this
lead.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/12/2016 05:19 PM, Jason Brooks wrote:
> On Mon, Dec 12, 2016 at 2:12 PM, Dusty Mabe  wrote:
>> After I get a bug[1] fixed and out the door I'm going to publish
>> a blog post/docs on setting up Fedora 25 Atomic host and/or Cloud
>> base to use overlay2 as the storage driver for docker.
>>
>> I'd like for everyone that can to test this out and to start running
>> their container workloads with overlay2 with selinux enabled and let's
>> file bugs and get it cleaned up for Fedora 26 release.
> This makes sense as the default for the docker package for non-atomic
> fedora, since the alternative is loopback storage -- are you
> suggesting this as a change for the atomic host as well? If so, what's
> the rationale there?
Overlay allows better memory sharing, so you can run more containers on
a single host
then you can with Devicemapper.

We are working on patches to docker-storage-setup to allow it to
allocate overlayfs to the
remaining storage similar to what we do with devicemapper for Atomic Host.
>> Should we file this as a "change" for Fedora 26?
>>
>> Dusty
>> ___
>> cloud mailing list -- cloud@lists.fedoraproject.org
>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora 26 change: using overlayfs as default

[Daniel J Walsh]

On 12/12/2016 05:16 PM, Dusty Mabe wrote:
>
> On 12/12/2016 05:13 PM, Josh Berkus wrote:
>> On 12/12/2016 02:12 PM, Dusty Mabe wrote:
>>> After I get a bug[1] fixed and out the door I'm going to publish 
>>> a blog post/docs on setting up Fedora 25 Atomic host and/or Cloud
>>> base to use overlay2 as the storage driver for docker.
>>>
>>> I'd like for everyone that can to test this out and to start running
>>> their container workloads with overlay2 with selinux enabled and let's
>>> file bugs and get it cleaned up for Fedora 26 release.
>>>
>>> Should we file this as a "change" for Fedora 26?
>> I'd say so, yes.
> Can you help to figure out what we need to do for that?
>
>> Also, someone needs to test the case of migrating an existing system and
>> how that looks.
> I don't think there is a migration. You can really go from one to the
> other. Since docker-storage-setup only runs on first boot then we
> shouldn't have to handle this case, correct?
>
> Dusty
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
The only way to change from one storage to the other is to use

atomic storage export
change the config
atomic storage reset
atomic storage import

___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #178 `Fix locale support in base image.`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
How large is localctl?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/178
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #176 `status of kubernetes on fedora atomic 25`

[Daniel J Walsh]

dwalsh added a new comment to an issue you are following:
``
I have asked Giuseppe Scrivano  to move forward on system 
containers to implement kubernetes workflow on atomic host.  He currently has 
most of services available as system containers and is moving them into 
github.com/projectatomic/atomic-system-containers

We need to get these containers built for Fedora 25.

He even has an experimental system container that runs docker in it.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/176
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Blogs for F25 release

[Daniel J Walsh]

On 11/10/2016 08:47 AM, Dusty Mabe wrote:
>
> On 11/10/2016 06:12 AM, Daniel J Walsh wrote:
>>
>> On 11/09/2016 12:43 PM, Dusty Mabe wrote:
>>> I believe we need to communicate a few things for F25:
>>>
>>> 1 - overlayfs - what it is, how to enable it in the various f25 images we 
>>> release
>>> 2 - containerized k8s - no longer in atomic host so we have to show people 
>>> how to use it
>>>
>>> I am already planning to write the first blog post. Any volunteers for the 
>>> 2nd one.
>>>
>>>
>>> Any more blogs that need to go out? 
>>>
>>> Dusty 
>>> ___
>>> cloud mailing list -- cloud@lists.fedoraproject.org
>>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>> I also plan on writing a security blog on OverlayFS with SELinux on
>> Fedora 25.
> Sounds good. You can focus on security and I can focus on showing
> people how to set it up out of the box.
>
> Dusty
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
Great.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Blogs for F25 release

[Daniel J Walsh]

On 11/09/2016 12:43 PM, Dusty Mabe wrote:
> I believe we need to communicate a few things for F25:
>
> 1 - overlayfs - what it is, how to enable it in the various f25 images we 
> release
> 2 - containerized k8s - no longer in atomic host so we have to show people 
> how to use it
>
> I am already planning to write the first blog post. Any volunteers for the 
> 2nd one.
>
>
> Any more blogs that need to go out? 
>
> Dusty 
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
I also plan on writing a security blog on OverlayFS with SELinux on
Fedora 25.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Add mdadm to Fedora Atomic Host

[Daniel J Walsh]

On 08/18/2016 12:00 PM, Dusty Mabe wrote:
> We need to add mdadm to Fedora Atomic Host so that we can support software 
> raid disk setups.
>
> https://pagure.io/fedora-atomic/pull-request/8
>
No way to do this with SPC?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [atomic-devel] docker does not work in F24 Atomic

[Daniel J Walsh]

On 05/11/2016 01:03 PM, Dusty Mabe wrote:

Hey All,

As far as I can tell Docker is broken in F24 atomic. We have had
issues with docker for a while now but testing on fedora cloud base
from the updates-testing repo seemed to show the problem as resolved.

However, now that docker-1.10.3-7.gita41254f.fc24.x86_64 is in stable
we now see that it is still failing in Atomic Host:
https://bugzilla.redhat.com/show_bug.cgi?id=1334588

And even more so the newer version (in updates-testing) is still
failing if I use `ostree admin unlock --hotfix` to try to test it out.
See https://bugzilla.redhat.com/show_bug.cgi?id=1334588#c6

Can we please get all hands on deck to try to figure out this issue
for F24 Atomic?

Thanks,
 Dusty


Dusty where can I get a vagrant image or a libvirt image I can play with?
___
cloud mailing list
cloud@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: Fedora 24 and Atomic

[Daniel J Walsh]

On 03/17/2016 10:07 AM, Matthew Miller wrote:

Hey, so, Dennis tells me we don't currently have an F24 two-week
Atomic. I don't think we need Atomic as part of the actual Alpha
compose/release, but as I understand it, the plan is to cut the
two-week Atomic over to F24 base at the F24 release. In order to do
that, it seems like having prerelease images built and passing tests is
important or am I missing something?





Makes sense to me.
___
cloud mailing list
cloud@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: Putting Networkd on cloud Atomic and base image for F24

[Daniel J Walsh]

On 12/21/2015 04:05 PM, Subhendu Ghosh wrote:
>
>
> On Mon, Dec 21, 2015 at 11:14 AM, Peter Robinson  > wrote:
>
> On Mon, Dec 21, 2015 at 2:10 PM, Subhendu Ghosh
> > wrote:
> > Both networks and NM might be needed in the future. We should
> look into how
> > we can build images that support both or look to build alternate
> images.
> >
> > NM stack is useful for WiFi and cellular enabled images in IoT
> gateway
> > devices. I don't really see networkd supporting the those
> requirements.
>
> I would expect an IoT image for a gateway device would need a bunch of
> other things that wouldn't be relevant for a generic cloud image so
> would it be better to target that as a separate image rather than
> trying to jam everything into one? It would be easier to define and a
> lot simpler in terms of QA and other moving parts.
>
>
> True - that's why I noted there may be use cases for both. And we
> should attempt to wire up the usability thru both stacks even if we
> end up building 2 different images.
>
> Also as Colin noted, Atomic host is likely to get used on both
> bare-metal and cloud  - so giving networkd a full press effort for a
> release cycle might be good. In not like these decisions cannot be
> changed.
>
> -subhendu
>
>  
>
>
> ___
> cloud mailing list
> cloud@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
I thought NM was starting to use networkd under the covers?
___
cloud mailing list
cloud@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: Why I'm excited about Atomic for Fedora

[Daniel J Walsh]

On 10/28/2015 02:08 PM, Matthew Miller wrote:
> On Wed, Oct 28, 2015 at 10:59:01PM +0530, Aditya Patawari wrote:
>> For me, I often have to move away from Fedora Cloud or Server editions
>> because of limited support cycle. I don't want to run a distribution
>> in my production environment where security updates won't be available
>> after a short amount of time. I am not sure if atomic updates or
>> ostree would help here. I would love to run more of Fedora Cloud or
>> Server instances if, at least, security updates are supported for a
>> longer time.
> With Atomic, the idea would be that you'd basically just move to the
> newer host release seamlessly, because your containers will run in the
> same way.
>
>> That said, I still have a fair number of instances running in
>> production because Fedora often packages newer releases of tools and
>> software which is required to run some of the applications.
> And, on the other side of the above, you can update your containers as
> fits your schedule, and mix and match e.g. CentOS and Fedora containers
> as appropriate.
>
Theoretically you should be able to move from f23 to f24 with an atomic
update when f24 happens.
And would still be able to reboot back into f23 if you had problems with
f24.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [atomic-devel] Introducing sen: terminal user interface for docker engine

[Daniel J Walsh]

On 10/27/2015 07:41 AM, Joe Brockmeier wrote:
> On Tuesday, October 27, 2015 10:13:17 AM Stef Walter wrote:
>> On 27.10.2015 09:59, Tomas Tomecek wrote:
>>> Quoting Joe Brockmeier (2015-10-27 01:55:17)
>>>
 Any chance this is going to be a Cloud feature for Fedora 24?
 (Probably jst a bit late to slip into F23 now.)

 Best,

 jzb
>>> Way too late for f23 since I just made it work recently and I'm sure
>>> it's full of bugs (and missing features).
>>>
>>> I'm planning to package this to Fedora, no question. Can submit it
>>> as a f24 feature.
> Nice. I'm CC'ing the cloud working group here as well. 
>
>>> One could think that sen is directly competing with cockpit. That's
>>> true. The difference is target audience -- sen is meant for folks
>>> who are not fans of webuis and prefer terminal instead. Not sure if
>>> this should be mentioned in the feature proposal.
> Nope, totally different audience. 
>  
>> Yup. Doesn't compete with Cockpit at all. In fact you could use it
>> within Cockpit's terminal, if you were feeling really funky ...
> I like this. Container-ception? 
>
> Best, 
>
> jzb
It would be nice if they shared some of the same code though, if possible?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux denials when starting docker in F23

[Daniel J Walsh]

On 10/10/2015 09:09 AM, Dusty Mabe wrote:
>
>
> On 10/10/2015 08:02 AM, Daniel J Walsh wrote:
>>
>> On 10/09/2015 01:07 PM, Bruno Wolff III wrote:
>>> On Fri, Oct 09, 2015 at 12:43:52 -0400,
>>>   Dusty Mabe <du...@dustymabe.com> wrote:
>>>>
>>>> On 10/08/2015 03:06 PM, Dusty Mabe wrote:
>>>>> and this is in the journal:
>>>>>
>>>>> ```
>>>>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>>>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>>>> msg='Unknown permission stop for class system
>>>>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>>>>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>>>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>>>> msg='Unknown permission stop for class system
>>>>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>>>>> ```
>>>> Any comments on the USER_AVC statements? Even if I have docker.pp I
>>>> still see these.
>>> I got something similar running getmail from cron. I asked about it on
>>> the selinux list but didn't get any suggestions on how to make a rule
>>> to allow this (audit2allow doesn't seem to handle this avc.)
>>> ___
>>> cloud mailing list
>>> cloud@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>> If you systemctl daemon-rexec does the problem go away?
>
> No, I still see them. I did an reexec and then started and stopped a
> container. The `USER_AVC` messages get spit out to the journal on both
> start and stop.
>
> ```
> [root@footest ~]# journalctl -f | grep USER_AVC &
> [1] 11388
> [root@footest ~]# docker run -it --rm busybox /bin/sh
> Oct 10 13:08:16 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
> permission start for class system exe="/usr/lib/systemd/systemd"
> sauid=0 hostname=? addr=? terminal=?'
> / #
> / # exit
> Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
> permission stop for class system exe="/usr/lib/systemd/systemd"
> sauid=0 hostname=? addr=? terminal=?'
> Oct 10 13:08:23 footest audit[1]: USER_AVC pid=1 uid=0 auid=4294967295
> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown
> permission stop for class system exe="/usr/lib/systemd/systemd"
> sauid=0 hostname=? addr=? terminal=?'
> ```
So this means that selinux policy does not define a start call for the
system class.  Meaning this is either a bug in systemd, systemd is
asking for a start access on system when it should be asking for it on a
service.  Or selinux-policy needs to add a start permission for system.
  I am thinking this is probably a problem with systemd.  Adding
Miroslav to
see if he knows.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux denials when starting docker in F23

[Daniel J Walsh]

On 10/09/2015 01:07 PM, Bruno Wolff III wrote:
> On Fri, Oct 09, 2015 at 12:43:52 -0400,
>  Dusty Mabe  wrote:
>>
>>
>> On 10/08/2015 03:06 PM, Dusty Mabe wrote:
>>> and this is in the journal:
>>>
>>> ```
>>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>> msg='Unknown permission stop for class system
>>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>>> msg='Unknown permission stop for class system
>>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>>> ```
>>
>> Any comments on the USER_AVC statements? Even if I have docker.pp I
>> still see these.
>
> I got something similar running getmail from cron. I asked about it on
> the selinux list but didn't get any suggestions on how to make a rule
> to allow this (audit2allow doesn't seem to handle this avc.)
> ___
> cloud mailing list
> cloud@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
If you systemctl daemon-rexec does the problem go away?
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: selinux denials when starting docker in F23

[Daniel J Walsh]

On 10/08/2015 03:23 PM, Dusty Mabe wrote:
>
>
> On 10/08/2015 03:06 PM, Dusty Mabe wrote:
>> Hey guys anybody seen these when starting
>> docker-1.8.2-5.gitcb216be.fc23.x86_64:
>>
>> ```
>> Oct 08 18:55:47 cloudhost.localdomain audit[1513]: AVC avc: denied {
>> read } for  pid=1513 comm="iptables" path="net:[4026531957]"
>> dev="nsfs" ino=4026531957 scontext=system_u:system_r:iptables_t:s0
>> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
>> ```
>>
>> Nevertheless the docker daemon is up and running but if I start a
>> container and then force remove it I see:
>>
>> ```
>> Error deleting container: Error response from daemon: Cannot destroy
>> container
>> 710f834e316946a422a00fb3470b895b387519ecb01a5b195cc818b9764f82a7:
>> Failed to set container state to RemovalInProgress: Status is already
>> RemovalInProgress
>> ```
>>
>> and this is in the journal:
>>
>> ```
>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>> msg='Unknown permission stop for class system
>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>> Oct 08 19:04:31 cloudhost.localdomain audit[1]: USER_AVC pid=1 uid=0
>> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
>> msg='Unknown permission stop for class system
>> exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
>> ```
>
> Also (on a separate machine - this time the f23 cloud vagrant box) - I
> am seeing this when I run `docker run -it --rm busybox /bin/sh`:
>
> ```
> [root@f23 ~]# docker run -it --rm busybox /bin/sh
> permission denied
> Error response from daemon: Cannot start container
> 48f491260754d82c292f0d52154cb9fc45f8dede1a9bdc9adbe9a465406671e5: [8]
> System error: permission denied
> ```
>
> and from the journal:
>
> ```
> Oct 08 19:19:01 f23 audit[998]: AVC avc:  denied  { transition } for
> pid=998 comm="exe" path="/bin/sh" dev="dm-3" ino=33555457
> scontext=system_u:system_r:unconfined_service_t:s0
> tcontext=system_u:system_r:svirt_lxc_net_t:s0:c581,c843 tclass=process
> permissive=0
> ```
> ___
> cloud mailing list
> cloud@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
This looks like docker is running with the wrong context.  Make sure
docker-selinux is installed. and /usr/bin/docker has the right label.

restorecon -v /usr/bin/docker

If docker is still labeled bin_t, then check if docker.pp is installed

semodule -l | grep docker

If you don't see docker listed, check if docker-selinux is installed.

yum install docker-selinux

If docker label changes you need to restart the docker daemon

systemctl restart docker
ps -eZ | grep docker

Should be running as docker_t

There could be a conflict between selinux-policy and docker-selinux, I
think selinux-policy has dropped docker.pp from its list of policy
packages, which it should do.
docker-selinux is now supposed to ship it.   But it could be
docker-selinux is installed and then selinux-policy gets updated and
removes the docker.pp file.

Just speculating on what could cause this.
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Docker mysterious behavior in F22

[Daniel J Walsh]

On 05/17/2015 08:23 PM, Dusty Mabe wrote:
 On Sun, May 17, 2015 at 07:43:38PM -0400, Matthew Miller wrote:
 On Sun, May 17, 2015 at 07:18:05PM -0400, Dusty Mabe wrote:
 So. Some new information. Looks like there is a new docker in testing [1] 
 that does not have this problem. We need to add karma to this. Please test 
 and upvote/downvote!
 Matt should I still open a bug for this issue so it can be proposed as
 a freezeexception?
 Yes -- otherwise it won't get included in the composes and will be
 shipped as a zero-day update.
 https://bugzilla.redhat.com/show_bug.cgi?id=1222352

 It would suck if we shipped F22 atomic with a Docker that can't run
 apache :( 
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
We have been shipping a /run on tmpfs docker for some time.  If the
docker image has /run/httpd
the docker command is supposed to copy the contents in the images /run
onto the tmpfs.  If this is
not happening it is a bug.  Of course httpd should be able to handle the
fact that /run/httpd does not exists
and create it. 
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf in Dockerfiles

[Daniel J Walsh]

Scott we found an interesting problem with libvirt protections on
/dev/kvm.  If you run this container on an atomic machine, the device
has the wrong protections.  You need to add chmod 666 /dev/kvm to make
it work, or

chmod 660 /dev/kvm
chown root:qemu /dev/kvm

I think this would break on other machines that do not have libvirt
installed on the host.


On 03/19/2015 10:20 AM, Scott Collier wrote:


 On 03/11/2015 09:40 AM, Major Hayden wrote:
 On 03/11/2015 09:23 AM, Joe Brockmeier wrote:
  I'm CC'ing Scott b/c, if I'm not mistaken, he's done quite a lot of
  the work so far on the Dockerfiles - but also, I think he's looking
  for assistance there in keeping the effort going.
 I'll be glad to help maintain/update those Dockerfiles if needed, Scott.

  Thanks Major.  Here's a summary of things I think we should be
 looking at in general, not just Dockerfile maintenance:

  1. Ensuring dnf support on Fedora 22 images.  This means figuring
 out how to manage dockerfiles in a manner that both dnf or yum can
 work.  For example, the FROM line will determine what package
 installation method we will use.  If it's FROM fedora:rawhide, should
 use dnf, if it's FROM fedora:21, should use yum.  Just need to think
 that through and how we want to handle.  I haven't played around with
 dnf yet.

  2. Need READMEs for the libvirt images:

  https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/libvirt
 
 https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/systemd/libvirt

  3. Need some extra eyes on all PRs and images that come in.  Might
 be good to require a +1 from two maintainers before merging a
 request?  Thoughts?

  4. I'd like to set up some CI on these where and if it makes sense.
 Some triggers: docker package updates, Dockerfile updates, etc...
 Something simple: build the image, run the image, test for an expected
 result.

  5. Does it make sense to add some kubernetes support / examples to
 these?  I know not all of these apps are scalable or usable in a
 production k8s cluster, per se, but dropping in a yaml file for a few
 select images, so people can explore and learn wouldn't hurt. It could
 sit right by the Dockerfile.  People could build the image, and deploy
 in a k8s environment.

  6. Now that the LABEL patch has been (or will be merged) into
 Docker, we'll want people to start testing the LABEL functionality in
 fedora-dockerfiles and take advantage of that with the new atomic
 package.  We'll want to abstract away any complex docker install /
 docker run commands moving forward.  This will take some effort. This
 will be very helpful on an any host with the atomic tool.

  Anything else? Thoughts?



 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Daniel J Walsh]

On 03/09/2015 12:03 PM, Michael P. McGrath wrote:
 - Original Message -
 From: Daniel J Walsh dwa...@redhat.com
 To: Fedora Cloud SIG cloud@lists.fedoraproject.org
 Sent: Monday, March 9, 2015 10:45:42 AM
 Subject: Re: Atomic 2 week releases


 On 03/09/2015 11:34 AM, Michael P. McGrath wrote:
 Hey all, I wanted to start a thread about doing more frequent Atomic
 releases in Fedora.
 In particular I'd like to start building a new atomic release every two
 weeks that
 includes the latest version of Docker, Kubernetes, and OSTree for the
 Fedora Atomic
 images.

 The problem I'm trying to solve here is that there is a lot of work going
 on upstream in
 the Docker and Kubernetes communities and there isn't a very good way to
 consume that
 upstream work on a Red Hat/Fedora/CentOS system today.  By focusing on more
 regular
 releases, we can fix some of the issues we've seen (like demoing new
 features at a
 conference that people can't actually use).

 There are still some details to work out like whether to base this image on
 Fedora
 $CURRENT or rawhide and what to do when the builds fail.  Fortunately, this
 can possibly
 be done without much additional change to the release process.  We're
 already rebuilding
 the docker/kubernetes/ostree rpms almost daily, and there are nightly
 builds as well
 (at least in rawhide).

 If we can pull a 2 week process off, I'd like to see that followed by a 4
 week process
 in CentOS which will behave similarly but with the slightly slower-moving,
 more stable bits.

 Thoughts?

 [1] http://www.projectatomic.io/download/

 --
 Mike McGrath | mmcgr...@redhat.com | (312) 660-3547
 Atomic | Red Hat Chicago | http://projectatomic.io/
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 I guess the question here would be around where we would do the releases?

 In a perfect world, I would like to see Daily releases in Rawhide, as
 long was we had an installable
 tree.  Every two weeks would be in Fedora Stable.  If others wanted to
 back port to Fedora Stable-1
 that would be ok, but I don't see that as the primary focus.

 We would be doing a lot of this with the Docker Devel branch, along with
 some patches that we are experimenting
 with.

 I am sure K8s would be doing something similar.

 What version of docker would be in Fedora $CURRENT?  stable or devel?  And
 would that version go out to both Atomic Fedora *and* regular Fedora users
 or just Atomic Fedora?

 -Mike
Those are the questions I would like to have answered.
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Daniel J Walsh]

On 03/10/2015 01:09 PM, Michael P. McGrath wrote:
 - Original Message -
 From: Daniel J Walsh dwa...@redhat.com
 To: Fedora Cloud SIG cloud@lists.fedoraproject.org
 Sent: Tuesday, March 10, 2015 11:31:27 AM
 Subject: Re: Atomic 2 week releases


 On 03/09/2015 12:03 PM, Michael P. McGrath wrote:
 - Original Message -
 From: Daniel J Walsh dwa...@redhat.com
 To: Fedora Cloud SIG cloud@lists.fedoraproject.org
 Sent: Monday, March 9, 2015 10:45:42 AM
 Subject: Re: Atomic 2 week releases


 On 03/09/2015 11:34 AM, Michael P. McGrath wrote:
 Hey all, I wanted to start a thread about doing more frequent Atomic
 releases in Fedora.
 In particular I'd like to start building a new atomic release every two
 weeks that
 includes the latest version of Docker, Kubernetes, and OSTree for the
 Fedora Atomic
 images.

 The problem I'm trying to solve here is that there is a lot of work going
 on upstream in
 the Docker and Kubernetes communities and there isn't a very good way to
 consume that
 upstream work on a Red Hat/Fedora/CentOS system today.  By focusing on
 more
 regular
 releases, we can fix some of the issues we've seen (like demoing new
 features at a
 conference that people can't actually use).

 There are still some details to work out like whether to base this image
 on
 Fedora
 $CURRENT or rawhide and what to do when the builds fail.  Fortunately,
 this
 can possibly
 be done without much additional change to the release process.  We're
 already rebuilding
 the docker/kubernetes/ostree rpms almost daily, and there are nightly
 builds as well
 (at least in rawhide).

 If we can pull a 2 week process off, I'd like to see that followed by a 4
 week process
 in CentOS which will behave similarly but with the slightly
 slower-moving,
 more stable bits.

 Thoughts?

 [1] http://www.projectatomic.io/download/

 --
 Mike McGrath | mmcgr...@redhat.com | (312) 660-3547
 Atomic | Red Hat Chicago | http://projectatomic.io/
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 I guess the question here would be around where we would do the releases?

 In a perfect world, I would like to see Daily releases in Rawhide, as
 long was we had an installable
 tree.  Every two weeks would be in Fedora Stable.  If others wanted to
 back port to Fedora Stable-1
 that would be ok, but I don't see that as the primary focus.

 We would be doing a lot of this with the Docker Devel branch, along with
 some patches that we are experimenting
 with.

 I am sure K8s would be doing something similar.

 What version of docker would be in Fedora $CURRENT?  stable or devel?  And
 would that version go out to both Atomic Fedora *and* regular Fedora users
 or just Atomic Fedora?

 -Mike
 Those are the questions I would like to have answered.
 Stable in current, devel in rawhide.  We just don't yet have the toolchains to
 split different versions of our packages onto the same Fedora.  We'll have to
 see if there's a way to do it when Adam joins up.

 -Mike
I was thinking a long the lines of putting a new docker package into
updates at the same time we release it to
atomic.  Then after a couple of weeks releasing the docker package to
updates.   But yes we will be shipping
docker upstream minor releases as updates along with some experimental
patches (Patches that have not made it
upstream yet.) 
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Atomic 2 week releases

[Daniel J Walsh]

On 03/09/2015 11:34 AM, Michael P. McGrath wrote:
 Hey all, I wanted to start a thread about doing more frequent Atomic releases 
 in Fedora.
 In particular I'd like to start building a new atomic release every two weeks 
 that
 includes the latest version of Docker, Kubernetes, and OSTree for the Fedora 
 Atomic
 images.

 The problem I'm trying to solve here is that there is a lot of work going on 
 upstream in
 the Docker and Kubernetes communities and there isn't a very good way to 
 consume that
 upstream work on a Red Hat/Fedora/CentOS system today.  By focusing on more 
 regular
 releases, we can fix some of the issues we've seen (like demoing new features 
 at a
 conference that people can't actually use).  

 There are still some details to work out like whether to base this image on 
 Fedora
 $CURRENT or rawhide and what to do when the builds fail.  Fortunately, this 
 can possibly
 be done without much additional change to the release process.  We're already 
 rebuilding
 the docker/kubernetes/ostree rpms almost daily, and there are nightly builds 
 as well
 (at least in rawhide).

 If we can pull a 2 week process off, I'd like to see that followed by a 4 
 week process
 in CentOS which will behave similarly but with the slightly slower-moving, 
 more stable bits.

 Thoughts?

 [1] http://www.projectatomic.io/download/

 --
 Mike McGrath | mmcgr...@redhat.com | (312) 660-3547
 Atomic | Red Hat Chicago | http://projectatomic.io/
 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I guess the question here would be around where we would do the releases? 

In a perfect world, I would like to see Daily releases in Rawhide, as
long was we had an installable
tree.  Every two weeks would be in Fedora Stable.  If others wanted to
back port to Fedora Stable-1
that would be ok, but I don't see that as the primary focus.

We would be doing a lot of this with the Docker Devel branch, along with
some patches that we are experimenting
with.

I am sure K8s would be doing something similar.


___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: Running mesos-slave in Docker container (Atomic Discussion)

[Daniel J Walsh]

docker run --privileged

Turns off all of the docker security.

Has anyone tried to run a container for something like mesos that execs
docker commands, to maybe look like

docker run --privileged -v /:/host -v /run:/run -ti -net=host mesos /bin/sh

This would cause all of / to be mounted in /host and then you could execute

/host/usr/bin/docker for example.  Not sure why you would want
/var/lib/docker mounted into the mesos container.



On 09/23/2014 09:18 AM, Tim St Clair wrote:
 Scott - 

 When you mentioned running in privileged mode mode, what does that
 mean?  Could you provide more details.

 Cheers,
 Tim

 

 *From: *Tim Chen t...@mesosphere.io
 *To: *u...@mesos.apache.org, Gabriel Monroy gabr...@opdemand.com
 *Sent: *Tuesday, September 23, 2014 2:41:17 AM
 *Subject: *Re: Running mesos-slave in Docker container

 Hi Grzegorz,

 To run Mesos master|slave in a docker container is not straight
 forward because we utilize kernel features therefore you need to
 explicitly test out the features you like to use with Mesos with
 slave/master in Docker.

 Gabriel during the Mesosphere hackathon has got master and slave
 running in docker containers, and he can probably share his
 Dockerfile and run command.

 I believe one work around to get cgroups working with Docker run
 is to mount /sys into the container (mount -v /sys:/sys).

 Gabriel do you still have the command you used to run slave/master
 with Docker?

 Tim



 On Tue, Sep 23, 2014 at 12:24 AM, Grzegorz Graczyk
 gregor...@gmail.com mailto:gregor...@gmail.com wrote:

 I'm trying to run mesos-slave inside Docker container, but it
 can't start due to problem with mounting cgroups.

 I'm using:
 Kernel Version: 3.13.0-32-generic
 Operating System: Ubuntu 14.04.1 LTS
 Docker: 1.2.0(commit fa7b24f)
 Mesos: 0.20.0

 Following error appears:
 I0923 07:11:20.92147519 main.cpp:126] Build: 2014-08-22
 05:04:26 by root
 I0923 07:11:20.92160819 main.cpp:128] Version: 0.20.0
 I0923 07:11:20.92162019 main.cpp:131] Git tag: 0.20.0
 I0923 07:11:20.92162819 main.cpp:135] Git SHA:
 f421ffdf8d32a8834b3a6ee483b5b59f65956497
 Failed to create a containerizer: Could not create
 DockerContainerizer: Failed to find a mounted cgroups
 hierarchy for the 'cpu' subsystem; you probably need to mount
 cgroups manually!

 I'm running docker container with command:
 docker run --name mesos-slave --privileged --net=host -v
 /var/run/docker.sock:/var/run/docker.sock -v
 /var/lib/docker:/var/lib/docker -v
 /usr/local/bin/docker:/usr/local/bin/docker
 gregory90/mesos-slave --containerizers=docker,mesos
 --master=zk://localhost:2181/mesos --ip=127.0.0.1

 Everything is running on single machine.
 Everything works as expected when mesos-slave is run outside
 docker container.

 I'd appreciate some help.





 -- 
 Cheers,
 Timothy St. Clair
 Red Hat Inc.


 ___
 cloud mailing list
 cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: libvirt and SELlinux 'access denied' in a VM

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/24/2014 06:28 AM, Juerg Haefliger wrote:
 
 
 
 On Mon, Mar 24, 2014 at 11:23 AM, Juerg Haefliger jue...@gmail.com 
 mailto:jue...@gmail.com wrote:
 
 
 
 
 On Sat, Mar 22, 2014 at 11:46 AM, Daniel J Walsh dwa...@redhat.com
 mailto:dwa...@redhat.com wrote:
 
 On 03/21/2014 10:36 AM, Juerg Haefliger wrote:
 Hi,
 
 I started a VM using the official F20 cloud image, installed libvirt and 
 its dependencies and tried to create a guest but SELinux won't let me:
 
 [root@fedora-20 ~]# virsh create mini.xml error: Failed to create domain 
 from mini.xml error: Input/output error
 
 [root@fedora-20 ~]# journalctl | tail Mar 21 14:23:06 fedora-20
 systemd[1]: SELinux policy denies access. Mar 21 14:23:06 fedora-20 
 systemd-machined[7210]: Failed to start machine scope: Access denied Mar
 21 14:23:06 fedora-20 libvirtd[6856]: Input/output error
 
 [root@fedora-20 ~]# cat /var/log/libvirt/qemu/mini.log 2014-03-21 
 14:23:06.740+: starting up LC_ALL=C 
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
 QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name mini -S -machine 
 pc-i440fx-1.6,accel=tcg,usb=off -m 1024 -realtime mlock=off -smp 
 1,sockets=1,cores=1,threads=1 -uuid -2890-2015-1f87-cbfa725b1dd3 
 -nographic -no-user-config -nodefaults -chardev 
 socket,id=charmonitor,path=/var/lib/libvirt/qemu/mini.monitor,server,nowait

 
- -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
 virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 2014-03-21 
 14:23:06.744+: shutting down
 
 
 type=VIRT_MACHINE_ID msg=audit(1395412399.728:281): pid=6856 uid=0 
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm=mini 
 uuid=-2890-2015-1f87-cbfa725b1dd3 
 vm-ctx=system_u:system_r:svirt_tcg_t:s0:c728,c986 
 img-ctx=system_u:object_r:svirt_image_t:s0:c728,c986 model=selinux 
 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=success' 
 type=VIRT_MACHINE_ID msg=audit(1395412399.728:282): pid=6856 uid=0 
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm=mini 
 uuid=-2890-2015-1f87-cbfa725b1dd3 vm-ctx=107:107 img-ctx=107:107 
 model=dac exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? 
 res=success' type=USER_AVC msg=audit(1395412399.788:283): pid=1 uid=0 
 auid=4294967295 ses=4294967295  subj=system_u:system_r:init_t:s0
 msg='avc: denied  { start } for auid=-1 uid=-1 gid=-1 
 scontext=system_u:system_r:init_t:s0
 tcontext=system_u:system_r:init_t:s0 tclass=service
 exe=/usr/lib/systemd/systemd sauid=0 hostname=? addr=? terminal=?'
 type=VIRT_RESOURCE msg=audit(1395412400.015:284): pid=6856 uid=0
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=mem 
 reason=start vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3
 old-mem=0 new-mem=1048576 exe=/usr/sbin/libvirtd hostname=? addr=?
 terminal=? res=success' type=VIRT_RESOURCE msg=audit(1395412400.015:285):
 pid=6856 uid=0 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=vcpu 
 reason=start vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3
 old-vcpu=0 new-vcpu=1 exe=/usr/sbin/libvirtd hostname=? addr=?
 terminal=? res=success' type=VIRT_CONTROL msg=audit(1395412400.015:286):
 pid=6856 uid=0 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu op=start 
 reason=booted vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3
 vm-pid=-1 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=?
 res=failed'
 
 I'm not overly familiar with SELinux. Is this a configuration issue? Am
 I missing some policy packages or could this be an issue with the cloud 
 image?
 
 Works fine when I disable SELinux.
 
 Google found this, but it's old and apparently resolved: 
 https://bugzilla.redhat.com/show_bug.cgi?id=860235
 
 Thanks ...Juerg
 
 
 
 ___ cloud mailing list 
 cloud@lists.fedoraproject.org mailto:cloud@lists.fedoraproject.org 
 https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of 
 Conduct: http://fedoraproject.org/code-of-conduct
 
 
 There is no SELinux data that you posted.  I don't think your machine is 
 mislabeled.  Doing the /.autorelabel dance is a waste of time.
 
 ausearch -m avc,user_avc -ts recent
 
 After you have the problem, to see if SELinux posted any error messages.
 
 If there are no messages then try to turn off dontaudit rules.
 
 semodule -DB Run your test ausearch -m avc,user_avc -ts recent
 
 
 This is all I get:
 
 time-Mon Mar 24 10:21:18 2014 type=USER_AVC
 msg=audit(1395656478.686:22577): pid=1 uid=0 auid=4294967295
 ses=4294967295  subj=system_u:system_r:init_t:s0 msg='avc:  denied  {
 start } for auid=-1 uid=-1 gid=-1 scontext=system_u:system_r:init_t:s0 
 tcontext=system_u:system_r:init_t:s0 tclass

Re: libvirt and SELlinux 'access denied' in a VM

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/24/2014 08:44 AM, Juerg Haefliger wrote:
 
 
 
 On Mon, Mar 24, 2014 at 1:14 PM, Daniel J Walsh dwa...@redhat.com 
 mailto:dwa...@redhat.com wrote:
 
 On 03/24/2014 06:28 AM, Juerg Haefliger wrote:
 
 
 
 On Mon, Mar 24, 2014 at 11:23 AM, Juerg Haefliger jue...@gmail.com 
 mailto:jue...@gmail.com mailto:jue...@gmail.com
 mailto:jue...@gmail.com wrote:
 
 
 
 
 On Sat, Mar 22, 2014 at 11:46 AM, Daniel J Walsh dwa...@redhat.com
 mailto:dwa...@redhat.com mailto:dwa...@redhat.com
 mailto:dwa...@redhat.com wrote:
 
 On 03/21/2014 10:36 AM, Juerg Haefliger wrote:
 Hi,
 
 I started a VM using the official F20 cloud image, installed libvirt
 and its dependencies and tried to create a guest but SELinux won't let
 me:
 
 [root@fedora-20 ~]# virsh create mini.xml error: Failed to create
 domain from mini.xml error: Input/output error
 
 [root@fedora-20 ~]# journalctl | tail Mar 21 14:23:06 fedora-20 
 systemd[1]: SELinux policy denies access. Mar 21 14:23:06 fedora-20 
 systemd-machined[7210]: Failed to start machine scope: Access denied
 Mar 21 14:23:06 fedora-20 libvirtd[6856]: Input/output error
 
 [root@fedora-20 ~]# cat /var/log/libvirt/qemu/mini.log 2014-03-21 
 14:23:06.740+: starting up LC_ALL=C 
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin 
 QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name mini -S -machine 
 pc-i440fx-1.6,accel=tcg,usb=off -m 1024 -realtime mlock=off -smp 
 1,sockets=1,cores=1,threads=1 -uuid
 -2890-2015-1f87-cbfa725b1dd3 -nographic -no-user-config
 -nodefaults -chardev 
 socket,id=charmonitor,path=/var/lib/libvirt/qemu/mini.monitor,server,nowait

 
 
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
 -no-shutdown
 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
 virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 2014-03-21 
 14:23:06.744+: shutting down
 
 
 type=VIRT_MACHINE_ID msg=audit(1395412399.728:281): pid=6856 uid=0 
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm=mini 
 uuid=-2890-2015-1f87-cbfa725b1dd3 
 vm-ctx=system_u:system_r:svirt_tcg_t:s0:c728,c986 
 img-ctx=system_u:object_r:svirt_image_t:s0:c728,c986 model=selinux 
 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=success' 
 type=VIRT_MACHINE_ID msg=audit(1395412399.728:282): pid=6856 uid=0 
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm=mini 
 uuid=-2890-2015-1f87-cbfa725b1dd3 vm-ctx=107:107
 img-ctx=107:107 model=dac exe=/usr/sbin/libvirtd hostname=? addr=?
 terminal=? res=success' type=USER_AVC msg=audit(1395412399.788:283):
 pid=1 uid=0 auid=4294967295 ses=4294967295
 subj=system_u:system_r:init_t:s0 msg='avc: denied  { start } for
 auid=-1 uid=-1 gid=-1 scontext=system_u:system_r:init_t:s0 
 tcontext=system_u:system_r:init_t:s0 tclass=service 
 exe=/usr/lib/systemd/systemd sauid=0 hostname=? addr=? terminal=?' 
 type=VIRT_RESOURCE msg=audit(1395412400.015:284): pid=6856 uid=0 
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=mem 
 reason=start vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3 
 old-mem=0 new-mem=1048576 exe=/usr/sbin/libvirtd hostname=? addr=? 
 terminal=? res=success' type=VIRT_RESOURCE
 msg=audit(1395412400.015:285): pid=6856 uid=0 auid=4294967295
 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023
 msg='virt=qemu resrc=vcpu reason=start vm=mini
 uuid=-2890-2015-1f87-cbfa725b1dd3 old-vcpu=0 new-vcpu=1
 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=success'
 type=VIRT_CONTROL msg=audit(1395412400.015:286): pid=6856 uid=0
 auid=4294967295 ses=4294967295 
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu op=start 
 reason=booted vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3 
 vm-pid=-1 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? 
 res=failed'
 
 I'm not overly familiar with SELinux. Is this a configuration issue?
 Am I missing some policy packages or could this be an issue with the
 cloud image?
 
 Works fine when I disable SELinux.
 
 Google found this, but it's old and apparently resolved: 
 https://bugzilla.redhat.com/show_bug.cgi?id=860235
 
 Thanks ...Juerg
 
 
 
 ___ cloud mailing list 
 cloud@lists.fedoraproject.org mailto:cloud@lists.fedoraproject.org
 mailto:cloud@lists.fedoraproject.org
 mailto:cloud@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of 
 Conduct: http://fedoraproject.org/code-of-conduct
 
 
 There is no SELinux data that you posted.  I don't think your machine is 
 mislabeled.  Doing the /.autorelabel dance is a waste of time.
 
 ausearch -m avc,user_avc -ts recent
 
 After you have the problem, to see if SELinux posted any error messages.
 
 If there are no messages then try to turn off dontaudit rules.
 
 semodule -DB Run your test ausearch -m avc,user_avc

Re: libvirt and SELlinux 'access denied' in a VM

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/21/2014 10:36 AM, Juerg Haefliger wrote:
 Hi,
 
 I started a VM using the official F20 cloud image, installed libvirt and
 its dependencies and tried to create a guest but SELinux won't let me:
 
 [root@fedora-20 ~]# virsh create mini.xml error: Failed to create domain
 from mini.xml error: Input/output error
 
 [root@fedora-20 ~]# journalctl | tail Mar 21 14:23:06 fedora-20 systemd[1]:
 SELinux policy denies access. Mar 21 14:23:06 fedora-20
 systemd-machined[7210]: Failed to start machine scope: Access denied Mar 21
 14:23:06 fedora-20 libvirtd[6856]: Input/output error
 
 [root@fedora-20 ~]# cat /var/log/libvirt/qemu/mini.log 2014-03-21
 14:23:06.740+: starting up LC_ALL=C
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none
 /usr/bin/qemu-system-x86_64 -name mini -S -machine 
 pc-i440fx-1.6,accel=tcg,usb=off -m 1024 -realtime mlock=off -smp 
 1,sockets=1,cores=1,threads=1 -uuid -2890-2015-1f87-cbfa725b1dd3 
 -nographic -no-user-config -nodefaults -chardev 
 socket,id=charmonitor,path=/var/lib/libvirt/qemu/mini.monitor,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
 virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x2 2014-03-21
 14:23:06.744+: shutting down
 
 
 type=VIRT_MACHINE_ID msg=audit(1395412399.728:281): pid=6856 uid=0 
 auid=4294967295 ses=4294967295
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm=mini
 uuid=-2890-2015-1f87-cbfa725b1dd3 
 vm-ctx=system_u:system_r:svirt_tcg_t:s0:c728,c986 
 img-ctx=system_u:object_r:svirt_image_t:s0:c728,c986 model=selinux 
 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=success' 
 type=VIRT_MACHINE_ID msg=audit(1395412399.728:282): pid=6856 uid=0 
 auid=4294967295 ses=4294967295
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu vm=mini
 uuid=-2890-2015-1f87-cbfa725b1dd3 vm-ctx=107:107 img-ctx=107:107
 model=dac exe=/usr/sbin/libvirtd hostname=? addr=? terminal=?
 res=success' type=USER_AVC msg=audit(1395412399.788:283): pid=1 uid=0
 auid=4294967295 ses=4294967295  subj=system_u:system_r:init_t:s0 msg='avc:
 denied  { start } for auid=-1 uid=-1 gid=-1
 scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:init_t:s0
 tclass=service exe=/usr/lib/systemd/systemd sauid=0 hostname=? addr=?
 terminal=?' type=VIRT_RESOURCE msg=audit(1395412400.015:284): pid=6856
 uid=0 auid=4294967295 ses=4294967295
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=mem
 reason=start vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3 old-mem=0
 new-mem=1048576 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? 
 res=success' type=VIRT_RESOURCE msg=audit(1395412400.015:285): pid=6856
 uid=0 auid=4294967295 ses=4294967295
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu resrc=vcpu
 reason=start vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3 old-vcpu=0
 new-vcpu=1 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? 
 res=success' type=VIRT_CONTROL msg=audit(1395412400.015:286): pid=6856
 uid=0 auid=4294967295 ses=4294967295
 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=qemu op=start
 reason=booted vm=mini uuid=-2890-2015-1f87-cbfa725b1dd3 vm-pid=-1
 exe=/usr/sbin/libvirtd hostname=? addr=? terminal=? res=failed'
 
 I'm not overly familiar with SELinux. Is this a configuration issue? Am I 
 missing some policy packages or could this be an issue with the cloud
 image?
 
 Works fine when I disable SELinux.
 
 Google found this, but it's old and apparently resolved: 
 https://bugzilla.redhat.com/show_bug.cgi?id=860235
 
 Thanks ...Juerg
 
 
 
 ___ cloud mailing list 
 cloud@lists.fedoraproject.org 
 https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
 Conduct: http://fedoraproject.org/code-of-conduct
 

There is no SELinux data that you posted.  I don't think your machine is
mislabeled.  Doing the /.autorelabel dance is a waste of time.

ausearch -m avc,user_avc -ts recent

After you have the problem, to see if SELinux posted any error messages.

If there are no messages then try to turn off dontaudit rules.

semodule -DB
Run your test
ausearch -m avc,user_avc -ts recent

And look for messages about virt.

This will turn dontaudit rules back on.
semodule -B


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMtahAACgkQrlYvE4MpobPh4ACgymOncdUt6k7+Z5BwJObOmyLx
hJUAn08Uow4Qh7KWL+Qg+F14ikr52ktE
=TMxx
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 20 RC1 AMIs

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/2013 11:44 AM, Matthew Miller wrote:
 On Thu, Dec 12, 2013 at 03:18:31PM +0100, Vitaly Kuznetsov wrote:
 ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image
 for x86_64
 Compared to TC5 images: 1) iptables-services package is missing in RC1
 
 This is intentional and by popular demand -- in an IaaS environment, the 
 cloud provider's security groups or equivalent concept provides the 
 firewall. If one wants defense-in-depth it's easy to install 
 iptables-services or firewalld with cloud-init.
 
 2) SELinux contexts. It gets better :-) In TC5 if you remember we had: #
 restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon
 reset /boot/extlinux/ldlinux.sys context
 system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 restorecon reset
 /var/cache/yum context
 system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 
 restorecon reset /var/log/boot.log context
 system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 
 restorecon reset /var/log/cron context
 system_u:object_r:var_log_t:s0-system_u:object_r:cron_log_t:s0
 
 I'm pre-creating the two log files, so they end up right.
 
 In RC1 we have only these: # restorecon -R -v -n -e /proc -e /sys -e /tmp
 -e /run -e /dev / restorecon reset /var/cache/yum context
 system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 
 restorecon reset /boot/extlinux/ldlinux.sys context
 system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
 I tried to be clever with changing ldlinux.sys from immutable and back
 again but apparently that doesn't do it. (Since this isn't ever actually
 run on the system, only _before_ the system, and not on EC2 at all, the 
 side-effects of a wrong context should be small.)
 
 I'm more concerned about /var/cache/yum, since that is already precreated 
 and should already be right.
 
Any chance this is something mounted on that directory?  That the relabel is
not hitting the inode?

Another option would be to just remove this directory.  Especially if there is
not content.  yum would recreate it on the update.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKqDCAACgkQrlYvE4MpobNp+wCghhrcEdRESombmys7Pu73lbzH
7KQAnj+dM94shsnCtg9z+8ynyZ26RvaB
=wArP
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 20 TC2 AMIs

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/21/2013 03:13 PM, Vitaly Kuznetsov wrote:
 Matthew Miller mat...@fedoraproject.org writes:
 
 On Thu, Nov 21, 2013 at 01:30:15PM +0100, Vitaly Kuznetsov wrote:
 I ran basic tests agains them and they're ok. The only issue I still
 see is wrong SELinux context for several files:
 
 # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon
 reset /var/cache/yum context
 system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 
 restorecon reset /var/log/boot.log context
 system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0

 
restorecon reset /boot/extlinux/ldlinux.sys context
system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
 That's weird. We're running fixfiles at the end of the build process to 
 clean up anything like that.
 
 I looked into kickstart, you do '/usr/sbin/fixfiles -R -a restore'. I tried
 running it manually on fresh instance:
 
 # /usr/sbin/fixfiles -R -a restore 75k/sbin/restorecon set context 
 /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation
 not permitted' 80k/sbin/restorecon set context 
 /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation
 not permitted' 177k/sbin/restorecon set context 
 /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation
 not permitted'
 
 However /boot/extlinux/ldlinux.sys is the only file needs fixind after 
 this:
 
 # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset
 /boot/extlinux/ldlinux.sys context 
 system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0
 
 Anyway, https://bugzilla.redhat.com/show_bug.cgi?id=1033274 as suggested by
 dwalsh)
 
Any change something is mounted on top of these files/directories when the
fixfiles is run.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKPXq8ACgkQrlYvE4MpobPw7wCeMz5w3mGE9PRI+qRJxQTDmpK3
gzYAoN2VWaVI5iGpxkVN/vTA+JTfKWoh
=WycT
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: container/container-medium-19.ks container/container-medium-20.ks container/container-minimal-19.ks container/container-minimal-20.ks

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/19/2013 01:18 PM, Matthew Miller wrote:
 container/container-medium-19.ks  |3 +++ 
 container/container-medium-20.ks  |3 +++ 
 container/container-minimal-19.ks |2 ++ 
 container/container-minimal-20.ks |2 ++ 4 files changed, 10
 insertions(+)
 
 New commits: commit 813cd55875feaff0e3273fb2b53dc2ed51bdf62a Author:
 Matthew Miller mat...@mattdm.org Date:   Thu Sep 19 12:17:48 2013 -0500
 
 remove /boot contents (created by appliance-creator, not needed)
 
 diff --git a/container/container-medium-19.ks
 b/container/container-medium-19.ks index 2a311fb..2826c43 100644 ---
 a/container/container-medium-19.ks +++ b/container/container-medium-19.ks 
 @@ -119,6 +119,9 @@ rm -rf /var/lib/yum/history/* yum history new || yum
 history new truncate -c -s 0 /var/log/yum.log
 
 +echo Removing boot, since we don't need that. +rm -rf /boot/* + echo
 Fixing SELinux contexts. /usr/sbin/fixfiles -R -a restore
 
 diff --git a/container/container-medium-20.ks
 b/container/container-medium-20.ks index 5cec913..4c9b2f5 100644 ---
 a/container/container-medium-20.ks +++ b/container/container-medium-20.ks 
 @@ -119,6 +119,9 @@ rm -rf /var/lib/yum/history/* yum history new || yum
 history new truncate -c -s 0 /var/log/yum.log
 
 +echo Removing boot, since we don't need that. +rm -rf /boot/* + echo
 Fixing SELinux contexts. /usr/sbin/fixfiles -R -a restore
 
 diff --git a/container/container-minimal-19.ks
 b/container/container-minimal-19.ks index 2548b44..cf0d311 100644 ---
 a/container/container-minimal-19.ks +++
 b/container/container-minimal-19.ks @@ -110,6 +110,8 @@ yum -C -y remove
 passwd --setopt=clean_requirements_on_remove=1 yum -C -y remove findutils
 --setopt=clean_requirements_on_remove=1 yum -C -y remove firewalld
 --setopt=clean_requirements_on_remove=1
 
 +echo Removing boot, since we don't need that. +rm -rf /boot/*
 
 echo Cleaning old yum repodata. yum clean all diff --git
 a/container/container-minimal-20.ks b/container/container-minimal-20.ks 
 index b6df5b4..653cefb 100644 --- a/container/container-minimal-20.ks +++
 b/container/container-minimal-20.ks @@ -110,6 +110,8 @@ yum -C -y remove
 passwd --setopt=clean_requirements_on_remove=1 yum -C -y remove findutils
 --setopt=clean_requirements_on_remove=1 yum -C -y remove firewalld
 --setopt=clean_requirements_on_remove=1
 
 +echo Removing boot, since we don't need that. +rm -rf /boot/*
 
 echo Cleaning old yum repodata. yum clean all
 
 
 ___ cloud mailing list 
 cloud@lists.fedoraproject.org 
 https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
 Conduct: http://fedoraproject.org/code-of-conduct
 
In a container image, you do not need to install selinux-policy*, since
selinux policy is not supported within the container.  From the containers
point of view
SELinux is disabled.

Because of this you can probably also eliminate policycoreutils, although
other packages might suck it back in.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlI7PjkACgkQrlYvE4MpobOS2gCfW3OOnCi3KkrRhId9joZ58kGE
oT8AnjIgKnxMBFnGem3vO/yBdq1DWA2B
=sLxT
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: container/container-medium-19.ks container/container-medium-20.ks container/container-minimal-19.ks container/container-minimal-20.ks

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/19/2013 03:10 PM, Matthew Miller wrote:
 On Thu, Sep 19, 2013 at 02:11:05PM -0400, Daniel J Walsh wrote:
 In a container image, you do not need to install selinux-policy*, since 
 selinux policy is not supported within the container.  From the
 containers point of view SELinux is disabled. Because of this you can
 probably also eliminate policycoreutils, although other packages might
 suck it back in.
 
 Yeah, the medium container is kind of a work-in-progress on this front.
 I thought I put selinux-policy on the minus list of packages -- I'll take
 a look at what's pulling it in.
 
 I'm really interested in your thoughts on how selinux might work in this 
 brave new world. :)
 
Well in its simplest form it would be used to stop one container from messing
with another container using MCS Separation.  virt-sandbox does this now, as
well as openshift and SELinux sandbox tool. Basically you run all processes
within the container with a single type container_t.  And all the writable
content is container_file_t.  Then you use a unigue MCS label for each
container and its content.  container_t:mcs1, can not touch container_t:mcs2.

We can also define constraints outside the container like, what ports the
container is allowed to use, or what capabilities are available. Whether it
can mount, mknod ...

We can also do transitions within the container.  For example the container
runs as container_setup_t and then executes myapp_exec_t it will transition to
container_t.  But the whole time nothing within the container knows about 
SELinux.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlI7NagACgkQrlYvE4MpobOieQCgzzbyouPbbb/JIuI5F/xepwRN
LCkAoKnKCSAEruAI/eNsWwH1h3w552MA
=R1KK
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Future directions for Fedora Cloud

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/16/2013 04:57 PM, Colin Walters wrote:
 On Wed, 2013-09-11 at 12:01 -0400, Matthew Miller wrote:
 
 So, idea one is to make something like CoreOS (http://coreos.com/): a 
 lightweight distribution made for running containers on top of. We
 wouldn't attempt to be _as_ lightweight as CoreOS (for that, there's
 CoreOS), but aim to be small while still providing key features like
 SELinux.
 
 How SELinux would work in a coreos/container deployment setup is an 
 interesting question.  One could imagine docker containers coming with 
 policy modules, but that ends up tying them to a specific host version, 
 which is kind of against the point of containers.
 
 More realistically I think one would have a relatively permissive domain 
 (generic_container_t), and use something like MCS labels to restrict the 
 flow of information between containers and the host.
 
Currently that is what we do with virt-sandbox containers.  svirt_lxc_net_t
and svirt_qemu_net_t is very loose, Full Network, Full Capabilities,
Read/Execute everything in /usr and most of /etc, no access to content in
/root, /home, /var (We bind mount containers content over /root, /home, and
/var)  And separate them from MCS.  They are only allowed to write to
svirt_sandbox_file_t.

I have setup the policy to allow policy writers to create limited network
privs container domains, fairly easily.  Perhaps we should do the same for
capabilities.

One concept I have built for OpenShift is the idea of an Admin of a container
versus the application within the container.  So a user joining a container
might have full access to all file types owned by the container, but the
applicagtion/service within the container would only be allowed to write to
the svirt_sandbox_file_rw_t content and read/exec svirt_sandbox_file_t content.


 Perhaps this could be built with Colin Walter's OSTree (see 
 https://wiki.gnome.org/OSTree) for atomic updates.
 
 To follow up on this, I have been working slowly on this tool called 
 yum-ostree which is designed to capture packages as OSTree commits. At
 the moment it's just a lame python script, but it's nearly to the point of
 being useful.  I'll post to the generic fedora-devel-list when it's ready.
 
 As far as OSTree compared to CoreOS; the biggest difference is that the 
 CoreOS updater mandates a particular filesystem chosen on the build server,
 because it sends block-level diffs.  OSTree operates at the filesystem
 layer (like rsync), and this allows more flexibility.  (At the moment
 though, OSTree is significantly less efficient on the network side).
 
 
 ___ cloud mailing list 
 cloud@lists.fedoraproject.org 
 https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
 Conduct: http://fedoraproject.org/code-of-conduct
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlI4UJEACgkQrlYvE4MpobN+6gCgz6dHVm8kDHFLHJss6vLt7QaT
b2cAnRhr3ODzKRz9HUQrspruwAI8Sq7+
=xqk7
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disabling firewalld on AWS?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/11/2013 08:53 AM, Sam Kottler wrote:
 
 
 - Original Message -
 From: Michael Hampton er...@ioerror.us To: 
 cloud@lists.fedoraproject.org Sent: Wednesday, September 11, 2013
 8:47:23 AM Subject: Re: Disabling firewalld on AWS?
 
 
 On 09/11/2013 08:13 AM, Sam Kottler wrote:
 On 09/10/2013 11:36 PM, Sam Kottler wrote:
 Given the deny-by-default nature of security groups I think
  it makes sense to disable firewalld in the AMI's. I
 haven't seen any other AMI's that have a firewall enabled
 by default and we probably shouldn't break that pattern
 IMO.
 
 Thoughts?
 
 
 This is easily one of my least-favorite features of certain
 Linux distributions.
 
 Debian/Ubuntu images don't have a firewall enabled by default in
  their cloud images because they don't have a firewall enabled at
  all in a default installation. At least the last time I looked
 at them; maybe they've gotten smarter in the last couple of
 years.
 
 I'm not really sure I see a benefit here. There may not even be a
  second firewall in front of the virtual machine; a user might
 turn it off because it's getting in the way, or a cloud provider
 might not provide this feature at all. I know of at least one
 public cloud provider which has an external firewall feature
 similar to AWS security groups, but it's off by default. In this
 case I see plenty of downside.
 
 If people disable their firewall then that's their prerogative,
  but it's confusing and non-standard to have a firewall
 running on the instance and one running via the security
 group(s) that the host is in.
 
 Also, I don't trust the public cloud providers to configure their 
 firewall correctly.
 
 So in your case you just `chkconfig firewalld on` and configure it. 
 I'm sure that people who share your opinion (myself among them) will
 do that for the extra layer of security, but I'm just advocating for
 the Fedora images to follow the way other AMI's are handling
 firewalls.
 
 And I'm saying that the way other AMIs do it is wrong. We should not also
 be wrong merely because everyone else is jumping off the cliff. Rather we
 should continue to be secure by default and require explicit action from
 the user to disable security, not explicit action to enable security.
 
 It's not disabl[ing] security, security groups already do that for
 you. You're adding an extra convoluted layer, and the vast majority of
 users will just disable it and rely on security groups (that's conjecture
 on my part). Have you ever heard about vulnerabilities in the AWS
 security group implementation? I haven't.
 
I would figure Amazon would do everything in its power to prevent leakage of
information about vulnerabilities to the public.  Their stock price would take
a large hit...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIwaM4ACgkQrlYvE4MpobN15gCgiDdJpXpg56jlhb+08JbgtiaN
fGQAoOEsGcfzXLiLinHBA3/x1nYI3LdF
=l2dv
-END PGP SIGNATURE-
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct