= Proposed Self Contained Change: Improved Ivy Packaging =
https://fedoraproject.org/wiki/Changes/ImprovedIvyPackaging
Change owner(s): Mikolaj Izdebski <mizdebsk(a)redhat.com>
This change aims at improving the way of packaging Java software, which uses
Apache Ivy to manage build dependencies.
== Detailed Description ==
Currently packages which use Apache Ivy as dependency manager are packaged in
manual way. Dependencies must be symlinked manually, all files have to be
explicitly installed, there are no auto-requires.
This change aims at simplifying Ivy packaging in a similar way as it was done
with Maven packaging [1].
In particular, the following changes will be implemented:
* automatic resolution of Ivy artifacts,
* integration with system Maven repository,
* automatic installation of Ivy artifact metadata,
* auto requires.
== Scope ==
Proposal owners:
* Implement code to resolve and publish Ivy artifacts in XMvn upstream
* Package new upstream version XMvn in Fedora or backport Ivy changes to
current XMvn version
* Implement necessary macros in Javapackages Tools upstream
* Package new upstream version Javapackages Tools in Fedora or backport
necessary changes to current Javapackages Tools version
* Prepare draft of Java packaging guidelines change and submit to FPC
Other developers:
* Maintainers of packages using Apache Ivy during build or installing Ivy
artifacts can optionally update their packages to use the new packaging
techniques, but that's not absolutely required as existing ways of packaging
Ivy artifacts will continue to work.
Release engineering:
* No action required.
Policies and guidelines:
* Java packaging guidelines will have to be updated to include the new way of
packaging Ivy artifacts.
[1] https://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging
= Proposed Self Contained Change: Better Erlang Support =
https://fedoraproject.org/wiki/Changes/BetterErlangSupport
Change owner(s): Peter Lemenkov <lemenkov(a)gmail.com>, Sam Kottler <skottler
[at] redhat.com>, Fedora Erlang SIG <erlang(a)lists.fedoraproject.org>
Update Erlang/OTP to R17, and improve Erlang integration with the rest of
Fedora.
== Detailed Description ==
Erlang in Fedora is already in a good shape. However we can do better since
there are a number of annoying shortcomings and issues. Just a few of them:
* Fedora partially enabled Ellyptic Curve Crypto recently but we still provide
Erlang with EC disabled completely because there is no way to enable just a
few EC in the current Erlang version.
* Erlang<->systemd interaction is in a quite poor state currently.
* There is no way to install "headless" Erlang. Every Fedora Erlang user have
to install graphical libraries even if (s)he doesn't want to use GUI on the
target machine.
* Every daemon written in Erlang has its own logging solution which doesn't
use neither syslog nor Journald.
* Erlang packaging is quite complex and undocumented mostly.
In order to address all these issues we should do the following:
* Enable fine grained EC crypto support [1] by upgrading Erlang to the latest
R17 (not yet released, and scheduled to April, 2014).
* Start working on a better systemd support in Erlang by enabling EPMD systemd
support. This could be done by merging patches from Matwey V. Kornilov [2]
and systemd unit-files from openSUSE [3].
* Add erlang-ejournald [4], erlang-lager_journald_backend [5], and make
Journald as a default logging backend.
* Split-off infrequently used modules [6] which requires X11, Pulseaudio and
ensure that it won't break anything.
* Fix the long-standing noarch issue by providing additional default location
for Erlang bytecode data.
* Update Erlang RPM-related macros to improve packaging by reducing spec-file
sizes.
== Scope ==
Proposal owners:
* We must rebuild Erlang R17 and submit it to build-overrides.
** We have to rebuild all the packages listed below in the Dependencies [7]
section.
* WiP: A necessary *.socket unit must be added to erlang-erts to enable EPMD
socket activation.
** Every Erlang daemon's systemd unit must require epmd.socket.
* We need to fill new review request for erlang-ejournald
** We have to fill new review request for erlang-lager_journald_backend
* We have to patch out GUI parts and provide a way to tell user what to do in
order to enable this functionality.
* Add another default directory to look for Erlang *.beam files.
* Every Erlang package must require erlang-rpm-macros.
* Riak has growing Bugzilla backlog. We have to address all of these issues.
Other developers: N/A
Release engineering: N/A
Policies and guidelines: We should create Erlang Packaging Guidelines which
doesn't exist yet.
[1] https://bugzilla.redhat.com/1023017
[2] https://github.com/matwey/otp/tree/systemd
[3] https://build.opensuse.org/package/show/openSUSE:Factory/erlang
[4] https://github.com/travelping/ejournald
[5] https://github.com/travelping/lager_journald_backend
[6] https://bugzilla.redhat.com/784693
[7] https://fedoraproject.org/wiki/Changes/BetterErlangSupport#Dependencies
= Proposed System Wide Change: GCC49 =
https://fedoraproject.org/wiki/Changes/GCC49
Change owner(s): Jakub Jelínek <jakub(a)redhat.com >
Switch GCC in Fedora 21 to 4.9.x, rebuild all packages with it.
== Detailed Description ==
GCC 4.9.0 is currently in stage4, in prerelease state with only regression
bugfixes and documentation fixes allowed. The release will happen probably in
the first half of April. Marek Polacek has performed a test mass rebuild on
x86_64 with gcc-4.9.0-0.*.fc21, most packages have built successfully, others
have failed to rebuild also with gcc 4.8.x, for the remaining packages most of
the needed changes are now tracked in [1] or, if it were bugs on the gcc side,
have been fixed in the mean time. GCC 4.9.0 prereleases have so far been built
as scratch packages, [2] (and similarly for ppc* and s390* secondary
architectures). Other distributions have performed test mass rebuilds on other
architectures (i?86, s390x, arm).
== Scope ==
All packages should be rebuilt with the new gcc once it hits f21.
* Proposal owners: Build gcc in f21, rebuild packages that have direct
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
* Other developers: First few days/weeks just voluntary rebuilds using the new
system gcc, if things fail, look at http://gcc.gnu.org/gcc-4.9/porting_to.html
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug,
analyze and report.
* Release engineering: Organize a mass rebuild
* Policies and guidelines: No policies need to be changed
---
Change Wrangler Note: Contingency Deadline is a bit vague "Before release" but
with GCC revert, distribution wide coordination would be needed with high
probability of slip. I'll open it for further discussion on list for
FESCo/releng..
[1] http://gcc.gnu.org/gcc-4.9/porting_to.html
[2] http://koji.fedoraproject.org/scratch/jakub/task_6667028/
= Proposed Self Contained Change: Apache Hive =
https://fedoraproject.org/wiki/Changes/ApacheHive
Change owner(s): Peter MacKinnon <pmackinn(a)redhat.com>
Apache Hive [1] is a data warehouse built on top of Apache Hadoop.
== Detailed Description ==
The Apache Hive data warehouse software facilitates querying and managing
large datasets residing in distributed storage. Apache Hive provides a
mechanism to project structure onto this data and query the data using a SQL-
like language called HiveQL.
== Scope ==
* Proposal owners: The Hive package has been accepted into Fedora and provides
all the functionality from the upstream release with the exception of HBase
support since the latest stable versions are not currently aligned.
* 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://hive.apache.org/
= Proposed Self Contained Change: Apache HBase =
https://fedoraproject.org/wiki/Changes/ApacheHBase
Change owner(s): Robert Rati <rrati(a)redhat.com>
Apache HBase [1] is a distributed database built on top of Apache Hadoop.
== Detailed Description ==
Apache HBase is used when you need random, realtime read/write access to your
Big Data. Apache HBase hosts very large tables -- billions of rows X millions
of columns -- atop clusters of commodity hardware. Apache HBase is a
distributed, versioned, non-relational database modeled after Google's
Bigtable: A Distributed Storage System for Structured Data by Chang et al.
Just as Bigtable leverages the distributed data storage provided by the Google
File System, Apache HBase provides Bigtable-like capabilities on top of Hadoop
and HDFS.
== Scope ==
* Proposal owners: The Hbase package has been accepted into Fedora and
provides all the functionality from the upstream release.
* 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://hbase.apache.org/
= Proposed Self Contained Change: Apache Oozie =
https://fedoraproject.org/wiki/Changes/ApacheOozie
Change owner(s): Robert Rati <rrati(a)redhat.com>
Apache Oozie [1] is a workflow scheduler system to manage Apache Hadoop jobs.
== Detailed Description ==
Apache Oozie is a workflow scheduler. It is integrated with the rest of the
Hadoop stack and supports several types of Hadoop jobs out of the box (such as
Java map-reduce, Streaming map-reduce, Pig, Hive, Sqoop and Distcp) as well as
system specific jobs (such as Java programs and shell scripts).
== Scope ==
* Proposal owners: Apache Oozie is packaged and awaiting review [2].
* 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://oozie.apache.org/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1071456
= Proposed Self Contained Change: Apache Mesos =
https://fedoraproject.org/wiki/Changes/ApacheMesos
Change owner(s): Timothy St. Clair <tstclair(a)redhat.com>
Apache Mesos [1] is a cluster manager for sharing distributed application
frameworks. This change brings Mesos to Fedora, which many have called a
micro-kernel for the data center.
== Detailed Description ==
Apache Mesos is a cluster manager that provides efficient resource isolation
and sharing across distributed applications, or frameworks. It can run Hadoop,
MPI, Hypertable, Spark, and other applications on a dynamically shared pool of
nodes.
== Scope ==
* Proposal owners: Currently our Mesos package has been accepted into Fedora.
It should feature all of the functionality available from the upstream
release.
* 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://mesos.apache.org/
= Proposed Self Contained Change: DNSSEC support for FreeIPA =
https://fedoraproject.org/wiki/Changes/IPAv3DNSSEC
Change owner(s): Petr Špaček <pspacek(a)redhat.com>
FreeIPA with integrated DNS server will support serving of DNSSEC secured
zones and automatic DNSSEC key maintenance.
This first version will have only the very basic functionality with limited
user interface and limited resiliency. Next versions (to be delivered in
Fedora 22 time frame) will improve resiliency and user interface
significantly.
== Detailed Description ==
DNS server integrated to FreeIPA in Fedora 20 is not able to serve signed DNS
zones. New version of FreeIPA and bind-dyndb-ldap adds support for DNSSEC.
Zone maintenance (like perioding zone re-signing etc.) will be handled
automatically, so the administrative overhead should be minimal.
== Scope ==
* Proposal owners: This change requires major rewrite of bind-dyndb-ldap
package, some isolated changes in packages freeipa* and it's integration with
OpenDNSSEC for key rotation.
* Other developers: FreeIPA team has to prepare user interface for this
feature. (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
= Proposed System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For
Long-Running Services =
https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork
Change owner(s): Lennart Poettering <lennart at poettering dot net>, Dan
Walsh, Kay Sievers
Let's make Fedora more secure by default! Recent systemd versions provide two
per-service switches PrivateDevices=yes/no and PrivateNetwork=yes/no which
enable services to run without access to any physical devices in /dev, or
without access to kind of network sockets. So far this has seen little use in
Fedora, and with this Fedora Change we'd like to change this, and enable these
for all long-running services that do not require device/network access.
== Detailed Description ==
When PrivateDevices=yes is set in the [Service] section of a systemd service
unit file, the processes run for the service will run in a private file system
namespace where /dev is replaced by a minimal version that only includes the
device nodes /dev/null, /dev/zero, /dev/full, /dev/urandom, /dev/random,
/dev/tty as well as the submounts /dev/shm, /dev/pts, /dev/mqueue,
/dev/hugepages, and the /dev/stdout, /dev/stderr, /dev/stdin symlinks. No
device nodes for physical devices will be included however. Furthermore, the
CAP_MKNOD capability is removed. Finally, the "devices" cgroup controller is
used to ensure that no access to device nodes except the listed ones is
possible. This is an efficient way to take away physical device access for
services, thus minimizing the attack surface.
When PrivateNetwork=yes is set in the [Service] section of a systemd service
unit file, the processes run for the service will run in a private network
namespace whith a private loopback network interface, and no other network
devices. Network communication between host and service can not be initiated.
This is an efficient way to take away network access for services, thus
minimizing the attack surface.
By default both switches default to "no".
Note that PrivateDevices=yes should not be used for:
1. Services that actually require physical device access
2. Services which may be used to execute arbitrary user or administrator
supplied programs (such as cron, ...). We shouldn't limit what people can do
with these services.
3. This option creates a new file system namespace where mount/umount
propagation is turned off back into the host. This means that mounts made by
the service will stay private to the service. Thus this option should not be
used by services which shall be able to establish mounts in the host.
Note that PrivateNetwork=yes should not be used for:
1. Services that actually require network access (with the exception of
daemons only needing socket activation)
2. Services which may be used to execute arbitrary user or administrator
supplied programs. (see above)
3. Services which might need to resolve non-system user and group names.
Since on some setups resolving non-system users might require network access
to an LDAP or NIS server, enabling this option on might break resolving of
these user names. Note however that system users/groups are always resolvable
even without network access. Hence it is safe to enable this option for
daemons which just need to resolve their own system user or group name.
4. This also disconnects the AF_UNIX abstract namespace from the host (In
case you wonder what this refers to: sockets listed in /proc/net/unix that
start with an @ are in the abstract namespace, those which start in / are in
the file system namespace). This means that services which listen or connect
to AF_UNIX sockets in the abstract namespaces might break. AF_UNIX sockets in
the file system continue to work correctly even with PrivateNetwork=yes. We
strongly recommend anyway to stop using abstract namespace AF_UNIX sockets, as
they bring very little benefit these days. If your package uses them please
consider moving them into the file system into a subdirectory in /run (system
services) or $XDG_RUNTIME_DIR (user services).
5. This also disconnects the AF_NETLINK and AF_AUDIT socket families from
the host. For services requiring auditing, that need to subscribe to network
configuration changes, or want to subscribe to hardware devices coming and
going (udev) PrivateNetwork=yes cannot be used hence.
The focus for this change is to turn one or both switches on, primarily on
long-running services, and not on services that quickly run at boot and do not
stay running continuously afterwards.
== Scope ==
* Proposal owners:
We'll file a number of bugs to more important packages where
PrivateDevices=yes and/or PrivateNetwork=yes might be applicable.
We'll also update systemd itself to make use of these options for all its own
services, where this is applicable. (DONE)
* Other developers:
Fedora developers should check whether their long-running services might be
candidates for PrivateDevices=yes and/or PrivateNetwork=yes, and if so set
these settings for their services.
* Release engineering:
Nothing required.
* Policies and guidelines:
It might be nice to update the packaging policies to also recommend making use
of these settings.