devel-announce March 2014

devel-announce@lists.fedoraproject.org

7 participants
34 discussions

F21 Self Contained Change: Improved Ivy Packaging
by Jaroslav Reznik 31 Mar '14

31 Mar '14

= 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

1 0

F21 Self Contained Change: Better Erlang Support
by Jaroslav Reznik 31 Mar '14

31 Mar '14

= 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

1 0

F21 System Wide Change: GCC49
by Jaroslav Reznik 31 Mar '14

31 Mar '14

= 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/

1 0

F21 Self Contained Change: Apache Hive
by Jaroslav Reznik 31 Mar '14

31 Mar '14

= 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/

1 0

F21 Self Contained Change: Apache HBase
by Jaroslav Reznik 31 Mar '14

31 Mar '14

= 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/

1 0

F21 Self Contained Change: Apache Oozie
by Jaroslav Reznik 31 Mar '14

31 Mar '14

= 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

1 0

Planned Outage: Mass reboots/Upgrades - 2014-04-01 21:00 UTC
by Kevin Fenzi 28 Mar '14

28 Mar '14

Planned Outage: Mass reboots/Upgrades - 2014-04-01 21:00 UTC There will be an outage starting at 2014-04-01 21: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 '2014-04-01 21:00 UTC' Reason for outage: We will be rebooting all servers to pick up the latest system updates. Additionally we will be upgrading the koji build system to 1.9.0. During the outage window some services may be down and then back up again, but no single service should be down more than a few minutes, and some services may not be affected at all. Affected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4280 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

F21 Self Contained Change: Apache Mesos
by Jaroslav Reznik 26 Mar '14

26 Mar '14

= 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/

1 0

F21 Self Contained Change: DNSSEC support for FreeIPA
by Jaroslav Reznik 26 Mar '14

26 Mar '14

= 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)

1 0

F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services
by Jaroslav Reznik 26 Mar '14

26 Mar '14

= 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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2014