devel July 2013

devel@lists.fedoraproject.org

308 participants
304 discussions

Summary/Minutes for today's FESCo meeting (2013-07-17)
by Miloslav Trmač 17 Jul '13

17 Jul '13

#fedora-meeting: FESCO (2013-07-17) =================================== Meeting started by mitr at 18:00:48 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-07-17/fesco.2013-07-17… . Meeting summary --------------- * init process (mitr, 18:00:54) * ACTION: mitr Update FESCo meeting process page for election results (mitr, 18:04:26) * #1132 libtool + %global _hardened_build 1 = no full hardening (mitr, 18:05:53) * LINK: https://fedorahosted.org/fesco/ticket/1132 (mitr, 18:05:57) * AGREED: apply kludge to redhat-rpm-config now, ask libtool maintainer to come up with a more sustainable/better fix in libtool and drop kludge when no longer needed (+5) (mitr, 18:15:49) * #1135 F20 System Wide Change: Fedora 20 Boost 1.54 Uplift - (mitr, 18:16:50) * LINK: https://fedoraproject.org/wiki/Changes/F20Boost154 (mitr, 18:16:52) * LINK: https://fedorahosted.org/fesco/ticket/1135 (mitr, 18:16:56) * AGREED: F20 System Wide Change: Fedora 20 Boost 1.54 Uplift was accepted (+6) (mitr, 18:19:12) * #1137 F20 Self Contained Changes (mitr, 18:19:32) * LINK: https://fedorahosted.org/fesco/ticket/1137 (mitr, 18:19:36) * LINK: https://fedoraproject.org/wiki/Changes/SharedCertificateTools (mitr, 18:21:38) * LINK: https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM (mitr, 18:21:42) * LINK: https://lists.fedoraproject.org/pipermail/devel-announce/2013-July/001181.h… (mitr, 18:21:50) * LINK: https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots (mitr, 18:21:54) * AGREED: Self-contained changes from ticket #1137 are accepted (+7) (mitr, 18:23:10) * #1136 F20 System Wide Change: ARM as primary Architecture - (mitr, 18:23:25) * LINK: https://fedoraproject.org/wiki/Changes/ARM_as_Primary (mitr, 18:23:27) * LINK: https://fedorahosted.org/fesco/ticket/1136 (mitr, 18:23:31) * LINK: http://stg.fedoraproject.org/en/get-fedora-options#2nd_arches (nirik, 18:31:07) * AGREED: "build ARM on primary infrastructure. whether it is released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time" (+5) (mitr, 19:24:46) * Next week's chair (mitr, 19:25:08) * Marcela has volunteered to be the next week's chair (mitr, 19:25:10) * Open Floor (mitr, 19:25:15) * Mass rebuild - https://fedorahosted.org/rel-eng/ticket/5655 (mitr, 19:25:43) * ACTION: mitr ask Perl SIG to think about ways of speeding the Perl rebuild up (mitr, 19:39:13) * There is a Koji storage outage tomorrow/friday (mitr, 19:39:38) * AGREED: start mass rebuild as soon as perl rebuild is merged back and redhat-rpm-config is patched for libtool, but no earlier than Jul 20 (+6) (mitr, 19:40:45) * Open Floor (mitr, 19:40:49) * LINK: https://fedoraproject.org/wiki/Changes/NoBinDeps -- submitted this week so I don't know if we want to discuss it -- I think the question as stated in the Change is not a Change but an FPC issue -- but it would be helpful to FPC if fesco discussed the basic issue of whether we want UsrMove to imply that we've "merged /bin with /usr/bin" or that we've "replaced /bin with /usr/bin" (abadger1999, 19:40:58) * AGREED: FESCo prefers "merged /bin and /usr/bin" (mitr, 19:51:01) Meeting ended at 19:53:38 UTC. Action Items ------------ * mitr Update FESCo meeting process page for election results * mitr ask Perl SIG to think about ways of speeding the Perl rebuild up

1 0

F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin
by Jaroslav Reznik 17 Jul '13

17 Jul '13

= Proposed System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin = https://fedoraproject.org/wiki/Changes/NoBinDeps Change owner(s): Ales Kozumplik <ales(a)redhat.com> Disallow dependencies on files under /bin, /sbin, /lib and /lib64. == Detailed description == The current packaging guidelines read: "Whenever possible you should avoid file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin." I propose changing this to: "Whenever possible you should avoid file dependencies outside of /etc, /usr/bin, or /usr/sbin." Related FPC ticket [1]: FPC wanted this change to be created. == Scope == Proposal owners: None Other developers: replace all explicit /bin/<foo> requires with /usr/bin/<foo>. Release engineering: N/A Policies and guidelines: update the packaging guidelines accordingly. [1] https://fedorahosted.org/fpc/ticket/314 _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

17 23

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. _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

1 0

Fwd: F20 Self Contained Change: Shared Certificate Tools
by Toshio Kuratomi 17 Jul '13

17 Jul '13

On Wed, Jul 10, 2013 at 01:22:37PM +0200, Jaroslav Reznik wrote: > > Because not all crypto implementations read their trusted information directly > from the dynamic database, the tool will take care of extracting things as > appropriate after making a change. This will enable administrators to run a > single command to add an anchor (and perform other tasks). > So it sounds like this is a modify and sync strategy? Are there other tools in the distribution that may modify the primary or the sync'd certificates that need to be changed so that they don't step on what p11-kit is doing? -Toshio

2 1

cdrkit ported from cdparanoia to libcdio-paranoia
by Frantisek Kluknavsky 17 Jul '13

17 Jul '13

