Re: [atomic-devel] podman user defined network support

[Muayyad AlSadi]

This example have:

 postgres database
Rabbitmq
Mamcached
Django oython web app and its delayed tasks



https://github.com/containers/podman-compose/blob/master/examples/awx3/docker-compose.yml

On Mon, Sep 9, 2019, 5:04 PM Farkas Levente  wrote:

> In the light of the above solution...
>
> is anybody use containers with podman in any real environment?
>
> let's just assume a database and a service (where we can't put them into
> the same pod)?
> eg. we've a db cluster and a few service which use that cluster.
>
> thanks in advance.
>
> On Fri, May 17, 2019 at 2:26 AM Muayyad AlSadi  wrote:
>
>> rootless podman containers can create network using slirp4netns
>> but there is no container to container communication
>>
>> the workaround I used in podman-compose is that I share a network between
>> containers
>> and all containers talk via pod shared localhost (not to be confused with
>> host localhost)
>>
>> I was able to run this complex stack having:
>>
>> a django web interface
>> Postgres database
>> rabbitmq
>> memcached
>> tasks
>>
>> all linked to gather and non-exported to host except the django web
>> interface
>>
>>
>> https://github.com/muayyad-alsadi/podman-compose/blob/master/examples/awx/docker-compose.yml
>>
>> the trick is like this
>>
>> podman pod create -p 8080:80 --name=mypod --share net
>> podman run --name=db --pod=mypod  ...
>> podman run --name=web --pod=mypod --add-host db:127.0.0.1 ...
>>
>>
>>
>>
>> On Thu, May 16, 2019 at 5:31 PM Farkas Levente 
>> wrote:
>>
>>> On 5/8/19 9:19 PM, Brent Baude wrote:
>>> > On Wed, 2019-05-08 at 09:53 +0200, Farkas Levente wrote:
>>> >> hi,
>>> >> it seems that podman do not support network command. ie. it's not
>>> >> possible to create user defined network.
>>> >>
>>> >> is it possible to create a user defined network somehow?
>>> >>
>>> >> is it possible to define a user defined network is rootless mode?
>>> >>
>>> >> since podman do not support --link how can communicate two container
>>> >> in
>>> >> a podman environment?
>>> >>
>>> >> without this feature is there any other way than --net=host? since
>>> >> currently i can't find any other ways. eg. a db and a service
>>> >> container.
>>> >>
>>> >> thanks in advance.
>>> >>
>>> >
>>> > In order to specific a specific network, you must create that network
>>> > with CNI.  These network descriptions are defined in /etc/cni/net.d and
>>> > podman ships a default one.  A while back, I created a secondary cni
>>> > network for doing some podman testing. I called the network podman2 and
>>> > the conf file appears as:
>>> >
>>> > {
>>> > "cniVersion": "0.3.0",
>>> > "name": "podman2",
>>> > "plugins": [
>>> >   {
>>> > "type": "bridge",
>>> > "bridge": "cni1",
>>> > "isGateway": true,
>>> > "ipMasq": true,
>>> > "ipam": {
>>> > "type": "host-local",
>>> > "subnet": "10.99.0.0/16",
>>> > "routes": [
>>> > { "dst": "0.0.0.0/0" }
>>> > ]
>>> > }
>>> >   },
>>> >   {
>>> > "type": "portmap",
>>> > "capabilities": {
>>> >   "portMappings": true
>>> > }
>>> >   }
>>> > ]
>>> > }
>>> >
>>> > The CNI project is outside podman and can be found ->
>>> >
>>> https://github.com/containers/libpod/blob/master/test/e2e/common_test.go#L267
>>> > you might also want to checkout out their plugins subproject.
>>>
>>> ok. but this means currently there is no alternative for docker network.
>>> what's more currently with podman you must use --net=host.
>>> since there is no user defined network (at least with easy command
>>> line), what's more there is no --link option for podman. so neither of
>>> the docker container communication works with podman. is it true?
>>>
>>>
>>>
>>> --
>>>   Levente   "Si vis pacem para bellum!"
>>>
>>>
>
> --
>   Levente   "Si vis pacem para bellum!"
>

Re: [atomic-devel] Bootable fedora atomic host 29 for cloud(OpenStack)?

[Muayyad AlSadi]

here

https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/


On Sat, Jun 22, 2019 at 4:46 AM Dusty Mabe  wrote:

>
>
> On 6/11/19 5:28 PM, Feilong Wang wrote:
> > Hi there,
> >
> > I'm new for the fedora atomic community, so please bear me if the
> question is silly. I found there is no cloud images since FC28. So could
> anybody let me know where can I get a bootable Fedora Atomic Host 29 image
> for cloud (OpenStack)? The qcow2 image from
> https://ftp.icm.edu.pl/pub/Linux/dist/fedora-alt/atomic/stable/Fedora-29-updates-20190528.0/AtomicHost/x86_64/images/
> doesn't work for me. Thank you very much.
>
> The qcow there works in openstack. It's the only qcow we provide.
>
> Dusty
>
>

Re: [atomic-devel] how to cancel pending

[Muayyad AlSadi]

I found the answer for first question, which is

rpm-ostree cancel

but how show progress



On Mon, May 20, 2019 at 5:12 PM Muayyad AlSadi  wrote:

> Hi,
>
> I was about to upgrade my fedora 29 silverblue to 30
>
> https://fedoramagazine.org/how-to-rebase-to-fedora-30-beta-on-silverblue/
>
> I was about rebase
>
> # rpm-ostree rebase fedora-workstation:fedora/30/x86_64/silverblue
> error: System transaction in progress
>
> # rpm-ostree status
> State: busy
> 
>
> I don't need the pending download of update 29 image
> how to cancel that?
> and how to see the progress of that?
> for example if it's 98% I don't want to cancel it.
>
>
>
>
>

[atomic-devel] how to cancel pending

[Muayyad AlSadi]

Hi,

I was about to upgrade my fedora 29 silverblue to 30

https://fedoramagazine.org/how-to-rebase-to-fedora-30-beta-on-silverblue/

I was about rebase

# rpm-ostree rebase fedora-workstation:fedora/30/x86_64/silverblue
error: System transaction in progress

# rpm-ostree status
State: busy


I don't need the pending download of update 29 image
how to cancel that?
and how to see the progress of that?
for example if it's 98% I don't want to cancel it.

Re: [atomic-devel] podman user defined network support

[Muayyad AlSadi]

rootless podman containers can create network using slirp4netns
but there is no container to container communication

the workaround I used in podman-compose is that I share a network between
containers
and all containers talk via pod shared localhost (not to be confused with
host localhost)

I was able to run this complex stack having:

a django web interface
Postgres database
rabbitmq
memcached
tasks

all linked to gather and non-exported to host except the django web
interface

https://github.com/muayyad-alsadi/podman-compose/blob/master/examples/awx/docker-compose.yml

the trick is like this

podman pod create -p 8080:80 --name=mypod --share net
podman run --name=db --pod=mypod  ...
podman run --name=web --pod=mypod --add-host db:127.0.0.1 ...




On Thu, May 16, 2019 at 5:31 PM Farkas Levente  wrote:

> On 5/8/19 9:19 PM, Brent Baude wrote:
> > On Wed, 2019-05-08 at 09:53 +0200, Farkas Levente wrote:
> >> hi,
> >> it seems that podman do not support network command. ie. it's not
> >> possible to create user defined network.
> >>
> >> is it possible to create a user defined network somehow?
> >>
> >> is it possible to define a user defined network is rootless mode?
> >>
> >> since podman do not support --link how can communicate two container
> >> in
> >> a podman environment?
> >>
> >> without this feature is there any other way than --net=host? since
> >> currently i can't find any other ways. eg. a db and a service
> >> container.
> >>
> >> thanks in advance.
> >>
> >
> > In order to specific a specific network, you must create that network
> > with CNI.  These network descriptions are defined in /etc/cni/net.d and
> > podman ships a default one.  A while back, I created a secondary cni
> > network for doing some podman testing. I called the network podman2 and
> > the conf file appears as:
> >
> > {
> > "cniVersion": "0.3.0",
> > "name": "podman2",
> > "plugins": [
> >   {
> > "type": "bridge",
> > "bridge": "cni1",
> > "isGateway": true,
> > "ipMasq": true,
> > "ipam": {
> > "type": "host-local",
> > "subnet": "10.99.0.0/16",
> > "routes": [
> > { "dst": "0.0.0.0/0" }
> > ]
> > }
> >   },
> >   {
> > "type": "portmap",
> > "capabilities": {
> >   "portMappings": true
> > }
> >   }
> > ]
> > }
> >
> > The CNI project is outside podman and can be found ->
> >
> https://github.com/containers/libpod/blob/master/test/e2e/common_test.go#L267
> > you might also want to checkout out their plugins subproject.
>
> ok. but this means currently there is no alternative for docker network.
> what's more currently with podman you must use --net=host.
> since there is no user defined network (at least with easy command
> line), what's more there is no --link option for podman. so neither of
> the docker container communication works with podman. is it true?
>
>
>
> --
>   Levente   "Si vis pacem para bellum!"
>
>

Re: [atomic-devel] recommended way of running a container

[Muayyad AlSadi]

there were two ways I used to do this with docker and it can also be done
with podman

1. stateless way, always fresh

ExecStartPre=-/bin/podman stop -t=1 mycnt
ExecStartPre=-/bin/podman remove mycnt
ExecStart=/bin/podman run -i --name mycnt -v  myimg mycmd
ExecReload=-/bin/podman restart -t=1 mycnt
ExecStop=/bin/podman stop -t=1 mycnt

2. create once, and just attach

ExecStartPre=-/bin/podman run -d -w /etc/ -p 9090:8080 --name mycnt busybox
httpd -f -p 8080
ExecStartPre=-/bin/podman start mycnt
ExecStart=/bin/podman attach --no-stdin --sig-proxy mycnt
ExecReload=-/bin/podman restart -t=1 mycnt
ExecStop=/bin/podman stop -t=1 mycnt




On Mon, May 6, 2019 at 2:16 PM Farkas Levente  wrote:

> On 5/2/19 9:20 PM, Brent Baude wrote:
> > On Thu, 2019-05-02 at 16:12 +0200, Farkas Levente wrote:
> >> - Create a systemd service file on the host for the healthcheck,
> >> - Create a systemd timer  file on the host for the healthcheck.
> >>
> >
> > Just for the record, healthchecks are optional.  The systemd service
> > and timer files are created automatically for you with podman and are
> > considered to be transient in nature.  That means if the system is
> > rebooted, that timer and service are deleted.  If the container is
> > started again, they are recreated.
>
> does it means the recommended way to create one systemd service file for
> the container and in this service the ExecStart's podman should have to
> be a --healthcheck-command parameter (and may be more) and use the
> podman generated transient timer or service for healtcheck?
>
> and in this case in case of failure who and how will restart the main
> service?
>
> --
>   Levente   "Si vis pacem para bellum!"
>
>

Re: [atomic-devel] moby-engine for centos/epel

[Muayyad AlSadi]

> Oh, and forgot, would like to see it in EPEL for reasons that you will
likely see this week :-)

thank you very much


On Mon, May 6, 2019 at 12:29 PM Scott McCarty  wrote:

> Oh, and forgot, would like to see it in EPEL for reasons that you will
> likely see this week :-)
>
> On Mon, May 6, 2019, 11:28 AM Scott McCarty  wrote:
>
>> Neal,
>> Yeah, we will not port to RHEL (no ans at all), but to get
>> moby-engine working on CentOS should be just stealing the Fedora spec file
>> and doing a little work...
>>
>> On Mon, May 6, 2019, 10:57 AM Neal Gompa  wrote:
>>
>>> On Mon, May 6, 2019 at 4:52 AM Scott McCarty 
>>> wrote:
>>> >
>>> > Muayyad & Neal,
>>> > That makes perfect sense. Thank you for the feedback. It might
>>> sound crazy but I am keeping a list of every use case I can find and
>>> tracking our progress with podman.
>>> >
>>> > All of these use cases make sense (and I plan on tracking them in my
>>> list when I get back to a computer). If I were to surmise, it sounds like
>>> many people need some time to migrate certain use cases which have Docker
>>> specific requirements. Hence, having the option of moby-engine around would
>>> make that more convenient.
>>> >
>>> > Sounds like there are two short term goals:
>>> >
>>> > 1. Update podman in CentOS. I have to dig into this to see if it is
>>> tracking g the version in RHEL properly.
>>> > 2. Add moby-engine to CentOS. This one might be interesting for for
>>> the same reason, but admittedly it would be hard for me to push to dedicate
>>> Red Hat people's time to package it. We would love a volunteer ;-)
>>> >
>>> > So much work and so little time. I wish I could just knock out all of
>>> these use cases out on a weekend, but a 19 month old has put a dent in my
>>> free time :-)
>>> >
>>>
>>> The old patches for making docker work with RHEL entitlements would
>>> need to be ported, though.
>>>
>>> SUSE has a variation of these patches for their docker package[1],
>>> maybe these could help with moby-engine?
>>>
>>> [1]:
>>> https://build.opensuse.org/package/show/Virtualization:containers/docker
>>>
>>>
>>> --
>>> 真実はいつも一つ！/ Always, there's only one truth!
>>>
>>

Re: [atomic-devel] moby-engine for centos/epel

[Muayyad AlSadi]

> SUSE has a variation of these patches for their docker package[1],
> maybe these could help with moby-engine?

I guess fedora's moby-engine .src.rpm would be just fine

https://src.fedoraproject.org/rpms/moby-engine/tree/master





On Mon, May 6, 2019 at 11:57 AM Neal Gompa  wrote:

> On Mon, May 6, 2019 at 4:52 AM Scott McCarty  wrote:
> >
> > Muayyad & Neal,
> > That makes perfect sense. Thank you for the feedback. It might sound
> crazy but I am keeping a list of every use case I can find and tracking our
> progress with podman.
> >
> > All of these use cases make sense (and I plan on tracking them in my
> list when I get back to a computer). If I were to surmise, it sounds like
> many people need some time to migrate certain use cases which have Docker
> specific requirements. Hence, having the option of moby-engine around would
> make that more convenient.
> >
> > Sounds like there are two short term goals:
> >
> > 1. Update podman in CentOS. I have to dig into this to see if it is
> tracking g the version in RHEL properly.
> > 2. Add moby-engine to CentOS. This one might be interesting for for the
> same reason, but admittedly it would be hard for me to push to dedicate Red
> Hat people's time to package it. We would love a volunteer ;-)
> >
> > So much work and so little time. I wish I could just knock out all of
> these use cases out on a weekend, but a 19 month old has put a dent in my
> free time :-)
> >
>
> The old patches for making docker work with RHEL entitlements would
> need to be ported, though.
>
> SUSE has a variation of these patches for their docker package[1],
> maybe these could help with moby-engine?
>
> [1]:
> https://build.opensuse.org/package/show/Virtualization:containers/docker
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>

Re: [atomic-devel] moby-engine for centos/epel

[Muayyad AlSadi]

> BTW Have you tried out Podman

of course, Podman is an awesome peice of software
BTW: I'm the author of podman-compose and I'm writing an article about
buildah for fedora magazine

> I think this is up to a volunteer to take it on.

centos ships too old docker I'm not sure about compatibility
maybe we should ship moby-engine in a different repo just like we used to
do with docker and docker-latest

https://access.redhat.com/articles/2317361



On Sun, May 5, 2019 at 2:34 PM Daniel Walsh  wrote:

> On 5/5/19 4:33 AM, Muayyad AlSadi wrote:
> > Hi,
> >
> > it seems that fedora had shipped moby-engine,
> > when can we ship it for centos/epel?
> >
> > if not in epel,link for that repo?
>
> I think this is up to a volunteer to take it on.
>
>
> BTW Have you tried out Podman
>
>

[atomic-devel] moby-engine for centos/epel

[Muayyad AlSadi]

Hi,

it seems that fedora had shipped moby-engine,
when can we ship it for centos/epel?

if not in epel,link for that repo?

Re: [atomic-devel] forbidden base package replacement

[Muayyad AlSadi]

> Not sure to fully understand.

