Re: goal: booting with an empty /etc

[Daniel Walsh]

On 12/11/23 09:55, Peter Boy wrote:



Am 11.12.2023 um 15:09 schrieb David Both :

What is the objective of achieving this "boot with empty /etc"? What
does it accomplish? What problem does it solve?

For me, from a sysadmin POV, the great advantage is the clear separation of 
sysadmin made configuration and distribution provided (default) configuration. 
It makes the life of a sysadmin much easier, easier backup and selective 
restore, easier hunting for the cause of issues in a local app configuration, 
easier recovery and easier rebuild of a system that has become completely 
unusable. And all this for an RPM-based system and has nothing to do with 
containers.

However, I would consider a simple and unmistakable structure, i.e. 2 separate 
directories with XFS or BTRFS file system, to be reasonable and not an overlay 
file system. This only makes the recovery in emergency mode and limited tool 
availability prone to errors.

I would like to go even further and also separate distribution default code and 
locally installed code in the /usr tree. OpenSuse has developed a good proposal 
for this some time ago.

The nice thing about the overlay solution is that individual commands 
would not need to be modified to understand the new configuration.

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[Daniel Walsh]

On 12/9/23 16:55, DJ Delorie wrote:

Zbigniew Jędrzejewski-Szmek  writes:

I'm not entirely sure if you're just doing Friday trolling or if
you're serious.

Serious.  I have many machines and VMs, and every time I do a Fedora
install, I have a list of your choices I have to revert because they
don't work for me.  It's tiring.


I fear this will end like the /tmp fiasco where one /tmp became many tmp
directories, and no consistent rule about which one to use.

/tmp is generally backed by RAM and does not survive a reboot.

Not on any of my machines.  I want tmp files around after a reboot so I
can figure out what caused the reboot.


This can be achieved without "empty /etc" as a goal.  For example, why
can't we use podman's overlay filesystem to mount /usr/etc under /etc so
that all the configuration appears in /etc but installed vs changed
files are kept segregatable?

(FTR, not "podman's". The filesystem is a kernel thing.)

If the goal was to just move everything wholesale, that'd be a

I meant, rpms install into the lower fs, and the user edits the upper
fs.  You can "revert" to "factory settings" by wiping just the upper fs.

You can expose the two layers elsewhere (like /usr/etc) if that helps
with the merging.


(Another problem is that this scheme only works "live". If you want
to look *into* an image from the outside, the overlay wouldn't be
assembled, so the tools need to know how to handle the config split
manually.)

If you get your way, /etc would be empty anyway ;-)


For example, /etc/services is a list of port:service mappings, and people
maybe used to edit that twenty years ago,

I still edit this one.

Great for you. So you can be the one person who uses the override
mechanism for this file.

That you assume I'm the only one is part of the problem.


Another common case is "empty" configuration files, i.e. templates
that show the default configuration.

I find these VERY helpful when trying to fix configuration issues on my
machines.

Right. I'm not saying that those should go away. Quite the opposite.

If you move them away from where I expect to find them, effectively
they've gone away.  Instead of having everything I need in the one spot,
I have to go hunting for it.  If history is right, everyone will choose
a different spot and finding info will become very difficult.  Even
*documenting* where to find this information will become difficult,
because everyone puts their docs in different places.

Please figure out a way to make upgrades more reliable without having to
retrain millions of Linux users or turn Fedora into Windows.  I'm not
sure I'm exaggerating here.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


ostree does something like this. Having a lower /usr/etc and a upper 
/var/etc mapped at /etc, would be interesting. although there would be 
no ability to merge, the upper overrides the lower.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Several questionable packages installed on fresh system

[Daniel Walsh]

On 7/10/23 05:00, Olivier Fourdan wrote:

Hi Vit

On Mon, Jul 10, 2023 at 10:38 AM Vít Ondruch  wrote:

Hi,

I have recently installed Fedora Rawhide via netinstall and there are
some questionable packages installed by default, such as:

cpp
libtomcrypt
libxcrypt-compat
exiv2

and I wonder what is the mechanism, which pulls these in? For example,
there is not much what would depend on cpp:

~~~
$ sudo dnf repoquery --whatdepends cpp


Instead of whatdepends use --whatrequire.

$ sudo dnf repoquery --whatrequires cpp

Depends seems to include `recommends` and `suggests`



Updating and loading repositories:
Repositories loaded.
NsCDE-0:2.2-2.fc38.x86_64
buildah-0:1.30.0-1.fc39.x86_64
calendar-0:1.37-7.20211220cvs.fc37.x86_64
gcc-0:13.1.1-4.fc39.x86_64
xrdb-0:1.2.1-5.fc38.x86_64
~~~


I can't see it in comps:


~~~
$ grep -R cpp
comps-f16.xml.in:  cppunit
comps-f16.xml.in:  cpphs
comps-f15.xml.in:  cppunit
comps-f15.xml.in:  cpphs
comps-f8.xml.in:  cppunit
comps-f11.xml.in:  cppunit
comps-f11.xml.in:  cpphs
comps-f18.xml.in:  cppunit
comps-f7.xml.in:  cppunit
comps-f12.xml.in:  cppunit
comps-f12.xml.in:  cpphs
comps-f9.xml.in:  cppunit
comps-f17.xml.in:  cppunit
comps-f17.xml.in:  cpphs
comps-f13.xml.in:  cppunit
comps-f13.xml.in:  cpphs
comps-f14.xml.in:  cppunit
comps-f14.xml.in:  cpphs
comps-f10.xml.in:  cppunit
grep:
.git/objects/pack/pack-8b71ed94572d14e6f4922239550f2e605ead175b.pack:
binární soubor odpovídá
grep:
.git/objects/pack/pack-e5b1b3c9ad6241515210e06736de0317714d0810.pack:
binární soubor odpovídá
comps-eln.xml.in.in:  cppunit-devel
comps-eln.xml.in.in:  mingw32-cpp
comps-eln.xml.in.in:  mingw64-cpp
comps-eln.xml.in.in:  ocaml-cppo
comps-eln.xml.in.in:  poppler-cpp
comps-eln.xml.in.in:  poppler-cpp-devel

~~~


I can't see it in kickstarts:


~~~
$ grep -R cpp
custom/fedora-livedvd-haskell.ks:cpphs

~~~


So what is the mechanism these are installed? Where I can report this?

Can't comment on all the packages you listed, but the C preprocessor
(CPP) is indeed required by xrdb (that's an option in xrdb, see "-cpp"
in man xrdb) and xrdb itself is required by GDM:
https://src.fedoraproject.org/rpms/gdm/blob/rawhide/f/gdm.spec#_80

GDM uses xrdb from its data/Init.in and data/Xsession.in:

https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/Xsession.in#L118-129
https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/Init.in#L31-34

Please note that these commands all use "xrdb -nocpp" so cpp is not
actually used there, but the package dependencies still pull it of
course.

HTH
Cheers
Olivier
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Issue with Rawhide docker image?

[Daniel Walsh]

On 6/7/23 13:31, Kevin Fenzi wrote:

On Wed, Jun 07, 2023 at 07:19:32PM +0200, Iñaki Ucar wrote:

On Wed, 7 Jun 2023 at 19:15, Kevin Fenzi  wrote:

On Tue, Jun 06, 2023 at 12:30:56PM -0500, Chris Adams wrote:

Once upon a time, Clement Verna  said:

Once https://github.com/docker-library/official-images/pull/14789 merges,
the rawhide image on the DockerHub should be fixed too :-)

So... if it takes a manual process (including opening a PR), does it
really make sense to put Rawhide images on Dockerhub?

Sadly, lots of people look there, but yeah... it's not great.

Yeah, basically, because $VISIBILITY. Anyway this looks like something
that could be easily automated via GH Actions.

Any automation there would probibly need buy-in from docker folks,
because if we filed a automated PR every day and a docker human had to
review/merge it, they might not think thats a good way to spend their
time.

kevin


If people would just use Podman they would not have this issue.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases

[Daniel Walsh]

On 2/8/23 09:51, Daniel P. Berrangé wrote:

On Wed, Feb 08, 2023 at 09:43:19AM -0500, Stephen Gallagher wrote:

On Wed, Feb 8, 2023 at 9:35 AM Daniel P. Berrangé  wrote:
...

Checked with the team and I'm told 32-bit containers on 64-bit arch
should not be impacted.

More generally podman can run containers of foreign architectures using
qemu-user emulation, albeit with an obvious speed penalty. Still this
has been useful for testing issues on non-x86_64 arches where hardware
access is hard to come by.

Hold up, this is a really useful tip buried in this thread. Is there a
good howto or example of how to do this? This deserves a Fedora
Magazine or CommBlog article!

AFAIR, assuming you have 'qemu-user-static-' RPM installed for the
arch you need (which registers the binfmt handlers at boot), there is
not much more to it than passing '--arch $NAME' to 'podman run'

e.g. on my current x86_64 F37 host I can do

$ podman run -it --arch s390x fedora:rawhide
[root@89b49bd5fefd /]# uname -a
Linux 89b49bd5fefd 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 
15:09:04 UTC 2022 s390x GNU/Linux
[root@89b49bd5fefd /]# uname -m
s390x

one caveat is that if you later run without --arch, I've seen it remember
pick the foreign arch container that's already downloaded, instead of
fetching the native arch container.

Also qemu-user emulation isn't perfect, so if you hit wierd inexplicable
behaviour, QEMU upstream will welcome bug reports...

With regards,
Daniel


Yes Podman picks the latest image of a particular name.  Many debates 
have happened on this, but this is the default.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)

[Daniel Walsh]

On 10/14/22 18:09, Colin Walters wrote:


On Thu, Oct 13, 2022, at 3:08 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable

I know there's a lot going on here, so I put together
https://github.com/cgwalters/dnfimage-config
as a demonstration system to show this all works today.  (Though there's a lot 
left to do)

To say this another way...I really, really wish I had a time machine to go back and 
announce *this* instead of doing Fedora Atomic Host way back in the day.  If when Docker 
had come out (before Kubernetes, before podman, before CoreOS) I wish I'd said "hey 
this container stuff is cool, why don't we make bootable host operating systems 
configurable via containers too").  Oh well, better late than never!

(And yes, we're not the first to this nowadays, but...first, this path gives a seamless 
upgrade for all the existing ostree-based systems out there, and second, you absolutely 
can continue to do "dnf install cowsay" or whatever client side on standalone 
systems like desktops and homelab servers, you aren't obligated to tie your an installed 
OS to external build infrastructure)





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


I just wanted to throw in my two cents on this, that I absolutely love 
the idea. We all wish we had Way Back machines.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Container-sig] About Fedora containers

[Daniel Walsh]

On 6/22/22 10:04, Daniel P. Berrangé wrote:

On Mon, Jun 20, 2022 at 08:21:48AM +0200, Lumír Balhar wrote:

Hello.

Because we had a lot of troubles with Fedora infra for container images (I
can provide more details, if you want), we have decided to move our
containers to https://quay.io/organization/fedora.

So are you saying that registry.fedoraproject.org is obsolete and
should not be used anymore ?

With regards,
Daniel


Can it be setup as a redirector to the quay.io site?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 - Errors/Warnings with `dnf update`

[Daniel Walsh]

On 3/31/22 02:35, Carmelo Sarta wrote:

Hello there!
I've never seen this error before
`error: Plugin selinux: hook fsm_file_prepare failed`
but I would try
`dnf reinstall container-selinux`
and maybe
`dnf reinstall podman`
There seems to be an error appening when people are installing 
container-selinux, that I have not pinned down.  It does not happen on 
my system.

Hope this helps

On Thu, Mar 31, 2022 at 4:27 AM Nathanael D. Noblet 
 wrote:


Hello,

  Just wondering if this is a bug and what to report against. I
upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update`
and saw some odd output. Not sure if its a bug with dnf or selinux or
the packages being installed. Let me know if its a known issue or if I
need to file a bug and where.

Running transaction
  Preparing        :
1/1
  Upgrading        : crun-1.4.4-1.fc36.x86_64
1/16
error: lsetfilecon: (/usr/bin/crun;62451078,
system_u:object_r:container_runtime_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package crun-1.4.4-1.fc36.x86_64
  Upgrading        : containers-common-4:1-53.fc36.noarch
2/16
error: unpacking of archive failed on file /usr/bin/crun;62451078:
cpio: (error 0x2)
error: crun-1.4.4-1.fc36.x86_64: install failed
error: lsetfilecon: (/var/lib/containers/sigstore,
system_u:object_r:container_var_lib_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package containers-common-4:1-53.fc36.noarch
  Upgrading        : conmon-2:2.1.0-2.fc36.x86_64
3/16
error: unpacking of archive failed on file
/var/lib/containers/sigstore: cpio: (error 0x2)
error: containers-common-4:1-53.fc36.noarch: install failed
error: lsetfilecon: (/usr/bin/conmon;62451078,
system_u:object_r:conmon_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package conmon-2:2.1.0-2.fc36.x86_64
  Upgrading        : podman-3:4.0.2-1.fc36.x86_64
4/16
error: unpacking of archive failed on file /usr/bin/conmon;62451078:
cpio: (error 0x2)
error: conmon-2:2.1.0-2.fc36.x86_64: install failed
error: lsetfilecon: (/usr/bin/podman;62451078,
system_u:object_r:container_runtime_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package podman-3:4.0.2-1.fc36.x86_64
  Upgrading        : runc-2:1.1.1-1.fc36.x86_64
5/16
error: unpacking of archive failed on file /usr/bin/podman;62451078:
cpio: (error 0x2)
error: podman-3:4.0.2-1.fc36.x86_64: install failed
error: lsetfilecon: (/usr/bin/runc;62451078,
system_u:object_r:container_runtime_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package runc-2:1.1.1-1.fc36.x86_64
  Upgrading        : swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64
6/16
error: unpacking of archive failed on file /usr/bin/runc;62451078:
cpio: (error 0x2)
error: runc-2:1.1.1-1.fc36.x86_64: install failed
error: lsetfilecon: (/usr/bin/swtpm;62451078,
system_u:object_r:swtpm_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package swtpm-0.7.2-
1.20220307git21c90c1.fc36.x86_64
  Upgrading        : snapd-2.54.4-1.fc36.x86_64
7/16
error: unpacking of archive failed on file /usr/bin/swtpm;62451078:
cpio: (error 0x2)
error: swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64: install failed
error: lsetfilecon: (/etc/sysconfig/snapd;62451078,
system_u:object_r:snappy_config_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package snapd-2.54.4-1.fc36.x86_64
  Running scriptlet: flatpak-1.12.7-1.fc36.x86_64
8/16
error: unpacking of archive failed on file
/etc/sysconfig/snapd;62451078: cpio: (error 0x2)
error: snapd-2.54.4-1.fc36.x86_64: install failed

  Upgrading        : flatpak-1.12.7-1.fc36.x86_64
8/16
error: lsetfilecon: (/usr/libexec/flatpak-system-helper;62451078,
system_u:object_r:flatpak_helper_exec_t:s0) Invalid argument
error: Plugin selinux: hook fsm_file_prepare failed

Error unpacking rpm package flatpak-1.12.7-1.fc36.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure



--

and thanks for all the fish,

Re: shadow-utils libsubid soname bump

[Daniel Walsh]

On 1/27/22 06:13, Iker Pedrosa wrote:

Hi,

On Wed, Jan 26, 2022 at 3:32 PM Matt Heon  wrote:

We're prepared to handle this already as part of the Podman v4.0
change proposed for F36 elsewhere on this list - bumping to the
new version will pick up support for the breaking changes in the
library, and as long as we trigger a Podman build shortly after
the libsuid update lands, we should be in good shape, so our only
ask would be to coordinate when the shadow-utils build is dropped
to make sure that happens. Unfortunately, I don't think we want to
push any Podman v4 builds into F36 until the feature is accepted -
is it acceptable to you to wait until that happens? A plan B would
be to backport relevant patches for the changes in libsuid to the
existing Podman release and cut a build based on that, but we're
prefer to avoid that if at all possible.


The update can wait until the change is accepted for F36. We'll need 
to coordinate to do the two builds, though. Can you please ping me 
when everything is ready on your side?


@Daniel Walsh <mailto:dwa...@redhat.com> : yes, the API provided by 
the shared library has changed its name.

Giuseppe can you handle this.



Thanks,
Matt Heon

On Wed, Jan 26, 2022 at 3:49 AM Iker Pedrosa 
wrote:

Hi,

I'm currently working in rebasing shadow-utils to the latest
version, 4.11.1, and it contains a soname bump for the subid
library. I've created the side tag "f36-build-side-49901" to
prepare the update.

dnf reports that the only package that contains a dependency
for this library is podman. @Matt Heon
<mailto:mh...@redhat.com>, as the maintainer of this package,
how do you want to proceed?

-- 


Iker Pedrosa

Software Engineer, Identity Management team

Red Hat <https://www.redhat.com>

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb <mailto:Basque+proverb>

<https://www.redhat.com>



--

Iker Pedrosa

Software Engineer, Identity Management team

Red Hat <https://www.redhat.com>

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb <mailto:Basque+proverb>

<https://www.redhat.com>

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: shadow-utils libsubid soname bump

[Daniel Walsh]

On 1/26/22 03:49, Iker Pedrosa wrote:

Hi,

I'm currently working in rebasing shadow-utils to the latest version, 
4.11.1, and it contains a soname bump for the subid library. I've 
created the side tag "f36-build-side-49901" to prepare the update.


dnf reports that the only package that contains a dependency for this 
library is podman. @Matt Heon , as the 
maintainer of this package, how do you want to proceed?


We are releasing a new Podman 4.* in the next couple of weeks, and can 
build off of it.  Is the Shared library calls changing?

--

Iker Pedrosa

Software Engineer, Identity Management team

Red Hat 

Txapela (gorria) buruan eta ibili munduan

(Red) hat on his head and walk the world

Basque proverb 




___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Podman 4.0 rc2 is available in updates-testing.

[Daniel Walsh]

We would love to have people play with this and test it out.

Note: this release has breaking changes to it's API, so it will not be 
released to f35. Only to F36, but users will be able to download and use 
it on F35, we will not push it to stable though.


https://github.com/containers/podman/releases/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Anyone interested in helping to convert the Ubuntu Discourse Docker setup to Fedora Podman?

[Daniel Walsh]

On 12/6/21 14:11, Philip Rhoades via devel wrote:

People,

I cloned this:

  https://github.com/discourse/discourse_docker

and did a "podman build" on the Dockerfile and it made it to step 39 
(of 59) before stopping with a complaint about a missing dir . .


It would be great to get a Fedora Podman Discourse container going (in 
a separate exercise some time ago I was able to get a development-only 
version going but I eventually gave up on the too-hard production 
version) - anyone interested in helping / advising?


Thanks,

Phil.

What was podman complaining about on stpe 39?  Could you attach the 
build log?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Current minimal base image for containers?

[Daniel Walsh]

On 7/11/21 12:14, Martin Langhoff wrote:

Hi Fedora Devel,

is there any current equivalent of Fedora atomic, or the super-compact
RHEL-7 minimal container images? IIRC those were _really_ small (ie:
~70MB) in size, had been installed with nodocs, etc.

Couldn't find a CoreOS _minimal container_ image either. Current
Fedora 34 minimal container image is 120MB.

regards,


martin


Take a look at ubi8-micro.  Not Fedora based but downstream of Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Banning bots from submitting automated koji builds

[Daniel Walsh]

On 6/25/21 16:13, Neal Gompa wrote:

On Fri, Jun 25, 2021 at 3:43 PM Daniel Walsh  wrote:

On 6/25/21 10:25, Neal Gompa wrote:

On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar
 wrote:

Hi list,


I own the rhcontainerbot account. Apologies it took so long to respond to this 
thread. A number of legitimate concerns have been raised about the bot, so let 
me address those below on behalf of the Containers team.


We have disabled all autobuilds for now.

The podman RC build landing in updates a month ago was a one-off and it has 
been discussed at: 
https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/

The fuse-overlayfs downgrade occurred unintendedly during the upstream branch 
rename from master to main. That has been fixed at: 
https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442
Disabling autobuilds during the branch rename phase would’ve evidently avoided 
this issue.


Going forward:

We will only manually build upstream release tags for Fedora releases. We  
would prefer to send RC tags to Fedora rawhide as that will trigger gating 
tests and allow us to test podman with FCOS and toolbox CIs, so please let us 
know if that would be a deal-breaker.


RCs and final releases are generally okay IMO even for stable
releases, as long as you're prepared to address feedback brought up in
bodhi updates. The problem here is nobody is paying attention to Bodhi
at all.


We may look at re-enabling the bot only for koji builds of upstream releases, 
while bodhi updates will still be manual. We’ll make sure to check for 
breakages / version downgrades before re-enablement. The bot has so far 
compared upstream tags, rpm installability, version number sanity, but 
evidently it has missed a lot of cases including git branch changes.

If we re-enable the bot, we will mention the human’s name and email for every 
changelog entry in every relevant package as well as regularly monitor the 
bot’s email. Please let us know if there are any concerns with this approach.

We will use openSUSE’s OBS for builds of the latest upstream commits for our 
users who need the latest packages. We would need this to check if the latest 
commits in podman work well with new kernel features and selinux.


Team members  will not add karma to containers’ packages, with the exception of 
our QE Engineer who owns our gating tests and is in charge of final testing of 
our builds.  Currently Ed Santiago (FAS: @santiago) owns that responsibility.


The important aspect isn't who is doing it, but that it's actually
*tested* to work. Very serious breakages have happened in the past,
and that's we want to avoid going forward.

And sometimes this breakage is caused by other parts of the system. For
example a kernel update caused breakage in Podman when it suddenly
enabled overlay mounts, which no one had tried.  We quickly fixed the
container-selinux package to handle it, and got the fixes in F33 and F34
before the kernel showed up.

If we remove Podman updates from Rawhide other then when we prepare for
release. Their will be errors that do not get caught early.

Forcing us to treat Rawhide like we do F34 makes Rawhide less
interesting to the container effort.


But none of you are paying attention to Rawhide anyway. As far as I
know, none of you actively run Rawhide, none of you test it, and
nobody is paying attention to when stuff is pushed into Rawhide. This
is the difference between what your team is doing and what I do when I
push snapshots into Rawhide.

If you're going to push stuff into Rawhide, *care* about it.



I ran rawhide for > 10 years so I know the joy and sometimes pain, but I 
will have the team focus more on it going forward.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Banning bots from submitting automated koji builds

[Daniel Walsh]

On 6/25/21 10:25, Neal Gompa wrote:

On Fri, Jun 25, 2021 at 10:15 AM Lokesh Mandvekar
 wrote:

Hi list,


I own the rhcontainerbot account. Apologies it took so long to respond to this 
thread. A number of legitimate concerns have been raised about the bot, so let 
me address those below on behalf of the Containers team.


We have disabled all autobuilds for now.

The podman RC build landing in updates a month ago was a one-off and it has 
been discussed at: 
https://lists.podman.io/archives/list/pod...@lists.podman.io/thread/WYNTH224D5MVBC2RFOG6RPIC52JZFKAB/

The fuse-overlayfs downgrade occurred unintendedly during the upstream branch 
rename from master to main. That has been fixed at: 
https://koji.fedoraproject.org/koji/buildinfo?buildID=1775442
Disabling autobuilds during the branch rename phase would’ve evidently avoided 
this issue.


Going forward:

We will only manually build upstream release tags for Fedora releases. We  
would prefer to send RC tags to Fedora rawhide as that will trigger gating 
tests and allow us to test podman with FCOS and toolbox CIs, so please let us 
know if that would be a deal-breaker.


RCs and final releases are generally okay IMO even for stable
releases, as long as you're prepared to address feedback brought up in
bodhi updates. The problem here is nobody is paying attention to Bodhi
at all.


We may look at re-enabling the bot only for koji builds of upstream releases, 
while bodhi updates will still be manual. We’ll make sure to check for 
breakages / version downgrades before re-enablement. The bot has so far 
compared upstream tags, rpm installability, version number sanity, but 
evidently it has missed a lot of cases including git branch changes.

If we re-enable the bot, we will mention the human’s name and email for every 
changelog entry in every relevant package as well as regularly monitor the 
bot’s email. Please let us know if there are any concerns with this approach.

We will use openSUSE’s OBS for builds of the latest upstream commits for our 
users who need the latest packages. We would need this to check if the latest 
commits in podman work well with new kernel features and selinux.


Team members  will not add karma to containers’ packages, with the exception of 
our QE Engineer who owns our gating tests and is in charge of final testing of 
our builds.  Currently Ed Santiago (FAS: @santiago) owns that responsibility.


The important aspect isn't who is doing it, but that it's actually
*tested* to work. Very serious breakages have happened in the past,
and that's we want to avoid going forward.


And sometimes this breakage is caused by other parts of the system. For 
example a kernel update caused breakage in Podman when it suddenly 
enabled overlay mounts, which no one had tried.  We quickly fixed the 
container-selinux package to handle it, and got the fixes in F33 and F34 
before the kernel showed up.


If we remove Podman updates from Rawhide other then when we prepare for 
release. Their will be errors that do not get caught early.


Forcing us to treat Rawhide like we do F34 makes Rawhide less 
interesting to the container effort.



We will also notify the containers’ communities that rawhide will no longer 
contain the latest builds as some of them are accustomed to using.


Having a COPR would be nice for this. With tools like Packit and such
able to continuously build in COPR for every PR and every commit, you
can provide a fairly nice experience here. I do this with rpmlint, for
example.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)

[Daniel Walsh]

On 6/9/21 15:53, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jun 09, 2021 at 10:29:50AM -0500, Justin Forbes wrote:

On Wed, Jun 9, 2021 at 10:19 AM David Duncan  wrote:

On Wed, Jun 9, 2021, 4:13 AM Zbigniew Jędrzejewski-Szmek  
wrote:

On Wed, Jun 09, 2021 at 06:52:40AM -, David Duncan wrote:

Bumping this for technical discussion. We are planning to put this in action if 
there are no technical objections.

Please wait until the FESCo has approved the Change.


I made that sound like an imperative. That was a mistake. I wanted to redirect 
the thread to technical review instead of program concerns.  Of course no 
actual implementation will be done without approval.


So, I suppose I should mention here for discussion what I put in the
FESCo ticket.  My main concern with this from a cloud image
standpoint, is cloud images are run on a number of hosts. Many of
those hosts are RHEL or CentOS based. As RHEL does not enable the
btrfs filesystem at all, and has no plans to that I am aware of, this
means that users on those hosts will no longer be able to mount their
images to debug issues or modify in any way.  Libguestfs for RHEL is
not a workaround at this point, because it doesn't support btrfs on
RHEL either.  It would also mean that these images could not be used
as container images in that environment.  Of course the images can
still be booted, and will work as expected as long as they are running
in a virtualized environment with their own kernel.  I am not sure how
important this is for people, but it needs to be considered.

Yeah, I think we have to accept that there won't be any kernel support
in RHEL in a timeframe that matters for Fedora, and the RHEL host will not be
able to mount the images natively. So the questions for me are:
1. I this a problem in practice? I.e. how often do people need to use Fedora
images for containers on RHEL hosts?
2. What workaround can we put in place? Something in EPEL or dkms module with
btrfs in a copr repo?

Zbyszek
Container images have nothing to do with this. Container images are 
stored as tar balls and are constructed on the underlying OS.  This is 
purely an issue with soemthing like libguestfs

___

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Daniel Walsh]

On 5/20/21 15:58, Colin Walters wrote:


On Thu, May 20, 2021, at 8:21 AM, Daniel P. Berrangé wrote:


Lets say the Fedora base image is refreshed with updated RPMs on a weekly
basis. Each application republishes their app containers on an arbitrarily
different schedule, maybe fortnightly, monthly, whatever. Thus out of
10 different apps deployed, you could easily find yourself shipping 10
different versions of the base image.

This of course is the big difference between flatpak and 
docker/podman/kubernetes as they work today.  flatpak dynamically links base 
images (by having apps go into `/app`).

I can't think of a hard reason that podman couldn't learn to dynamically link 
base images too with the same approach of having the app bits live in `/app`.  
Or honestly, in many cases we could just forcibly dynamically link layers, for 
most of the OpenShift platform we just have big statically linked Go binaries 
that don't overlay anything on the host (no package installs etc).

One could imagine something like this in a Containerfile:

```
FROM quay.io/fedora:rust as buildroot
COPY . /build
RUN cargo build --release

