<div dir="ltr"><div>The last piece of the puzzle might be the pykolab.log which reports an error on deleting users created with the changes I have applied (from kolab doc + few more settings I have mentioned):</div><div><br></div><div>2019-09-17 16:44:59,663 pykolab.auth ERROR [6103] Traceback (most recent call last):<br>  File "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 1806, in _change_delete_unknown<br>    success = eval("self._change_delete_%s(entry, change)" % (_type))<br>  File "<string>", line 1, in <module><br>  File "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 1772, in _change_delete_group<br>    self.imap.cleanup_acls(entry[result_attribute])<br>  File "/usr/lib/python2.7/site-packages/pykolab/imap/__init__.py", line 80, in cleanup_acls<br>    if self.imap.has_folder(folder):<br>AttributeError: Cyrus instance has no attribute 'has_folder'</div><div><br></div><div>Literally no idea what to do.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 3:50 PM Milan Petrovic <<a href="mailto:petrovic.milan@gmail.com">petrovic.milan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I have also tried adding the "daemon_rcpt_policy = false" in kolab.conf, as described here: <a href="https://blog.uvclay.com/kolab-1-install/" target="_blank">https://blog.uvclay.com/kolab-1-install/</a>, but the policy is being enforced somehow still. The only clue I've got from the logs: <br></div><div><br></div><div>2019-09-17 11:13:23,674 pykolab.conf WARNING [5990] Option ldap/auth_cache_uri does not exist in config file /etc/kolab/kolab.conf, pulling from defaults<br>2019-09-17 11:13:23,674 pykolab.conf WARNING [5990] Option does not exist in defaults.</div><div><br></div><div>But even after searching for a "default kolab.conf" (thinking, maybe everything gets pulled from there, not just auth_cache_uri) I'm no way smarter nor I know what to do next.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 1:59 PM Milan Petrovic <<a href="mailto:petrovic.milan@gmail.com" target="_blank">petrovic.milan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'm in a process of setting up Kolab Winterfell after running the 3.4 version for several years and have few issues along the way.</div><div><br></div><div>I'm trying to disable the recipient policy, as I did in the old version but the process somehow fails with Winterfell.</div><div><br></div><div>I have removed primary and secondary mail settings from kolab.conf, also added the "admin_auto_fields_rw = true", and have applied the modified sample-insert-user_types.php (the script runs without errors, I have triple checked all the instances of "auto_form_fields" and "form_fields").</div><div><br></div><div>However, when I create a new user in Webadmin, seems like there is somewhere still the old (deleted by me) primary and secondary email policy active. No matter what I type for these two emails, the user is created with the policies described in the original kolab.conf (although they have been deleted, service restarted, etc.): primary with given.surname and alias with the initial of the given name dot surname.</div><div><br></div><div>Where else are these policies defined? Where should I look?<br></div></div>
</blockquote></div>
</blockquote></div>