TreeBASE hosting at Naturalis

[Rutger Vos]

Hi all,

here a quick status update on TreeBASE hosting at Naturalis, with some pressing questions from our ICT dept at the bottom:

The "project bureau" of the Naturalis ICT department has considered hosting TreeBASE and would be keen to do this, though they are aware that they are not the only candidates for this so they are now developing a plan for what hosting would mean and whether they can offer something that we can all commit to with confidence.

The basic idea is that they would replicate as much as possible the practices and configuration that were developed at NESCent, but folding it a bit more into the ICT departments workflow and way of doing this. This might include things such as:

- move code to github

- decide whether to adopt Jenkins (or something else)

- expand automated provisioning of dev/stage/prod servers using puppet

They want to make very, very specific agreements about who's responsible for what. As far as they've been able to tell, this includes the following topics, with they responsibility between parentheses:

- the content, i.e. editing and reviewing submissions (presumably, they have nothing to do with that)

- the code, i.e. bug fixes and feature additions (again, they don't plan to do anything with that)

- testing, i.e. do bug fixes and enhancements work as intended on the staging server (presumably this is shared, e.g. they deploy, others test & verify)

- system/db administration, i.e. checking performance and tuning it (to the extent that this doesn't involve code modifications they would do this)

And they would like further clarification on a number of issues - so the following are important and require your feedback:

- do they need to worry about copyright issues w.r.t. the abstracts in the database?

- what exactly does the annual growth rate (60%/pa) refer to?

- what's in place in terms of automation (e.g. continuous integration) and how would they best be able to copy this?

Thanks,

Rutger

[Hilmar Lapp]

On 10/23/14, 5:19 AM, Rutger Vos wrote:
> *they would like further clarification on a number of issues - so the
> following are important and require your feedback:*
> *- do they need to worry about copyright issues w.r.t. the abstracts in
> the database?*

No. They are covered under fair use.

> *- what exactly does the annual growth rate (60%/pa) refer to?*

Storage (flat file and database). (Which means it's not clear, and we don't
have good data, on how this growth translates to increased CPU and memory
needs.)

> *- what's in place in terms of automation (e.g. continuous integration)
> and how would they best be able to copy this?*

We use Jenkins for deployment. Staging and testing are auto-redeployed upon
each commit. Production is triggered manually.

-hilmar
--
Hilmar Lapp -:- informatics.nescent.org/wiki -:- lappland.io

[Hilmar Lapp]

On 10/23/14, 5:19 AM, Rutger Vos wrote:

- the content, i.e. editing and reviewing submissions (presumably, they have nothing to do with that)

Congruent with NESCent hosting.

- the code, i.e. bug fixes and feature additions (again, they don't plan to do anything with that)

Mostly ditto. However, TreeBASE still stores passwords in the clear, which is a major security flaw and vulnerability. There may be others waiting to be discovered. The code, to the extent I know, has never been security-audited. There is currently apparently zero funding for code maintenance, and so time will only reveal more security issues, not less, including issues caused by reliance on end-of-support versions of Java, Tomcat, etc.

- testing, i.e. do bug fixes and enhancements work as intended on the staging server (presumably this is shared, e.g. they deploy, others test & verify)

Congruent with NESCent hosting, except that we redeploy staging and testing automatically upon commits.

- system/db administration, i.e. checking performance and tuning it (to the extent that this doesn't involve code modifications they would do this)

Again, this would be congruent with NESCent hosting.

[Rutger Vos]

Mostly ditto. However, TreeBASE still stores passwords in the clear, which is a major security flaw and vulnerability. There may be others waiting to be discovered. The code, to the extent I know, has never been security-audited. There is currently apparently zero funding for code maintenance, and so time will only reveal more security issues, not less, including issues caused by reliance on end-of-support versions of Java, Tomcat, etc.

Mmmm... yes, we never did get around to hashing the passwords, did we? I think I will have to discuss this with them because they are quite big on practicing due diligence on stuff like this.

 

- testing, i.e. do bug fixes and enhancements work as intended on the staging server (presumably this is shared, e.g. they deploy, others test & verify)

Congruent with NESCent hosting, except that we redeploy staging and testing automatically upon commits.

Is this Jenkins? I expect the ICT dept will just want to copy this setup.

 

- system/db administration, i.e. checking performance and tuning it (to the extent that this doesn't involve code modifications they would do this)

Again, this would be congruent with NESCent hosting.

Cool, thanks!

Rutger