Hi, Ben. Please check Cache Refresh's log in `tomcat/logs` within container, you should find some clues there.

2016-07-13 10:50:26,442 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-5-thread-2) Failed to 'add' person '@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A!0000!8CEE.7D7F' org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to persist entry: inum=@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A!0000!8CEE.7D7F,ou=people,o=@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A,o=gluu at org.gluu.site.ldap.persistence.LdapEntryManager.persist(LdapEntryManager.java:113) at org.gluu.site.ldap.persistence.AbstractEntryManager.persist(AbstractEntryManager.java:100) at org.gluu.oxtrust.ldap.service.PersonService.addPerson(PersonService.java:102) at sun.reflect.GeneratedMethodAccessor853.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) at org.gluu.oxtrust.ldap.service.PersonService_$$_javassist_seam_10.addPerson(PersonService_$$_javassist_seam_10.java) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.updateTargetEntryViaCopy(CacheRefreshTimer.java:658) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.updateTargetEntriesViaCopy(CacheRefreshTimer.java:547) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.detectChangedEntries(CacheRefreshTimer.java:370) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processImpl(CacheRefreshTimer.java:261) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.process(CacheRefreshTimer.java:179) at sun.reflect.GeneratedMethodAccessor707.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56) at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.async.AsynchronousInterceptor.aroundInvoke(AsynchronousInterceptor.java:52) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114) at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer_$$_javassist_seam_33.process(CacheRefreshTimer_$$_javassist_seam_33.java) at sun.reflect.GeneratedMethodAccessor706.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jboss.seam.util.Reflections.invoke(Reflections.java:22) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144) at org.jboss.seam.Component.callComponentMethod(Component.java:2313) at org.jboss.seam.core.Events.raiseEvent(Events.java:85) at org.jboss.seam.async.AsynchronousEvent$1.process(AsynchronousEvent.java:33) at org.jboss.seam.async.Asynchronous$ContextualAsynchronousRequest.run(Asynchronous.java:80) at org.jboss.seam.async.AsynchronousEvent.execute(AsynchronousEvent.java:27) at org.jboss.seam.async.ThreadPoolDispatcher$RunnableAsynchronous.run(ThreadPoolDispatcher.java:142) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: Connection exception (LDAP config error: schema violation contact LDAP admin.: Entry inum=@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A!0000!8CEE.7D7F,ou=people,o=@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A,o=gluu violates the Directory Server schema configuration because it contains an unknown objectclass ox-09B5355EB99F4FF900017FE54E6A) at org.gluu.site.ldap.OperationsFacade.addEntry(OperationsFacade.java:335) at org.gluu.site.ldap.persistence.LdapEntryManager.persist(LdapEntryManager.java:108) ... 59 more

Sorry, Ben, it seems I started to jump into conclusions - you never mentioned you are using CR. Could you elaborate a bit on your setup: how do you add new users that don't show up lately, may be even provide a screenshots of all related configuration pages with your settings?

I imagine the bottom part is what counts: > Caused by: Connection exception (LDAP config error: schema violation contact LDAP admin.: Entry inum=@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A!0000!8CEE.7D7F,ou=people,o=@!09B5.355E.B99F.4FF9!0001!7FE5.4E6A,o=gluu violates the Directory Server schema configuration because it contains an unknown objectclass ox-09B5355EB99F4FF900017FE54E6A) at org.gluu.site.ldap.OperationsFacade.addEntry(OperationsFacade.java:335) at org.gluu.site.ldap.persistence.LdapEntryManager.persist(LdapEntryManager.java:108) But I have no idea what exactly that means.

In our environment, Gluu is just used for trust to a provider for authentication and attribute passing. We add users to our AD environment and they usually populate in gluu. I did see a user added today that worked, but I have added two users and they don't show up at all on the Gluu server.

Thank you, Ben. Could you provide output of those (within container)? 1. `# cat /opt/opendj/config/schema/{99,100}-user.ldif` 2. `# ll /opt/opendj/config/schema/` And just a bit unrelated question: why do you use 2.4.2 package? Current version is 2.4.3, an 2.4.4 is almost there.

