Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: hpras on February 27, 2015, 08:16:28 pm
-
I tried Zentyal 3.4 a while back on our domain, it provisioned correctly but had the samba/outlook/openchange crash bug, so I removed the openchange server completely. I have tried to load 4.0 up, joined the AD, and transferred the FSMO roles to it. Running the web-gui or the commandline I get the following...... (domain and passwords changed to protect the guilty)
bob@sbsmail:/etc/samba$ sudo openchange_provision --firstorg='SBS' --standalone --user='hans' --password='******'
params.c:pm_process() - Processing configuration file "/etc/samba/shares.conf"
NOTE: This operation can take several minutes
- Step 1: Register Exchange OIDs
- Step 2: Add Exchange attributes to Samba schema
Error: "(68, 'Entry CN=ms-Exch-Access-Control-Map,CN=Schema,CN=Configuration,DC=domain,DC=domain,DC=com already exists')" when adding element:
#
# ms-Exch-Access-Control-Map
# Contains the mapping for the access controls.
#
dn: CN=ms-Exch-Access-Control-Map,CN=Schema,CN=Configuration,DC=domain,DC=domain,DC=com
objectClass: top
objectClass: attributeSchema
cn: ms-Exch-Access-Control-Map
distinguishedName: CN=ms-Exch-Access-Control-Map,CN=Schema,CN=Configuration,DC=domain,DC=domain,DC=com
attributeID: 1.2.840.113556.1.4.7000.102.64
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
showInAdvancedViewOnly: TRUE
adminDisplayName: ms-Exch-Access-Control-Map
adminDescription: ms-Exch-Access-Control-Map
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: msExchAccessControlMap
name: ms-Exch-Access-Control-Map
#schemaIDGUID: 8ff54464-b093-11d2-aa06-00c04f8eedd8
isMemberOfPartialAttributeSet: FALSE
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=domain,DC=domain,DC=com
[!] error while provisioning the Exchange schema classes (68): Entry CN=ms-Exch-Access-Control-Map,CN=Schema,CN=Configuration,DC=domain,DC=domain,DC=com already exists
Traceback (most recent call last):
File "/usr/sbin/openchange_provision", line 109, in <module>
openchange.provision(setup_path, provisionnames, lp, creds)
File "/usr/lib/python2.7/dist-packages/openchange/provision.py", line 777, in provision
install_schemas(setup_path, names, lp, creds, reporter)
File "/usr/lib/python2.7/dist-packages/openchange/provision.py", line 447, in install_schemas
provision_schema(sam_db, setup_path, names, reporter, schema['path'], schema['description'], schema['modify_mode'])
File "/usr/lib/python2.7/dist-packages/openchange/provision.py", line 233, in provision_schema
sam_db.add_ldif(el, ['relax:0'])
File "/usr/lib/python2.7/dist-packages/samba/__init__.py", line 224, in add_ldif
self.add(msg, controls)
_ldb.LdbError: (68, 'Entry CN=ms-Exch-Access-Control-Map,CN=Schema,CN=Configuration,DC=domain,DC=domain,DC=com already exists')
It looks like the old provisioning is blocking the ability to setup openchange. Any ideas out there?
Thanks
-
Hi,
I had a similar situation when I de-provisioned openchange and tried to re-provision again.
I solved it with a HACK (please note the importance of HACK) of the python code.
Please be warned this may not work for you and you should backup your server before testing. Or even better duplicate your issue in a VM for testing.
In my case I concluded that the AD schema was extended on my first provision of openchange and that the provision script was not properly checking for this and trying to re-extend the ad schema.
I tracked it down to lines 413-453 in /usr/lib/python2.7/dist-packages/openchange/provision.py which seem to be used to extend the AD schema.
From the Zentyal console...
sudo leafpad /usr/lib/python2.7/dist-packages/openchange/provision.py
Then in leafpad...
Options->Line Numbers
to enable the line numbering.
Scroll down to line 444.
'modify_mode': True}]
and insert a new line below. and type the following (note it starts with four spaces, these are important)
schemas = []
--------------------------
So lines 444 -> 446 should now read
'modify_mode': True}]
schemas = []
for schema in schemas:
This hack makes the list of schema modifications to add empty so the script does not try and alter the AD schema.
As mentioned at the beginning THIS IS A HACK and it should be removed from the code once / if it works for you.
I have no idea as to the consequences of removing these lines but it worked for me. I suspect that if your AD has not had the schema alterations made previously it could cause other issues. Also I am unsure if it will work on upgraded systems as the scheme may have been altered during version changes and need alterations by the script.
All that being said it worked for me and it is possibly worth a shot (having made proper backups etc).
-
Great hack!
Thank you so much
Fed
-
Dear Cal-Tec,
I'm having another problem, I think based on the alteration of the schema.
The re-provision worked well but anytime I would like to enable open change mail for each user I got the following error:
root command openchange_newuser --create --enable --mail Firstname.LastName@zentyal-domain.lan 'firstname.Lastname' failed. Error output: params.c:pm_process() - Processing configuration file "/etc/samba/openchange.conf" params.c:pm_process() - Processing configuration file "/etc/samba/shares.conf" Traceback (most recent call last): File "/usr/sbin/openchange_newuser", line 69, in <module> provision.newuser(provisionnames, lp, creds, username=username, mail=opts.mail) File "/usr/lib/python2.7/dist-packages/openchange/provision.py", line 674, in newuser db.modify_ldif(ldif_value) File "/usr/lib/python2.7/dist-packages/samba/__init__.py", line 235, in modify_ldif self.modify(msg, controls) _ldb.LdbError: (16, "objectclass_attrs: attribute 'msExchRecipientTypeDetails' on entry 'CN=Firstname lastname,CN=Users,DC=zentyal-domain,DC=lan' was not found in the schema!") Command output: . Exit value: 1 at /usr/share/perl5/EBox/Sudo.pm line 240
I bet is because I have used your hack but then I deleted and now it can find the right schema where to change user properties.
Sorry but I don't know much of python neither LDAP ....
Thanks for any additional info
Federico
-
The cleaner approach to force re-provisioning regardless of your fu**ed up LDAP:
The manpage of openchange_provision says:
--ignore-already-exists
Ignore errors when installing schemas that already
exists
So we only need to find the call for openchange_provision in that bunch of perl source files - it's hidden in /usr/share/perl5/EBox/OpenChange/Model/Provision.pm on line 457:
my $cmd = "openchange_provision --firstorg='$organizationName' ";
just add that command line switch:
my $cmd = "openchange_provision --ignore-already-exists --firstorg='$organizationName' ";
Provisioning should be possible now using the web-gui
-
seteq,
Did you test this procedure ou it's just based on openchange manpage?
Jose
-
Hi,
I am here on Zentyal 4.1 and I could not reprovison openchange also.
I can confirm that adding "--ignore-already-exists" into "Provision.pm" works:
vim /usr/share/perl5/EBox/OpenChange/Model/Provision.pm +457
[...]
So we only need to find the call for openchange_provision in that bunch of perl source files - it's hidden in /usr/share/perl5/EBox/OpenChange/Model/Provision.pm on line 457:
my $cmd = "openchange_provision --firstorg='$organizationName' ";
just add that command line switch:
my $cmd = "openchange_provision --ignore-already-exists --firstorg='$organizationName' ";
-
Seems to work for 4.2 as well.
-
Hi, thanks for this brilliant HACK!!!!!
Works on Zentyal 4.0
Best
Alejandro
-
Oh what a great fix. Thanks a lot.