instead of modifying the host to add/remove the packages you want,
you can create a docker image containing whatever you want to run (even if
it's the docker daemon itself)
then run that container using atomic tool with ostree/runc backend (without
docker daemon)

the same way atomic host is running etcd and flanneld without docker daemon

here is a session

[root@laptop ~]# docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the
docker daemon running?
[root@laptop ~]#
[root@laptop ~]# atomic run --storage ostree
registry.fedoraproject.org/fedora-minimal /bin/bash
bash-4.4#



[image: Screenshot from 2018-05-31 16-09-12.png]
​



On Thu, May 31, 2018 at 4:02 PM arnaud gaboury 
wrote:

> On 05/31/2018 02:53 PM, Muayyad AlSadi wrote:
>
> you can use "atomic" command line tool to run whatever you want inside
> a system container (even without docker daemon)
>
>
> Not sure to fully understand. Here what I did:
>
> 
> # atomic host install docker-ce-17.03.2.ce-1.el7.centos.x86_64.rpm
> docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch.rpm
> Checking out tree 291ea90... done
> Enabled rpm-md repositories: updates fedora
> rpm-md repo 'updates' (cached); generated: 2018-05-30 14:04:09
> rpm-md repo 'fedora' (cached); generated: 2018-04-25 04:27:32
> Importing metadata [=] 100%
> Resolving dependencies... Forbidden base package replacements:
>   selinux-policy-targeted 3.14.1-29.fc28 -> 3.14.1-30.fc28 (updates)
>   selinux-policy 3.14.1-29.fc28 -> 3.14.1-30.fc28 (updates)
> failed
> error: Some base packages would be replaced
> --
>
> Is it what you were talking about?
>
>
> http://www.projectatomic.io/blog/2018/03/containers-w-skopeo-ostree-oci/http://www.projectatomic.io/blog/2017/06/creating-system-containers/
>
> On Thu, May 31, 2018 at 3:04 PM arnaud gaboury  
>  wrote:
>
>
> In order to create a Kubernetes cluster, I want to downgrade docker to 
> docker-ce-17.03.
>
> I uninstalled successfully current docker version with some dependencies with 
> the following command:
>
> --
> # rpm-ostree override remove cockpit-docker docker docker-common
> --
>
> Now i want to install two rpm files for docker:
>
> ---
> # rpm-ostree install docker-ce-17.03.2.ce-1.el7.centos.x86_64.rpm 
> docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch.rpm
> --
>
> The above command returned:
>
> ---
> Resolving dependencies... Forbidden base package replacements:
>   selinux-policy-targeted 3.14.1-29.fc28 -> 3.14.1-30.fc28 (updates)
>   selinux-policy 3.14.1-29.fc28 -> 3.14.1-30.fc28 (updates)
> failed
> error: Some base packages would be replaced
> 
>
> Googling, it seems this is a common issue, but I didn't find any solution. 
> How can I solve this issue and install docker-ce & dependencies?
>
> Regards.
>
>

Re: [atomic-devel] forbidden base package replacement

[Muayyad AlSadi]

you can use "atomic" command line tool to run whatever you want inside
a system container (even without docker daemon)

http://www.projectatomic.io/blog/2018/03/containers-w-skopeo-ostree-oci/
http://www.projectatomic.io/blog/2017/06/creating-system-containers/

On Thu, May 31, 2018 at 3:04 PM arnaud gaboury  wrote:
>
> In order to create a Kubernetes cluster, I want to downgrade docker to 
> docker-ce-17.03.
>
> I uninstalled successfully current docker version with some dependencies with 
> the following command:
>
> --
> # rpm-ostree override remove cockpit-docker docker docker-common
> --
>
> Now i want to install two rpm files for docker:
>
> ---
> # rpm-ostree install docker-ce-17.03.2.ce-1.el7.centos.x86_64.rpm 
> docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch.rpm
> --
>
> The above command returned:
>
> ---
> Resolving dependencies... Forbidden base package replacements:
>   selinux-policy-targeted 3.14.1-29.fc28 -> 3.14.1-30.fc28 (updates)
>   selinux-policy 3.14.1-29.fc28 -> 3.14.1-30.fc28 (updates)
> failed
> error: Some base packages would be replaced
> 
>
> Googling, it seems this is a common issue, but I didn't find any solution. 
> How can I solve this issue and install docker-ce & dependencies?
>
> Regards.

[atomic-devel] rpm-ostree equivalent of fastest mirror and parallel downloads

[Muayyad AlSadi]

Hi,

in /etc/dnf/dnf.conf I have

fastestmirror=1
max_parallel_downloads=20

what is the of that in rpm-ostree?

Re: [atomic-devel] atomic install/run cockpit does not work on atomic-ws

[Muayyad AlSadi]

Then it's might be a good time to have detas for ws.


On Thu, Mar 29, 2018, 6:39 PM Micah Abbott <miabb...@redhat.com> wrote:

> On 03/29/2018 12:34 PM, Muayyad AlSadi wrote:
> >  > rpm-ostree upgrade --check
> >
> > it gives me,
> >
> > mporting metadata [=] 100%
> > **
> >
> ERROR:src/app/rpmostree-dbus-helpers.c:1362:rpmostree_print_cached_update:
> > assertion failed: (g_variant_dict_lookup (, "ref-has-new-commit",
> > "b", _new_checksum))
> > Aborted (core dumped)
>
> This looks like:
>
> https://github.com/projectatomic/rpm-ostree/issues/1267
>
> You can work around it like so:
>
> "In the meantime, you can work around this by setting
> AutomaticUpdatePolicy in /etc/rpm-ostreed.conf to check (see
> rpm-ostreed.conf(5)). If you don't have the timer running, no checks
> will actually be performed in the background."
>
>
> > while "rpm-ostree upgrade" works fine, but I guess it's too much ~200MB,
> > we are supposed to get deltas aren't we?
>
> We have deltas for Fedora Atomic Host, but not for Atomic Workstation.
>
>
> > 466 metadata, 663 content objects fetched; 191,364 KiB transferred in
> > 163 seconds
> > Checking out tree e703ce3... done
> >
> >
> >
> >
> > On Tue, Mar 27, 2018 at 3:59 PM, Matthias Clasen <mcla...@redhat.com
> > <mailto:mcla...@redhat.com>> wrote:
> >
> >
> > what is the command line that check for updates without applying
> > the update? and list pending updates?
> > is it pull?
> >
> >
> > rpm-ostree upgrade --check
> >
> >
> >
> > when an update came to atomic ws, it removed those (picture
> > inlined, look at removals: 10 packages)
> >
> > is there a way to carry those newly installed packages from the
> > current layer into the updae?
> >
> > rpm-ostree has all needed information to do this.
> >
> > it knows they were added in the past
> > it knows they are still missing in the update
> > it knows how to merge (or rebase) them
> >
> >
> > rpm-ostree upgrade does that - it keeps the exiting layer in place.
> >
> >
>

Re: [atomic-devel] atomic install/run cockpit does not work on atomic-ws

[Muayyad AlSadi]

> rpm-ostree upgrade --check

it gives me,

mporting metadata [=] 100%
**
ERROR:src/app/rpmostree-dbus-helpers.c:1362:rpmostree_print_cached_update:
assertion failed: (g_variant_dict_lookup (, "ref-has-new-commit", "b",
_new_checksum))
Aborted (core dumped)

while "rpm-ostree upgrade" works fine, but I guess it's too much ~200MB, we
are supposed to get deltas aren't we?

466 metadata, 663 content objects fetched; 191,364 KiB transferred in 163
seconds
Checking out tree e703ce3... done




On Tue, Mar 27, 2018 at 3:59 PM, Matthias Clasen  wrote:

>
> what is the command line that check for updates without applying the
>> update? and list pending updates?
>> is it pull?
>>
>
> rpm-ostree upgrade --check
>
>
>>
>> when an update came to atomic ws, it removed those (picture inlined, look
>> at removals: 10 packages)
>>
>> is there a way to carry those newly installed packages from the current
>> layer into the updae?
>>
>> rpm-ostree has all needed information to do this.
>>
>> it knows they were added in the past
>> it knows they are still missing in the update
>> it knows how to merge (or rebase) them
>>
>>
> rpm-ostree upgrade does that - it keeps the exiting layer in place.
>

Re: [atomic-devel] atomic install/run cockpit does not work on atomic-ws

[Muayyad AlSadi]

I've installed them using

[root@localhost ~]# rpm-ostree install htop cockpit-bridge cockpit-system
cockpit-docker cockpit-networkmanager cockpit-ostree
[root@localhost ~]# rpm-ostree ex livefs
[root@localhost ~]# rpm-ostree ex livefs --replace

then run cockpit with

[root@localhost ~]# sytemctl start docker
[root@localhost ~]# sytemctl start sshd
[root@localhost ~]# atomic install registry.fedoraproject.org/f27/cockpit
[root@localhost ~]# atomic run --name cockpit
registry.fedoraproject.org/f27/cockpit

and it worked

> cockpit has been more for managing servers I think so the needed bits
aren't embedded in FAW.

I believe its bridge should be added (the same way we have sshd
pre-installed) to have consistent experience
because the proper way to add more applications to atomic is via flatpak or
docker/atomic
but cockpit won't work neither ways.

I have some questions

what is the command line that check for updates without applying the
update? and list pending updates?
is it pull?


when an update came to atomic ws, it removed those (picture inlined, look
at removals: 10 packages)

is there a way to carry those newly installed packages from the current
layer into the updae?

rpm-ostree has all needed information to do this.

it knows they were added in the past
it knows they are still missing in the update
it knows how to merge (or rebase) them



​



On Fri, Mar 23, 2018 at 7:34 PM, Dusty Mabe <du...@dustymabe.com> wrote:

>
>
> On 03/23/2018 11:56 AM, Muayyad AlSadi wrote:
> > hi,
> >
> > I've installed the latest atomic workstation on a vm
> >
> > I tried to run cockpit by typing
> >
> > atomic install registry.fedoraproject.org/f27/cockpit <http://registry.
> fedoraproject.org/f27/cockpit>
> >
> > but it gives
> >
> > cockpit-bridge must be installed on host
> >
> >
> >
> > is there a way to run cockpit on atomic workstation?
>
>
> cockpit has been more for managing servers I think so the needed bits
> aren't embedded in FAW.
>
> If you want you can layer in the same packages we include in FAH. They are
> listed here:
>
> https://pagure.io/fedora-atomic/blob/master/f/fedora-
> atomic-host.json#_112-116
>
>
> >
> > BTW: I wrote a review in Arabic for atomic-ws, it's awesome. I'll
> translate it very soon. but I would like to include cockpit in the english
> version
> >
> > http://g0alkeeper.blogspot.com/2018/03/blog-post.html
>
> Nice! Thanks for helping us reach another audience!
>
> Dusty
>

[atomic-devel] atomic install/run cockpit does not work on atomic-ws

[Muayyad AlSadi]

hi,

I've installed the latest atomic workstation on a vm

I tried to run cockpit by typing

atomic install registry.fedoraproject.org/f27/cockpit

but it gives

cockpit-bridge must be installed on host

is there a way to run cockpit on atomic workstation?

BTW: I wrote a review in Arabic for atomic-ws, it's awesome. I'll translate
it very soon. but I would like to include cockpit in the english version

http://g0alkeeper.blogspot.com/2018/03/blog-post.html

Re: [atomic-devel] testing atomic ws on virt-manager

[Muayyad AlSadi]

thank you, after making it permissive it worked


On Fri, Mar 23, 2018 at 3:26 AM, Dusty Mabe <du...@dustymabe.com> wrote:

>
>
> On 03/22/2018 07:39 PM, Muayyad AlSadi wrote:
> > hi,
> >
> > I'm using qemu-kvm with virt-manager on Fedora 27
> > and trying to install atomic ws, from here
> >
> > https://kojipkgs.fedoraproject.org/compose/
> branched/Fedora-28-20180322.n.0/compose/AtomicWorkstation/x86_64/iso/
> >
> > the installation progress bar is very wrong, but that is not a problem.
> >
> > I waited for it to complete and rebooted
> >
> > the newly installed system booted then got stuck for too long
> > it even says that it started GDM, but I can't see it
> >
> > can somebody try to reproduce this?
>
> I think you are probably hitting: https://bugzilla.redhat.com/
> show_bug.cgi?id=1559531
>
> Try setting selinux to permissive mode.
>
> Dusty
>

[atomic-devel] testing atomic ws on virt-manager

[Muayyad AlSadi]

hi,

I'm using qemu-kvm with virt-manager on Fedora 27
and trying to install atomic ws, from here

https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180322.n.0/compose/AtomicWorkstation/x86_64/iso/

the installation progress bar is very wrong, but that is not a problem.

I waited for it to complete and rebooted

the newly installed system booted then got stuck for too long
it even says that it started GDM, but I can't see it

can somebody try to reproduce this?

Re: [atomic-devel] Kubernetes manual setup (need reviewers)

[Muayyad AlSadi]

Make it public?

On Wed, Mar 14, 2018, 8:29 PM Chris Negus  wrote:

> I have a draft of a write-up for running Kubernetes on Fedora or Fedora
> Atomic, using kubeadm, that I'd like to submit to upstream Kubernetes. I
> would appreciate people reviewing the document and trying the procedure.
>
> Before publishing, I have a few issues that I need to get through (listed
> at the top of the document). Any feedback (especially help with those
> issues) would be appreciated:
>
>
> https://docs.google.com/document/d/1s9yUkC4nj3V0CCWV18PYimIIwBBB1OGxpuMmyinA62Y/edit#
>
> -- Chris Negus
>
>
> - Original Message -
> > On 02/23/2018 10:43 AM, Matthew Miller wrote:
> > > On Fri, Feb 23, 2018 at 10:16:46AM -0800, Jason Brooks wrote:
> > >>> If we have a preferred non-manual way, we should encourage people to
> > >>> use that, but I don't see what we lose from having good documentation
> > >>> at a lower level too.
> > >> That's totally awesome. Now someone needs to do that work. In the
> > >> absence of that person, it's not dismissive to link them to a popular
> > >> resource for manual installation.
> > >
> > > Of course -- but what I mean is saying "You wanted to know how to do
> > > Kubernetes on Fedora Atomic Host? Go do Kubernetes the hard way!"
> > > doesn't come off as very friendly to someone who doesn't know that
> > > "Learn  the hard way!" is a somewhat tongue-in-cheek meme. If
> > > that's the best resource and we recommend it, let's recommend it with a
> > > preface.
> >
> > Oh, I was planning to recommend Kubeadm.  Kubeadm is good enough for
> > most users, these days, and it's actually a good way to test new
> > Kubernetes releases.  And the Kubeadm team is enthusiastic enough to
> > maybe offer us some help.
> >
> > My primary concern with making sure that Kube is available on FAH/CAH is
> > that I want Kubernetes developers regarding AH as a reasonable target
> > platform for development.  We also want to make sure not to abandon our
> > existing AH+Kube users, but presumably installation docs are not the
> > primary thing those users need.
> >
> > I wouldn't *mind* having a "the hard way" doc for FAH/CAH, but I can't
> > commit to putting in the time it would require to write it, since I'm
> > not sure who the target user for it is.  Someone who wants something
> > "production" is going to install Origin, no?
> >
> > --
> > --
> > Josh Berkus
> > Kubernetes Community
> > Red Hat OSAS
> >
> >
>
>

Re: [atomic-devel] Kubernetes manual setup

[Muayyad AlSadi]

> Well actually... the main way I've used these system containers is
> with the ansible scripts at:
> https://github.com/kubernetes/contrib/tree/master/ansible but those
> have been deprecated.
>

You can say that they have been moved to
https://github.com/kubernetes-incubator/kubespray

>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

what about requiring sudo to do nsenter? (even when using runc rootless)



On Mon, Mar 5, 2018 at 4:09 PM, Giuseppe Scrivano <gscri...@redhat.com>
wrote:

> Muayyad AlSadi <als...@gmail.com> writes:
>
> > when using runc
> >
> > $ mypid=`runc list | tail -n 1 | awk '{print $2}'`
> > $ nsenter -a -t $mypid /bin/sh
> > nsenter: reassociate to namespace 'ns/cgroup' failed: Operation not
> permitted
> > $ sudo nsenter -a -t $mypid /bin/sh
> > # worked fine
> >
> > but when using bwraps
> >
> > $ mypid=`bwrap-oci list | tail -n 1 | awk '{print $2}'
> > $ nsenter -a -t $mypid /bin/sh
> > nsenter: reassociate to namespace 'ns/net' failed: Operation not
> permitted
> > $ sudo nsenter -a -t $mypid /bin/sh
> > nsenter: failed to execute /bin/sh: No such file or directory
>
> I guess that is an issue in bwrap as it internally uses chroot instead
> of a pivot_root.  This PR should probably fix the problem you are
> seeing:
>
>   https://github.com/projectatomic/bubblewrap/pull/256
>
> Giuseppe
>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

when using runc

$ mypid=`runc list | tail -n 1 | awk '{print $2}'`
$ nsenter -a -t $mypid /bin/sh
nsenter: reassociate to namespace 'ns/cgroup' failed: Operation not
permitted
$ sudo nsenter -a -t $mypid /bin/sh
# worked fine

but when using bwraps

$ mypid=`bwrap-oci list | tail -n 1 | awk '{print $2}'
$ nsenter -a -t $mypid /bin/sh
nsenter: reassociate to namespace 'ns/net' failed: Operation not permitted
$ sudo nsenter -a -t $mypid /bin/sh
nsenter: failed to execute /bin/sh: No such file or directory


why do I need to be root to join using nsenter with runc
and why bwraps failed even if I'm root










On Mon, Mar 5, 2018 at 1:23 PM, Giuseppe Scrivano <gscri...@redhat.com>
wrote:

> Muayyad AlSadi <als...@gmail.com> writes:
>
> > it seems there is no bwrap-oci exec and nsenter does not work as regular
> user.
> >
> > how to enter an existing user name space just like "runc exec redis
> /bin/sh" using bubble wrap or nsenter?
>
> exec is not implemented yet.  The easiest way to workaround this
> limitation is to use directly "nsenter -a".
>
> Regards,
> Giuseppe
>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

it seems there is no bwrap-oci exec and nsenter does not work as regular
user.

how to enter an existing user name space just like "runc exec redis /bin/sh"
using bubble wrap or nsenter?


On Sun, Feb 25, 2018 at 10:58 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> > is this still broken with my PR?
>
> no, your PR and branch works fine, please merge it
>
> > if you are interested to put this blog post in the perspective of how
> the atomic CLI works and explains its internals as you did, I can help you
> with the review and we could publish it on: http://www.projectatomic.io/bl
> og/.
> > What do you think?
>
> I'm in.
>
>
>
> On Sun, Feb 25, 2018 at 7:41 PM, Giuseppe Scrivano <gscri...@redhat.com>
> wrote:
>
>> Muayyad AlSadi <als...@gmail.com> writes:
>>
>> > here is my blog post
>> >
>> > https://bcksp.blogspot.com/2018/02/diy-docker-using-skopeoos
>> treerunc.html
>>
>> if you are interested to put this blog post in the perspective of how
>> the atomic CLI works and explains its internals as you did, I can help
>> you with the review and we could publish it on:
>> http://www.projectatomic.io/blog/.
>>
>> What do you think?
>>
>> Thanks,
>> Giuseppe
>>
>
>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

> Please use the original config.json file you get with 'runc spec
--rootless' and change only the process/args there.

that did not work,

> that won't work, you need to specify the mounts.  Have you tried with
bwrap-oci from the PR I've opened?

I'm using this

$ rpm -q bwrap-oci
bwrap-oci-0.2-1.fc27.x86_64

your PR and branch works fine





On Sun, Feb 25, 2018 at 4:29 PM, Giuseppe Scrivano <gscri...@redhat.com>
wrote:

>
> Muayyad AlSadi <als...@gmail.com> writes:
>
> > no, it did not work for me
> >
> > I've removed the entire mount section
> >
> > "mounts": [ ],
>
> that won't work, you need to specify the mounts.  Have you tried
> with bwrap-oci from the PR I've opened?
>
> Please use the original config.json file you get with 'runc spec
> --rootless' and change only the process/args there.
>
> Regards,
> Giuseppe
>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

no, it did not work for me

I've removed the entire mount section

"mounts": [ ],

I tried to only remove the sys/none item in mounts,

it got stuck (no output, no error message and on another terminal it would
be running)

the following

bwrap-oci --dry-run run delme

gives

/usr/bin/bwrap --userns-block-fd FD --as-pid-1 --die-with-parent --bind
rootfs / --unshare-pid --unshare-ipc --unshare-uts --unshare-user
--unshare-user --cap-drop ALL --cap-add CAP_KILL --cap-add
CAP_NET_BIND_SERVICE --cap-add CAP_AUDIT_WRITE --chdir / --setenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin --setenv TERM
xterm --uid 0 --gid 0 --proc /proc --dev /dev --bind /dev/pts /dev/pts
--tmpfs /dev/shm --mqueue /dev/mqueue --tmpfs /tmp --dev-bind /dev/tty
/dev/tty --hostname runc --block-fd FD --sync-fd FD --info-fd FD --bind
/dev/null /proc/kcore --bind /dev/null /proc/latency_stats --bind /dev/null
/proc/timer_list --bind /dev/null /proc/timer_stats --bind /dev/null
/proc/sched_debug --bind /dev/null /sys/firmware --bind /dev/null
/proc/scsi --ro-bind /proc/asound /proc/asound --ro-bind /proc/bus
/proc/bus --ro-bind /proc/fs /proc/fs --ro-bind /proc/irq /proc/irq
--ro-bind /proc/sys /proc/sys --ro-bind /proc/sysrq-trigger
/proc/sysrq-trigger --remount-ro / sh

which does not work but the following words fine

/usr/bin/bwrap --as-pid-1 --die-with-parent --bind rootfs / --unshare-pid
--unshare-ipc --unshare-uts --unshare-user --unshare-user --cap-drop ALL
--cap-add CAP_KILL --cap-add CAP_NET_BIND_SERVICE --cap-add CAP_AUDIT_WRITE
--chdir / --setenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin --setenv TERM
xterm --uid 0 --gid 0 --proc /proc --dev /dev --bind /dev/pts /dev/pts
--tmpfs /dev/shm --mqueue /dev/mqueue --tmpfs /tmp --dev-bind /dev/tty
/dev/tty --hostname runc --remount-ro / sh

the config is attached





On Sun, Feb 25, 2018 at 2:01 PM, Giuseppe Scrivano <gscri...@redhat.com>
wrote:

> Hi Muayyad,
>
> Muayyad AlSadi <als...@gmail.com> writes:
>
> > here is my blog post
> >
> > https://bcksp.blogspot.com/2018/02/diy-docker-using-
> skopeoostreerunc.html
>
> That is definitely a great blog post!  It is a very good explanation of
> how the atomic CLI works for a non root user.
>
>
> > the error in "bwrap-oci run"
> > bwrap-oci: unknown mount type none
> > was because of type none in /sys
> >
> > "mounts": [
> > ...
> > {
> > "destination": "/sys",
> > "type": "none",
> > "source": "/sys",
> > "options": [
> > "rbind",
> > "nosuid",
> > "noexec",
> > "nodev",
> > "ro"
> > ]
> > }
> >
> > but removing it did not solve the problem
>
> The issue you reported is a bug in bwrap-oci.  It fails with an error
> caused by the '"type" : "none"' generated by .runc spec --rootless.
>
> Could you please try if this PR solves the problem for you?
>
>   https://github.com/projectatomic/bwrap-oci/pull/17
>
> Another option is to change "none" to "bind" in the configuration file.
>
> In general bwrap-oci is more tolerant than runc with the config.json
> configuration.  bwrap-oci takes the freedom of adding the user namespace
> even if it is not specified and handle the users mapping inside of the
> container (if you need more than one user mapped please take a look at
> /etc/subuid and /etc/subgid).  It is designed this way so that the
> configuration that works for a system container could to some extend be
> used by a non root user in a seamless way.
>
> You should be fine to run the container with the config.json file you
> get with "runc spec" without the "--rootless" option.
>
> Please let me know if this works for you.
>
> Regards,
> Giuseppe
>


config.json
Description: application/json

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

here is my blog post

https://bcksp.blogspot.com/2018/02/diy-docker-using-skopeoostreerunc.html

the error in "bwrap-oci run"
bwrap-oci: unknown mount type none
was because of type none in /sys

"mounts": [
...
{
"destination": "/sys",
"type": "none",
"source": "/sys",
"options": [
"rbind",
"nosuid",
"noexec",
"nodev",
    "ro"
]
}

but removing it did not solve the problem



On Fri, Feb 23, 2018 at 1:49 AM, Muayyad AlSadi <als...@gmail.com> wrote:

> after that, the following worked
>
> cd cont1
> runc spec
> runc run myname
>
> I also tried "runc spec --rootless" and it worked but bwrap-oci did not
>
> $ bwrap-oci run
> bwrap-oci: unknown mount type none
>
>
>
> On Fri, Feb 23, 2018 at 1:33 AM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> ostree checkout ociimage/nginx_3Alatest cont1
>> cat cont1/manifest.json | jq '.layers[]|.digest' | sed -re 's/"//g' | cut
>> -d ':' -f 2 | while read a; do echo ostree checkout --union ociimage/$a
>> cont1/rootfs; done
>>
>> what's next?
>>
>>
>> On Fri, Feb 23, 2018 at 12:18 AM, Muayyad AlSadi <als...@gmail.com>
>> wrote:
>>
>>> hi,
>>>
>>> I'm running fedora as regular user
>>> and I wonder how can I use skopeo+ostree+bwrap-oci to run a docker image
>>> using bwrap-oci having files stored as ostree
>>>
>>> $ mkdir ostree
>>> $ cd ostree
>>> $ ostree init --mode=bare-user --repo=$PWD
>>> $ skopeo copy docker://redis:alpine ostree:redis@$PWD
>>> $ skopeo copy docker://nginx:alpine ostree:nginx@$PWD
>>> $ skopeo copy docker://busybox:alpine ostree:busybox@$PWD
>>> $ ostree refs
>>> $ ostree ls ociimage/redis_3Alatest
>>> $ ostree checkout ociimage/nginx_3Alatest cont1
>>> $ cd cont1
>>> $ bwrap-oci -c manifest.json run
>>> bwrap: --userns-block-fd requires --unshare-user
>>>
>>> so what went wrong?
>>>
>>>
>>
>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

after that, the following worked

cd cont1
runc spec
runc run myname

I also tried "runc spec --rootless" and it worked but bwrap-oci did not

$ bwrap-oci run
bwrap-oci: unknown mount type none



On Fri, Feb 23, 2018 at 1:33 AM, Muayyad AlSadi <als...@gmail.com> wrote:

> ostree checkout ociimage/nginx_3Alatest cont1
> cat cont1/manifest.json | jq '.layers[]|.digest' | sed -re 's/"//g' | cut
> -d ':' -f 2 | while read a; do echo ostree checkout --union ociimage/$a
> cont1/rootfs; done
>
> what's next?
>
>
> On Fri, Feb 23, 2018 at 12:18 AM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> hi,
>>
>> I'm running fedora as regular user
>> and I wonder how can I use skopeo+ostree+bwrap-oci to run a docker image
>> using bwrap-oci having files stored as ostree
>>
>> $ mkdir ostree
>> $ cd ostree
>> $ ostree init --mode=bare-user --repo=$PWD
>> $ skopeo copy docker://redis:alpine ostree:redis@$PWD
>> $ skopeo copy docker://nginx:alpine ostree:nginx@$PWD
>> $ skopeo copy docker://busybox:alpine ostree:busybox@$PWD
>> $ ostree refs
>> $ ostree ls ociimage/redis_3Alatest
>> $ ostree checkout ociimage/nginx_3Alatest cont1
>> $ cd cont1
>> $ bwrap-oci -c manifest.json run
>> bwrap: --userns-block-fd requires --unshare-user
>>
>> so what went wrong?
>>
>>
>

Re: [atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

ostree checkout ociimage/nginx_3Alatest cont1
cat cont1/manifest.json | jq '.layers[]|.digest' | sed -re 's/"//g' | cut
-d ':' -f 2 | while read a; do echo ostree checkout --union ociimage/$a
cont1/rootfs; done

what's next?


On Fri, Feb 23, 2018 at 12:18 AM, Muayyad AlSadi <als...@gmail.com> wrote:

> hi,
>
> I'm running fedora as regular user
> and I wonder how can I use skopeo+ostree+bwrap-oci to run a docker image
> using bwrap-oci having files stored as ostree
>
> $ mkdir ostree
> $ cd ostree
> $ ostree init --mode=bare-user --repo=$PWD
> $ skopeo copy docker://redis:alpine ostree:redis@$PWD
> $ skopeo copy docker://nginx:alpine ostree:nginx@$PWD
> $ skopeo copy docker://busybox:alpine ostree:busybox@$PWD
> $ ostree refs
> $ ostree ls ociimage/redis_3Alatest
> $ ostree checkout ociimage/nginx_3Alatest cont1
> $ cd cont1
> $ bwrap-oci -c manifest.json run
> bwrap: --userns-block-fd requires --unshare-user
>
> so what went wrong?
>
>

[atomic-devel] how to try combining skopeo+ostree+bwrap-oci

[Muayyad AlSadi]

hi,

I'm running fedora as regular user
and I wonder how can I use skopeo+ostree+bwrap-oci to run a docker image
using bwrap-oci having files stored as ostree

$ mkdir ostree
$ cd ostree
$ ostree init --mode=bare-user --repo=$PWD
$ skopeo copy docker://redis:alpine ostree:redis@$PWD
$ skopeo copy docker://nginx:alpine ostree:nginx@$PWD
$ skopeo copy docker://busybox:alpine ostree:busybox@$PWD
$ ostree refs
$ ostree ls ociimage/redis_3Alatest
$ ostree checkout ociimage/nginx_3Alatest cont1
$ cd cont1
$ bwrap-oci -c manifest.json run
bwrap: --userns-block-fd requires --unshare-user

so what went wrong?

Re: [atomic-devel] Httpd vs. Containers

[Muayyad AlSadi]

You can just symbolic link that to /data or /tmp
Or adjust config /etc/httpd/ to use /dev/stdout and /dev/stderr

On Mon, Apr 24, 2017, 7:49 PM Josh Berkus  wrote:

> Folks,
>
> I've been building some containers for our libraries, and I'm noticing
> that there's a serious deficiency in the standard Fedora and CentOS
> httpd packages for running them in a container, namely:
>
>httpd doesn't log to journald
>
> Our default packages for httpd still log to /var/log/httpd/  This means
> that not only can we not redirect the log output to the host (or
> kubernetes), but the container itself will grow indefinitely due to
> those log files.
>
> Given that the httpd packages should have been changed when Fedora and
> CentOS switched to systemd, I'm guessing that there's something else
> holding this back?
>
> What would people suggest is a good way to make our httpd RPMs usable in
> containers?
>
> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
>
>

Re: [atomic-devel] creating qcow2 for proof of concept appliance

[Muayyad AlSadi]

without ostree it's 98 MB,

OK: 98 MiB in 26 packages

there is no need to add grub, because I'm using fedora's grub (because
their's did not work)

I've made an alpine qcow2 that booted (a bunch of losetup, chroots,
fedora's grub2-install of fedora, ...)

assuming I ended with a qcow2 with a working alpine qcow2 + ostree +
fedora's grub2
how to make that into ostree ?

it seems that their initrd is just a simple script, and it seems that
supporting LVM in alpine is not fun

so I'll stop here





On Sat, Mar 18, 2017 at 12:01 AM, Muayyad AlSadi <als...@gmail.com> wrote:

> after adding grub
>
> OK: 129 MiB in 68 packages
>
>
> On Fri, Mar 17, 2017 at 11:59 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> I've done the following so far
>>
>> since I'm considering very minimal installation suitable for appliance, I
>> considered fedora's busybox, but in that case I would need to create a
>> statically linked ostree
>>
>> as I mentioned I'm not doing this to be for production server nor a
>> workstation
>> I tried to start with alpine linux, but they don't provide qcow2 images,
>>
>> so I run
>>
>> mkdir alpine-root
>> docker run --rm -ti --name a1 -v `pwd`/alpine-root:/data/ alpine /bin/sh
>>
>> and inside the container I run
>>
>> apk --arch x86_64 -X http://nl.alpinelinux.org/alpine/edge/main/  -X
>> http://nl.alpinelinux.org/alpine/edge/testing/ -U --allow-untrusted
>> --root /data --initdb add alpine-base ostree linux-virtgrsec
>>
>> the end result was
>>
>> OK: 120 MiB in 67 packages
>>
>> compared to 6 MB without ostree and kernel
>>
>> I guess linux-virtgrsec is the smallest kernel they have
>>
>> I'm not sure if 120MB for an embedded appliance is good or bad.
>> and this image does not have a bootloader yet
>>
>> but ostree seems to be working!
>>
>> now I have a directory /alpine-root having a working ostree and a kernel
>>
>> what's next? add a bootloader and make that a qcow2 and make an ostree
>> out of it
>>
>> references
>> https://wiki.alpinelinux.org/wiki/Bootstrapping_Alpine_Linux
>>
>>
>>
>>
>> On Tue, Mar 7, 2017 at 5:45 AM, Trishna Guha <trishnaguh...@gmail.com>
>> wrote:
>>
>>> On Mon, Mar 6, 2017 at 9:37 PM, Dusty Mabe <du...@dustymabe.com> wrote:
>>> > So trishna just put out some content recently on how to build an
>>> > atomic host. While it's not the official way we do it, this [1]
>>> > might be useful to you.
>>> > [1] https://fedoramagazine.org/automate-building-fedora-atomic/
>>>
>>> I would suggest directly to look at the repository [0] now.
>>> It does the setup like it does in the magazine article.
>>> In additional you can compose OSTree with customized packages for the
>>> Atomic host.
>>>
>>> [0] https://github.com/trishnaguha/build-atomic-host
>>>
>>> --
>>> Regards,
>>> Trishna Guha
>>>
>>> trishnaguh...@gmail.com
>>> trishnag.wordpress.com
>>>
>>
>>
>

Re: [atomic-devel] creating qcow2 for proof of concept appliance

[Muayyad AlSadi]

after adding grub

OK: 129 MiB in 68 packages


On Fri, Mar 17, 2017 at 11:59 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> I've done the following so far
>
> since I'm considering very minimal installation suitable for appliance, I
> considered fedora's busybox, but in that case I would need to create a
> statically linked ostree
>
> as I mentioned I'm not doing this to be for production server nor a
> workstation
> I tried to start with alpine linux, but they don't provide qcow2 images,
>
> so I run
>
> mkdir alpine-root
> docker run --rm -ti --name a1 -v `pwd`/alpine-root:/data/ alpine /bin/sh
>
> and inside the container I run
>
> apk --arch x86_64 -X http://nl.alpinelinux.org/alpine/edge/main/  -X
> http://nl.alpinelinux.org/alpine/edge/testing/ -U --allow-untrusted
> --root /data --initdb add alpine-base ostree linux-virtgrsec
>
> the end result was
>
> OK: 120 MiB in 67 packages
>
> compared to 6 MB without ostree and kernel
>
> I guess linux-virtgrsec is the smallest kernel they have
>
> I'm not sure if 120MB for an embedded appliance is good or bad.
> and this image does not have a bootloader yet
>
> but ostree seems to be working!
>
> now I have a directory /alpine-root having a working ostree and a kernel
>
> what's next? add a bootloader and make that a qcow2 and make an ostree out
> of it
>
> references
> https://wiki.alpinelinux.org/wiki/Bootstrapping_Alpine_Linux
>
>
>
>
> On Tue, Mar 7, 2017 at 5:45 AM, Trishna Guha <trishnaguh...@gmail.com>
> wrote:
>
>> On Mon, Mar 6, 2017 at 9:37 PM, Dusty Mabe <du...@dustymabe.com> wrote:
>> > So trishna just put out some content recently on how to build an
>> > atomic host. While it's not the official way we do it, this [1]
>> > might be useful to you.
>> > [1] https://fedoramagazine.org/automate-building-fedora-atomic/
>>
>> I would suggest directly to look at the repository [0] now.
>> It does the setup like it does in the magazine article.
>> In additional you can compose OSTree with customized packages for the
>> Atomic host.
>>
>> [0] https://github.com/trishnaguha/build-atomic-host
>>
>> --
>> Regards,
>> Trishna Guha
>>
>> trishnaguh...@gmail.com
>> trishnag.wordpress.com
>>
>
>

Re: [atomic-devel] creating qcow2 for proof of concept appliance

[Muayyad AlSadi]

I've done the following so far

since I'm considering very minimal installation suitable for appliance, I
considered fedora's busybox, but in that case I would need to create a
statically linked ostree

as I mentioned I'm not doing this to be for production server nor a
workstation
I tried to start with alpine linux, but they don't provide qcow2 images,

so I run

mkdir alpine-root
docker run --rm -ti --name a1 -v `pwd`/alpine-root:/data/ alpine /bin/sh

and inside the container I run

apk --arch x86_64 -X http://nl.alpinelinux.org/alpine/edge/main/  -X
http://nl.alpinelinux.org/alpine/edge/testing/ -U --allow-untrusted --root
/data --initdb add alpine-base ostree linux-virtgrsec

the end result was

OK: 120 MiB in 67 packages

compared to 6 MB without ostree and kernel

I guess linux-virtgrsec is the smallest kernel they have

I'm not sure if 120MB for an embedded appliance is good or bad.
and this image does not have a bootloader yet

but ostree seems to be working!

now I have a directory /alpine-root having a working ostree and a kernel

what's next? add a bootloader and make that a qcow2 and make an ostree out
of it

references
https://wiki.alpinelinux.org/wiki/Bootstrapping_Alpine_Linux




On Tue, Mar 7, 2017 at 5:45 AM, Trishna Guha 
wrote:

> On Mon, Mar 6, 2017 at 9:37 PM, Dusty Mabe  wrote:
> > So trishna just put out some content recently on how to build an
> > atomic host. While it's not the official way we do it, this [1]
> > might be useful to you.
> > [1] https://fedoramagazine.org/automate-building-fedora-atomic/
>
> I would suggest directly to look at the repository [0] now.
> It does the setup like it does in the magazine article.
> In additional you can compose OSTree with customized packages for the
> Atomic host.
>
> [0] https://github.com/trishnaguha/build-atomic-host
>
> --
> Regards,
> Trishna Guha
>
> trishnaguh...@gmail.com
> trishnag.wordpress.com
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Muayyad AlSadi]

https://admin.fedoraproject.org/pkgdb/package/rpms/dumb-init/
https://copr.fedorainfracloud.org/coprs/alsadi/dumb-init/

On Tue, Mar 7, 2017 at 4:42 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> typical use is a Dockerfile having
>
> RUN curl -sSL -o /usr/local/bin/dumb-init https://github.com/Yelp/dumb-
> init/releases/download/v1.0.2/dumb-init_1.0.2_amd64 && chmod +x
> /usr/local/bin/dumb-init
>
> ENTRYPOINT ["dumb-init", "--", "/start.sh"]
>
>
>
>
> On Tue, Mar 7, 2017 at 4:38 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> I've packaged dumb-init, it's in copr
>> And there was a package review for official repos
>>
>> > Anyone using these today?
>>
>> yes, I use it along with oneway < https://github.com/muayyad-als
>> adi/oneway/releases/
>>
>> > What does dumb-init or tini get me that systemd doesn't?
>>
>> simply dumb init does not thing, it's just exec a single process (the
>> docker way which is single process per container)
>>
>> so instead of start.sh we use dumb-init start.sh
>>
>> it's not intended to do what sysvinit / systemd / upstart do
>> it just fork then exec it's argument, the parent process just handle defunct
>> processes
>>
>> > I am skeptical of any "resource" argument against systemd
>>
>> it does not do any management (the dumb part of it's name)
>>
>> > I think multiple init systems will just generate more technical
>> questions
>>
>> please give it a chance, not because we need another init system, but
>> because it's NOT an init system.
>> it just run a single process (look at supervisord which is in the
>> official repo, is more close to be an init system than dumb-init)
>>
>> > Doesn't work in Kubernetes today.
>>
>> I do use it with k8s!
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 7, 2017 at 3:32 PM, Clayton Coleman <ccole...@redhat.com>
>> wrote:
>>
>>> Doesn't work in Kubernetes today.
>>>
>>> > On Mar 7, 2017, at 2:44 AM, Marius Vollmer <marius.voll...@redhat.com>
>>> wrote:
>>> >
>>> >
>>> > Clayton Coleman <ccole...@redhat.com> writes:
>>> >
>>> >> [...] Anyone using these today?
>>> >
>>> > What about "docker run --init"?  Anything wrong with that?
>>>
>>>
>>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Muayyad AlSadi]

typical use is a Dockerfile having

RUN curl -sSL -o /usr/local/bin/dumb-init
https://github.com/Yelp/dumb-init/releases/download/v1.0.2/dumb-init_1.0.2_amd64
&& chmod +x /usr/local/bin/dumb-init

ENTRYPOINT ["dumb-init", "--", "/start.sh"]




On Tue, Mar 7, 2017 at 4:38 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> I've packaged dumb-init, it's in copr
> And there was a package review for official repos
>
> > Anyone using these today?
>
> yes, I use it along with oneway < https://github.com/muayyad-
> alsadi/oneway/releases/
>
> > What does dumb-init or tini get me that systemd doesn't?
>
> simply dumb init does not thing, it's just exec a single process (the
> docker way which is single process per container)
>
> so instead of start.sh we use dumb-init start.sh
>
> it's not intended to do what sysvinit / systemd / upstart do
> it just fork then exec it's argument, the parent process just handle defunct
> processes
>
> > I am skeptical of any "resource" argument against systemd
>
> it does not do any management (the dumb part of it's name)
>
> > I think multiple init systems will just generate more technical
> questions
>
> please give it a chance, not because we need another init system, but
> because it's NOT an init system.
> it just run a single process (look at supervisord which is in the official
> repo, is more close to be an init system than dumb-init)
>
> > Doesn't work in Kubernetes today.
>
> I do use it with k8s!
>
>
>
>
>
>
>
>
> On Tue, Mar 7, 2017 at 3:32 PM, Clayton Coleman <ccole...@redhat.com>
> wrote:
>
>> Doesn't work in Kubernetes today.
>>
>> > On Mar 7, 2017, at 2:44 AM, Marius Vollmer <marius.voll...@redhat.com>
>> wrote:
>> >
>> >
>> > Clayton Coleman <ccole...@redhat.com> writes:
>> >
>> >> [...] Anyone using these today?
>> >
>> > What about "docker run --init"?  Anything wrong with that?
>>
>>
>

Re: [atomic-devel] Has anyone considered packaging dumb-init or tini for use in Fedora/CentOS/RHEL?

[Muayyad AlSadi]

I've packaged dumb-init, it's in copr
And there was a package review for official repos

> Anyone using these today?

yes, I use it along with oneway <
https://github.com/muayyad-alsadi/oneway/releases/

> What does dumb-init or tini get me that systemd doesn't?

simply dumb init does not thing, it's just exec a single process (the
docker way which is single process per container)

so instead of start.sh we use dumb-init start.sh

it's not intended to do what sysvinit / systemd / upstart do
it just fork then exec it's argument, the parent process just handle defunct
processes

> I am skeptical of any "resource" argument against systemd

it does not do any management (the dumb part of it's name)

> I think multiple init systems will just generate more technical questions

please give it a chance, not because we need another init system, but
because it's NOT an init system.
it just run a single process (look at supervisord which is in the official
repo, is more close to be an init system than dumb-init)

> Doesn't work in Kubernetes today.

I do use it with k8s!








On Tue, Mar 7, 2017 at 3:32 PM, Clayton Coleman <ccole...@redhat.com> wrote:

> Doesn't work in Kubernetes today.
>
> > On Mar 7, 2017, at 2:44 AM, Marius Vollmer <marius.voll...@redhat.com>
> wrote:
> >
> >
> > Clayton Coleman <ccole...@redhat.com> writes:
> >
> >> [...] Anyone using these today?
> >
> > What about "docker run --init"?  Anything wrong with that?
>
>

Re: [atomic-devel] creating qcow2 for proof of concept appliance

[Muayyad AlSadi]

> So trishna just put out some content recently on how to build

yes, I've seen them, and such articles triggered the idea

and I have made some custom os-tree builds in the past

> your goals ... project 

typically I use fedora/centos for my REAL work (I work for web company)
but the intention of this post is only proof of concept to demonstrate the
power of os-tree
out side typical cloud work loads, but indeed in appliances (ex. a headless
router or a box with graphical UI running wayland)

why I think atomic is relevant?
they need atomic image updates, without package manager
they need very minimal OS that fits in some sd
the manufacturer only need http to host his blobs (ex. s3) for remote
updates

what is the scope of the project?
phase 1.

a headless bootable qcow2 image with busybox, golang-based web server that
just show datetime and project atomic logo (maybe os meta data ex. version)

phase 2.
a very minimal wayland graphical application that shows project atomic logo
and a button to display os meta data like version, build date ..etc.


considerations
1. size (try to remove all kinds of dependencies by using staticlly linked
binaries, golang,...)
2. boot speed

why?
for fun, as I don't have any factory that produce appliances.

> how best to achive them. I'm @dustymabe in #atomic on Freenode.

I'll be there

[atomic-devel] creating qcow2 for proof of concept appliance

[Muayyad AlSadi]

hi,

I have an idea to demonstrate (in a blog post, video, ..etc.) the power of
os-tree and project atomic, outside the word of production servers

I have two example use cases,

a headless appliance (busybox, simple go http server)
a graphical wayland application that display animated project atomic logo

we need to demonstrate creations of

* a qcow2 image
* steps to create custom os-tree repo local/remote repo
* steps to push an update

it should have latest fedora kernel
it should have very minimal system (almost nothing, preferably busybox and
static go every thing)

this link might be useful

https://github.com/mikkeloscar/go-wlc
https://github.com/BurntSushi/go-wayland-simple-shm

[atomic-devel] SELinux permission problem with fedora 25 but not 24 when using emptyDir: {}

[Muayyad AlSadi]

Hi,

I have a kube spec like this (full yaml here
https://paste.fedoraproject.org/527041/48440635/raw/)

...
spec:
  containers:
- name: mypod
  image: fedora
  imagePullPolicy: Always
  command:
- /bin/bash
  args:
- "-c"
- "sleep 3600"
  volumeMounts:
- name: mydata
  mountPath: /data
  volumes:
- name: mydata
  emptyDir: {}
  securityContext: {}
...

when I kubectl exec into it and type

touch /data/something

it gives permission problem

the directory ls -lhdZ .

drwxrwxrwx. 2 root root system_u:object_r:var_lib_t:s0 6 Jan 14 15:06 .

docker inspect show something like

...
"MountLabel": "system_u:object_r:container_file_t:s0:c191,c610",
"ProcessLabel": "system_u:system_r:container_t:s0:c191,c610",
...
"Binds": [

"/var/lib/kubelet/pods/fd1dba6c-da67-11e6-9f74-0aeaf5f6fe91/volumes/
kubernetes.io~empty-dir/redis:/data",
...
"SecurityOpt": [
"seccomp=unconfined"
],
...

do I have to adjust kube config or label /var/lib/kubelet/ ?

Re: [atomic-devel] Docker project: Can you have overlay2 speed and density with devicemapper? Yep.

[Muayyad AlSadi]

I have a serious question about a way to map UIDs inside the container to
UIDs outside it. And a way to specify UID for mounted volumes like /data/
and /app/code/

Let's look to the topic from developer point of view.

I have vagrant sshfs mouting my home into the box.

My home have volumes owned by me with uid=1001. Also it have my ide and my
code.

I have a container that have a user called app with uid=1000 and have an
old clone in /app/code/

I'm mounting /home/ali/volumes/proj1 into /data/
And sometimes /home/ali/workspace/proj1 into /app/code

The problem is we can't specify uid of those mounts inside the containers.

One way is to sed /etc/passwd to change uid of the in container app user

But in that case we need to chmod /app/code from old uid before sed to new
one.
Which require writable container.

The otherway is to keep app uid as is but to chown /data (passed from
outside) to uid 1000 (app) which would create a problem outside.

If we can specify uid when mounting that would solve the problem.

On Oct 26, 2016 9:53 PM, "Clayton Coleman"  wrote:

> Yeah it sounds like it - that's a good place to start, and then if we
> realize we need the knob we can come back and decide on an API object
> change if necessary.
>
> On Wed, Oct 26, 2016 at 2:46 PM, Mrunal Patel  wrote:
>
>> IMO, this doesn't really need any new knobs in the pod spec. This could
>> be handled under the hood in the container runtime level (by config or
>> default).
>>
>>
>> On Wed, Oct 26, 2016 at 11:44 AM, Jeremy Eder  wrote:
>>
>>> ​If a user specifies read-only in their podspec...what does that
>>> translate to (it might be a distro-specific question).  IMO the
>>> --shared-rootfs should be the default when --read-only is specified, but
>>> it's not atm.
>>>
>>> Vivek has implemented it for devicemapper first.  But the intent is that
>>> it will be added to most or all graph drivers, including overlay/overlay2.
>>> It has the most benefit on devicemapper or btrfs which have unique inodes
>>> per container.
>>>
>>>
>>>
>>>
>>> On Wed, Oct 26, 2016 at 2:20 PM, Vishnu Kannan 
>>> wrote:
>>>
 *What* do you intend to surface to users? IIUC, this discussion is
 specific to device mapper storage drivers right?

 On Tue, Oct 25, 2016 at 5:03 AM, Jeremy Eder  wrote:

> Hi,
>
> Vivek Goyal (cc) and I were discussing ways to deliver page cache
> sharing, POSIX compliance and SELinux support with a single docker graph
> driver, using existing kernel facilities.  We decided to go with a
> bind-mount technique, and Vivek has posted a first cut here:
> https://github.com/docker/docker/pull/27364​
>
> Testing of the prototype looks like a great improvement:
> ​http://developerblog.redhat.com/2016/10/25/docker-project-c
> an-you-have-overlay2-speed-and-density-with-devicemapper-yep/
>
> Assuming this type of feature is merged in a container run-time, what
> preference would Kube folks have for surfacing this to users ... currently
> it's a daemon runtime flag that says ... if you use --read-only then you
> get the shared-rootfs as well.  Obviously this requires "12factor-ish"
> design up front, because you can no longer scribble in the container
> filesystem in places that are not persistent volumes, but we think
> read-only container hygiene is well worth the security and performance
> improvements to be had.
>
> https://twitter.com/rhdevelopers/status/790870667008757760
>
> --
> You received this message because you are subscribed to the Google
> Groups "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to kubernetes-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to kubernetes-...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/CABxNGQa-VL
> zP%3DEFYQucfJtTEtSHmWac4Tv%3Dc%2BQVAFJNcDLSb1g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


>>>
>>>
>>> --
>>>
>>> -- Jeremy Eder
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to kubernetes-dev+unsubscr...@googlegroups.com.
>> To post to this group, send email to kubernetes-...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/kubernetes-dev/CANEZBD4zd%3Dk-m2B2rK5Eixv_%2BfY3tFqSgJa%
>> 2BaemW4f4fj5g3Bg%40mail.gmail.com
>> 

[atomic-devel] Grant your developers jailed shell access to some containers

[Muayyad AlSadi]

Hi

Checkout this simple project

https://github.com/muayyad-alsadi/docker-jumpshell

Re: [atomic-devel] systemd as pid 1 in an unprivileged container.

[Muayyad AlSadi]

Here
https://github.com/fedora-cloud/Fedora-Dockerfiles
And here

https://admin.fedoraproject.org/pkgdb/package/rpms/fedora-dockerfiles/

On Wed, Sep 14, 2016, 9:56 PM Daniel J Walsh <dwa...@redhat.com> wrote:

> Sure, but I have no idea how to?
>
> On 09/14/2016 12:34 PM, Muayyad AlSadi wrote:
>
> would you please update this
>
> https://hub.docker.com/r/fedora/systemd-systemd/
>
>
> On Wed, Sep 14, 2016 at 4:14 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> Awesome!
>>
>> On Wed, Sep 14, 2016, 3:51 PM Daniel J Walsh <dwa...@redhat.com> wrote:
>>
>>>
>>> On 09/14/2016 05:26 AM, Muayyad AlSadi wrote:
>>>
>>> Nice article.
>>>
>>> I would like to stress that docker is intended to be process container
>>> not system container.
>>>
>>> In adeal (aka. Fictional unicorn) containers you would have a single
>>> process. Your start.sh should exec (to replace the shell) the application
>>> ("exec node ." Or "exec java -jar start.jar")
>>>
>>> Many applications does not fit such restrictions. People end up using
>>> things like supervisord (a python script that manage multiple processes )
>>> but of course it won't work out of the box. One need to rewrite services
>>> into its .ini format.
>>>
>>> We have seen many fake systemds that are not 100% compatible.
>>>
>>> Having real systemd would make dockerizing such apps a trivial job.
>>>
>>> I would love if real systemd that just work. that fail gracefully for
>>> example when it does not have cgroups mounted it would just ignore
>>> cgroups-related directives.
>>>
>>> I wish if I just run
>>>
>>> docker run -dt fedora-systemd
>>>
>>> Without any -v
>>>
>>> How far are we from this?
>>>
>>> We have it now, that is what is  talked about in the end of the article,
>>> oci-systemd--hook.
>>>
>>> On Sep 13, 2016 8:55 PM, "Daniel J Walsh" <dwa...@redhat.com> wrote:
>>>
>>>>
>>>> http://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/
>>>>
>>>>
>>>>
>>>
>
>

Re: [atomic-devel] systemd as pid 1 in an unprivileged container.

[Muayyad AlSadi]

would you please update this

https://hub.docker.com/r/fedora/systemd-systemd/


On Wed, Sep 14, 2016 at 4:14 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> Awesome!
>
> On Wed, Sep 14, 2016, 3:51 PM Daniel J Walsh <dwa...@redhat.com> wrote:
>
>>
>> On 09/14/2016 05:26 AM, Muayyad AlSadi wrote:
>>
>> Nice article.
>>
>> I would like to stress that docker is intended to be process container
>> not system container.
>>
>> In adeal (aka. Fictional unicorn) containers you would have a single
>> process. Your start.sh should exec (to replace the shell) the application
>> ("exec node ." Or "exec java -jar start.jar")
>>
>> Many applications does not fit such restrictions. People end up using
>> things like supervisord (a python script that manage multiple processes )
>> but of course it won't work out of the box. One need to rewrite services
>> into its .ini format.
>>
>> We have seen many fake systemds that are not 100% compatible.
>>
>> Having real systemd would make dockerizing such apps a trivial job.
>>
>> I would love if real systemd that just work. that fail gracefully for
>> example when it does not have cgroups mounted it would just ignore
>> cgroups-related directives.
>>
>> I wish if I just run
>>
>> docker run -dt fedora-systemd
>>
>> Without any -v
>>
>> How far are we from this?
>>
>> We have it now, that is what is  talked about in the end of the article,
>> oci-systemd--hook.
>>
>> On Sep 13, 2016 8:55 PM, "Daniel J Walsh" <dwa...@redhat.com> wrote:
>>
>>> http://developers.redhat.com/blog/2016/09/13/running-
>>> systemd-in-a-non-privileged-container/
>>>
>>>
>>>
>>

Re: [atomic-devel] systemd as pid 1 in an unprivileged container.

[Muayyad AlSadi]

Awesome!

On Wed, Sep 14, 2016, 3:51 PM Daniel J Walsh <dwa...@redhat.com> wrote:

>
> On 09/14/2016 05:26 AM, Muayyad AlSadi wrote:
>
> Nice article.
>
> I would like to stress that docker is intended to be process container not
> system container.
>
> In adeal (aka. Fictional unicorn) containers you would have a single
> process. Your start.sh should exec (to replace the shell) the application
> ("exec node ." Or "exec java -jar start.jar")
>
> Many applications does not fit such restrictions. People end up using
> things like supervisord (a python script that manage multiple processes )
> but of course it won't work out of the box. One need to rewrite services
> into its .ini format.
>
> We have seen many fake systemds that are not 100% compatible.
>
> Having real systemd would make dockerizing such apps a trivial job.
>
> I would love if real systemd that just work. that fail gracefully for
> example when it does not have cgroups mounted it would just ignore
> cgroups-related directives.
>
> I wish if I just run
>
> docker run -dt fedora-systemd
>
> Without any -v
>
> How far are we from this?
>
> We have it now, that is what is  talked about in the end of the article,
> oci-systemd--hook.
>
> On Sep 13, 2016 8:55 PM, "Daniel J Walsh" <dwa...@redhat.com> wrote:
>
>>
>> http://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/
>>
>>
>>
>

Re: [atomic-devel] Oneway - a way to drop privileges inside containers and lock it like that

[Muayyad AlSadi]

That's being said I would recommend real systemd for fat containers like
freeipa

https://github.com/adelton/docker-freeipa

IMHO dumb-init is meant to replace /start.sh (making it dumb-init
/start.sh) not to replace systemd.

My quesion is oneway.c properly written and safe and do what I expect it to
do?

On Tue, Sep 6, 2016, 9:22 PM Daniel J Walsh <dwa...@redhat.com> wrote:

>
>
> On 09/06/2016 02:16 PM, Muayyad AlSadi wrote:
>
> I only want two processes
>
> confd and my application (apache or php-fpm or node . or uwsgi ...)
>
> The role of confd is to watch etcd/consul and update config when needed.
>
> I guess systemd is overkill for such simple thing (I don't want  ttys,
> crons, dbus, journald)
>
> systemd in a container would just run journald as well as systemd, not
> much more unless you tell it to.
> Having journald would allow you to catch messages that httpd writes to
> syslog, but fine.
>
> Apache is a well-established and it have a way to drop privileges but this
> is not the case with "node ."
>
> I'm not sure about k8s no new priv.
> Ex. I want confd as root and node as app.
>
> I guess apache does not have nnp option.
>
> On Tue, Sep 6, 2016, 9:05 PM Daniel J Walsh <dwa...@redhat.com> wrote:
>
>> A couple of things.  1 you could use real systemd rather then using some
>> other init system.
>>
>> Secondly and perhaps conflicting, is why not run apache as non root to
>> start rather then dropping
>>
>> privs.  Apache will run perfectly fine without requiring root privs.
>> Also you could set the NO_NEW_PRIVS
>>
>> right in docker/k8s.
>>
>>
>> On 09/06/2016 01:46 PM, Muayyad AlSadi wrote:
>> >
>> > Hi,
>> >
>> > Typical fictional unicorn containers should have one process
>> >
>> > On practice it's actually processes of one concern ex. Apache
>> >
>> > One issue is that your entry point /start.sh should exec to replace
>> > the shell (so that application process would recieve signals)
>> >
>> > Since start.sh is pid 1 it has the responsibility to handle zombies.
>> > For this we can use yelp's dumb-init (which is almost to be pushed to
>> > official repo and already in copr)
>> >
>> > https://github.com/Yelp/dumb-init
>> >
>> > Typically our start.sh start confd in background using nohup
>> >
>> > Then I exec my application but I would like to drop privileges, first
>> > I used exec sudo or exec su but it wont replace the proces.
>> >
>> > I wrote a simple application that drop groups , supplementary groups
>> > and user
>> >
>> > Not only that but also it can optionally set
>> > PR_SET_NO_NEW_PRIVS with prctl
>> > So that it will never get more privileges even with sudo/su.
>> >
>> > What do you think?
>> >
>> > https://github.com/muayyad-alsadi/oneway/blob/master/README.md
>> >
>>
>>
>

[atomic-devel] Oneway - a way to drop privileges inside containers and lock it like that

[Muayyad AlSadi]

Hi,

Typical fictional unicorn containers should have one process

On practice it's actually processes of one concern ex. Apache

One issue is that your entry point /start.sh should exec to replace the
shell (so that application process would recieve signals)

Since start.sh is pid 1 it has the responsibility to handle zombies. For
this we can use yelp's dumb-init (which is almost to be pushed to official
repo and already in copr)

https://github.com/Yelp/dumb-init

Typically our start.sh start confd in background using nohup

Then I exec my application but I would like to drop privileges, first I
used exec sudo or exec su but it wont replace the proces.

I wrote a simple application that drop groups , supplementary groups and
user

Not only that but also it can optionally set
PR_SET_NO_NEW_PRIVS with prctl
So that it will never get more privileges even with sudo/su.

What do you think?

https://github.com/muayyad-alsadi/oneway/blob/master/README.md

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

BTW: I'm considering writing my own "supervisord"-like in go (to make it
single binary)

which unlike runit, s6 and others does not intend to be full init system
(no ttys, no logs, no crons)
just like supervisord, it just process supervisor that allow you to run
multiprocess container.
I'm considering an almost compatible ini syntax to systemd (so it could be
called go-systemd, or yet another fake systemd)

why not just supervisord, because we are considering python-less micro base
image for apps that does not need python specially go binary containers
(ex. busybox, etcd, kube*, .. )

but I'm not sure if this is even a good idea or not



On Thu, Jul 14, 2016 at 12:02 AM, Muayyad AlSadi <als...@gmail.com> wrote:

> Try fake runtime which provides systemd (fake one indeed).
>
> On Wed, Jul 13, 2016, 11:55 PM Colin Walters <walt...@verbum.org> wrote:
>
>>
>>
>> On Mon, Jun 20, 2016, at 01:57 PM, Micah Abbott wrote:
>> > On 06/20/2016 09:38 AM, Joe Brockmeier wrote:
>> > > Have we published any comparisons of an Alpine image "fully loaded"
>> > > (e.g., with the actual tools) vs. Fedora, etc.? AIUI, when you
>> actually
>> > > install things like Apache httpd, or whatnot the comparison looks much
>> > > closer.
>> >
>> > I hacked up some quick Dockerfiles for this particular example (httpd)
>> > and the end result is that alpine was still smaller - 8.652 MB vs.
>> 232.8 MB
>>
>> The largest chunk of this is that the httpd RPM pulls in systemd, and
>> that's
>> going to be true presently for a lot of our RPMs.  So that's a whole
>> subthread to this.
>>
>> It'd be possible to teach micro-yuminst to just ignore requirements
>> on specific packages like systemd, while still allowing anyone who
>> explicitly
>> wants them to pull them in.
>>
>>

Re: [atomic-devel] Blog post about upgrading from f23 atomic to f24?

[Muayyad AlSadi]

The commands are here

https://fedoraproject.org/wiki/Atomic_Host_upgrade

On Jul 14, 2016 1:05 AM, "Muayyad AlSadi" <als...@gmail.com> wrote:

> Yes it's a simple ostree rebase
>
> But no, it's not recommended  I guess because 23 is more recent and
> maintained.
>
> As you can see here f24 atomic is not released. The latest build is a
> month ago, while f23 is a week ago
>
> https://getfedora.org/en/cloud/download/atomic.html
>
> On Jul 14, 2016 12:55 AM, "Josh Berkus" <jber...@redhat.com> wrote:
>
> Can someone write this?  Or at least give me a set of recommended steps
> so I can?
>
> Is it as simple as ostree rebase?
>
> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
>
>
>

Re: [atomic-devel] Blog post about upgrading from f23 atomic to f24?

[Muayyad AlSadi]

Yes it's a simple ostree rebase

But no, it's not recommended  I guess because 23 is more recent and
maintained.

As you can see here f24 atomic is not released. The latest build is a month
ago, while f23 is a week ago

https://getfedora.org/en/cloud/download/atomic.html

On Jul 14, 2016 12:55 AM, "Josh Berkus"  wrote:

Can someone write this?  Or at least give me a set of recommended steps
so I can?

Is it as simple as ostree rebase?

--
--
Josh Berkus
Project Atomic
Red Hat OSAS

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

Try fake runtime which provides systemd (fake one indeed).

On Wed, Jul 13, 2016, 11:55 PM Colin Walters  wrote:

>
>
> On Mon, Jun 20, 2016, at 01:57 PM, Micah Abbott wrote:
> > On 06/20/2016 09:38 AM, Joe Brockmeier wrote:
> > > Have we published any comparisons of an Alpine image "fully loaded"
> > > (e.g., with the actual tools) vs. Fedora, etc.? AIUI, when you actually
> > > install things like Apache httpd, or whatnot the comparison looks much
> > > closer.
> >
> > I hacked up some quick Dockerfiles for this particular example (httpd)
> > and the end result is that alpine was still smaller - 8.652 MB vs. 232.8
> MB
>
> The largest chunk of this is that the httpd RPM pulls in systemd, and
> that's
> going to be true presently for a lot of our RPMs.  So that's a whole
> subthread to this.
>
> It'd be possible to teach micro-yuminst to just ignore requirements
> on specific packages like systemd, while still allowing anyone who
> explicitly
> wants them to pull them in.
>
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

I'll be happy if arg parsing is missing but the assumed default is nodocs

On Wed, Jul 13, 2016, 11:47 PM Colin Walters <walt...@verbum.org> wrote:

> On Wed, Jul 13, 2016, at 04:40 PM, Muayyad AlSadi wrote:
>
> What about my question about the equivalent of "--setopt tsflags=nodocs"
>
> @walters does micro-yuminst assume this option
>
>
> https://github.com/cgwalters/micro-yuminst/issues/1
>
> I'll rework the command line parsing soon to better support things like
> this.
>
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

What about my question about the equivalent of "--setopt tsflags=nodocs"

@walters does micro-yuminst assume this option

On Wed, Jul 13, 2016, 11:25 PM Colin Walters  wrote:

> On Wed, Jul 13, 2016, at 09:40 AM, Tim St. Clair wrote:
>
> Awesome!
>
> Do we have a formal position, or is this still POC?
>
>
> Still a PoC, but I believe it'd be relatively easy for downstreams to
> productize.  For
> example, we're using librepo[1] which is the same library used by dnf (and
> rpm-ostree)
> that knows how to speak TLS client certificates[2] that Red Hat Enterprise
> Linux uses
> to gate access to content.  And for that matter implements RPM GPG
> verification the same
> way.
>
> In general the micro-yuminst layer will require some maintenance but not
> that much;
> "yum -y install" is 95% of anyone wants to do in Docker images.
>
> Probably the next interesting question is whether the current base images
> should derive from this.
>
> Anyways, I encourage feedback as issues in
> https://github.com/cgwalters/centos-dockerbase-minimal
>
> If there's enough interest, we'll see about importing it into the
> projectatomic/ github org and
> taking next steps like integrating it into the CentOS build processes.
>
> BTW, I set up a Jenkins job for this:
> https://ci.centos.org/job/atomic-dockerimage-centosmin/
>
> [1] https://github.com/rpm-software-management/librepo
> [2] https://github.com/rpm-software-management/libhif/pull/144
>
>

Re: [atomic-devel] Exposing Pods to external network

[Muayyad AlSadi]

regarding type=NodePort the docs say

If you set the type field to "NodePort", the Kubernetes master will
> allocate a port from a flag-configured range (default: 3-32767), and
> each Node will proxy that port (the same port number on every Node) into
> your Service. That port will be reported in your Service’s
> spec.ports[*].nodePort field.
>

so you either specify this number in that range and open NodeIP:NodePort or
let it pick random and you query this port from

kubectl desc service XYZ

-

the other option is keep it type=ClusterIP (the default type) but to
specify ExternalIPs, the docs say

In the ServiceSpec, externalIPs can be specified along with any of the
> ServiceTypes. In the example below, my-service can be accessed by clients
> on 80.11.12.10:80 (externalIP:port)
>



On Wed, Jul 13, 2016 at 10:29 AM, Rafiqul Islam <rafi...@telenordigital.com>
wrote:

> Thanks for help replying.
> I am not sure how cluster IP will work, let me go through the links, and I
> will revert go to you.
>
> On Mon, Jul 11, 2016 at 1:55 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> I guess you can specify type=NodePort
>>
>> or use specify externalIPs  with type=ClusterIP (which is the default
>> type)
>>
>> kubectl describe service NAME
>>
>>
>> http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_servicespec
>> http://kubernetes.io/docs/user-guide/services/
>> http://kubernetes.io/docs/user-guide/load-balancer/
>> http://kubernetes.io/docs/user-guide/services/operations/
>>
>> On Mon, Jul 11, 2016 at 7:28 AM, Rafiqul Islam <
>> rafi...@telenordigital.com> wrote:
>>
>>> Thanks for the reply.
>>>
>>> Questions:
>>>
>>> 1. What distro of Atomic are you using?
>>> Fedora-Cloud-Atomic-23-20160607.x86_64-ap-southeast-2-HVM-standard-0
>>> (ami-0f69406c)
>>>
>>> 2. How have you set up the Services for those pods?
>>> created cluster based on
>>> http://www.projectatomic.io/docs/gettingstarted/
>>>
>>> Its simple ngingx deployment and created service using
>>>
>>> kubectl expose deployment my-nginx --port=80
>>>
>>> web server is accessible only within the cluster not from outside the 
>>> cluster to external network.
>>>
>>>
>>> On Thu, Jul 7, 2016 at 1:16 AM, Josh Berkus <jber...@redhat.com> wrote:
>>>
>>>> On 06/21/2016 01:37 PM, Rafiqul Islam wrote:
>>>> > Dear Team
>>>> > Thanks for this wonderful project. I have created a kuberntes cluster
>>>> > based on fedora atomic image
>>>> > (http://www.projectatomic.io/docs/gettingstarted/) . We can run
>>>> > applications running on pods from inside the network. However we are
>>>> not
>>>> > able access these application from external network. There may be a
>>>> load
>>>> > balancer concept to expose services to external network. Could you
>>>> > please help enlighten me on the load balancer to expose services to
>>>> > external network?
>>>>
>>>> Sorry for hold on this; we had a glut of spam and I didn't notice your
>>>> question waiting in moderation.
>>>>
>>>> Questions:
>>>>
>>>> 1. What distro of Atomic are you using?
>>>>
>>>> 2. How have you set up the Services for those pods?
>>>>
>>>> --
>>>> --
>>>> Josh Berkus
>>>> Project Atomic
>>>> Red Hat OSAS
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Rafiqul Islam* | Technology, Ops, and Infrastructure Lead
>>>
>>> *M*: +8801709651000
>>>
>>> *Skype*: islamraofu | *E*: rafi...@telenordigital.com
>>>
>>
>>
>
>
> --
>
> *Rafiqul Islam* | Technology, Ops, and Infrastructure Lead
>
> *M*: +8801709651000
>
> *Skype*: islamraofu | *E*: rafi...@telenordigital.com
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

does your minimal micro-yuminst assume "--setopt tsflags=nodocs"


On Tue, Jul 12, 2016 at 9:30 PM, Colin Walters  wrote:

> ...3 weeks later:
>
> On Tue, Jun 21, 2016, at 04:59 PM, Colin Walters wrote:
>
>
> It does seem viable to create a `centosmin` image that in some cases uses
> different package builds (e.g. ensuring rpm doesn't pullrelatively close in
> being min-coreutils + bash + yum.  Some postprocessing on the depchain such
> as deleting `.py{,c}` files etc. would help.
>
>
> I realized recently that the work we'd been doing in libhif[1] which is a
> C library for package management
> would allow us to have a minimal "yum -y install" reimplementation[2]
> using libhif, which would be
> good for such a minimal image as then we could drop Python for example.
>
> I spent some of last Friday's plane flight back from the Summit working on
> it:
> https://github.com/cgwalters/centos-dockerbase-minimal
>
> You can try it with:
>
> docker pull docker.io/cgwalters/centosmin
>
> I've only done some basic smoketesting on it.  Compressed it's 28MB,
> uncompressed 77MB right now.
> I estimate it wouldn't be too hard to get within 60MB, but past that
> things get a bit trickier as we
> need to investigate single-binary coreutils, a minimal libcurl build, and
> in general trimming
> out a lot of the duplication in our C libraries like only having openssl
> and not nss, trimming down
> glib2 etc.
>
> I'm curious what people think.  The tradeoff is we now have two base
> images (per distribution).
>
> [1] https://github.com/rpm-software-management/libhif
> [2] https://gitlab.com/cgwalters/micro-yuminst
>

Re: [atomic-devel] Exposing Pods to external network

[Muayyad AlSadi]

I guess you can specify type=NodePort

or use specify externalIPs  with type=ClusterIP (which is the default type)

kubectl describe service NAME


http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_servicespec
http://kubernetes.io/docs/user-guide/services/
http://kubernetes.io/docs/user-guide/load-balancer/
http://kubernetes.io/docs/user-guide/services/operations/

On Mon, Jul 11, 2016 at 7:28 AM, Rafiqul Islam 
wrote:

> Thanks for the reply.
>
> Questions:
>
> 1. What distro of Atomic are you using?
> Fedora-Cloud-Atomic-23-20160607.x86_64-ap-southeast-2-HVM-standard-0
> (ami-0f69406c)
>
> 2. How have you set up the Services for those pods?
> created cluster based on http://www.projectatomic.io/docs/gettingstarted/
>
> Its simple ngingx deployment and created service using
>
> kubectl expose deployment my-nginx --port=80
>
> web server is accessible only within the cluster not from outside the cluster 
> to external network.
>
>
> On Thu, Jul 7, 2016 at 1:16 AM, Josh Berkus  wrote:
>
>> On 06/21/2016 01:37 PM, Rafiqul Islam wrote:
>> > Dear Team
>> > Thanks for this wonderful project. I have created a kuberntes cluster
>> > based on fedora atomic image
>> > (http://www.projectatomic.io/docs/gettingstarted/) . We can run
>> > applications running on pods from inside the network. However we are not
>> > able access these application from external network. There may be a load
>> > balancer concept to expose services to external network. Could you
>> > please help enlighten me on the load balancer to expose services to
>> > external network?
>>
>> Sorry for hold on this; we had a glut of spam and I didn't notice your
>> question waiting in moderation.
>>
>> Questions:
>>
>> 1. What distro of Atomic are you using?
>>
>> 2. How have you set up the Services for those pods?
>>
>> --
>> --
>> Josh Berkus
>> Project Atomic
>> Red Hat OSAS
>>
>
>
>
> --
>
> *Rafiqul Islam* | Technology, Ops, and Infrastructure Lead
>
> *M*: +8801709651000
>
> *Skype*: islamraofu | *E*: rafi...@telenordigital.com
>

Re: [atomic-devel] Where do I file bugs against Atomic Host?

[Muayyad AlSadi]

Maybe if it has hithub, then in github

On Fri, Jun 24, 2016, 9:37 PM Tim St. Clair  wrote:

> I typically file under one and clone for other product.
>
> On Fri, Jun 24, 2016 at 1:14 PM, Josh Berkus  wrote:
> > Folks,
> >
> > So, where do I file bugs against AH which I believe to be generic to AH
> > and not specific to Fedora/Redhat/CentOS?  There doesn't seem to be a
> place.
> >
> > --
> > --
> > Josh Berkus
> > Project Atomic
> > Red Hat OSAS
> >
>
>
>
> --
> Cheers,
> Timothy St. Clair
> tstcl...@redhat.com
>
>

Re: [atomic-devel] Atomic ISO has bad default IPtables

[Muayyad AlSadi]

I use docker-glue (which can easily be made as a privileged container with
host networking / "nsenter --net")
that watch specific labels on containers to adjust haproxy/ipvsadm

https://github.com/muayyad-alsadi/docker-glue

Re: [atomic-devel] can fedora atomic 23 be upgraded to 24

[Muayyad AlSadi]

Thank you

On Wed, Jun 22, 2016, 6:49 PM Jonathan Lebon <jle...@redhat.com> wrote:

> - Original Message -
> > On 06/22/2016 11:36 AM, Muayyad AlSadi wrote:
> > > What about developer mode in grub menu?
> >
> > The grub entry won't be added as part of a rebase.
>
> Right, if you don't currently have a grub entry, rebasing
> will not make one appear.
>
> However, the grub entry should be "refreshed" if it was
> previously there. If that was the case, then this is a bug
> indeed.
>

Re: [atomic-devel] can fedora atomic 23 be upgraded to 24

[Muayyad AlSadi]

What about developer mode in grub menu?

On Wed, Jun 22, 2016, 6:09 PM Colin Walters <walt...@verbum.org> wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=1309075
>
> On Wed, Jun 22, 2016, at 10:56 AM, Micah Abbott wrote:
> > On 06/22/2016 09:34 AM, Muayyad AlSadi wrote:
> > > now, it gave me
> > >
> > > error: fsetxattr: Invalid argument
> > >
> > > I'll try "setenforce 0" and and see
> >
> > I saw the same.
> >
> > The following journal entries look relevant:
>
> This is https://bugzilla.redhat.com/show_bug.cgi?id=1309075
>

Re: [atomic-devel] can fedora atomic 23 be upgraded to 24

[Muayyad AlSadi]

it worked with "setenforce 0", for some reason I can't see developer mode
in grub menu

On Wed, Jun 22, 2016 at 4:34 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> now, it gave me
>
> error: fsetxattr: Invalid argument
>
> I'll try "setenforce 0" and and see
>

Re: [atomic-devel] can fedora atomic 23 be upgraded to 24

[Muayyad AlSadi]

now, it gave me

error: fsetxattr: Invalid argument

I'll try "setenforce 0" and and see

[atomic-devel] can fedora atomic 23 be upgraded to 24

[Muayyad AlSadi]

hi,

is there a command to upgrade to fedora atomic 24?

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

for those, they can strip locales (see david link)
how much would they save?



On Tue, Jun 21, 2016 at 4:11 AM, Derek Carr <dec...@redhat.com> wrote:

> Why does 1 not matter?  If a cluster orchestrator charges your container
> for its image size, it would matter.  There are some Kubernetes users in
> the community that have that goal and want to charge local disk usage to
> the pod (including shared image layers).  Admittedly, there are other users
> that do not want to do that, but it does mean the on disk format matters
> for some folks.
>
> On Monday, June 20, 2016, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> I gave up shrinking locales because they compress will
>>
>> There are two use cases for small images
>> 1. The on disk format, which is shared between multiple containers via
>> layers
>>
>> 2. When export tarball and pass it.
>>
>> For 1. Fat does not matter and for 2 it also does not matter because
>> ~100mb becomes 2mb.
>>
>> On Tue, Jun 21, 2016, 3:43 AM David O. <de...@oszi.one> wrote:
>>
>>> A little self-plug: Here's how I do it:
>>> https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh
>>> It's designed to run in a container of the same OS (F23 can build F24)
>>> so it can be built anywhere...
>>>
>>> Anyway, apart from systemd and locales I'm in favor of fat base images
>>> when an entire OS is needed. Because in the end not only it saves storage
>>> and bandwidth but also memory (same page cache).
>>> What we should focus on is avoiding fracturization (everything built on
>>> different base images) and educating people that smaller is not always
>>> better.
>>> So I don't think it's worth the effort to remove even dnf from the base
>>> images when it would/should include python3 either way.
>>>
>>> We could also go down the rabbit hole and create a tree of base images
>>> starting with the bare minimum.
>>> Is this also in the realm of the "layered images" project?
>>>
>>> Just my two cents.
>>> And for static binaries and unikernels there is no need for an OS anyway.
>>>
>>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

I gave up shrinking locales because they compress will

There are two use cases for small images
1. The on disk format, which is shared between multiple containers via
layers

2. When export tarball and pass it.

For 1. Fat does not matter and for 2 it also does not matter because ~100mb
becomes 2mb.

On Tue, Jun 21, 2016, 3:43 AM David O.  wrote:

> A little self-plug: Here's how I do it:
> https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh
> It's designed to run in a container of the same OS (F23 can build F24) so
> it can be built anywhere...
>
> Anyway, apart from systemd and locales I'm in favor of fat base images
> when an entire OS is needed. Because in the end not only it saves storage
> and bandwidth but also memory (same page cache).
> What we should focus on is avoiding fracturization (everything built on
> different base images) and educating people that smaller is not always
> better.
> So I don't think it's worth the effort to remove even dnf from the base
> images when it would/should include python3 either way.
>
> We could also go down the rabbit hole and create a tree of base images
> starting with the bare minimum.
> Is this also in the realm of the "layered images" project?
>
> Just my two cents.
> And for static binaries and unikernels there is no need for an OS anyway.
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

given a fake-runtime,

yum --nogpgcheck --installroot=$OSROOT --releasever=23 --setopt
tsflags=nodocs install httpd

I got the following

[root@fedora osroot]# for i in . usr/lib/ usr/lib/locale/ usr/share/locale/
usr/share/i18n; do du -sm $i ; done
227.
109usr/lib/
109usr/lib/locale/
28usr/share/locale/
10usr/share/i18n

so most of the 227MB are locales and i18n

I noticed that httpd pulled systemd-libs because it depends on
libsystemd.so.0()(64bit)

I don't know why it needs systemd libs (if it's for notify, I don't need it
inside docker)



On Tue, Jun 21, 2016 at 1:17 AM, Muayyad AlSadi <als...@gmail.com> wrote:

> >localedef --prefix $OSROOT --list-archive  xargs localedef --prefix
> $OSROOT --delete-from-archive
>
> the line was
>
> localedef --prefix $OSROOT --list-archive  | grep -v en_US | xargs
> localedef --prefix $OSROOT --delete-from-archive
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

>localedef --prefix $OSROOT --list-archive  xargs localedef --prefix
$OSROOT --delete-from-archive

the line was

localedef --prefix $OSROOT --list-archive  | grep -v en_US | xargs
localedef --prefix $OSROOT --delete-from-archive

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

> I hacked up some quick Dockerfiles for this particular example (httpd)
and the end result is that alpine was still smaller - 8.652 MB vs. 232.8 MB

you can use this trick to strip ~100MB

localedef --prefix $OSROOT --list-archive  xargs localedef --prefix
$OSROOT --delete-from-archive
mv $OSROOT/usr/lib/locale/locale-archive
$OSROOT/usr/lib/locale/locale-archive.tmpl
chroot $OSROOT /usr/sbin/build-locale-archive

but if you measure the size of the compressed tarball, it's not much.

you can try use

rpm --root $OSROOT --dbpath /var/lib/rpm --initdb

then add a temporary yum line pointing to the repo

cat <> $OSROOT/etc/yum.repos.d/tmp.repo
[tmp$i]
name=tmp$i
$line
gpgcheck=0
EOF

then install your packages (you don't need to have much)

yum --nogpgcheck --installroot=$OSROOT --releasever=$release $yumsetopt
install -y $packages

if you install system-release using rpm you can eliminate "--nogpgcheck"
and "$OSROOT/etc/yum.repos.d/tmp.repo"

maybe you may want to make sure to install "filesystem" (with either
busybox or "bash grep tar coreutils findutils sed cpio cyrus-sasl gawk vi
passwd sudo")

add httpd to that and let's see

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

I was socked by the size of the following file

ls -lh /usr/lib/locale/locale-archive
-rw-r--r--. 1 root root 107M Jun  8 11:07 /usr/lib/locale/locale-archive

but I was socked more that even after stripping it the total compressed
image size did not change at all (because more of the content of that file
is redundant and compressible)

moral of the store: don't look to base image size as metric

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

alpine is something like busybox,
It does not use the true and tested gnu glibc, it uses musl instead.

It has its use case which is different than fedora.

Usage of Alpine in official docker images is also political decision
because they have hired its main developer.

The size of the base image is not really a big deal when we have layers.
It's good to have a small base image but no more than that.

I believe we should eliminate translation of command line tools. Eliminate
useless i18n/l10n files, time zones, ... in some stripped base images.

Yum/dnf can be told to skip docs.

Split packages and take only needed parts.

Re: [atomic-devel] Introducing bubblewrap

[Muayyad AlSadi]

why setuid? why not just do the non-privileged part, then fire a dbus event
to some root service to do the privileged part of adding network config.
(and uses policy kit to validate the request).

or a root daemon that do the privileged part of network configuration.

so in summary
an unprivileged user tool that do every possible thing (except network
configuration)
it then fires a dbus event or a request to privileged daemon "please
configure network on this please"




On Fri, May 6, 2016 at 11:59 AM, Karanbir Singh 
wrote:

> On 06/05/16 00:52, Daniel J Walsh wrote:
> >
> >
> > On 05/05/2016 02:10 PM, Josh Berkus wrote:
> >>> Currently it is not part of a product and has not has a rigorous
> >>> review from a security team.  However, I believe our approach
> >>> is good, and if anyone wants a peer-reviewed setuid binary
> >>> for container features, it's worth considering bubblewrap!
> >> So I want to have a "Pop the Bubblewrap" contest which we discussed
> >> somewhere else.  That is, let's put out a contest for users to try to
> >> break through bubblewrap and report the technical issues.  We'll have
> >> some prizes.
> >>
> >> I'm happy to run the contest, and RH PR would help publicize it, but I'd
> >> need someone to manage it from the technical side.
> >>
> > I like the idea.  We have a security review going on right now with the
> > Security Response team.  Perhaps we should see where they are with the
> > review before we put out the challenge.
> >
> >
>
> happy to help promote this from the CentOS side of things as well
>
> regards,
>
> --
> Karanbir Singh
> +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
> GnuPG Key : http://www.karan.org/publickey.asc
>
>

Re: [atomic-devel] Reducing the footprint of the Fedora docker base image

[Muayyad AlSadi]

here are what I install

bash grep tar coreutils findutils rpm sed cpio cyrus-sasl file nc file-libs
gawk xz openssh-server vi setup filesystem man passwd sudo iproute
procps-ng iputils which net-tools psmisc

sometimes when I over optimize I replace systemd (by a fake runtime rpm
that claim to provides systemd and a like) with supervisord

Compress cracklib

gzip -9 $OSROOT/usr/share/cracklib/pw_dict.pwd

Minimize locale-archive

localedef --prefix $OSROOT --list-archive | egrep -v
$strip_locales_to_keep_re | xargs localedef --prefix $OSROOT
--delete-from-archive
mv $OSROOT/usr/lib/locale/locale-archive
$OSROOT/usr/lib/locale/locale-archive.tmpl
chroot $OSROOT /usr/sbin/build-locale-archive

find "$OSROOT/usr/share/i18n/locales/" -type f | egrep -v
$strip_locales_to_keep_re | xargs rm -rf
find "$OSROOT/usr/share/zoneinfo/" -type f | egrep -v $strip_tz_to_keep_re
| xargs rm -rf

regarding locals I want to keep things like date formats ..etc. but not
translation (I don't want french version of ls --help)

---

regarding a more stripped image image without dnf/yum, this would be useful
in case if we have pivot root support in Dockerfile

https://github.com/jlhawn/dockramp/issues/1

rpm --root $OSROOT --dbpath ...
yum --nogpgcheck --installroot=$OSROOT --releasever=$release $yumsetopt
install





On Thu, Feb 11, 2016 at 2:12 PM, Pavel Odvody  wrote:

> On Thu, 2016-02-11 at 05:08 -0500, Daniel Riek wrote:
> >
> >
> > On Thu, Feb 11, 2016 at 4:52 AM, Fabian Deutsch 
> > wrote:
> > > On Wed, Feb 10, 2016 at 11:13 PM, Josh Berkus 
> > > wrote:
> > > > On 02/10/2016 11:38 AM, Courtney Pacheco wrote:
> > > >>
> > > >> If possible, I'd like some feedback on the work I did. Comments
> > > and
> > > >> criticism are more than welcomed! I realize there may be some
> > > >> controversy in terms of what I chose to remove and what I chose
> > > to turn
> > > >> into weak dependencies, but I would like to hear your thoughts
> > > either way.
> > > >>
> > > >
> > > > First, thanks for doing this!  It really shows a lot.  I'd be
> > > really curious
> > > > as to what's in the remaining 144MB, given that Alpine and
> > > BusyBox can get
> > > > away with a userspace which is 25% of that size.
> > > >
> > > > As Dan points out, we can't necessarily dispose of DNF/Yum during
> > > the
> > > > standard container build (i.e. Dockerfile).  However ... could we
> > > remove
> > > > them afterwards?
> > >
> > > Maybe this can be handled by a tooling itself - add yum, install,
> > > cleanup afterwards.
> > >
> > >
> > >
> > With squashing that is doable, but it's ugly and fragile.
> >
>
> Agreed, until Docker itself supports squashing of layers we should stay
> away from that.
>
> > A better way would be to move them into "sidecar" images, that get
> > mounted during docker build and can be added at runtime. We can use
> > the atomic wrapper or kubernetes or atomic app to automate that. The
> > key todos I see here are :
> > * Get an out-of-tree dnf that brings it own dependencies and can be
> > mounted into a container during build (similar to the secrets patch).
>
> This might be satisfied with the standalone DNF bundles, the other
> option would be having a DNF version that can execute from an "empty"
> chroot (not nice due to all the corner cases with NSS/glibc and cURL).
>
> > * Figure out how to manage that across multiple versions of base
> > images.
> > * Enable mounting containers as volumes (unless I am mistaken, right
> > now we can only mount host directories as volumes? Might be wrong)
>
> Yes, but there's a nice loophole! If we mount hosts / we can use
> /proc/{PID}/root to get to the root of particular container, from my
> Fedora 22 host:
>
> $ docker run -tid ubuntu:latest bash
> a19fdc5ab50e3507d99cf16b4367e23a9f6b932655bbf531384e403026399c5c
> $ docker inspect --format "{{ .State.Pid }}"
> a19fdc5ab50e3507d99cf16b4367e23a9f6b932655bbf531384e403026399c5c
> 30328
> $ cat /proc/30328/root/etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
>
> This way we could run the service SPC container like:
>
> $ docker run --privileged -v /:/host fedora:23 cat
> /host/proc/30328/root/etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=14.04
> DISTRIB_CODENAME=trusty
> DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
>
> TLDR version: I just used Fedora 23 container to inspect an Ubuntu
> 14.04 container on my Fedora 22 host.
>
> > * Create the tooling and metadata to make it work in practice.
> >
> > I think there has been some work along those lines, it would be great
> > to drive it forward.
>
> In the above example, if we exchange Ubuntu container for another
> Fedora container we could do:
>
> $ docker run --name ServiceContainer --privileged -v /:/host fedora:23
> dnf update --installroot /host/proc//root/
>
> And it will work even if the target container doesn't have 

Re: [atomic-devel] Concerns about pushing Docker 1.10 into Fedora23

[Muayyad AlSadi]

> Well we probably need you guys playing with this, if there is a problem
so we can figure out how to fix it.

Drop me an email when it's pushed to rawhide.

On Wed, Feb 10, 2016, 4:12 PM Daniel J Walsh <dwa...@redhat.com> wrote:

> Well we probably need you guys playing with this, if there is a problem so
> we can figure out how to fix it.
>
>
> On 02/10/2016 03:22 AM, Muayyad AlSadi wrote:
>
> my concern is the built in DNS in new docker 1.10 and how to disable it to
> use the one provided by freeipa and dnsmasq backed by consul or skydns
>
>
>
> On Tue, Feb 9, 2016 at 6:04 PM, Jason Brooks <jbro...@redhat.com> wrote:
>
>>
>>
>> - Original Message -
>> > From: "Josh Berkus" <jber...@redhat.com>
>> > To: atomic-devel@projectatomic.io
>> > Sent: Tuesday, February 9, 2016 12:14:01 AM
>> > Subject: [atomic-devel] Concerns about pushing Docker 1.10 into Fedora23
>> >
>> > Folks,
>> >
>> > We were discussing the changes in Docker 1.10 at DevConf and became very
>> > concerned about the consequences of pushing it into Fedora23.  I don't
>> think
>> > that users will be prepared for the upgrade process for existing images.
>> > Basically, I can see two things happening to create some really unhappy
>> > users: (1) most of them ignore the update notice and then have a long
>> outage
>> > when they restart Docker, or (2) some of them run the migrator, and for
>> > users with dozens of images it makes their system unresponsive until
>> it's
>> > done.   There's also a bunch of API changes, which *supposedly* don't
>> break
>> > backwards compatibility, but has anyone tested for this?
>> >
>> > Is it worth considering holding 1.10 back until Fedora24?
>>
>> F24 is set to release on June 7, docker makes a major release each
>> three months or so, and 1.9 is already three months old...
>>
>> I don't think it's possible to fully shield users from the fast dev
>> pace of docker while keeping fedora reasonably up-to-date.
>>
>> Docker just moves fast, we should kick our testing into a higher
>> gear to keep up.
>>
>> Jason
>>
>>
>> >
>> > --
>> > Josh Berkus
>> > Project Atomic
>> > Red Hat
>> >
>> >
>>
>>
>
>

Re: [atomic-devel] dockerlite the fedora way

[Muayyad AlSadi]

Antonio gave it to me

https://github.com/nalind/graphc

On Mon, Jan 4, 2016, 5:51 PM Daniel J Walsh <dwa...@redhat.com> wrote:

> Nalin has been working on an update to this, but I was unable to find his
> github.
>
> Nalin?
>
>
> On 01/02/2016 07:54 AM, Muayyad AlSadi wrote:
>
> >> Yes critical to this is to get the graphdriver (COW File Systems) out
> as a separate package.  graphc so to speak.  We  are working on this.
>
> > is there a link for graphc?
>
> I guess I found it
>
> https://github.com/willmtemple/graphc
>
> On Sat, Jan 2, 2016 at 2:36 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> sorry,
>>
>> > Yes critical to this is to get the graphdriver (COW File Systems) out
>> as a separate package.  graphc so to speak.  We  are working on this.
>>
>> is there a link for graphc?
>>
>> and what does containerd add to the blend?
>>
>> https://containerd.tools/
>>
>>
>>
>>
>> On Sat, Jan 2, 2016 at 2:35 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>>
>>> > Yes critical to this is to get the graphdriver (COW File Systems) out
>>> as a separate package.  graphc so to speak.  We  are working on this.
>>>
>>> is there a link for graphc?
>>> and what does
>>>
>>>
>>>
>>> On Mon, Nov 2, 2015 at 3:49 PM, Pavel Odvody <podv...@redhat.com> wrote:
>>>
>>>> On Mon, 2015-11-02 at 13:43 +0200, Muayyad AlSadi wrote:
>>>> > > systemd-importd since v221
>>>> >
>>>> > awesome! is this in F23?
>>>> >
>>>>
>>>> Yes, Fedora 23 has v222. Note that `machinectl` is the correct name for
>>>> the command:
>>>>
>>>>   $ machinectl pull-dkr --dkr-index-url=http://index.docker.io
>>>> --verify=no library/fedora:22 fedora22
>>>>   ... snip ...
>>>>   $ systemd-nspawn -M fedora22
>>>>   Spawning container fedora22 on /var/lib/machines/fedora22.
>>>>   Press ^] three times within 1s to kill container.
>>>>
>>>> >
>>>> > On Mon, Nov 2, 2015 at 1:05 PM, Pavel Odvody <podv...@redhat.com>
>>>> > wrote:
>>>> > > On Fri, 2015-10-30 at 22:58 +0200, Muayyad AlSadi wrote:
>>>> > > > Hi,
>>>> > > >
>>>> > > > dockerlite is way to provide minimal docker features using
>>>> > > scripts on
>>>> > > > btrfs and lxc
>>>> > > >
>>>> > > > https://github.com/docker/dockerlite
>>>> > > >
>>>> > > > maybe it was aimed to demonstrate how simple docker can be
>>>> > > >  implemented.
>>>> > > > but I like that the idea of having containers independent of the
>>>> > > > daemon
>>>> > > > (ie. we can run non-root containers and containers do not die
>>>> > > when
>>>> > > > the daemon restarted)
>>>> > > >
>>>> > > > I like to see such project that uses
>>>> > > >
>>>> > > > 1. device mapper instead of btrfs
>>>> > > > 2. use systemd-nspawn instead of lxc
>>>> > > > 3. use systemd's @ and dbus
>>>> > > >
>>>> > > > for example docker events api can be implemented as wrapper of
>>>> > > dbus
>>>> > > >
>>>> > > > docker run -d foo
>>>> > > >
>>>> > > > will redirect to
>>>> > > >
>>>> > > > echo "whatever=whatever" > /etc/sysconfig/dockerlite/123.rc
>>>> > > > systemctl start dockerlite@123.service
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > >
>>>> > > Hi,
>>>> > >
>>>> > > systemd-importd since v221 can pull Docker V2 images and use them
>>>> > > for
>>>> > > launching nspawn containers. Since nspawn uses btrfs volumes by
>>>> > > default, the inbound layers are automatically  converted into btrfs
>>>> > > sub
>>>> > > -volumes (fun fact: they are received in reverse order :)):
>>>> > >
>>>> > >   systemd-pull --dkr-index-url=http://index.docker.io --verify=no
>>>> > > dkr library/fedora:22 fedora-22
>>>> > >   systemd-nspawn -M fedora-22
>>>> > >
>>>> > > Since this is V2-aware, you can also pull by image digest:
>>>> > >
>>>> > >   systemd-pull --dkr-index-url=https://index.docker.io --verify=no
>>>> > > dkr
>>>> > > library/fedora@sha256:3bc3c17b7fb900f8a35a22c36a05840d0b3a07896c426
>>>> > > 8e989558ef68279ecc2 fedora-20
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Pavel Odvody <podv...@redhat.com>
>>>> > > Software Engineer - EMEA ENG Developer Experience
>>>> > > 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
>>>> > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
>>>> > >
>>>> > >
>>>> > >
>>>>
>>>> --
>>>> Pavel Odvody <podv...@redhat.com>
>>>> Software Engineer - EMEA ENG Developer Experience
>>>> 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
>>>> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
>>>>
>>>>
>>>>
>>>
>>
>
>

Re: [atomic-devel] dockerlite the fedora way

[Muayyad AlSadi]

>> Yes critical to this is to get the graphdriver (COW File Systems) out as
a separate package.  graphc so to speak.  We  are working on this.

> is there a link for graphc?

I guess I found it

https://github.com/willmtemple/graphc

On Sat, Jan 2, 2016 at 2:36 PM, Muayyad AlSadi <als...@gmail.com> wrote:

> sorry,
>
> > Yes critical to this is to get the graphdriver (COW File Systems) out as
> a separate package.  graphc so to speak.  We  are working on this.
>
> is there a link for graphc?
>
> and what does containerd add to the blend?
>
> https://containerd.tools/
>
>
>
>
> On Sat, Jan 2, 2016 at 2:35 PM, Muayyad AlSadi <als...@gmail.com> wrote:
>
>> > Yes critical to this is to get the graphdriver (COW File Systems) out
>> as a separate package.  graphc so to speak.  We  are working on this.
>>
>> is there a link for graphc?
>> and what does
>>
>>
>>
>> On Mon, Nov 2, 2015 at 3:49 PM, Pavel Odvody <podv...@redhat.com> wrote:
>>
>>> On Mon, 2015-11-02 at 13:43 +0200, Muayyad AlSadi wrote:
>>> > > systemd-importd since v221
>>> >
>>> > awesome! is this in F23?
>>> >
>>>
>>> Yes, Fedora 23 has v222. Note that `machinectl` is the correct name for
>>> the command:
>>>
>>>   $ machinectl pull-dkr --dkr-index-url=http://index.docker.io
>>> --verify=no library/fedora:22 fedora22
>>>   ... snip ...
>>>   $ systemd-nspawn -M fedora22
>>>   Spawning container fedora22 on /var/lib/machines/fedora22.
>>>   Press ^] three times within 1s to kill container.
>>>
>>> >
>>> > On Mon, Nov 2, 2015 at 1:05 PM, Pavel Odvody <podv...@redhat.com>
>>> > wrote:
>>> > > On Fri, 2015-10-30 at 22:58 +0200, Muayyad AlSadi wrote:
>>> > > > Hi,
>>> > > >
>>> > > > dockerlite is way to provide minimal docker features using
>>> > > scripts on
>>> > > > btrfs and lxc
>>> > > >
>>> > > > https://github.com/docker/dockerlite
>>> > > >
>>> > > > maybe it was aimed to demonstrate how simple docker can be
>>> > > >  implemented.
>>> > > > but I like that the idea of having containers independent of the
>>> > > > daemon
>>> > > > (ie. we can run non-root containers and containers do not die
>>> > > when
>>> > > > the daemon restarted)
>>> > > >
>>> > > > I like to see such project that uses
>>> > > >
>>> > > > 1. device mapper instead of btrfs
>>> > > > 2. use systemd-nspawn instead of lxc
>>> > > > 3. use systemd's @ and dbus
>>> > > >
>>> > > > for example docker events api can be implemented as wrapper of
>>> > > dbus
>>> > > >
>>> > > > docker run -d foo
>>> > > >
>>> > > > will redirect to
>>> > > >
>>> > > > echo "whatever=whatever" > /etc/sysconfig/dockerlite/123.rc
>>> > > > systemctl start dockerlite@123.service
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > > Hi,
>>> > >
>>> > > systemd-importd since v221 can pull Docker V2 images and use them
>>> > > for
>>> > > launching nspawn containers. Since nspawn uses btrfs volumes by
>>> > > default, the inbound layers are automatically  converted into btrfs
>>> > > sub
>>> > > -volumes (fun fact: they are received in reverse order :)):
>>> > >
>>> > >   systemd-pull --dkr-index-url=http://index.docker.io --verify=no
>>> > > dkr library/fedora:22 fedora-22
>>> > >   systemd-nspawn -M fedora-22
>>> > >
>>> > > Since this is V2-aware, you can also pull by image digest:
>>> > >
>>> > >   systemd-pull --dkr-index-url=https://index.docker.io --verify=no
>>> > > dkr
>>> > > library/fedora@sha256:3bc3c17b7fb900f8a35a22c36a05840d0b3a07896c426
>>> > > 8e989558ef68279ecc2 fedora-20
>>> > >
>>> > >
>>> > > --
>>> > > Pavel Odvody <podv...@redhat.com>
>>> > > Software Engineer - EMEA ENG Developer Experience
>>> > > 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
>>> > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
>>> > >
>>> > >
>>> > >
>>>
>>> --
>>> Pavel Odvody <podv...@redhat.com>
>>> Software Engineer - EMEA ENG Developer Experience
>>> 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
>>> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
>>>
>>>
>>>
>>
>

Re: [atomic-devel] dockerlite the fedora way

[Muayyad AlSadi]

> Yes critical to this is to get the graphdriver (COW File Systems) out as
a separate package.  graphc so to speak.  We  are working on this.

is there a link for graphc?
and what does



On Mon, Nov 2, 2015 at 3:49 PM, Pavel Odvody <podv...@redhat.com> wrote:

> On Mon, 2015-11-02 at 13:43 +0200, Muayyad AlSadi wrote:
> > > systemd-importd since v221
> >
> > awesome! is this in F23?
> >
>
> Yes, Fedora 23 has v222. Note that `machinectl` is the correct name for
> the command:
>
>   $ machinectl pull-dkr --dkr-index-url=http://index.docker.io
> --verify=no library/fedora:22 fedora22
>   ... snip ...
>   $ systemd-nspawn -M fedora22
>   Spawning container fedora22 on /var/lib/machines/fedora22.
>   Press ^] three times within 1s to kill container.
>
> >
> > On Mon, Nov 2, 2015 at 1:05 PM, Pavel Odvody <podv...@redhat.com>
> > wrote:
> > > On Fri, 2015-10-30 at 22:58 +0200, Muayyad AlSadi wrote:
> > > > Hi,
> > > >
> > > > dockerlite is way to provide minimal docker features using
> > > scripts on
> > > > btrfs and lxc
> > > >
> > > > https://github.com/docker/dockerlite
> > > >
> > > > maybe it was aimed to demonstrate how simple docker can be
> > > >  implemented.
> > > > but I like that the idea of having containers independent of the
> > > > daemon
> > > > (ie. we can run non-root containers and containers do not die
> > > when
> > > > the daemon restarted)
> > > >
> > > > I like to see such project that uses
> > > >
> > > > 1. device mapper instead of btrfs
> > > > 2. use systemd-nspawn instead of lxc
> > > > 3. use systemd's @ and dbus
> > > >
> > > > for example docker events api can be implemented as wrapper of
> > > dbus
> > > >
> > > > docker run -d foo
> > > >
> > > > will redirect to
> > > >
> > > > echo "whatever=whatever" > /etc/sysconfig/dockerlite/123.rc
> > > > systemctl start dockerlite@123.service
> > > >
> > > >
> > > >
> > >
> > > Hi,
> > >
> > > systemd-importd since v221 can pull Docker V2 images and use them
> > > for
> > > launching nspawn containers. Since nspawn uses btrfs volumes by
> > > default, the inbound layers are automatically  converted into btrfs
> > > sub
> > > -volumes (fun fact: they are received in reverse order :)):
> > >
> > >   systemd-pull --dkr-index-url=http://index.docker.io --verify=no
> > > dkr library/fedora:22 fedora-22
> > >   systemd-nspawn -M fedora-22
> > >
> > > Since this is V2-aware, you can also pull by image digest:
> > >
> > >   systemd-pull --dkr-index-url=https://index.docker.io --verify=no
> > > dkr
> > > library/fedora@sha256:3bc3c17b7fb900f8a35a22c36a05840d0b3a07896c426
> > > 8e989558ef68279ecc2 fedora-20
> > >
> > >
> > > --
> > > Pavel Odvody <podv...@redhat.com>
> > > Software Engineer - EMEA ENG Developer Experience
> > > 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
> > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
> > >
> > >
> > >
>
> --
> Pavel Odvody <podv...@redhat.com>
> Software Engineer - EMEA ENG Developer Experience
> 5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
>
>
>

