= Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s):
* P J P <pjp AT fedoraproject DOT org>
* Pavel Šimerda <pavlix AT pavlix DOT net>
* Tomas Hozza <thozza AT redhat DOT com>
* Petr Špaček <pspacek AT redhat DOT com>
Plain DNS protocol is insecure and therefore vulnerable from various
attacks (e.g. cache poisoning). A client can never be sure that there
is no man-in-the-middle, if it does not do the DNSSEC validation
locally.
We want to have Unbound server installed and running on localhost by
default on Fedora systems. Where necessary, have also dnssec-trigger
installed and running by default. Unbound and dnssec-trigger will be
properly integrated with the default network configuration manager
(e.g. NetworkManager for Fedora Server and Workstation) and with the
graphical user interface (especially GNOME). The localhost address
will be the only record in /etc/resolv.conf and no other software
except dnssec-trigger will be allowed to change its content.
== Detailed Description ==
Plain DNS protocol is insecure and therefore vulnerable from various
attacks (e.g. cache poisoning). DNSSEC is a DNS extension which
enabled the client to verify the DNS query response and make sure
there is no attacker to spoof some records. A user connected to
network usually receives a set of resolvers from DHCP, which should be
used for name resolution. These resolvers may also do the DNSSEC
validation. However a client can never be sure that there is no
man-in-the-middle, if it does not do the DNSSEC validation locally.
Purpose of this Fedora change is to have a validating DNS resolver
installed on Fedora systems by default. This includes necessary
discussions, coordination and integration with other components
installed on Fedora by default.
There are growing instances of discussions and debates about the need
for a trusted local validating DNS resolver. There are multiple
reasons for having such a resolver, most importantly security and
usability. Security and 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 validating DNS resolver not only makes sense but is, in fact,
badly needed. It has become a need of the hour. (See: [1], [2], [3])
All DNS literature strongly recommends it and amongst all discussions
and debates about the 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 will simplify and
facilitate a lot of other design decisions and application development
in the future. (See: [1], [2], [3])
[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
== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files.
* properly document how to test and configure the new default setup
* persuade and coordinate with the other package owners to incorporate
new changes/workflow in their applications.
* discuss with WGs in which products the change makes sense and what
are the expectations of WGs for different Fedora products
* resolve interoperability issues for Docker and other containers use-cases
Other developers: (especially NetworkManager and the likes)
* NetworkManager has to implement notifications on connectivity state changes
* Gnome Shell has to use the connection provided resolvers (fetched
directly from NM) for Hot-Spot login purposes
* Ideally other developers and user should test their software and
application in this setup and verify that it is working as expected
Release engineering:
* Make sure that the necessary packages (dnssec-trigger, unbound) are
part of the composes for the appropriate Fedora Products.
* Add services needed for the setup into the default presets
(dnssec-triggerd.service)
Policies and guidelines:
* Any software, including NetworkManager, will have to be configured
to not tamper with the content of '/etc/resolv.conf' by default. The
connection-provided resolver entries should be stored in a separate
configuration file or in memory and accessible via some API.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Planned Outage: Copr upgrade - 2015-11-30 08:00 UTC
There will be an outage starting at 2015-11-30 08:00 UTC, which will last approximately 4 hours.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d 'YYYY-MM-DD HH:MM UTC'
Reason for outage:
Upgrade of Copr backend and Copr frontend to Fedora 23.
Affected Services:
copr.fedoraproject.orgcopr-be.cloud.fedoraproject.org
Services not listed are not affected by this outage.
Contact Information: msuchy(a)redhat.com
Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/4999
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
= System Wide Change: Livemedia Creator =
https://fedoraproject.org/wiki/Changes/LivemediaCreator
Change owner(s):
* Dennis Gilmore <dennis AT ausil DOT us>
livemedia-creator is a tool that is part of lorax, it has the ability
to make livecd's, raw disk images, and to do pxe2live. We plan to use
it to make pxe2live for Atomic, the LiveCD's and ARM disk images in
fedora.
== Detailed Description ==
We will be adding to koji the the ability to run livemedia-creator in
a chroot. We will replace the long legacy tools used to make LiveCD's
and ARM disk images, as well as as the ability to deliver pxe2live for
atomic. livecd-creator and appliance-creator only support python2 and
yum, they have not seen any significant development in years and are
increasingly crufty. Using livemedia-creator allows us to use dnf to
create the media via anaconda and to ensure that the media is made the
same way we install any Fedora system, reducing the code paths and
differences in how a system looks based on which tool made it.
== Scope ==
Proposal owners:
* add livemedia-creator support to koji
* add support to pungi to create media using livemedia-creator
Other developers: port spin-kickstarts to work with livemedia-creator
Release engineering: communicate the changes and work with spins
owners to assist in kickstart porting
List of deliverables: All LiveCD's, ARM disk images and pxe2live will
be made with tooling changes
Policies and guidelines: We will be writing and/or updating docs on
how to write kickstarts for Spins
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
The Nomination period of Elections to Council, FESCo, FAmSCo and
Env&Stacks is now over. The list of nominees follows:
== Council (1 open seat) ==
* Robert Mayr (robyduck)
* Joe Brockmeier (jzb)
[ https://fedoraproject.org/wiki/Council/Nominations ]
== FESCo (5 open seats) ==
* Kevin Fenzi (nirik / kevin)
* Parag Nemade (paragn)
* Justin Forbes (jforbes)
* Germano Massullo (Caterpillar / germano)
* Jared Smith (jsmith)
* Adam Miller (maxamillion)
* Kalev Lember (kalev)
[ https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations ]
== FAmSCo (7 open seats) ==
* Gabriele Trombini (IRC/FAS mailga)
* Abdel G. Martínez L. (IRC/FAS potty)
* Christoph Wickert (IRC/FAS cwickert)
* Sirko Kemter (IRC/FAS gnokii)
* Matthew Williams (IRC/fas Lorddrachenblut)
* Truong Anh Tuan (IRC/FAS tuanta)
* Dan Mossor (IRC: danofsatx FAS:dmossor)
* Ben Williams (IRC: kk4ewt FAS:jbwillia)
* Alick Zhao (IRC/FAS alick)
* Luis Bazan (IRC/FAS lbazan)
[ https://fedoraproject.org/wiki/FAmSCo_nominations ]
== Env & Stacks (4 open seats) ==
* Tomas Tomecek (ttomecek)
* Petr Hracek (phracek)
[ https://fedoraproject.org/wiki/Env_and_Stacks/Nominations ]
As you can see, we have got enough nominees for all the teams/groups,
except Env & Stacks working group. As we can not cover 4 open seats in
Env & Stacks working group with just 2 nominees, I am going to talk to
the working group to agree on a backup plan.
Nominees for Council, FESCo and FAmSCo can now start with their own
campaign, to attract people in the Fedora community. I am also going
to work with people from CommOps team to prepare Community Blog for
publishing answers from candidates on collected questions in the
Election's Questionnaire [
https://fedoraproject.org/wiki/Elections/Questionnaire ].
I wish all the nominees good luck and a lot of fun during the campaign
period, attracting people from the community :)
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= System Wide Change: Fedora 24 Boost 1.60 uplift =
https://fedoraproject.org/wiki/Changes/F24Boost160
Change owner(s):
* Jonathan Wakely <jwakely AT redhat DOT com >
This change brings Boost 1.60.0 to Fedora 24. This will mean F24 ships
with the latest upstream Boost release.
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boostese seen in output from g++. Such care is to be expected
this time around as well.
Boost 1.60 is scheduled for release on 2 Dec 2016 and a beta release
is already available for testing
== Scope ==
Proposal owners:
* Build will be done with Boost.Build v2 (which is upstream-sanctioned
way of building Boost)
* Request a "f24-boost" build system tag (discussion):
https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost
* Build boost into that tag (take a look at the build #606493 for inspiration)
* Post a request for rebuilds to fedora-devel (XXX link to
fedora-devel message here)
* Work on rebuilding dependent packages in the tag.
* When most is done, re-tag all the packages to rawhide
* Watch fedora-devel and assist in rebuilding broken Boost clients (by
fixing the client, or Boost).
In order to discover any problems ASAP the proposal owner has created
a COPR and built the Boost 1.60.0 beta, and started rebuilding the
300+ dependent packages. The results of this COPR will be thrown away,
but it means any bugs in the upstream release can be reported and
fixed before the final release (rather than patched in the Fedora
package) and any changes needed in dependent packages will be known
sooner.
Other developers:
* Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* The proposal owner has already started test rebuilds of affected
packages and identifying the needed changes, and will propose patches
to Boost upstream or to the client packages' upstreams as appropriate.
Policies and guidelines:
* Apart from scope, this is business as usual, so no policies, no guidelines.
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
Hello,
In the coming hours we will be both upgrading fedora-packages [1] to a new
version (relying on mdapi [2]) and rebuilding its index.
This should take a couple of hours during which fedora-packages will not be
available. It will impact the package name completion in the new update form
of Bodhi as well as the pkgwat utility.
We will update http://status.fedoraproject.org to reflect the progress and
announce here when the rebuild is finished.
Thanks for your attention,
Pierre & Ralph for the Fedora infrastructure team
[1] https://apps.fedoraproject.org/packages
[2] https://apps.fedoraproject.org/mdapi/
= Proposed System Wide Change: Systemd package split =
https://fedoraproject.org/wiki/Changes/systemd_package_split
Change owner(s):
Zbigniew Jędrzejewski-Szmek <zbyszek AT in DOT waw DOT pl>
Two new subpackages will be split out from the main systemd package.
systemd-container will contain stuff for launching and managing VMs
and containers. system-udev will contain udevd and other
hardware-related bits.
== Detailed Description ==
* systemd-container.rpm will consist of systemd-nspawn,
systemd-machined, machinectl, systemd-importd, systemd-pull.
* systemd-udev.rpm will consist of systemd-udevd, udevadm, udev rules,
and the hardware database.
Both new subpackages will be optional. systemd-container.rpm is useful
only for people creating containers or VMs. systemd-udev.rpm should be
generally installed, but can be skipped in containers.
== Scope ==
Proposal owners:
* Update packaging to create the new subpackages.
Other developers:
* add dependencies on systemd-udev and systemd-container as necessary
for other packages, modify comps. Make sure anaconda installs
systemd-udev by default.
Release engineering: N/A
List of deliverables: N/A
Policies and guidelines: N/A
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