[SSSD] [sssd PR#719][comment] ifp: extraAttributes is UnknownProperty
URL: https://github.com/SSSD/sssd/pull/719 Title: #719: ifp: extraAttributes is UnknownProperty jhrozek commented: """ Ack, an integration test was submitted in PR #726 """ See the full comment at https://github.com/SSSD/sssd/pull/719#issuecomment-451461413 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#726][comment] TESTS: Add a simple integration test for retrieving the extraAttributes property
URL: https://github.com/SSSD/sssd/pull/726 Title: #726: TESTS: Add a simple integration test for retrieving the extraAttributes property jhrozek commented: """ This is a test for PR #719 It is expected that it will fail until that PR is merged. """ See the full comment at https://github.com/SSSD/sssd/pull/726#issuecomment-451461254 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#719][+Accepted] ifp: extraAttributes is UnknownProperty
URL: https://github.com/SSSD/sssd/pull/719 Title: #719: ifp: extraAttributes is UnknownProperty Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#726][+Blocked] TESTS: Add a simple integration test for retrieving the extraAttributes property
URL: https://github.com/SSSD/sssd/pull/726 Title: #726: TESTS: Add a simple integration test for retrieving the extraAttributes property Label: +Blocked ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#726][opened] TESTS: Add a simple integration test for retrieving the extraAttributes property
URL: https://github.com/SSSD/sssd/pull/726
Author: jhrozek
Title: #726: TESTS: Add a simple integration test for retrieving the
extraAttributes property
Action: opened
PR body:
"""
Related: https://pagure.io/SSSD/sssd/issue/3906
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/726/head:pr726
git checkout pr726
From 8a78a096148baf96b0e801f3948b5af22512d8b6 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Fri, 4 Jan 2019 15:26:02 +0100
Subject: [PATCH] TESTS: Add a simple integration test for retrieving the
extraAttributes property
Related:
https://pagure.io/SSSD/sssd/issue/3906
---
src/tests/intg/test_infopipe.py | 31 +++
src/tests/multihost/basic/test_ifp.py | 26 ++
2 files changed, 57 insertions(+)
create mode 100644 src/tests/multihost/basic/test_ifp.py
diff --git a/src/tests/intg/test_infopipe.py b/src/tests/intg/test_infopipe.py
index 6c316628b..9d575e675 100644
--- a/src/tests/intg/test_infopipe.py
+++ b/src/tests/intg/test_infopipe.py
@@ -207,12 +207,14 @@ def format_basic_conf(ldap_conn, schema):
# problem with "ifp" + client regristration in monitor
# There is not such problem in 1st test. Just in following tests.
command = {ifp_command} --uid 0 --gid 0 --debug-to-files
+user_attributes = +extraName
[domain/LDAP]
{schema_conf}
id_provider = ldap
ldap_uri= {ldap_conn.ds_inst.ldap_url}
ldap_search_base= {ldap_conn.ds_inst.base_dn}
+ldap_user_extra_attrs = extraName:uid
[application/app]
inherit_from = LDAP
@@ -534,6 +536,35 @@ def test_get_user_groups(dbus_system_bus, ldap_conn, sanity_rfc2307):
assert sorted(res) == ['single_user_group', 'two_user_group']
+def get_user_property(dbus_system_bus, username, prop_name):
+users_obj = dbus_system_bus.get_object(
+'org.freedesktop.sssd.infopipe',
+'/org/freedesktop/sssd/infopipe/Users')
+
+users_iface = dbus.Interface(users_obj,
+ "org.freedesktop.sssd.infopipe.Users")
+
+user_path = users_iface.FindByName(username)
+user_object = dbus_system_bus.get_object('org.freedesktop.sssd.infopipe',
+ user_path)
+
+prop_iface = dbus.Interface(user_object, 'org.freedesktop.DBus.Properties')
+return prop_iface.Get('org.freedesktop.sssd.infopipe.Users.User',
+ prop_name)
+
+
+def test_get_extra_attributes_empty(dbus_system_bus,
+ldap_conn,
+sanity_rfc2307):
+"""
+Make sure the extraAttributes property can be retrieved
+"""
+extra_attrs = get_user_property(dbus_system_bus,
+'user1',
+'extraAttributes')
+assert extra_attrs['extraName'][0] == 'user1'
+
+
def test_sssctl_domain_list_app_domain(dbus_system_bus,
ldap_conn,
sanity_rfc2307):
diff --git a/src/tests/multihost/basic/test_ifp.py b/src/tests/multihost/basic/test_ifp.py
new file mode 100644
index 0..b1d218f5c
--- /dev/null
+++ b/src/tests/multihost/basic/test_ifp.py
@@ -0,0 +1,26 @@
+"""
+InfoPipe test cases
+"""
+
+import pytest
+from sssd.testlib.common.utils import SSHClient
+
+class TestInfoPipe(object):
+"""
+Test the InfoPipe responder
+"""
+def test_ifp_extra_attributes_property(self, multihost):
+"""
+Test requesting the extraAttributes property works at all,
+see e.g. https://pagure.io/SSSD/sssd/issue/3906
+"""
+dbus_send_cmd = \
+"""
+dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe \
+/org/freedesktop/sssd/infopipe/Users/LDAP_2eTEST/123 \
+org.freedesktop.DBus.Properties.Get \
+string:"org.freedesktop.sssd.infopipe.Users.User" \
+string:"extraAttributes"
+"""
+cmd = multihost.master[0].run_command(dbus_send_cmd)
+assert cmd.returncode == 0
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#725][opened] MULTIHOST: Do not use the deprecated namespace
URL: https://github.com/SSSD/sssd/pull/725
Author: jhrozek
Title: #725: MULTIHOST: Do not use the deprecated namespace
Action: opened
PR body:
"""
This issue was causing warnings with the current pytest versions as
installed from pip.
See: https://docs.pytest.org/en/latest/deprecations.html#pytest-namespace
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/725/head:pr725
git checkout pr725
From 3b8d4b8baa4901be91a9c7ecfb62a556f260b6ae Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Tue, 27 Nov 2018 11:39:18 +0100
Subject: [PATCH] MULTIHOST: Do not use the deprecated namespace
This issue was causing warnings with the current pytest versions as
installed from pip.
See:
https://docs.pytest.org/en/latest/deprecations.html#pytest-namespace
---
src/tests/multihost/basic/conftest.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/tests/multihost/basic/conftest.py b/src/tests/multihost/basic/conftest.py
index 65e2d641b..a9e9cf0a6 100644
--- a/src/tests/multihost/basic/conftest.py
+++ b/src/tests/multihost/basic/conftest.py
@@ -17,13 +17,13 @@
import ldap
-def pytest_namespace():
-return {'num_masters': 1,
-'num_ad': 0,
-'num_atomic': 0,
-'num_replicas': 0,
-'num_clients': 0,
-'num_others': 0}
+def pytest_configure():
+pytest.num_masters = 1
+pytest.num_ad = 0
+pytest.num_atomic = 0
+pytest.num_replicas = 0
+pytest.num_clients = 0
+pytest.num_others = 0
@pytest.fixture(scope="class")
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#724][comment] COMPONENT: util/tev_curl
URL: https://github.com/SSSD/sssd/pull/724 Title: #724: COMPONENT: util/tev_curl alexey-tikhonov commented: """ > Could you please explain the double-free in more detail? > Looking at tevent docs, they say that the tevent timer is freed automatically That's correct. > and looking at the code, the `schedule_fd_processing` function is only ever > called from `tcurl_init` which should be a one-time operation. So currently > I'm not sure how could the function delete a timer that was already executed? `schedule_fd_processing` is not "called" from `tcurl_init`. It is setup as callback there. So `libcurl` calls `schedule_fd_processing` every time it wants to have (new) timer setup. And (in kcm intg test) it happens quite a lot of times. Being called `schedule_fd_processing` wants to delete previous timer before creating new one. That's basically proper action. The problem is it sometimes tries to delete non-existent (already executed and deleted by libtevent) timer. This is "double free" case. Proposed patch sets timer pointer in `tcurl_ctx` to NULL at the end of timer handler (actually can be placed anywhere in the handler: handler called => timer deleted by libtevent). That prevents `schedule_fd_processing` from freeing already freed memory. And I think it is good idea overall to not have pointers to freed memory (dangling pointers). This should be safe operation since all processes are single-thread processes (as far as I understand). """ See the full comment at https://github.com/SSSD/sssd/pull/724#issuecomment-451390544 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd PR#724][comment] COMPONENT: util/tev_curl
URL: https://github.com/SSSD/sssd/pull/724 Title: #724: COMPONENT: util/tev_curl alexey-tikhonov commented: """ > Could you please explain the double-free in more detail? > Looking at tevent docs, they say that the tevent timer is freed automatically That's correct. > and looking at the code, the `schedule_fd_processing` function is only ever > called from `tcurl_init` which should be a one-time operation. So currently > I'm not sure how could the function delete a timer that was already executed? `schedule_fd_processing` is not "called" from `tcurl_init`. It is setup as callback there. So `libcurl` calls `schedule_fd_processing` every time it wants to have (new) timer setup. And (in kcm intg test) it happens quite a lot of times. Being called `schedule_fd_processing` wants to delete previous timer before creating new one. That's basically proper action. The problem is it sometimes tries to delete non-existent (already executed and deleted by libtevent) timer. This is "double free" case. Proposed patch sets timer pointer in `tcurl_ctx` to NULL at the end of timer handler (actually can be placed anywhere in the handler: handler called => timer deleted by libtevent). That prevents `schedule_fd_processing` from freeing already freed memory. And I think it is good idea overall to not have pointers to freed memory. This should be safe operation since all processes are single-thread processes (as far as I understand). """ See the full comment at https://github.com/SSSD/sssd/pull/724#issuecomment-451390544 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
