If you had a working standard install, you should be able to put things back that way and have it all still work.
The postgres issue might be related to PostgreSQL 13 update?
If you made a backup before you started you can install on a fresh server and restore that backup. That should be a worst case scenario.
How can I know if postgres issue is related to 13 update? I didn’t choose to update it, I simply digited “./launcher rebuild app”, and all the… things happened.
Yes, it’s version 13, after hours reading on internet of other people with the same problem I discovered this could be the problem, but I didn’t find a way to bring discourse alive.
Then that’s not the issue. Sorry.
I’m sorry to hear your having these troubles. I know the frustrating feeling of spending hours on trying to fix something. But you also learn something everytime, even if the path to the solution rarely is a straight line…
I’m sorry, but I’m not the right person to help you with this. I have no experience with postgres or unicorns. There are three ways how I make it through such “nothing works” scenarios: 1. backup so that I can always go back to the original state. 2. try/change only one thing at a time and try it on a non-production machine (or less important forum) first. 3. invest even more hours trying to figure things out.
BTW: writing detailed problem descriptions/ support tickets more than once helped me solve the problem. I didn’t even have to submit the ticket. Writing it up made me see the solution.
So in your case, what I’d try to understand is: under what circumstances can changing the app.yml and then changing it back to its original state lead to a different outcome than the original outcome. When looking into this, you either realize that you didn’t actually restore the exact original or you understand what else you need to “reset” in order for it to work.
I’m really sorry but I do not understand: first you asked me if the postgres issue might be related to Postgresql 13 update, and when I answered “yes, it’s version 13” (I swear I didn’t know what was before, lot of time I didn’t rebuild the app), you answer that is not the issue… so, why postgres is always “starting” and discourse don’t go?
Hey @Wanderer . I can’t tell what your problem might be, so the postgres upgrade was a wild guess. I’m pretty sure that if you are running postgres 13, then the issue is not that you are stuck getting upgraded from 10 or 12, so while there could be some problem with postgres, it probably is not related to the postgres 13 upgrade.
My best recommendation for someone who isn’t expert in these matters is to do a clean installation and restore your most recent backup.
If you would like to get more specific help for your issue and have a budget, you can contact me or post in #marketplace.
I’m going to work on improving the Nngin Proxy Manager instructions, but my guess is that your problem, though brought to light by trying to move to this complicated setups, likely is not because of these instructions being faulty. (I don’t know, but that’s my best guess.)
Here’s my version of this. I almost gave up, but @tophee linked to a post that I (!?) wrote that provided the necessary magic! This is now a straight-forward way to configure Nginx Proxy Manager for Discourse. I think this makes this similar to Running other websites on the same machine as Discourse - #396.
See that these lines in your yml file are commented out or deleted:
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
npm-default network.If you blindly follow the Nginx Proxy Manager install instructions, it will create a docker network called npm_default.
Add this stanza to your yml file(s). If you have separate web_only and data containers, you’ll need to add this to each of them (I didn’t test the mail-receiver container.). docker_args is not indented.
docker_args: |
--network npm_default
Comment out or remove these lines from your yml file:
# expose:
# - "80:80" # http
# - "443:443" # https
You can then rebuild your container(s) and configure Nginx Proxy Manager like this:
A simple (but not necessarily recommended) way to spin up a second Discourse site would be this:
cd /var/discourse/containers
cp app.yml othersite.yml
# somehow edit, at a minimum, the hostname in othersite.yml
./launcher rebuild othersite
Then add it to NPM as above, using othersite instead of app.
I tested this with an app.yml plus two web_only-style containers and a single data container plus a separate othersite-redis container that is a copy of the data container containing only the redis templates. (But an easier solution would be to put the extra redis in the web_only container).
So, after some struggling, I managed to make all the stuff working.
I must premise: although I’m a “old generation” developer (first '80), I always looked for the best and new form to develop or manage, so I really hate in 2021 to write weird commands full of cryptic options like with the old cp/m - dos, I always look for some interface that make my life easier and clearer.
Then, I use e.g. Portainer to manage containers, it permits to start/stop/edit/duplicate all containers on the fly, without “bashing” up and down the filesystem in search of one-in-a-million file; e.g. to change the container network it’s just to choose one from a list and make a click, idem for adding some parameters, or a volume like in the example @tophee wrote; for this reason I tried NPM, because I prefer to “contain” my Nginx proxy and because apparently with just a few click, well understanding what I’m doing but without to remember a new set of weird command-and-options.
Back to my Discourse container, I had to “discourse-setup” it again; evertything went right, “evil” Postgres installed in version 13, no “drunk unicorn” (I’m sorry but thinking about an “unicorn” running in my server makes me laugh! 
), in short all went the right way. Then, I made the modification in order to make Discourse running with websocket: everything ok also this time. Fortunately, previous Discourse setup made automatic backups, so with just few clicks I restored everything (the most I use Discourse, the most I love it!).
I had to try several times the setting for NPM, in the beginning I had some problem with certificates, but in the end even it run well.
I added a second proxy pointing to my Wordpress container (yes, I’m “containing” everything, I like the idea of a most clean server with all the main packages contained in a managed place), and even it run well.
So, in the end, I have my server (a VPS) with its email server (I also tried to “contain” it, but after weeks of harsh fight, I gave up), Discourse pointing to it, Worpress running in another container, and NPM managing both: all on my server, without depending on other (and much, much more expensive) services for deploing, emailing, etc.
Next step, importing some hundred thousand post from the “old good Phpbb”: prepare yourself for other posts from me! 
A great thank to @tophee and @pfaffman for the help, I can understand how difficult can it be to help people when they work in non standard way like me.
Glad you were able to get it to work with Websocket. For anyone else struggling with that, go for @pfaffman 's instructions for doing it without websocket above.
I don’t know what caused your problem, but it strikes me that this might be a point to clarify for anyone who is relatively new to discourse administration: you need to understand how the let’s encrypt certificate works in the default installation (w/o any outer proxy) vs how it works with NPM (and if you wonder why its called outer proxy, you need to figure that out too).
Since I originally set up my outer proxy manually and also set up let’s encrypt manually, I had an understanding for all the magic that discourse as well as NPM do for you so that https just works, and therefore I was able to avoid various pitfalls when switching from discourse-managed certificates to NPM-managed certificates.
I don’t really see why you would want to put the mail server behind NPM…
No Christoph, not behind NPM, just on a container. I tried Zimbra, but was a huge mess. Than a simple “contained” Postfix, but with no success too. I was in the beginning of my Linux experience (I’m still a beginner, but I’m getting more and more confident at least regarding some administration concept), so I gave up and tried directly on the server, it starts without great problems so I proceeded that way, even though it was quite hard to configure Discourse to use my email server. But now, evertything seems to work.
Sounds good with installation till i get stuck with npm to communicate with the discourse host; you mention to put the IP of the data container inside the mySQL host of the npm compose file
environment:
DB_MYSQL_HOST: "db"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "npm"
DB_MYSQL_NAME: "npm"
but when i change the (DB_MYSQL_HOST) to data container it’s show me connection refused.
connect ECONNREFUSED 172.17.0.2:3306 <-- error when npm in discours network (network_mode: bridge).
getaddrinfo ENOTFOUND db <-- error when the mySQL in npm compose file defind as "db".
any suggestion to let step 3. working with me ?
You need to see that both containers are on the same docker network. If you don’t have NPM working then you don’t (yet) have a Discourse configuration problem.
i mistakly forget the maria db docker network; but after adding
network_mode: bridge
i still get npm error in connect to the discourse database;
environment:
DB_MYSQL_HOST: "172.17.0.2" #data container - but i receive error ( error connect ECONNREFUSED 172.17.0.2:3306 ) when enabled.
# DB_MYSQL_HOST: "db" default npm databse (outside discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "h4xb0xr1z__0k"
DB_MYSQL_NAME: "npm"
when npm and maria comes up and running; the logs of maria good… but npm
error connect ECONNREFUSED 172.17.0.2:3306
any missing ?
my docker-compose file
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
network_mode: bridge
restart: unless-stopped
ports:
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
environment:
DB_MYSQL_HOST: "172.17.0.2" #data container - but i receive error ( connect ECONNREFUSED 172.17.0.2:3306 ) when enabled.
# DB_MYSQL_HOST: "db" default npm databse (outside discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "mypassword"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
# depends_on:
# - db
db:
image: 'mariadb:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'mypassword'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'mypassword'
volumes:
- ./data/mysql:/var/lib/mysql
i have discourse running with data + web-only; the map for IP’s after npm and maria is like this:
data container IP: 172.17.0.2
web_only container IP: 172.17.0.3
npm container IP: 172.17.0.5
maria data (npm) IP: 172.17.0.4
Hi @tophee
Can you give us your recommendation on using SQLite with NPM, since it’s more easy and trusted to work with than mariadb issue’s;
I have setup NPM with SQLite and everything working fine, nginx virtual host, ssl, etc… but i want make sure how to connect the database of discourse with NPM ? since i’m getting 502 error for the npm setup with the discourse site.
my docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
network_mode: bridge <-- this network has been added to let NPM be in same discourse network, and they now see each others.
ports:
# Public HTTP Port:
- '80:80'
# Public HTTPS Port:
- '443:443'
# Admin Web Port:
- '81:81'
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
No, my recommendation is to use NPMs standard setup unless you know what you’re doing. That’s the reason why I’m using the standard setup.
You don’t need step 3 if you connect the discourse container via websocket.
This is because
Are you sure that 172.17.0.2 is your db container? - In any case: you can skip this trouble by leaving NPM on its own network and connection discourse via web socket.
Thanks @tophee for clarification, i have done and correct everything, but seems i didn’t use websocket and i was focused on the port with npm setup and discourse’s containers;
my issue i face with NPM was with CloudFlared Argo tunnel, after i finish the setup of NPM, ssl, everything… i managed to run CloudFlared argo tunnel but the issue was that CloudFlared cannot be run as a secondary proxy, were we need to disable NPM to be in front of the origin web; the error i get from CloudFlare is this:
Error 1000: DNS points to prohibited IP
after searching for this error with cloudflare; it’s give me this
There is a reverse-proxy at your origin that sends the request back through the Cloudflare proxy. Instead of using a reverse-proxy, contact your hosting provider or site administrator to configure an HTTP redirect at your origin.
How can we disable NPM as a reverse-proxy ?
My point is to make the orign IP works without NPM “while” npm is installed and working; so we can make cloudflared communicate with our server ?
Uninstall NPM. The whole point of NPM is to act as a reverse proxy. If you don’t want a reverse proxy, turn it off.
I don’t quite get the point and this is certainly nothing have any knowledge about. You should probably check the NPM forum or something. This has nothing to do with discourse.
I already did open there; and i discuss here also, and yes, i have disable it after 2 days playing around; but i would add how to i add custom port support with Discourse and NPM here, since this topic support only socket nginx with npm;
Thanks.
No. It doesn’t only support sockets unless you follow the socket instructions. It says that you don’t have to use sockets:
When I last tested this, it worked just fine using a port as suggested.