Posts made by kichikawa_2913

@dean-houston Thank you for the insight! Definitely did not think of that as an issue.

We have been using ProGet for a while now and are really starting to expand how we use it. We have developers upload private, shareable NuGet/PyPi packages and mirror nuget.org/PyPi packages. We hadn't had multiple connectors for one type of feed until recently with NPM repositories and some new NuGet feeds for other vendors.

Has anyone found if associating multiple connectors to one feed made management easier or more difficult? If you introduce promoting packages, does that affect the decision to associate multiple connectors to one feed?

An example we have is mirroring the default NPM rpository as well as a FontAwesome NPM repository for a paid tier. It seems easier to associate both connectors to one "unapproved-npm" feed and promote allowed verisons to one "approved-npm" feed, but we also don't have an automated pipeline around promoting packages. So, we are still very earlier in discovering what works for us.

Any input/experience would be greatly appreciated!

Hello! We have been creating our own, internal, Terraform modules and would like to host them internally. Casting my vote to have this implemented!

@atripp I know this is an old topic, but I have not see anyone else ask about the Age field with uploaded symbols and I don't see it addressed here. We had a developer upload a .snupkg to a ProGet feed (hosted on Podman containers on Linux) and the age field does not make sense to me either. We are running Version 2023.15 (Build 4)

We are also experiencing this issue, what version will this be resolved in?

I second this! We also use Prometheus for metrics on as many of our tools as we can get.

@atripp restarting the container seemed to have resolved the issue, the secure credential does not show like that anymore and I was able to link a secure resource to it.

@atripp we only have one web node so traffic is only going to one instance.

Here is what shows after clicking on the TeamCity extension:

@rhessinger here is the Extensions page:

