Any step by step guides to using Portainer and YNH?

Discuss
21

Hi floriandierickx

it’s the same to me. Anyway, the 5 point guide as mentioned above is okay.
But (still) there are some drawbacks.

When you restart docker the containers may get different IPs. In portainer itself you could/should enter a distinctive static address for each container. Also keep in mind the networks of your apps!

The error 502 Bad Gateway occurs, because the redirect ip changed, and now cannot be reached.
You get rid of it when you give nginx proxy the right IP address.
The ad-hoc workaround would be, changing the proxy settings to the actual, new container IP.

Right now, the greatest disadvantage obviously of the YNH redirect app is, that you cannot edit settings afterwards over GUI.

To do this you can edit the setting files manually:
It’s just the workaround!

nano /etc/nginx/conf.d/SUB.DOMAIN.XY.d/redirect.conf

Change the IP to point to the right container:
proxy_pass http://172.19.0.4:9000;

Then restart the proxy
systemctl restart nginx

And then call the server again
SUB.DOMAIN.XY

It should run. But this kind of frickle-frackle is not, what we want.

On the other hand, as mentioned in the description of the YNH redirect app, we should use a local ip.
Test what you get using curl. For example

curl http://127.0.0.1:9000
curl http://127.0.0.1:81
curl http://172.19.0.4:81

…

Okay, so now, for portainer I edited

nano /etc/nginx/conf.d/portainer.example.org.d/redirect.conf

change proxy_pass and then restart nginx.

proxy_pass http://127.0.0.1:9000

With the installation of the YNH redirect app (see step 4 above) it would be the
Redirect destination path:

http://127.0.0.1:9000

Now call the server again over secured https

https://portainer.example.org

and you will get the login screen of portainer.

1 Like
22

why do you need to install ngnix on docker? YNH has nginix

23

No, no, I think there is a misunderstanding.
I didn’t want to install nginx. As I mentioned before, my first idea was, to install portainer, and inside of it, nginx proxy manager.

Anyway, here we are talking about Portainer.

So, by now, portainer (and other container apps) can be reached over secured sub domains. But there’s one problem left.

The server can be reached by HTTPS, but also over its IP. Thus you have to close the exposed public ports.

For this, you need another taskforce.

1 Like
24

When you deploy a container, or restart docker, your iptables are completely different of your main rules.

Have a look at the rules settings
iptables -nvL
after

  1. deploying a container, or restarting docker and

  2. after restoring your own rules with
    iptables-restore < /etc/iptables/rules.v4

ad 1:
very complex

ad 2:
likely easy structured, just your own rules

Now, when you restore your own rules first and then restart docker, you get a combination of both!!!

Now iptables shows your own rules and the docker rules.
iptables -nvL

It seems this combination of the firewall settings should be the state, your server must use!!!???

Therefore, the tip would be, first restore your own rules and then restart docker! Then the combination of both is active!!!

The question now, what is the role of the YNH firewall with its poor gui?

1 Like
25

It is a security issue as Docker opens this port to the internet without ssl.

2 Likes
26

BTW:
I have tried to fix this with portainer testing package. Its failing on CI, but works for me.
It can be tested by:
$ yunohost app install --debug https://github.com/YunoHost-Apps/portainer_ynh/tree/testing

Will love to have feedback.

2 Likes
27

Thank you kanhu.
I had to fix some things during last days.
And to be honest, I’m a little bit afraid, to install the --debug for testing.

What I know so far additionally, is that after reboot, YNH exposes all docker ports to the public.

On the other hand, docker adds many rules to the iptables chains.

After restart the iptables contains even your own settings of the
/etc/yunohost/hooks.d/post_iptable_rules/95--my--hooks

Right after rebooting the machine, it seems very important to restart the YNH firewall, also [when you have docker installed].

But before that, it could be a good idea to wait a few seconds, to be shure docker has started.

Now, after restarting the YNH firewall, the iptables differ a lot those after restart.

This seems exactly what you want:
The YNH settings are good.
Docker is working and the exposed ports are closed.
The settings of the
/etc/yunohost/hooks.d/post_iptable_rules/...
are working.

With docker installed you must restart the YNH firewall right after a reboot.

Hey, kanhu, your testing --debug is to proof that?

I would do so, but I have already installed docker and portainer.
I don’t want to spend days repairing again.

What to do // what could we do now?

Uninstall docker and portainer, or
uninstall only portainer…???

Give us some advice!! Thanks.

28

I’m using the .local domains and I’m running into similar issues, any idea on how to proceed from here? I just can’t seem to reach anything once it’s running in portainer.

29

Unfortunately, using the package is giving me the same error as manually installing and configuring a Redirect/Reverse Proxy. Some resources are being SSOed despite being logged in, so I can’t even get past Portainer’s admin setup page.

Screenshot 2023-12-27 212310
Screenshot 2023-12-27 212310718×382 11.4 KB

This is on a request to https://portainer.mydomain.tld/api/users/admin/check

Editing /etc/ssowat/conf.json.persistent with the lines below does nothing…

{
    "permissions": {
        "portainerapi": {
            "auth_header": false,
            "label": "Portainer (api)",
            "public": true,
            "show_tile": true,
            "uris": [
                "portainer.mydomain.tld/api/"
            ],
            "users": []
        }
    }
}

Can someone shed a light to a fix?

1 Like
30

Your screenshot doesn’t mention what’s the HTTP status code … é_è

31

My bad! It returns 404.

32

Then 404 probably means that the sso does let the request through, but the requested endpoint really does not exists, and/or there’s whatever issue in the reverse proxy configuration or the app configuration …

33

The response header even include some “Content-Type: application/json” … doesn’t that json contain any info …?

34

I’m sorry, checked the wrong request.

Requesting https://portainer.mydomain.tld/api/users/1 returns 401 Unauthorized with JSON content being {"message":"A valid authorisation token is missing","details":"Unauthorized"}

35

I’m only 90% sure of this but i’m pretty sure that this looks like what portainer would answer when an anonymous user hits its API …

36

Well, I guess it was all solved before, but as a beginner I wasn’t able to troubleshoot this alone and today I learned something new.

After your input to check the JSON response (never knew this was possible), that request on https://portainer.mydomain.tld/api/users/admin/check was actually returning 404 correctly, because it couldn’t find any registered user.

I added back my edit to /etc/ssowat/conf.json.persistent and was able to login with the registered credentials getting past that 401.

I appreciate your help and definitely will be able to troubleshoot a lot more stuff with this new tool on my mental swiss army knife. :slight_smile: