TG
Tony Garnock-Jones
Fri, Apr 3, 2015 11:35 AM
Hi all,
I hope this is the right place for newbie installation questions.
Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
from
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
as root.
After a few failed runs -- it seems mostly network timeout related -- it
looked like it completed successfully. However, upon starting the server
and visiting the login page, I cannot log in as the admin user.
Inspecting the database tables (psql -h localhost -U cspace, select *
from users), I see zero user rows.
I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
create_db -Drecreate_db=true import". Still no rows in the users table.
Any suggestions for things to try? Perhaps there is a command-line tool
I could use to create some users?
Since it's a virtual machine, in extremis I could blow the whole thing
away and start again, but I'd prefer not to have to take that step if I
can avoid it :-)
Thanks for any advice anyone might have.
Cheers,
Tony
Hi all,
I hope this is the right place for newbie installation questions.
Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
from
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
as root.
After a few failed runs -- it seems mostly network timeout related -- it
looked like it completed successfully. However, upon starting the server
and visiting the login page, I cannot log in as the admin user.
Inspecting the database tables (psql -h localhost -U cspace, select *
from users), I see zero user rows.
I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
create_db -Drecreate_db=true import". Still no rows in the users table.
Any suggestions for things to try? Perhaps there is a command-line tool
I could use to create some users?
Since it's a virtual machine, in extremis I could blow the whole thing
away and start again, but I'd prefer not to have to take that step if I
can avoid it :-)
Thanks for any advice anyone might have.
Cheers,
Tony
AR
Aron Roberts
Fri, Apr 3, 2015 7:50 PM
Hi Tony,
We've also occasionally encountered similar network timeout issues, and
have had the same experience with failed installations when those occur.
(I'll make a JIRA issue for that, so we can look into making the installer
more robust, when one or more of the components it's downloading isn't
rapidly available.)
One thought: you might first try backtracking a bit, but not as far as
re-creating the VM ...
Perhaps try this? (The following assumes you're in the home directory of
a user with 'sudo' privileges on your VM ...)
First, doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
Second, re-running the bootstrap script (without '-y'), just to make sure
you've got all the latest modules. (I just spotted and fixed an issue in
one test module, a fix that's needed to make the next step below succeed.)
sudo ./bootstrap-cspace-modules.sh
(If for any reason a copy of that bootstrap script isn't present, you can
download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
)
And then re-running the installation, beginning at a late step in the
process:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
(If all the prerequisites were successfully installed, such as Ant, Maven,
Oracle JDK 7, and PostgreSQL, I'm hoping this will take it from there ...)
I'm currently in the middle of testing this, so I haven't yet verified that
this will work. But if you're willing to experiment with it, this approach
might be a bit less monumental and time-consuming than starting from
scratch ...
Thanks!
Aron Roberts
UC Berkeley
On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones tonyg@ccs.neu.edu
wrote:
Hi all,
I hope this is the right place for newbie installation questions.
Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
from
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
as root.
After a few failed runs -- it seems mostly network timeout related -- it
looked like it completed successfully. However, upon starting the server
and visiting the login page, I cannot log in as the admin user.
Inspecting the database tables (psql -h localhost -U cspace, select *
from users), I see zero user rows.
I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
create_db -Drecreate_db=true import". Still no rows in the users table.
Any suggestions for things to try? Perhaps there is a command-line tool
I could use to create some users?
Since it's a virtual machine, in extremis I could blow the whole thing
away and start again, but I'd prefer not to have to take that step if I
can avoid it :-)
Thanks for any advice anyone might have.
Cheers,
Tony
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Tony,
We've also occasionally encountered similar network timeout issues, and
have had the same experience with failed installations when those occur.
(I'll make a JIRA issue for that, so we can look into making the installer
more robust, when one or more of the components it's downloading isn't
rapidly available.)
One thought: you might first try backtracking a bit, but not as far as
re-creating the VM ...
Perhaps try this? (The following assumes you're in the home directory of
a user with 'sudo' privileges on your VM ...)
First, doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
Second, re-running the bootstrap script (without '-y'), just to make sure
you've got all the latest modules. (I just spotted and fixed an issue in
one test module, a fix that's needed to make the next step below succeed.)
sudo ./bootstrap-cspace-modules.sh
(If for any reason a copy of that bootstrap script isn't present, you can
download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
)
And then re-running the installation, beginning at a late step in the
process:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
(If all the prerequisites were successfully installed, such as Ant, Maven,
Oracle JDK 7, and PostgreSQL, I'm hoping this will take it from there ...)
I'm currently in the middle of testing this, so I haven't yet verified that
this will work. But if you're willing to experiment with it, this approach
might be a bit less monumental and time-consuming than starting from
scratch ...
Thanks!
Aron Roberts
UC Berkeley
On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones <tonyg@ccs.neu.edu>
wrote:
> Hi all,
>
> I hope this is the right place for newbie installation questions.
>
> Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
> from
>
> http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
> as root.
>
> After a few failed runs -- it seems mostly network timeout related -- it
> looked like it completed successfully. However, upon starting the server
> and visiting the login page, I cannot log in as the admin user.
>
> Inspecting the database tables (psql -h localhost -U cspace, select *
> from users), I see zero user rows.
>
> I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
> create_db -Drecreate_db=true import". Still no rows in the users table.
>
> Any suggestions for things to try? Perhaps there is a command-line tool
> I could use to create some users?
>
> Since it's a virtual machine, in extremis I could blow the whole thing
> away and start again, but I'd prefer not to have to take that step if I
> can avoid it :-)
>
> Thanks for any advice anyone might have.
>
> Cheers,
> Tony
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
AR
Aron Roberts
Fri, Apr 3, 2015 10:13 PM
Hi Tony,
Just tested this: doing a 'repair' installation of CollectionSpace using
the automated installer was successful, and fortunately it doesn't require
going back and re-generating the VM from scratch. There are a couple more
steps involved at the end of this process, which have been added below.
Please note that the default users for each tenant (an admin user and a
read-only user) are created, if needed, each time the server has
successfully started up, so the 'users' table in the 'cspace' database will
- legitimately - be empty until that occurs at least once.
Aron
--
The full set of steps:
- Doing some cleanup of the artifacts (databases, source code directories)
created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
- Re-running the bootstrap script (without '-y'), just to make sure you've
got all the latest modules. (I just spotted and fixed an issue in one test
module, a fix that's needed to make the next step below succeed.)
sudo ./bootstrap-cspace-modules.sh
(When asked "Install your CollectionSpace server now [y/n]?", enter 'n')
(If for any reason a copy of that bootstrap script isn't present, you can
download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
)
- Re-running the CollectionSpace server installation, beginning at a late
step in the process ... the one that checks out source code and builds and
deploys the server:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
- Starting the server:
sudo su cspace
$CATALINA_HOME/bin/startup.sh
(Optional: view startup messages until the server starts up)
tail -f $CATALINA_HOME/logs/catalina.out
- Verifying that the server's Services layer is functional and that
AuthN/AuthZ is working:
curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/intakes
If all this works, there's a high likelihood that login via the browser
will work successfully as well.
On Fri, Apr 3, 2015 at 12:50 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
Hi Tony,
We've also occasionally encountered similar network timeout issues, and
have had the same experience with failed installations when those occur.
(I'll make a JIRA issue for that, so we can look into making the installer
more robust, when one or more of the components it's downloading isn't
rapidly available.)
One thought: you might first try backtracking a bit, but not as far as
re-creating the VM ...
Perhaps try this? (The following assumes you're in the home directory of
a user with 'sudo' privileges on your VM ...)
First, doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
Second, re-running the bootstrap script (without '-y'), just to make sure
you've got all the latest modules. (I just spotted and fixed an issue in
one test module, a fix that's needed to make the next step below succeed.)
sudo ./bootstrap-cspace-modules.sh
(If for any reason a copy of that bootstrap script isn't present, you can
download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
)
And then re-running the installation, beginning at a late step in the
process:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
(If all the prerequisites were successfully installed, such as Ant, Maven,
Oracle JDK 7, and PostgreSQL, I'm hoping this will take it from there ...)
I'm currently in the middle of testing this, so I haven't yet verified
that this will work. But if you're willing to experiment with it, this
approach might be a bit less monumental and time-consuming than starting
from scratch ...
Thanks!
Aron Roberts
UC Berkeley
On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones tonyg@ccs.neu.edu
wrote:
Hi all,
I hope this is the right place for newbie installation questions.
Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
from
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
as root.
After a few failed runs -- it seems mostly network timeout related -- it
looked like it completed successfully. However, upon starting the server
and visiting the login page, I cannot log in as the admin user.
Inspecting the database tables (psql -h localhost -U cspace, select *
from users), I see zero user rows.
I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
create_db -Drecreate_db=true import". Still no rows in the users table.
Any suggestions for things to try? Perhaps there is a command-line tool
I could use to create some users?
Since it's a virtual machine, in extremis I could blow the whole thing
away and start again, but I'd prefer not to have to take that step if I
can avoid it :-)
Thanks for any advice anyone might have.
Cheers,
Tony
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Tony,
Just tested this: doing a 'repair' installation of CollectionSpace using
the automated installer was successful, and fortunately it doesn't require
going back and re-generating the VM from scratch. There are a couple more
steps involved at the end of this process, which have been added below.
Please note that the default users for each tenant (an admin user and a
read-only user) are created, if needed, each time the server has
successfully started up, so the 'users' table in the 'cspace' database will
- legitimately - be empty until that occurs at least once.
Aron
--
The full set of steps:
1. Doing some cleanup of the artifacts (databases, source code directories)
created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
2. Re-running the bootstrap script (without '-y'), just to make sure you've
got all the latest modules. (I just spotted and fixed an issue in one test
module, a fix that's needed to make the next step below succeed.)
sudo ./bootstrap-cspace-modules.sh
(When asked "Install your CollectionSpace server now [y/n]?", enter 'n')
(If for any reason a copy of that bootstrap script isn't present, you can
download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
)
3. Re-running the CollectionSpace server installation, beginning at a late
step in the process ... the one that checks out source code and builds and
deploys the server:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
4. Starting the server:
sudo su cspace
$CATALINA_HOME/bin/startup.sh
(Optional: view startup messages until the server starts up)
tail -f $CATALINA_HOME/logs/catalina.out
5. Verifying that the server's Services layer is functional and that
AuthN/AuthZ is working:
curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/intakes
If all this works, there's a high likelihood that login via the browser
will work successfully as well.
On Fri, Apr 3, 2015 at 12:50 PM, Aron Roberts <aron@socrates.berkeley.edu>
wrote:
> Hi Tony,
>
> We've also occasionally encountered similar network timeout issues, and
> have had the same experience with failed installations when those occur.
> (I'll make a JIRA issue for that, so we can look into making the installer
> more robust, when one or more of the components it's downloading isn't
> rapidly available.)
>
> One thought: you might first try backtracking a bit, but not as far as
> re-creating the VM ...
>
> Perhaps try this? (The following assumes you're in the home directory of
> a user with 'sudo' privileges on your VM ...)
>
> First, doing some cleanup of the artifacts (databases, source code
> directories) created during the later parts of the installation:
>
> sudo -u postgres dropdb cspace
> sudo -u postgres dropdb nuxeo
> sudo -u postgres dropdb lifesci_domain
>
> sudo rm -Rf /home/cspace/cspace_source/
>
> Second, re-running the bootstrap script (without '-y'), just to make sure
> you've got all the latest modules. (I just spotted and fixed an issue in
> one test module, a fix that's needed to make the next step below succeed.)
>
> sudo ./bootstrap-cspace-modules.sh
>
> (If for any reason a copy of that bootstrap script isn't present, you can
> download it again via the steps listed at
> http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
> )
>
> And then re-running the installation, beginning at a late step in the
> process:
>
> sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
>
> (If all the prerequisites were successfully installed, such as Ant, Maven,
> Oracle JDK 7, and PostgreSQL, I'm hoping this will take it from there ...)
>
> I'm currently in the middle of testing this, so I haven't yet verified
> that this will work. But if you're willing to experiment with it, this
> approach might be a bit less monumental and time-consuming than starting
> from scratch ...
>
> Thanks!
> Aron Roberts
> UC Berkeley
>
> On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones <tonyg@ccs.neu.edu>
> wrote:
>
>> Hi all,
>>
>> I hope this is the right place for newbie installation questions.
>>
>> Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
>> from
>>
>> http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
>> as root.
>>
>> After a few failed runs -- it seems mostly network timeout related -- it
>> looked like it completed successfully. However, upon starting the server
>> and visiting the login page, I cannot log in as the admin user.
>>
>> Inspecting the database tables (psql -h localhost -U cspace, select *
>> from users), I see zero user rows.
>>
>> I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
>> create_db -Drecreate_db=true import". Still no rows in the users table.
>>
>> Any suggestions for things to try? Perhaps there is a command-line tool
>> I could use to create some users?
>>
>> Since it's a virtual machine, in extremis I could blow the whole thing
>> away and start again, but I'd prefer not to have to take that step if I
>> can avoid it :-)
>>
>> Thanks for any advice anyone might have.
>>
>> Cheers,
>> Tony
>>
>> _______________________________________________
>> Talk mailing list
>> Talk@lists.collectionspace.org
>>
>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>>
>
>
TG
Tony Garnock-Jones
Sat, Apr 4, 2015 4:34 AM
Hi Aron,
Thanks for that detailed guide! Unfortunately, after performing all the
steps, I'm still having no luck.
Looking at the logs (I wish I'd done this more closely before), I see
that it is complaining "SEVERE: Exception processing JAR at resource
path /usr/local/share/apache-tomcat-6.0.33/lib/cspace.jar in context
/cspace-services", "java.util.zip.ZipException: error in opening zip file".
Sure enough, inspecting that file with unzip -v shows it's corrupt (no
zip directory at the end). I've deleted it, and am trying "ant deploy"
again.
... hmm. It wasn't recreated. The logs no longer complain about
cspace.jar (presumably because it is entirely absent now), but I'm still
getting errors such as this:
SEVERE: Error loading WebappClassLoader
context: /host-manager
delegate: false
repositories:
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@2571157a
org.apache.jasper.servlet.JspServlet
java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
I'll attach my log files, in case they're useful.
I know how difficult it is to debug problems like this; do let me know
if there's something obvious that leaps out at you from the logs.
Otherwise, given my rustiness with tomcat and j2ee in general (it has
been more than 10 years! scary), I'll probably throw away this VM, make
another from scratch, and hope everything goes smoothly on the rerun.
Regards, and thanks again,
Tony
On 04/03/2015 06:13 PM, Aron Roberts wrote:
Hi Tony,
Just tested this: doing a 'repair' installation of CollectionSpace
using the automated installer was successful, and fortunately it doesn't
require going back and re-generating the VM from scratch. There are a
couple more steps involved at the end of this process, which have been
added below.
Please note that the default users for each tenant (an admin user and
a read-only user) are created, if needed, each time the server has
successfully started up, so the 'users' table in the 'cspace' database
will - legitimately - be empty until that occurs at least once.
Aron
--
The full set of steps:
- Doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
- Re-running the bootstrap script (without '-y'), just to make sure
you've got all the latest modules. (I just spotted and fixed an issue in
one test module, a fix that's needed to make the next step below succeed.)
sudo ./bootstrap-cspace-modules.sh
(When asked "Install your CollectionSpace server now [y/n]?", enter 'n')
(If for any reason a copy of that bootstrap script isn't present, you
can download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller)
- Re-running the CollectionSpace server installation, beginning at a
late step in the process ... the one that checks out source code and
builds and deploys the server:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
- Starting the server:
sudo su cspace
$CATALINA_HOME/bin/startup.sh
(Optional: view startup messages until the server starts up)
tail -f $CATALINA_HOME/logs/catalina.out
- Verifying that the server's Services layer is functional and that
AuthN/AuthZ is working:
curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/intakes
If all this works, there's a high likelihood that login via the browser
will work successfully as well.
On Fri, Apr 3, 2015 at 12:50 PM, Aron Roberts
<aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
Hi Tony,
We've also occasionally encountered similar network timeout
issues, and have had the same experience with failed installations
when those occur. (I'll make a JIRA issue for that, so we can look
into making the installer more robust, when one or more of the
components it's downloading isn't rapidly available.)
One thought: you might first try backtracking a bit, but not as
far as re-creating the VM ...
Perhaps try this? (The following assumes you're in the home
directory of a user with 'sudo' privileges on your VM ...)
First, doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
Second, re-running the bootstrap script (without '-y'), just to make
sure you've got all the latest modules. (I just spotted and fixed an
issue in one test module, a fix that's needed to make the next step
below succeed.)
sudo ./bootstrap-cspace-modules.sh
(If for any reason a copy of that bootstrap script isn't present,
you can download it again via the steps listed at
http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller)
And then re-running the installation, beginning at a late step in
the process:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
(If all the prerequisites were successfully installed, such as Ant,
Maven, Oracle JDK 7, and PostgreSQL, I'm hoping this will take it
from there ...)
I'm currently in the middle of testing this, so I haven't yet
verified that this will work. But if you're willing to experiment
with it, this approach might be a bit less monumental and
time-consuming than starting from scratch ...
Thanks!
Aron Roberts
UC Berkeley
On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones
<tonyg@ccs.neu.edu <mailto:tonyg@ccs.neu.edu>> wrote:
Hi all,
I hope this is the right place for newbie installation questions.
Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
from
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
as root.
After a few failed runs -- it seems mostly network timeout
related -- it
looked like it completed successfully. However, upon starting
the server
and visiting the login page, I cannot log in as the admin user.
Inspecting the database tables (psql -h localhost -U cspace,
select *
from users), I see zero user rows.
I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
create_db -Drecreate_db=true import". Still no rows in the users
table.
Any suggestions for things to try? Perhaps there is a
command-line tool
I could use to create some users?
Since it's a virtual machine, in extremis I could blow the whole
thing
away and start again, but I'd prefer not to have to take that
step if I
can avoid it :-)
Thanks for any advice anyone might have.
Cheers,
Tony
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto:Talk@lists.collectionspace.org>
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Hi Aron,
Thanks for that detailed guide! Unfortunately, after performing all the
steps, I'm still having no luck.
Looking at the logs (I wish I'd done this more closely before), I see
that it is complaining "SEVERE: Exception processing JAR at resource
path /usr/local/share/apache-tomcat-6.0.33/lib/cspace.jar in context
/cspace-services", "java.util.zip.ZipException: error in opening zip file".
Sure enough, inspecting that file with unzip -v shows it's corrupt (no
zip directory at the end). I've deleted it, and am trying "ant deploy"
again.
... hmm. It wasn't recreated. The logs no longer complain about
cspace.jar (presumably because it is entirely absent now), but I'm still
getting errors such as this:
SEVERE: Error loading WebappClassLoader
context: /host-manager
delegate: false
repositories:
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@2571157a
org.apache.jasper.servlet.JspServlet
java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
I'll attach my log files, in case they're useful.
I know how difficult it is to debug problems like this; do let me know
if there's something obvious that leaps out at you from the logs.
Otherwise, given my rustiness with tomcat and j2ee in general (it has
been more than 10 years! scary), I'll probably throw away this VM, make
another from scratch, and hope everything goes smoothly on the rerun.
Regards, and thanks again,
Tony
On 04/03/2015 06:13 PM, Aron Roberts wrote:
> Hi Tony,
>
> Just tested this: doing a 'repair' installation of CollectionSpace
> using the automated installer was successful, and fortunately it doesn't
> require going back and re-generating the VM from scratch. There are a
> couple more steps involved at the end of this process, which have been
> added below.
>
> Please note that the default users for each tenant (an admin user and
> a read-only user) are created, if needed, each time the server has
> successfully started up, so the 'users' table in the 'cspace' database
> will - legitimately - be empty until that occurs at least once.
>
> Aron
>
> --
>
> The full set of steps:
>
> 1. Doing some cleanup of the artifacts (databases, source code
> directories) created during the later parts of the installation:
>
> sudo -u postgres dropdb cspace
> sudo -u postgres dropdb nuxeo
> sudo -u postgres dropdb lifesci_domain
>
> sudo rm -Rf /home/cspace/cspace_source/
>
> 2. Re-running the bootstrap script (without '-y'), just to make sure
> you've got all the latest modules. (I just spotted and fixed an issue in
> one test module, a fix that's needed to make the next step below succeed.)
>
> sudo ./bootstrap-cspace-modules.sh
>
> (When asked "Install your CollectionSpace server now [y/n]?", enter 'n')
>
> (If for any reason a copy of that bootstrap script isn't present, you
> can download it again via the steps listed at
> http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller)
>
> 3. Re-running the CollectionSpace server installation, beginning at a
> late step in the process ... the one that checks out source code and
> builds and deploys the server:
>
> sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
>
> 4. Starting the server:
>
> sudo su cspace
> $CATALINA_HOME/bin/startup.sh
>
> (Optional: view startup messages until the server starts up)
> tail -f $CATALINA_HOME/logs/catalina.out
>
> 5. Verifying that the server's Services layer is functional and that
> AuthN/AuthZ is working:
>
> curl -i -u admin@core.collectionspace.org:Administrator
> http://localhost:8180/cspace-services/intakes
>
> If all this works, there's a high likelihood that login via the browser
> will work successfully as well.
>
>
> On Fri, Apr 3, 2015 at 12:50 PM, Aron Roberts
> <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote:
>
> Hi Tony,
>
> We've also occasionally encountered similar network timeout
> issues, and have had the same experience with failed installations
> when those occur. (I'll make a JIRA issue for that, so we can look
> into making the installer more robust, when one or more of the
> components it's downloading isn't rapidly available.)
>
> One thought: you might first try backtracking a bit, but not as
> far as re-creating the VM ...
>
> Perhaps try this? (The following assumes you're in the home
> directory of a user with 'sudo' privileges on your VM ...)
>
> First, doing some cleanup of the artifacts (databases, source code
> directories) created during the later parts of the installation:
>
> sudo -u postgres dropdb cspace
> sudo -u postgres dropdb nuxeo
> sudo -u postgres dropdb lifesci_domain
>
> sudo rm -Rf /home/cspace/cspace_source/
>
> Second, re-running the bootstrap script (without '-y'), just to make
> sure you've got all the latest modules. (I just spotted and fixed an
> issue in one test module, a fix that's needed to make the next step
> below succeed.)
>
> sudo ./bootstrap-cspace-modules.sh
>
> (If for any reason a copy of that bootstrap script isn't present,
> you can download it again via the steps listed at
> http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller)
>
> And then re-running the installation, beginning at a late step in
> the process:
>
> sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
>
> (If all the prerequisites were successfully installed, such as Ant,
> Maven, Oracle JDK 7, and PostgreSQL, I'm hoping this will take it
> from there ...)
>
> I'm currently in the middle of testing this, so I haven't yet
> verified that this will work. But if you're willing to experiment
> with it, this approach might be a bit less monumental and
> time-consuming than starting from scratch ...
>
> Thanks!
> Aron Roberts
> UC Berkeley
>
> On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones
> <tonyg@ccs.neu.edu <mailto:tonyg@ccs.neu.edu>> wrote:
>
> Hi all,
>
> I hope this is the right place for newbie installation questions.
>
> Yesterday I created a fresh Ubuntu 14.04 instance and ran the script
> from
> http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
> as root.
>
> After a few failed runs -- it seems mostly network timeout
> related -- it
> looked like it completed successfully. However, upon starting
> the server
> and visiting the login page, I cannot log in as the admin user.
>
> Inspecting the database tables (psql -h localhost -U cspace,
> select *
> from users), I see zero user rows.
>
> I have tried "sudo -u postgres dropdb cspace", followed by "sudo ant
> create_db -Drecreate_db=true import". Still no rows in the users
> table.
>
> Any suggestions for things to try? Perhaps there is a
> command-line tool
> I could use to create some users?
>
> Since it's a virtual machine, in extremis I could blow the whole
> thing
> away and start again, but I'd prefer not to have to take that
> step if I
> can avoid it :-)
>
> Thanks for any advice anyone might have.
>
> Cheers,
> Tony
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
> <mailto:Talk@lists.collectionspace.org>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
>
>
AR
Aron Roberts
Mon, Apr 6, 2015 8:27 PM
Hi Tony,
My sincere apologies for this delayed response. The corrupted
lib/cspace.jar file is definitely of concern. That hints at issues with the
integrity of contents of the Tomcat folder, regardless of the possible
cause or causes.
It's probably a good idea to start over with a new VM. If you'd like to
experiment a bit, here's an almost completely unattended way to create a
VirtualBox VM running Ubuntu 14.04.x LTS, and then run the automated
CollectionSpace server installer within that VM:
- Install both VirtualBox (https://www.virtualbox.org/) and Vagrant (
https://www.vagrantup.com/).
- Create a directory.
- Cd to that directory.
- Download the file named 'Vagrantfile' from
https://github.com/mark-cooper/cspace_vagrantbox into that directory. (E.g.
right-click or Ctrl-click the Vagrantfile link and choose "Save Link As..."
or equivalent; copy the Vagrantfile into that directory, from your
Downloads folder, if needed)
- From within the directory you created, enter: vagrant up
(This will initiate the automated installer and start displaying
progress messages; allow at least 30 minutes for
installation to complete. If any serious errors occur during installation,
feel free to share them here. You can also retry that process; 'exit' from
the VM, then at your host computer's shell prompt, enter 'vagrant halt',
'vagrant destroy', and then 'vagrant up', to start the installation process
over, once again.)
If/when installation appears to succeed:
- Log in to the VM by entering: vagrant ssh
(No username/password should be needed; you can use 'vagrant' and
'vagrant' if you're ever asked for these)
- Change to the 'cspace' user account by entering: sudo su cspace.
- Start the CollectionSpace server by entering:
$CATALINA_HOME/bin/startup.sh
- If you wish, you can monitor the server's console output during startup
via: tail -f $CATALINA_HOME/logs/catalina.out (Enter Control-C to break
out of 'tail', when you're done monitoring.)
- Test CollectionSpace's services layer by entering:
curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/intakes
(If all is well, you should see a '200 OK' response with an XML document in
its body.)
- Connect to CollectionSpace in your browser (on your host computer, not
in the VM) via http://10.11.12.45:8180/collectionspace/ui/core/index.html
(That private IP address is hard-coded in the Vagrantfile used to start up
the VM. If that doesn't work, enter 'ipconfig' to verify the relevant IPv4
addresses assigned to 'eth1' and 'eth0', and, if different from
"10.11.12.45", try each of those, in turn.)
- Try logging in via the Sign In screen.
If login succeeds, you can proceed with the remaining setup instructions
at
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Afterinstallation
As well, if for some reason installation is continually failing, you
might try:
- Getting a pre-made VM; see
http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-March/001922.html
- Doing a manual installation.
Good luck!
Aron
On Fri, Apr 3, 2015 at 9:34 PM, Tony Garnock-Jones tonyg@ccs.neu.edu
wrote:
Hi Aron,
Thanks for that detailed guide! Unfortunately, after performing all the
steps, I'm still having no luck.
Looking at the logs (I wish I'd done this more closely before), I see
that it is complaining "SEVERE: Exception processing JAR at resource
path /usr/local/share/apache-tomcat-6.0.33/lib/cspace.jar in context
/cspace-services", "java.util.zip.ZipException: error in opening zip file".
Sure enough, inspecting that file with unzip -v shows it's corrupt (no
zip directory at the end). I've deleted it, and am trying "ant deploy"
again.
... hmm. It wasn't recreated. The logs no longer complain about
cspace.jar (presumably because it is entirely absent now), but I'm still
getting errors such as this:
SEVERE: Error loading WebappClassLoader
context: /host-manager
delegate: false
repositories:
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@2571157a
org.apache.jasper.servlet.JspServlet
java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
I'll attach my log files, in case they're useful.
I know how difficult it is to debug problems like this; do let me know
if there's something obvious that leaps out at you from the logs.
Otherwise, given my rustiness with tomcat and j2ee in general (it has
been more than 10 years! scary), I'll probably throw away this VM, make
another from scratch, and hope everything goes smoothly on the rerun.
Regards, and thanks again,
Tony
On 04/03/2015 06:13 PM, Aron Roberts wrote:
Hi Tony,
Just tested this: doing a 'repair' installation of CollectionSpace
using the automated installer was successful, and fortunately it doesn't
require going back and re-generating the VM from scratch. There are a
couple more steps involved at the end of this process, which have been
added below.
Please note that the default users for each tenant (an admin user and
a read-only user) are created, if needed, each time the server has
successfully started up, so the 'users' table in the 'cspace' database
will - legitimately - be empty until that occurs at least once.
Aron
--
The full set of steps:
- Doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
- Re-running the bootstrap script (without '-y'), just to make sure
you've got all the latest modules. (I just spotted and fixed an issue in
one test module, a fix that's needed to make the next step below
sudo ./bootstrap-cspace-modules.sh
(When asked "Install your CollectionSpace server now [y/n]?", enter 'n')
(If for any reason a copy of that bootstrap script isn't present, you
can download it again via the steps listed at
- Re-running the CollectionSpace server installation, beginning at a
late step in the process ... the one that checks out source code and
builds and deploys the server:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
- Starting the server:
sudo su cspace
$CATALINA_HOME/bin/startup.sh
(Optional: view startup messages until the server starts up)
tail -f $CATALINA_HOME/logs/catalina.out
- Verifying that the server's Services layer is functional and that
AuthN/AuthZ is working:
curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/intakes
If all this works, there's a high likelihood that login via the browser
will work successfully as well.
On Fri, Apr 3, 2015 at 12:50 PM, Aron Roberts
<aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
Hi Tony,
We've also occasionally encountered similar network timeout
issues, and have had the same experience with failed installations
when those occur. (I'll make a JIRA issue for that, so we can look
into making the installer more robust, when one or more of the
components it's downloading isn't rapidly available.)
One thought: you might first try backtracking a bit, but not as
far as re-creating the VM ...
Perhaps try this? (The following assumes you're in the home
directory of a user with 'sudo' privileges on your VM ...)
First, doing some cleanup of the artifacts (databases, source code
directories) created during the later parts of the installation:
sudo -u postgres dropdb cspace
sudo -u postgres dropdb nuxeo
sudo -u postgres dropdb lifesci_domain
sudo rm -Rf /home/cspace/cspace_source/
Second, re-running the bootstrap script (without '-y'), just to make
sure you've got all the latest modules. (I just spotted and fixed an
issue in one test module, a fix that's needed to make the next step
below succeed.)
sudo ./bootstrap-cspace-modules.sh
(If for any reason a copy of that bootstrap script isn't present,
you can download it again via the steps listed at
And then re-running the installation, beginning at a late step in
the process:
sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
(If all the prerequisites were successfully installed, such as Ant,
Maven, Oracle JDK 7, and PostgreSQL, I'm hoping this will take it
from there ...)
I'm currently in the middle of testing this, so I haven't yet
verified that this will work. But if you're willing to experiment
with it, this approach might be a bit less monumental and
time-consuming than starting from scratch ...
Thanks!
Aron Roberts
UC Berkeley
On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones
<tonyg@ccs.neu.edu <mailto:tonyg@ccs.neu.edu>> wrote:
Hi all,
I hope this is the right place for newbie installation questions.
Yesterday I created a fresh Ubuntu 14.04 instance and ran the
as root.
After a few failed runs -- it seems mostly network timeout
related -- it
looked like it completed successfully. However, upon starting
the server
and visiting the login page, I cannot log in as the admin user.
Inspecting the database tables (psql -h localhost -U cspace,
select *
from users), I see zero user rows.
I have tried "sudo -u postgres dropdb cspace", followed by "sudo
create_db -Drecreate_db=true import". Still no rows in the users
table.
Any suggestions for things to try? Perhaps there is a
command-line tool
I could use to create some users?
Since it's a virtual machine, in extremis I could blow the whole
thing
away and start again, but I'd prefer not to have to take that
step if I
can avoid it :-)
Thanks for any advice anyone might have.
Cheers,
Tony
_______________________________________________
Talk mailing list
Talk@lists.collectionspace.org
<mailto:Talk@lists.collectionspace.org>
Hi Tony,
My sincere apologies for this delayed response. The corrupted
lib/cspace.jar file is definitely of concern. That hints at issues with the
integrity of contents of the Tomcat folder, regardless of the possible
cause or causes.
It's probably a good idea to start over with a new VM. If you'd like to
experiment a bit, here's an almost completely unattended way to create a
VirtualBox VM running Ubuntu 14.04.x LTS, and then run the automated
CollectionSpace server installer within that VM:
- Install both VirtualBox (https://www.virtualbox.org/) and Vagrant (
https://www.vagrantup.com/).
- Create a directory.
- Cd to that directory.
- Download the file named 'Vagrantfile' from
https://github.com/mark-cooper/cspace_vagrantbox into that directory. (E.g.
right-click or Ctrl-click the Vagrantfile link and choose "Save Link As..."
or equivalent; copy the Vagrantfile into that directory, from your
Downloads folder, if needed)
- From within the directory you created, enter: vagrant up
(This will initiate the automated installer and start displaying
progress messages; allow at least 30 minutes for
installation to complete. If any serious errors occur during installation,
feel free to share them here. You can also retry that process; 'exit' from
the VM, then at your host computer's shell prompt, enter 'vagrant halt',
'vagrant destroy', and then 'vagrant up', to start the installation process
over, once again.)
If/when installation appears to succeed:
- Log in to the VM by entering: vagrant ssh
(No username/password should be needed; you can use 'vagrant' and
'vagrant' if you're ever asked for these)
- Change to the 'cspace' user account by entering: sudo su cspace.
- Start the CollectionSpace server by entering:
$CATALINA_HOME/bin/startup.sh
- If you wish, you can monitor the server's console output during startup
via: tail -f $CATALINA_HOME/logs/catalina.out (Enter Control-C to break
out of 'tail', when you're done monitoring.)
- Test CollectionSpace's services layer by entering:
curl -i -u admin@core.collectionspace.org:Administrator
http://localhost:8180/cspace-services/intakes
(If all is well, you should see a '200 OK' response with an XML document in
its body.)
- Connect to CollectionSpace in your browser (on your host computer, not
in the VM) via http://10.11.12.45:8180/collectionspace/ui/core/index.html
(That private IP address is hard-coded in the Vagrantfile used to start up
the VM. If that doesn't work, enter 'ipconfig' to verify the relevant IPv4
addresses assigned to 'eth1' and 'eth0', and, if different from
"10.11.12.45", try each of those, in turn.)
- Try logging in via the Sign In screen.
If login succeeds, you can proceed with the remaining setup instructions
at
http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Afterinstallation
As well, if for some reason installation is continually failing, you
might try:
1) Getting a pre-made VM; see
http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-March/001922.html
2) Doing a manual installation.
Good luck!
Aron
On Fri, Apr 3, 2015 at 9:34 PM, Tony Garnock-Jones <tonyg@ccs.neu.edu>
wrote:
> Hi Aron,
>
> Thanks for that detailed guide! Unfortunately, after performing all the
> steps, I'm still having no luck.
>
> Looking at the logs (I wish I'd done this more closely before), I see
> that it is complaining "SEVERE: Exception processing JAR at resource
> path /usr/local/share/apache-tomcat-6.0.33/lib/cspace.jar in context
> /cspace-services", "java.util.zip.ZipException: error in opening zip file".
>
> Sure enough, inspecting that file with unzip -v shows it's corrupt (no
> zip directory at the end). I've deleted it, and am trying "ant deploy"
> again.
>
> ... hmm. It wasn't recreated. The logs no longer complain about
> cspace.jar (presumably because it is entirely absent now), but I'm still
> getting errors such as this:
>
> SEVERE: Error loading WebappClassLoader
> context: /host-manager
> delegate: false
> repositories:
> ----------> Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader@2571157a
> org.apache.jasper.servlet.JspServlet
> java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
>
> I'll attach my log files, in case they're useful.
>
> I know how difficult it is to debug problems like this; do let me know
> if there's something obvious that leaps out at you from the logs.
> Otherwise, given my rustiness with tomcat and j2ee in general (it has
> been more than 10 years! scary), I'll probably throw away this VM, make
> another from scratch, and hope everything goes smoothly on the rerun.
>
> Regards, and thanks again,
> Tony
>
>
> On 04/03/2015 06:13 PM, Aron Roberts wrote:
> > Hi Tony,
> >
> > Just tested this: doing a 'repair' installation of CollectionSpace
> > using the automated installer was successful, and fortunately it doesn't
> > require going back and re-generating the VM from scratch. There are a
> > couple more steps involved at the end of this process, which have been
> > added below.
> >
> > Please note that the default users for each tenant (an admin user and
> > a read-only user) are created, if needed, each time the server has
> > successfully started up, so the 'users' table in the 'cspace' database
> > will - legitimately - be empty until that occurs at least once.
> >
> > Aron
> >
> > --
> >
> > The full set of steps:
> >
> > 1. Doing some cleanup of the artifacts (databases, source code
> > directories) created during the later parts of the installation:
> >
> > sudo -u postgres dropdb cspace
> > sudo -u postgres dropdb nuxeo
> > sudo -u postgres dropdb lifesci_domain
> >
> > sudo rm -Rf /home/cspace/cspace_source/
> >
> > 2. Re-running the bootstrap script (without '-y'), just to make sure
> > you've got all the latest modules. (I just spotted and fixed an issue in
> > one test module, a fix that's needed to make the next step below
> succeed.)
> >
> > sudo ./bootstrap-cspace-modules.sh
> >
> > (When asked "Install your CollectionSpace server now [y/n]?", enter 'n')
> >
> > (If for any reason a copy of that bootstrap script isn't present, you
> > can download it again via the steps listed at
> >
> http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
> )
> >
> > 3. Re-running the CollectionSpace server installation, beginning at a
> > late step in the process ... the one that checks out source code and
> > builds and deploys the server:
> >
> > sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
> >
> > 4. Starting the server:
> >
> > sudo su cspace
> > $CATALINA_HOME/bin/startup.sh
> >
> > (Optional: view startup messages until the server starts up)
> > tail -f $CATALINA_HOME/logs/catalina.out
> >
> > 5. Verifying that the server's Services layer is functional and that
> > AuthN/AuthZ is working:
> >
> > curl -i -u admin@core.collectionspace.org:Administrator
> > http://localhost:8180/cspace-services/intakes
> >
> > If all this works, there's a high likelihood that login via the browser
> > will work successfully as well.
> >
> >
> > On Fri, Apr 3, 2015 at 12:50 PM, Aron Roberts
> > <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote:
> >
> > Hi Tony,
> >
> > We've also occasionally encountered similar network timeout
> > issues, and have had the same experience with failed installations
> > when those occur. (I'll make a JIRA issue for that, so we can look
> > into making the installer more robust, when one or more of the
> > components it's downloading isn't rapidly available.)
> >
> > One thought: you might first try backtracking a bit, but not as
> > far as re-creating the VM ...
> >
> > Perhaps try this? (The following assumes you're in the home
> > directory of a user with 'sudo' privileges on your VM ...)
> >
> > First, doing some cleanup of the artifacts (databases, source code
> > directories) created during the later parts of the installation:
> >
> > sudo -u postgres dropdb cspace
> > sudo -u postgres dropdb nuxeo
> > sudo -u postgres dropdb lifesci_domain
> >
> > sudo rm -Rf /home/cspace/cspace_source/
> >
> > Second, re-running the bootstrap script (without '-y'), just to make
> > sure you've got all the latest modules. (I just spotted and fixed an
> > issue in one test module, a fix that's needed to make the next step
> > below succeed.)
> >
> > sudo ./bootstrap-cspace-modules.sh
> >
> > (If for any reason a copy of that bootstrap script isn't present,
> > you can download it again via the steps listed at
> >
> http://wiki.collectionspace.org/display/UNRELEASED/Automated+installer+for+CollectionSpace+4.1#AutomatedinstallerforCollectionSpace4.1-Runningtheinstaller
> )
> >
> > And then re-running the installation, beginning at a late step in
> > the process:
> >
> > sudo puppet apply /etc/puppet/modules/cspace_source/tests/init.pp
> >
> > (If all the prerequisites were successfully installed, such as Ant,
> > Maven, Oracle JDK 7, and PostgreSQL, I'm hoping this will take it
> > from there ...)
> >
> > I'm currently in the middle of testing this, so I haven't yet
> > verified that this will work. But if you're willing to experiment
> > with it, this approach might be a bit less monumental and
> > time-consuming than starting from scratch ...
> >
> > Thanks!
> > Aron Roberts
> > UC Berkeley
> >
> > On Fri, Apr 3, 2015 at 4:35 AM, Tony Garnock-Jones
> > <tonyg@ccs.neu.edu <mailto:tonyg@ccs.neu.edu>> wrote:
> >
> > Hi all,
> >
> > I hope this is the right place for newbie installation questions.
> >
> > Yesterday I created a fresh Ubuntu 14.04 instance and ran the
> script
> > from
> >
> http://wiki.collectionspace.org/display/DOC/Automated+installer+for+CollectionSpace+4.1
> > as root.
> >
> > After a few failed runs -- it seems mostly network timeout
> > related -- it
> > looked like it completed successfully. However, upon starting
> > the server
> > and visiting the login page, I cannot log in as the admin user.
> >
> > Inspecting the database tables (psql -h localhost -U cspace,
> > select *
> > from users), I see zero user rows.
> >
> > I have tried "sudo -u postgres dropdb cspace", followed by "sudo
> ant
> > create_db -Drecreate_db=true import". Still no rows in the users
> > table.
> >
> > Any suggestions for things to try? Perhaps there is a
> > command-line tool
> > I could use to create some users?
> >
> > Since it's a virtual machine, in extremis I could blow the whole
> > thing
> > away and start again, but I'd prefer not to have to take that
> > step if I
> > can avoid it :-)
> >
> > Thanks for any advice anyone might have.
> >
> > Cheers,
> > Tony
> >
> > _______________________________________________
> > Talk mailing list
> > Talk@lists.collectionspace.org
> > <mailto:Talk@lists.collectionspace.org>
> >
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
> >
> >
> >
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
>
TG
Tony Garnock-Jones
Mon, Apr 6, 2015 9:25 PM
Hi Aron,
On 04/06/2015 04:27 PM, Aron Roberts wrote:
My sincere apologies for this delayed response.
It's probably a good idea to start over with a new VM. If you'd like
to experiment a bit, here's an almost completely unattended way to
create a VirtualBox VM running Ubuntu 14.04.x LTS, and then run the
automated CollectionSpace server installer within that VM:
Yes, OK. I agree. Thanks. I'll give it a go. It'll give me an
opportunity to try out Vagrant :-)
Cheers,
Tony
Hi Aron,
On 04/06/2015 04:27 PM, Aron Roberts wrote:
> My sincere apologies for this delayed response.
No problem!
> It's probably a good idea to start over with a new VM. If you'd like
> to experiment a bit, here's an almost completely unattended way to
> create a VirtualBox VM running Ubuntu 14.04.x LTS, and then run the
> automated CollectionSpace server installer within that VM:
Yes, OK. I agree. Thanks. I'll give it a go. It'll give me an
opportunity to try out Vagrant :-)
Cheers,
Tony