FROM DYNAMIC quay.io/fedora
COPY --from-buildroot /build/target/release/myapp /usr/bin/myapp
```

Where the `DYNAMIC` part here opts-in to dynamic linking like flatpak, and the 
overlayfs is dynamic instead of static.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Nice idea, but we will forget it as soon as the next crisis hits.  Could 
you open this issue in containers/storage or Podman, so we can continue 
to think about it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Daniel Walsh]

On 5/20/21 08:21, Daniel P. Berrangé wrote:

On Wed, May 19, 2021 at 04:37:55PM -0400, Daniel Walsh wrote:

The sad thing with these types of slimming is that it is horrible in
production use case.

I often describe layered images in the form of a wedding cake, where you
have a large base

and then smaller  mid section say with httpd or java engine and then a small
layer on top which has the actual application.

This gives applications the ability to share most of the content of the base
image and those who share the mid section ability to share.  This shrinks
the overall disk space and more importantly allows the kernel to realize
that the same glibc or jre is being used so it is not loaded into memory for
each application run.

I wonder how much of a difference it actually makes a difference in the
practice.

Lets say the Fedora base image is refreshed with updated RPMs on a weekly
basis. Each application republishes their app containers on an arbitrarily
different schedule, maybe fortnightly, monthly, whatever. Thus out of
10 different apps deployed, you could easily find yourself shipping 10
different versions of the base image. IOW we only get the space benefit
of sharing a large image, if a large number of apps are aligned with using
the same point in time version base image.


I usually look more towards ubi images, which update at a much slower rate.


If we assume that apps in general will NOT align on the same point in
time version of a base image, and the base image gets refreshed frequently
then a small base image feels more important.

If you can control all your apps such that they get built using the
exact same version of the base, then a large base would get the benefits
you describe. It is easier to achieve sharing with a slow refreshed
container - IOW perhaps it matter more for RHEL than for Fedora.

Yes


It feels like we probably can cope with both scenarios at the same
time though. The large base to maximize sharing doesn't actually
have to be the bottom most layer to get sharing. We just need a
large base /somewhere/ below the end user applications. It could
easily be the second layer.


Yes, but I wonder how many applications start with the default base images

and then install content.  From fedora, from alpine as opposed to `from 
fedora-httpd`



Lets say we have a "fedora" image that's tiny with the absolute bare
minimum - just package manager and things that needs. Then we could
have a "fedora-max" that inherits from this and throws in the kitchen
sink. Or you could have more targetted layers "fedora-python",
"fedora-java", etc. That way if you are deployed a bunch of python
apps you can derive from the large-ish "fedora-python" container
image and get maximum sharing of python stack, while we still offer
a very small base image for those who don't care about sharing and
just want to win on size.


Sure, and in some ways this is happening with fedora-minimal.

Hopefully in the future we will have new features in conainers/storage 
that will alleviate some of the problems I have described in previous 
emails, through the use of reflinks, pulling only changes in images, and 
other features like support for zstd images.


https://github.com/containers/storage/pull/795

https://github.com/containers/storage/pull/775



Regards,
Daniel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora CoreOS stable stream now rebased to Fedora 34

[Daniel Walsh]

On 5/20/21 02:54, Clement Verna wrote:



On Wed, 19 May 2021 at 13:55, Neal Gompa > wrote:


On Wed, May 19, 2021 at 2:45 AM Clement Verna
mailto:cve...@fedoraproject.org>> wrote:
>
>
>
> On Wed, 19 May 2021 at 06:50, Tomasz Torcz mailto:to...@pipebreaker.pl>> wrote:
>>
>> Dnia Tue, May 18, 2021 at 03:37:27PM -0400, Dusty Mabe napisał(a):
>> > Over the next two days we're rolling out the first Fedora 34
based
>> > Fedora CoreOS into the `stable` stream.
>> >
>> > - systemd-resolved is still enabled but not used yet [1]
>>
>>   This was Fedora 33 feature.
>>
>> > - Move to cgroup v2 by default [5].
>>
>>   This was Fedora 31 feature.
>>
>>   I was wondering: Fedora CoreOS actively undoes distribution-wide
>> changes (at least the two above, I remember lagging with
iptables-nft
>> around Fedora 32).  End user may confused, seeing the list of
changes
>> for the release X, but receiving only few of them with edition
CoreOS X.
>>
>>   Should such divergence be allowed?  Should Fedora CoreOS use
the same
>> version number while not containing all the changes from main
Fedora Linux?
>
>
> I think this is the fundamental difference here, Fedora CoreOS
does not have a version number. It has 3 streams, stable, testing
and next, these streams are based on a version of Fedora Linux but
that should just be a detail that most end users should not have
to care about.
> Another difference is that Fedora CoreOS has automatic updates
and if we want our users to trust these automatic updates we need
them to be rock solid. This leads to Fedora CoreOS being more
conservative on how changes are rolled out to users, taking the
example rolling out cgroups v2 in the Fedora 31 time frame would
have broken all users that are using Docker to run their
containers and this was not acceptable :-).
>
>  If some users are getting confused and get curious about why
there are these differences and learn more about how Fedora CoreOS
works, that's a good thing IMO :-)

No. This is a cop-out and a bad answer.

The reason this happened is
because Fedora CoreOS historically has not participated in the
development of Fedora Linux, including the Changes process, and
generally rolled back features instead of adapting with them during
the development cycle.


I don't think it is fair to say that FCOS is not participating in the 
Change process. FCOS is following closely the Change Proposals 
[0][1][2][3]. I agree that we could do a better job at submitting 
Change Proposals and that's something we should improve on.
One thing I have a hard time to understand tho, if what happens when a 
Change proposals breaks FCOS (like cgroups v2 for example) ? Should 
that just be rejected ? AFAIK not all changes are adopted by every 
Editions or Spins. What is in your opinion the correct way forward ?



It's not like making changes and breaking upgrades is acceptable in
Fedora Linux either. 



Breaking or non backward compatible changes are acceptable in Fedora 
Linux tho between major version bump. Again here the cgroups v2 is a 
good example, folks using Docker had to perform some manual steps to 
switch back to cgroups v1 to keep using their workflow working. This 
is fine when you have a major version bump but this does not happen in 
FCOS.
This might end up being a major problem with FCOS, if we are stuck with 
the defaults forever, and never able to take advantage of new technology.


It's just that the Fedora CoreOS WG has not
participated in the main development process and rolled back changes
instead of adapting to them, which has frustrated pretty much
everyone. The containers team in particular was extremely unhappy to
find out cgroup v1 was still used in FCOS. I was pretty cheesed off
when I discovered the sqlite rpmdb feature was rolled back in FCOS.


In general, I'm not pleased with how Fedora CoreOS does this.
Hopefully they will do better in the future.


[0] - https://github.com/coreos/fedora-coreos-tracker/issues/372 

[1] - https://github.com/coreos/fedora-coreos-tracker/issues/609 

[2] - https://github.com/coreos/fedora-coreos-tracker/issues/704 

[3] - https://github.com/coreos/fedora-coreos-tracker/issues/824 




-- 
真実はいつも一つ！/ Always, there's only one truth!

___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to
devel-le...@lists.fedoraproject.org

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Daniel Walsh]

On 5/19/21 04:34, Daniel P. Berrangé wrote:

On Wed, May 19, 2021 at 09:04:08AM +0200, Clement Verna wrote:

On Mon, 17 May 2021 at 16:40, Frank Ch. Eigler  wrote:


Daniel P. Berrangé  writes:


The container runtime in the host OS will have configured most mount
points before the container starts. It would be relatively uncommon
for processes inside the container image to need to mount additional
volumes later.

That's fair, but util-linux contains many other tools that may be useful
at runtine within a containerized tool (logger, flock, lsmem, rename,
taskset, whereis, others?).  Some those be moved somewhere else?

/usr/bin/* files from f33's util-linux:

cal chmem choom chrt col colcrt colrm column dmesg eject fallocate
fincore findmnt flock getopt hardlink hexdump i386 ionice ipcmk ipcrm
ipcs irqtop isosize kill last lastb linux32 linux64 logger login look
lsblk lscpu lsipc lsirq lslocks lslogins lsmem lsns mcookie mesg more
mount mountpoint namei nsenter prlimit raw rename renice rev script
scriptlive scriptreplay setarch setpriv setsid setterm su taskset ul
umount uname26 unshare utmpdump uuidgen uuidparse wall wdctl whereis
write x86_64


It is all about tradeoff between what **may** be useful and the size of the
base image. In the container base image space, size is very important (see
how successful is Alpine) and we have to make tradeoff in terms of what
tools are included by default in the image.

This is very true, but to be brutally honest when you look at these
differences below, I can't see any of the traditional distros ever
winning on size, because Alpine is a different order of magnitude
compared to them. If minimal size is the user's primary goal we're
not even in the same contest as Alpine.

That means we have to win on some other metric with the remaining
users, for whom size is not the primary driving factor.

We have to at least not look terrible size-wise compared to other
traditional distros, which means we need to be as close as practical
to Ubuntu / Debian (slim).

IMHO even then we would need the default "fedora" image to be the
minimal one, as that's what a casual user will compare, unless they
happen to know "fedora-minimal" exists.


To get an idea on how Fedora does compared to some other distros

REPOSITORY TAG  IMAGE ID
  CREATED   SIZE
registry.fedoraproject.org/fedora  rawhide  5e91f1acac7d  47
hours ago  187 MB
registry.fedoraproject.org/fedora-minimal  latest   438d4fec7485  5
days ago119 MB
docker.io/library/debian   latest   4a7a1f401734  7
days ago119 MB

FWIW, there's also debian:stable-slim at 72 MB


registry.opensuse.org/opensuse/leaplatest   1a798c6c690f  5
days ago108 MB
docker.io/library/ubuntu   latest   7e0aa2d69a15  3
weeks ago   75.1 MB

So we need to cull 45 MB / 36% of 'fedora-minimal' to reach this target,
or 112 MB / 60% of 'fedora'.

util-linux is a decent sized chunk of that, so makes sense to question
its need.


docker.io/library/alpine   latest   6dbb9cc54074  4
weeks ago   5.88 MB


Regards,
Daniel


The sad thing with these types of slimming is that it is horrible in 
production use case.


I often describe layered images in the form of a wedding cake, where you 
have a large base


and then smaller  mid section say with httpd or java engine and then a 
small layer on top which has the actual application.


This gives applications the ability to share most of the content of the 
base image and those who share the mid section ability to share.  This 
shrinks the overall disk space and more importantly allows the kernel to 
realize that the same glibc or jre is being used so it is not loaded 
into memory for each application run.


Now with the crazy developers driving the show, we end up with upside 
down wedding cakes, where basically everyone shares the absolute minimal 
base and then adds a ton of stuff on top.


In production, the apps end up sharing almost nothing, meaning they use 
much more disk, much more bandwidth when pulling images and much more 
memory in the OS since the kernel sees files that should be shared in 
memory as existing at different INODES.


We can work to help fix some of these by improving the pulling and 
storing of images, but for now shrinking the size of the image is 
counter productive for running containers in something like Kubernetes.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Podman and docker compose

[Daniel Walsh]

Brent Baude, not on this list responds:


Sergio,

Unfortunately Podman can not do network links.  It is something we cannot
support in the API nor docker-compose.  Perhaps the use of the link in
the yaml could be reworked not need it?


On 4/12/21 01:15, Sergio Belkin wrote:



El dom, 11 abr 2021 a las 23:11, Gwyn Ciesla via devel 
(>) escribió:


Have you tried podman-compose? It's in the Fedora repos.


-- 
Gwyn Ciesla

she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie



Sent from ProtonMail mobile



 Original Message 
On Apr 11, 2021, 7:34 PM, Sergio Belkin < seb...@gmail.com
> wrote:


Hi,
I'm playing around with podman and docker compose, so I've
read the post at
https://www.redhat.com/sysadmin/podman-docker-compose
.

The example with Gitea does not work, this the output:

sudo docker-compose up
descargas_elasticsearch_1 is up-to-date
Creating descargas_skydive-analyzer_1 ... error

ERROR: for descargas_skydive-analyzer_1  Cannot create
container for service skydive-analyzer: bad parameter: Link is
not supported

ERROR: for skydive-analyzer  Cannot create container for
service skydive-analyzer: bad parameter: Link is not supported
ERROR: Encountered errors while bringing up the project.

Am I doing something wrong?

This is the log:

abr 11 21:28:25 munster.belkin.home systemd[1]: Starting
Podman API Service...
abr 11 21:28:25 munster.belkin.home systemd[1]: Started Podman
API Service.
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info
msg="/usr/bin/podman filtering at
log level info"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Error
initializing configured
OCI runtime kata: no valid executable found for OCI runtime
kata: invalid argument"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI
network podman (typ
e=bridge) at /etc/cni/net.d/87-podman-bridge.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI
network descargas_d
efault (type=bridge) at /etc/cni/net.d/descargas_default.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI
network internet-mo
nitoring_back-tier (type=bridge) at
/etc/cni/net.d/internet-monitoring_back-tier.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI
network internet-mo
nitoring_front-tier (type=bridge) at
/etc/cni/net.d/internet-monitoring_front-tier.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Setting
parallel job count to
25"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="using systemd
socket activati
on to determine API endpoint"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="using API
endpoint: ''"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="API server
listening on \"/ru
n/podman/podman.sock\""
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(87f3d612-9e67-4975
-a52d-e34f8f177998) -- GET /version BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(f6beda6a-42c3-414c
-9d8c-0314e00c86d7) -- GET /v1.40/networks/descargas_default
BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(60f23924-261e-41fd
-9e14-459930ec3a0b) -- GET /v1.40/info BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(bd218869-1c22-4faf
-878e-f2bffeaec753) -- GET /v1.40/networks/descargas_default
BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info

Re: Podman and docker compose

[Daniel Walsh]

On 4/11/21 22:10, Gwyn Ciesla via devel wrote:

Have you tried podman-compose? It's in the Fedora repos.

Podman APIV2 is supposed to support docker-compose, if this fails an 
Issue or Bugzilla should be opened.  Podman-compose is an alternative 
open source project for compose, which we are not sure is going to 
continue into the future.


--
Gwyn Ciesla
she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie



Sent from ProtonMail mobile



 Original Message 
On Apr 11, 2021, 7:34 PM, Sergio Belkin < seb...@gmail.com> wrote:


Hi,
I'm playing around with podman and docker compose, so I've read
the post at https://www.redhat.com/sysadmin/podman-docker-compose
.

The example with Gitea does not work, this the output:

sudo docker-compose up
descargas_elasticsearch_1 is up-to-date
Creating descargas_skydive-analyzer_1 ... error

ERROR: for descargas_skydive-analyzer_1  Cannot create container
for service skydive-analyzer: bad parameter: Link is not supported

ERROR: for skydive-analyzer  Cannot create container for service
skydive-analyzer: bad parameter: Link is not supported
ERROR: Encountered errors while bringing up the project.

Am I doing something wrong?

This is the log:

abr 11 21:28:25 munster.belkin.home systemd[1]: Starting Podman
API Service...
abr 11 21:28:25 munster.belkin.home systemd[1]: Started Podman API
Service.
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="/usr/bin/podman
filtering at
log level info"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Error
initializing configured
OCI runtime kata: no valid executable found for OCI runtime kata:
invalid argument"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network
podman (typ
e=bridge) at /etc/cni/net.d/87-podman-bridge.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network
descargas_d
efault (type=bridge) at /etc/cni/net.d/descargas_default.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network
internet-mo
nitoring_back-tier (type=bridge) at
/etc/cni/net.d/internet-monitoring_back-tier.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network
internet-mo
nitoring_front-tier (type=bridge) at
/etc/cni/net.d/internet-monitoring_front-tier.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="Setting parallel
job count to
25"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="using systemd
socket activati
on to determine API endpoint"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="using API
endpoint: ''"
abr 11 21:28:25 munster.belkin.home podman[282]:
time="2021-04-11T21:28:25-03:00" level=info msg="API server
listening on \"/ru
n/podman/podman.sock\""
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(87f3d612-9e67-4975
-a52d-e34f8f177998) -- GET /version BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(f6beda6a-42c3-414c
-9d8c-0314e00c86d7) -- GET /v1.40/networks/descargas_default BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(60f23924-261e-41fd
-9e14-459930ec3a0b) -- GET /v1.40/info BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(bd218869-1c22-4faf
-878e-f2bffeaec753) -- GET /v1.40/networks/descargas_default BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(25b1c622-5f7d-47c6
-8d81-cf0f0a497a2f) -- GET

/v1.40/containers/json?limit=-1=0=0_cmd=0=%7B%22label%22%3A+%5B%22com.docker.comp
ose.project%3Ddescargas%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D
BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]:
time="2021-04-11T21:28:28-03:00" level=info
msg="APIHandler(7af0b0a3-1e79-4f66
-8e4d-afe5f21a336d) -- GET

/v1.40/containers/json?limit=-1=1=0_cmd=0=%7B%22label%22%3A+%5B%22com.docker.comp

Re: Podman and docker compose

[Daniel Walsh]

Brent PTAL


On 4/11/21 20:34, Sergio Belkin wrote:

Hi,
I'm playing around with podman and docker compose, so I've read the 
post at https://www.redhat.com/sysadmin/podman-docker-compose 
.


The example with Gitea does not work, this the output:

sudo docker-compose up
descargas_elasticsearch_1 is up-to-date
Creating descargas_skydive-analyzer_1 ... error

ERROR: for descargas_skydive-analyzer_1  Cannot create container for 
service skydive-analyzer: bad parameter: Link is not supported


ERROR: for skydive-analyzer  Cannot create container for service 
skydive-analyzer: bad parameter: Link is not supported

ERROR: Encountered errors while bringing up the project.

Am I doing something wrong?

This is the log:

abr 11 21:28:25 munster.belkin.home systemd[1]: Starting Podman API 
Service...
abr 11 21:28:25 munster.belkin.home systemd[1]: Started Podman API 
Service.
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="/usr/bin/podman 
filtering at

log level info"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="Error initializing 
configured
OCI runtime kata: no valid executable found for OCI runtime kata: 
invalid argument"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network 
podman (typ

e=bridge) at /etc/cni/net.d/87-podman-bridge.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network 
descargas_d

efault (type=bridge) at /etc/cni/net.d/descargas_default.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network 
internet-mo
nitoring_back-tier (type=bridge) at 
/etc/cni/net.d/internet-monitoring_back-tier.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="Found CNI network 
internet-mo
nitoring_front-tier (type=bridge) at 
/etc/cni/net.d/internet-monitoring_front-tier.conflist"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="Setting parallel job 
count to

25"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="using systemd socket 
activati

on to determine API endpoint"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="using API endpoint: ''"
abr 11 21:28:25 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:25-03:00" level=info msg="API server listening 
on \"/ru

n/podman/podman.sock\""
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(87f3d612-9e67-4975

-a52d-e34f8f177998) -- GET /version BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(f6beda6a-42c3-414c

-9d8c-0314e00c86d7) -- GET /v1.40/networks/descargas_default BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(60f23924-261e-41fd

-9e14-459930ec3a0b) -- GET /v1.40/info BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(bd218869-1c22-4faf

-878e-f2bffeaec753) -- GET /v1.40/networks/descargas_default BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(25b1c622-5f7d-47c6
-8d81-cf0f0a497a2f) -- GET 
/v1.40/containers/json?limit=-1=0=0_cmd=0=%7B%22label%22%3A+%5B%22com.docker.comp
ose.project%3Ddescargas%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D 
BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(7af0b0a3-1e79-4f66
-8e4d-afe5f21a336d) -- GET 
/v1.40/containers/json?limit=-1=1=0_cmd=0=%7B%22label%22%3A+%5B%22com.docker.comp
ose.project%3Ddescargas%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D 
BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(ad9f4acb-47ac-4699
-aa65-e542a59912e9) -- GET 
/v1.40/containers/c519bbe7f21e7c01729d62237b819b84b3bf364784a115fa536ad45153224ffc/json 
BEGIN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(000638a6-ac24-403b
-81d2-a41f4ec0cde0) -- GET 
/v1.40/containers/json?limit=-1=1=0_cmd=0=%7B%22label%22%3A+%5B%22com.docker.comp
ose.project%3Ddescargas%22%2C+%22com.docker.compose.service%3Delasticsearch%22%2C+%22com.docker.compose.oneoff%3DFalse%22%5D%7D 
BEG

IN"
abr 11 21:28:28 munster.belkin.home podman[282]: 
time="2021-04-11T21:28:28-03:00" level=info 
msg="APIHandler(2f67caff-4f06-496f
-8abe-f7c5c698d8a9) -- GET 

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Daniel Walsh]

On 4/3/21 02:34, Tomasz Torcz wrote:

Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):

On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel  wrote:

On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:

Unless OpenShift and RKE recently changed so that containers can run
as root by default (as of yesterday, they didn't), this is solidly a
bad idea, since it makes it much more unintuitive to set up secure
containers conforming with the guidelines for these Kubernetes
platforms.

In my experience, containers trying to run stuff from shadow-utils in
their entrypoint/startup scripts tend to be a reason for containers to
*not* run on OpenShift/OKD without additional adjustments.

A related (and more common) issue are images that expect to run with a
particular named user (or UID) determined during the build process
(again, most likely created using shadow-utils).

I'm not familiar with Rancher but at least for OpenShift, I don't think
the availability of shadow-utils is very useful. At run time, you can't
use the shadow-utils at all and whatever you do with it during build
time is unlikely to be helpful (and actively harmful more often than
not) at run time when OpenShift assigns you an arbitrary UID.

It's basically required for building containers that will work at
runtime where OpenShift assigns an arbitrary UID.

For example, in my containers, I *build* and create a "runtime user"
with the UID 1000, and then set things up to use that context at the
end. OpenShift uses that for its dynamic UID assignment.

   But you do not need shadow-utils for that. Even OpenShift
documentation shows simple echo is enough:

if ! whoami &> /dev/null; then
   if [ -w /etc/passwd ]; then
   echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} 
user:${HOME}:/sbin/nologin" >> /etc/passwd
   fi
fi
https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
(yeah, I know it's an old and obsolete version of docs)


What about all of the users of Docker and Podman who do?


```

from fedora

run useradd XYZ

user XYZ

...

