deutrino's picture

Hi there,

I'm looking to deploy an app that requires nginx and Postgres, but not PHP. I did some searching and it looks like my least-worst options are

  • Start from the Postgres TKL app, install nginx manually, and go from there
  • Make a full Postgres + nginx + rest of my software build (TKLdev)

Any pointers here? It looks like the only nginx TKL app is a LEPP stack, but I figure I could crib a lot of the configs etc from that if I go the TKLdev route.

It would really be nice to have a build for which Let's Encrypt would Just Work out of the box, and I feel that might be painful to figure out if I start from the Postgres TKL app.

Thanks for any advice.


Jeremy Davis's picture

Personally, I'd be inclined to start with the Postgres appliance, but as you note, none of them will exactly suit your needs and whichever way you go you'll need to do some tweaking...

Please note too, that the Postgres appliance does include a minimalist install of PHP (required for Adminer) and includes LigHTTPd (aka Lighty) as the web server (for Adminer, plus also to serve the landing page).

I have been considering shifting all of our appliances that include Lighty (except for the Lighty appliance itself obviously) to use Nginx instead, which would have made it a very logical starting point for you. Lighty is a great lightweight webserver, but Nginx is even lighter and much more popular. FWIW we started providing our appliances with Lighty back in the days before Nginx was really a thing (well it existed but wasn't as full featured as it is now and wasn't very well known). As Lighty continues to work fine, it hasn't been a big priority to change...

If you go the TKLDev route and build it yourself from the ground up, then you could easily cut and paste code from other appliances as works for you! :)

Re the Let's Encrypt stuff, the way that we've implemented that is web-server agnostic. It includes a mini-server of it's own to serve the Let's Encrypt challenges on update. So even if you have nothing running on port 80, it should "just work"! :)

The only issue that I foresee would be if you had something serving content on port 80 by default, that we haven't considered/accounted for (IIRC it should handle Apache, Nginx, Lighty, Tomcat or nothing OOTB). If you hit any issues, please let me know and I can point you towards the code that would need to be adjusted.

deutrino's picture

Hi, and thanks for the detailed reply! I am indeed trying to get a deployment up and running starting from the Postgres appliance and documenting the process.

The quick question I have now is, is it safe to shut Lighty off for both port 80 and 443, such that nginx can take those over? I'm guessing yes, but just wanted to make sure. I saved the ports for the various admin services and can connect to those directly in the future.


Jeremy Davis's picture

Short answer: yes you can!

Longer answer, seeing as you're going to install Nginx anyway, IMO you'd be better off removing Lighty altogether and just use Nginx to host Adminer (that's all it'll be hosting anyway if you disable it from serving on ports 80 & 443).

To remove Lighty:

apt purge lighttpd

Please note I didn't test that. I'm assuming the Lighty package's name is 'lighttpd'.

If you want to keep Adminer working, you'll need to tweak things a little so they work with Nginx. I suggest that you have a look at the Nginx appliance build code on how to do that. IIRC you'll need to bring in the PHP-FastCGI stuff (so Adminer runs under a PHP-FastCGI process) and then configure an Nginx reverse proxy for it. So long as you don't adjust the Adminer specfic config that is included with the PostgreSQL app, then that side of things should continue to work fine.

deutrino's picture

Okay, this is great information. Thanks. I will look into building a combined Postgres + nginx TKL image.

My end goal is to have a TKL build for Pleroma, which is the spiritual successor to GNU Social. Development on GNU Social has been dormant for quite some time, and the Fediverse is evolving.

This will be an interesting build because Pleroma is built with Elixir (Erlang) and uses nginx to proxy content. And because I've never done this before. :)


Jeremy Davis's picture

Considering your note re GNU Social, it'd be pretty damn awesome to have a Pleroma appliance in the "official" TurnKey library! So assuming that you can get it going, we'd be happy to pull your Pleroma build code into TurnKey and build it as an official appliance (giving you full credit for the development of course)! :)

FWIW what I usually do when building a new appliance is get the basics in place as best I can as TKLDev build code. Then I build to an ISO and continue development in the ISO until I think I'm close. Then I go back and build a new ISO. Hopefully I've got it all and it's good to go, although often it requires a few more tweaks and a final rebuild. The only catch is that you need to make sure that you copy back any changes that you make in your ISO. I generally use SCP to copy files across (to my TKLDev) or sometimes just copy paste (e.g. to add missing packages).