Here is the container log after starting up, it looks like the extensions load okay:

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0 - 200 233 - 3.2996ms
Running Execution Dispatcher...
Execution Dispatcher completed.
Running Execution Dispatcher...
Execution Dispatcher completed.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0 - 200 233 - 2.8641ms
Running Execution Dispatcher...
Execution Dispatcher completed.
Running Execution Dispatcher...
Execution Dispatcher completed.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0 - 200 233 - 5.0181ms
Running Execution Dispatcher...
Execution Dispatcher completed.
Running Execution Dispatcher...
Execution Dispatcher completed.
Running Infrastructure Sync...
Infrastructure Sync completed.
Running Execution Dispatcher...
Execution Dispatcher completed.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0 - 200 233 - 4.6794ms
Attempting to use shared configuration for BuildMaster.
Shared configuration file not found at /etc/inedo/BuildMaster.config.
No encryption key is configured. Credentials will be stored in plain text.
BuildMaster version is 7.0.21.1.
Current DB schema version is 7.0.21.1.
Starting the messenger...
Configuring proxy settings...
Checking for server and database time difference...
Starting the Event Listener Dispatcher task runner...
Event Listener Dispatcher task runner started.
Starting the Server Checker task runner...
Server Checker task runner started.
Starting the Execution Dispatcher task runner...
Execution Dispatcher task runner started.
Starting the Update Checker task runner...
Update Checker task runner started.
Starting the Infrastructure Sync task runner...
Infrastructure Sync task runner started.
Starting the Pipeline Stage Validator task runner...
Pipeline Stage Validator task runner started.
Starting the Repository Monitor task runner...
Repository Monitor task runner started.
Starting the Scheduled Promotion Dispatcher task runner...
Scheduled Promotion Dispatcher task runner started.
Starting the System Execution Cleanup task runner...
System Execution Cleanup task runner started.
Starting the Retention Policy Dispatcher task runner...
Retention Policy Dispatcher task runner started.
Initializing Server Checker...
Initializing Execution Dispatcher...
Server Checker initialized.
Running Server Checker...
Checking servers...
Server Checker completed.
Execution Dispatcher initialized.
Running Execution Dispatcher...
Execution Dispatcher completed.
info: Inedo.Web.BackgroundTaskQueueService[0]
      Background Task Queue is starting.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://[::]:8082
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /usr/local/buildmaster
Initializing Event Listener Dispatcher...
Event Listener Dispatcher initialized.
Running Event Listener Dispatcher...
Checking for event occurrences after #0...
No event listeners need to be run.
Event Listener Dispatcher completed.
Running Execution Dispatcher...
Execution Dispatcher completed.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0
Setting proxy configuration...
Initializing extensions in /var/buildmaster/extensions...
Loading DotNet extension from /tmp/Inedo/ExtensionCache/f6315c3b229fa3387291f6ed2860acff8156a66d/package/net5.0/DotNet.dll...
Loading Git extension from /tmp/Inedo/ExtensionCache/d72b402996bcfb39d53ea89306b0b9f99bdebb90/package/net5.0/Git.dll...
Loading GitHub extension from /tmp/Inedo/ExtensionCache/6d078cf74c73cb8253cc22f64b763f3354be2e70/package/net5.0/GitHub.dll...
Loading InedoCore extension from /tmp/Inedo/ExtensionCache/a97372944e4b7e10404a9c7a4e846b944543463e/package/net5.0/InedoCore.dll...
Loading Jira extension from /tmp/Inedo/ExtensionCache/dc2da12cdb46e606be47ee7ae37766778b7026e9/package/Jira.dll...
Loading Scripting extension from /tmp/Inedo/ExtensionCache/54259091ec39b1a2d22a7dbf039d26bd4593daf0/package/net5.0/Scripting.dll...
Loading Windows extension from /tmp/Inedo/ExtensionCache/3f1cf38d508f252d35c93e10c85435e41d929dfe/package/net5.0/Windows.dll...
Loading Jenkins extension from /tmp/Inedo/ExtensionCache/1e4510c2ecb2c4f9d6a20631d1e0a4174bdafa94/package/net5.0/Jenkins.dll...
Loading NuGet extension from /tmp/Inedo/ExtensionCache/e535b3c4766bf719a6949ef3fd7538b3fecc4da0/package/NuGet.dll...
Loading NUnit extension from /tmp/Inedo/ExtensionCache/71b4512fcd92ddf010a08c2fe8a07f6db5366de5/package/NUnit.dll...
Loading Python extension from /tmp/Inedo/ExtensionCache/511919953e90ac88aeb465de74ad46e07417a5b0/package/net5.0/Python.dll...
Loading TeamCity extension from /tmp/Inedo/ExtensionCache/b85e2ed12ff40cfdda3c896b7bbed5959005f24d/package/net5.0/TeamCity.dll...
Extensions manager initialization complete.
Initializing Infrastructure Sync...
Infrastructure Sync initialized.
Running Infrastructure Sync...
Infrastructure Sync completed.
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://ohsedvcntnr01.summit.network:8082/0x44/BuildMaster.WebApplication/Inedo.BuildMaster.Web.WebApplication.Controls.NotificationBar/GetNotifications - 0 - 200 233 - 751.3204ms
Running Execution Dispatcher...
Execution Dispatcher completed.
Initializing Pipeline Stage Validator...
Pipeline Stage Validator initialized.
Running Pipeline Stage Validator...
Getting list of active builds...
Pipeline Stage Validator completed.

@atripp thank you for the info! What's the typical setup you see with other customers? Is all this described in documentation somewhere I missed?

Hello!

We are working on a PoC of BuildMaster and something we can't find in documentation is where exactly does the code get built? We are used to an environment where the code gets checked out on a dedicated agent server that has all the build tools needed installed on it and the code gets compiled there. I see BuildMaster has an Agent you can install and connect to other systems using WMI/SSH, but is code compiled on the target system?

Currently for us:

Bitbucket (source code checked out to) -> TeamCity Agent (compiles code/unit tests) -> Octopus Deploy -> IIS Server

How BuildMaster may work?

