signature templating



  • 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.



  • 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?



  • 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.



  • any clues?


  • Kopano

    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.



  • 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


  • Kopano

    @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.



  • 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?


  • Kopano

    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



  • 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 ?


  • Kopano

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



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