administrators

Hi @michael-day_7391,

What version of Windows Server are you running?

When generating that command, ProGet will call Environment.UserName to determine the username the service is running as. I'm guessing this is returning the computer account instead of NETWORK SERVICE. I have crated a ticket, PG-3219, to review it, but I would like to test it on the same version of Windows Server as you.

Thanks,
Rich

Hi @daniel-pardo_5658 ,

This behavior is expected; the UI is meant for creating basic, case-insenstiive archives.

As for the permissions.... File metadata (including owner, execute permissions, etc) are stored within the filesystem (or as metadata in a zip file)... so once you transmit a file, that information is irrevocably lost.

Best to upload a package file.

Cheers,
Steve

Hi @daniel-pardo_5658 ,

Thanks for the suggestion; Universal Packages already support tags in the package manifest file: https://docs.inedo.com/docs/proget/feeds/universal/universal-packages#manifest

Otherwise, if you're referring to "tagging" a package already added to a feed - that's a hard pass :)

The reason is that a package is designed to be self-contained (i.e. all the metadata about the package is stored within the package) and cryptographically sealed (i.e. so you can't edit/mutate a package). Tags break these, as they apply semantic metadata outside of the package.

These have caused big issues in ecosystems that have tried them (like npm) - but long story short, there's a good reason they don't exist and there's most certainly a better way to accomplish what you're trying to :)

Cheers,
Steve

Hi @geraldizo_0690 ,

Nice find with the busybox image... that makes it a lot easier to test/debug on our end!!

We already have a ZST library in ProGet so, In theory, it shouldn't be that difficult to use that for layers like this. We'll add that via PG-3218 in an upcoming maintenance release -- currently targeting February 20.

Thanks,
Alana

Hi @michael-day_7391,

The docs say to use NETWORK SERVICE because that is the default account ProGet users when it's installed. You need to use the username of the account that the ProGet service is running as. If your ProGet service is running as MYDOMAIN\PROGET-SERVER$", then your netsh command should use that. If it is using NETWORK SERVICE, then you should be use NETWORK SERVICE. If you want to switch to a different username, then you need to first remove the urlacl by running the following, then re-add it with the correct name.

netsh http delete urlacl url==https://*:443/

The event viewer error Windows event viewer shows event id 1000, can be ignored. That is a default message that shows because we configure the URL binding in code.

The netsh http add sslcert command should only be used when you are using a haostname binding, since you are unsign *:443, you should not need this.

While you are working through this issue, I would change UseHttpsRedirection="True" to UseHttpsRedirection="False" in your config so you can still access the site over HTTP until you get this figured out. The ERR_CONNECTION_CLOSED message typically indicates an issue with the certificate binding. The most common issue that can cause this is when the permissions are incorrect on your certificate.

1. Open the Certificate Manager using Window's MMC
2. Navigate to Certificates (Local Computer) -> YOUR_STORE (ex: Personal) -> Certificates
3. Right click on the certificate and select All Tasks -> Manage Private Keys
4. And give read access to your service account

See more in our Troubleshooting guide.

Can you verify the permissions on the certificate?

Thanks,
Rich

Hi @geraldizo_0690 ,

Are you seeing any errors/messages logged like, Blob xxxxxxx is not a .tar.gz file; nothing to scan.? If you go to Admin > Executions, you may see some historic logs about Container scanning.

Thanks,
Alana

Hi @Sigve-opedal_6476 ,

Could you give some tips/guidance on how to repro the error? Ideally, it's something we can see only in ProGet :)

It's probably some quirk in how they implement things, but I wanted to make sure we're looking at the right things before starting.

Thanks,
Alana

Hi @scusson_9923 ,

That is an internal/web-only API url, so it wouldn't behave quite right outside a web browser.

I can't think of an easy way to accomplish what you're looking to do.... if you could share some of the bigger picture, maybe we can come up with a different approach / idea that would be easier to accomplish.

Thanks,
Alana

Hi @certificatemanager_4002 ,

I'm sorry but I'm not familiar enough with Kubernetes to help troubleshoot this issue.

All that I recognize here is the upgradedb command, which is documented here:
https://docs.inedo.com/docs/installation/linux/installation-upgrading-docker-containers#upgrading-the-database-only-optional

If you run that command from the command-line (on either linux or windows), things will written to the console. I wish I could tell you why you aren't seeing the messages.

Thanks,
Alana

Hi @caspacokku_2900,

I apologize for the confusion. I meant that running through the test example you provided (looks like that comment has since been deleted) and this new one, I was unable to recreate both the PostgreSQL errors and the "The given key 'version' was not present in the dictionary." error. I'm thinking the dictionary error is related to either the PostgreSQL errors or a hiccup in the network connection where the response was not fully returned, but had a successful response code causing the request to still be cached. What is also confusing is that the cache should refresh the request after 30 minutes. This means if the caching is causing the issue, it should resolve itself within 30 minutes. Also, I see you have set the metadata caching to 100, which cargo hits pretty quickly. I typically set that to 1000 requests in a crates.io connector because cargo is a very chatty client.

The main reason I was asking for a reproduction case is that I wanted to rule out an error in parsing the cargo metadata. With this latest test case you provided, I can verify that everything appears to be parsing correctly. I ran this build 30 times back to back with your settings and connector caching enabled (both metadata and crate caching). In between each build, I cleared the local registry cache and ran cargo clean. I was not able to reproduce these errors or cause issues with the connector cache. This leads me to believe that there is an environmental factor that is causing this issue. Can you please check with your IT team to see if there is anything they are seeing (external HTTP request manipulation, network packets dropping, RAM correction errors, etc..) on your server?

Thanks,
Rich