Univention Bugzilla – Bug 34421
update-python-modules breaks register UDM extensions
Last modified: 2014-09-15 12:33:11 CEST
+++ This bug was initially created as a clone of Bug #32405 +++ ... * It updates the Python links e.g. by calling update-python-modules -p I don't know what called "update-python-modules -a -v -f" (maybe a package update, maybe a Python update, maybe a package removal), but doing this manually removed all UDM extensions: # find syntax.d hooks.d handlers -iname \*ox\* | wc -l 24 # update-python-modules -a -v -f ... # cd $PWD # find syntax.d hooks.d handlers -iname \*ox\* It looks like "update-python-modules" starts from scratch and removed the complete directory before creating it anew; because of that the "cd $PWD" is needed. It only processes those modules listed in /usr/share/python-support/*.{public,private}. # udm modules | grep ox # cd /usr/share/pyshared/univention/admin # find hooks.d syntax.d handlers -path \*ox\* -type f -exec bash -c 't=/usr/lib/pymodules/python2.6/univention/admin/$1;mkdir -p ${t%/*};ln -n -s $PWD/$1 $t;pycompile $t' -- {} \; # udm modules | grep ox oxmail/oxcontext oxmail/oxdomain oxmail/oxfetchmailmulti oxmail/oxfetchmailsingle oxmail/oxfolder oxmail/oxlists oxmail/oxmail oxresources/oxresources
This is triggered as soon as a Python package using python-support is installed - in my case it was triggered by > /usr/bin/python /usr/sbin/update-python-modules ucs-test-framework.public > /usr/bin/python /usr/sbin/update-python-modules --post-install The bug doesn't manifest immediately, but as soon as univention-cli-server is restarted: Then the new instance no longer finds the modules. I can reproduce the bug by doing the following on a new 3.2-1 Generic VM: # udm settings/udm_syntax create --set name=Bug34421 --set filename=Bug34421.py --set data="$(bzip2 </usr/share/pyshared/univention/admin/syntax.d/example.py |base64)" --set package=bug34421 --set packageversion=34421 # udm settings/udm_syntax list --position cn=Bug34421,dc=phahn,dc=dev DN: cn=Bug34421,dc=phahn,dc=dev ARG: None ucsversionstart: None ucsversionend: None name: Bug34421 package: bug34421 active: TRUE packageversion: 34421 data: QlpoOTFBWSZTWTX9SDkAAClfgAAwQOQ4EgIADAoqZ89gIAByM/UmCNohoPQgxBtJKMmNGkAHqZqGMapeZawdSqXoZnpSIiZoZlqG3Mgum23LKUuB05WRhXGvHvglZFwppXlfg99jUlbFLdDH+ZQtg8NMhmV2jEa4BYMMtf8XckU4UJA1/Ug5 filename: Bug34421.py # stat /usr/lib/pymodules/python2.6/univention/admin/syntax.d/Bug34421.py File: „/usr/lib/pymodules/python2.6/univention/admin/syntax.d/Bug34421.py“ -> „/usr/share/pyshared/univention/admin/syntax.d/Bug34421.py“ Size: 57 Blocks: 0 IO Block: 4096 symbolische Verknüpfung Device: fd00h/64768d Inode: 935185 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: (65534/ nogroup) Access: 2014-03-29 09:28:31.812000000 +0100 Modify: 2014-03-29 09:28:31.796000000 +0100 Change: 2014-03-29 09:28:31.796000000 +0100 # /usr/sbin/update-python-modules --post-install # stat /usr/lib/pymodules/python2.6/univention/admin/syntax.d/Bug34421.py stat: Aufruf von stat für „/usr/lib/pymodules/python2.6/univention/admin/syntax.d/Bug34421.py“ nicht möglich: Datei oder Verzeichnis nicht gefunden
FYI: This helped finding the culprit: # grep -n axf /usr/sbin/update-python-modules 19:call(("ps", "axf"), stdout=open("/tmp/ps.log", "a"), stdin=open("/dev/null","r"))
Good catch! (In reply to Philipp Hahn from comment #1) > I can reproduce the bug by doing the following on a new 3.2-1 Generic VM: > > # udm settings/udm_syntax create --set name=Bug34421 --set > filename=Bug34421.py --set data="$(bzip2 > </usr/share/pyshared/univention/admin/syntax.d/example.py |base64)" --set > package=bug34421 --set packageversion=34421 > > # udm settings/udm_syntax list --position cn=Bug34421,dc=phahn,dc=dev > DN: cn=Bug34421,dc=phahn,dc=dev > ARG: None > ucsversionstart: None > ucsversionend: None > name: Bug34421 > package: bug34421 > active: TRUE > packageversion: 34421 > data: > QlpoOTFBWSZTWTX9SDkAAClfgAAwQOQ4EgIADAoqZ89gIAByM/ > UmCNohoPQgxBtJKMmNGkAHqZqGMapeZawdSqXoZnpSIiZoZlqG3Mgum23LKUuB05WRhXGvHvglZFw > ppXlfg99jUlbFLdDH+ZQtg8NMhmV2jEa4BYMMtf8XckU4UJA1/Ug5 > filename: Bug34421.py > > # stat /usr/lib/pymodules/python2.6/univention/admin/syntax.d/Bug34421.py > File: „/usr/lib/pymodules/python2.6/univention/admin/syntax.d/Bug34421.py“ > -> „/usr/share/pyshared/univention/admin/syntax.d/Bug34421.py“ > Size: 57 Blocks: 0 IO Block: 4096 symbolische > Verknüpfung > Device: fd00h/64768d Inode: 935185 Links: 1 > Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: (65534/ nogroup) > Access: 2014-03-29 09:28:31.812000000 +0100 > Modify: 2014-03-29 09:28:31.796000000 +0100 > Change: 2014-03-29 09:28:31.796000000 +0100 > We should add this is in a new test case.
Ok, the listener module udm_extension.py now creates a ".public" pysupport file for each module/hook/syntax. The objectclass is used as a prefix for the filename. Then update-python-modules -p is used to generate the pymodules links. The run of ucs-test -e udm-extensions -E dangerous was successful. Advisory: 2014-03-25-univention-directory-manager-modules.yaml Testcase yet to be done.
Test case: 72_udm-extensions/43_test_update-python-modules
As discussed, the usage of update-python-modules will break the existing modules which have been registered before.
Ok, the python-univenton-directory-manager postinst now calls "univenton-directory-listener-ctrl resync udm_extension" as part of this update.
OK, looks good. The test case failed with the old version and succeed with the new version. YAML: OK
*** Bug 34558 has been marked as a duplicate of this bug. ***
http://errata.univention.de/ucs/3.2/97.html