Topics created by Stephen.Schaff

Hi @Stephen-Schaff, Thanks for the detailed write-up; the behavior you describe makes sense, and made for very copy/pasting PG-2478 :) We anticipate getting this in the next maintenance release, scheduled for Sept 15 Best, Dean

@Stephen-Schaff thanks so much Stephen, that's great! It's not so hard for us to add this api key back, but your code works just the same mostly i think! let us know... Anyway I've updated the documentation :)

Hi @Stephen-Schaff, This checkbox will do the latter, i.e. "keep the newest 100 versions in each chart (up to 2,000 charts in total)" :) Note that you can also run retention policies in "dry mode" (it's a setting under Advanced Settings), to see how they would perform. Cheers, Nanci

@Stephen-Schaff thanks! We are planning to rebuild all the users/groups/permissions pages in the coming weeks, so I'll also this as something for us to consider getting in

@Stephen-Schaff great to hear! And I guess another way to do it would be enabling/disabling the semver restrictions on the feed Let us know if it keeps happening, and you can find a pattern - we'll see if we can identify what might be the cause of it

@Stephen-Schaff We're also considering locking down nuget.org, so the more info we have in ProGet, the better.

Hi @Stephen-Schaff, The latest tag is a bit odd. Each client handles it differently and I have found most clients will not repull a newer version if latest has already been pulled once. According to Docker's API (and Kubernetes), a client is supposed to pull the manifest from the server and compare it with the currently downloaded image and update if there is any difference, but I have found that does not always work. You can configure Kubernetes to always pull an image, but I cannot confirm how well it works. As for getting a list of tags, we basically have two ways. What it sounds like you are looking for is to just get a list of alternative tags. The only way to do this is to use our native API and using the DockerImages_GetTags method and grouping by DockerImage_Id. The other way to get a list of tags would be to use the docker API itself. This way will get all tags associated with a repository, not just the alternative tags. To do this: Make a get request to http://<your proget server>/v2/_auth with an Authorization header with the value of Basic <BASE 64 encoded username:password> The response will be a JSON object. Take the value in the token property Make a GET request to list all tags to http://<your proget server>/v2/<feed name>/<image>/tags/list (ex: `http://proget.localhost/v2/defaultdocker6/dotnet/core/aspnet/tags/list) In the header include an Authorization header with a value Bearer <token from step 1> This will return a JSON object that has an array property called tags That will get you a list of tags using the Docker API. Hope this helps! Thanks, Rich

Hi @Stephen-Schaff , Yes, this can be a little bothersome. Actually this is something that we're considering for v6, to mostly replace the "impersonation" feature: Allow on Feeds: [feed1, feed2, «group1»] Feed Permission: View/Download Publish/Push Delete/Overwrite The "username" would still be there, but mostly for "personal api keys". Thanks, Alana

@Stephen-Schaff you got it! We'll try to get PG-1996 added in the next maintenance release. Should just be a pretty straight-forward loop :)

Thank you. I will do that.

Thanks for the update @Stephen-Schaff -- And just to add to this, you should see "Note that you can use the following alternative tags to refer to this image:..." on the browse image page.

Version 6 of ProGet removes the ability to make calls to the docker API via a ProGet API Key. As such the code posted above no longer works. I updated it to work using the Docker Token based Authentication system. I am posting it here in case someone comes along this post and wanted to use this code: function RepackageContainerImage() { param ( [string] $packageName = $(throw "-packageName is required. This is the namespace/image-name"), [string] $fromFeed = $(throw "-fromFeed is required"), [string] $toFeed = $(throw "-toFeed is required"), [string] $fromVersion = $(throw "-fromVersion is required. This is the current tag on the image in the fromFeed."), [string] $toVersion = $(throw "-toVersion is required. This is the tag to be applied after the image is promoted."), [string] $comments = "Promoted by automation", [string] $apiKey = $(throw "-apiKey is required"), [string] $progetBaseUrl = $(throw "-progetBaseUrl is required") ) # Promote the Container Image $postBody = @{ packageName="$packageName"; groupName=""; version="$fromVersion"; fromFeed="$fromFeed"; toFeed="$toFeed"; comments="$comments" } $promoteResponse = Invoke-WebRequest -Uri "$progetBaseUrl/api/promotions/promote" -Method POST -Body $postBody -Headers @{"X-ApiKey"="$apiKey"} # Retag the container image by downloading the manifest and then re-uploading it as the new version $pullToken = GetDockerToken -feed $toFeed -packageName $packageName -actionToAuthorize "pull" -apiKey $apiKey -progetBaseUrl $progetBaseUrl $manifest = Invoke-WebRequest -Uri "$progetBaseUrl/v2/$fromFeed/$packageName/manifests/$fromVersion" -Method GET -Headers @{Authorization=("Bearer {0}" -f $pullToken)} $pushToken = GetDockerToken -feed $toFeed -packageName $packageName -actionToAuthorize "push" -apiKey $apiKey -progetBaseUrl $progetBaseUrl Invoke-WebRequest -Uri "$progetBaseUrl/v2/$toFeed/$packageName/manifests/$toVersion" -Method PUT -Body $manifest.ToString() -Headers @{Authorization=("Bearer {0}" -f $pushToken)} } function GetDockerToken() { param ( [string] $packageName = $(throw "-packageName is required. This is the namespace and image name. For example: library/my-container-image"), [string] $feed = $(throw "-feed is required"), [string] $actionToAuthorize = $(throw "-action is required. This is the docker action to be authorized (pull, push, delete, etc)"), [string] $apiKey = $(throw "-apiKey is required"), [string] $progetBaseUrl = $(throw "-progetBaseUrl is required"), [string] $service ) if ($service -eq "") { $service = $progetBaseUrl.SubString(8,$progetBaseUrl.Length-8) } $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f "api","$apiKey"))) $response = Invoke-WebRequest -Uri "$progetBaseUrl/v2/_auth?service=$service&scope=repository`:$feed/$packageName`:$actionToAuthorize" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} if ($response.StatusDescription -eq "OK") { $token = ($response.Content | ConvertFrom-Json).token $token } }

@NanciCalo, Thank you for your prompt help! We have contacted our purchasing department to get a rush order on the new license. ("Rush" means that I hope to have it in a week or so.) I was able to put in a trial license and everything seems to be working fine. It says it is good until the 27 of June, which should be more than enough time to get a new license purchased and installed. Thank you again for keeping us running!

That does indeed have the info. Thank you!

Hi @Stephen-Schaff, I was finally able to recreate this error and I believe I fixed it in PG-1948. This is set to be released on Friday in ProGet 5.3.28. If you would like to apply the fix now, I have attached a SQL script to PG-1948 and you can run it against your ProGet database. If you run this script, it will not affect future upgrades of ProGet. Thanks, Rich

Hi @Stephen-Schaff , We already have "Personal API Keys" coming, so I think this will address those concerns. The User Impersonation is really only used by the "Feed API" Endpoints anyways, and the only "problematic" endpoints might be "Feed Management API" (they could delete feeds) or "Native API" (they could do anything). Otherwise, I think this would best be handled by training and documentation. Perhaps just a warning to put on the Create API Key page? We've learned the hard way that advanced settings like this are really hard to support -- everyone forgets they exist (including support team). steve

Hi @Stephen-Schaff , Thanks for the suggestion! So we had considered the "auto-generated one-time key" in our initial design, but decided against it for several reasons. This enables the less-secure "API Key Spreadsheet Antipattern" - basically people want to store keys they generate -- and since the software doesn't allow it, they go this route. It's the same problem with "change your password every 30 days" policies that create easier-to-guess passwords. This tends to create a lot of stale keys due to a fear to delete them. Administrators can "back-up" the API Keys if they can see them, and add-them back if cleaning up causes a problem. Allowing keys to be entered allows users to more easily migrate from one instance to another - just do a DNS change, and all old automations /old keys will work fine. API Keys are similar to passwords, but different; passwords are entered by a human to log-in, and in theory should only be "in that human's head" -- where as API Keys are always entered somewhere (usually in a script). In general, in ProGet, we recommend keeping API Key as limited as possible. This simplifies things for everyone. There's no practical security problems in allowing all users to publish packages to feed.... you should be using package promotion to test/verify packages anyway.