-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/24/2010 10:38 AM, Jakub Hrozek wrote:
On 03/24/2010 03:10 PM, Simo Sorce wrote:
> On Wed, 24 Mar 2010 10:04:14 -0400
> Simo Sorce <ssorce(a)redhat.com> wrote:
>> On Wed, 24 Mar 2010 14:51:07 +0100
>> Jakub Hrozek <jhrozek(a)redhat.com> wrote:
>>
>>> Packages /etc/rwtab.d/sssd file that allows SSSD to run on a
>>> read-only root filesystem.
>>
>> NACK.
>>
>> The way rwtab normally works is that it creates a tmpfs and symlinks
>> or bind mounts it to the locations given by rwtab.
>>
>> But this means the data will be discarded at the first reboot.
>>
>> SSSD data is not just cache, sssd.ldb has to survive across reboots so
>> this approach is wrong. True sssd will start and work, except you will
>> loose everything on reboot.
>>
>> I do not want to endorse, make it easy or even recommend to create
>> such a broken configuration.
>>
>> /var/lib has to be writable and not shared if you want to run some
>> services, and if you want it read-only/shared/etc you better not use
>> sssd.
> Just to be clear, I am not saying we should actively prevent use of
> sssd on stateless machines, but sssd by its very nature is not
> stateless, so if an admin wants to use it in a stateless way he has to
> make the choice consciously and explicitly and evaluate if it makes
> sense or not.
I agree with this. But I think that this explicit decision is made when
the admin opts for stateless machines. And when he makes it, I think our
software should just work - or the subset that makes sense on a
stateless machine.
Even on a clean, pristine Fedora install, there is a file /etc/rwtab
that contains many entries - some even specific to a certain package
like /var/puppet. Unless you change your configuration to a ro root,
these don't have any effect - and so does the file in this patch have no
effect until the admin starts using ro root.
> sssd can still give some benefits as it can better cache some things
> reducing load on an ldap server or as a showcase in a livecd, but will
> also loose all the good stuff like being able to login offline after a
> reboot.
I don't think anyone expects that from a stateless client. Caching the
NSS and PAM data between reboots is a win on its own.
> So given that sssd would loose a consitent set of its features on a
> stateless machine we shouldn't make it work on there by default IMO.
> Simo.
I agree with Jakub here. I think it's perfectly acceptable to include
the SSSD in the rwtab. A person using a read-only root is probably doing
so BECAUSE they don't care about persistence across reboots. In these
cases, having our SSSD as a cache while the machine is up is still
advantageous, because it allows the machine to survive a remote auth
server outage.
Yes, we'll lose the cache on reboot, and we will be unable to use SSSD
for a provider=local setup, but I very much doubt that anyone would be
using it for anything other than a reliable cache in this situation.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAkuqdlEACgkQeiVVYja6o6Nf6ACgk0UTF/1DpUWRMMBrSoOTMyOY
NBsAmgM2xSryydKnylp3yEO9p2/CbJ0p
=5jRd
-----END PGP SIGNATURE-----