fedora-atomic discussion point: /usr/lib/passwd
by Colin Walters
For the fedora-atomic work, the only not-in-Fedora package is
shadow-utils because it requires a patch, that still lives in my
walters/rpm-ostree COPR.
Patch is linked from my post here:
http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/0100...
Also, some discussion in the glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=16142
What I'd like to open is a discussion about whether /usr/lib/passwd is
the right thing long term. I think it'd be very useful to support it
short term, but it's not perfect.
The main case where it breaks is when you have a daemon that runs as
non-root and saves state, so you give it its own system user, but not a
reserved uid. Daemons in this class will have their uids effectively
ordered by package installation order =/
One way to fix this that goes with my general direction of moving
things out of %post into systemd: a dynamic uid reservation system that
saves state persistently.
Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
except we'd wrap that with something that checked whether the user
existed first.
Then /etc/passwd would still be local system-persistent state, and
OSTree still wouldn't need to run a %post. I think though it'd be good
to still use /usr/lib/passwd in this model for daemons that *don't*
save state persistently, like dbus. No need to pollute /etc/passwd
with them.
(Note, we'd also need to teach %systemd_preun to run some kind of
ExecUninstall=, or skip spawning subprocesses and teach systemd how to
modify the user database directly)
Thoughts?
9 years, 7 months
Automatically generated configuration files
by Florian Weimer
I'm working on advice on automated X.509 certificate generation during
package installation.
One aspect is that these files obviously have to be generated on the
system during installation (or first service start) and cannot be
shipped in the package. Some existing RPMs just drop files into
/etc/pki/certs and /etc/pki/tls/private, without marking them as ghost
files or configuration files. (I'm not even sure if you can mark
something for which no content is provided in the RPM as a configuration
file.)
I wonder what an ideal RPM package would do in this case?
--
Florian Weimer / Red Hat Product Security Team
9 years, 7 months
We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
by Daniel J Walsh
The problem is lots of services require systemd because they ship a
unit file and want systemctl reload to happen. Systemd then triggers a
require for udev and kmod, which docker containers do not need.
rpm -q --whatrequires systemd| wc -l
151
On rawhide I see 151 packages on my system which require systemd.
We have a couple of options we could add a package called fakesystemd
which provides a /usr/bin/systemctl that does nothing and does a
provides systemd in the specfile. Then if the user wanted to install
systemd into a container it would need to obsolete the fakesystemd package.
Or we could break out /usr/bin/systemctl into its own package and have
it be smart enough to do nothing if systemd did not exist.
9 years, 7 months
F21 System Wide Change: Wayland
by Jaroslav Reznik
= Proposed System Wide Change: Wayland =
https://fedoraproject.org/wiki/Changes/Wayland
Change owner(s): Matthias Clasen and the desktop team <mclasen(a)redhat.com,
desktop(a)lists.fedoraproject.org>
Port the GNOME desktop to Wayland.
== Detailed Description ==
GNOME is being ported to Wayland. In particular GNOME shell is changed to run
as a Wayland compositor instead of an X11 compositor. Other components of
GNOME that currently talk directly to the X server, such as gnome-settings-
daemon or gnome-control-center, will be ported to corresponding Wayland
interfaces. Many GTK+ applications will just work, using the existing Wayland
backend. Applications that make use of X-specific APIs will be supported with
the xwayland X server, which is started on demand. gdm will be changed to
support both Wayland-based sessions and X-based sessions.
This change is targeted at F21. For F20, we aim for having an experimental
GNOME shell Wayland compositor available, without necessarily having all the
surrounding desktop infrastructure ported. To avoid destabilizing the X
compositor, mutter will ship two separate libraries, and gnome-shell will ship
two binaries that will link against them. Concretely, we plan to have a
separate mutter-wayland package.
For more details, see this page [1].
== Scope ==
* Proposal owners:
** Port GNOME shell to be a Wayland compositor
** Implement Wayland equivalents for X11 APIs such as XRANDR, XI2 and
accessibility features
** Port gnome-settings-daemon, gnome-control-center, gnome-desktop from X11
APIs to Wayland equivalents
** Enable gdm to launch Wayland sessions
** Complete the GTK+ Wayland backend to be on par with the X11 backend
** Package mutter-wayland as a separate package review [2] (DONE)
* Other developers:
** The X team needs to improve xwayland to be good enough for all X11
application - in practice this means we need X 1.16
** The X team needs to cooperate with us in reimplementing some X11 APIs
** The X team needs to package libevdev (DONE)
** The X team needs to package libinput (DONE)
** It is not necessary for all spins or all desktop environments in Fedora to
switch to Wayland at the same time (or ever)
* Release engineering:
** No tasks anticipated
* Policies and guidelines:
** Once we have a basic Wayland-based GNOME session, it would be good to
encourage testers and packagers to test their applications under Wayland
** For applications that are known not to work under Wayland, we will need
guidelines for how to ensure that they will transparently run under xwayland
[1] https://wiki.gnome.org/ThreePointNine/Features/WaylandSupport
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1007445
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 7 months
kernel packaging split up landing in Rawhide
by Josh Boyer
Hi All,
As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1],
I've committed and pushed the kernel packaging split up into
kernel-core and kernel-drivers subpackages. For those of you running
rawhide, this really shouldn't be a major impact at all. When you do
a yum update, you will see "kernel", "kernel-core", and
"kernel-drivers" packages being installed. The end result should be
in line with today's rawhide kernels.
Note: Unless you're using a typical VM or Cloud image, don't uninstall
the kernel or kernel-drivers packages. The machine may boot with just
kernel-core, but it will lack drivers for a significant portion of
bare-metal hardware without kernel-drivers installed.
Despite best efforts in testing, it's always possible a bug or two
snuck through. In the event that you do have an issue with this,
please file a bug against the kernel package.
josh
[1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
9 years, 7 months
Re: [Fedora Update] [CRITPATH] [comment] mesa-10.1-6.20140305.fc20, pure-0.58-3.fc20, python-llvmpy-0.12.4-1.fc20, pocl-0.9-4.fc20.1, OpenGTL-0.9.18-9.fc20, gedit-code-assistance-0.2.0-5.fc20, gambas3-3.5.3-1.fc20.1, dragonegg-3.4-0.3.rc0.fc20, llvm-3.4-6.fc20
by Adam Jackson
On Sat, 2014-04-19 at 15:33 +0000, updates(a)fedoraproject.org wrote:
> The following comment has been added to the mesa-10.1-6.20140305.fc20,pure-0.58-3.fc20,python-llvmpy-0.12.4-1.fc20,pocl-0.9-4.fc20.1,OpenGTL-0.9.18-9.fc20,gedit-code-assistance-0.2.0-5.fc20,gambas3-3.5.3-1.fc20.1,dragonegg-3.4-0.3.rc0.fc20,llvm-3.4-6.fc20 update:
>
> bodhi - 2014-04-19 15:33:49 (karma: 0)
> This update has been submitted for stable by ignatenkobrain.
Can you please not just decide to push things to updates that I'd
already promised fesco I'd leave in testing for a long soak period?
That be great.
- ajax
9 years, 7 months
F21 Self Contained Change: The Shogun Machine Learning Toolbox
by Jaroslav Reznik
= Proposed Self Contained Change: The Shogun Machine Learning Toolbox =
https://fedoraproject.org/wiki/Changes/shogun
Change owner(s): Björn Esser <besser82(a)fedoraproject.org>
SHOGUN is a large Scale Machine Learning Toolbox, being implemented in C++ and
offering interfaces to C#, Java, Lua, Octave, Perl, Python, R and Ruby.
== Detailed Description ==
* Homepage: The SHOGUN Machine Learning Toolbox [1]
* SCM-repo: on GitHub [2]
* Documentation: is available here [3]
* further Information: on Wikipedia [4]
The machine learning toolbox's focus is on large scale kernel methods and
especially on Support Vector Machines (SVM). It provides a generic SVM object
interfacing to several different SVM implementations, among them the state of
the art LibSVM. Each of the SVMs can be combined with a variety of kernels.
The toolbox not only provides efficient implementations of the most common
kernels, like the Linear, Polynomial, Gaussian and Sigmoid Kernel but also
comes with a number of recent string kernels as e.g. the Locality Improved,
Fischer, TOP, Spectrum, Weighted Degree Kernel (with shifts). For the latter
the efficient LINADD optimizations are implemented. Also SHOGUN offers the
freedom of working with custom pre-computed kernels. One of its key features
is the "combined kernel" which can be constructed by a weighted linear
combination of a number of sub-kernels, each of which not necessarily working
on the same domain. An optimal sub-kernel weighting can be learned using
Multiple Kernel Learning. Currently SVM 2-class classification and regression
problems can be dealt with. However SHOGUN also implements a number of linear
methods like Linear Discriminant Analysis (LDA), Linear Programming Machine
(LPM), (Kernel) Perceptrons and features algorithms to train hidden Markov-
models. The input feature-objects can be dense, sparse or strings and of type
int/short/double/char and can be converted into different feature types.
Chains of "pre-processors" (e.g. subtracting the mean) can be attached to each
feature object allowing for on-the-fly pre-processing.
== Scope ==
* Proposal owners: Create the rpm-spec and file a review bug. Have the package
build after review was granted.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
[1] http://shogun-toolbox.org/
[2] https://github.com/shogun-toolbox/shogun
[3] http://shogun-toolbox.org/doc/en/current/
[4] http://en.wikipedia.org/wiki/Shogun_%28toolbox%29
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 7 months
F21 System Wide Change: Default Local DNS Resolver
by Jaroslav Reznik
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P <pjp(a)fedoraproject.org>, Pavel Šimerda
<pavlix(a)pavlix.net>, Tomas Hozza <thozza(a)redhat.com>
To install a local DNS resolver trusted for the DNSSEC validation running on
127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
The automatic name server entries received via dhcp/vpn/wireless
configurations should be stored separately, as transitory name servers to be
used by the trusted local resolver. In all cases, DNSSEC validation will be
done locally.
This change was submitted after the Submission deadline.
== Detailed Description ==
There are growing instances of discussions and debates about the need for a
trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are
multiple reasons for having such a resolver, importantly security & usability.
Security & protection of user's privacy becomes paramount with the backdrop of
the increasingly snooping governments and service providers world wide.
People use Fedora on portable/mobile devices which are connected to diverse
networks as and when required. The automatic DNS configurations provided by
these networks are never trustworthy for DNSSEC validation. As currently there
is no way to establish such trust.
Apart from trust, these name servers are often known to be flaky and
unreliable. Which only adds to the overall bad and at times even frustrating
user experience. In such a situation, having a trusted local DNS resolver not
only makes sense but is in fact badly needed. It has become a need of the
hour. (See: [1], [2], [3])
Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous,
having a trusted local DNS resolver will not only be imperative but be
unavoidable. Because it will perform the most important operation of
establishing trust between two parties.
All DNS literature strongly recommends it. And amongst all discussions and
debates about issues involved in establishing such trust, it is unanimously
agreed upon and accepted that having a trusted local DNS resolver is the best
solution possible. It'll simplify and facilitate lot of other design decisions
and application development in future. (See: [1], [2], [3])
People:-
* Petr Spacek
* Paul Wouters
* Simo Sorce
* Dmitri Pal
* Carlos O'Donell
== Scope ==
* Proposal owners: Proposal owners shall have to
** define the syntax and semantics for new configuration parameters/files.
** persuade and coordinate with the other package owners to incorporate new
changes/workflow in their applications.
* Other developers: (especially NetworkManager and the likes)
** would have to implement the new features/workflow for their applications
adhering to the new configurations and assuming the availability of the
'''trusted''' local DNS resolver.
** NetworkManager already has features & capability to support local DNS
resolvers. Though few details are still under development, but are expected to
realize in near future. Please see [4]
* Release engineering:
** would have to ensure that trusted local DNS resolver is available
throughout the installation stage and the same is installed on all
installations including LiveCDs etc.
* Policies and guidelines:
** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.)
would have to ensure that their DNS resolver starts at boot time and works out
of the box without any user intervention.
** NetworkManager and others would have to be told to not tamper with the
local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver
entries in a separate configuration file.
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
[4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 7 months