Re: [atomic-devel] dockerlite the fedora way

[Muayyad AlSadi]

> Yes critical to this is to get the graphdriver (COW File Systems) out as
a separate package.  graphc so to speak.  We  are working on this.

awesome!

>  What would we need next to save a layered image?

from https://runc.io/ it says "runC does not create a daemon, so it
integrates well with systemd."
so then we need make use of systemd @ magic (or maybe systemd-machined)
and map dbus events into docker-like HTTP REST API
and we would have drop-in replacement

for example
$ docker run -d myrepo/myapp
123abcdef123

will just create some bookkeeping files then systemctl start mywrapper@
123abcdef123


===
I don't like the idea of having moving parts inside docker daemon, I
believe we should reach a point where it's sole job is to delegate the
container running to systemd
here is an example of docker daemon crashing and all running containers die
for a silly glitch in my 3G connection

https://github.com/docker/docker/issues/15328






On Sat, Oct 31, 2015 at 11:56 AM, Daniel J Walsh <dwa...@redhat.com> wrote:

> Yes critical to this is to get the graphdriver (COW File Systems) out as a
> separate package.  graphc so to speak.  We
> are working on this.
>
> Once you have graphc you can mount up an image in any of the backends that
> Docker supports, Devmapper, Btrfs,
> overlayfs and run a container on them.  What would we need next to save a
> layered image?
>
>
> On 10/30/2015 05:15 PM, Muayyad AlSadi wrote:
>
> > this using runc?
> ok let it be runc instead of lxc
>
> so can we have docker-like dockerlite with *devicemapper* and runc ?
>
> the idea would be to make use of docker way of saving space with layers
> ..etc. (running several containers from same image, saving space by layers
> ..etc.)
> and support the rich community of images and the ecosystem of build-tools
>
>
>
>
>
>
> On Fri, Oct 30, 2015 at 11:08 PM, Daniel J Walsh <dwa...@redhat.com>
> wrote:
>
>>
>>
>> On 10/30/2015 04:58 PM, Muayyad AlSadi wrote:
>> > Hi,
>> >
>> > dockerlite is way to provide minimal docker features using scripts on
>> > btrfs and lxc
>> >
>> > https://github.com/docker/dockerlite
>> >
>> > maybe it was aimed to demonstrate how simple docker can be  implemented.
>> > but I like that the idea of having containers independent of the daemon
>> > (ie. we can run non-root containers and containers do not die when the
>> > daemon restarted)
>> >
>> > I like to see such project that uses
>> >
>> > 1. device mapper instead of btrfs
>> > 2. use systemd-nspawn instead of lxc
>> > 3. use systemd's @ and dbus
>> >
>> > for example docker events api can be implemented as wrapper of dbus
>> >
>> > docker run -d foo
>> >
>> > will redirect to
>> >
>> > echo "whatever=whatever" > /etc/sysconfig/dockerlite/123.rc
>> > systemctl start dockerlite@123.service
>> >
>> >
>> >
>> This looks kind of dead, why not look at implementing something like
>> this using runc?
>>
>>
>
>