Bitbucket (source code checked out to) -> IIS Server (BuildMaster issues remote commands to compile code/unit tests)?

I guess we could still have agents with BuildMaster, but I guess they are more generic than how TeamCity defines it where we install a specific agent binary on there.

Hello!

We are trying out a PoC of BuildMaster running in containers on Podman (like how we run ProGet currently) and we are having issues trying to migrate TeamCity projects into BuildMaster via the extension.

We install the extension, create the Secure Credential (TeamCity API Key), and after creating that it looks like this:

While it's in this state it can't be used when setting up the Secure Resource, so we can't continue with the setup of the TeamCity integration.

We tried to uninstall and reinstall the extension, but same thing. No errors in the Diagnostics Messages or in the container logs from what I can tell.

@atripp our security team does not have anything that could be blocking. I'll work to get a fiddler .saz file for you as soon as I can. Thank you all again!

@atripp those are the only things in the container logs when I click "Install" in VS for the package in question. The name of the package is in the URLs below and I don't see any other URLs related to that package in the log.

I also made sure to clear the NuGet cache before attempting to install and I get the same results; request to http://repo.dev.internal.network/nuget/approved-nuget/v3/registrations-gz/selenium.webdriver.chromedriver/index.json results in a 401, LDAP search, some health checks, then a request to http://repo.dev.internal.network/nuget/approved-nuget/v3/registrations-gz/selenium.webdriver.chromedriver/index.json resulting in a 200.

I'm double checking with our security team to make sure we aren't blocking anything.

@stevedennis said in Permissions only work when set for specific user, not a group (LDAP):

Hi @kichikawa_2913 ,

The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of api and the password of your api key.

Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.

The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.

Cheers,
Steve

I tried removing my credentials for VS and re-added them as "api" username and personal API key as the password, same results; get a 401, LDAP query, then 200 and getting same error in VS.

Seems like we need to keep the Anonymous permissions on all repos?

I think I remember in one of my posts, or another, someone saying that NuGet CLI will not send authentication on the initial query for a NuGet package and there might be a way to force it to?

@atripp I wasn't seeing anything in the logs before but this is what I get now. There's an initial query that looks to return a 401 then a second query after the LDAP lookup that returns a 200. I took away the Anonymous permissions in hopes to not use that where I can.

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://server01.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://server01.internal.network/health - 0 - 200 492 application/json 0.2094ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://server01.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://server01.internal.network/health - 0 - 200 492 application/json 0.1055ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://repo.dev.internal.network/nuget/approved-nuget/v3/registrations-gz/selenium.webdriver.chromedriver/index.json - -
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://repo.dev.internal.network/nuget/approved-nuget/v3/registrations-gz/selenium.webdriver.chromedriver/index.json - - - 401 84 - 36.7864ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://repo.dev.internal.network/nuget/approved-nuget/v3/registrations-gz/selenium.webdriver.chromedriver/index.json - -
Begin LDAP Get Search Results
LdapReferralException
LdapReferralException
LdapReferralException
End LDAP Get Search Results
Begin ActiveDirectoryUser IsMemberOfGroup
End ActiveDirectoryUser IsMemberOfGroup
Begin ActiveDirectoryUser IsMemberOfGroup
End ActiveDirectoryUser IsMemberOfGroup
Begin ActiveDirectoryUser IsMemberOfGroup
End ActiveDirectoryUser IsMemberOfGroup
Begin ActiveDirectoryUser IsMemberOfGroup
End ActiveDirectoryUser IsMemberOfGroup
Begin ActiveDirectoryUser IsMemberOfGroup
End ActiveDirectoryUser IsMemberOfGroup
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://server01.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://server01.internal.network/health - 0 - 200 492 application/json 0.2086ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://server01.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://server01.internal.network/health - 0 - 200 492 application/json 0.0710ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://repo.dev.internal.network/nuget/approved-nuget/v3/registrations-gz/selenium.webdriver.chromedriver/index.json - - - 200 11843 application/json 425.9930ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://server01.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://server01.internal.network/health - 0

