Recreating Playground

From Digital Scholarship Group
Revision as of 11:32, 22 December 2020 by Sbauman (talk | contribs)
Jump to navigation Jump to search

Installing CentOS and WWO onto playground

This page is notes for re-creating the WWO environment from RH 6.10 (wwp.neu.edu) to CentOS 8.2 (playground). It will serve as a guide to start, and then hopefully a useful description for future similar upgrades.

CentOS

Installing CentOS was essentially trivial. We used the CentOS-8.2.2004-x86_64-boot.iso.

It appears that yum has been superceded by dnf.

Things we should or have installed

  • Emacs — installed 2020-11-30 with sudo yum install emacs-nox.x86_64
  • Emacs/nxml — was automagically installed by above (and has nice colors! :-)
  • make — installed 2020-11-30 with sudo yum install make.x86_64
  • Subversion — installed 2020-11-30 with sudo yum install subversion.x86_64
  • libxml2/xmllint — libxml2-2.9.7-7.el8.x86_64 is already installed
  • libxslt/xsltproc — installed 2020-11-30 with sudo yum install libxslt.x86_64
  • ant — intsalled 2020-11-30 with sudo yum install ant.noarch
  • screen — nope, Red Hat recommends tmux instead — installed 2020-11-30 with sudo yum install tmux.x86_64
  • Tomcat — no yum package found
  • git — installed 2020-11-30 with sudo yum install git.x86_64 (installed 46 dependencies, mostly Perl packages)
  • eXist — no yum package found, so see detailed description below
  • MariaDB (maybe? maybe not)
  • CouchDB (maybe? maybe not)
  • lessc (pkg = node-less) — no yum package found
    • Ash checked, they recommend installing via npm
    • npm — installed 2020-12-02 with sudo dnf install npm.x86_64
    • installed lessc with sudo npm install less -g
  • Perl — v 5.26.3 already installed
  • PHP — installed 2020-11-30 with sudo yum install php.x86_64
  • Python — I do not know if we want version 3.6 or 3.8 (or 2.7, which I doubt); see the RHEL8 doc
  • Awstats —not found
  • locate — already installed, but need to generate and cronify udpatedb; done 2020-11-30, I think. Ran sudo /usr/bin/updatedb and now locate seems to work. Symlinked /usr/bin/updatedb to /etc/cron.daily/updatedb. Hope that works. I think we check by loooking at timestamp of /var/lib/mlocate/mlocate.db.
  • gcc — installed 2020-12-02 with sudo dnf install gcc.x86_64

Apache setup, modules, etc.

We (Syd & Ash) worked on configuring the web server for awhile, but were still having problems. Ernesto (user=nestochan) gave us a hand, performed some firewall magic, and now it is working. Need to find out what he did.

  • server side includes
  • whatever we need for security and textbaseIP stuff
    • mod_jk
    • /etc/httpd/passwd/
  • redirection stuff (mostly part of configuration)
  • probably want to check several files in wwp-test:/etc/httpd/ into version control; consider:
    • conf.d/webalizer.conf
    • conf.d/limitipconn.conf
    • conf.d/reqtimeout.conf
    • conf.d/wwp-blog.conf
    • conf.d/wwp.conf-ssl.conf
    • conf.d/mod_security.conf
    • conf.d/dsc-wiki.conf
    • conf.d/dsg-wiki.conf
    • modsecurity.d

files from /etc/httd/ whose differences between wwp and wwp-test need to be investigated

  • Files wwp-test/httpd/conf/httpd.conf and wwp/httpd/conf/httpd.conf differ
  • Files wwp-test/httpd/conf.d/awstats.conf and wwp/httpd/conf.d/awstats.conf differ
  • Only in wwp-test/httpd/conf.d: dsc-wiki.conf
  • Only in wwp-test/httpd/conf.d: dsg-wiki.conf
  • Files wwp-test/httpd/conf.d/limitipconn.conf and wwp/httpd/conf.d/limitipconn.conf differ
  • Files wwp-test/httpd/conf.d/mod_security.conf and wwp/httpd/conf.d/mod_security.conf differ
  • Files wwp-test/httpd/conf.d/redirects.conf and wwp/httpd/conf.d/redirects.conf differ
  • Files wwp-test/httpd/conf.d/ssl.conf and wwp/httpd/conf.d/ssl.conf differ
  • Only in wwp-test/httpd/conf.d: useless
  • Files wwp-test/httpd/conf.d/wwp-blog.conf and wwp/httpd/conf.d/wwp-blog.conf differ
  • Files wwp-test/httpd/conf.d/wwp.conf and wwp/httpd/conf.d/wwp.conf differ
  • Files wwp-test/httpd/conf.d/wwp.conf-ssl.conf and wwp/httpd/conf.d/wwp.conf-ssl.conf differ
  • Files wwp-test/httpd/conf.d/wwprd.conf and wwp/httpd/conf.d/wwprd.conf differ
  • Files wwp-test/httpd/conf.d/wwprewrite.conf and wwp/httpd/conf.d/wwprewrite.conf differ

other things to be moved over

  • WWO
  • WWP website
    • including configuration files
    • include git repos per /var/www/html/WWP/lab/README-WWP
  • eXist applications (see WWP_eXist-DB_applications)
  • either Awstats or something better
    • remember, /usr/local/bin/rgxg is used by Awstats
  • WordPress
  • /usr/local/bin/wwpwwwup.bash

things to be moved only to wwp-test

  • MediaWiki
  • CouchDB and the data produced for Cultures of Reception

things we need help with

  • MediaWiki (Karl)
  • WordPress (Karl)
  • https: access part of Apache config (Ernesto)
  • documenting what was done to firewall (Ernesto)
  • mod_jk?

Version control plan

Our plan is to keep all the Apache2 configuration stuff (/etc/httpd/) under Subversion on playground, wwp-test, local machines, etc.; BUT not on production (wwp) itself. To update that machine you will have to copy files over by hand. This is in part to help reduce chance of messing things up with an svn up and in part as an acknowledgement that a) karl & Ernesto work in this dir, too, and b) some of the files actually have to be different (due to name of host being different, i.e. wwp vs wwp-test vs 129.10.107.233).

eXist-DB

`wget` the JAR file from [1]. WWP is currently using eXist v4.7.1, but will soon be upgrading to 5.x. 

useradd --home-dir /opt/local/eXistDB --create-home --system existdb
chmod 0775 /usr/local/eXistDB
sudo su - existdb

Add environmental variables to .bash_profile: 

export EXIST_HOME=/opt/local/eXistDB/eXist-current
export RUN_AS_USER=existdb

Then, in the terminal: 

source ~/.bash_profile
java -jar /tmp/exist-4.5.0-setup.jar -console

As part of the install process, you'll be asked for a directory path for the newly-installed database. Use /opt/local/eXistDB/eXist-VERSION , where VERSION is the version number. Set the administrator password rather than leaving the field blank.

Create a symlink: `ln -s eXist-VERSION eXist-current`.

Navigate into eXist-current, aka $EXIST_HOME.

Create a backup of $EXIST_HOME/tools/jetty/etc/jetty-http.xml.orig, for example: 

cp tools/jetty/etc/jetty-http.xml tools/jetty/etc/jetty-http.xml.orig

Edit the Jetty file and set the HTTP port to 8088 from 8080.

Create a backup of $EXIST_HOME/webapp/WEB-INF/web.xml, then edit it. Set `//init-param[param-name = ('xquery-submission', 'xupdate-submission')]` to "authenticated".

Create a backup of $EXIST_HOME/conf.xml Set `//serializer/@indent` to "no". Set `//indexer/@preserve-whitespace-mixed-content` to "yes". Add Saxon settings to `//transformer[@class eq 'net.sf.saxon.TransformerFactoryImpl']`: 

<attribute name="http://saxon.sf.net/feature/recoveryPolicyName"
           value="recoverWithWarnings"
           type="string"/>
<attribute name="http://saxon.sf.net/feature/strip-whitespace"
           value="none"
           type="string"/>

Install eXist as a service

eXist comes with YAJSW, which acts as a wrapper daemon to run eXist automatically on server boot. YAJSW configuration files and scripts can be found at $EXIST_HOME/tools/yajsw.

Create a backup of $EXIST_HOME/tools/yajsw/conf/wrapper.conf. Change "wrapper.app.account" to `existdb\\existdb`. Previous installations have also changed "wrapper.java.command", "wrapper.console.title", "wrapper.ntservice.name", and "wrapper.daemon.pid.dir", but they aren't essential.

As root: 

EXIST_HOME=/opt/local/eXistDB/eXist-current RUN_AS_USER=existdb /opt/local/eXistDB/eXist-current/tools/yajsw/bin/installDaemon.sh

You may have the option to run the eXist service through "non-privileged systemd" or "privileged systemV-init". Playground currently (2020-12-04) uses systemd. Not sure what previous installations have used.

November 2019 notes

“playground” is the name Ashley & Syd give to the box they are using for experimentations. (Currently for web stat packages.) This page describes a procedure for installing a CentOS (i.e., RedHat clone) OS on it quickly.

  • Remember to back up iptables and restore it
  • We re-set the clock with instructions from a website we found.
Retrieved from "https://dsg.northeastern.edu/wiki/index.php?title=Recreating_Playground&oldid=3736"