[Archivesspace_Users_Group] Running the (development) PUI on a separate server?

[Majewski, Steven Dennis (sdm7g)]

OK: This seems to work for me:


In the public:devserver target of build/build.xml:

  change -Daspace.config.backend_url=  to point to the remote backend server.


Solr URL  and public_user_secret are set in default_java_options property near the head of that file.

It looks like those can also be set from a JAVA_OPTS environment variable.

Solr URL should point to the remote solr server, and public_user_secret needs to be set to the same value for both local devserver and in AppConfig[:public_user_secret] on the remote server. Otherwise, you'll get login failures from the local public app being unable to log into the remote backend.


With those settings, it appears to be working for me, but I haven't exhaustively tested it.


-- Steve Majewski / UVA Alderman Library
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu>
Sent: Friday, September 29, 2017 4:09:56 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Running the (development) PUI on a separate server?


Oops: Sorry. I wasn't thinking correctly about running dev mode.


The URLs except for the ports are hardwired in build.xml.

Looks like it only needs itself and backend URLs.  ( No solr ? )



 <target name="public:devserver" depends="set-classpath, public:clean, public:copy-shared-resources" description="Start an instance of the ArchivesSpacePublic development server">

    <java classpath="${jruby_classpath}" classname="org.jruby.Main" fork="true" failonerror="true"

          dir="../public">

      <jvmarg line="-Daspace.service=public -Daspace.config.backend_url=http://localhost:${aspace.backend.port}/ -Daspace.config.public_url=http://localhost:${aspace.public.port}/ ${default_java_options} ${env.JAVA_OPTS}"/>

      <env key="GEM_HOME" value="${gem_home}" />

      <env key="GEM_PATH" value="" />

      <env key="BUNDLE_PATH" value="${gem_home}" />

      <env key="ASPACE_INTEGRATION" value="${aspace.integration}" />

      <arg line="bin/rails s mizuno -b 0.0.0.0 --port=${aspace.public.port}" />

    </java>

  </target>


-- Steve Majewski / UVA Alderman Library
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at virginia.edu>
Sent: Friday, September 29, 2017 3:57:09 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Running the (development) PUI on a separate server?


I haven't tried it (yet) but I'm guessing that you just have to set AppConfig[:enable_*] for all but :enable_public to false, and redirect all of the "http://localhost:port" default settings for AppConfig[:*_url] to point to the remote counterparts. You might also need to set AppConfig[:frontend_proxy_url]


That should (in theory) get you a configuration with only public server running, talking to backend, solr and frontend on remote server.



-- Steve Majewski / UVA Alderman Library
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Fox, Bobbi <bobbi_fox at harvard.edu>
Sent: Friday, September 29, 2017 2:14:58 PM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] Running the (development) PUI on a separate server?

Hi,

I’m working on customizing the PUI for our institution, working in development mode, and, rather than cloning off our humongous, takes-2+-days to index database (which I need to do, because my “product owner” is a committee made up of picky(yeah, that’s redundant) Archivists :-) , I was hoping to point to the backend of our V2.1.* QA system already running.

Has anyone tried this?  What incredible munging of the build.xml am I likely to need to do?

Thanks,
Bobbi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170929/2d4e005a/attachment.html>