@aslepikas_5779 said in docker pull from proget not working:
I updated to 5.2.25 where PG-1669 was fixed. This still appears to be an issue, same warning as above, only difference is the User Agent field
User Agent: docker/19.03.3 go/go1.12.10 git-commit/a872fc2 kernel/4.4.0-165-generic os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.3 \(linux\))
Is the stack trace actually empty? If not, it would be very helpful in tracking down this bug.
Hello @aslepikas_5779 and @jyip_5228:
It looks like this happens in the processing of the Authorization: Bearer anonymous header. I've filed PG-1669 to fix this.
Hello @jyip_5228,
Anonymous Docker feed access is supported, and a 500 response is (almost) always a bug.
In the ProGet advanced settings, you can set Diagnostics.FeedErrorLogging to the Docker feed's numeric ID and it should give more information about the failed request in the diagnostic center.
Hello @Adam,
What you are doing is correct; this is a bug in the Windows extension.
I've filed inedox-windows#76 to fix this.
Hello @tdean_3904,
This appears to be because the Docker extension doesn't create its own working directory automatically. To work around this, add the following operation call right before the Docker operation:
Ensure-Directory
(
Name: $WorkingDirectory
);
Hello @PhilippeC,
Thanks for the repro case. I've filed this as OT-355.
@James-McAllister_0459 said in deleting docker images via REST API:
Is there any way to get the published date or created date of the image from a REST api?
The Docker API in ProGet doesn't (currently) return a Last-Modified header, but depending on which date you want, it can still be accessed:
Published date can be accessed via the native API using the tables you identified. However, this API is generated directly from internal ProGet database procedures, so this may break in the (unlikely) event that ProGet's Docker database structure changes.
Created date is a property of the image, which is embedded in the manifest's config field. Inside the JSON blob referenced by the manifest, the creation date of the image is in a field named created. This is optional in the Docker specification, but if you're building your own images, it should always be present.
Hello @James-McAllister_0459
For the API key, use HTTP basic auth with api as the username and the API key as the password. You can also obtain a token via the Docker auth flow, but that's much more complicated.
The manifest must be deleted by digest, not tag, so the URL should have /manifests/sha256: in it rather than just /manifests/ followed by a tag.
Hello @pcoombe_0297,
You can use api as the username and an API key as the password for any feed API supported by ProGet.
The auth format is HTTP Basic auth, so you'd prefix the API key with api: and then base64-encode the result.
You can also log in interactively via the npm login command. If your ProGet username cannot be used as an NPM username (such as a qualified domain user), ProGet will also accept the username via the email field.
While investigating a way to add dates to the file, I discovered that the Release file is malformed.
I've filed PG-1596 to fix this, which should be in the next maintenance release.
Hello @gravufo,
This is only a warning, not an error, so the Debian feed's packages should still be accessible from apt.
The reason we don't have a Date entry in the Release file is that Date represents when the Release file was last generated, and ProGet generates the Release file for each request.
This would be fine if everything used the InRelease file, but a lot of tools still access Release and Release.gpg as two separate requests, so the signature would very likely be for a different file than was downloaded.
We decided against putting the Date in the InRelease file only because having InRelease and Release be two different files might cause hard-to-diagnose problems down the road. Date is documented as optional, so the file is still technically correct and the warning can be safely ignored.
Hello @Jonathan-Engstrom_2384,
This is what the server list will look like with OT-348 as viewed from the Undrifted-Role role.
Hello @yafeng-wu_3838
I checked the second image and your ProGet instance definitely has all the layers for that image available as blobs.
However, I noticed that the manifest was version 1, and version 2 of the manifest format was added with Docker v1.10.0 (released in 2016). Is the Docker client running on that machine very old? I'm wondering if this is related to the Content-Type header ProGet is sending causing the client to be confused.
Hmm, I'm thinking it might be better to have each individual configuration available via some API.
The ServerConfigurations_Extended view contains many useful fields, so until that API is designed implemented, querying that directly can probably support your use case.
Hello Ali,
The agent version is not shown in BuildMaster 5.x's server overview page, but you can view it by going to /administration/service-status and forcing a run of the AgentUpdater executer and then checking the log for something like Connected to localhost:46336 (v39.0.0.2); checking status... (in this case, the agent on localhost is v39.0.0.2, the version of InedoAgent distributed with BuildMaster 5.8.3)
Hello Mickael,
ProGet does not support SSL on its own. However, if you have a reverse proxy like Traefik or nginx, you can terminate SSL in the reverse proxy and forward the connection to a locally-bound HTTP address.
Here's the documentation for setting up SSL Traefik and nginx:
https://docs.traefik.io/user-guide/examples/#http-https-with-sni
https://nginx.org/en/docs/http/configuring_https_servers.html
Here's what I currently have that is working; I'm running ProGet 5.2.0 on Windows with the self-hosted (non-IIS) web server. SSL is using Let's Encrypt; nginx is running on a Linux machine.
server {
include /etc/nginx/lubar.me-shared.conf;
server_name proget.local.lubar.me;
server_name proget.lubar.me;
# CSP header removed for brevity; irrelevant to this issue
client_max_body_size 0; # disable any limits to avoid HTTP 413 for large image uploads
# required to avoid HTTP 411: see Issue #1486 (https://github.com/dotcloud/docker/issues/1486)
chunked_transfer_encoding on;
location / {
if ($lan_ip = 0) {
limit_rate_after 200k;
limit_rate 50k;
}
proxy_pass http://proget-upstream;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_set_header Accept-Encoding '';
proxy_hide_header X-AspNet-Version;
proxy_http_version 1.1;
proxy_buffering off;
proxy_request_buffering off;
proxy_connect_timeout 1m;
proxy_read_timeout 1h;
proxy_send_timeout 1h;
}
}
It looks like the current issue people are facing might be related to something specific to the Docker version of ProGet. I will investigate this.
Hello Marko,
The SqlServerDsc package's manual download gives me a version number matching the one in ProGet (without the extra .0).
I will investigate the "central directory" error. It seems like it may be caused by another error while ProGet is serving the file.
I'm going to guess this is related to ProGet's symbol handing code. If you don't need symbol stripping, disabling it on the Linux NuGet feed might be a good workaround.
Update: I was not able to reproduce this with the latest ProGet Docker version (5.1.22). It may have been fixed by some other change.
Hello Neil,
When I download that package from the PowerShell gallery, it has the version number 12.2.0 (not 12.2.0.0 as is shown in the UI).
I'm not sure where the extra .0 is coming from.
Hello Eric,
I think Docker requires at least one . in the hostname, and it's trying to access the default Docker hub.
Another way that might work would be to add the port number to the hostname:
<server name>:443/<feed name>/library/redis
(the library part is optional to match the Docker hub, so <server name>:443/<feed name>/redis should also work)
Hello Scott,
This is done for 1-part repository names to match the behavior of Docker Hub.
You should still be able to access the container without library/; that is, this should also work:
<proget_server>:80/<container_feed>/<container_name>:<tag>
Hello Ryan,
Sorry about the delayed response.
The Push to ProGet Visual Studio extension is for Universal (upack) feeds, not NuGet (nupkg) feeds.
Hello Ta,
I was unable to find any mention of what metadata keys the Docker Hub looks for for those values, but I've filed PG-1443 to display all labels without any special formatting.
Hello Martin,
I've filed PG-1422 to stop ProGet from checking whether anonymous users have any feeds they can access. You may also want to check in SSMS whether any of the indexes need to be rebuilt or reorganized.
Hello Adam,
I've filed PG-1409 to allow setting a password on a connector with a blank username, which will allow bearer tokens to be used in npm.
Hello Philippe,
If the example code is identical to what you're running, the 10GB is misspelled as 1OGB (with the letter O instead of a zero).
Hello Jon,
I've released version 1.0.2 of the Jenkins plugin to fix the build never being found, and it appears to work properly with importing assets as well.
Hello Jon,
project/job/jobname should still work.
It appears that the code to wait for a build to finish is getting stuck:
Queueing build in Jenkins...
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Posting to http://jenkins:8080/job/project/job/jobs/build...
Jenkins build queued successfully.
Queue item number: 1
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Waiting for build to start... (In the quiet period. Expires in 2.8 sec)
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Waiting for build to start... (In the quiet period. Expires in 0.62 sec)
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Waiting for build to start... (???)
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Waiting for build to start... ()
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
Creating HttpClient with username ben...
Retrieving CSRF protection header value...
I'll try to find the root cause of this.
Hello Jeremy,
It seems that the Maven feed code in ProGet is incorrectly identifying all prerelease Maven package versions as snapshot versions.
I've filed this as PG-1380.
Hello Michael,
Does the feed have a connector for https://www.powershellgallery.com/api/v2? You can check the connectors attached to a feed from the Manage Feed page.
If the PowerShellGet package was cached from a connector and the connector was subsequently deleted or disconnected from the feed, the package will still show that icon.
Hello Boubacar,
There have been a lot of changes to Docker feeds in ProGet 5.1. Does pushing the Windows image work on a newer version of ProGet?
Hello Antoine and Anton,
I've filed this as PG-1376.
Hello Florian and Antoine,
I've filed this as PG-1376.
Hello Jan,
I've filed PG-1350 to improve the error message when no connector successfully returns a manifest.
Hello all,
ProGet 5.1.7 fixes an additional issue that was causing SemVer2 NuGet packages to fail to download: PG-1329
Update: I've filed this bug with Docker: https://github.com/docker/distribution/issues/2649
When I view the data being sent between ProGet and the Docker client, there's a HEAD request that would normally return this body:
{"errors":[{"code":"UNKNOWN","message":"Could not resolve ProGet feed \"docker\". Docker repository names in ProGet must include the feed as a prefix. Example: MyFeed/library/ubuntu","detail":[]}]}
However, because it's a HEAD request, Docker doesn't receive any body.
Hello Hamza,
I am able to reproduce this and I've filed PG-1317 to fix it.
Hello Steven,
Try visiting this page in a browser: http://<ProGet hostname>/feeds/<feed name>/NuGet.Frameworks/4.7.0-rtm.5148
There should be an error message like this:
The version number provided is invalid, but would be valid if this NuGet feed were migrated to SemVer2.
You can migrate a legacy NuGet feed to SemVer2 by clicking the button at the top of the feed management page.
Hello Frank,
Are the remaining packages marked as Package Source: Remote Connector (cached) in the left sidebar?
Hello J,
ProGet assumes it's in a schema named dbo. By default, that's what SQL Server uses. To change the default schema back to dbo, run this command:
ALTER USER [proget] WITH DEFAULT_SCHEMA [dbo]
Hello Pedro,
Docker feeds appear to have been missed when the api user was added for feed authentication. I've filed PG-1295 to fix that.
ProGet 5.1.0 is not released on Docker Hub, but you can build the image locally with this command:
docker build -t inedo/proget:5.1.0 --build-arg PROGET_VERSION=5.1.0 github.com/Inedo/proget-docker
Hello Tony,
I've filed PG-1294 to fix this. As a workaround, you can access the package directly by version number even without this fix.
Hello Tom and Brett,
The endpoint being requested seems simple enough. For example, here's what it requests for -StartWith Inedo..
I've filed PG-1281 to add an implementation of this endpoint.
Hello Timofey,
I've filed PG-1280 to hide the build metadata from NuGet version numbers when they are displayed in titles.
Hello Ludovic,
This appears to happen when there is no version of your package tagged as latest. To fix it, click the Edit Details button on the latest version of your package and add a tag named latest (all lower-case).
I've filed PG-1279 to fix this happening in the first place.
Hello Jasper,
I don't have a Linux installation of ProGet in front of me, but it's possible that this would work if you renamed the feed to dspdocker (with no capital letters).