manifoldscholar / manifold-omnibus Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 2.0 444 KB

License: GNU General Public License v3.0

Ruby 63.87% Shell 6.55% HTML 29.45% JavaScript 0.13%

manifold-omnibus's People

Contributors

Watchers

Forkers

zdavis 0xgoerlimainnet

manifold-omnibus's Issues

Expose a fallback web root for files such as robots.txt

Our nginx config has /opt/manifold/embedded/src/client/dist/manifold/www set as the root. There are valid cases for adding files to the webroot, such as a custom robots.txt file, so we may want to expand our nginx config to fallback to a directory that the admin controls.

resources batch load of multiple GIF images can lock up a manifold server

In submitting a resource batch load process, which included many animated GIFs, we observed our Manifold instance peg two CPUs and remain at a load average of 15 for several minutes. It eventually cooled off, but it was nerve-wracking to watch. There should be a way to throttle the image processing queue to keep the CPU load workable.

For reproduction purposes, the google sheet of the metadata we're using is here:
https://docs.google.com/spreadsheets/d/1ATwb0Jf4dbNqFZd7faRnLEqq898I662G9AnKNRvM6Ps/edit?usp=sharing

and the drive folder is here:
https://drive.google.com/drive/folders/1Uj81gzMflKiyeTObg5npZ7aoIby3d6hz?usp=sharing

Recently upgraded Manifold instance cannot start Elastic Search service

We recently upgraded our instance of Manifold from 4.1.0~beta.1-1.el7 to 5.0.0-1.el7 (and ran into some difficulty, which we logged on issue #42). A user noticed that searching wasn't working. In troubleshooting, we determined that the Elastic Search service was not booting up correctly. Looking at the log files:

2020-07-16_22:11:08.31908 [2020-07-16T22:11:08,314][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [] uncaught exception in thread [main]
2020-07-16_22:11:08.31923 org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: plugins directory [/opt/manifold/embedded/elasticsearch/plugins] not found
2020-07-16_22:11:08.31928 	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:136) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31932 	at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:123) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31938 	at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:70) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31944 	at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:134) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31952 	at org.elasticsearch.cli.Command.main(Command.java:90) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31958 	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31963 	at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31968 Caused by: java.lang.IllegalStateException: plugins directory [/opt/manifold/embedded/elasticsearch/plugins] not found
2020-07-16_22:11:08.31974 	at org.elasticsearch.bootstrap.Spawner.spawnNativePluginControllers(Spawner.java:69) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31979 	at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:168) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31983 	at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:342) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31987 	at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:132) ~[elasticsearch-5.6.15.jar:5.6.15]
2020-07-16_22:11:08.31992 	... 6 more

I could see that ES was failing to load because it could not find this plugins folder:
/opt/manifold/embedded/elasticsearch/plugins

I confirmed this folder did not exist, created it manually, and restarted ES with a sudo manifold-ctl restart elasticsearch command. I confirmed the service was indeed up:

sudo netstat -plunt | grep 3036
tcp6       0      0 127.0.0.1:3036          :::*                    LISTEN      26096/java
tcp6       0      0 ::1:3036                :::*                    LISTEN      26096/java

I then ran a reindex command successfully:

sudo manifold-api manifold:search:reindex
Reindexing Subject...
Reindexing Event...
Reindexing Maker...
Reindexing Annotation...
Reindexing Project...
Reindexing User...
Reindexing ResourceCollection...
Reindexing Resource...
Reindexing Tag...
Reindexing TextSection...
Reindexing Text...
Reindex complete

Manifold client access API over localhost, which fails when SSL is enabled

Ideally, the client would access the API over the FQDN with a hosts entry mapping the FQDN to localhost

Vulnerable log4j JAR needs updating

My university is rolling out the requirement to install the Qualys vulnerability checking agent on all systems connected to the network, and the first report on our Manifold host complained about the existence of /opt/manifold/embedded/elasticsearch/lib/log4j-core-2.11.1.jar, referencing this NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2021-44228 .

Increase open file limit in api and cable startup scripts

Ingestions can run into open file limits.

See https://github.com/castiron/pancho-puppet/commit/454cd4e2f5aa9208ff946432bc02a1c15149db21

/var/opt/manifold/etc/node-env.js has wrong API env var

process.env.API_URL = "http://localhost";

Should likely be:

process.env.CLIENT_SERVER_API_URL = "http://localhost";

Expose a RAILS_DB_HOST setting in /etc/manifold/manifold.rb

rake install:centos7 fails to upgrade package

If we've already installed the package on the Centos VM, the install command will fail:

zdavis@gelatinous-cube:~/src/omnibus-manifold$ rake install:centos7
error: Failed dependencies:
	manifold conflicts with manifold-2.0.0~rc.2+git.8.5dc68261-1.el7.x86_64
	manifold is obsoleted by manifold-2.0.0~rc.2+git.8.5dc68261-1.el7.x86_64
	manifold conflicts with (installed) manifold-2.0.0~rc.2-1.el7.x86_64
	manifold is obsoleted by (installed) manifold-2.0.0~rc.2-1.el7.x86_64
Connection to 127.0.0.1 closed.

This is happening because that Platform class is installing it with the rpm -i flag instead of the upgrade -U flag. Perhaps we need to add a rake task specifically for upgrading?

Additionally, I noticed that the install command does not maintain the root user's environment. The command is sudo rpm -ivh #{package_path} — but when run as the vagrant user, the path won't include manifold-ctl, which could lead to unexpected upgrade results, since the package seems to be detecting it:

