Hello all!

I finally got my Lemmy instance up and running yay!

It runs on a local machine, I have nginx installed and my website pointing onto it.

lemmy.mindoki.com => my_static_ip(port 80) => local_ip => nginx

In ngunx I just set up a hello world message, and it works out. lemmy.mindoki.com shows it.

Now, my Lemmy instance is accessible on 0.0.0.0:1236 but obviously only from inside the hosting machine itself.

I have tinkered a bit with the nginx.conf but I feel there is lot of things to do wrongly, especially as it’s ‘dynamic’, but also it seems like a schoolbook example (for Lemmy, so no hits on my favourite search engine), so maybe someone has a working nginx.conf file to spare for a basic setup like this?

Thanks a bunch!

2 points

Not sure if that’s what you’re looking for, but the Ansible repository has an NGINX template for both the Docker internal routing as well as for the host to reach the Docker internal one.

It is indeed pretty basic: essentially you just need to proxy_pass a location to the correct backend server.

permalink
report
reply
1 point

Thanks a bunch, but that is still quite incomprehensible for me, which means that either I’ll just fool around trying to get it right (which is not what I want to do) or learn it all the hard way (which I try to escape :-) ) or get some clever help ^^

Should I change: default “http://lemmy-ui”; “~^(?!(GET|HEAD)).*:” “http://lemmy”; proxy_pass “http://lemmy”; to my website somehow (I have an A redirect from lemmy.mindoki.com to my external IP => route to the linux box)?

Thanks again!

permalink
report
parent
reply
2 points

So, the part that selects what hostname it serves is the server_name directive. What those http://lemmy and http://lemmy-ui point to is the backend services. In this case, it’s assuming the Docker setup where the containers are named lemmy and lemmy-ui respectively. They’re completely invisible to the user, and in this case relies on Docker directing those names to the appropriate containers automatically. You don’t need to change those, unless you’re not using Docker. If you’re not using Docker, then those need to point to the address to reach lemmy and lemmy-ui. So for example, you might want to set that to http://127.0.0.1:1236.

Essentially, traffic comes in at port 80/443 or whatever your listen directives say, then NGINX receives the connection and processes the host header in the request to match it against which server{} block serves that server_name, or falls back to whichever server block defines listen ..... default_server, or if there isn’t any, it usually falls into whichever server block happens to be first loaded in by the server. Pretty much only the listen and server_name directives are relevant here in terms of handling incoming traffic from the outside, mostly. Things like ssl_* will also configure how to handle incoming HTTPS connection, but that happens slightly after the server block has been identified using the listen and server_name directives. Most other directives are about how to handle the request once it’s in the server block.

Then, it processes the request entirely within that server block. In this particular case, there’s a bit of logic so that it proxies it to lemmy-ui unless it’s an ActivityPub request or anything not a GET/HEAD request, in which case it tries to proxy it to the lemmy backend service. That’s what the if directives accomplish here. Usually we put those in location blocks, in this case the location / block so it handles all paths except other location blocks that override it. Some directives can be put directly in the server block and will apply to all locations unless overridden. Technically NGINX processes the location blocks first in order of precision (ie. /foo/bar/42/comments is more specific than /foo, and when there’s a tie it’s based on configuration order in the config file).

There’s also a location block to map some URLs like /.well-known and /pictrs that also gets proxied to the lemmy backend directly. The way those work is say, you want to handle something at http://example.com/demo, you can add a location /demo {} block and the directives in that block will only apply when the URL is /demo/*.

Does that clarify things for you?

permalink
report
parent
reply
1 point

Thank you and yes, yes it does clarify a lot how nginx is working!

I’m trying to use use the conf file coming with lemmy docker install, and after some searching I don’t even know if this is deprecated or not (it’s in the http{} ), or how I should tell nginx the information about where to find the docker devices:

upstream lemmy {
    # this needs to map to the lemmy (server) docker service hostname
    server "lemmy:8536";
}
upstream lemmy-ui {
    # this needs to map to the lemmy-ui docker service hostname
    server "lemmy-ui:1234";
}

Also, shouldn’t I tell nginx to listen to port 80?

Also, I get this error when I run “sudo nginx -s reload” and I don’t even understand what it means:

nginx: [emerg] host not found in upstream “lemmy” in /etc/nginx/nginx.conf:53

Thank you again, I’m a slow learner!

permalink
report
parent
reply
1 point

you tell it what you mean by lemmy and lemmy-ui earlier in the config file outside of the server {} block

upstream lemmy {
# this needs to map to the lemmy (server) docker service hostname
server “127.0.0.1:8536”;
}
upstream lemmy-ui {
# this needs to map to the lemmy-ui docker service hostname
server “127.0.0.1:1234”;
}

permalink
report
parent
reply

Lemmy Support

!lemmy_support@lemmy.ml

Create post

Support / questions about Lemmy.

Matrix Space: #lemmy-space

Community stats

  • 125

    Monthly active users

  • 1.2K

    Posts

  • 5.7K

    Comments

Community moderators