@rhessinger I have done that multiple times and no difference.

We recently started having an issue restoring/installing Selenium.WebDriver.ChromeDriver versions 96.X or newer from ProGet using Visual Studio and dotnet CLI. If we flip over to nuget.org the problem is resolved. We also had a developer "get it working" when he changed his Visual Studio settings to prefer PackageReference over packages.config:

I made that change in my environment and am still having the problem. I don't see any errors in ProGet and on the package Usage/Statistics page I do not see any attempts from the day I tried to download the package from Visual Studio.

The user I am running Visual Studio as is able to log into the Web UI and manually download the package, but not from Visual Studio or nuget CLI.

Seems to be related to versions after 95.0.4638.6900, we are able to install that version and prior without issues from ProGet.

@Dan_Woolf everything seems working as expected except for the following error from Visual Studio:

Severity Code Description Project File Line Suppression State Error Package 'Selenium.WebDriver.ChromeDriver 99.0.4844.5100' is not found in the following primary source(s): 'https://repo.dev.internal/nuget/approved-nuget/v3/index.json'. Please verify all your online package sources are available (OR) package id, version are specified correctly.

This error has apparently been reported since before we started working in this ticket. Should I open a new ticket to look into this one? This seems to be the only package we have this issue with, if we go directly to nuget.org we do not have this issue.

@Dan_Woolf All your bullets are correct and I did clear out my Visual Studio credentials; re-entering my credentials appears to have resolved the issue even with the 6.1 preview features enabled. I did not use an API key, I just entered my Windows credentials.

We are going to get our LDAP integration user corrected and continue to test to be sure. Thank you all for your help! It is greatly appreciated.

@Dan_Woolf something else I noticed in the preview security features is that I can't find where to manage the AD credentials for the LDAP integration user. I had to revert back to pre-6.0 behavior to do it.

@Dan_Woolf working with some other team members, we found that the user we are using for the AD configuration does not have permissions to enumerate the user groups. I tried with a different user that does have permissions and view/downloading packages from the UI works fine, but from Visual Studio still does not. I tested using pre 6.0 security features and post-6.0 features with the same results.

So part of the issue is the permissions of the user we are using in the AD configuration.

@Dan_Woolf the issues we were running into (value too large for defined data type) were related to our AV being installed and enabled on the server.

@sebastian we updated to 6.0.10 and made sure InedoCore was up-to-date and we are still seeing issues where scoping view/download permissions to an AD group does not work but adding "Anonymous" or specific users does work.

We are now having issues just creating the container getting the following error:

Error: error creating temporary passwd file for container 441b7e059858087ded586bf7b20a02284af788603bd6fb67e532a0021107db1c: open /home/{username}/.local/share/containers/storage/overlay/6b312eb340dc2cafa8c6aaccdec719d8c249b226b4825ada3250bafd209a607d/merged/etc/passwd: value too large for defined data type

I don't think this is related to ProGet, so I'll report back after we get this resolved.

@sebastian thanks for the info! We'll try to update to most recent version and restarting the instance.

@Dan_Woolf we don't have that group in different OUs from what I can see, that looks like the "path"/hierarchy to the group ("Security Groups" -> "Roles" -> "IT"). I'm not as familiar with AD as I would like to be, so I'll ping our admins on that.

@Dan_Woolf sent a second email showing all the settings used in the tool.

@Dan_Woolf I'm not getting any users back, I emailed you the debug log.

@Dan_Woolf from a Visual Studio perspective it seems to be working better, meaning we can see all versions for a package but unable to download certain versions of packages. The only example I have so far is Selenium ChromeDriver NuGet.

Error Package 'Selenium.WebDriver.ChromeDriver 99.0.4844.5100' is not found in the following primary source(s): 'https://repo.dev.summit.network/nuget/approved-nuget/v3/index.json'. Please verify all your online package sources are available (OR) package id, version are specified correctly.

