Since OpenDeploy 7.1 the database passwords inside the database.xml must be either encoded or encrypted. A crucial fact the Autonomy has, well to put it nicely, forgotten to put in any documentation.

Strangely, the type of encoding/encryption is determined by the 'strictAuthentication' setting in odbase.xml (I really, really don't see how these setting could ever be related. The strictAuthentication has to do with whether 2 opendeploy servers should do a strict or loose ip check to authenticate themselves.)

So if strictAuthentication is set to:
- no: then ENCODE your password using the clt iwodpasscoder (simple base64 encoding, no security whatsoever!)
- yes: then ENCRYPT your password using the clt iwodpassencrypter
(PBEWithMD5AndDES encryption with a password equal to the fq hostname, by default; not secure in any way!)
and enter the result of the clt in database.xml.

[And don't forget, if you ever change this setting to update this file again]

I've seen many Teamsite implementations that deploy from the Staging area. This is not optimal and let me explain today why I think so.

Teamsite has excellent version management capabilities that will give you an historic archive over your website, if you chose to use it by creating editions before you actual deploy them. By passing this feature will leave you with a teamsite implementation that misses out on one of the most powerfull features. Apart from this rather theoratical reason there are also some more pratical reasons:

1. you will loose the option to rollback your website to a previous edition

2. the staging area is not garantueed to be stable during the lifespan of the deployment, which can give unexpected results

3. you will not be able to compare editions to know what has changed in between two deploys

4. you will not comply anymore with tracebility requirements (like f.i. the Sarbanes-Oxley laws)

OpenDeploy 6.1.1 has been out for quite a while. I have not had a look at it for a while but I don't think there was any reason to look at this version before: it does not contain much news.

The new features that are included are not that shocking (some new adapters and an option to only deploy files at the root-level, I'm not sure yet what good that is for).

But it comes with 1 major drawback and one that is well hidden in the release notes: you must obtain (and install) a license key for each install (both base server and receiver). This fact should be WRITTEN IN BOLD in the release notes but no, Interwoven has chosen not to mention this at all. How stupid can you be? The good thing is that license keys for receivers can be installed remote via.... opendeploy!!!. That is indeed quite nice.

And obtaining an license key is the same old hassle it has been since TS65 Sp2: via a website that is running on (or should I say hidden behind) port 8080. This port is, in most sensible enterprises, blocked for out going traffic. And thus you either have to use your private home internet connection, how professional, or send a request to support via email. Either way, it will cost you extra downtime, something that you can do without on any production server. You would think Interwoven would be wiser and run this website on a decent port, well let's say port 80.

Little tip for if you want to install Ts65Sp2 on a production server AND minimize downtime: install the service pack on another server, copy the license-detail executable to your production server and run it. It will return the needed details to generate a key BEFORE you run the Sp2-installer.