devel-announce July 2013

devel-announce@lists.fedoraproject.org

6 participants
56 discussions

F20 Self Contained Change: SSSD Smart Card Support
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: SSSD Smart Card Support = https://fedoraproject.org/wiki/Changes/SSSD_Smart_Card_Support Change owner(s): Nalin Dahyabhai <nalin(a)fedoraproject.org> During the F20 development cycle, SSSD intends to add support for authenticating users using smart cards, much as it now supports doing so using passwords, and to some extent, OTP tokens. This change tracks implementation of that feature in SSSD, and if applicable or necessary, modifications to applications and PAM configurations to properly make use of this new support. == Detailed description == On a system that's using SSSD, a user should be able to log in at the console (either text or graphical) using their user name and their smart card PIN. If SSSD is configured to use a directory server, information from that server should be used to verify that the card belongs to the right user. If SSSD is configured to use Kerberos, SSSD should attempt to use the card to obtain a Kerberos TGT for the user using PKINIT. Text-mode login should handle this with minimum difficulty, since we'll just be asking the user a different question at login-time, perhaps after asking the user whether they'd like to use a password or the smart card. Graphical login programs may want to provide a fancier UI than that. == Scope == Because PAM-aware applications don't always support PAM conversations sufficiently to be able to tell a user that we're asking for a smart card PIN rather than their password, applications which do, and which want to support smart cards, may need updates to their PAM configurations to tell pam_sss to tell SSSD that they won't just ignore the text of a prompt and supply a password when SSSD is asking for a PIN. If we end up offering integration points that don't fit into the standard PAM model (unsolicited notification of card insertion and removal may force this), we may need to add a second API to SSSD to allow applications which want to take advantage of that level of integration the ability to do so. Those applications would need to be modified as well. Proposal owners: * SSSD will need to be able to handle authentication which requires multiple round trips between an SSSD client and one of its backend processes. * SSSD will need to be able to enumerate the set of smart cards that are available on the system, preferably filter that list down to the ones which are in readers attached to the same seat as the SSSD client process, and present that list to either an SSSD client or to libkrb5 (which will then present a list of things that it can use, which SSSD will massage and present to the client). * If a client supplies a PIN to use for logging in to a card, it will need to log in to the card, and verify the certificate(s) on the card. * Then, it should either use information from a directory server (the user's userCertificate attribute, for a start, or by binding to the server as an SSL client using the user's certificate and key, and then asking the server to tell us which user we've authenticated to it as) to match the card to the user, or attempt PKINIT using the card to get a Kerberos TGT for the user (this implicitly gets the KDC to do the work of matching the card to the user). Other developers: * If authconfig controls the PAM configurations for the applications which handle local login tightly enough, we'll want authconfig to add an option to their invocations of pam_sss. If not, SSSD will need to infer things based on service names. * Where authconfig currently mixes pam_sss and pam_pkcs11, it will switch to configuring just pam_sss. * We'll need to coordinate with the GDM maintainers if they want to do something fancier than that. (For example, noticing that a card has been inserted, asking SSSD if anyone's logged in using that card before, and if so, maybe adding a clickable target alongside the user name entry field to let the user skip some typing. It would make for a nice tech demo, but privacy- conscious users would want to disable it, so the less-fancy option, which provides fewer clues to a would-be attacker, needs to always be available.) Release engineering: * No mass rebuild required. * There will probably be new dependencies added to SSSD source and binary packages. Policies and guidelines: * No new packaging guidelines.

1 0

F20 Self Contained Change: Vagrant
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: Vagrant = https://fedoraproject.org/wiki/Changes/Vagrant Change owner(s): Alex Drahon <adrahon(a)redhat.com> Provide Vagrant http://www.vagrantup.com/ with the KVM plugin. == Detailed description == Vagrant is an automation tool used to manage development environments using virtualization and configuration management tools. It allows developers and teams to work on their projects and test them in an environment similar to production. Historically, Vagrant had a dependency on VirtualBox, but the newer versions have a plugin system allowing it to work with other virtualization technologies, including KVM. == Scope == Proposal owners: There's still some work to be done on the vagrant-kvm plugin to make it work seamlessly, eg. with SELinux and Firewalld, but it should be simple enough. Most of the work is about packaging Vagrant and its dependencies as rubygems RPMs and ensuring integration with the Fedora Ruby environment. 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 0

