Re: Disabling recipient policy doesn't work in Winterfell

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):

2019-09-17 16:44:59,663 pykolab.auth ERROR [6103] Traceback (most recent
call last):
  File "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py",
line 1806, in _change_delete_unknown
    success = eval("self._change_delete_%s(entry, change)" % (_type))
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py",
line 1772, in _change_delete_group
    self.imap.cleanup_acls(entry[result_attribute])
  File "/usr/lib/python2.7/site-packages/pykolab/imap/__init__.py", line
80, in cleanup_acls
    if self.imap.has_folder(folder):
AttributeError: Cyrus instance has no attribute 'has_folder'

Literally no idea what to do.

On Tue, Sep 17, 2019 at 3:50 PM Milan Petrovic <[email protected]>
wrote:

> I have also tried adding the "daemon_rcpt_policy = false" in kolab.conf,
> as described here: https://blog.uvclay.com/kolab-1-install/, but the
> policy is being enforced somehow still. The only clue I've got from the
> logs:
>
> 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
> 2019-09-17 11:13:23,674 pykolab.conf WARNING [5990] Option does not exist
> in defaults.
>
> 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.
>
>
>
> On Tue, Sep 17, 2019 at 1:59 PM Milan Petrovic <[email protected]>
> wrote:
>
>> 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.
>>
>> I'm trying to disable the recipient policy, as I did in the old version
>> but the process somehow fails with Winterfell.
>>
>> 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").
>>
>> 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.
>>
>> Where else are these policies defined? Where should I look?
>>
>

_______________________________________________
users mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/users