[vagrant@centos7-install pkg]$ sudo rpm -Uvh manifold-2.0.0~rc.2+git.8.5dc68261-1.el7.x86_64.rpm
Preparing...                          ################################# [100%]
You're about to install manifold!
which: no manifold-ctl in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
Updating / installing...
   1:manifold-2.0.0~rc.2+git.8.5dc6826^C^C################################# [ 50%]

Update Elasticsearch for v6

3.0 package doesn't set browser environment correctly

With SSL enabled, running manifold-ctl fails to add process.env.SSL_ENABLED = true; to the end of /var/opt/manifold/etc/browser-env.js

Ensure that Mammoth path is correct for v6

API log may not be rotated properly

One user ended up with a 19gb log file, suggesting this log is not being rotated properly. Need to investigate

Show maintenance page when Manifold is restarting or unavailable.

See ManifoldScholar/manifold#1692

Configure nginx headers for performance send_files in manifold API

LOW PRIORITY: Adjust feedback color on install

Every time I install Manifold my first thought is that it didn't work because the title Manifold Scholarship is red. Consider changing it to green?

manifold-ctl error on Centos7

See end of output:

[root@centos7-install ~]# manifold-ctl
I don't know that command.
/opt/manifold/embedded/bin/omnibus-ctl: command (subcommand)
cleanse
  Delete *all* manifold data, and start from scratch.
uninstall
  Kill all processes and uninstall the process supervisor (data will be preserved).
upgrade
  Run migrations after a package upgrade
General Commands:
  cleanse
    Delete *all* manifold data, and start from scratch.
  help
    Print this help message.
  reconfigure
    Reconfigure the application.
  show-config
    Show the configuration that would be generated by reconfigure.
  uninstall
    Kill all processes and uninstall the process supervisor (data will be preserved).
Service Management Commands:
  graceful-kill
    Attempt a graceful stop, then SIGKILL the entire process group.
  hup
    Send the services a HUP.
  int
    Send the services an INT.
  kill
    Send the services a KILL.
  once
    Start the services if they are down. Do not restart them if they stop.
  restart
    Stop the services if they are running, then start them again.
  service-list
    List all the services (enabled services appear with a *.)
  start
    Start services if they are down, and restart them if they stop.
  status
    Show the status of all the services.
  stop
    Stop the services, and do not restart them.
  tail
    Watch the service logs of all enabled services.
  term
    Send the services a TERM.
/opt/manifold/embedded/lib/ruby/gems/2.3.0/gems/omnibus-ctl-0.3.6/lib/omnibus-ctl.rb:570:in `run': undefined method `gsub' for nil:NilClass (NoMethodError)
	from /opt/manifold/embedded/lib/ruby/gems/2.3.0/gems/omnibus-ctl-0.3.6/bin/omnibus-ctl:31:in `<top (required)>'
	from /opt/manifold/embedded/bin/omnibus-ctl:23:in `load'
	from /opt/manifold/embedded/bin/omnibus-ctl:23:in `<main>'

Upgrade of Manifold using the Yum repo is not currently possible on CentOS

There is a known issue is with the CentOS yum repo, which currently looks like this:

cat /etc/yum.repos.d/manifold-release.repo
[manifold-release]
name=Manifold (release) - $basearch
baseurl=https://storage.googleapis.com/manifold-yum/el7/x86_64/release
enabled=1
gpgcheck=0

The known issue is, attempts to upgrade using Yum are not successful:

sudo yum update manifold

After running the above, the installed version remains the same:

sudo yum list installed | egrep manifold 
manifold.x86_64                       4.1.0~beta.1-1.el7             @manifold-release

The workaround we've found is to use the manual installation method detailed in the upgrading documentation:

Download the latest stable version, as documented in the installation instructions to a temporary location, such as ~/tmp
Install using: sudo rpm -ivh --nodeps --force manifold-your-version-here.rpm
Verify using: sudo rpm -qa | grep manifold

Add epub mime type to nginx; adjust default nginx content-type to application/octet-stream

The default nginx config in the omnibus package does not include a mime type for EPUB, and at least on Ubuntu16 + 18, EPUB mime types won't be correctly recognized.

Interim fix is:

Edit /opt/manifold/embedded/conf/mime/types and add this line to the list of mime types:

application/epub+zip epub;

Then restart nginx with manifold-ctl restart nginx

This change will be overwritten when you next upgrade Manifold, but that should be OK because this will be fixed before we generate packages again.

We should probably also default the content-type in the response to application/octet-stream in cases where nginx can't determine a file's mime-type.

Disable old versions of TLS

These can be managed via nginx['ssl_protocols'], but we should have better defaults.

Add DB name to /opt/manifold/etc/manifold-psql-rc

The helpful psql wrapper at /usr/bin/manifold-psql loads connection details from this file. We should make sure it includes the DB name as well. Without it, the db name defaults to the PG username and the manifold-psql command throws an error. The correct DB name is manifold_production

Accept license flag may not be working properly

Charles Birmingham reports:

I tried the "manifold-ctl reconfigure --accept-license" command, but it didn't work since there are extra license agreements that don't appear to be taken into account.

Users should be able to manage API environment via manifold.rb

There is a mechanism in place for this, but it may not be working quite as expected.

We are adding variables to an environment directory at https://github.com/ManifoldScholar/omnibus-manifold/blob/master/cookbooks/manifold/recipes/manifold-api.rb#L122, but I'm not sure these are being included when the API app is run.

It might make more sense to add these to the API's .env file, rather than to rely on this env dir.

I'm going to look at this over the weekend and publish new packages for v2.0.3.

manifoldscholar / manifold-omnibus Goto Github PK

manifold-omnibus's People

Contributors

Watchers

Forkers

manifold-omnibus's Issues

Recommend Projects

Recommend Topics

Recommend Org