Releasing ownership
by Lakshmi Narasimhan T V
I am releasing ownership of the following packages due to lack of time
chm2pdf -- A tool to convert CHM files to PDF files
emacs-slime -- The superior lisp interaction mode for emacsgnome-guitar --
A small suite of applications for the guitaristgriffith -- Media collection
managerphatch -- Photo batch processorpython-chm -- Python package for CHM
files handlingstow -- Manage the installation of software packages from
sourcexcftools -- Command-line tools for extracting information from XCF
files
11 years, 2 months
Proposed F19 Feature: systemd features
by Jaroslav Reznik
Announcing various systemd features in one announcement, see bellow:
= Features/SystemdCalendarTimers =
https://fedoraproject.org/wiki/Features/SystemdCalendarTimers
Feature owner(s): Lennart Poettering <lennart at poettering dot net>
systemd has supported timer units for activating services based on time since
its inception. However, it only could schedule services based on monotonic
time events (i.e. "every 5 minutes"). With this feature in place systemd also
supports calendar time events (i.e. "every monday morning 6:00 am", or "at
midnight on every 1st, 2nd, 3rd of each month if that's saturday or sunday").
= Features/SystemdHardwareDatabase =
https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase
Feature owner(s): Kay Sievers <kay at redhat dot com>
The udevd service has a long history of managing kernel devices. Besides
generating events when devices are discovered or removed it maintains a
dynamic, stateless database of all available devices including meta data about
them. With Fedora 19 we want to substantially enhance the metadata that udev
keeps for each device, by augmenting it from a userspace database of non-
essential information, that is indexed by device identification data such as
PCI/USB vendor/product IDs.
= Features/SystemdLightweightContainers =
https://fedoraproject.org/wiki/Features/SystemdLightweightContainers
Feature owner(s): Lennart Poettering <lennart at poettering dot net>
For a longer time systemd already included the systemd-nspawn tool as a more
powerful version of chroot(1), primarily inteded for use in development,
experimenting, debugging, instrumentation, testing and building of software.
With Fedora 19 we want to make nspawn considerably more useful, so that it can
easily be used to start containers capable of booting up a complete and
unmodified Fedora distribution inside as normal system services.
= Features/SystemdMessageCatalog =
https://fedoraproject.org/wiki/Features/SystemdMessageCatalog
Feature owner(s): Lennart Poettering <lennart at poettering dot net>
Logging is essential for finding and tracking down system problems. Just finding
and tracking them down however is seldom enough to actually get them fixed.
With Journal Message Catalogs we want to link helpful meta information
directly to many log messages applications generate, keyed off an ID
identifying the type of message. This localized meta information can help the
user to fix the problem, refer him to additional documentation, or even inform
him where to get further help.
= Features/SystemdResourceControl =
https://fedoraproject.org/wiki/Features/SystemdResourceControl
Feature owner(s): Lennart Poettering <lennart at poettering dot net>
systemd already has support for assigning specific resources to system services
using various configuration settings. With Fedora 19 we'd like to build on
that, and add the ability for the admin to dynamically query the resource
control parameters and change them at runtime.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: System Configuration Shell
by Jaroslav Reznik
= Features/SystemConfigurationShell =
https://fedoraproject.org/wiki/Features/SystemConfigurationShell
Feature owner(s): Tom Schwaller <tom dot schwaller at web dot de>
The System Configuration Shell System provides an easy to use interactive
command line interface with a standardized syntax to manage your system.
== Detailed description ==
Network Administrators love their very powerful switch/router/firewall/etc. CLI
which can be used for all administrative tasks in a very structured and well
documented way. Compare that to classical Linux System Administration which is
a mix of editing configuration files using different formats and executing
commands & scripts with a heterogeneous syntax. The System Configuration Shell
will provide an interactive command line interface using the python-configshell
framework with a standardized syntax to manage your system. It consists of the
command configsh which starts an interactive shell and can also be used in
shell scripts and the command config for one-shot configuration commands (e.g.
config hostname www.fedoraproject.org which not only executes hostname
www.fedoraproject.org but also changes several configuration files to make the
new hostname permanent).
The System Configuration Shell will facilitate the Linux System administrators
daily work. Since every command is logged (in a verbose mode even showing the
exact system commands and scripts executed), each administrator can decide
him/herself if he/she feels comfortable using standard parts (or local
extensions) the System Configuration Shell. The approach is similar to the
OpenWrt UCI Command Line Utility or the Vyatta vbash but using a different
approach.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: Less Brittle Kerberos
by Jaroslav Reznik
= Features/LessBrittleKerberos =
https://fedoraproject.org/wiki/Features/LessBrittleKerberos
Feature owner(s): Stef Walter <stefw(a)redhat.com>
Make kerberos in Fedora simpler to use by removing some of the brittleness
that are common failure points. In particular we remove the need for kerberos
clients to sync their clocks, and remove the need to have reverse DNS records
carefully setup for services.
== Detailed description ==
MIT kerberos 1.11 now contains work so that clients do not have to sync their
system clocks with that of the KDC. A time offset is discovered during preauth
and stored along with the local credentials. This removes a common point of
failure when using kerberos.
Kerberos clients can optionally verify reverse DNS records for services that
they connect to as a way of trying to identify which realm they belong to.
However in many cases these do not exist. Kerberos should fall back to it's
default behavior in that case. Failure to do this is a common point of failure
when using kerberos.
Further enhancements will be included in kerberos 1.11:
* http://k5wiki.kerberos.org/wiki/Projects/Responder (for 1.11)
* http://web.mit.edu/kerberos/krb5-latest/
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: CUPS 1.6
by Jaroslav Reznik
= Features/CUPS1.6 =
https://fedoraproject.org/wiki/Features/CUPS1.6
Feature owner(s): Tim Waugh <twaugh(a)redhat.com>, Jiri Popelka
<jpopelka(a)redhat.com>
Update CUPS to the latest upstream release and use PDF rather than PostScript
as baseline document format.
== Detailed description ==
CUPS 1.6 was released in July 2012 and has brought several important changes
* Merged Fedora's patch for color management using colord
* Merged Fedora's patch for mDNS/DNS-SD support using Avahi
* Removed support for CUPS Browsing and Polling
* The CUPS Browsing protocol is currently the primary mechanism for CUPS-
to-CUPS printer queue discovery on Linux. It works by having each CUPS server
periodically broadcast UDP packets on port 631 announcing its available
queues, and listening for broadcasts from other CUPS servers. CUPS Browsing
protocol has no longer been meeting the requirements of current networking
technologies, and in fact has had some bad effects on wireless networks due to
the use of UDP broadcasts. Rather than trying to address these issues by
introducing a new and incompatible update to the protocol, the existing
mDNS/DNS-SD standards can serve as a ready replacement and actually has been
used in CUPS for many years now.
* All filters and backends not used by Mac OS X have been dropped
* These filters and backends, together with the filters for the PDF printing
workflow are now hosted as the cups-filters project at linuxfoundation.org.
PDF printing workflow
* Currently CUPS uses PostScript as the common format for manipulating print
jobs. We want to switch the standard print job transfer format from PostScript
to PDF, which has many important advantages.
* Additional filters for the PDF printing workflow have been added to the cups-
filters project.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: NetworkManager Bridging Support
by Jaroslav Reznik
= Features/NetworkManagerBridging =
https://fedoraproject.org/wiki/Features/NetworkManagerBridging
Feature owner(s): Pavel Šimerda <psimerda at redhat.com>, Dan Williams <dcbw
at redhat dot com>
NetworkManager should be able to configure bridge interfaces with commonly used
options and recognize their existing configuration on startup without
disrupting their operation.
== Detailed description ==
A bridge connects two or more physical or virtual network interfaces to allow
network traffic to flow between the two interfaces at a low level. Bridging is
commonly used to connect Virtual Machines to the outside world; a bridge
interface is created, to which a physical interface (typically ethernet) is
assigned as a slave, and a virtual interface (typically TAP) is created and
also assigned to the bridge as a slave, and then given to the Virtual Machine.
Thus traffic from one or more VMs can be combined and sent out of the machine
via the physical interface.
This setup is currently done either manually using ifcfg files and ifup/ifdown,
or by a tool like libvirt/netcf. NetworkManager should be able to configure
bridge interfaces and their slaves with the same functionality as provided by
libvirt, and should recognize and not disrupt existing bridge connections when
it starts up.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: Usermode Migration
by Jaroslav Reznik
= Features/UsermodeMigration =
https://fedoraproject.org/wiki/Features/UsermodeMigration
Feature owner(s): Harald Hoyer <harald(a)redhat.com>, Kay Sievers
<kay(a)redhat.com>, Bill Nottingham <notting(a)redhat.com>
Access control of privileged operations for ordinary users should be handled
exclusively by a centrally managed authority.
Usermode/consolehelper should be phased out and be replaced entirely by
polkit.
== Detailed description ==
The usermode/consolehelper program is a setuid-root wrapper around a couple of
system tools, providing superuser privileges to ordinary users. Its policy is
controlled by text files in /etc.
These days, most privileged system operations are already controlled by
polkit, a well-established, fine-grained, (possibly) network-transparent
service for managing privileged operations by ordinary users. Enterprise
environments need to be able to centrally define access control policy for the
organization, and automatically apply it to all connected workstations.
* polkit can be used by privileged processes to decide if it should execute
privileged operations on behalf of the requesting user. For directly executed
tools, polkit provides a setuid-root helper program called ‘’pkexec’’.The
hooks to ask the user for authorizations are well-integrated into text
environments, and native in all major graphical environments.
* The concept of a ''console user'' (that usermode/consolehelper implements)
is no longer a sufficient concept to derive privileges from. OTOH polkit
authorizations can properly distinguish between multiple active sessions and
seats: e.g. an untrusted user’s reboot request is only granted if only a
single user session runs at that time.
Btw. this Feature was already accepted for Fedora 18 and it's continuous effort
spread over several releases.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months