[atomic-devel] dockerlite the fedora way

[Muayyad AlSadi]

Hi,

dockerlite is way to provide minimal docker features using scripts on btrfs
and lxc

https://github.com/docker/dockerlite

maybe it was aimed to demonstrate how simple docker can be  implemented.
but I like that the idea of having containers independent of the daemon
(ie. we can run non-root containers and containers do not die when the
daemon restarted)

I like to see such project that uses

1. device mapper instead of btrfs
2. use systemd-nspawn instead of lxc
3. use systemd's @ and dbus

for example docker events api can be implemented as wrapper of dbus

docker run -d foo

will redirect to

echo "whatever=whatever" > /etc/sysconfig/dockerlite/123.rc
systemctl start dockerlite@123.service

Re: [atomic-devel] Proposal for default qcow2 image virtual size 10G instead of 6G

[Muayyad AlSadi]

You can do live expand of xfs, to take all the space type

xfs_growfs /

So you should do something like

qemu-img resize myimg.qcow2 +20G

then boot it then type

xfs_growfs /

Or use cloud init


On Fri, Sep 4, 2015, 8:04 PM Vivek Goyal <vgo...@redhat.com> wrote:

> Not sure what you are trying to say?
>
> Thanks
> Vivek
>
> On Fri, Sep 04, 2015 at 04:59:08PM +, Muayyad AlSadi wrote:
> > It's xfs so it will just expand.
> >
> > On Fri, Sep 4, 2015, 7:51 PM Vivek Goyal <vgo...@redhat.com> wrote:
> >
> > > Hi,
> > >
> > > Virtual size of qcow2 f22 atomic size is 6G. I am wondering if there is
> > > a reason behind such small size. Will 10G be a better default.
> > >
> > > Right now out of 6G, 3G is consumed by rootfs. We also setup thin pool
> > > for docker which will consume 40% of free space (or 2G minimum). Some
> > > people are finding that out of box, there is not enough space for thin
> > > pool and 3G free space gets exhausted pretty fast.
> > >
> > > Is it a good idea to bump up default virtual size to 10G?
> > >
> > > Thanks
> > > Vivek
> > >
> > >
>

