Ubuntu 20.04, Nginx, Redmine, Ruby, and Passenger-Phusion confusion

Redmine, Ruby, Passenger-Phusion, and Nginx makes for an extremely confusing situation with dependencies, installation “instructions”, and “mismatching” package versions.

Redmine wants Ruby x, your Linux distribution has Ruby y, Passenger-Phusion only works with Ruby z, and you quite often end up in a loop somewhere. This article will not do anything to help that confusion I’m afraid.

On Passenger-Phusion’s website, there’s an interesting explanation as to why you need to let Passenger-Phusion build Nginx for you, unless you can actually use everything pre-packaged, which you cannot if you want to use Ubuntu 20.04.LTS and Redmine 4.1.

Before you begin, you should know that installing Passenger in its Nginx integration mode involves extending Nginx with code from Passenger. However, Nginx does not support loadable modules. This means that in order to install Passenger’s Nginx integration mode, it is necessary to recompile Nginx from source. And that is exactly what we will do in this installation guide.

Now, if you head on over to the Nginx blog, you can read:

NGINX Open Source 1.11.5 and NGINX Plus Release R11 introduced binary compatibility for dynamic modules. This article explains how to compile third‑party modules for use with NGINX Open Source and NGINX Plus in a development environment.

That statement was made for Nginx 1.11. They are, at the time of this writing, at 1.19.

So basically, if you want to run Redmine 4.1 on Ubuntu 20.04.LTS, which ships with Ruby 2.7, and a Passenger-Phusion module that requires Ruby 2.7, you’re on your own since Redmine 4.1 does not support Ruby 2.7. If you use RVM to installed Ruby 2.6.x, you need to manually handle Passenger-Phusion, which eventually requires re-compiling Nginx, regardless of it supporting “dynamic modules”.

There is one small glimmer of hope:
Installing Passenger as a normal or dynamic Nginx module

Using Ubuntu 18.04.LTS, the included Passenger, Nginx, and Ruby all work with Redmine 4.1.x, so that may be a smoother path to take before this is all “fixed”, if it gets fixed.

pdftk and php-pdftk on Ubuntu 18.04 without using snap

During a product launch I recently came across an “interesting” issue involving pdftk (and php-pdftk). Some of the developers had made assumptions (ever heard that one before?) about the operating environment and how things were/are configured.

These assumptions were based on a development environment that in no way reflected the final production environment (ever heard that one before?). In this particular case, they were expecting the great PDF toolkit (pdftk) to be available and working just like it did in their development environment.

To summarize the issue: pdftk has been removed from Ubuntu 18.04 due to dependency issues. The “recommended” solution is to install pdftk using snap. This, in itself, is not a bad recommendation. But in a web server environment, it may put you in a place you don’t want to be in.

So after a few hours of toying with ideas and testing various things, I figured there must be some Debian-like package that would actually work when installed on Ubuntu 18.04 and that is not a snap package.

There is.

Later versions (or packages) of pdftk now exist as pdftk-java, and they do work with php-pdftk as well.

In my case, I located pdftk-java_3.1.1-1_all.deb and installed it. Or tried to rather. It has a number of dependencies that you will see for yourself. You’ll need to decide if their “weight” makes it worthwhile for you to go down this path. But it was one, reasonably good, way for us to solve the problem.

The developers you ask? They have been sent to /dev/codersgulag/cobol and will spend a number of solar iterations there.

(The file I ended up using was http://ftp.debian.org/debian/pool/main/p/pdftk-java/pdftk-java_3.1.1-1_all.deb, and it does work on Ubuntu 18.04.LTS)