Hi, cdrkit-1.1.11-18 just entered rawhide, patched to use libcdio-paranoia instead of cdparanoia. Most affected subpackages are probably wodim and icedax. Dirsplit, libusal and genisoimage not that much. This change can break popular burning frontends (k3b, brasero, ...) if done poorly. Please test. Thank you very much. Frantisek Kluknavsky

1 0

Schedule for Thursday's FPC Meeting (2013-07-18 16:00 UTC)
by Jason L Tibbitts III 17 Jul '13

17 Jul '13

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2013-07-18 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-07-18 09:00 Thu US/Pacific PDT 2013-07-18 12:00 Thu US/Eastern EDT 2013-07-18 16:00 Thu UTC <- 2013-07-18 17:00 Thu Europe/London BST 2013-07-18 18:00 Thu Europe/Paris CEST 2013-07-18 18:00 Thu Europe/Berlin CEST 2013-07-18 21:30 Thu Asia/Calcutta IST ------------------new day---------------------- 2013-07-19 00:00 Fri Asia/Singapore SGT 2013-07-19 00:00 Fri Asia/Hong_Kong HKT 2013-07-19 01:00 Fri Asia/Tokyo JST 2013-07-19 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = #topic #304 asking for bundling exception for the package "rubygem-rdiscount" .fpc 304 https://fedorahosted.org/fpc/ticket/304 #topic #310 Request review of httpd-itk .fpc 310 https://fedorahosted.org/fpc/ticket/310 = New business = #topic #311 Node.js guidelines update .fpc 311 https://fedorahosted.org/fpc/ticket/311 #topic #312 Architecture specific header files .fpc 311 https://fedorahosted.org/fpc/ticket/312 #topic #314 proposed packaging guidelines change: https://fedoraproject.org/wiki/User:Akozumpl/No_bin_deps .fpc 314 https://fedorahosted.org/fpc/ticket/314 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

Fedora ARM Weekly Status Meeting 2013-07-17
by Paul Whalen 17 Jul '13

17 Jul '13

Good day all, Please join us today (Wednesday, July 17th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Kernel Status Update 3) Aarch64 - Status Update, problem packages - Moving to Koji update 4) F20 PA Promotion Criteria discussion 5) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list.

1 0

Why can't ExecStopPre= be used to abort stopping a (broken) service?
by Paul Wouters 17 Jul '13

17 Jul '13

Hi, For daemons, it happens that people (or puppet/ansible) makes a config change that causes the config file to not load and be invalid. When restarting the service, it will stop but not start. Ideally, the stop should be aborted. I was looking at ExecStopPre= (which is mentioned in the systemd.service man page, although it does not have its own section, so is easilly missed) but it did not abort the stop on a parse error in the daemon's config file. I found this note by Lennart: http://osdir.com/ml/fedora-devel-list/2011-05/msg00696.html No, ExecStopPre= cannot be used for making shutdown of a service conditional. Even if one of the pre lines fails we will go on with shutting down the service, however we will store the exit code and the service will be in "failed" state once fully shut down. My question is, why not? Various daemons (libreswan, bind, knot, nsd, etc) have a "check config" option that could be used to prevent stopping a service if the config file got messed up so it would prevent the service from starting. I realise that it is not optimal to keep a service running that will fail to restart on the next machine boot, but is that preferable over failing immediately? If ExecStopPre= would fail and log a message, sysadmins would be able to notice the issue and fix it. And there would be 0 downtime. As opposed to the current behaviour, which kills the service. However, if ExecStopPre= would support this, then every maintainer could choose for themselves which situation is preferred. Paul

6 11

Re: F20 System Wide Change: No Default Syslog
by Denys Vlasenko 17 Jul '13

17 Jul '13

On 07/17/2013 03:00 PM, drago01 wrote: > On Wed, Jul 17, 2013 at 2:57 PM, Denys Vlasenko <dvlasenk(a)redhat.com> wrote: >> On 07/17/2013 02:45 PM, drago01 wrote: >>>>> instead of administrators simply adding rsyslog or syslog-ng manually >>>>> at install time or to their ks snippets. >>>> >>>> And this too was answered several times already. >>>> The machine in question may be already borked. >>>> Our support people will need to figure out - >>>> over the phone or email! - what has happened on client's >>>> installation, and having traditional grep/sed/awk >>>> recipes not working anymore because /var/log/messages >>>> is not there anymore is an extremely unwelcome discovery >>>> in an emergency. >>> >>> You can use grep / sed / awk on the jounrnal output as well. >> >> Please do read the text you are replying to. > > I did. Okay, I will try explaining with an example. A support engineer receives a panicked call from a customer. "Help, something wrong with our server!!!oneone". Engineer does not know what version of OS that server runs, what is installed there and how it is configured. So it needs to be investigated. Quite a typical situation. Engineer asks customer whether he has root login to the server. Customer has it. Then engineer asks to run "tail /var/log/messages". Customer says: "I see cannot open ‘/var/log/messages’: No such file or directory message". Great, isn't it? Engineer asks to run journalctl. Customer says: "I see 'Input/output error' message".

6 9

systemd network-online.target question
by Kaleb S. KEITHLEY 17 Jul '13

17 Jul '13

I need glusterd to start before any _netdev mounts (NFS or glusterfs) take place. reading the system.special man page it talks about ...pulling in network-online.target and order themselves after it. Would adding a Before=network-online.target to the glusterd.service be the right thing to do or is there a better solution? (It already has After=network.target rpcbind.service) Thanks, -- Kaleb

2 4

← Newer
1
...
13
14
15
16
17
18
19
...
31
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2013