/opt/zimbra/conf && LDAP

[ranpel]

May I ask why there exists /opt/zimbra/conf? If you can't configure anything from here why even place it? Because it's helpful? Too hard to look in ldap or the respective package? I'm trying to affect slapd.conf and frankly, the obfuscation layer of zimbra configuration is... a bit much. I thought Sun was bad.

That being said, how might one expand the schema in the zimbra ldap server? Or other equally nifty ldap configuration objectives?....

How might one turn on LDAPS:636?

(Please don't reply "You don't need it, you can do TLS on 389") Because if I could do TLS on 389 I wouldn't be trying.

I have more regarding postfix but it's time for na-night.
Thank you,
Randy

[dijichi2]

slapd.conf.in. it's not supposed to be used as a general ldap server, which is why it's self contained. if you extend schema, chances are it will either break next upgrade or your stuff will get lost/corrupted.

May I ask why there exists /opt/zimbra/conf? If you can't configure anything from here why even place it? Because it's helpful? Too hard to look in ldap or the respective package? I'm trying to affect slapd.conf and frankly, the obfuscation layer of zimbra configuration is... a bit much. I thought Sun was bad.

not sure what you're trying to say here. /opt/zimbra/conf is useful, contains lots of files you can configure, and they are deliberately centralised here away from respective package directories. the 'obsfucation' layer is for automated customization, not obsfucation.

[ranpel]

I appreciate your response. The question was how do I make changes to slapd.conf that will stay, not what happens if I do.

If Zimbra has enterprise level pieces that cannot be extended the long term value is diminished severely no? Why glob all these standard ports for non-extensible packages?

It's short term value is being evaluated at the moment...

"slapd.conf.in. it's not supposed to be used as a general ldap server, which is why it's self contained. if you extend schema, chances are it will either break next upgrade or your stuff will get lost/corrupted."

[ranpel]

Hi,

Also, I've already tried the approach in the wiki for nis and samba schema extensions. When I restart zimbra these extension are gone. Thus the question.

Thanks,
Randy

[phoenix]

Changes are made to the slapd.conf.in not slapd.conf - then the changes will 'stick'. It's not guaranteed that any changes made to parts of Zimbra will remain after an upgrade. The reason that it's done that way is because Zimbra, in it's current configuration, is a self contained set of packages that make it easy for us to upgrade and tune the components for the best performance of Zimbra.

[ranpel]

Hi,

Fantastic, thank you.

Yes I understand the approach. After I change it, and I like it, and it works.. make sure one can repeat it. :O)

Is there a similar approach to postfix or can I just chop main.cf?

Thanks again.

Randy

[phoenix]

The files in /opt/zimbra/conf that have an extension of .in can be modified and the relevant .conf is regenerated, if the .conf file is in an applications /conf directory it can be modified directly as, in general, they're static. As has been said, changes like this won't survive an upgrade.

[ranpel]

Good info that is.

Very good...

Thank you,
Randy