Couple of questions regarding configuring targets

System

Hi,

I have read through the manuals, and I am not finding what I need. That is likely because I am not 100% sure what to look for, so I am hoping someone can point me in the right direction.

I need to add 4 additional runtime environments to our setup. All 4 will be Linux based.

With that in mind, how do I add an additional deployment targets to the OOTB LSCS v7.2.1 deployment? These will need to have a different target directory than the existing as they are different platforms.

I know that each environment needs its own database instance, but two of the environemts will be identical. One of the Linux servers will replace the current windows based runtime host. Is it ok to configure the new Linux server to use the existing database currently in use by the windows server?

Our current setup is a Windows 2003 server running TeamSite/LiveSite/OpenDeploy 7.2.1. pushing to a windows 2003 server running LSDS/LSCS/Apache and tomcat and a SQL 2008 server. We are able to succesfully deploy LiveSite content to this server.

Thanks!

Rick Poulin

Ultimately, this is probably going to be more about being crafty with OpenDeploy things rather than LSCS deployment-specific things. The bottom line is that you're not making it easy on yourself by having different flavours of front-end platforms.

If it's at all possible, make your front ends exactly the same and use OpenDeploy's replication farms to deploy to all of them.

By having different deployment paths on different servers, you'd have to use separate target rules in your deployment config (LSDS's default is called teamsite-areadiff.xml, which you could copy+edit and then update the same in the LSCS authoring properties file) and/or go as far as having different deployment definitions, all executed within the same deployment instance.

The tricky bit about both suggestions is the import adapter. I haven't tried deploying to multiple LSDS instances at once myself, but that import adapter is configured to use Java RMI to talk to the instance it's deploying to. I don't know whether it'll work to update multiple servers unless you actually call the import adapter multiple times by using separate deployment definitions for each target -- less than ideal from a maintenance and performance perspective.