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(a)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?