signature templating

micro

Hello folks,

I want to introduce signature templating and currently testing with my own account. I am referring to the script setdefaultsignature.py that is located in /usr/share/doc/kopano-webapp/scripts/signatures and have following questions:

[1] the script setdefaultsignature.py checks for an existing signature in users webapp account. Unless it exist it will import/add the signature from the template. But how can I force a replication even if the users already has an existing signature? Is there a way to do this? I checked the script and found this definition

[...]
if webappsettings['settings']['zarafa']['v1']['contexts']['mail']['signatures']['all'].get(signatureid):
           print('Default Signature already exists.')
       else:
           print('Adding Default Signature.')
           webappsettings['settings']['zarafa']['v1']['contexts']['mail']['signatures']['all'][
               signatureid] = signaturecontent
           webappsettings['settings']['zarafa']['v1']['contexts']['mail']['signatures']['new_message'] = signatureid
           webappsettings['settings']['zarafa']['v1']['contexts']['mail']['signatures'][
               'replyforward_message'] = signatureid
           write_settings(json.dumps(webappsettings))
[...]

but have no idea how to modify it accordingly to add such a function. Any ideas?

[2] I have made some changes in ActiveDirectory and waited >30mins but the change was not reflected into the signature templating. In webapp I manually deleted the signature and re-run the script so the script successfully inserted the signature into my account. But the phone number or title or some other changes didn’t reflect to the new created signature. Still the old values are used. So it looks like Kopano didn’t get latest infos from our AD. What could cause this malfunction, how can I force Kopano to sync with our AD?

[3] I closed DeskApp and started Outlook 2013 with OLE installed. I removed any signature I had before. Then on the top right area I clicked the [KOPANO] ribbon and clicke the AKTUELL button (german meaning of UP-TO-DATE or SYNCED). This action opens a window where I can choose what kind of data I want to sync. I clicked on “Sync Signatures” but the process never ends and doesn’t timeout. I am getting the message “The signatures are being synced.” but even after 10minutes it doesn’t finish, even not when I click the CANCEL button. I had to terminate and kill the OUTLOOK.EXE process. What am I missing ? I restarted Outlook and went again into this sync window. I can successfully sync GAB or other server data, that works fine and just needs a fraction of time to finish. But the signatures are not synced.

Any help appreciated. Thanks in advance.

mcdaniels

Hi,
if you alter the AD settings of an useraccount, you have to log off and in again to the PC, to make the changes happen. At least this works for me.

If you use AD accounts for kopano it should sync.

Do you use multiple DCs?

micro

It doesn’t make sense to me to logoff from my computer and login again but nevertheless I tried and it didn’t help. The issue is that the attributes of the signature templating are filled with old data. For me it seems that Kopano cached somewhere those data and still use them although they have changed in AD.

Yes, I use two DCs and also checked them some minutes ago. I did run

netstat -atnpu |grep 636

to see if my kopano server is connected to both my DCs through LDAPS protocol. To my surprise I saw only connections to my secondary DC. So I checked both DCs there are no issues and they are up and working fine. I checked and compared the updates user data on both DCs, they both are the same and correct. I decided to restart kopano-server and right after it I checked again the netstat command. Funnily kopano-server now shows only CONNECTED to my primary DC, there’s no connection with my secondary DC.

I checked again my signature and now the data shown is up-to-date and thus OK as expected. But I’m still puzzled …

(a) why did I need to restart kopano-server to have the updated AD data also shown on Kopano-Server ?
(b) why does kopano-server only maintain a connection to one of my two DCs ?

my ldap.active-directory.cfg is:

ldap_host = 192.168.100.1
ldap_port = 636
ldap_protocol = ldaps
ldap_uri = ldaps://192.168.100.1:636 ldaps://192.168.100.2:636
ldap_server_charset = utf-8
ldap_bind_user = CN=myhost ActiveDirectory Bind,OU=service,OU=users,OU=ad company-name ,DC=ad,DC=company-name,DC=com
ldap_bind_passwd = passw0rd
ldap_network_timeout = 30
ldap_last_modification_attribute = uSNChanged
ldap_page_size = 1000
ldap_search_base = OU=ad company-name ,DC=ad,DC=company-name,DC=com
ldap_object_type_attribute = objectClass
ldap_user_type_attribute_value = user
ldap_group_type_attribute_value = group
ldap_contact_type_attribute_value = contact
ldap_company_type_attribute_value = organizationalUnit
ldap_addresslist_type_attribute_value = zarafaAddresslist
ldap_dynamicgroup_type_attribute_value = zarafaDynamicGroup
ldap_user_search_filter = (&(objectCategory=Person)(zarafaAccount=1))
ldap_user_unique_attribute = objectGuid
ldap_user_unique_attribute_type = binary
ldap_fullname_attribute = cn
ldap_loginname_attribute = sAMAccountName
ldap_password_attribute = unicodePwd
ldap_authentication_method = bind
ldap_emailaddress_attribute = mail
ldap_emailaliases_attribute = otherMailbox
ldap_isadmin_attribute = zarafaAdmin
ldap_nonactive_attribute = zarafaSharedStoreOnly
ldap_resource_type_attribute = zarafaResourceType
[...]