F20 Self Contained Change: Sugar 0.100 (1.0)
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: Sugar 0.100 (1.0) = https://fedoraproject.org/wiki/Changes/Sugar-0.100 Change owner(s): Peter Robinson <pbrobinson at fedoraproject dot org> Update Sugar to the new upstream 0.100 (1.0) release. == Detailed description == We want to provide the new version of the Sugar desktop environment as well as more activities to allow further building upon the collaborative environment. Users curious about the Sugar interface can test out Sugar on an existing Fedora system by selecting the Sugar environment from their display manager. Developers interested in working on the Sugar interface or writing activities can have a development platform without needing an XO laptop. New features include a new set of web services, initial release of JS Activities and a number of improvements to the Sugar UX. == Scope == Proposal owners: Peter Robinson, update Sugar 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 0

F20 Self Contained Change: Apache OpenOffice
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: Apache OpenOffice = https://fedoraproject.org/wiki/Changes/ApacheOpenOffice Change owner(s): Andrea Pescetti <pescetti(a)apache.org> Add Apache OpenOffice [1], the free productivity suite, to Fedora. == Detailed description == Apache OpenOffice (formerly OpenOffice.org) is an extremely popular free and open- source office software suite. Donated by Oracle to the Apache Software Foundation in 2011, it is now developed and supported by a thriving community; it graduated from the Apache Incubator in October 2012 and it is now an Apache Top-Level Project. Apache OpenOffice 4.0, due in the last decade of July 2013, is a major update. The two new versions (3.4.0 and 3.4.1) released in 2012 under the Apache guidance totalled 60 million downloads so far, not counting mirrors. To be clear, this proposal is about merely adding Apache OpenOffice: it doesn't affect existing office suites included in Fedora and it doesn't require that Apache OpenOffice is made the default office suite in Fedora. == Scope == Proposal owners: Packaging is the main issue here. The default OpenOffice build process produces RPM packages, but there are major changes to be done to obtain a set of RPM packages and matching SRPMs suitable for inclusion in Fedora. Version 4.0 produces packages based on the current product name: this allows to avoid name clashes with older versions of OpenOffice. The OpenOffice sources have been updated to allow a clean build with the default tools shipped with Fedora 19. The change is isolated, except some possible packaging overlap with LibreOffice, see below. Other developers: This issue was widely discussed for Fedora 19 too (the feature was then postponed to Fedora 20 since OpenOffice 4.0 was rescheduled to be released after Fedora 19). The /usr/bin/soffice and /usr/bin/unopkg executables/symlinks are still a problem since (in the Fedora packages) they would conflict between LibreOffice and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too. As discussed on the mailing lists, applications that programmatically spawn an OpenOffice/LibreOffice process may benefit of the "soffice" symlink when they need to locate an OpenOffice/LibreOffice installation. On the other hand, the current upstream LibreOffice packages do not rely on a "soffice" symlink. Anyway, some coordination will be needed, as already envisaged by FESCo for Fedora 19, to ensure a smooth user experience. The impact on the system as a whole is believed to be limited enough for this change not to be considered 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://openoffice.org/

1 0

F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd = https://fedoraproject.org/wiki/Changes/ntpdate Change owner(s): Michael Harris <MikeDawg (at) gmail (dot) com> ntpdate is slowly being depricated. STIG enhancements for RHEL 6 penalize systems that make use of ntpdate. Also documentation from the NSA Hardening Guidelines as well as CIS Hardening documentation recommends disabling the use of ntpd as a full-time daemon. == Detailed description == ntpdate is slowly being depricated in favor of ntpd. DoD STIGs now penalize for the use of ntpdate on Red Hat Enterprise systems. I would like to "modernize" the ntpdate utility to do two things. First, I would like to get rid of the dependency of ntpdate, in favor of ntpd. Second, I would like to add a set time and/or randomized time for ntpd to check for time updates (as configured by the user in /etc/sysconfig/ntpdate). I'm thinking of using ntpd with the -q option to immediately exit the daemon after it runs. == Scope == Proposal owners: Need to re-engineer the startup task for ntpdate ( /etc/init.d/ntpdate, NOT /usr/sbin/ntpdate ); or figure out if this is something that is more easily created via a cron job. Format /etc/sysconfig/ntpdate to accept additional options, as discussed above. Other developers: None Release engineering: None Policies and guidelines: None

1 0

