[SSSD-users] timeout and offline mode behaviour

Jakub Hrozek jhrozek at redhat.com
Wed Jun 4 08:53:51 UTC 2014


On Wed, Jun 04, 2014 at 11:18:52AM +0300, "Thomas B. Rücker" wrote:
> On 04/06/14 10:18, Jakub Hrozek wrote:
> > 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.
> 
> That would probably fit our setup very well. We started exploring
> NM-dispatcher scripts for our "are we inside" state checking anyway and
> have something quite reliable now. We need that state anyway in several
> places, so SSSD using the same state would be good and consistent from
> our point of view. This would allow us to replace "ip route add
> blackhole 203.0.113.42" with something sensible that tells sssd that it
> should be offline or online.
> 
> I realize that this is just one way to skin this cat, for us it's quite
> appealing though.
> 
> Cheers
> 
> Thomas

Can you file a ticket in that case, please?


More information about the sssd-users mailing list