Question from a potential implementer: can the automated installer be used on a shared server or does it need its own or at least its own slice? Thanks!

Hi Megan (and all), On Wed, Jul 23, 2014 at 12:45 PM, Megan Forbes <megan.forbes@lyrasis.org> wrote: > Question from a potential implementer: can the automated installer be used on a shared server or does it need its own or at least its own slice? CollectionSpace's automated installer can certainly be run on a server on which other services are already installed. You can also manually install CollectionSpace on a shared server. However, there are some reasons for concern, or at least caution, when considering doing so. As I understand it, the primary concern is that installing the dependencies for CollectionSpace can potentially impact the dependencies of other server applications. For instance, installing CollectionSpace - whether manually or via the automated installer: - Installs a local instance of the PostgreSQL server, makes some configuration changes to that server (such as changing access permissions), and creates users and databases. If a server host already had PostgreSQL installed, perhaps in a different version with a different configuration, this could potentially cause problems. (Summary: It probably isn't a good idea to run the automated CollectionSpace installer on a system with PostgreSQL already present. And the automated installer doesn't yet have a mechanism to specify that CollectionSpace should 'talk' to a remote CollectionSpace instance, rather than installing PostgreSQL locally, which could help mitigate that problem. I'll make a JIRA issue for that work, if it doesn't already exist.) - Installs Oracle Java 7 and makes it the default Java instance on the host. If a server host had applications relying on a different version of Java (whether Oracle, OpenJDK, or the like), that could potentially cause problems. (Summary: it probably isn't a good idea to run the CollectionSpace installer on a system with Java-dependent applications already present.) There may also be other dependencies issues. Here's a general one: the automated installer - and the manual installation instructions, as well - specify that various dependencies are to be installed via the built-in installers ("package managers") on Linux systems; specifically via 'yum' for RedHat-based Linux systems and 'apt-get' for Debian-based Linux systems. This could result in installing a version of a dependency, like ImageMagick, that is either newer or older than what was already present on a host, and that could potentially cause problems for other applications. Another concern is that installing CollectionSpace causes a Tomcat server folder to be added, and the instance of Tomcat that it adds - by default - is configured to listen on its standard port, 8080, as well as to have CollectionSpace listen on port 8180. It's possible that might present port conflicts, although those could be worked around via configuration tweaking. (Richard: have I missed anything here?) Aron Roberts Research IT UC Berkeley P.S. We're hopeful that using virtualization and/or containerization (e.g. Docker), we can avoid many of these types of potential conflicts altogether, and make CollectionSpace installation more flexible. > > Thanks! > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org