Despite the package version there and downloadable:

If I log into the UI with a user from that group I still get 403.

@stevedennis

1. User logs in, clicks on "Feeds", and only sees the 403 message on the page with nothing else available.
2. I sent an email with screenshots of the test privileges for the group and specific user in that group.

What do you mean by "revert to the 6.0 behavior"? We are on 6.0.8, should we revert back to the initial release of 6.0.0?

@Dan_Woolf 1 did not work and 2 lets me log in but results in 403 unauthorized still.

@Dan_Woolf we only have one "emergency admin" account created with the built-in method. The only reason that is enabled is because the UI recommended it be enabled in case of an emergency or when switching between methods. We have absolutely no users from AD setup on the built-in method.

@Dan_Woolf Sent

@Dan_Woolf said in Permissions only work when set for specific user, not a group (LDAP):

[QA-785] Permissions Configuration

Sending an email with screenshots.

We are running 6.0.8 Build 5 and InedoCore 1.13.0 with and update available to 1.13.1.

@Dan_Woolf thank you for the clarification!

1. Users are downloading packages using Visual Studio and I did see it prompt for credentials that are stored in the Windows Credential Manager.
2. The users can log into the ProGet UI but are not able to view or download any packages from any feeds despite having the permissions setup with an LDAP group. They are only able to accomplish this when I scope permissions/tasks directly to a user.

We do have "Search recursively" enabled in our LDAP setup.

Thank you for the response.

1. Using the username of api and the api key as the password, is that setup in the Task/Permissions section or in a NuGet.config file?
2. I used the "test privileges" function and it shows that the group has View/Download permissions.
3. My user is directly in the group, not indirectly by some other group.

Hello,

I logged an issue here: https://forums.inedo.com/topic/3271/cannot-push-nuget-package-to-ldap-secured-feed?_=1646689732560 about not being able to upload packages to an LDAP secured feed. It was indicated there that the NuGet client queries the feed first which does not use any API key, so we had to enable Anonymous permissions to View/Download on all feeds. Why is that the case?

Also, I think this is related to that, we tried to set permissions to View/Download feeds at an LDAP security group level, but users are getting a 403 unauthorized. If I scope the permissions directly to the user it all seems to work as intended. Am I configuring the LDAP group permissions incorrectly?

@Dan_Woolf thank you for the details! Is all that reflected in documentation somewhere? If not, can documentation be updated to explain that a container network is required to have the service messenger traffic balanced across nodes? I don't remember seeing anything describing that.

If I click the [change] button at the bottom of each node's Service section and set it to all the same thing tcp://containerhost01.internal.network:6001 they all show as connected now and green.

It almost seems like the instances are not using the shared configuration setting.

@Dan_Woolf I updated the Service.MessengerEndpoint value, restarted the containers, no difference.

@Dan_Woolf I'll have to dig back through the documentation but I thought all the instances just needed to communicate back to the primary node.

1. We did not setup any network for these. They are rootless containers running on two different hosts and they are all listening on different ports using the host's IP.
2. We do have HA enabled.

I did try changing the Service.MessengerEndpoint to the value you recommended but I did not restart the containers, I will try that.

I'm not seeing any issues already logged on this; we just upgraded our production cluster of 4 podman containers running on OEL 8 from 5.3.37 to 6.0.8 and we are seeing our "backup" instances not able to connect to the primary node's service messenger.

I have tried to click the "Reconnect Service Messengers" and it does not appear to do anything. The only things in the container logs are this:

Messenger not connected; attempting to connect...
Messenger not connected; attempting to connect...
Messenger not connected; attempting to connect...
Messenger connect failure: Resource temporarily unavailable
Messenger connect failure: Resource temporarily unavailable
Messenger connect failure: Resource temporarily unavailable

Besides those errors, these may be unrelated, we are seeing these in all containers:

