Summary/Minutes for today's FESCo meeting (2013-07-17)
by Miloslav Trmač
#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-...
.
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...
(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
10 years, 9 months
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.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
10 years, 9 months
Fwd: F20 Self Contained Change: Shared Certificate Tools
by Toshio Kuratomi
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
10 years, 9 months
cdrkit ported from cdparanoia to libcdio-paranoia
by Frantisek Kluknavsky
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
10 years, 9 months
Fedora ARM Weekly Status Meeting 2013-07-17
by Paul Whalen
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.
10 years, 9 months
Why can't ExecStopPre= be used to abort stopping a (broken) service?
by Paul Wouters
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
10 years, 9 months
Re: F20 System Wide Change: No Default Syslog
by Denys Vlasenko
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".
10 years, 9 months
systemd network-online.target question
by Kaleb S. KEITHLEY
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
10 years, 9 months
