You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dmitri, I tried to reproduce this issue on my virtual machine (RHEL 5.6, sssd and openldap versions are the same) without any success. I tried steps described in ticket #494 with various configurations. I was wondering if you can help me by providing steps to reproduce the issue.
Log online to get user cached (as if I worked from office)
Disconnect from the network (unplugged the machine)
Suspend machine (getting home)
Log in offline (got home)
Establish VPN and get online (got on the corp network)
Work for some time, let the ticket expire (worked and left machine logged in)
Suspend machine and unplug (going to the office)
Bring into a completely different wireless network and plug in (got into office but into a meeting)
Get on VPN.
Observe the problem. Not reproducible at will sorry.
I suspect that the problem is related to the situation when network is there but the server is not reachable since it requires VPN. Since going from home to office and back completely swaps the network environment under SSSD it might be sticking to its old knowledge about the network somehow and getting confused. I would look into netlink related area.
Thanks you. I don't think VPN causes the issue, because SSSD works with connection to servers, not connection to network. If you have a log describing what happens, it might shed a light on what's going on. Either way I shall investigate further and try to reproduce the issue.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/599
Occasionally the sssd log get filled up consuming all available disk space with one message:
It happens with openldap 2.3.43 and sssd 1.2.1 on RHEL 5.5.
After this the machine becomes unusable.
Comments
Comment from sgallagh at 2010-08-10 14:57:57
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.4.0
owner: somebody => jhrozek
Comment from dpal at 2010-09-14 15:17:08
Fields changed
milestone: SSSD 1.4.0 => SSSD 1.2.4
Comment from sgallagh at 2010-09-14 15:20:53
Fields changed
owner: jhrozek => jzeleny
Comment from jzeleny at 2010-09-16 14:31:23
Dmitri, I tried to reproduce this issue on my virtual machine (RHEL 5.6, sssd and openldap versions are the same) without any success. I tried steps described in ticket #494 with various configurations. I was wondering if you can help me by providing steps to reproduce the issue.
Comment from dpal at 2010-09-16 15:12:13
Try the following scenario:
Observe the problem. Not reproducible at will sorry.
I suspect that the problem is related to the situation when network is there but the server is not reachable since it requires VPN. Since going from home to office and back completely swaps the network environment under SSSD it might be sticking to its old knowledge about the network somehow and getting confused. I would look into netlink related area.
This is the best I can help with.
Comment from jzeleny at 2010-09-16 16:10:15
Thanks you. I don't think VPN causes the issue, because SSSD works with connection to servers, not connection to network. If you have a log describing what happens, it might shed a light on what's going on. Either way I shall investigate further and try to reproduce the issue.
Comment from sgallagh at 2010-10-09 01:31:24
Fixed by 2159516
component: SSSD => LDAP Provider
fixedin: => 1.2.4
resolution: => fixed
status: new => closed
Comment from dpal at 2012-01-19 02:50:04
Fields changed
rhbz: => 0
Comment from dpal at 2017-02-24 14:47:03
Metadata Update from @dpal:
The text was updated successfully, but these errors were encountered: