[SSSD-users] timeout and offline mode behaviour

Jakub Hrozek 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
> level.
> 
> > 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
signals?

Then the user could drop NM dispatcher scripts that would SIGUSR2 SSSD on
joining the right network.


More information about the sssd-users mailing list