Snaps and Fedora
by Neal Gompa
Hello all,
Over the course of this week, I've been involved in the first Snap
sprint focused on making the Snap system broadly useful and workable
across a wide variety of Linux distributions. While I obviously did
not represent Fedora in any official capacity (and I'm not even really
sure it's possible for a person to represent such a diverse community
such as ours), I ensured that Fedora was part of the conversation when
it came to evolving the Snap system.
There are some interesting highlights from the event that I think are
quite relevant to Fedora:
* Snaps are intended to evolve beyond Ubuntu. While snaps have their
origins in Click for Ubuntu Touch user apps, the Snap system is
clearly designed to support a broader array of capabilities and
systems. Snaps can be used to handle OS components, services, CLI
tools, desktop applications, build environments, web services, and so
on.
* Runtimes are supported in snaps. While technically there's no
specific "type" of snap, it's possible to build a snap that contains
common libraries and services that can be connected to other snaps.
This is done through the "plugs" and "slots" that can be used to
create interfaces among them. This is a true superset of the
capability provided by Flatpak through Portals, since it can be used
to export non-DBus oriented communications mechanisms. This is
described on the Snapcraft documentation[0].
* SELinux-based confinement is a _very_ high priority. As most know,
snapd currently only works on systems using AppArmor and seccomp, and
only those using AppArmor patches developed by Ubuntu that are in the
process of being upstreamed. For SELinux support, we aren't exactly
sure how this will be pulled off. I proposed something along the lines
of how confinement works for Docker containers and virtual machines
(sVirt), but I'm not sure if that's the right approach for enabling
proper confinement while allowing the sandboxes to support the
interconnection capabilities of snaps. The way that the Snap system
enforces confinement using AppArmor and seccomp is by generating a
profile for the snap on the fly that defines what it can and cannot do
and access for the mounted snap filesystem (from the squashfs image).
This policy is applied, locking down the snap's environment. I'm
curious to hear from others on how the approach should be for
providing confinement using SELinux.
* Detection and auto-configuration of confinement is coming.
Snap-confine currently relies on build time configuration to figure
out whether it should support confinement. However, this will change.
Snap-confine will be merged into snapd and snapd will be set up to
query and set up whatever confinement is possible, given the
information returned from the kernel and systemd about what
confinement mechanisms are supported.
* The snap format is simple and lends itself to being able to be
generated by many kinds of tools. While the current main tool used to
make snaps is Snapcraft, there's no reason someone couldn't build a
"snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could
theoretically use RPM spec format (or a derivative of it) to build
snaps.
* Snapcraft is currently Ubuntu specific, but will be reworked to
remove that. Snapcraft and the snapcraft.yaml format will change to
enable easily and reproducibly building snaps using Debian and RPM
based distro bases in addition to Ubuntu[3]. The goal is to make it
possible for a distribution like Fedora to be able to easily add
support for building snaps and snap parts from Fedora infrastructure
using Fedora packages/software, along the lines of what we do now for
Docker images, so that people can use them in their own snaps or
solutions.
* The VideoLAN project now officially offers a VLC snap[4], and the
Elementary OS folks are working on snaps for their Pantheon Desktop
applications and tying it to an Elementary GTK runtime snap.
Similarly, the KDE Neon folks are developing a KDE Frameworks 5
runtime snap and building application snaps to use them.
* Using snapd with alternative stores is possible. In fact, the tests
done on snapd builds rely on a "fake store" set up locally to be able
to test all the functionality. The store API is fully documented[5]
and there's even a simple implementation of it[6].
* Support for snaps to offer AppStream metadata is coming. The Snappy
development team is highly interested in implementing support for
AppStream so that it's easier for software centers and other tools to
be able to discover and interact with snaps through snapd. Snapd
support for AppStream XML through its API[7] for software centers is
planned as well.
* Fedora packaging of the snap system is under active development.
Zygmunt Krynicki (zyga) is extremely enthused to get the system in
Fedora fully functional, and I'm mentoring him on various aspects of
Fedora packaging, including maintenance and policies.
* Snap development is rather fast, with releases expected to occur
every two weeks. There's no intention to break the API between snapd
and the rest of the system, so interaction points should be fine. The
pace is well-suited for being able to push updates to Fedora in a
timely fashion so that users can get the best experience possible for
using applications and services under the system.
I know that the Workstation WG is very much behind Flatpak right now,
but I see no reason that we cannot offer both. In fact, it is in the
best interests of our users to fully enable both systems to the best
extent we can, so that they have the freedom to develop and use
applications as they see fit.
So, what does everyone think of Snappy, given this new information?
Constructive feedback is highly valuable and very welcome, especially
at this early stage!
Best regards,
Neal
[0]: http://snapcraft.io/docs/reference/interfaces
[1]: https://github.com/ascherer/debbuild
[2]: http://pkgbuild.sourceforge.net/
[3]: https://bugs.launchpad.net/snapcraft/+bug/1602258
[4]: https://uappexplorer.com/app/vlc.videolan
[5]: http://search.apps.ubuntu.com/docs/
[6]: https://github.com/noise/snapstore
[7]: https://github.com/snapcore/snapd/blob/master/docs/rest.md
--
真実はいつも一つ！/ Always, there's only one truth!
7 years, 8 months
glibc subpackage changes
by Florian Weimer
To implement some Fedora 25 changes (split NSS (Name Service Switch)
subpackages, libcrypt without NSS (Mozilla Network Security Services)
library depdencies), I added additional subpackages to the glibc
packages, namely:
- libcrypt
- libcrypt-nss
- nss_db
- nss_hesiod
- nss_nis
The expectation is that libgcrypt-nss is installed by default, and
system administrators may opt to install libcrypt (with the internal
algorithm implementations instead). libcrypt and libcrypt-nss both
provide the soname-based RPM dependencies required by applications which
need password hashing.
In contrast, nss_db, nss_hesiod, nss_nis are expected to be installed by
system administrators who need the specific functionality. They are not
installed by default. (nss_files and nss_dns remain part of the main
glibc package because their use is pretty much required by all
installations.)
The background for these changes is twofold: We want to reduce minimal
image size (also the gains a very small), and we want to pave the road
towards alternative implementations (based on OpenSSL for libcrypt, and
based on libtirpc for nss_nis).
Thanks,
Florian
7 years, 8 months
Attempting to contact unresponsive maintainer - mnagy
by Kevin Fenzi
Greetings, we've been told that the email addresses
for this package maintainer is no longer valid. I'm starting the
unresponsive maintainer policy to find out if they are still interested
in maintaining their packages (and if so, have them update their email
addresses in FAS). If they're not interested in maintaining or we
can't locate them I'll have FESCo orphan the packages so that others
can take them over.
If you have a way to contact this maintainer, please let them
know that we'd appreciate knowing what to do with their packages.
Thanks!
User mnagy - former email mgagy(a)redhat.com
Point of contact:
rpms/itzam-core -- Library for creating and manipulating keyed-access database files ( master f25 f24 f23 el6 el5 )
rpms/messiggy -- Messiggy is a database of celestial objects ( master f25 f24 f23 el6 el5 )
Co-maintainer:
rpms/vsftpd -- Very Secure Ftp Daemon ( master f25 f24 f23 )
7 years, 8 months
Orphaned packages seeking new point of contact
by Kevin Fenzi
Greetings.
Per:
#topic #1602 dvgrab, non-responsive maintainer
.fesco 1602
https://fedorahosted.org/fesco/ticket/1602
#topic #1603 scons, non-responsive maintainer for epel builds
.fesco 1603
https://fedorahosted.org/fesco/ticket/1603
#topic #1604 wise2, non-responsive maintainer
.fesco 1604
https://fedorahosted.org/fesco/ticket/1604
#topic #1607 Orphan package for "patches"
.fesco 1607
https://fedorahosted.org/fesco/ticket/1607
I have orphaned the following packages / branches and they need a new point of
contact to stay in the Fedora or EPEL Collections:
ascii (epel7)
ascii (f23)
ascii (f24)
ascii (f25)
ascii (master)
blender (el6)
blender (epel7)
blender (f23)
blender (f24)
blender (f25)
blender (master)
bouncycastle-mail (el5)
bouncycastle-mail (el6)
bouncycastle-mail (epel7)
bouncycastle-tsp (el5)
bouncycastle-tsp (el6)
coffee-script (el6)
coffee-script (epel7)
coffee-script (f23)
coffee-script (f24)
coffee-script (f25)
coffee-script (master)
compat-libuv010 (f23)
compat-libuv010 (f24)
compat-libuv010 (f25)
compat-libuv010 (master)
dom4j (el6)
dvgrab (f23)
dvgrab (f23)
dvgrab (f24)
dvgrab (f24)
dvgrab (f25)
dvgrab (f25)
dvgrab (master)
dvgrab (master)
emacs-common-ess (f23)
emacs-common-ess (f24)
emacs-common-ess (f25)
emacs-common-ess (master)
firecontrol (f23)
firecontrol (f24)
firecontrol (f25)
firecontrol (master)
ghc-editline (f23)
ghc-editline (f24)
ghc-editline (f25)
ghc-editline (master)
ghc-primes (f23)
gnu-smalltalk (el5)
gnu-smalltalk (el6)
gnu-smalltalk (epel7)
gnu-smalltalk (f23)
gnu-smalltalk (f24)
gnu-smalltalk (f25)
gnu-smalltalk (master)
gnustep-back (el6)
gnustep-back (f23)
gnustep-back (f24)
gnustep-back (f25)
gnustep-back (master)
gnustep-base (el6)
gnustep-base (epel7)
gnustep-base (f23)
gnustep-base (f24)
gnustep-base (f25)
gnustep-base (master)
gnustep-examples (el6)
gnustep-examples (f23)
gnustep-examples (f24)
gnustep-examples (f25)
gnustep-examples (master)
gnustep-gui (el6)
gnustep-make (el6)
gnustep-make (epel7)
gnustep-make (f23)
gnustep-make (f24)
gnustep-make (f25)
gnustep-make (master)
gorm (el6)
gorm (f23)
gorm (f24)
gorm (f25)
gorm (master)
gprolog (epel7)
gprolog (f23)
gprolog (f24)
gprolog (f25)
gprolog (master)
gresolver (f23)
gresolver (f24)
gresolver (f25)
gresolver (master)
highlight (el5)
highlight (el6)
highlight (f23)
highlight (f24)
highlight (f25)
highlight (master)
http-parser (el5)
http-parser (el6)
http-parser (epel7)
http-parser (f23)
http-parser (f24)
http-parser (f25)
http-parser (master)
icu4j (el6)
inadyn (el5)
inadyn (el6)
inadyn-mt (f23)
inadyn-mt (f24)
inadyn-mt (f25)
inadyn-mt (master)
jaxen-bootstrap (el6)
js-jquery1 (el5)
js-jquery1 (el6)
js-jquery1 (epel7)
js-jquery1 (f23)
js-jquery1 (f24)
js-jquery1 (f25)
js-jquery1 (master)
js-jquery (el5)
js-jquery (el6)
js-jquery (epel7)
js-jquery (f23)
js-jquery (f24)
js-jquery (f25)
js-jquery (master)
js-jquery-migrate (el5)
js-jquery-migrate (el6)
js-jquery-migrate (epel7)
js-jquery-migrate (f23)
js-jquery-migrate (f24)
js-jquery-migrate (f25)
js-jquery-migrate (master)
js-sizzle (el6)
js-sizzle (epel7)
js-sizzle (f23)
js-sizzle (f24)
js-sizzle (f25)
js-sizzle (master)
kaya (f23)
kaya (f24)
kaya (f25)
kaya (master)
kyum (el5)
kyum (el6)
latex2emf (f23)
latex2emf (f24)
latex2emf (f25)
latex2emf (master)
libart_lgpl (f23)
libart_lgpl (f24)
libart_lgpl (f25)
libart_lgpl (master)
libavc1394 (f23)
libavc1394 (f24)
libavc1394 (f25)
libavc1394 (master)
libdiscid (f23)
libdiscid (f24)
libdiscid (f25)
libdiscid (master)
libdv (f23)
libdv (f24)
libdv (f25)
libdv (master)
libiec61883 (f23)
libiec61883 (f24)
libiec61883 (f25)
libiec61883 (master)
libntlm (epel7)
libraw1394 (f23)
libraw1394 (f24)
libraw1394 (f25)
libraw1394 (master)
libuv (el6)
libuv (epel7)
libuv (f23)
libuv (f24)
libuv (f25)
libuv (master)
lightning (master)
man2html (el5)
man2html (el6)
man2html (epel7)
man2html (f23)
man2html (f24)
man2html (f25)
man2html (master)
msv (el6)
node-gyp (el6)
node-gyp (epel7)
node-gyp (f23)
node-gyp (f24)
node-gyp (f25)
node-gyp (master)
npm (el6)
npm (epel7)
npm (f23)
npm (f24)
ode (el6)
open-cobol (f23)
open-cobol (f24)
open-cobol (f25)
open-cobol (master)
oxygen-icon-theme (master)
oxygen-icon-theme (master)
pdf-renderer (f23)
pdf-renderer (f24)
pdf-renderer (f25)
pdf-renderer (master)
perl-Ace (f23)
perl-Ace (f24)
perl-Ace (f25)
perl-Ace (master)
perl-AutoClass (f23)
perl-AutoClass (f24)
perl-AutoClass (f25)
perl-AutoClass (master)
perl-Convert-Binary-C (f23)
perl-Convert-Binary-C (f24)
perl-Convert-Binary-C (f25)
perl-Convert-Binary-C (master)
perl-Data-Stag (f23)
perl-Data-Stag (f24)
perl-Data-Stag (f25)
perl-Data-Stag (master)
perl-GD-SVG (f23)
perl-GD-SVG (f24)
perl-GD-SVG (f25)
perl-GD-SVG (master)
perl-Graph (f23)
perl-Graph (f24)
perl-Graph (f25)
perl-Graph (master)
perl-Math-Derivative (f23)
perl-Math-Derivative (f24)
perl-Math-Derivative (f25)
perl-Math-Derivative (master)
perl-Math-Spline (f23)
perl-Math-Spline (f24)
perl-Math-Spline (f25)
perl-Math-Spline (master)
perl-PostScript (f23)
perl-PostScript (f24)
perl-PostScript (f25)
perl-PostScript (master)
perl-SVG (f23)
perl-SVG (f24)
perl-SVG (f25)
perl-SVG-Graph (f23)
perl-SVG-Graph (f24)
perl-SVG-Graph (f25)
perl-SVG-Graph (master)
perl-SVG (master)
perl-Text-Shellwords (f23)
perl-Text-Shellwords (f24)
perl-Text-Shellwords (f25)
perl-Text-Shellwords (master)
perl-XML-DOM-XPath (f23)
perl-XML-DOM-XPath (f24)
perl-XML-DOM-XPath (f25)
perl-XML-DOM-XPath (master)
perl-XML-XPathEngine (f23)
perl-XML-XPathEngine (f24)
perl-XML-XPathEngine (f25)
perl-XML-XPathEngine (master)
pgp-tools (el5)
pgp-tools (f23)
pgp-tools (f24)
pgp-tools (f25)
pgp-tools (master)
picard (f23)
picard (f24)
picard (f25)
picard (master)
psgml (f23)
psgml (f24)
psgml (f25)
psgml (master)
pypop (el5)
pypop (el6)
pypop (f23)
pypop (f24)
pypop (f25)
pypop (master)
python-numeric (el6)
python-pysmell (f23)
python-pysmell (f24)
python-pysmell (f25)
python-pysmell (master)
python-rencode (el6)
python-smbpasswd (f23)
python-smbpasswd (f24)
python-smbpasswd (f25)
python-smbpasswd (master)
python-webm (el6)
python-webm (f23)
python-webm (f24)
python-webm (f25)
python-webm (master)
scons (el5)
scons (el6)
scons (epel7)
snobol (epel7)
snobol (f23)
snobol (f24)
snobol (f25)
snobol (master)
steghide (f23)
steghide (f24)
steghide (f25)
steghide (master)
stellarium (el6)
stellarium (epel7)
stellarium (f23)
stellarium (f24)
stellarium (f25)
stellarium (master)
suck (epel7)
suck (f23)
suck (f24)
suck (f25)
suck (master)
ttname (el5)
ttname (el6)
ttname (f23)
ttname (f24)
ttname (f25)
ttname (master)
twinkle (master)
uglify-js1 (el6)
uglify-js1 (epel7)
uglify-js1 (f23)
uglify-js1 (f24)
uglify-js1 (f25)
uglify-js1 (master)
uglify-js (el6)
uglify-js (epel7)
uglify-js (f23)
uglify-js (f24)
uglify-js (f25)
uglify-js (master)
v8 (el6)
v8 (epel7)
web-assets (el5)
web-assets (el6)
web-assets (epel7)
web-assets (f23)
web-assets (f24)
web-assets (f25)
web-assets (master)
wise2 (f23)
wise2 (f24)
wise2 (f25)
wise2 (master)
yakuake (f24)
yakuake (f25)
yakuake (master)
ycssmin (el6)
ycssmin (epel7)
ycssmin (f23)
ycssmin (f24)
ycssmin (f25)
ycssmin (master)
7 years, 8 months
Schedule for Friday's FESCo Meeting (2016-07-29)
by Kevin Fenzi
Following is the list of topics that will be discussed in the FESCo
meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2016-07-29 16:00 UTC'
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic #1600 F25 System Wide Change: KillUserProcesses=yes by default
.fesco 1600
https://fedorahosted.org/fesco/1600
= New business =
#topic #1568 F25 Self Contained Changes
.fesco 1568
https://fedorahosted.org/fesco/ticket/1568
#topic #1602 dvgrab, non-responsive maintainer
.fesco 1602
https://fedorahosted.org/fesco/ticket/1602
#topic #1603 scons, non-responsive maintainer for epel builds
.fesco 1603
https://fedorahosted.org/fesco/ticket/1603
#topic #1604 wise2, non-responsive maintainer
.fesco 1604
https://fedorahosted.org/fesco/ticket/1604
#topic #1605 finish retirement of sysvinit-only packages
.fesco 1605
https://fedorahosted.org/fesco/ticket/1605
#topic #1606 f25 approved Changes not in MODIFIED status (considered as
not testable)
.fesco 1606
https://fedorahosted.org/fesco/ticket/1606
#topic #1607 Orphan package for "patches"
.fesco 1607
https://fedorahosted.org/fesco/ticket/1607
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
7 years, 8 months
F25 System Wide Change: KillUserProcesses=yes by default
by Jan Kurik
= Proposed System Wide Change: KillUserProcesses=yes by default =
https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default
Change owner(s):
* Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
Set the default policy to terminate processes in session scope when
the user logs out. Specifically, systemd-logind's KillUserProcesses
setting, which currently is set to "no" to override the upstream
default, will be removed to follow the upstream default of "yes".
== Detailed Description ==
Since the introduction of systemd-logind a few years back, when a
session is created, systemd hooks into the PAM session creation step
to move the process that starts the session into a separate cgroup.
This means that processes which are started as part of the session can
be reliably tracked, even if they detach from the terminal and
daemonize. When a user session terminates, various processes started
as part of the user session (initally) remain alive. When the session
is terminated, remaining processes receive a HUP signal (*), which can
be and often is ignored.
Under the proposed setting of KillUserProcesses=yes, systemd will
forcibly terminate (using SIGTERM and then SIGKILL) all processes
which are part of the session scope (the cgroup created for the login
session) when the user logs out. In order for a process to avoid being
killed it has to be part of a different systemd unit. For user
processes this can be achieved in two primary ways: by starting the
unit as a service (e.g. 'systemd-run --user /usr/bin/foo', or creating
a dedicated user service unit), or by telling systemd to create a new
scope unit to encompass a specific process (e.g. 'systemd-run --user
--scope /usr/bin/foo', or making a dbus call to create a scope unit
directly). This step can be integrated directly into programs when
this makes sense for their primary use case, e.g. screen.
(*) Whether SIGHUP is sent depends on a few factors: bash sends it
children, tcsh does not, and the kernel also sends SIGHUP to processes
which have a terminal open.
== Scope ==
* Proposal owners:
- work upstream to clarify what is the best way for programs to mark
themselves to survive logout
- update the documentation with more explanations and examples, as we
learn what people find confusing in the current scheme of things
- evaluate a "permissive" mode for KillUserProcesses, to make it
easier to debug processes which stay around after a session terminates
- remove the compile-time override in the systemd package
- work with upstream authors and Fedora maintainers of programs like
screen and tmux to implement the ability to automatically start them
in a way that survives a user session, and if the system policy does
not allow that, to warn the user.
* Other developers:
- cooperate on the last item from previous point
- identify additional services which need to adapt to the changed default.
Different services might merit different handling here: some might be
updated them to start through the non-session-specific dbus instance,
some might need documentation changes, while others possibly should be
handled like tmux and screen.
* Release engineering: N/A
* List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines:
- a Fedora Magazine article or similar to publicize the change would be nice
* Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 8 months
