On (25/07/17 12:30), Jakub Hrozek wrote:
>On Tue, Jul 25, 2017 at 12:02:06PM +0200, Lukas Slebodnik wrote:
>> On (25/07/17 11:10), Jakub Hrozek wrote:
>> >On Tue, Jul 25, 2017 at 08:39:59AM +0200, Lukas Slebodnik wrote:
>> >> On (24/07/17 18:34), Jakub Hrozek wrote:
>> >> >Hi,
>> >> >
>> >> >I would really like to release 1.15.3 soon (like, today, at worst
>> >> >tomorrow if we can't merge PR #328 and #331 today). The release
notes
>> >> >are here:
>> >> >
https://pagure.io/fork/jhrozek/SSSD/docs
>> >> >
>> >> >You can either clone the repo and run 'make html' or, for
your
>> >> >convenience, I'm pasting the RST-formatted release notes
below:
>> >> >
>> >> >SSSD 1.15.3
>> >> >===========
>> >> >
>> >> >Highlights
>> >> >----------
>> >> >
>> >> >New Features
>> >> >^^^^^^^^^^^^
>> >> > * In a setup where an IPA domain trusts an Active Directory
domain,
>> >> > it is now possible to `define the domain resolution order
>> >> >
<
http://www.freeipa.org/page/Releases/4.5.0#AD_User_Short_Names>`_.
>> >> > Starting with this version, SSSD is able to read and honor the
domain
>> >> > resolution order, providing a way to resolve Active Directory
users by
>> >> > just their short name. SSSD also supports a new option
>> >> > ``domain_resolution_order`` applicable in the ``[sssd]``
section
>> >> > that allows to configure short names for AD users in setup with
>> >> > ``id_provider=ad`` or in a setup with an older IPA server that
doesn't
>> >> > support the ``ipa config-mod --domain-resolution-order``
>> >> > configuration option. Also, it is now possible to use
>> >> > ``use_fully_qualified_names=False`` in a subdomain
configuration, but
>> >> > please note that the user and group output from trusted domains
will
>> >> > always be qualified to avoid conflicts.
>> >> >
>> >> > * Design page - `Shortnames in trusted domains
<
https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html>`_
>> >> >
>> >> > * SSSD ships with a new service called KCM. This service acts as
a
>> >> > storage for Kerberos tickets when ``libkrb5`` is configured to
use
>> >> > ``KCM:`` in ``krb5.conf``. Compared to other Kerberos
credential
>> >> > cache types, KCM is better suited for containerized environments
and
>> >> > because the credential caches are managed by a stateful daemon,
in
>> >> > future releases will also allow to renew tickets acquired
outside SSSD
>> >> > (e.g. with ``kinit``) or provide notifications about ticket
changes.
>> >> >
>> >>
>> >> Maybe we can mention that it is an optional feature and can be
disabled
>> >> at configure time if users does not want additional build/runtime time
>> >> dependencies.
>> >
>> >Done
>> >
>> >>
>> >>
>> >> > * Design page - `KCM server for SSSD
<
https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html>`_
>> >> >
>> >> > * `NOTE`: There are several known issues in the ``KCM``
responder that
>> >> > will be handled in the next release such as
>> >> > `issues with very large tickets
<
https://pagure.io/SSSD/sssd/issue/3386>`_
>> >> > or `tracking the SELinux label of the peer
<
https://pagure.io/SSSD/sssd/issue/3434>`_
>> >> >
>>
>> I have two ideas here.
>>
>> BTW, I've just realized that we might mention known crash(which might be a
>> corner case)
https://bugzilla.redhat.com/show_bug.cgi?id=1446302#c26
>> And also clone it to upstream :-)
>
>Well, did we reproduce the crash after fixing the NSS/NSPR teardown?
>
Backtrace is different then in NSS/NSPR teardown.
>I also wonder if just tagging all issues that are KCM-related in trac
>with a single tag and saying 'known issues can be found at
>http://blabla" would be better?
>
That might be confusing if we triage some ticket to future releases.
Because basically all bugs are known issues. We might mention just
most important ones. But on the other hand it was not very simple to reproduce
it. So we needn't mention it.
>>
>> We might also mention that root will not directly see users credentials;
>> which is a difference comparing to kernel keyring or FILE.
>>
https://pagure.io/SSSD/sssd/issue/3376
>> But root can use "su user -c /usr/bin/klist"
>
>We can, but I wonder if (because this is not going to chage) it would be
>more useful to say in general that there are some differences compared
>to Heimdal that are described in the manual page..
I had an impression that we will introduce an option to allow it.
https://pagure.io/SSSD/sssd/issue/3376/#comment-438541
Yes, but the default will never change. But we can do both -- change the
release notes (done) and then later amend the manpage by fixing