-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Packages /etc/rwtab.d/sssd file that allows SSSD to run on a read-only root filesystem.
Fixes: #428
The original reported wouldn't be able to test for a couple of days, but I did some testing (LDAP identity + Kerberos auth), so I think we can at least review if the patch is correct.
On Wed, 24 Mar 2010 14:51:07 +0100 Jakub Hrozek jhrozek@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.
Simo.
On Wed, 24 Mar 2010 10:04:14 -0400 Simo Sorce ssorce@redhat.com wrote:
On Wed, 24 Mar 2010 14:51:07 +0100 Jakub Hrozek jhrozek@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.
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.
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.
Simo Sorce wrote:
On Wed, 24 Mar 2010 10:04:14 -0400 Simo Sorce ssorce@redhat.com wrote:
On Wed, 24 Mar 2010 14:51:07 +0100 Jakub Hrozek jhrozek@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.
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.
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.
Simo,
I think that this limitation should be documented. It is the admin's choice to use SSSD on such system or not but if he does he should be warned and accept limitations that SSSD would not fully function. I do not see a reason to NACK the patch on the grounds you mentioned. If there is a better solution sure but if this is the limitation of the read only system then let us do the best we can offer (which the current fix provides) than just dismiss the claim as you suggest.
I suggest Steve and original bug reporter to chime in.
Thanks Dmitri
On Wed, 24 Mar 2010 10:22:51 -0400 Dmitri Pal dpal@redhat.com wrote:
Simo,
I think that this limitation should be documented. It is the admin's choice to use SSSD on such system or not but if he does he should be warned and accept limitations that SSSD would not fully function. I do not see a reason to NACK the patch on the grounds you mentioned. If there is a better solution sure but if this is the limitation of the read only system then let us do the best we can offer (which the current fix provides) than just dismiss the claim as you suggest.
I suggest Steve and original bug reporter to chime in.
The only problem I have is that by adding this in by default, someone may not realize what is going on, and SSSD has no way to warn as it just works.
Of course we can decide that that's ok and the admin is just getting what he asked for, I am open to discuss, and if most think we should get it in, I am ok.
Simo.
Simo Sorce wrote:
On Wed, 24 Mar 2010 10:22:51 -0400 Dmitri Pal dpal@redhat.com wrote:
Simo,
I think that this limitation should be documented. It is the admin's choice to use SSSD on such system or not but if he does he should be warned and accept limitations that SSSD would not fully function. I do not see a reason to NACK the patch on the grounds you mentioned. If there is a better solution sure but if this is the limitation of the read only system then let us do the best we can offer (which the current fix provides) than just dismiss the claim as you suggest.
I suggest Steve and original bug reporter to chime in.
The only problem I have is that by adding this in by default, someone may not realize what is going on, and SSSD has no way to warn as it just works.
May be some kind of warning in the log and syslog would be sufficient. For example if we detect that the root is RO we can output some sort of message into syslog. If it is a RO would the syslog be on the NFS or some other writable media? Or the common practice to use rsyslog in this case? Anyways, a message like: "Read only file system detected. Some of the SSSD functionality will be disabled. See documentation for more details." would go a long way towards alerting admin. The enabling it by default might be fine then.
Thoughts?
Of course we can decide that that's ok and the admin is just getting what he asked for, I am open to discuss, and if most think we should get it in, I am ok.
Simo.
On Wed, 24 Mar 2010 10:38:24 -0400 Dmitri Pal dpal@redhat.com wrote:
May be some kind of warning in the log and syslog would be sufficient. For example if we detect that the root is RO we can output some sort of message into syslog. If it is a RO would the syslog be on the NFS or some other writable media? Or the common practice to use rsyslog in this case? Anyways, a message like: "Read only file system detected. Some of the SSSD functionality will be disabled. See documentation for more details." would go a long way towards alerting admin. The enabling it by default might be fine then.
Thoughts?
I don't want to add code to detect a read-only filesystem, it's not sssd's job.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/24/2010 03:10 PM, Simo Sorce wrote:
On Wed, 24 Mar 2010 10:04:14 -0400 Simo Sorce ssorce@redhat.com wrote:
On Wed, 24 Mar 2010 14:51:07 +0100 Jakub Hrozek jhrozek@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.
-----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@redhat.com wrote:
On Wed, 24 Mar 2010 14:51:07 +0100 Jakub Hrozek jhrozek@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/
On Wed, 24 Mar 2010 16:30:09 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
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.
Ok, it looks like most are ok with it, I retire my objection.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/24/2010 05:46 PM, Simo Sorce wrote:
On Wed, 24 Mar 2010 16:30:09 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
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.
Ok, it looks like most are ok with it, I retire my objection.
Simo.
Pushed to master.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org