EDIT: I did find out by testing that kopano-server will keep the connection to a single DC. When the connection drops to this DC and kopano-server needs to get info from LDAP/AD then it tries the other server. I simulated it by stopping my AD on DC1 and then ran a “kopano-admin --details foo”. Afterwards netstat command showed me that the connection to the online DC2 was established. Funnily there are only 6 connections to port 636 to DC2, before when I was connected to DC1 there were 8 conncetions. Then I started DC1 AD again and put DC2 offline and ran again a “kopano-admin” command to force kopano-server to pull informations of AD. I checked netstat and I had 8 connections established to DC1. Did put then DC2 online again. So I guess this is normal behaviour, kopano-server does not keep active connections to both DCs in parallel. It uses kind of round-robin for it. So this should be working fine on my side and not be the issue.

The signature still is not being synced within Outlook+OLE. Same issue as explained in initial posting.

micro

any clues?

fbartels

Hi @micro ,

@micro said in signature templating:

I have made some changes in ActiveDirectory and waited >30mins but the change was not reflected into the signature templating

AFAIK the signature in WebApp is only updated with the latest values from the GAB upon login of the user. So for changes to be picked up in WebApp the user needs to login again.
How changes from ldap are ending up in the gab is a question of your local configuration. If you use the default value for sync_gab_realtime then this data will be updated once you request a user listing (e.g. by opening the gab in WebApp). If you have set this to no then you need to kick off a sync process e.g. via kopano-cli.

The process is explained in https://documentation.kopano.io/kopanocore_administrator_manual/user_management.html#the-kopano-user-synchronization-principle

@micro said in signature templating:

Outlook […] This action opens a window where I can choose what kind of data I want to sync. I clicked on “Sync Signatures” but the process never ends and doesn’t timeout

Yes, this a know effect in KOE. There is a timing issue at the start of Outlook that can prevent this process from finishing.

@micro said in signature templating:

Yes, I use two DCs […] To my surprise I saw only connections to my secondary DC.

This is kind of expected. Even if you configure multiple ldap servers through the ldap_uri will only speak to one of them at a time. The behaviour of the used ldap library is that it connects to the first configured ldap server (with a separate connection per thread) and once this first server isn’t responding it moves over to the next entry in the list. So for your server to only query your second node the first must have not been responding at some time. If you want to load balance ldap queries over your two servers, then you need a separate ldap load balancer.

micro

Hi Felix,

thanks for getting into my questions. The last point about LDAP round-robin is clear so far and understood, solved.

I am using sync_gab_realtime=yes in my server.cfg and I did some further testing to learn how the sync works. In my signature templating for example I use the variable {%title} which I assigned the value “foo” for my user account in ActiveDirectory. In the beginning my user account in WebApp does not have any signature set. I run the signature templating wrapper for my user account which in advance sets the signature template for my account, it is called “WebApp Default Signature”. I start composing a new email and the signature shows as expected, so far so good.

Now in ActiveDirectory I change the title to the value “bar”. I logoff from Kopano DeskApp with my user account, re-login and compose a new message. The signature still shows “foo” in the particular field. So the re-login alone doesn’t solve it. I need to delete the “WebApp Default Signature” from my settings within WebApp and then log-off. Then it needs the wrapper to executed again so it sets the signature. Then I login and now it works and I see the value “bar” in signature. Conclusion: if I want to have any modified ActiveDirectory user account setting reflected to Kopanos’ signature templating it needs the user to manually remove his signature and then the administrator needs to re-execute the wrapper to put the signature again into users’ WebApp. I find this kinda inconvenient because you loose the mighty power of a centralized default signature mechanism. Did I miss anything or is this really normal behaviour?

About the Outlook issue: how can I solve this? At that time a KOL user never retrieves the default signature. Outlook cannot pull the signature from Kopano because the process is never terminated and needs to be force killed by CTRL+ALT+ENF and process task manager to kill OUTLOOk.EXE afterwards.

Thank you in advance

fbartels

@micro said in signature templating:

Did I miss anything or is this really normal behaviour?

That certainly sounds strange (and imho not right). The thing that I could think of to verify this solution is to check in your gab if these values have been updated there. If they have then it should also work with WebApp. But I am not too familiar with this part of WebApp myself, so if you don’t get any further responses here I would recommend to open up a support case.

As for KOE once solution (apart from downgrading to an older pre 2.0 version) would be to disable the signature sync in the plugin debugger. We eventually will need to get to fixing this.

micro

Hi Felix,

I forgot to mention that the AD changes are reflected in GAB when I open GAB to check after the change.

related to KOE, understood. So this is something known to you and in investigation. Is there any jira ticket that I can watch somehow to follow the work in progress?

fbartels

Hi @micro,

ok if the changes can be seen in the gab then this sounds like an issue in WebApp.

The koe thing comes down to https://jira.kopano.io/browse/KOE-176

micro

thank you Felix.

@micro said in signature templating:

[1] the script setdefaultsignature.py checks for an existing signature in users webapp account. Unless it exist it will import/add the signature from the template. But how can I force a replication even if the users already has an existing signature? Is there a way to do this? I checked the script and found this definition

can anyone lead me to the right direction for solving this? I’d like to enforce on specific cases the signature to some or all users. How can this be done ?

fbartels

@micro I recommend to get in direct contact with our support. afair the mentioned script was originally created there.

micro

already did so on Friday and waiting for feedback. But I thought I might ask here about enforcing the signature templating.