Bug 32397 - [Python UDM CLI API] Add possiblity to edit policy references (also for objects not created by the API)
[Python UDM CLI API] Add possiblity to edit policy references (also for objec...
Status: VERIFIED WONTFIX
Product: UCS Test
Classification: Unclassified
Component: Framework
unspecified
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: Dmitry Galkin
Philipp Hahn
:
Depends on:
Blocks: 32271
  Show dependency treegraph
 
Reported: 2013-08-28 10:57 CEST by Lukas Walter
Modified: 2014-11-21 10:03 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
repaste from pastebin (935 bytes, text/plain)
2014-11-10 17:08 CET, Florian Best
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Walter univentionstaff 2013-08-28 10:57:03 CEST
It should be possible to add/remove policy references to/from UDM objects via the python UDM CLI API.

This should also be possible for objects which have not been created during the test by the UDM CLI API itself, but also for already existing objects.
In such cases, the cleanup should restore the original state at exit.
Comment 1 Dmitry Galkin univentionstaff 2014-11-10 17:00:18 CET
(In reply to Lukas Walter from comment #0)
> It should be possible to add/remove policy references to/from UDM objects
> via the python UDM CLI API.

Does not seem to make any problem, at least with current state of UCSTestUDM() class. The policy references should be passed as kwargs in a dict to avoid policy-reference spelling with a dash in-between. For example see: ucs-test/tests/60_umc/06_non-ucr-policies

> This should also be possible for objects which have not been created during
> the test by the UDM CLI API itself, but also for already existing objects.
> In such cases, the cleanup should restore the original state at exit.

Also does not seem to be not valid. With svn revision 44225 there was a change by lwalter, which did exactly the opposite, i.e. blocked any modification/removal of objects which are not listen in the '_cleanup' dictionary. Although, if there is a need to make such a modification, it can be done directly from where it is used, for instance: http://hutten.knut.univention.de/pastebin/m2f58c3c9
Comment 2 Florian Best univentionstaff 2014-11-10 17:08:28 CET
Created attachment 6336 [details]
repaste from pastebin
Comment 3 Philipp Hahn univentionstaff 2014-11-20 15:38:10 CET
(In reply to Dmitry Galkin from comment #1)
> (In reply to Lukas Walter from comment #0)
> > It should be possible to add/remove policy references to/from UDM objects
> > via the python UDM CLI API.
> 
> Does not seem to make any problem, at least with current state of
> UCSTestUDM() class. The policy references should be passed as kwargs in a
> dict to avoid policy-reference spelling with a dash in-between. For example
> see: ucs-test/tests/60_umc/06_non-ucr-policies

OK:

#!/usr/bin/python2.7
from univention.testing.udm import UCSTestUDM
from subprocess import call
with UCSTestUDM() as udm:
 pol = udm.create_object('policies/pwhistory', name='pol', length='5', pwQualityCheck=False,pwLength='5')
 usr = udm.create_user(username='usr', options=['posix'], **{'policy-reference': pol})
call('udm users/user list | grep ^DN', shell=True)

> > This should also be possible for objects which have not been created during
> > the test by the UDM CLI API itself, but also for already existing objects.
> > In such cases, the cleanup should restore the original state at exit.
> 
> Also does not seem to be not valid. With svn revision 44225 there was a
> change by lwalter, which did exactly the opposite, i.e. blocked any
> modification/removal of objects which are not listen in the '_cleanup'
> dictionary. Although, if there is a need to make such a modification, it can
> be done directly from where it is used, for instance:
> http://hutten.knut.univention.de/pastebin/m2f58c3c9

FAIL: This is wrong:
>>> UDM._cleanup['users/user'] = 'uid=Administrator,cn=users,dc=dgalkin,dc=dev'

UDM._cleanup maps "module-name" to "list of DNs". The above line only works because the the implementation uses "dn in _cleanup[module]" with works with both »dn in "string"« and »dn in ["string"]«

If 
>>> UDM._cleanup['users/user'] = ['uid=Administrator,cn=users,dc=dgalkin,dc=dev']
is used instead, it would delete the Administrator account, which is not wanted: only the modification should be undone.
It's also a gross hack as this is modifying some internal state of UCSTestUDM() - _cleanup starts with a '_' which marks it as internal.

#!/usr/bin/python2.7
from univention.testing.udm import UCSTestUDM
from subprocess import call, check_output
call('udm users/user create --set username=usr --set lastname=usr --set password=univention', shell=True)
with UCSTestUDM() as udm:
 dn = 'uid=usr,' + udm.LDAP_BASE
 udm._cleanup['users/user'] = [dn]
 udm.modify_object('users/user', dn=dn, description=check_output(('date')))
call('udm users/user list | grep ^DN', shell=True)

In addition all previously added users would be lost, so at least
 udm._cleanup.setdefault('users/user', []).append(dn)
should be used.
 

As modifying an existing object is IMHO a bad idea, I set this bug to verified nevertheless: Implementing such a functionality would require saving the old LDAP state and restoring it afterwards. As modification can have cascading effects, this would require same major work.
Comment 4 Florian Best univentionstaff 2014-11-20 15:53:41 CET
hmm… It's not possible to set a policy to the ldap-base then. That's why this bug exists...
Comment 5 Philipp Hahn univentionstaff 2014-11-20 15:56:46 CET
(In reply to Florian Best from comment #4)
> hmm… It's not possible to set a policy to the ldap-base then. That's why
> this bug exists...

No: this bug does not specifically ask for LDAP-base (or any other already existing entry). For newly created objects it works, for all other existing objects it is IMHO too dangerous.
Comment 6 Dmitry Galkin univentionstaff 2014-11-21 10:03:09 CET
(In reply to Philipp Hahn from comment #5)
> No: this bug does not specifically ask for LDAP-base (or any other already
> existing entry). For newly created objects it works, for all other existing
> objects it is IMHO too dangerous.

OK, I would also say that as long as I used the ucs-test framework, it is not a common case to modify a preexisting object during the test run. Normally, one would create an object for the test and than delete it after the test is finished.