[Fedora-packaging] Static UIDs and GIDs

[Simo Sorce]

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/12/2013 11:35 AM, Toshio Kuratomi wrote:
> > 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).
> > 
> 
> SSSD *should* be able to handle this. It may partially depend on where
> in the boot order SSSD resides, but I think we have the unit files on
> modern systems starting SSSD very early in the process. If not, that's
> a bug that we can resolve.

We may patch sssd to be socket-activated, that would make it start as
soon as is needed. However that may not be always useful if the network
is not up yet and caches are not primed. (unless the LOCAL backend is
 being used)

Simo.

-- 
Simo Sorce * Red Hat, Inc. * New York