F20 Self Contained Change: SSSD Smart Card Support
by Jaroslav Reznik
= 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.
10 years, 9 months
F20 Self Contained Change: Vagrant
by Jaroslav Reznik
= 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)
10 years, 9 months
F20 Self Contained Change: Sugar 0.100 (1.0)
by Jaroslav Reznik
= 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)
10 years, 9 months
F20 Self Contained Change: Apache OpenOffice
by Jaroslav Reznik
= 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/
10 years, 9 months
F20 Self Contained Change: Remove deprecated calls of using ntpdate in favor of ntpd
by Jaroslav Reznik
= 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
10 years, 9 months
F20 Self Contained Change: Snapshot and Rollback Tool
by Jaroslav Reznik
= 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
10 years, 9 months
F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
by Jaroslav Reznik
= 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)
10 years, 9 months
F20 Self Contained Change: ACPICA Tools Update
by Jaroslav Reznik
= 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)
10 years, 9 months
Rawhide tree now includes install images
by Kevin Fenzi
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
10 years, 9 months
F20 Self Contained Change: FreeIPA OTP UI
by Jaroslav Reznik
= 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)
10 years, 9 months