info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://proget.internal.network/health - 0 - 200 489 application/json 1.5043ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://proget.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://proget.internal.network/health - 0 - 200 489 application/json 1.6918ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://proget.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://proget.internal.network/health - 0 - 200 489 application/json 1.5451ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 POST http://proget.internal.network/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 POST http://proget.internal.network/0x44/ProGet.WebApplication/Inedo.ProGet.WebApplication.Controls.Layout.NotificationBar/GetNotifications - 0 - 200 30 - 0.5531ms
Failed to record node status: IFeatureCollection has been disposed.
Object name: 'Collection'.
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://proget.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://proget.internal.network/health - 0 - 200 489 application/json 5.3372ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://proget.internal.network/health - 0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://proget.internal.network/health - 0 - 200 489 application/json 1.8011ms
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]

Here is what we have the "Service.MessengerEndpoint" set to: tcp://containerhost.internal.network:6001 - we only have the primary node listening on tcp://*:6001, no other containers are listening, this is how we had it setup on the previous version. There is also a value in the "Service.MessengerEncryptionKey" field.

I also noticed in the first screenshot that the address the other instances are attempting to connect to are different per instance.

Looks like using the environment variable worked. Sorry for the pollution!

Looks like I'm late to the party and ashamed I did not see the other issues related to this....https://forums.inedo.com/topic/3402/proget-on-rootless-docker-cannot-switch-port

I'll try these out and see if this solves it.

We are testing upgrading ProGet from 5.3.37 to 6.0.5 in our test environment. We run ProGet in rootless Podman containers on OEL8 with the following command:

podman run -d --runtime=crun --userns=keep-id -v /home/local-user/sharedconfig/config1:/usr/share/Inedo/SharedConfig -v /var/proget/packages:/var/proget/packages -p 8080:8080 --name=cproget -e SQL_CONNECTION_STRING='<connection string>' -e TZ='America/New_York' proget.inedo.com/productimages/inedo/proget:6.0.5

In the .../sharedconfig/config1 directory we have the following:

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

The config above is a result of working in this issue: https://forums.inedo.com/topic/3098/run-proget-container-as-non-root/3?_=1641935170390

We are getting the following error when the container starts:

Starting the Package/Container Scanner task runner...
Package/Container Scanner task runner started.
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.
info: Inedo.Web.BackgroundTaskQueueService[0]
      Background Task Queue is starting.
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, EndpointConf                                                                                                                                                                                        ig 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 Drop Path Monitor...
Drop Path Monitor initialized.
Running Drop Path Monitor...
Getting list of feeds with a drop path...
No feeds with a drop path.
Drop Path Monitor completed.
Initializing Execution Dispatcher...

It seems to me that the new version is possibly ignoring the config file we have to force it to use higher ports since we are running rootless. We have confirmed the location is mounted and we can see the shared configuration file in the container when interactively working in it.

@stevedennis sorry for such a delayed reply. Our use case is simply because when we setup our shares on our SAN we setup a share per package type (python, NuGet, etc) just in case of the need to more granularly control backups/maintenance of the shares. We may run into different issues/needs depending on the package type or we may not, just wanted to have the ability.

@Dan_Woolf thank you for the swift reply! We do have Storage.PackageRootPath set and we setup NFS shares for each type of package under that path that we host internally (Python, NuGet, Powershell, etc.) but just noticed an explicit NuGet path is not available unless you go to each feed.

Unless there's some under-the-hood functionality between nugetV2 and nugetv3 that would prevent it, I think it would be nice to have a setting like the others at a global scope for NuGet for consistency.

We are running ProGet v5.3.37 in Linux Containers and we are not seeing a way to set the "Storage.*" path for NuGet feeds under "Administration" >> "Advanced Settings". We are able to set Python, NPM, etc. The only way we have found to do this is editing each NuGet/Powershell feed individually under the "Manage Feed" >> "Storage and Retention".

Is there a specific reason there's not a more general path setting for those or just an oversight?