We are on 2.4.2 because that is where we started at and haven't needed to upgrade. ``` cat ./opt/opendj/config/schema/{99,100}-user.ldif dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema modifiersName: cn=Directory Manager,cn=Root DNs,cn=config modifyTimestamp: 20160406113222Z dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema objectClasses: ( ox-09B5355EB99F4FF900017FE54E6A-oid NAME 'ox-09B5355EB99F4FF900017FE54E6A' SUP top STRUCTURAL MUST objectClass MAY ( eduPersonAffiliation $ eduPersonEntitlement $ eduPersonPrincipalName $ eduPersonScopedAffiliation ) X-ORIGIN 'gluu' ) ``` ``` ll ./opt/opendj/config/schema/ total 476 -rw-r--r--. 1 1002 systems 43693 Apr 5 09:17 00-core.ldif -rw-r--r--. 1 1002 systems 6596 Apr 5 09:17 01-pwpolicy.ldif -rw-r--r--. 1 1002 systems 194369 Apr 5 09:17 02-config.ldif -rw-r--r--. 1 1002 systems 5058 Apr 5 09:17 03-changelog.ldif -rw-r--r--. 1 1002 systems 3561 Apr 5 09:17 03-rfc2713.ldif -rw-r--r--. 1 1002 systems 2133 Apr 5 09:17 03-rfc2714.ldif -rw-r--r--. 1 1002 systems 3235 Apr 5 09:17 03-rfc2739.ldif -rw-r--r--. 1 1002 systems 3272 Apr 5 09:17 03-rfc2926.ldif -rw-r--r--. 1 1002 systems 1710 Apr 5 09:17 03-rfc3112.ldif -rw-r--r--. 1 1002 systems 12652 Apr 5 09:17 03-rfc3712.ldif -rw-r--r--. 1 1002 systems 15858 Apr 5 09:17 03-uddiv3.ldif -rw-r--r--. 1 1002 systems 12207 Apr 5 09:17 04-rfc2307bis.ldif -rw-r--r--. 1 1002 systems 6339 Apr 5 09:17 05-rfc4876.ldif -rw-r--r--. 1 1002 systems 12223 Apr 5 09:17 05-samba.ldif -rw-r--r--. 1 1002 systems 14141 Apr 5 09:17 05-solaris.ldif -rw-r--r--. 1 1002 systems 1125 Apr 5 09:17 06-compat.ldif -rw-r--r--. 1 1002 systems 344 Apr 6 07:32 100-user.ldif -rw-r--r--. 1 1002 systems 104442 Apr 5 09:17 101-ox.ldif -rw-r--r--. 1 1002 systems 704 Apr 5 09:17 77-customAttributes.ldif -rw-r--r--. 1 1002 systems 2220 Apr 5 09:17 96-eduperson.ldif -rw-r--r--. 1 1002 systems 183 Apr 6 07:32 99-user.ldif ```

Ok, the objectclass it claims to be absent at least is present in schema files. Try to do next: 1. `# service tomcat stop` 2. `# service opendj stop` 3. `# service opendj start` 4. Pay attention for any error messages in the console, like "some schema file wasn't loaded" or "definition of some objectclass isn't correct". Then also check `/opt/opendj/logs/server.out` and, perhaps, `/opt/opendj/log/errors` too for similar (or any at all) errors happened during latest server start up

Did as you suggested. No errors on the screen, however, this was in the /opt/opendj/logs/server.out > [14/Jul/2016:11:03:37 -0400] category=CONFIG severity=SEVERE_WARNING msgID=3276996 msg=An objectclass read from schema configuration file 100-user.ldif could not be parsed: The definition for the objectclass with OID ox-09b5355eb99f4ff900017fe54e6a-oid declared that it should include optional attribute "edupersonaffiliation". No attribute type matching this name or OID exists in the server schema The errors log had no errors.

What is output of `# grep -r -i -e edupersonaffiliation /opt/opendj/config/schema/` ?

``` /opt/opendj/config/schema/96-eduperson.ldif:attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' /opt/opendj/config/schema/100-user.ldif:objectClasses: ( ox-09B5355EB99F4FF900017FE54E6A-oid NAME 'ox-09B5355EB99F4FF900017FE54E6A' SUP top STRUCTURAL MUST objectClass MAY ( eduPersonAffiliation $ eduPersonEntitlement $ eduPersonPrincipalName $ eduPersonScopedAffiliation ) X-ORIGIN 'gluu' ) ```

Edited post a bit, to be easy to read, thanks. How did this happen, by the way? Do you use any custom attributes in your setup? Were you adding or updating them just before this happened?

Can't get it. Attribute seems to be defined, but it says it can't find the definition. Can something prevent it from loading this `96-eduperson.ldif` file? Could you also provide output of `# cat /opt/opendj/config/schema/96-eduperson.ldif` ?