F20 Self Contained Change: Snapshot and Rollback Tool
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: Snapshot and Rollback Tool = https://fedoraproject.org/wiki/Changes/Rollback Change owner(s): Stephen Gallagher <sgallagh(a)redhat.com>, Colin Walters <walters(a)redhat.com> With the advent of thinly-provisioned LVM pools, it has become possible for us to implement full-system LVM snapshotting for recording rollback points. We are planning to support this for yum updates and eventually fedup upgrades going forwards. This change request notes the addition of new tools provided by the roller-derby project to present an interface and a CLI for managing and initiating rollbacks. == Detailed description == The roller-derby project will be providing a library and a CLI for creating, labeling and managing LVM snapshots (plus non-LVM backups of /boot), oriented primarily towards rpm-managed data, but useful beyond that. The yum plugin "yum-plugin-fs-snapshot" will be updated to consume this library and save the system state in a compatible format. The roller-derby CLI tool will provide an interactive and scriptable interface for manipulating these snapshots and determining when to remove older ones. It will also allow the tagging of snapshots as "known-good", to be skipped when automatically-trimming for space. The roller-derby project will likely provide a small daemon to keep track of the available space in the LVM pool to proactively clean up snapshots before the system runs out of space. In order to prevent "loss" of data when rebooting into an snapshot, the roller-derby CLI will allow saving a snapshot of the current state before rolling back and will provide tools to allow mounting of that current state to recover changes that have occurred since the rollback point. == Scope == The scope of this project is the completion of the initial release of the roller-derby project and the inclusion of thinly-provisioned LVM as an option in the Anaconda installer [1]. Proposal owners: We need to complete the roller-derby project. Other than the Anaconda change referenced above, all dependencies are available in Fedora already. Other developers: OS Installer Support for LVM Thin Provisioning Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) [1] https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport

1 0

F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: OS Installer Support for LVM Thin Provisioning = https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport Change owner(s): David Lehman <dlehman(a)fedoraproject.org> LVM has introduced thin provisioning technology, which provides greatly improved snapshot functionality in addition to thin provisioning capability. This change will make it possible to configure thin provisioning during OS installation. == Detailed description == Thin Provisioning support in the installer will include a new automatic partitioning variant as well as support for thin volumes during custom storage configuration. == Scope == Proposal owners: implement Thin Provisioning functionality in the installer 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 0

F20 Self Contained Change: ACPICA Tools Update
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed Self Contained Change: ACPICA Tools Update = https://fedoraproject.org/wiki/Changes/AcpicaTools Change owner(s): Al Stone <ahs3(a)redhat.com> For developers working with the ACPI subsystem, there are tools available from the reference implementation at http://www.acpica.org. These tools have been restructured over time and the current Fedora packages as a result contain either outdated versions or do not make available a complete set of tools. We propose an acpica-tools package that replaces both the existing iasl package and the the existing pmtools package in order to make all current tools available, and make it more straightforward in the future to keep them up-to- date. == Detailed description == If a developer is working on ACPI tables for a given system, they can use the existing iasl and pm-tools packages to create and modify ACPI tables. However, there is an reference implementation of ACPI at http://acpica.org that provides a significant number of additional tools that have never been included in Fedora before -- for example, tools that allow one to create an ACPI table and execute the methods contained in the table in user space, instead of having to modify existing tables. We would propose adding all of these new tools (acpixtract, acpidebug, ...) in the new package. Further, pmtools provides the acpdiump tool that used to live at http://lesswatts.org. That site has now been abandoned by the upstream developer and subsumed into the acpica.org toolset. Hence, there is no longer an upstream for the old acpidump, but there is a shiny new version available from acpica.org. We would propose therefore replacing pmtools with the proposed new package. Finally, the old packaging did not run any of the test cases provided by the upstream developers. After some work by Linaro (see linaro.org) these tests have all been brought up to date and the new packaging for acpica-tools now runs the test suites in order to ensure the tools are functional. == Scope == Proposal owners: The majority of this work is already done (please see BZ#904843). The iasl and pmtools packages will need to be deprecated and/or removed. The acpica-tools package will need additional updates to stay in step with upstream, complete review, and be included into the git infrastructure properly. 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 0

Rawhide tree now includes install images
by Kevin Fenzi 16 Jul '13

16 Jul '13

Greetings. After consulting with various teams, release engineering has re-enabled rawhide composes to create install images again. These images were dropped as part of the 'no frozen rawhide' proposal several years ago. This allows users to use the latest boot.iso or pxe images to install rawhide instances or point to rawhide as a install-able tree. kevin

1 0

F20 Self Contained Change: FreeIPA OTP UI
by Jaroslav Reznik 16 Jul '13

16 Jul '13

= Proposed Self Contained Change: FreeIPA OTP UI = https://fedoraproject.org/wiki/Changes/IPAv3OTPUI Change owner(s): Nathaniel McCallum <npmccallum(a)fedoraproject.org> FreeIPA will gain a user interface for managing users' OTP tokens. == Detailed description == In Fedora 19 we introduced rudimentary support for OTP in krb5 and FreeIPA. Building on this work, we are creating a management system so that tokens can be managed alongside other user attributes. == Scope == Proposal owners: change development 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 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce July 2013