Run proget container as non root

kichikawa_2913

@rhessinger I have tried to run the container by mapping internal 80 to 8080 on the host with the same permission denied result. I have checked to make sure 8080 is not being used on the host, that error is coming from inside the container, I would expect an error from Podman when calling podman run if the host port was already in use. I have gotten an error from podman when not mapping the ports because it was trying to use privileged port on the host (80).

I'll do some testing with the Service.MessengerEndpoint port, thank you!

kichikawa_2913

@rhessinger said in Run proget container as non root:

'tcp://127.0.0.1:6001'

I modified the database using that stored procedure you mentioned and am still getting the permissions denied.

Is there a way to override the port the service is using? I saw in the documentation that the Windows version has a configuration file that can enable overriding the URLs, but I did not see that config in the container. Would that config file allow changing the port the service is binding to?

rhessinger

Hi @kichikawa_2913,

Thanks for following up with that information. I was doing a little more research on podman this morning and it looks like this is a problem with the internal port. I have actually found quite a bit of people who claim that port 80 inside a container will not work on a root-less image, but looking at the podman document, their example uses port 80 inside the internal container. Let me look if there is an easy way to change that port binding on Linux and I'll get back to you shortly.

While I'm checking on that, can you try something for me? It looks like podman also needs a protocol to bind the port to. Could you try the following and let me know if that works?

podman run -d --userns=keep-id -v proget-packages:/var/proget/packages -v /etc/pki/ca-trust/source/anchors:/usr/local/share/ca-certificates:ro -p 8080:80/tcp --name=proget -e SQL_CONNECTION_STRING='Server=SERVERNAME;Database=ProGet;User ID=USERNAME;Password=PASSWORD' -e TZ='America/New_York' -i -t proget.inedo.com/productimages/inedo/proget:5.3.32 /bin/bash

Thanks,
Rich

kichikawa_2913

@rhessinger adding the /tcp resulted in the same error. Thank you for the information though!

rhessinger

Hi @kichikawa_2913,

I have an idea on how to accomplish this. It looks like Docker allows you to expose ports in the run command. Here is what I'm thinking should work. The first thing to do is to map a volume to /usr/share/Inedo/SharedConfig. In my example, I'll map to SharedConfig.

So here would be the steps to try:

Create the config file using port 8080

echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig><ConnectionString Type="SqlServer">'"`$SQL_CONNECTION_STRING"'</ConnectionString><WebServer Enabled="true" Urls="http://*:8080/"/></InedoAppConfig>' > SharedConfig/ProGet.config

run the container using the following command

podman run -d --userns=keep-id -v proget-packages:/var/proget/packages -v  `SharedConfig:/usr/share/Inedo/SharedConfig` -v /etc/pki/ca-trust/source/anchors:/usr/local/share/ca-certificates:ro --expose=8080 -p 8080:8080 --name=proget -e ASPNETCORE_URLS='http://+:8080' -e SQL_CONNECTION_STRING='Server=SERVERNAME;Database=ProGet;User ID=USERNAME;Password=PASSWORD' -e TZ='America/New_York' -i -t proget.inedo.com/productimages/inedo/proget:5.3.32 /bin/bash

Can you please give that a try?

Thanks,
Rich

kichikawa_2913

@rhessinger said in Run proget container as non root:

echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig><ConnectionString Type="SqlServer">'"`$SQL_CONNECTION_STRING"'</ConnectionString><WebServer Enabled="true" Urls="http://*:8080/"/></InedoAppConfig>' > SharedConfig/ProGet.config

Creating that configuration file and mounting it worked! I did not need the environment variable ASPNETCORE_URLS anymore and just changed the port binding to -p 8080:8080. Thank you for your help!

This worked implemented under Podman, I do not have Docker setup to test this with. I would assume it would work there as well just using Docker specific syntax with the commands.

kichikawa_2913

SIDE NOTE: The Podman run command I have in this thread mounts a root CA certificate location from the host into the container, this will not work with root-less containers. After we mount that volume we run podman exec -ti proget sh and then update-ca-certificates which won't work in root-less mode. Another method will need done to get your organization's root CA cert into the container for LDAPS.

rhessinger

Hi @kichikawa_2913,

That's great to hear! Just to make sure, you left in the --expose=8080 correct?

For the LDAPS thing, that makes complete sense. The SSL certs are at a root level and there is nothing we can do to change that. But I will note that there is an undocumented feature I added to bypass certificate validation for LDAPS. If you navigate to Administration -> Change User Directory -> Advanced -> Active Directory (NEW) and then select Use LDAPS and Bypass LDAPS Certificate Validation, that will allow you to use LDAPS and it just bypasses any certificate errors in the process.

Thanks,
Rich

kichikawa_2913

@rhessinger I did not have the --expose=8080.

I remember you adding that feature when we were working on the LDAP issues, thanks for reminding me!

rhessinger

Hi @kichikawa_2913,

Thanks for the information. I have updated our Docker Troubleshooting Guide to include details about root-less containers. We are also discussing internally if we want to change the default port to be > 1024 going forward.

Thanks,
Rich

kichikawa_2913

@rhessinger I was able to get the container running, validated a license, but then noticed that on the Administration page I was getting errors connecting to the messenger service:

Messenger not connected; attempting to connect...
Messenger connect failure: Connection refused
Messenger not connected; attempting to connect...
Messenger connect failure: Connection refused
Messenger connect failure: Connection refused
Messenger not connected; attempting to connect...
Messenger connect failure: Connection refused

I then ran the stored procedure you mentioned previously:

EXEC [Configuration_SetValue] 'Service.MessengerEndpoint', 'tcp://127.0.0.1:6001'

The messenger service is now connecting and seems to be operating as intended.

atripp

@kichikawa_2913 glad it's working now, you seem to have found the issue.

FYI, you can also configure that value from Advanced Settings page under Admin.