I don't think anything should be stopping it from loading 96-eduperson.ldif. It has been working up until now. Here is the output you asked for: ``` > cat /opt/opendj/config/schema/96-eduperson.ldif dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema cn: schema attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.1 NAME 'eduPersonAffiliation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.2 NAME 'eduPersonNickName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.3 NAME 'eduPersonOrgDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.4 NAME 'eduPersonOrgUnitDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.5 NAME 'eduPersonPrimaryAffiliation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.6 NAME 'eduPersonPrincipalName' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.7 NAME 'eduPersonEntitlement' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.8 NAME 'eduPersonPrimaryOrgUnitDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.9 NAME 'eduPersonScopedAffiliation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.10 NAME 'eduPersonTargetedID' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Internet2 MACE Working Group' ) attributeTypes: ( 1.3.6.1.4.1.5923.1.1.1.11 NAME 'eduPersonAssurance' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 4512 Internet2 MACE Working Group' ) objectClasses: ( 1.3.6.1.4.1.5923.1.1.2 NAME 'eduPerson' AUXILIARY MAY ( eduPe rsonAffiliation $ eduPersonNickName $ eduPersonOrgDN $ eduPersonOrgUnitDN $ e duPersonPrimaryAffiliation $ eduPersonPrincipalName $ eduPersonEntitlement $ eduPersonPrimaryOrgUnitDN $ eduPersonScopedAffiliation $ eduPersonTargetedID $ eduPersonAssurance ) X-ORIGIN 'Internet2 MACE Working Group' ) ```

Still can't come up with any idea. Let's try to experiment a bit: 1. `# service tomcat stop` 2. `# service opendj stop` 3. Creat a backup of `opt/opendj/config/schema/99-user.ldif` (or `100-user`, the one where `ox-09B5355EB99F4FF900017FE54E6A` objectclass is defined), then edit it, removing `eduPersonAffiliation` from the definition; you should have something like that in the end: `...SUP top STRUCTURAL MUST objectClass MAY ( eduPersonEntitlement $ eduPersonPrincipalName $ eduPersonScopedAffiliation ) X-ORIGIN 'gluu' )` 4. `# service opendj start` 5. Check the same logs and console output again for errors. If you'll see none, stop opendj again, try to revert all these changes, start, check logs again.

Now the error moved to the next item in the list. I removed eduPersonAffiliation and then the error triggered on eduPersonEntitlement. > [14/Jul/2016:16:40:11 -0400] category=CONFIG severity=SEVERE_WARNING msgID=3276996 msg=An objectclass read from schema configuration file 100-user.ldif could not be parsed: The definition for the objectclass with OID ox-09b5355eb99f4ff900017fe54e6a-oid declared that it should include optional attribute "edupersonentitlement". No attribute type matching this name or OID exists in the server schema I have set it back now and the error is once again for eduPersonAffiliation.

Not sure if this helps, but I cant modify the eduPersonAffiliation attribute from the GUI either. 

I am not sure if this a function of being tied to AD or not, but I cannot manually add users or modify the attributes of existing users either.

That could be expected. Objectclass `ox-09B5355EB99F4FF900017FE54E6` (actually its name is composed from OrgID and unique for each instance) is where Gluu puts all your custom attributes (in 2.4.3+ it doesn't seem to contain anything but custom attributes) So when oxTrust tries to persist a user you are adding through web UI it also tries to include this objectclass, of course. But due to the fact OpenDJ in your setup currently isn't able to interpret schema files correctly for some reason, it doesn't load this objectclass's definition during startup, thus, from its point of view, there is no such class in the schema. This is your issue, in a nutshell. It doesn't seem to have anything to do with Gluu itself. Have you tried to google for similar OpenDJ's issues?

I have tried google but haven't found anything.

Just an FYI, went back to a restore from two months ago and are still having the same issues.

May I ask you to share all contents of `schema/` directory zipped? If you don't have access to the attachment feature of the board, you could employ some 3rd party file sharing service.

> Just an FYI, went back to a restore from two months ago and are still having the same issues. What did that restore involve? Which parts of your instance were overwritten? Or let's say, which parts were not overwritten (if any)?

We are running this as a Centos 7.2 VM in vsphere. Did a full restore of the vmdk file from May 2nd. Shut down the current running gluu server, spun up the restored copy, re-ip'd it and started the services. Got the same edu error. Furthermore, users who I have successfully brought in since then were not in there even after a cache refresh. I am at a total loss. And you can find the zip of the schema directory here: https://app.box.com/s/71cqg2fp4c2o3qaurz0nroe5xpr2tehf

Another idea: there are multiple notes over docs that schema files' loading order matters. Please try to rename the file in which problematic objectclass is defined in different ways, implying different sorting orders, so it would be loaded before `96-eduperson.ldif`, then after that. [Docs for OpenDS](http://docs.oracle.com/cd/E19476-01/821-0506/extending-schema-with-custom-file.html) (a relative project) have it that custom schema files must be loaded after standard ones. Can't find similar notes for OpenDJ.

Just tried swapping the file to be both 95-user.ldif and 110-user.ldif and neither changed a thing, with 96-eduperson.ldif.

You mentioned that ox-09B5355EB99F4FF900017FE54E6 is (actually its name is composed from OrgID and unique for each instance) Is it possible that if something changed on the server, say CPU or memory, that the name could have changed but not in the ldif file?

If something like that would happen it would be a very weird bug. No, it isn't supposed to be changed like that, but I believe you can change it even from web UI, on the json configuration page. But I've already compared the value it complains about in logs you provided to the value that is in your schema files output before, they are the same. As you can see, it doesn't even comes to Gluu, your tomcat is stopped, you start opendj and you get schema error right away. So it comes down to OpenDJ. My guess that if you'll remove all these `edu*` attributes from this custom class's definition it will at least start without problems, but the fact these attributes are mentioned in it means you activated them in web UI and probably using them in TRs and mapping them with CR. So it will again result in schema violation errors, but now because `edu*` attributes are not allowed in user entries. Okay, here is a dirty hack to try: 1. Stop tomcat and opendj 2. Move the file where the problematic class is defined out of `schema/` 3. Copy just this class definition to the end of the `96-eduperson.ldif` file. I mean only this part: `( ox-09B5355EB99F4FF900017FE54E6A-oid NAME 'ox-09B5355EB99F4FF900017FE54E6A' SUP top STRUCTURAL MUST objectClass MAY ( eduPersonAffiliation $ eduPersonEntitlement $ eduPersonPrincipalName $ eduPersonScopedAffiliation ) X-ORIGIN 'gluu' )` 4. Start opendj At least this should work. Before starting tomcat again you'll need to restore everything back and restart opendj again. That's just to verify the assumption.

I assume I use the ox-09B5355EB99F4FF900017FE54E6A from ours and not the one you put there?

Yes, I've edited my post.

I had to add objectClasses: to the front of it, but that worked! Could the file have been corrupt somehow?

It still seems to me more like a loading order sort of issue. Though I can't even guess why it suddenly changed loading order of schema files. Btw in mine (though newer) test instance files are named the same way and I don't have such issue atm. What I provided is not a solution, as Gluu expects this class's definition to be in that very file you moved out. But at least you now have some strong clues about the cause. May be somebody at OpenDJ's forums will be able to help you.

So, something I haven't tried, I renamed it 97-user.ldif and removed the stuff from 96 and it works. Set it back to 100-user.ldif and it fails, same file. And it failed before when I named it 110-user.ldif There is a 99-user.ldif, could that be the issue?

I think it may compare strings without interpreting numbers as such, so from this point of view, anything starting with `9` is way "greater" than starting with `1`. That's why I suggested to try to account for different comparisons it could employ. I'm not sure whether it's possible to change filenames Gluu uses to store its custom schema extensions. I'll check and get back to you later.

Yes, this is very likely the case. I've just checked contents of my own schema files against yours. In my schema this class is defined in `99-user` file, and in yours it's `100-user`.

From OpenDS docs it seems that `99-user` is the one where it saves all schema extensions added by user. In my 2.4.3 instance it stores this custom objectclass there too, though custom attributes are still in the `100-user` So the only thing I can recommend at the moment is to try to move this class's definition there (using the usual steps of updating configuration I provided above). Try to start opendj after that, check logs - if it's okay, start tomcat, then try to create a new custom attribute in web UI - that will result in update of schema files. Then check what actually has happened, what files these changes were written into. `99-user`? `100-user`? Another test you could do is to make some inactive `edu*` attribute active - as they are also being added to this custom class on activation. Backup prior to that is highly recommended.

Hi, Ben. Have you had an opportunity to try my last proposal? From what I see in docs, just putting this objectclass's definition into `99-user` and restarting everything should fix the issue (still you'll need to test custom attribute creation feature (from web UI) after that properly)

Sorry, no I haven't had a chance to try that yet as it is currently working and I have been a little swamped. I will give it a shot tomorrow and let you know how it goes.

Hi, Ben. I'm closing the ticket (we have a policy for tickets that aren't getting updates for some time). Feel free to post results here when you'll find time to test it.