[atomic-devel] atomic-reactor and building in a container

[Muayyad AlSadi]

quote from https://github.com/projectatomic/atomic-reactor

 Features: build inside a docker container (so your builds are separated
between each other)

I was consulting with upstream docker and found they have a milestone to
separate builder outside of docker, ie docker build at some point would
an external app would build an image and pass it to docker daemon to load
it or push it docker registry

they recently introduced CP api that allow docker client to copy files
between containers/host

https://docs.docker.com/reference/commandline/cp/

one of those builders is dockramp

https://github.com/jlhawn/dockramp

and there we are discussing how to do something similar to atomic-reactor,
but using extended Dockerfiles only

we are discussing a way to pivot/switch containers root in away similar to
rpm's spec-file, the docker file is a usual dockerfile that starts with a
build image (or stock image followed by yum install gcc golang ...)
then do the build then switch the root to a minimal/base image (without
compiler) that is sufficient to run it, with something like this

RUN make install SERVER_PREFIX=/dest/server CLIENT_PREFIX=/dest/client
RUN cp /bin/server-extra /dest/server/bin/
RUN cp /bin/server-replicator /dest/replicator/bin/
RUN cp /bin/client-extra /dest/client/bin/
SWITCH_ROOT busybox /dest/server
TAGGED_SWITCH_ROOT client busybox /dest/client
TAGGED_SWITCH_ROOT replicator busybox /dest/replicator

it would build 3 images: foobar, foobar-client, foobar-replicator