1. Home
  2. Categories
  3. Support
  4. Run proget container as non root

Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Run proget container as non root

  • Crimrose

    I have problem with proget when running it as non root container due to proget server required port 80, 1000 which is private port.
    Here is the logs error
    Unable to start Kestrel. System.Net.Sockets.SocketException (13): Permission denied while running alpine as non root user
    May I know are there any ways to change the port of Proget config to use port > 1024 ?

    1 Crimrose 1 Reply
  • Crimrose

    @Crimrose said in Run proget container as non root:

    I have problem with proget when running it as non root container due to proget server required port 80, 1000 which is private port.
    Here is the logs error
    Unable to start Kestrel. System.Net.Sockets.SocketException (13): Permission denied while running alpine as non root user
    May I know are there any ways to change the port of Proget config to use port > 1024 ?

    Sorry for the logs output that I copied wrong, but proget has same error status.

    0
  • rhessinger
    inedo-engineer

    Hi @Crimrose,

    What version of the ProGet image are you running? Would you be able send over your docker start command? Based on your error message, it sounds like you might have flipped the port mapping in the stat command. When using docker you should be able to map the internal port 80 to any external port on your Docker host that is open.

    Thanks,
    Rich

    0
  • K

    We are actually running into this issue as well using Podman root-less containers because everything inside the container is running as the user.

    [user@serverName]$ 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: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
-- {GUID for Container} --
[user@serverName]$ podman exec -it proget /bin/bash
bash: /root/.bashrc: Permission denied
[user@4c2bc39a6a24:/usr/local/proget$ id
uid=1001(user) gid=1001(user) groups=1001(user)

    I think it may have to do with the Messenger Endpoint that runs on port 1000. I am able to override the front-end web app (binding to port 80) using -e ASPNETCORE_URLS='http://+:8080' but I think we are still seeing that error because of that Messenger Endpoint here:

    ProGet version is 5.3.32.11.
Current DB schema version is 5.3.32.11.
Starting the messenger...
Messenger endpoint is tcp://localhost:1000
Reading standard license list...
Importing license list into database...

    Any thoughts on how to override that URL as well?

    Here are the logs:

    ProGet version is 5.3.32.11.
Current DB schema version is 5.3.32.11.
Starting the messenger...
Messenger endpoint is tcp://localhost:1000
Reading standard license list...
Importing license list into database...
License import complete.
Looking for web app at: /usr/local/proget/web
Initializing Scheduled Job Dispatcher...
Scheduled Job Dispatcher initialized.
Running Scheduled Job Dispatcher...
Checking for scheduled jobs...
Ensuring that all required scheduled jobs are configured...
Scheduled job configuration is correct.
Scheduled Job Dispatcher completed.
crit: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to start Kestrel.
      System.Net.Sockets.SocketException (13): Permission denied
         at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, String callerName)
         at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
         at System.Net.Sockets.Socket.Bind(EndPoint localEP)
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.<Bind>g__BindSocket|13_0(<>c__DisplayClass13_0& )
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass29_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context)
         at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.BindAsync(AddressBindContext context)
         at Microsoft.AspNetCore.Server.Kestrel.Core.AnyIPListenOptions.BindAsync(AddressBindContext context)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IEnumerable`1 listenOptions, AddressBindContext context)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
Initializing Proxy Configuration Monitor...
Proxy Configuration Monitor initialized.
Running Proxy Configuration Monitor...
Proxy Configuration Monitor completed.
Initializing Feed Replication...
Feed Replication initialized.
Running Feed Replication...
Feed Replication completed.
Initializing Docker Upload Cleanup...
Docker Upload Cleanup initialized.
Running Docker Upload Cleanup...
Docker Upload Cleanup completed.
Initializing Connector Cache Check...
Connector Cache Check initialized.
Running Connector Cache Check...
Getting list of connector responses...
No connector responses to check.
Connector Cache Check completed.
    0
  • rhessinger
    inedo-engineer

    Hi @kichikawa_2913,

    I'm not very familiar with Podman root-less containers. Does it expose all ports that are internal to the container externally?

    I think the issue that may be happening is the changing of the internal port which we have configured to be port 80. I do not think the ASPNETCORE_URLS will actually change the port that the site runs on internally because we are actually hosting the kestrel server within our service so we tell it to use port 80. Have you tried running the command as this:

    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 --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

    After a bit of research, it looks like you will get that error when you are trying to bind to a host port that is already in use. So make sure nothing else is using port 8080 on the host.

    The messenger endpoint URL is a URL that is only used internally in the container. You should not run into any conflicts with the default port that is used since it is not exposed externally. If you want to test using a different port, you can connect to your SQL database and run the following stored procedure. Make sure to update to the port you want to try.

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

    Please let me know what you find!

    Thanks,
    Rich

    0 K 3 Replies
  • K

    @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!

    0
  • K

    @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?

    0
  • rhessinger
    inedo-engineer

    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

    0 K 1 Reply
  • K

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

    0
  • rhessinger
    inedo-engineer

    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:

    1. 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
    1. 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

    1 K 1 Reply
  • K

    @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.

    0
  • K

    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.

    0
  • rhessinger
    inedo-engineer

    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

    1 K 1 Reply
  • K

    @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!

    0
  • rhessinger
    inedo-engineer

    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

    1
  • K

    @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.

    0
  • atripp
    inedo-engineer

    @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.

    1
Log in to reply
 
Inedo Website Home • Support Home • Code of Conduct • Forums Guide • Documentation