[Fedora-packaging] Static UIDs and GIDs

Toshio Kuratomi a.badger at gmail.com
Fri Apr 12 15:35:28 UTC 2013


On Fri, Apr 12, 2013 at 09:35:27AM -0400, Tom Lane wrote:
> Stephen Gallagher <sgallagh at redhat.com> writes:
> > On 04/11/2013 03:30 PM, "J??hann B. Gu??mundsson" wrote:
> >> Based on experience storing system related uid's and gid's in ldap
> >> is a bad idea ( what happens if you cant reach your ldap )
> 
> > That was true once upon a time, but I'd like to mention that in the
> > era of SSSD for user-ID lookups, there are a great many deployments
> > out there using LDAP for such IDs quite successfully.
> 
> Is this new technology since, um, January?  Because I was told as
> recently as January that you can't rely on systemd knowing about
> UIDs that are defined in LDAP:
> https://bugzilla.redhat.com/show_bug.cgi?id=894750#c4
> 
> The context there was that any service with tmpfiles.d entries had
> better have uid/gid that are known at poweron.  Reliably, not just
> most of the time.  I'm uninterested in somebody telling me they'll
> cache the values, because *I* get the bug report when it doesn't work.
> 
I've made a note in the ticket to look at wording around LDAP when I start
changing the draft.  I do note that lennart mentioned SSSD as a way to make
LDAP suitable though:

"""
 There are solutions for that (i think sssd can cache that for you), but as
 system users are generally managed by postinst scripts, and hence are more
 under the ownership of the OS than the admin I'd not bother.
"""

So I'm not certain I should vastly discourage the use of LDAP for system
accounts.  If LDAP + SSSD does work reliably then packages should probably
support that use case even if they don't cater specifically to it (and a
preallocation-based policy would allow that).

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20130412/9a500420/attachment.sig>


More information about the packaging mailing list