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 ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York