Hi @aries66_2180, I just set up a clean ProGet 6.0.16 docker instance and tested this and it seems to be working for me. Can you send me an example image you are trying to push that fails? Also, would you be able to use a tool like WireShark or Fiddler to record your requests when trying to push an image and email it over to us at support@inedo.com with a subject of [QA-878] Docker push error? Thanks, Rich

@atripp that's extremely informative! What I found this morning that was deleting and re-adding the connector for the IP feed after clearing the cache(because I'm paranoid) was what needed to happen for it to stop being cached by our Mainline feed.

@atripp Thanks for the reply! I am not aware of any additional pipelines with that same name, but will do some digging and see if I can find it. Thanks for checking.

Thanks for the quick action and the extra information. Did not realise conda build was making the check itself. We're going to install the new version and give it a try. Happy to help and make Proget better

Actually, in our case, broken files are stored in the ProGet storage on a disk, I checked them during the investigation. So it's not an issue that happens on the fly during the download process. And it's also not an issue that happens during package uploading, since after uploading, packages are valid and identical to the original ones on downloading and in the feed's storage. Maybe, those packages were broken in the feed's storage a relatively long time ago for some other reason (a bug in earlier versions of ProGet? a bug in our infrastructure?). And the issue starts to be observable only now because of caches or something like that... At this point, thanks to your answers, it seems that ProGet is not the one to blame. So, I ran a script yesterday that found all the broken packages in the feed, downloaded them from nuget.org, and republished them to ProGet. It was about 100 packages overall. Now I'm sure that every package in our feed is valid. I'll keep monitoring the feed, and if new broken packages arise in the feed, I'll continue the investigation and let you know if ProGet is somehow related to the issue. Thanks a lot, @atripp!

@atripp you're the best. I'll give these a shot and come back if i run into something i can't work through.

Thanks @rhessinger!

@rhessinger Thank you for this, it worked. I was able to successfully login and setup new users and privileges etc.

Thank you @atripp !

Hi @karsten-meichsner_9039 , Oh wonderful! If you're able/interested to try it out, then we should easily be able to add a checkbox in the UI for it and send you a patch/prerelease to try. That's how many of the other options got added Alana

Hi @karsten-meichsner_9039, I haven't seen that error before, but based on the text ("ProxyAuthenticationRequired for layer"), I think that Clair is trying to download an external layer? Some container image manifests (especially Windows, but not entirely) will point to a URL outside of the registry. This is often done for licensing reasons. What this means is that, Clair (or the docker client) downloads the layers from a url instead of ProGet. I'm not familiar enough with container scanners (Clair) to know how they search for vulnerabilities; I believe it's done by looking at the packages installed on the system. Log4j is not a package installed on the system (I think), but a library used in some applications. Cheers, Steve

Hi @james-traxler_1560, I'm not really sure I totally understand the issue, or how to resolve it... but I'll explain how a GET manifest request to your URL would work. Basically, ProGet returns whatever manifest file you uploaded, or whatever was downloaded via the connector. We do not generate the manifest files, or pay attention to the Accept request header. I understand that application/vnd.docker.distribution.manifest.list.v2+json is a "fat manifest", which is basically a manifest that points to other manifests on different architectures. So you don't know exactly what image you'll get until you install it on the machine. So if you want to inspect layers, you would first need to decide which manifest to use, I guess Cheers, Alana

Hi @marc-ledent_9164 , This isn't something that our LDAP/AD integration supports on Linux at this time. It's possible using the Windows-version, which has an LDAP integration that uses different libraries (that only work on Windows). We do plan on rewriting the LDAP/AD integration with a different library, as to allow this level of customization, but it's not something we can do right away. It'll be later this year. Cheers, Alana

@atripp said in ProGet doesn't log package publisher from command line: 6.0.16-rc.1 It's working Thanks alot

Hi @gurdip-sira_1271, Yes, this will be released with Otter later today. Thanks, Rich

Hello We are not experts in Powershell and we discovered DSC at the same time and thanks to Otter and we thought it was great and that they integrated perfectly. Knowing that DSC may not have continuity we will be attentive to the news, especially with Powershell Core. Thanks to the alternatives you have given us to DSC, we will modify our scripts and continue testing and studying Otter, because it seems a very good tool for us. Thank you and greetings

Hi @Joseph-Saladino_7499 , Hmm, that's really weird; the next thing I would try is to just restart all the machines (including the BuildMaster server). That's easy to do and the issue might go away. It could be a software error in the Windows networking stack It's possible that there's some intermediate network device that's interfering. Router, QoS device, etc. That's harder to diagnose, and would require some tracing ... starting by making sure that the RST packet is actually being received on the BuildMaster server (that's usually what indicates the error message), and then figuring out what device is sending it, and why. Our code doesn't work at the packet-level, but if the remote server (Inedo agent) is where the RST packets are coming from, it likely has to do with some obscure Windows setting... maybe even firmware on the network card. But at least something to look at. Cheers, Alana

Thank you I have moved my server from 2012 R2 to 2022 and the issue is resolved now Thanks again for quick reply