Please let us know how you go and ask if you hit any issues.

deutrino's picture

Thanks for this additional info. I'm still learning my way around TKLDev and don't fully understand it yet, so the tips about development process are really helpful.

I made good progress on a "LEPP" build last night. I'm wondering if there is any canonical source of information for a PHP 7.3 build which I can use as a cheat sheet - I recall seeing something about how you all were planning to use a non-official source of packages for this due to Debian's PHP being outdated.

An updated PHP could be a bit of a side track on the path to a Pleroma build, but I'd kind of like to make the LEPP build useful in its own right and get it stable, and I think PHP 7.3 would encourage this for a number of reasons. However if it's going to take an inordinate amount of time I may skip it.


deutrino's picture

Hmm, I figured out that PHP 7.2 is supported already.

I have a prototype LEPP build working, though there are some TODOs left. But if you have time, could you tell me if I did anything obvious wrong?


Jeremy Davis's picture

As I say, I've only had a quick glance, but from what I saw, you've very done well! :)

A couple of things did occur to me though. They're more preferences though, rather than anything you've done wrong.

The first is that my inclination for a standalone LEPP appliance would be to be inline with LAMP, LAPP and LEMP (aka Nginx-PHP-FastCGI) and to use the default PHP version from Debian (perhaps could have newer PHP but commented out? - FWIW that was what I had planned for LAMP et. al.). The reason for that is two-fold. First is that PHP from default Debian will get auto security updates. And secondly, I'm currently working on TurnKey v16.0 - which will include PHP 7.3 out of the box (based on Debian 10/Buster). So whilst v15.x remains useful, as soon as v16.0 is ready, all efforts will be focused on moving all appliances to that base.

Having said that, as you are planing this as the base for your intended app, then no need to redo that at this point.

The only other thing that jumped out at me was a note in the Makefile regarding PostgreSQL port. Whilst it's good to have it documented how to allow remote access to Postgres, by default it should not be publicly available. Again that is to keep it in inline with other appliances.

If you have any specific questions, or things you're not sure about, please do not hesitate to ask.

deutrino's picture

I'd actually be happy to produce a good LEPP build that you all could use / make official if you want, so I'll test it also with non-upgraded PHP and make sure everything works.

I see the docs say the sandbox is broken... is that still true? Now that I essentially cargo-culted a LEPP build together, I'm reading thru the docs (rather than just the getting started guides) more..

Jeremy Davis's picture

Re the sandbox, yes unfortunately that is still the case. We're currently not sure what we'll do with that. As I noted, we're currently in the process of working towards a v16.0 release. After we've got that completed, that will give us a little breathing space to look at "what next". We have some ideas (which we're not yet willing to make public) and exactly how we decide to move forward will determine whether we fix some of the broken bits, or rewrite it altogether...

Regardless, I think that a 'LEPP' appliance would be good to add! :)

PS in relation to testing, because the original TKLDev was written with the SysVinit system in mind (and we're now using SystemD), even if we fixed the sandbox, it isn't so useful for testing. That is because SystemD services won't run within a chroot (how we currently build appliances). One thought is to build within Nspawn containers!? That would have the added advantage of allowing us to do mutliple builds concurrently. We'll have to wait and see how it all pans out though...

deutrino's picture

Is there a way to conditionally install packages in the plan file, or conditionally install a plan file based on whether or not the user has uncommented PHP_VERSION in the Makefile?

Jeremy Davis's picture

In theory it should be possible, but I'm not super familiar with the depths of the C Pre Processor (Alon and Liraz set up all the TurnKey infrastructure initially, but they're now working on other projects, so now, together with our small team of developers, I'm primarily responsible for maintenance and development). I did have a stab at it, but was unable to get it to work, so fell back on a sub-optimal, although functional workaround.

How we did that for the LAMP based appliances was implement an additional and separate common 'LAMP' plan. You can find the default lamp plan in common, but there is also a lamp72 plan (which include PHP 7.2). A similar thing could be done for LEMP/LEPP if you wished. The common plan is included via the specific appliance plan, e.g. Nextcloud (the current version of Nextcloud requires PHP 7.1+).

It might well be useful to move some of the LEMP/LEPP plan/build code into common?I'm open to further discussion and/or providing guidance around that if you wish.

Add new comment