```

Do you just break them out of the box?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Community meeting today 11:00 AM EST

[Daniel Walsh]

https://podman.io/community/meeting/

https://bluejeans.com/796412039


 Agenda

 *

   11:00 -> 11:05 - Welcome!

 *

   11:05 -> 11:20 - Podman v3.0 Overview - Matt Heon

 *

   11:20 -> 11:30 - Podman Compose Demo - Brent Baude

 *

   11:30 -> 11:40 - Demo’s TBD - Tom Sweeney and more?

 *

   11:40 -> 11:55 - Open Forum/Questions and Answers Session

 *

   11:55 -> 12:00 - Next Meeting, Topics for Next Meeting, and Wrap up

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Container Plumbing Days call for speakers.

[Daniel Walsh]

Announcing Free Open Source Micro Virtual Conference `Container Plumbing 
Days` sponsored byRed Hat. March 9-10, 2021. Looking for speakers. Low 
level talks, from the container engine down to the OS. Not orchestrators.


http://containerplumbing.org/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Docker/Moby 20.10.0 has been released with cgroup v2 support

[Daniel Walsh]

On 12/13/20 09:27, Neal Gompa wrote:

Hey all,

It seems that Docker/Moby 20.10.0 has been released last week. With
this release, Docker/Moby now fully supports cgroup v2, which means
Fedora CoreOS can finally switch to cgroup v2 like the rest of Fedora
has since Fedora 31.

There seems to be a rather drastic change to Docker/Moby, though. The
docker/docker-ce repo has been retired and will be archived[1]. It
seems packaging is going to be significantly different, since the
individual components need to be orchestrated to be built now.

The docker/cli[2] and moby/moby[3] repos have been tagged. We seem to
already have sufficiently updated containerd and runc already, so it
seems the packaging for moby-engine needs to be restructured to deal
with the new method of building and shipping it.

I figured it'd be worth sending an email because the docker-ce repo
isn't getting tagged and I am unsure if the infrastructure would have
picked up this change and notified anybody. Hopefully we can get
Docker/Moby 20.10.0 into Fedora soon and have Fedora CoreOS switch to
cgroup v2.

[1]: https://github.com/docker/docker-ce/blob/master/README.md
[2]: https://github.com/docker/cli/releases/tag/v20.10.0
[3]: https://github.com/moby/moby/releases/tag/v20.10.0

Since I would love to see Fedora CoreOS shrunk can we remove runc and 
just use crun. Going forward we have changed the default for the 
containers/engines team to just use crun.  This means Podman and Buildah 
will use crun as default even on cgroups V1 platform. They have been 
using it as the default for cgroupv2 since fedora 31, so there has been 
a lot of use of it.


# du /usr/bin/runc /usr/bin/crun
11036    /usr/bin/runc
332    /usr/bin/crun

I would also love to see moby removed altogether from Fedora CoreOS and 
just install podman-docker package.  Now that Podman has APIV2 support 
it should be able to handle almost all "docker" use cases including 
docker-py and compose.


Doing these two things would help with FedoraCoreOS diet.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Trying to setup some tmpfiles handling for podman.

[Daniel Walsh]

# /tmp/podman-run-* directory can contain content for Podman containers 
that have run
# for many days. This following line prevents systemd from removing this 
content.

x /tmp/podman-run-*
D! /run/podman
X! /var/lib/cni/networks/*/last_reserved_ip*
D! /var/lib/cni/networks

Basically we want to make sure the /run/podman and /var/lib/cni/networks 
are cleaned up on boot.


BUT we don't want /var/lib/cni/networks/*/last_reserved_ip* to be removed.

This works but is still cleaning up last_reserved_ip.0?  What am I doing 
wrong?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-resolved in a container

[Daniel Walsh]

On 11/19/20 03:06, Nikos Mavrogiannopoulos wrote:

On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy  wrote:

On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:

Hi,
I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?

I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

   systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.

Is that on the "default" fedora container, or do you use something
else? On fedora33 I get the same message about dbus and systemd not
being pid 1.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


I was mistaken, there is no fedora-init image. There is a ubi8-init image.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-resolved in a container

[Daniel Walsh]

On 11/19/20 03:06, Nikos Mavrogiannopoulos wrote:

On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy  wrote:

On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:

Hi,
I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?

I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

   systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.

Is that on the "default" fedora container, or do you use something
else? On fedora33 I get the same message about dbus and systemd not
being pid 1.

fedora-init container runs with systemd, fedora container does NOT.

regards,
Nikos
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 podman: unpacking of archive failed cpio: cap_set_file

[Daniel Walsh]

On 10/5/20 02:13, Lumír Balhar wrote:

On 10/2/20 9:52 PM, Daniel Walsh wrote:

On 10/2/20 06:09, Lumír Balhar wrote:

Hello.

I have fully upgraded Fedora 33 on my laptop and when I try to use 
podman and install httpd package into container, I get the following 
error message:


Error unpacking rpm package httpd-2.4.46-1.fc32.x86_64
error: unpacking of archive failed on file 
/usr/sbin/suexec;5f76fa6a: cpio: cap_set_file

error: httpd-2.4.46-1.fc32.x86_64: install failed

The same thing happens for various different containers like 
fedora:33, fedora:32, centos:7 etc so I guess the problem is 
somewhere on the host and not in the containers.


It seems that the problem is not new and it was previously fixed in 
kernel where a patch added v3 namespaced file capabilities: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8db6c34f1dbc8e06aa016a9b829b06902c3e1340


Does anybody know why the latest kernel should not support it? 
Should I report a bug for the kernel?


Have a nice day.

Lumír
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


I have an update for skopeo (containers-common) that should fix this 
problem.


Please try this out and set the karma if it fixes the problem.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc


Hi.

The update is unpushed and there is no active update for Fedora 33 now.

Lumír


Lokesh can you explain what is going on?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 podman: unpacking of archive failed cpio: cap_set_file

[Daniel Walsh]

On 10/2/20 06:09, Lumír Balhar wrote:

Hello.

I have fully upgraded Fedora 33 on my laptop and when I try to use 
podman and install httpd package into container, I get the following 
error message:


Error unpacking rpm package httpd-2.4.46-1.fc32.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;5f76fa6a: 
cpio: cap_set_file

error: httpd-2.4.46-1.fc32.x86_64: install failed

The same thing happens for various different containers like 
fedora:33, fedora:32, centos:7 etc so I guess the problem is somewhere 
on the host and not in the containers.


It seems that the problem is not new and it was previously fixed in 
kernel where a patch added v3 namespaced file capabilities: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8db6c34f1dbc8e06aa016a9b829b06902c3e1340


Does anybody know why the latest kernel should not support it? Should 
I report a bug for the kernel?


Have a nice day.

Lumír
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


I have an update for skopeo (containers-common) that should fix this 
problem.


Please try this out and set the karma if it fixes the problem.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

[Daniel Walsh]

On 8/24/20 07:00, Miro Hrončok wrote:
> Hello.
>
> The following packages are downgrades when I attempt upgrade from
> Fedora 32 to Fedora 33:
>
> - containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
> - fuse-overlayfs 1.1.2 -> 1.1.0
> - strace 5.8 -> 5.7.0.6.7ab6
> - thunderbird 668.11.0 -> 8.10.0
>
> Is this expected?
>
Definitely not on the first two.  I have asked the maintainers to look
into it.  Looks like packages in rawhide are failing to build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Package Review SELinux help

[Daniel Walsh]

On 6/26/20 14:39, Robert-André Mauchin wrote:
> Hello,
>
>
> I know next to nothing about SELinux so I'd like some help about the Bitcoin 
> Package Review by negativo17: 
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1834731
>
> Notably: are the bitcoin.{te,fc,if} files are sane?
> Are they installed properly in the SPEC? Especially these parts:
>
> %post server
> %systemd_post %{name}.service
> for selinuxvariant in %{selinux_variants}
> do
> /usr/sbin/semodule -s ${selinuxvariant} -i \
> %{_datadir}/selinux/${selinuxvariant}/%{name}.pp \
> &> /dev/null || :
> done
> # FIXME This is less than ideal, but until dwalsh gives me a better way...
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8332 2> /dev/null
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8333 2> /dev/null
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18332 2> /dev/null
> /usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18333 2> /dev/null
> /sbin/fixfiles -R %{name}-server restore &> /dev/null || :
> /sbin/restorecon -R %{_localstatedir}/lib/%{name} || :
>
> %postun server
> %systemd_postun_with_restart %{name}.service
> if [ $1 -eq 0 ] ; then
> # FIXME This is less than ideal, but until dwalsh gives me a better way...

You can do these all in one command using

semanage import

This should speed installation.

> /usr/sbin/semanage port -d -p tcp 8332
> /usr/sbin/semanage port -d -p tcp 8333
> /usr/sbin/semanage port -d -p tcp 18332
> /usr/sbin/semanage port -d -p tcp 18333
> for selinuxvariant in %{selinux_variants}
> do
> /usr/sbin/semodule -s ${selinuxvariant} -r %{name} \
> &> /dev/null || :
> done
> /sbin/fixfiles -R %{name}-server restore &> /dev/null || :
> [ -d %{_localstatedir}/lib/%{name} ] && \
> /sbin/restorecon -R %{_localstatedir}/lib/%{name} \
> &> /dev/null || :
> fi
>
> Please comment in the RR if you can help.
>
> I find the documentation at https://fedoraproject.org/wiki/SELinux rather old 
> and not really focused on the packaging side of it. Is there guidelines 
> anywhere else?
>
> Best regards,
>
> Robert-André
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Daniel Walsh]

On 4/15/20 17:06, James Cassell wrote:
> On Wed, Apr 15, 2020, at 1:27 PM, Daniel Walsh wrote:
>> On 4/15/20 10:07, Lennart Poettering wrote:
>>> On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
>>>
>>>> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
>>>>> https://fedoraproject.org/wiki/Changes/systemd-resolved
>>>>>
>>>>> == Summary ==
>>>>>
>>>>> Enable systemd-resolved by default. glibc will perform name resolution
>>>>> using nss-resolve rather than nss-dns.
>>>>>
>>>>> == Owner ==
>>>>> * Name: [[User:catanzaro| Michael Catanzaro]]
>>>>> * Email: 
>>>>>
>>>>> == Detailed Description ==
>>>>>
>>>>> We will enable systemd-resolved by default.
>>>> Does this require systemd to be running? How does this affect DNS 
>>>> resolution on a Fedora 33 container?
>>> Depends.
>>>
>>> If a container manager copies in /etc/resolv.conf from the host into
>>> the container on container *start*, it might be wise to copy in
>>> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
>>> exists. That file in /run contains the currently up-to-date upstream
>>> DNS info literally.
>> Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
>> they can modify it internally,
>>
>> It looks like podman will just follow the link.  I setup this simple test
>>
>> # ls -l /etc/resolv.conf
>> lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
>> # cat /etc/resolv.conf
>> # Generated by NetworkManager
>> search redhat.com
>> nameserver 10.5.30.160
>> nameserver 10.11.5.19
>> nameserver 192.168.1.1
>> # podman run fedora cat /etc/resolv.conf
>> search redhat.com
>> nameserver 10.5.30.160
>> nameserver 10.11.5.19
>> nameserver 192.168.1.1
>>
>> So as long as the
>>
>> /run/systemd/resolve/resolv.conf
>>
>> file is properly formated, our container engines will just work.
>>
> I think there's some existing black magic to handle the case when resolv.conf 
> references 127.0.0.1... maybe it already also works for 127.0.0.53. 
> Otherwise, maybe it could be patched to handle 127.0.0.0/8 in the same way. 
> Then no special casing for resolved would be needed.
>
> V/r,
> James Cassell
Yes I believe the container engines see 127.0.0.1 and switch it to 8.8.8.8
>>> If a container builder copies in /etc/resolv.conf during build time,
>>> it probably should insert something like 8.8.8.8 as DNS servers there,
>>> also replacing whatever is there.
>>>
>>> Note that the logic in systemd and resolved is very defensive: if
>>> /etc/resolv.conf is not a symlink to
>>> /run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
>>> /etc/resolv.conf instead of managing it (see other mail), hence a
>>> container mgr/builder that wants to direct DNS traffic somewhere
>>> should just override the file to whatever it wants, and things will
>>> just work, regarldess if resolved runs in the container or not, and
>>> resolved -- if used -- will honour whatever the container mgr/builder
>>> put there.
>>>
>>> Lennart
>>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Shebang spawning podman/docker containerized interpreter?

[Daniel Walsh]

On 4/15/20 15:01, clime wrote:
> On Wed, 15 Apr 2020 at 09:50, Pavel Raiskup  wrote:
>> Hey all, I'd like to write scripts like:
>>
>> $ cat script
>> #! /bin/shebang which python3-evaluates this in container from image FOO
>> print("Hello world")
>>
>> .. and be able to run them just like `./script [ARGS ...]`.
>>
>> I played a bit with [1] today, and I'd like to package it to Fedora for at
>> least my personal convenience,  but I'm rather asking whether there isn't
>> something like that already (perhaps more robust and working everywhere).
>>
>> [1] https://github.com/praiskup/container-shebang
> Hello, it is interesting. I needed to look at the readme properly to
> understand what it does: https://github.com/praiskup/container-shebang
>
> It might be a bit cumbersome when you want to change container image
> in which the script should be evaluated, no? Cause you need:
>
> #!/bin/container-shebang --image fedora:32

I would make this less Fedora specific.  Default to $ID and $VERSION_ID
in /etc/os-release

That way it could work on RHEL, Centos, Ubuntu ... as well as Fedora.

> inside the script. Maybe if you connect it with environment variables
> or specify just "fedora" instead of "fedora:32"...
>
> What's the use-case by the way? Is host execution out of date? :)
> clime
>
>> Pavel
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Daniel Walsh]

On 4/15/20 10:07, Lennart Poettering wrote:
> On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
>
>> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
>>> https://fedoraproject.org/wiki/Changes/systemd-resolved
>>>
>>> == Summary ==
>>>
>>> Enable systemd-resolved by default. glibc will perform name resolution
>>> using nss-resolve rather than nss-dns.
>>>
>>> == Owner ==
>>> * Name: [[User:catanzaro| Michael Catanzaro]]
>>> * Email: 
>>>
>>> == Detailed Description ==
>>>
>>> We will enable systemd-resolved by default.
>> Does this require systemd to be running? How does this affect DNS resolution 
>> on a Fedora 33 container?
> Depends.
>
> If a container manager copies in /etc/resolv.conf from the host into
> the container on container *start*, it might be wise to copy in
> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
> exists. That file in /run contains the currently up-to-date upstream
> DNS info literally.

Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
they can modify it internally,

It looks like podman will just follow the link.  I setup this simple test

# ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
# cat /etc/resolv.conf
# Generated by NetworkManager
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
# podman run fedora cat /etc/resolv.conf
search redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1

So as long as the

/run/systemd/resolve/resolv.conf

file is properly formated, our container engines will just work.

>
> If a container builder copies in /etc/resolv.conf during build time,
> it probably should insert something like 8.8.8.8 as DNS servers there,
> also replacing whatever is there.
>
> Note that the logic in systemd and resolved is very defensive: if
> /etc/resolv.conf is not a symlink to
> /run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
> /etc/resolv.conf instead of managing it (see other mail), hence a
> container mgr/builder that wants to direct DNS traffic somewhere
> should just override the file to whatever it wants, and things will
> just work, regarldess if resolved runs in the container or not, and
> resolved -- if used -- will honour whatever the container mgr/builder
> put there.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Daniel Walsh]

On 4/14/20 17:26, Michael Catanzaro wrote:
> On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> I guess the lesson here is the nsswitch.conf change should be
>> clarified in the proposal.
>
> OK, I've just added it at the end of this part here:
>
> "systemd-libs currently has
> [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede5d234b7878753/f/systemd.spec#_606
> a %post scriplet] to enable nss-myhostname and nss-systemd by either
> (a) modifying authselect's user-nsswitch.conf template, if authselect
> is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
> will work with the systemd maintainers to enable nss-resolve here as
> well by adding `resolve [!UNAVAIL=return]` to the hosts line."
>
> Then the instructions in the change proposal for disabling
> systemd-resolved say:
>
> "Modify /etc/authselect/user-nsswitch.conf and remove resolve
> [!UNAVAIL=return] from the hosts line. Run authselect apply-changes.
> (If you have disabled authselect, then edit /etc/nsswitch.conf
> directly.)"
>
> I guess I should delete that from the proposal, since it's not needed?
>
>> I'm not sure what the best path option here is. The path of least
>> resistance would be to simply leave /etc/resolv.conf out of this change.
>> nss-resolve doesn't care, and the effect is only on things which
>> don't use the nss stack, or read /etc/resolv.conf for other purposes.
>
> NetworkManager only enables its systemd-resolved backend if
> /etc/resolv.conf is symlinked appropriately. So that needs to happen.
>
> I didn't consider cases where systemd is not running because Fedora
> hasn't supported booting without systemd in about a decade. But I
> guess the problem here is for containers where systemd is not running
> inside the container, but is running on the host system? I hadn't
> considered this scenario. What do Ubuntu containers do? I guess those
> are not all broken. :)
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

We can change container engines (podman, Buildah, CRI-O) to handle this
but they need to have a location of a properly configured resolv.conf
file, somewhere on the system to be used without systemd.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

New blog on speeding up container image builds using Buildah and dnf.

[Daniel Walsh]

https://www.redhat.com/sysadmin/speeding-container-buildah

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock inside docker

[Daniel Walsh]

On 3/5/20 11:40, Miro Hrončok wrote:
> On 05. 03. 20 15:09, Christoph Junghans wrote:
>> Hi,
>>
>> if I am trying to run mock inside docker, I am getting the following
>> error:
>> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
>> ERROR: Command failed:
>>   # /bin/mount -n --bind
>> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>>
>> In the past I usually added --old-chroot to workaround that, but now
>> this yields:
>> ERROR: Command failed:
>>   # /bin/mount -n -t tmpfs -o rprivate tmpfs
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>>
>> This mock 2.0 inside the f31 ("fedora:latest") container from this
>> morning.
>>
>> Any idea how get mock working again?
>
> We run mock in docker with:
>
> $ docker run --cap-add=SYS_ADMIN
>
> And it seems to still work (on Travis CI at least).
>
Using Podman we might be able to get this to work in a user namespace,
without requiring root at all.


If you setup a user inside of the container to run with a user
namespace/mount namespace then create one and mount the proc and tmpfs

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: mock inside docker

[Daniel Walsh]

Would like to know if this works with Podman.

On 3/5/20 11:22, Frantisek Zatloukal wrote:
> Hi,
>
> adding "--no-bootstrap-chroot" wouldn't help?
>
> On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans  > wrote:
>
> Hi,
>
> if I am trying to run mock inside docker, I am getting the
> following error:
> INFO: Results and/or logs in:
> /var/lib/mock/fedora-rawhide-x86_64/result
> ERROR: Command failed:
>  # /bin/mount -n --bind
> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>
> In the past I usually added --old-chroot to workaround that, but now
> this yields:
> ERROR: Command failed:
>  # /bin/mount -n -t tmpfs -o rprivate tmpfs
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>
> This mock 2.0 inside the f31 ("fedora:latest") container from this
> morning.
>
> Any idea how get mock working again?
>
> Christoph
>
> -- 
> Christoph Junghans
> Web: http://www.compphys.de
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> -- 
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Quality Engineer
> Red Hat
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora & Containers

[Daniel Walsh]

On 2/25/20 12:05 PM, Michal Schorm wrote:
> Hello,
>
> Will anybody be able to explain to me the current state of the
> containers & containerization in Fedora, please?
>
> I have some questions, but the more I searched for whom & where to
> ask, the more confused I became.
>
> --
>
> 1) There ́s an IRC on freenode, '#fedora-containers' channel.
> The TOPIC set contains the following message:
> "The place for container runtimes and application containers.
> Forums @ https://discussion.fedoraproject.org/c/containers,
> visit the site @ https://containers.fedoraproject.org
> (website operational at some point in August)."
> However no link mentioned are accessible.
>
> 2) There is 'Fedora Container & Tools Documentation' [1]
> It is only half-filled with information, some part missing entirely.
> Even parts as 'Container Guidelines' [2].
> Btw the wiki gladly redirects there ^ [3].
> Btw there are some scratch notes about the guidelines from damn 2017
> [4], which google offers me rather than the actual guidelines (because
> they don't exist)
>
> 3) So ... who is in charge of it? Whom to contact? How? Where?
> Does Fedora count with Containers or does it already thrown it overboard?
>
> 4) The container I am maintainer of (in pagure in 'container'
> namespace) is not branched automatically. The last branch is 'f30',
> but now I want to update it and add the missing branches. I have no
> idea how should I do it though, since (1) (2) are such a mess.
> I can try 'git push', but anyway, it won't solve the issue, it's not
> branched automatically.
>
> 5) The Dockerfile (are we still using this name? shouldn't it be
> 'containerfile' now, with podman?)

Containerfile will not work with Docker by default, so if you want to
stick to Dockerfile, it is fine.

> starts with line like:
> " FROM registry.fedoraproject.org/f30/."
> How can I substitute the Fedora release version with a variable, so I
> can share the same content amongst branches for different Fedora
> releases?

You could specify this as ARG and then have the caller pass in the
version of Fedora


ARG=RELEASE=f31

...

 FROM registry.fedoraproject.org/RELEASE/


...
podman build --build-arg RELEASE=f30 -f Dockerfile .



> [1] https://docs.fedoraproject.org/en-US/containers/
> [2] https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/
> [3] https://fedoraproject.org/wiki/Container:Guidelines
> [4] https://fedoraproject.org/wiki/Talk:Container:Guidelines
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Great article by Valentin Rothberg on Running Podman in systemd unit files.

[Daniel Walsh]

This is one of our most common questions, and why we are adding

podman generate systemd ...

People are interested in running containers as standard services on
linux systems.  Valentin dug deep into how to do this. He explains it
all here. 

https://www.redhat.com/sysadmin/podman-shareable-systemd-services

Please social media this.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

https://bodhi.fedoraproject.org/updates/new

[Daniel Walsh]

Is not working for me.

I am trying to release container-selinux-2.124.0 to F31 but the web app
just spins after I hit submit.  No error messages but no success.  Am I
doing something wrong or is the updates system broken?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should we discontinue the Python Classroom Lab?

[Daniel Walsh]

On 12/6/19 5:39 AM, Nicolas Mailhot via devel wrote:
> Le jeudi 05 décembre 2019 à 16:42 -0700, John M. Harris Jr a écrit :
>> Why in the world was Docker removed? Docker is the most popular
>> container 
>> technology, so if we must embrace the "container" systems, why not
>> include the most popular in Fedora?
> Because moby (née docker) is a trainwreck on the technical side (sky-
> high bundling of git snapshots, with disagreement on the correct
> snapshot to bundle between various components, that make maintaining
> docker, and pulling it forward, for example for changes cgroup-side, a
> major endeavour).
>
> In other words: classical technical debt accumulations. Lots of
> unhealthy technical compromises, to be first to market, and get adopted
> (that worked fine), and no plan to deal with what happens afterwards
> (long term maintenance, evolution, and support).
>
> Regards,
>
Docker is still available as Moby package.  Docker Inc changed their
requirements on the use of the name Docker.  So we stopped packaging
Docker directly on Fedora.  Moby is the upstream project comprising a
lot of what Docker is and will be.  So we ship that in Fedora.

Simultaneous with this we began working on splitting apart what was
Docker into a series of smaller tools that could run any OCI/Docker
Image in the same way that the Docker Daemon did.  But with different
security goals.


Skopeo - Allows you to copy container images from any container registry
to other types of container storage including other container
registries.  Think of this as scp for container images. Does not require
root on the host to run.

Buildah - Container image builder that allows the user to build
OCI/Docker images and push them to contianer registries.  Does not
require root.  Allows use of Dockerfile as well as simple bash scripting
for creating container images.  Can be run without any privilege inside
of another container.

Podman - Complete replacement of the Docker CLI.  Implements almost all
of the familiar commands from the Docker CLI with the same CLI.  alias
docker=podman, and your commands should work.  Works rootless as well as
root. Does not require a Daemon to be run. Really works well with
Systemd.  Also supports lots of advanced features like Pods.

CRI-O - Container Runtime Interface Daemon for running Kubernetes
workloads.  Dedicated/optimized to Kubernetes.  Does not support any
other orchestrators.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Should we discontinue the Python Classroom Lab?

[Daniel Walsh]

On 12/5/19 9:55 AM, John M. Harris Jr wrote:
> On Thursday, December 5, 2019 3:44:50 AM MST Miro Hrončok wrote:
>>   - Docker is broken
>> - one of the main ideas was to produce a Docker image
>> - the Docker instructions on the download page [4] are not working
>> - not even when replaced with podman
>> - I have no idea how to fix it
>> - I know no way to upload to official dockerhub [5]
> What's wrong with the packaged version of Docker?
>
It does not exists in Fedora 31.  What is the issue with Podman support?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I wrote a blog on why we moved Fedora 31 to cgroup V2

[Daniel Walsh]

https://www.redhat.com/sysadmin/fedora-31-control-group-v2

If you like it, please put it out on social media.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

[Daniel Walsh]

On 11/8/19 5:16 PM, John M. Harris Jr wrote:
> On Tuesday, November 5, 2019 12:09:55 PM MST Martin Kolman wrote:
>> On Tue, 2019-11-05 at 19:41 +0100, Kevin Kofler wrote:
>>
 Python 3 traditionally in Fedora was built with a shared library
 libpython3.?.so and the final binary was dynamically linked against
 that shared library. This change is about creating the static library
 and linking the final python3 binary against it,
>>>
>>> I oppose this change, because this is yet another size increase:
>> Up to ~27% speed increase for extra ~3.4 MB storage used seems like a good
>> trade-off to me...
>  
>>>
 As a negative side effect, when both libpython3.8.so and
 /usr/bin/python3.8 are installed, the filesystem footprint will be
 slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M).
>>>
>>> and while:
>>>
>>>
 OTOH only a very small amount of packages will depend on
 libpython3.8.so.
>>>
>>> in practice, that does not help because some of those packages are
>>> installed  by default, e.g., the ones you mentioned being installed by
>>> default even on the Docker image:
>>>
>>>
 *'''libcomps'''
 *'''libdnf'''
 *'''vim'''
>>>
>>> but there are more, such as gdb, libreoffice, krita, boost, etc. that are
>>>
>>> installed on various live images, and calamares, which is popular on 
>>> remixes. So all those images will be bloated as a result of your code 
>>> duplicating change.
>>>
>>>
>>> In addition:
>>>
>>>
 By applying this change, libpython's namespace will be separated from
 Python's, so '''C extension which are still linked to libpython'''
 might experience side effects or break.
>>>
>>> so compatibility is an issue too.
>>>
>>>
>>> Kevin Kofler
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List
>>> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
>>> Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o
>>> rg
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
>> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
>> Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Anyone that has ever worked with CD images understands that every megabyte 
> counts.
>
I would almost always take speed over disk size.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Trouble with install ordering and SELinux config

[Daniel Walsh]

Flat pack should be doing a requires(post): selinux-policy-base

To make sure it is installed before flatpack.
On 11/1/19 2:51 PM, Tim Zabel wrote:
> On Fri, 2019-11-01 at 12:02 -0600, Orion Poplawski wrote:
>> My F31 kickstart install is failing with:
>>
>> DNF error: Error in POSTIN scriptlet in rpm package flatpak-selinux
> Hmm, I've also ran into this issue of flatpak-selinux's POSTIN failing
> :(
>
> Just to be sure, are you building the kickstart with SELinux set to
> permissive? It won't work if it's in Enforcing.
>
>> This is because flapak-selinux installs a SELinux module in %post:
>>
>> %post selinux
>> %selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
>>
>> which sources /etc/selinux/config.  It is failing because
>> /etc/selinux/config
>> does not exist and /bin/sh exits with failure (/bin/bash does not
>> interestingly enough).
>>
>> This was reported earlier here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1723118
> For reference, here are some other BZs that I've ran into while trying
> to come up with my own fixes to this issue:
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=1732132
>
> * https://bugzilla.redhat.com/show_bug.cgi?id=1665643
>
>
>> and the suggestion made to add:
>>
>> Requires(post): selinux-policy
>>
>> since selinux-policy owns /etc/selinux/config.  However, selinux-
>> policy
>> creates /etc/selinux/config in its own %post, and Requires(post) only
>> guarantees that the package's contents are installed, not that its
>> scripts are
>> complete.
>>
>> So, what's the best way to fix this?  We need /etc/selinux/policy to
>> be
>> present and populated with SELINUXTYPE=targeted for the selinux
>> policy modules
>> to be installed properly.
>>
>> selinux-policy does:
>>
>> %post
>> if [ ! -s /etc/selinux/config ]; then
>> #
>> # New install so we will default to targeted policy
>> #
>> echo "
>> # This file controls the state of SELinux on the system.
>> # SELINUX= can take one of these three values:
>> # enforcing - SELinux security policy is enforced.
>> # permissive - SELinux prints warnings instead of enforcing.
>> # disabled - No SELinux policy is loaded.
>> SELINUX=enforcing
>> # SELINUXTYPE= can take one of these three values:
>> # targeted - Targeted processes are protected,
>> # minimum - Modification of targeted policy. Only selected
>> processes are
>> protected.
>> # mls - Multi Level Security protection.
>> SELINUXTYPE=targeted
>>
>> " > /etc/selinux/config
>>
>>  ln -sf ../selinux/config /etc/sysconfig/selinux
>>  restorecon /etc/selinux/config 2> /dev/null || :
>> else
>>  . /etc/selinux/config
>> fi
>> exit 0
>>
>> But can't this be achieved simply with:
>>
>> %config(noreplace) %{_sysconfdir}/selinux/config
>>
>> New installs would get the default config, but otherwise you would
>> get a
>> .rpmnew file.
>>
>> However, I realize that nothing is particularly simple about SELinux
>> so there
>> are probably things I'm not aware of that prevent this.
>>
>> PS - the else code seems to be a no-op.
> Back when I was trying to find my own fixes, I managed to fix one
> portion of the %post selinux that was enough to solve my own problems,
> but this issue you're seeing is one that I wasn't able to find a fix
> for myself. I've love to see a resolution to this.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do you Remove packages from the distro?

[Daniel Walsh]

On 10/23/19 10:05 AM, Stephen Gallagher wrote:
> On Wed, Oct 23, 2019 at 9:40 AM Daniel Walsh  wrote:
>>  How do I go about removing packages from Fedora Distro.  I want to drop
>> oci-systemd-hook and oci-register-machine?  I would love to remove them
>> from f31 but it might be too late.
> I think we need more information on what you mean by "drop", because
> there are a lot of ways to interpret that.
>
> Do you mean:
>
> 1) I don't want to maintain these packages anymore, but someone else might.
> 2) These packages are no longer useful and there's no reason to keep
> updating them from here onwards.
Option 2, I retired both of them.
> 3) These packages are being replaced by other software or are actively
> harmful and should not remain on an end-user's system.

oci-systemd-hook features are now embeded in Podman, and we not accepted
into the moby project.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

How do you Remove packages from the distro?

[Daniel Walsh]

 How do I go about removing packages from Fedora Distro.  I want to drop
oci-systemd-hook and oci-register-machine?  I would love to remove them
from f31 but it might be too late.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: kata containers: adding a docker runtime

[Daniel Walsh]

On 9/25/19 8:26 PM, Tomasz Torcz wrote:
> On Wed, Sep 25, 2019 at 12:14:54PM +0200, Christophe de Dinechin wrote:
>> Hi Lokesh,
>>
>>
>> As you know, I have been working on bringing kata containers to Fedora.
>>
>> Since this adds a new runtime, the docker.service file would need to be
>> modified in order to be able to accommodate extra --add-runtime options.
>>
>> What approach would you recommend?
>   There's no Docker in Fedora anymore, so maybe don't bother?
>  

Podman, CRI-O, Buildah should be able to use the kata runtime.  If
moby-engine, the replacement for DOcker needs wants to use it, then it
should add the capability. 


BTW These are OCI runtimes, non "docker" runtimes. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-sysusers versus containers

[Daniel Walsh]

On 9/17/19 8:04 AM, Colin Walters wrote:
>
> On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote:
>> systemd-sysusers seeks to unify user creation[1]. It also has the
>> benefit of being able to create users on bootup. But, it pulls in the
>> entire systemd infrastructure with all it's dependencies.
>>
>> containers do not need systemd to run. They are trying to be as small
>> as possible. But if a package in container needs to add a user, then
>> systemd is pulled in and that container grows by up to 60M.[2]
>>
>> Minimizing containers, both in the short term and long term, are
>> important to the minimization team.  We have opened an issue for
>> this.[3]
> As I said in the big thread, what we should aim to minimize is containers 
> built via multi-stage build; nothing else is going to be small.
>
> The user ID is a very interesting topic...bigger picture for example, 
> OpenShift defaults to the `MustRunAsRange` SCC[1] - ensuring a uid is 
> dynamically allocated for the container.  So the `useradd` and `sysusers` 
> stuff isn't relevant.
> (We have a longstanding issue though that the uid isn't in the passwd 
> database but I think podman is growing some code to fix that)
Podman and CRI-O handle this now, by adding the runasuser to the
/etc/passwd inside of the container, if it does not exists.
>
> For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a 
> lot of cases, using systemd dynamic users is best:
> http://0pointer.net/blog/dynamic-users-with-systemd.html
> Where possible - using it for e.g. postgres would probably be somewhat of a 
> surprise for admins.
>
> It'd be useful in this discussion to look at particular containers - I'm 
> guessing it's things like nginx and postgres where we want to ship both an 
> RPM and a container image?   And where things intersect here is whether or 
> not the RPM depends on systemd.  Maybe the least bad thing is to introduce a 
> `systemd-container-stub` package that is empty except for Provides?   
> Dunno...it's messy.
>
> A whole lot of service software is container-only - it doesn't make sense to 
> make RPMs for them, which sidesteps a lot of this.
>
> [1] 
> https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Daniel Walsh]

On 8/21/19 5:00 AM, Tomasz Torcz wrote:
> On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
>> Having a container without a package manager sounds like the worst possible 
>> thing to add to an already poorly implemented solution. In reality, 
>> containers, regardless of what they're running, should be treated as what 
>> they 
>> are, GNU/Linux installs. Each one should be self sufficient from the host 
>> system, so that they can be properly updated using a package manager.
>>
>> Each container should, realistically, be a self contained system.
>   You do not update the container. You rebuild it, creating new image
> with updated components, then you test out new image.
>   Package manager is only needed during the build (in fact, it
> is indispensable at this step) but not during runtime.
>
I agree.  Entering a container and doing a yum update is an
Anti-pattern.  The way container images updates is envisioned is when I
need an updated container, I pull down a brand new image.  Hopefully
this image has gone through a thorough CI/CD system.  The container
image on the build system probably is built using dnf/yum, but those
tools do not necessarily need to be in the final image. Preferably they
would not be there.  Unfortunately in the real world this is not true. 
And the default Dockerfile construct enforces base layers to have dnf
installed.  Buildah and Multi-Stage builds do allow you to eliminate
these tools, but that is more difficult to do.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Daniel Walsh]

On 8/7/19 11:24 AM, Colin Walters wrote:
>
> On Tue, Jul 30, 2019, at 3:52 PM, Daniel Walsh wrote:
>> If you want small images, just use buildah.
> Dockerfile-based multi-stage builds are significantly more popular than this 
> and should really be mentioned first.
Buildah supports multi-stage builds as well.
> I'm not saying `buildah` is bad, but...what you're talking about here also 
> encourages using the host as a build root which has various negatives.
>
> And I think the main conversation to have is whether we should introduce 
> something more like
> https://github.com/GoogleContainerTools/distroless
> that basically just has:
>
>  - glibc
>  - ca-certificates
>
> Or to rephrase, a sufficient runtime for e.g. a Rust/golang binary and that's 
> it.
> (While people often say both Rust and golang are statically linked, that's 
> true
>  of the language code, but by default  Rust links to glibc, Go does not, and I
>  think what Rust does is better and should be encouraged, so we want a libc
>  in this "ultramin" container)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Daniel Walsh]

On 8/6/19 9:15 AM, Jun Aruga wrote:
>>> Please come!
>>>
>> Would love to see your examples use podman...
> Sorry here is the podman's example.
> And no worry. podman's examples are used as much as possible in my talk!
>
> ```
> $ uname -m
> x86_64
>
> $ podman run --rm -t arm64v8/fedora:30 uname -m
> standard_init_linux.go:211: exec user process caused "exec format error"
>
> $ sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes
>
> $ podman run --rm -t arm64v8/fedora:30 uname -m
> aarch64
> ```
>
Nice.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Daniel Walsh]

On 8/6/19 7:56 AM, Jun Aruga wrote:
>> ```
>> $ docker run --rm -t arm64v8/fedora:30 uname -m
> standard_init_linux.go:207: exec user process caused "no such file or 
> directory"
>> $ docker run --rm --privileged multiarch/qemu-user-static:register --reset
>> $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m
>> aarch64
> Recently our multiarch project released a new feature to enable to run
> a standard multi-architecture containers on x86_64, without
> multiarch/* container that was needed before, not depending on host OS
> environment.
>
> That means below workflow works
>
> ```
> $ uname -m
> x86_64
>
> $ docker run --rm -t arm64v8/ubuntu uname -m
> standard_init_linux.go:211: exec user process caused "exec format error"
>
> $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
>
> $ docker run --rm -t arm64v8/fedora:30 uname -m
> aarch64
> ```
>
> Is it fine to advertise my talk at Flock 2019 this Friday here? :)
>
> Title: Let's add Fedora multiarch containers to your CI.
> https://flock2019.sched.com/event/SJLx/lets-add-fedora-multiarch-containers-to-your-ci
>
> * When: Friday August 9, 2019 10:30 - 10:55
> * Where: the room Panorama (140m² / 40 people), The Danubius Hotel
> HELIA in Budapest, Hungary, at Flock Budapest 2019
>
> = Table of contents = (it might be changed a little bit later)
> * Fedora and Upstream - Past and Present
> * CPU Architecture Kinds
> * Tools for multiarch - Today's topics
> * QEMU and binfmt_misc - on News
> * 5 steps - to add Fedora multiarch to upstream CI
> * 1. qemu-$arch-static - An interpreter
> * 2. binfmt_misc - A kernel feature for binary format
> * 3. qemu-user-static RPM on Fedora
> * 4. qemu-user-static RPM and container
> * 5. multiarch/qemu-user-static image and CI
> * Note A: ARM supported CI services
> * Note B: A Dockerfile to multi-arch images
>   docker buildx, docker/(podman) build --platform
>
> Please come!
>
Would love to see your examples use podman...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Daniel Walsh]

If you want small images, just use buildah.

ctr=$(buildah from scratch)
mnt=$(buildah mount $ctr)
COPY/DnF/make install into $mnt
buildah config ... $ctr
buildah commit $ctr NEWIMAGE
buildah push NEWIMAGE CONTAINERREGGISTY...

If you want to build off of base images, you can probably create them
with buildah also.

On 7/30/19 12:05 PM, Christian Glombek wrote:
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual
> package manager inside. You just have the container, mount the config,
> and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely
> a topic of overall interest!
>
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
>
> Christian Glombek
>
> Associate Software Engineer
>
> Red Hat GmbH 
>
> 
>
> cglom...@redhat.com 
>
> 
>
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn, 
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
>
>
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  > wrote:
>
> On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik  > wrote:
> >
> > Hi everyone!
> >
> > I'm starting a Minimization Objective [1] focusing on minimising
> the installation size of some of the popular apps, runtimes, and
> other pieces of software in Fedora.
> >
> > And there is a new Minimization Team [2] forming. Members of the
> team will consult and work with Fedora maintainers, develop
> tooling and services, generate reports showing the status of the
> Fedora ecosystem and a comparison with other ecosystems, etc. The
> goal is to build an environment where it's easy for our
> maintainers to keep things small over time, it's not just a
> one-off effort. Please see the Action Plan [3] for more details.
> >
> > Want to become a member? Let me know!
> >
> > Cheers!
> > Adam
> >
> > [1] https://docs.fedoraproject.org/en-US/minimization/
> > [2] https://docs.fedoraproject.org/en-US/minimization/team/
> > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
> >
>
> I'm interested, but not just for minimization for the sake of it. We
> need to be thoughtful about how we are changing the dependency tree.
>
>
>
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[Daniel Walsh]

On 7/11/19 7:57 PM, David Michael wrote:
> On Thu, Jul 11, 2019 at 5:22 PM Olivier Lemasle  wrote:
>> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
>>> I have orphaned moby-engine, the community Docker package in Fedora,
>>> due to no longer working in a role where I can maintain it as part of
>>> the job.  If anyone wants to take it, it is up to date in F30 and
>>> rawhide branches (F29 was not updated for compatibility since it
>>> doesn't enable SELinux), but there is an open issue that should be
>>> addressed before pushing new updates:  Docker 18.09 and later
>>> conflicts with runc and containerd since it dropped "docker-" prefixes
>>> from its binaries.  I can describe some options and backstory if
>>> needed, but I suppose you could address it however you want as the new
>>> maintainer.
>>>
>> I'm open to maintaining this package. However, what was the reason
>> "moby-engine" packaged its own version of runc and containerd, both
>> packaged on their own in Fedora?
> Each upstream Docker release targets a specific commit of each
> component (containerd, proxy, runc, and tini) specified at:
>
> https://github.com/docker/docker-ce/tree/v18.09.7/components/engine/hack/dockerfile/install
>
> These specific commits are basically considered part of the release;
> e.g. they are included in the Docker versions' release notes.  I'm not
> aware of the initial decision to bundle the components in the Fedora
> package since it was done that way from the beginning before I was a
> maintainer (I'd assume it was due to previous Docker versions using
> forks of the containerd and runc repos), but from experience
> maintaining it for another distro, upstream would send user bug
> reports back to you as the distro maintainer if there is any deviation
> from what they're shipping.  It might end up being less maintenance
> work by not unbundling the specified versions.
>
> Also, when I started maintaining it for Fedora, it was explained to me
> that moby-engine should follow upstream to provide an expected Docker
> experience on Fedora CoreOS (since any specialized container needs
> would be implemented in podman), but I don't think it is a priority
> for that team anymore.  You can probably do whatever you think is best
> at this point.
>
> Thanks.
>
> David
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

The problem is that the distribution is distributing a newer version of
runc then the moby-engine currently allows, and podman and Buildah take
advantage of newer features in the runc, therefore moby should not be
shipping its own /usr/bin/runc.  Since this blockes moby and podman
being installed at the same time. (Docker-ce does this as well, and is
wrong to do it.)

If Moby needs an older version of runc then is shipped by the
distribution then it should ship it's version under /usr/libexec


BTW I don't believe the Moby should exactly match Docker-ce, it should
follow the rules of fedora and hopefully be able to work with the other
packages of the distributions like runc/container-selinux etc.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[Daniel Walsh]

On 7/11/19 4:32 PM, Olivier Lemasle wrote:
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
>> I have orphaned moby-engine, the community Docker package in Fedora,
>> due to no longer working in a role where I can maintain it as part of
>> the job.  If anyone wants to take it, it is up to date in F30 and
>> rawhide branches (F29 was not updated for compatibility since it
>> doesn't enable SELinux), but there is an open issue that should be
>> addressed before pushing new updates:  Docker 18.09 and later
>> conflicts with runc and containerd since it dropped "docker-" prefixes
>> from its binaries.  I can describe some options and backstory if
>> needed, but I suppose you could address it however you want as the new
>> maintainer.
>>
> I'm open to maintaining this package. However, what was the reason
> "moby-engine" packaged its own version of runc and containerd, both
> packaged on their own in Fedora?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

They shouldn't, we have an open Bugzilla on that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Daniel Walsh]

On 7/8/19 11:00 AM, Neal Gompa wrote:
> On Mon, Jul 8, 2019 at 10:39 AM Daniel Walsh  wrote:
>> Their has not been much progress on runc development for this, which
>> might be a blocker.
>>
>> In the Podman/Buildah world, we have support for crun, an alternate OCI
>> Runtime replacement for runc.  crun supports cgroupsv2.
>>
>> There has been little movement in Kubernetes and OpenShift for adding
>> this support, but there has also been little incentive, since no OS Has
>> moved to it.
>>
>> Can systemd turn on the cgroupsv2 by default in Rawhide, to see what
>> complaints happen.
> I would be shocked if Fedora having it switched on would matter. We
> don't have a recent version of OpenShift or Kubernetes in our
> repositories...
>
It will also break Moby-Engine and Docker-ce.
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[Daniel Walsh]

On 7/3/19 6:50 PM, Stephen John Smoogen wrote:
>
>
> On Wed, 3 Jul 2019 at 17:15, Robert-André Mauchin  > wrote:
>
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
> > I have orphaned moby-engine, the community Docker package in Fedora,
> > due to no longer working in a role where I can maintain it as
> part of
> > the job.  If anyone wants to take it, it is up to date in F30 and
> > rawhide branches (F29 was not updated for compatibility since it
> > doesn't enable SELinux), but there is an open issue that should be
> > addressed before pushing new updates:  Docker 18.09 and later
> > conflicts with runc and containerd since it dropped "docker-"
> prefixes
> > from its binaries.  I can describe some options and backstory if
> > needed, but I suppose you could address it however you want as
> the new
> > maintainer.
> >
> > Thanks.
> >
> > David
>
>
> Wasn't there a « Container team » taking care of those packages?
>
>
> And there was a "Cloud team" and a "Server team" and a... there is no
> promise that said teams will last for any longer than the last
> interested person on it. 

Correct the Container Engine team is concentrating on Podman, Skopeo,
Buildah and CRI-O, as replacements of Docker.  We originally helped get
Moby Engine into Fedora, but need volunteers for ongoing maintenance.

>  
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> -- 
> Stephen J Smoogen.
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Daniel Walsh]

On 7/4/19 5:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 03, 2019 at 04:23:24PM -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/CGroupsV2
>>
>> == Summary ==
>> The kernel has had some support for CgroupsV2 for some time, and yet
>> no one has used it because it is not on by default.  There are lots of
>> new features and fixes over CgroupsV1 that it is time to reveal to the
>> user community.
>>
>> == Owner ==
>> * Name: [[User:dwalsh| Daniel J Walsh]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>> Enablement of the CgroupsV2 by default will allow tools like systemd,
>> container tools and libvirt to take advantage of the new features and
>> many fixes in Cgroups V1.  A lot of the functionality in VGroups V1
>> has been rewritten to fix fundamental flaws in its design.
>>
>> The reason CGroupsV2 by default has been blocked is that the Container
>> tools and someone the Virtualization tools did not have support.  We
>> believe that the time is right to try to move these tools along to
>> take advantage of this kernel feature. In order to begin testing these
>> features more widely we believe we need to have a platform like
>> Rawhide to test on and get others to test as well.
>>
>> The main features of CgroupsV2 we would like to take advantage of in
>> the container world is delegation of cgroup hierarchies.   Allowing
>> tools like podman to be able to use CGroups in rootless mode, would be
>> a large advance.
>>
>>
>> == Benefit to Fedora ==
>> Fedora is known for being a leading platform for the enablement of new
>> kernel functions, and this would continue its legacy.  The world will
>> eventually move to CGroupsV2 and Fedora should lead the way.
>>
>> == Scope ==
>> * Proposal owners:
>> The largest changes required to make this Change is to get containers
>> runtimes like RUNC to work with the change.  After RUNC has support
>> for CgroupsV2 we need to move container engines like Podman, CRI-o,
>> Buildah and Moby into support CgroupsV2.
>>
>> * Other developers:
>> We need to find other tools that have built the CGroupsV1 API into
>> themselves and get them to support CGroupsV2.
>>
>> Known packages:
>>
>> - libvirt: The team is already working on this.
>>
>> -  JVM:  Uses Cgroups file system to check for allocated memory for
>> the JVM, will have to use and understand the CgroupV2 mechanism to
>> discover these sessings.
>>
>> - Snap package does not run with CGroupV2:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1438079
>>
>> - Systemd will need to be modified to set the new default to cgroupv2
>>
>> * Release engineering: [https://pagure.io/releng/issue/8509 #8509]
>> * Policies and guidelines:
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> Any tools or scripts that an administrator used to manually configure
>> the CGroupsV1 will have to be modified to CGroupsV2.  Luckily if these
>> tools took advantage of systemd interfaces they should not require
>> changes.
>>
>> == How To Test ==
>> Make sure different tools that use cgroups continue to work when
>> booted into the new system.  Make sure containers, virtual machines
>> and the Jave Virtual Machine still work properly.  Convert the VM's of
>> the Container tools like CRI-O, Buildah, Podman for run on Rawhide and
>> make sure their test suites completely pass.  Will request that the
>> libvirt team and JVM teams similarly change their test platforms.
> Actually it's enough to set 'systemd.unified-cgroup-hierarchy' on the
> kernel command line to test. I think this should be mentioned, so
> people can test already in F29 or F30 or rawhide before the default is
> changed.
>
>> == User Experience ==
>> We believe that at this point their will be no or very little user
>> experience change, unless he is an administrator looking to modify the
>> system Cgroups using the cgroupsfs.
>>
>> One potential problem will be container images that expect to be
>> running in a CgroupV1 environment.  Some container engines leak the
>> Cgroup Hierarchy into containers so that tools within the container
>> can look at how much memory the cgroup gives them for example.  These
>> tools might break with the change, but they should be adjusted quickly
>> over time, and I don't really see a way to avoid this.
>>
>> == Dependencies ==
>> Currently there are no known changes to the package requirements for
>> this change.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: If the container tools and virtualization
>> tools do not work at beta and do not look like they will be ready for
>> beta freeze, then we revert to CgroupsV1 and try again in Fedora 32
>> * Contingency deadline: Beta Freeze
>> * Blocks release? Yes
> We know that cgroupv2 already (and for a long time...) works better
> than v1, so I'd rather make the switch unconditional, using the usual
> phrasing of "In the unlikely case catastrophic problems are discovered
> with v2, the default will be reverted 

Re: New mailing lists available for podman/libpod

[Daniel Walsh]

On 6/13/19 3:14 PM, Neal Gompa wrote:
> On Thu, Jun 13, 2019 at 3:13 PM Daniel Walsh  wrote:
>> Send an email to: podman-j...@lists.podman.io with the word "subscribe"
>> in the title, or by going to https://lists.podman.io and scrolling to
>> the bottom of that page to subscribe.
>>
> Could FAS login be added as a supported auth?
>
>
FAS Loging now supported.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New mailing lists available for podman/libpod

[Daniel Walsh]

On 6/13/19 3:14 PM, Neal Gompa wrote:
> On Thu, Jun 13, 2019 at 3:13 PM Daniel Walsh  wrote:
>> Send an email to: podman-j...@lists.podman.io with the word "subscribe"
>> in the title, or by going to https://lists.podman.io and scrolling to
>> the bottom of that page to subscribe.
>>
> Could FAS login be added as a supported auth?
>
>
It should be enabled now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

New mailing lists available for podman/libpod

[Daniel Walsh]

Send an email to: podman-j...@lists.podman.io with the word "subscribe"
in the title, or by going to https://lists.podman.io and scrolling to
the bottom of that page to subscribe.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?

[Daniel Walsh]

On 5/19/19 9:11 AM, Jun Aruga wrote:
> I am suggesting a new feature "podman buildx" like "docker buildx"
> that makes a better multi arch build experience.
> See below URL if you are interested in it.
>
> Supporting building multi-platform images (podman buildx)
> https://github.com/containers/buildah/issues/1590
>
I think this is something that the community would have to address, I
don't see it as a huge priority for the core developers at this point.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/17/19 3:50 PM, Ogas, Jordan Andrew wrote:
>
> > I am really interested in rootless podman as an alternative to
> Singularity,
>
> > And if there are any shortcomings.
>
>  
>
> One of the limitations we need to work around in our production
> environments
>
> is the inability to use setuid helpers, e.g., newuidmap and newgidmap.
>
> Unfortunately, container implementations with setuid helpers like
> Singularity
>
> (and perhaps Podman?) are not an option for our production clusters.
>
Not that this changes things much, but newuidmap and newgidmap use
FileCaps and thus

only have SETUID and SETGID respectively.

 getcap /usr/bin/new*idmap
/usr/bin/newgidmap = cap_setgid+ep
/usr/bin/newuidmap = cap_setuid+ep

>  
>
> Best,
>
> Jordan
>
>  
>
> *From: *Daniel Walsh 
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com" 
> *Date: *Friday, May 17, 2019 at 11:56 AM
> *To: *"Ogas, Jordan Andrew" , Development discussions
> related to Fedora 
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>  
>
> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>
> Not personally but my team are experimenting with Buildah/Podman.
>
> I am really interested in rootless podman as an alternative to
> Singularity, And if there are any shortcomings.
>
>  
>
> *From: *Daniel Walsh  <mailto:dwa...@redhat.com>
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com" <mailto:dwa...@redhat.com>
>  <mailto:dwa...@redhat.com>, Development
> discussions related to Fedora 
> <mailto:devel@lists.fedoraproject.org>
> *Date: *Thursday, May 16, 2019 at 2:23 PM
> *To: *"devel@lists.fedoraproject.org"
> <mailto:devel@lists.fedoraproject.org>
>  <mailto:devel@lists.fedoraproject.org>
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>  
>
> On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>
> Greetings,
>
>  
>
> My name is Jordan, I'm a member of the Programming and Runtime
> Environment
>
> team for the High Performance Computing Division (HPC) at the
> Los Alamos
>
> National Laboratory (LANL). I have been encouraged by my
> package reviewer,
>
> Dave Love, to introduce myself to the community in an effort
> to assimilate
>
> Fedora packaging culture and increase the likely hood of being
> sponsored.
>
>  
>
> It is my goal to become the official Charliecloud package
> maintainer and an expert
>
> in software packaging. The Charliecloud package under review
> is the first package
>
> I've ever created. Thus, I am hoping to find a sponsor who
> will be patient with me
>
> as I continue to grow and learn from my mistakes.
>
>  
>
> As a member of the PRE team at LANL I am responsible for
> testing and
>
> maintaining programming environments on a large collection of
> super computers
>
> with various specifications, e.g., hardware, architecture
> (hello aarch64),
>
> interconnects, size, etc. I spend a lot of time contributing
> to LANL's novel
>
> unprivileged Linux container runtime, Charliecloud.
>
> Have you experimented and played with rootless podman?
>
>
>  
>
> Outside of work you can usually find me relaxing with my wife
> or taming
>
> dinosaurs and dying to piranhas in the video game 'Ark:
> Survival Evolved' with
>
> my 9 year old son.
>
>  
>
> Package under review (in need of sponsorship):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>
>  
>
> Best,
>
>  
>
> Jordan Ogas
>
>
>
>
> ___
>
> devel mailing list -- devel@lists.fedoraproject.org 
> <mailto:devel@lists.fedoraproject.org>
>
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> <mailto:devel-le...@lists.fedoraproject.org>
>
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
>
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>  
>
>  
>

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/17/19 2:34 PM, Jonathan Billings wrote:
> On Fri, May 17, 2019 at 01:56:20PM -0400, Daniel Walsh wrote:
>> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>>> Not personally but my team are experimenting with Buildah/Podman.
>>>
>> I am really interested in rootless podman as an alternative to
>> Singularity, And if there are any shortcomings.
> As far as I know, rootless containers with podman require populating
> entries for each user in /etc/sub{uid,gid}, which isn't currently
> something easy to do if you have your users coming from sssd-ldap or
> sssd-ad.  Those files are updated when using useradd though, but it
> doesn't scale up to tens of thousands of users, particularly when the
> user list changes daily.
>
Yes I have open bug reports with the glibc/gcc teams to add nssswitch
support for those files.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>
> Not personally but my team are experimenting with Buildah/Podman.
>
I am really interested in rootless podman as an alternative to
Singularity, And if there are any shortcomings.
>
>  
>
> *From: *Daniel Walsh 
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com" , Development
> discussions related to Fedora 
> *Date: *Thursday, May 16, 2019 at 2:23 PM
> *To: *"devel@lists.fedoraproject.org" 
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>  
>
> On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>
> Greetings,
>
>  
>
> My name is Jordan, I'm a member of the Programming and Runtime
> Environment
>
> team for the High Performance Computing Division (HPC) at the Los
> Alamos
>
> National Laboratory (LANL). I have been encouraged by my package
> reviewer,
>
> Dave Love, to introduce myself to the community in an effort to
> assimilate
>
> Fedora packaging culture and increase the likely hood of being
> sponsored.
>
>  
>
> It is my goal to become the official Charliecloud package
> maintainer and an expert
>
> in software packaging. The Charliecloud package under review is
> the first package
>
> I've ever created. Thus, I am hoping to find a sponsor who will be
> patient with me
>
> as I continue to grow and learn from my mistakes.
>
>  
>
> As a member of the PRE team at LANL I am responsible for testing and
>
> maintaining programming environments on a large collection of
> super computers
>
> with various specifications, e.g., hardware, architecture (hello
> aarch64),
>
> interconnects, size, etc. I spend a lot of time contributing to
> LANL's novel
>
> unprivileged Linux container runtime, Charliecloud.
>
> Have you experimented and played with rootless podman?
>
>  
>
> Outside of work you can usually find me relaxing with my wife or
> taming
>
> dinosaurs and dying to piranhas in the video game 'Ark: Survival
> Evolved' with
>
> my 9 year old son.
>
>  
>
> Package under review (in need of sponsorship):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>
>  
>
> Best,
>
>  
>
> Jordan Ogas
>
>
>
> ___
>
> devel mailing list -- devel@lists.fedoraproject.org 
> <mailto:devel@lists.fedoraproject.org>
>
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> <mailto:devel-le...@lists.fedoraproject.org>
>
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>  
>

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>
> Greetings,
>
>  
>
> My name is Jordan, I'm a member of the Programming and Runtime Environment
>
> team for the High Performance Computing Division (HPC) at the Los Alamos
>
> National Laboratory (LANL). I have been encouraged by my package reviewer,
>
> Dave Love, to introduce myself to the community in an effort to assimilate
>
> Fedora packaging culture and increase the likely hood of being sponsored.
>
>  
>
> It is my goal to become the official Charliecloud package maintainer
> and an expert
>
> in software packaging. The Charliecloud package under review is the
> first package
>
> I've ever created. Thus, I am hoping to find a sponsor who will be
> patient with me
>
> as I continue to grow and learn from my mistakes.
>
>  
>
> As a member of the PRE team at LANL I am responsible for testing and
>
> maintaining programming environments on a large collection of super
> computers
>
> with various specifications, e.g., hardware, architecture (hello aarch64),
>
> interconnects, size, etc. I spend a lot of time contributing to LANL's
> novel
>
> unprivileged Linux container runtime, Charliecloud.
>
Have you experimented and played with rootless podman?
>
>  
>
> Outside of work you can usually find me relaxing with my wife or taming
>
> dinosaurs and dying to piranhas in the video game 'Ark: Survival
> Evolved' with
>
> my 9 year old son.
>
>  
>
> Package under review (in need of sponsorship):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>
>  
>
> Best,
>
>  
>
> Jordan Ogas
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: module load inside rpmbuild inside docker

[Daniel Walsh]

On 5/3/19 6:00 PM, Christoph Junghans wrote:
> Hi,
>
> I wanted to bump the legion package to 19.04.0
> (https://bugzilla.redhat.com/show_bug.cgi?id=1705033), however for
> some reason all tests segfault with openmpi
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=34577005), so I
> reported this upstream
> (https://github.com/StanfordLegion/legion/issues/533) and included a
> minimal dockerfile to reproduce this issue:
>
> FROM fedora:rawhide
> RUN dnf install -y spectool wget rpm-build dnf-plugins-core
> RUN wget 
> https://src.fedoraproject.org/fork/junghans/rpms/legion/raw/master/f/legion.spec
> RUN spectool -g legion.spec
> RUN dnf builddep -y legion.spec
> RUN dnf install -y make
> RUN rpmbuild -D"_sourcedir ${PWD}" -D"_srcrpmdir ${PWD}" -ba legion.spec
>
> This worked fine on Thursday(?) to reproduce the failing tests in
> %check, but now rpmbuild fails at an earlier stage with:
> + module load mpi/mpich-x86_64
> ++ /usr/share/lmod/lmod/libexec/lmod sh load mpi/mpich-x86_64
> Lmod has detected the following error: The following module(s) are unknown:
> "mpi/mpich-x86_64"
>
> If I jump into the container interactively (docker run -it ..
> /bin/bash), "module load" as well as rpmbuild (and "module load"
> inside) works.
>
> If know this is a convoluted case, but any ideas how fix this?
>
> Christoph
>
>
Are you running a privileged container in one case and not in the
other.  Normal running of containers should not allow you to load a
kernel module.


BTW Have you tried this with Podman?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

[Daniel Walsh]

On 2/15/19 7:02 AM, Lennart Poettering wrote:
> On Fr, 15.02.19 12:55, Zygmunt Krynicki (m...@zygoon.pl) wrote:
>
>> I’m happy to work on this issue once it becomes „pressing” and once
>> the prerequisites are available. If F30 disables v1 entirely and has
>> a kernel where we can get device, freezer and pid controllers then
>> it’s „just” a matter of coding.
> The kernel will support both modes for a long time I figure. And so
> will systemd. You can switch between both modes at boot time through a
> kernel cmdline option, and the change for F30 would be to just default
> to a different setting.
This is for F31 NOT F30.
>
> Note that in cgroupsv2 mode systemd will not mount the cgroupv1
> hierchies at all. (You can mount them yourself if you want to
> though. For example, systemd-nspawn can optionally provide cgroupsv1
> to container payloads on cgroupsv2 hosts, by simply mounting the
> name=systemd hierarchy into the container anyway)
>
> The "devices" cgroup controller is generally not available on
> cgroupsv2. However, there's now a set of bpf hook-ups that you can use
> instead and provide pretty much equivalent functionality. (systemd
> supports them already).
Awesome.
> The "freezer" cgroup controller is not available yet on cgroupsv2. But
> this is likely going to change soon, but it will be core cgroupsv2
> functionality, not a controller of its own. Until the freezer becomes
> available it should be completely fine to simply use SIGSTOP instead,
> semantics are not that different.
Yes I was told that it just missed getting into the 5.0 kernel, and
should be in the 5.1 kernel.
> The "pids" controllers has been available on cgroupsv2 since day one
> basically, at the same day it was introduced for cgroupsv1.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

[Daniel Walsh]

On 2/15/19 6:55 AM, Zygmunt Krynicki wrote:
>
>
>> Wiadomość napisana przez Neal Gompa > <mailto:ngomp...@gmail.com>> w dniu 15.02.2019, o godz. 12:51:
>>
>> On Fri, Feb 15, 2019 at 4:11 AM Zbigniew Jędrzejewski-Szmek
>> mailto:zbys...@in.waw.pl>> wrote:
>>>
>>> On Thu, Feb 14, 2019 at 08:10:09AM -0500, Daniel Walsh wrote:
>>>> I have opened a Change Request to change the defaults for Fedora 31 to
>>>> Cgroups V2.  I am looking for what packages will be affected by this
>>>> change.   Basically any package that adjusts Cgroups via the CgroupFS,
>>>> my understanding is working the the systemd APIs, you should be fine.
>>>>
>>>> Packages That I know will be affected:
>>>>
>>>> Container Tools
>>>>
>>>> * Runc, Podman, Buildah, Kubernetes, Docker, Moby-engine
>>>>
>>>> Virtualization tools
>>>>
>>>> * Libvirt
>>>>
>>>> Java
>>>>
>>>> * jvm
>>>>
>>>> Install
>>>>
>>>> * Anaconda
>>>>
>>>>
>>>> Anyone know of other packages?
>>>
>>> Great news!
>>>
>>> Can you briefly summarize the status / plans / timelines for the
>>> affected components?
>>> (Apart from anaconda, which doesn't need changes, we'll just flip the
>>> default in systemd, as discussed in the other subthread.)
>>>
>>
>> snapd will break in cgroupv2 mode:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1438079
>>
>> I don't know of anyone working on fixing that…
>
>
> I think the stance of the snapd team is that once v2 supports freezer
> we can have a look at adding the support.
>
Freezer is supposed to go into Kernel 5.1, I have been told.
> There’s a snapd bug tracking this as
> well: https://bugs.launchpad.net/snapd/+bug/1801664
>
> I’m happy to work on this issue once it becomes „pressing” and once
> the prerequisites are available. If F30 disables v1 entirely and has a
> kernel where we can get device, freezer and pid controllers then it’s
> „just” a matter of coding.
>
Device Cgroup is supposed to be done in eBPF, and systemd has an
implementation I believe.

This is for F31 NOT f30.  Also you will be able to boot the machine in
V1 mode. We are just talking about the default here.

> Best regards
> ZK
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

[Daniel Walsh]

On 2/14/19 10:49 AM, Daniel P. Berrangé wrote:
> On Thu, Feb 14, 2019 at 08:10:09AM -0500, Daniel Walsh wrote:
>> I have opened a Change Request to change the defaults for Fedora 31 to
>> Cgroups V2.  I am looking for what packages will be affected by this
>> change.   Basically any package that adjusts Cgroups via the CgroupFS,
>> my understanding is working the the systemd APIs, you should be fine.
>>
>> Packages That I know will be affected:
>>
>> Container Tools
>>
>> * Runc, Podman, Buildah, Kubernetes, Docker, Moby-engine
>>
>> Virtualization tools
>>
>> * Libvirt
>>
>> Java
>>
>> * jvm
>>
>> Install
>>
>> * Anaconda
>>
>> Anyone know of other packages?
> What is the expectation of compatibility for applications running inside
> containers ?
>
> Historically any running containers will see a v1 hierarchy inside their
> container. If the host is switched to v2, then presumably applications
> inside the container will also see a v2 layout.
>
> The wiki page says tools/scripts would be unaffected if they had used
> the systemd interface to access cgroups. This won't apply to tools
> or scripts inside the container though as the containers rarely run
> systemd inside.
>
> If this is correct, then even if all software in Fedora supports v2,
> users might still see breakage of applications they are running in
> containers on Fedora.
>
> Admittedly the set of things likely to be affected in this way is probably
> fairly small, but it feels like something that should be described in
> the change page on the wiki.
>
> Regards,
> Daniel
Good point.

I will update the Change with a comment on this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

[Daniel Walsh]

Ok I guess this will not effect anaconda, just affect systemd.

On 2/14/19 1:58 PM, Daniel Walsh wrote:
> On 2/14/19 9:55 AM, jkone...@redhat.com wrote:
>> Hi Dan,
>>
>> How the Anaconda will be affected? I'm not aware of any cgroups control
>> from Anaconda side or do we need change something to the installed
>> system to enable v2 cgroups?
>>
>> Thanks for answers,
>> Jirka
> It will need to change the default kernel option to enable it.
>> On Thu, 2019-02-14 at 08:10 -0500, Daniel Walsh wrote:
>>> I have opened a Change Request to change the defaults for Fedora 31
>>> to
>>> Cgroups V2.  I am looking for what packages will be affected by this
>>> change.   Basically any package that adjusts Cgroups via the
>>> CgroupFS,
>>> my understanding is working the the systemd APIs, you should be fine.
>>>
>>> Packages That I know will be affected:
>>>
>>> Container Tools
>>>
>>> * Runc, Podman, Buildah, Kubernetes, Docker, Moby-engine
>>>
>>> Virtualization tools
>>>
>>> * Libvirt
>>>
>>> Java
>>>
>>> * jvm
>>>
>>> Install
>>>
>>> * Anaconda
>>>
>>>
>>> Anyone know of other packages?
>>>
>>>
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: 
>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

[Daniel Walsh]

On 2/14/19 9:55 AM, jkone...@redhat.com wrote:
> Hi Dan,
>
> How the Anaconda will be affected? I'm not aware of any cgroups control
> from Anaconda side or do we need change something to the installed
> system to enable v2 cgroups?
>
> Thanks for answers,
> Jirka
It will need to change the default kernel option to enable it.
> On Thu, 2019-02-14 at 08:10 -0500, Daniel Walsh wrote:
>> I have opened a Change Request to change the defaults for Fedora 31
>> to
>> Cgroups V2.  I am looking for what packages will be affected by this
>> change.   Basically any package that adjusts Cgroups via the
>> CgroupFS,
>> my understanding is working the the systemd APIs, you should be fine.
>>
>> Packages That I know will be affected:
>>
>> Container Tools
>>
>> * Runc, Podman, Buildah, Kubernetes, Docker, Moby-engine
>>
>> Virtualization tools
>>
>> * Libvirt
>>
>> Java
>>
>> * jvm
>>
>> Install
>>
>> * Anaconda
>>
>>
>> Anyone know of other packages?
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: 
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FYI https://fedoraproject.org/wiki/Changes/CGroupsV2

[Daniel Walsh]

I have opened a Change Request to change the defaults for Fedora 31 to
Cgroups V2.  I am looking for what packages will be affected by this
change.   Basically any package that adjusts Cgroups via the CgroupFS,
my understanding is working the the systemd APIs, you should be fine.

Packages That I know will be affected:

Container Tools

* Runc, Podman, Buildah, Kubernetes, Docker, Moby-engine

Virtualization tools

* Libvirt

Java

* jvm

Install

* Anaconda


Anyone know of other packages?



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I will be giving a Fedora Classroom on Tuesday at 11:00 EST on Buildah

[Daniel Walsh]

Building Container Images with Buildah.

https://fedoramagazine.org/fedora-classroom-building-container-images-with-buildah/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

pam_cgfs.so support for Fedora?

[Daniel Walsh]

Has anyone looked at supporting pam_cgfs.so in Fedora.

This question was asked here.

https://github.com/containers/libpod/issues/1429

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Starting a Container SIG

[Daniel Walsh]

On 07/25/2018 01:09 PM, Clement Verna wrote:

Greeting all,

The container effort in Fedora has until now been looked after by the
Atomic WG, since this Working Group is now going to focus mostly on
Fedora CoreOS, I propose to create a new container SIG to regroup
people interested in the maintenance of application containers in
Fedora.

This SIG would look after the container guidelines [0], the container
review process [1] and also the release process and tooling.

Please Reply if you're interested with helping out making the
Container story great in Fedora. If there is a good response, I will
create a Container SIG wiki page, and I guess we can ask for
container-devel mailing list for SIG discussions.

Regards,
Clément

[0] - https://fedoraproject.org/wiki/Container:Guidelines
[1] - https://fedoraproject.org/wiki/Container:Review_Process
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/55QK4AYKBFGLFXCGAVJSXLEVEMC5NJQ2/


I would be willing to help.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6M5LS6Y7YKEUKOC7TE52WN37ETSAJFTX/

Re: In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.

[Daniel Walsh]

On 06/29/2018 10:03 AM, Nicolas Mailhot wrote:

Le 2018-06-29 14:31, Daniel Walsh a écrit :

Hi,


Users of OpenSHift Origin require CRI-O 1.10 right now.  But
Kubernetes users want to try out the latest packages for kubernetes
1.11 which would require CRI-O 1.11.  Origin might not be ready to
move to Kubernetes 1.11 for a while.

Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.*
releases in the same Fedora 28.


I actively don't care what version you choose as long as the 
kubernetes/dockers/whatever stack you settle on is done with proper 
srpms that expose in a clean -devel package Go source code that can be 
used to build any other Go software that wants to integrate with them. 
IE make them proper distro components the rest of the distro can work 
upon, not selfish binaries that care nothing about the rest of the 
Fedora universe.


Regards,

Right, I think there should be a Kubernetes 1.11 module and a kubernetes 
1.12 module, and in these modules we would have the appropriate 
kubernetes/CRI-O/crictl (Potentially docker and other packages)



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OVLR7HLIDZTELWJOFBNC7Z6WHLRO7ZGU/

In the OpenShift Origin/CRI-O/Kubernetes effort we have a dilemma.

[Daniel Walsh]

Users of OpenSHift Origin require CRI-O 1.10 right now.  But Kubernetes 
users want to try out the latest packages for kubernetes 1.11 which 
would require CRI-O 1.11.  Origin might not be ready to move to 
Kubernetes 1.11 for a while.


Bottom line we want to be able to ship CRI-0 1.10.* and CRI-O 1.11.* 
releases in the same Fedora 28.


I believe this is what Modularity was designed to fix.

Can I do this with Modularity?  If I can how do I use fedpkg to make 
this happen?


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4ZIWOOJIKBPCL57H5WBYUYH6VBL2GT73/

Re: systemd in non-privileged container

[Daniel Walsh]

On 04/30/2018 10:42 AM, James Hogarth wrote:

On 27 April 2018 at 17:47, Pavel Raiskup  wrote:

On Friday, April 27, 2018 5:41:19 PM CEST Lennart Poettering wrote:

On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) wrote:


Hi all,

just wanted to let you know about trivial experiment [1] with systemd in
container.  Non-privileged systemd can now pretty fine run in docker
container (tested on Fedora 27 box).

Hmm, IIRC there were at least two isues still, did they get resolved?
Specifically:

1. docker fakes a /dev/console that doesn't behave like a console
usually works, i.e. if a hangup is seen on it then it will destroy
the pty behind it, instead of keeping it around...

There't toy work-around to have at least something:
https://github.com/praiskup/systemd-container/blob/master/fedora-rawhide-x86_64/systemd

Pavel


2. docker sends SIGTERM to the container's PID 1 when it wants it to
go down even though SIGTERM to PID 1 on SysV systems generally
means "please reexecute", and not "please shut down".

What's the current state on that?


Did a bunch of related activities at my work recently ...

If you are using Red Hat docker (eg from the RHEL/CentOS extras repo)
then this will get a systemd container running for you:

Dockerfile:
FROM centos:7
ENV container docker
STOPSIGNAL SIGRTMIN+3
ENTRYPOINT ["/sbin/init"]
RUN yum -y update && yum clean all

Run statement:
docker run -dt --name mycontainer mysystemdimage

If you are using upstream docker then you need to do the following:
mkdir /etc/docker
echo '{"seccomp-profile": "/etc/docker/seccomp.json"}' > /etc/docker/daemon.json
wget -O /etc/docker/seccomp.json
https://src.fedoraproject.org/rpms/docker/raw/master/f/seccomp.json

Same dockerfile

Run statement:
docker run -dt --tmpfs /tmp:exec --tmpfs /run -v
/sys/fs/cgroup:/sys/fs/cgroup:ro --name mycontainer mysystemdimage

___

The real problem here is docker engines you don't control as the
seccomp filter is a potential blocker and potentially the run mount
options
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Perhaps it is time to update my blog on running systemd in a 
unprivileged container.

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

I would like to propose that we turn on XFS Reflink in Fedora 29 by default

[Daniel Walsh]

We are adding some features to container projects for User Namespace 
support that can take advantage of XFS Reflink.  I have talked to some 
of the XFS Reflink kernel engineers in Red Hat and they have informed me 
that they believe it is ready to be turned on by default.


I am not sure who in Red Hat I should talk to about this? Whether we 
should turn it on in the installer or in the mkfs.xfs command?


Who should I be talking to?  To make this happen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd in non-privileged container

[Daniel Walsh]

On 04/27/2018 11:41 AM, Lennart Poettering wrote:

On Fr, 27.04.18 17:27, Pavel Raiskup (prais...@redhat.com) wrote:


Hi all,

just wanted to let you know about trivial experiment [1] with systemd in
container.  Non-privileged systemd can now pretty fine run in docker
container (tested on Fedora 27 box).

Hmm, IIRC there were at least two isues still, did they get resolved?
Specifically:

1. docker fakes a /dev/console that doesn't behave like a console
usually works, i.e. if a hangup is seen on it then it will destroy
the pty behind it, instead of keeping it around...
First off this is not a Docker issue, it is a runc and OCI Runtime 
issue.  I am not sure if this is fixed or not at this point.

2. docker sends SIGTERM to the container's PID 1 when it wants it to
go down even though SIGTERM to PID 1 on SysV systems generally
means "please reexecute", and not "please shut down".
The container runtimes can specify a stop signal, so as long as you 
specify the correct stop signal when creating your systemd based image, 
everything should work properly.


NOTE you need to have oci-systemd-hook installed, and the container 
runtime needs to be able support OCI Runtime hooks.


podman, CRI-O and ProjectAtomic/Docker all support them.  Upstream 
Docker does NOT.



What's the current state on that?

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


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

Re: F28 Self Contained Change: Atomic, Cloud and Docker images for s390x

[Daniel Walsh]

On 02/09/2018 03:13 AM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Feb 05, 2018 at 12:20:09PM +0530, Sinny Kumari wrote:

On Fri, Feb 2, 2018 at 8:25 PM, Daniel Walsh <dwa...@redhat.com> wrote:

Not yet.  We are working on packaging podman which would give users the same
experience as Docker CLI without requiring a Daemon.  That would be the
thing to replace

Thanks Dan! Nice to know about podman.

What's the status here? I don't see podman in
http://fedoraproject.org/PackageReviewStatus/NEW.html, is it possible
to track the packaging effort somewhere?

Zbyszek


Podman/libpod should be packaged for Fedora 27/28 now.


dnf install podman --enablerepo=updates-testing
Fedora 27 - x86_64 - Test Updates   1.4 MB/s | 3.4 MB 00:02
Last metadata expiration check: 0:00:01 ago on Sat 10 Feb 2018 07:03:36 
AM EST.

Dependencies resolved.

 Package Arch    Version Repository    Size

Installing:
 podman  x86_64  0-0.3.git367213a.fc27 updates-testing  9.9 M

Transaction Summary

Install  1 Package

Total download size: 9.9 M
Installed size: 47 M
Is this ok [y/N]: y
Downloading Packages:
podman-0-0.3.git3672 24% [-   ] 490 kB/s | 2.4 MB 
00:15 ETA

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

Re: F28 Self Contained Change: Atomic, Cloud and Docker images for s390x

[Daniel Walsh]

On 01/31/2018 06:26 PM, Josh Boyer wrote:

On Tue, Jan 30, 2018 at 12:42 PM, Daniel Walsh <dwa...@redhat.com> wrote:

On 01/30/2018 11:50 AM, Jan Kurik wrote:

= Proposed Self Contained Change: Atomic, Cloud and Docker images for
s390x =

https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for_s390x

Change owner(s):
* Sinny Kumari 


This change is to bring s390x architecture closer to other Fedora
architectures by adding widely used Fedora variants. This includes
docker images, Atomic Host (iso, qcow2 and raw format) and regular
Cloud Images (qcow2 and raw format).


== Detailed Description ==
We already ship Atomic, Cloud and Docker images on other 64-bit Fedora
supported architectures- aarch64, x86_64 and ppc64le. With Fedora 27,
s390x is part of primary koji build system. Currently, we only ship
Server and Everything variants for s390x. So, our next steps should be
to have missing Fedora variants on s390x architecture which users will
find useful. This brings in shipping Atomic, Cloud and Docker images
in Fedora for s390x as well.


== Scope ==
* Proposal owners:
These are isolated changes which doesn't impact existing Fedora 28
release plan on s390x. To have these changes ready to ship in Fedora
28, we mainly require s390x koji builders configured to run these
composes, changes in pungi configuration [
https://pagure.io/pungi-fedora/pull-request/496 ] to enable the
additional compose and fixing s390x specific issues encountered when
compose fails to run.

* Other developers:
Changes in Fedora infrastructure configs/scripts will be required to
have s390x builders configured to run additional composes. Fedora
Infrastructure issue [
https://pagure.io/fedora-infrastructure/issue/6659 ] has been filed to
keep track of required changes to be done.

* Release engineering:
#Releng 7286: https://pagure.io/releng/issue/7286

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)


You mean OCI Images...

Mostly likely, yes.

Relatedly, has there been a change request to move the default
container runtime to cri-o or runc or rkt or anything other than
docker in Fedora Atomic?  If so, that will be neat and I'm sorry I
missed it.  If not, why not?

Not yet.  We are working on packaging podman which would give users the same
experience as Docker CLI without requiring a Daemon.  That would be the 
thing to replace
Docker if we went that way.  CRI-O != Docker.  It does not have any of 
the CLI that users would expect.

Rkt is dead in my opinion.  runc is on Atomic host now, I believe.



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


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

Re: F28 Self Contained Change: Atomic, Cloud and Docker images for s390x

[Daniel Walsh]

On 01/30/2018 11:50 AM, Jan Kurik wrote:

= Proposed Self Contained Change: Atomic, Cloud and Docker images for s390x =
https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for_s390x

Change owner(s):
* Sinny Kumari 


This change is to bring s390x architecture closer to other Fedora
architectures by adding widely used Fedora variants. This includes
docker images, Atomic Host (iso, qcow2 and raw format) and regular
Cloud Images (qcow2 and raw format).


== Detailed Description ==
We already ship Atomic, Cloud and Docker images on other 64-bit Fedora
supported architectures- aarch64, x86_64 and ppc64le. With Fedora 27,
s390x is part of primary koji build system. Currently, we only ship
Server and Everything variants for s390x. So, our next steps should be
to have missing Fedora variants on s390x architecture which users will
find useful. This brings in shipping Atomic, Cloud and Docker images
in Fedora for s390x as well.


== Scope ==
* Proposal owners:
These are isolated changes which doesn't impact existing Fedora 28
release plan on s390x. To have these changes ready to ship in Fedora
28, we mainly require s390x koji builders configured to run these
composes, changes in pungi configuration [
https://pagure.io/pungi-fedora/pull-request/496 ] to enable the
additional compose and fixing s390x specific issues encountered when
compose fails to run.

* Other developers:
Changes in Fedora infrastructure configs/scripts will be required to
have s390x builders configured to run additional composes. Fedora
Infrastructure issue [
https://pagure.io/fedora-infrastructure/issue/6659 ] has been filed to
keep track of required changes to be done.

* Release engineering:
#Releng 7286: https://pagure.io/releng/issue/7286

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)


You mean OCI Images...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Rename "nobody" user

[Daniel Walsh]

On 01/13/2018 10:18 AM, Steve Dickson wrote:

On 01/13/2018 08:50 AM, Steve Dickson wrote:

So I guess the next question is what the current
nobody id (25) used for and why does it exist?

Doing some research on this back in Aug 2001
nfsnobody was added to nfs-utils for the reasons stated in
https://bugzilla.redhat.com/show_bug.cgi?id=22685

Basically they were concern about changing the
uid value of the current 'nobody' account.

Why? IDK...

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


It is good to see that 17 years later we are arguing about the same 
thing.  :^)

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

Re: F28 System Wide Change: Rename "nobody" user

[Daniel Walsh]

On 01/12/2018 10:41 AM, Steve Dickson wrote:


On 01/12/2018 09:47 AM, Lennart Poettering wrote:

On Fr, 12.01.18 09:28, Steve Dickson (ste...@redhat.com) wrote:


User namespacing is a Linux kernel feature. It's most well known
consumers are probably Docker, and maybe flatpak/bubblewrap and LXC.

Well know for how long?

The commit adding user namespaces to the Linux kernel was in 2007. 11
years ago, in kernel 2.6.23.

Wow... we've been living this way a long time... Seemly without any problems?
If that is the case then I really don't see a need for this change
that could potentially cause such havoc.
Having this in the kernel and actually anyone using it are two different 
things.  We are just beginning to finally use this now.
  

It's not systemd that came up with reusing 65534 for user
namespacing. It's kernel people:

 $ cat /proc/sys/kernel/overflowuid
 65534

How was that number chosen and why can't be changed?

It's conceptually the same thing: it's where UIDs are mapped that
cannot be mapped properly otherwise.

Right... I'm assuming this overflow almost never happens
from looking at the code.
Well in UserNamespace it happens all the time.  Basically any Inode that 
is owned by a uid that is not mapped in the usernamespace will be 
reported as this UID.

In theory you can change it by echoing something into sysctl, but
that's mostly theoretic, and not what the various consumers of userns
do.

Understood.


And regardless, it's conceptually the same thing anyway, so it makes a
ton of sense to use the UID there for both NFS and userns
purposes. While I have my reservations about userns in general the
logic behind using that UID for this purpose is very clear to me and
makes sense as far as I can see.


So the problem trying to be solved is when the overflow uid/gid
are used (which is rarely), the owner of the file become
nfsnobody which does not make any sense because it is on a local filesystem.

It is not rare.

If this is the case, my I suggest that since the overflow uid/gid is
basically an arbitrary value and easily changeable... Why not
have some boot process echo '99' into /proc/sys/kernel/overflowuid
which would match nicely to a uid/gid of a user named 'nobody'?

You would force everyone everwhere to make this change.

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


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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/06/2017 10:14 AM, Mark Wielaard wrote:

On Mon, 2017-09-18 at 16:48 +0200, Tomas Tomecek wrote:

we managed to move tools container from Fedora Dockerfiles github
repo to Fedora infra [1]. As a side effects, we put systemtap in a
dedicated container.

We would very much appreciate your feedback here

What determines what goes into tools and what in a separate container
(like systemtap). I see the tools container has strace, gcc, gdb, perf,
etc. But not other development tools like binutils, elfutils and
valgrind. Will those be added or will they come in some separate
container?

Thanks,

Mark

Right now there is a an effort going on to shrink the tools container, 
it has grown huge.


I would prefer you create a debug container and put all of these tools 
in there.

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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:55 PM, Frank Ch. Eigler wrote:

Hi, Dan -

On Thu, Oct 05, 2017 at 01:49:48PM -0400, Daniel Walsh wrote:

[...]
But really for something like this, it would be better to just run
it --privileged.  There is [no] security confinement present in what
you are doing.

Yup.  I thought "atomic run --spc" would imply "docker run --privileged"
but it doesn't seem to.

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


No it looks like it is just running the label that is in the container 
image.

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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:47 PM, Frank Ch. Eigler wrote:

Hi, Dan -



Could you show the docker line that atomic run is executing?

% atomic run --spc candidate-registry.fedoraproject.org/f26/systemtap 
/usr/share/systemtap/examples/io/iotop.stp
docker run --cap-add SYS_MODULE -v /sys/kernel/debug:/sys/kernel/debug -v 
/usr/src/kernels:/usr/src/kernels -v /usr/lib/modules/:/usr/lib/modules/ -v 
/usr/lib/debug:/usr/lib/debug -t -i --name systemtap-spc 
candidate-registry.fedoraproject.org/f26/systemtap 
/usr/share/systemtap/examples/io/iotop.stp

... which fails.  But a hand-run % docker run, with "--security-opt
label:disable" added in the front works for me.



The LABEL would be the preferred way.

Sure, just someone(tm) needs to find the Dockerfile in git.  I
couldn't find it from a dozen minutes reading
https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
and pals.


- FChE


But really for something like this, it would be better to just run it 
--privileged.  There is on security confinement present in what you are 
doing.

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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:38 PM, Jeremy Eder wrote:

I don't see any avc when it fails while label:disable is set.
I ran semodule -DB and retried.  I now see dontaudit stuff but still 
no interesting denials.


I'm not sure if you were talking to me or Frank with the atomic 
command line...


I pulled the label out docker inspect on the systemtap image so I can 
run it manually.  Here is what I am running.

All I have added is the --security-opt label:disable part.

# docker run --security-opt label:disable --cap-add SYS_ADMIN -v 
/sys/kernel/debug:/sys/kernel/debug -v 
/usr/src/kernels:/usr/src/kernels -v 
/usr/lib/modules/:/usr/lib/modules/ -v /usr/lib/debug:/usr/lib/debug 
-t -i --name systemtap 
candidate-registry.fedoraproject.org/f26/systemtap 
<http://candidate-registry.fedoraproject.org/f26/systemtap>



Should be SYS_MODULE not SYS_ADMIN or maybe both.

I also tried with --security-opt seccomp:unconfimed.  That did not help.

Adding --privileged to the above command line, and systemtap works.

This is likely the key difference between why systemtap has always 
worked in the rhel-tools container...the label on that image includes 
--privileged.




On Thu, Oct 5, 2017 at 1:25 PM, Daniel Walsh <dwa...@redhat.com 
<mailto:dwa...@redhat.com>> wrote:


On 10/05/2017 01:18 PM, Jeremy Eder wrote:

setenforce 0 works...security-opt label:disable does not.

On Thu, Oct 5, 2017 at 1:06 PM, Daniel Walsh <dwa...@redhat.com
<mailto:dwa...@redhat.com>> wrote:

On 10/05/2017 01:00 PM, Frank Ch. Eigler wrote:

wcohen forwarded:

[...]

 [root@dhcp23-91 ~]# atomic run --spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
 docker run --cap-add SYS_MODULE -v
/sys/kernel/debug:/sys/kernel/debug -v
/usr/src/kernels:/usr/src/kernels -v
/usr/lib/modules/:/usr/lib/modules/ -v
/usr/lib/debug:/usr/lib/debug -t -i --name
systemtap-spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
  [...]
 ERROR: Couldn't insert module

'/tmp/stapNEjJDX/stap_4f013e7562b546a0316af840de9f0713_8509.ko':
Operation not permitted
[...]

I bet
# setenforce 0
makes it work for you.  As per audit.log:

type=AVC msg=audit(1507222590.683:7940): avc:  denied  {
module_load }
for  pid=7595 comm="staprun"
scontext=system_u:system_r:container_t:s0:c534,c921
tcontext=system_u:system_r:container_t:s0:c534,c921
tclass=system permissive=1


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>


Rather then putting the system into permissive mode, you
should run a privileged container or at least disable SELinux
protections.


docker run -ti --security-opt label:disable ...





-- 


-- Jeremy Eder


Could you show me the AVC you get when you do the label:disable?





--

-- Jeremy Eder



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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:18 PM, Jeremy Eder wrote:

setenforce 0 works...security-opt label:disable does not.

On Thu, Oct 5, 2017 at 1:06 PM, Daniel Walsh <dwa...@redhat.com 
<mailto:dwa...@redhat.com>> wrote:


On 10/05/2017 01:00 PM, Frank Ch. Eigler wrote:

wcohen forwarded:

[...]

   [root@dhcp23-91 ~]# atomic run --spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
 docker run --cap-add SYS_MODULE -v
/sys/kernel/debug:/sys/kernel/debug -v
/usr/src/kernels:/usr/src/kernels -v
/usr/lib/modules/:/usr/lib/modules/ -v
/usr/lib/debug:/usr/lib/debug -t -i --name
systemtap-spc
candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>
<http://candidate-registry.fedoraproject.org/f26/systemtap
<http://candidate-registry.fedoraproject.org/f26/systemtap>>
  [...]
 ERROR: Couldn't insert module
'/tmp/stapNEjJDX/stap_4f013e7562b546a0316af840de9f0713_8509.ko':
Operation not permitted
[...]

I bet
# setenforce 0
makes it work for you.  As per audit.log:

type=AVC msg=audit(1507222590.683:7940): avc: denied  {
module_load }
for  pid=7595 comm="staprun"
scontext=system_u:system_r:container_t:s0:c534,c921
tcontext=system_u:system_r:container_t:s0:c534,c921
tclass=system permissive=1


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>


Rather then putting the system into permissive mode, you should
run a privileged container or at least disable SELinux protections.


docker run -ti --security-opt label:disable ...





--

-- Jeremy Eder


Could you show me the AVC you get when you do the label:disable?


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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:11 PM, Frank Ch. Eigler wrote:

Hi, Dan -


[...]
Rather then putting the system into permissive mode, you should run
a privileged container

"atomic run --spc " fails similarly on f26, despite its
underlying "docker run --cap-add SYS_MODULE ..." parts.


or at least disable SELinux protections.

docker run -ti --security-opt label:disable ...

Is there an atomic(1) command line equivalent for this?  Or would
one have to put the security-option bits into the Dockerfile LABEL?


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


Could you show the docker line that atomic run is executing?  The LABEL 
would be the


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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Daniel Walsh]

On 10/05/2017 01:00 PM, Frank Ch. Eigler wrote:

wcohen forwarded:


[...]

   [root@dhcp23-91 ~]# atomic run --spc 
candidate-registry.fedoraproject.org/f26/systemtap 

 docker run --cap-add SYS_MODULE -v /sys/kernel/debug:/sys/kernel/debug -v 
/usr/src/kernels:/usr/src/kernels -v /usr/lib/modules/:/usr/lib/modules/ -v 
/usr/lib/debug:/usr/lib/debug -t -i --name systemtap-spc 
candidate-registry.fedoraproject.org/f26/systemtap 

  [...]
 ERROR: Couldn't insert module 
'/tmp/stapNEjJDX/stap_4f013e7562b546a0316af840de9f0713_8509.ko': Operation not 
permitted
[...]

I bet
# setenforce 0
makes it work for you.  As per audit.log:

type=AVC msg=audit(1507222590.683:7940): avc:  denied  { module_load }
for  pid=7595 comm="staprun" scontext=system_u:system_r:container_t:s0:c534,c921
tcontext=system_u:system_r:container_t:s0:c534,c921 tclass=system permissive=1


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


Rather then putting the system into permissive mode, you should run a 
privileged container or at least disable SELinux protections.



docker run -ti --security-opt label:disable ...

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

Re: GnuPG 2.2.0 and replacement of GnuPG1

[Daniel Walsh]

On 09/17/2017 02:12 PM, Brian Exelbierd wrote:


On Thu, Sep 7, 2017, at 02:25 PM, Dominik 'Rathann' Mierzejewski wrote:

On Sunday, 03 September 2017 at 13:45, Igor Gnatenko wrote:

GnuPG 2.2.0 has --enable-gpg-is-gpg2 which would install compat symlink
  from /usr/bin/gpg to /usr/bin/gpg2..

Is it time to retire gnupg (v1) ?

hplip still requires gnupg.

docker seems to as well ...

regards,

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


We will change the docker requirement to be V2.  We have no idea why it 
is set to V1, and upstream Docker is using v2.

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

Re: Converting selinux commands into a policy file

[Daniel Walsh]

On 09/14/2017 10:25 AM, Richard Shaw wrote:
I have been working on packaging the Ubiquity Unifi controller 
software for Fedora and EPEL and the package actually works pretty well.


I've created a review request on RPM Fusion non-free since it's not 
FOSS and I've only been given permission to package/distribute.


Currently I handle the selinux issues in %post as follows:

semanage fcontext -a -t mongod_log_t \
"%{_localstatedir}/log/unifi(/.*)?" 2>/dev/null || :
semanage fcontext -a -t mongod_var_lib_t \
"%{_sharedstatedir}/unifi/data(/.*)?" 2>/dev/null || :
restorecon -R %{_localstatedir}/log/unifi || :
restorecon -R %{_sharedstatedir}/unifi/data || :
semanage port -a -t mongod_port_t -p tcp 27117 2>/dev/null || :

The Fedora packaging wiki's I can find all seem to be drafts and fare 
more complicated...


Is it acceptable to do this in %post or do I really need to turn these 
into policy files and provide them as a subpackage?


Thanks,
Richard


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


It is fine to do this in post.  You could combine the commands together 
into one semanage command, if this is slow.


Similarly you can run a single restorecon command.

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