On Tue, Jul 25, 2017 at 12:50:20PM +0200, Lukas Slebodnik wrote: > 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 https://pagure.io/SSSD/sssd/issue/3455 _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
