Hi George, On Wed, Dec 9, 2015 at 9:25 AM, George Mamalakis <[email protected]> wrote:
> On 08/12/2015 06:51 μμ, Robert Fisher wrote: > > IMO nothing should ever depend on boot order of nodes. If your > application requires this, its architecture is wrong. If you need A up > before B, that strongly says to me that the application running on B will > die horribly if/when A goes away, even temporarily. I've seen distributed > systems built this way due to devs taking shortcuts and it bit them > horribly further down the line. > > Staggering VM startup, to prevent a "thundering herd" is a different, far > more valid, problem. > > R > > There are situations, like boxes with ldap'ed nswitch mechanisms, where > the LDAP server needs to boot before these boxes in order for them to > acquire the appropriate information and be able to start their services > properly. I've met other plausible examples in my life as well, and even > though priority-based design has restrictions over non priority-based > design, I wouldn't call it wrong. But that's obviously very subjective. > I realise that you gave this as an example of the need for fixed startup orders, rather than this being the question you were asking for help with, however I think this may be relevant nonetheless... It is somewhat common on Linux these days to use the Red Hat-originated SSSD, rather than one of the older caching daemons such as nslcd or nscd, or raw uncached libnss-ldap. SSSD should do client-side caching of data from LDAP and allow offline operation, and it should keep its cache across reboots. I think that would help to mitigate that particular issue you raised, assuming your machines have successfully booted at least once and warmed up their cache whilst LDAP was up? To go into more detail: as SSSD is a separate daemon (plus backends), it can be reconfigured without having to restart the services that depend on it, can detect when an LDAP server has gone down, and when it has come back up -- and crucially, it can use a local cache when appropriate. This is in contrast to using old fashioned libnss-ldap (at least directly, without ns(l)cd), which IIRC tends to result in individual running programs reading in /etc/nsswitch.conf and /etc/libnss-ldap.conf once at startup and then failing to notice changes. Certainly, SSSD seems to be what the RHEL Deployment Guide recommends for setting clients up to use LDAP as an identity and authentication source: - https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Introduction.html - https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/Configuring_Domains-Configuring_a_Native_LDAP_Domain.html - https://sites.google.com/site/guenterbartsch/blog/usesssdinsteadofnslcdinldapsetuponcentosrhel6 It seems that Ubuntu also supports SSSD: - https://wiki.ubuntu.com/Enterprise/Authentication/sssd Anyway, I hope that this information is in some way helpful, and is not merely a distraction from the discussion at hand. Kind Regards, Hazel Smith ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
