[SSSD-users] timeout and offline mode behaviour
jhrozek at redhat.com
Wed Jun 4 07:18:13 UTC 2014
On Tue, Jun 03, 2014 at 08:40:15AM -0400, Simo Sorce wrote:
> On Tue, 2014-06-03 at 06:36 +0000, Thomas Rücker wrote:
> > On 3 June 2014 06:25, Joschi Brauchle <joschi.brauchle at tum.de> wrote:
> > On 06/02/2014 05:39 PM, Simo Sorce wrote:
> > On Mon, 2014-06-02 at 10:34 +0200, Joschi Brauchle
> > wrote:
> > These are some of the details:
> > 1) The LDAP server has a local 192.168.x.x IP,
> > which is resolvable globally.
> > IPs in the 129.168 are not resolvable globally, they
> > are private
> > addresses and routing is not allowed outside private
> > networks.
> > What I meant is that the DNS hostname of the LDAP server
> > 'gemini.lnt.ei.tum.de' is globally resolvable to its private
> > '192.168.109.3' IP address. Unfortunately, this DNS setup
> > cannot be changed..
> > And neither can corporate firewalls be easily changed to return
> > failures instead of dropping packets. (our IPs are non-rfc1918) I know
> > it's well meant advice from Simo, but reality disagrees with the
> > implementation. Also if I read Joschi's further part of the mail
> > correctly it might even happen if the IP stack thinks it's unroutable.
> Understandable, but there are some conditions SSSD simply cannot know
> about w/o outside knowledge.
> > I agree it would be nice and preferable to just adjust the environment
> > to fit this, but many users might not be at liberty to do so.
> True, but then they need to be able to do something else at the system
> > I have a script that adds blackholes to the routing table just to work
> > around this brokenness if it detects a non-corporate network. I'd
> > rather not roll that to the corporate landscape.
> Well, one way could be to use a DNS name that simply does not resolve
> outside your network, maybe that is also not feasible, and is subject to
> caching issues too.
> Perhaps we could provide a way yo tell sssd to go permanently offline so
> you can build a script to turn this on/off based on your external
> knowledge of the network environment, would that work ?
That's an interesting thought. Do you mean having a mode (using an
option) where an offline failure would be permanent /except/ for receiving
Then the user could drop NM dispatcher scripts that would SIGUSR2 SSSD on
joining the right network.
More information about the sssd-users