Posts made by atripp

Thanks @certificatemanager_4002 -- that will definitely work if you're using inedodb (i.e. settting up a cluster), though for using a single-server instance, inedodb isn't recommended.

@Sigve-opedal_6476 I'm not super-experienced at Linux myself.... but if the container is stopped, then you should be able to just move/copy the files. The container must be able to read the files -- I do know there's some kind of permissions/user error when things aren't set right.

I'd share the database error when you restart.

Hi @certificatemanager_4002 ,

We do not recommend using a multi-server / clustered installation for the database server; for an application with a profile like ProGet, it's significantly slower, less reliable, and ironically, has lower availability.

Instead, in the unlikely event that your physical database server "goes bad", I would just do routine backups and be prepared to "spin up" a new server from backup ASAP.

Thank,
Alana

Hi @michael-day_7391 ,

It looks like this was an oversight, and this value cannot be configured. However, we will fix that via PG-3203 in the upcoming maintenance release on Friday.

Thanks,
Alana

Thanks @davidroberts63

I looked into this a little more, so just as an FYI...

• Terraform Modules are relatively simple templates for code/configuration that you write and maintain (think of it like a Helm chart)
• Terraform Providers are executable files invoked by Modules, and many of them simply embed and wrap a CLI tool; the most popular providers are AWS, Azure, GCP, but there are many niche ones by other vendors

No one really writes their own Terraform Providers, and it's highly unlikely you would ever do that. They should be thought of as SDK/CLIs you downloaded from a marketplace... except they run as admin/root and have your most "sacred" credentials.

So just to clarify... you can currently host Terraform Modules in ProGet and you can also most certainly host Terraform Providers in ProGet (just using an Asset Directory). The question comes down to user experience and convenience.

The issue here is that Terraform Providers do not fit into ProGet's "package" or "connector" mindset; so it's not just a new feed type, but creating a whole new feature in ProGet that won't really work like other feeds.

We were able to "force" Terraform Modules into Packages/Feeds... but as you can see, it requires a lot of hoops to jump through, since Terraform is a "terraform.io-first" tool. However, many users create their own Modules, so it adds a lot of value.

The same isn't true of Providers. From a "proxying" standpoint, high-control organizations would likely not want to "proxy" the Terraform Registry for Providers -- it's way to much risk, considering anyone can just upload whatever they'd like.

Instead, they'd likely have a review process for adding and upgrading providers. And once that's in place.... how much time are we saving by using a specialized feed type over an asset directory?

I don't have the answer to that --- but that's what we're considering :)

Thanks,
Alana

Hi @michael-day_7391 ,

Unfortunately AD/LDAP issues can be pretty challenging to troubleshoot and debug. I can give you a few general tips, but this is one of those things where there are no useful logs -- it's like trying to diagnose why you're getting a timeout doing an HTTP request. The real issue is somewhere down the line.

Assuming you're able to connect to the LDAP Server (Domain Controller in this case, it sounds like), the most common is permissions. This can get really painful, because it can be incredibly granular - an account can be allowed to enumerate groups, but not bind to specific users (i.e. do a login). Other times, it's related to multi-domain / complex forrests, and things like misconfigured trusts.

For security reasons, the AD/LDAP server never really tells the client what's wrong -- that's why you won't see anything useful in ProGet. You have to look at logs on the sever to find out what the exact issue is.

If those aren't easily accessible, my advise is to keep "playing around" and perhaps try the LDAP/OpenLDAP directory, which is basically just "raw" LDAP queries. Or try V5 vs V4, etc.

Here is the source code, if you're curious to see what's going on behind the scenes:
https://github.com/Inedo/inedox-inedocore/tree/master/InedoCore/InedoExtension/UserDirectories/ActiveDirectory

Agan, the server logs (LDAP/AD Server, nt ProGet server) are going to be the best place to look for queries and issues.

Hope that helps,

Alana

Hi @tyler_5201 ,

Sorry I really don't know what "squashing" or "101:0" permissions mean, so I don't really know what the issue is.... but I did read "this does work" and then saw you asked a question which I didn't quite understand

What I can say is that ProGet needs to have "full control" over the database, package, backup directories. That's not something we could reasonably change... and I don't know if you're even asking that.

Otherwise, we also have a pretty basic Docker image configuration (Dockerfile), and obviously making changes comes with risks. Before considering those changes, we would need to really understand what kind of value/benefit comes out of this and what kind of changes are involved here.

Thanks,
Alana

Hi @mikael ,

Thanks for the additional insight.

The use case you describe (offline/air-gapped usage of Terraform) does seem rather niche, and is different than the traditional "proxying" use case we describe. Very few organizations will restrict internet access like that, and Proxying is more about controlling versions and limiting what developers are able to use.

Anyway, it may not be a good fit for investment on our end. But we'll see if anyone else joins this thread :)

That said, a Provider is basically just a executable file in a zip file. I wonder if you could simply use Asset directories somehow.

Thanks,
Alana

Hi @jw ,

We added "auto-publish Inedo.ProGet" to our internal tracking list -- and in theory it will be done in the next week or so. I think we meant to do that earlier but it just fell off the list.

Thanks for pointing that out - please don't hesitate to bug us if you don't see it published next time :)

Thanks,
Alana

Hi @wechselberg-nisboerge_3629,

In ProGet, the maven metadata files (xml, hash) are indeed generated upon request. The output is deterministic, based on the artifacts in storage and (if relevant) in the remote repository (i.e. connectors). So, if you're seeing it changed, it's because an artifact was uploaded/etc.

One thing to note -- you cannot upload a metadata file or hash file. Well, you can try (and maven tries) to PUT the file, but the stream is always ignored or "written to /dev/null" as they say.

We've seen some maven workflows/plugins that attempt to modify/append to this metadata file and re-upload it with changes.

Thanks,
Alana

Hi @it_9582 ,

Thanks for the additional information.

The reason this is happening is because these endpoints do not return a WWW-Authenticate: Basic ... header value when responding with 401.

This behavior intentional, as our preferred authentication is using an API Key header value, not Basic credentials. Basic is an alternative option and can be used when you can't easily pass a header.

We are not willing/able to change this behavior, as it would require changing code on a substantial number of endpoints and may break user integrations that have been relying on existing behavior.

So I'm afraid this means you'll need to do one of the following:

• add the --auth-no-challenge option
• use wget --header="X-ApiKey: <api-key>" "<Download path>" instead
• use curl instead
• use pgutil instead

Cheers,
Alana

Hi @aristo_4359 ,

I assume you are referring to npm packages? And that you are using the /packages page and not the Feed page?

This behavior seems a bit quirky, but expected. The /packages page does not have any special logic for handling package-specific types - and the "search" is more like a "filter". In npm, the @ symbol denotes a group (namespace), and the / symbol is the separator between a group and name - and this is why you get this behavior.

Hope that explains the behavior a bit! It's not ideal, but a limitation for performance, etc.

Cheers,
Alana

Hi @it_9582 ,

Unfortunately I'm not really sure what your script is doing or how to fix it... but I will describe the server (ProGet) behavior.

Unless you allow Anonymous access on the endpoint, ProGet will respond with a 401 when you access a URL without any authentication information (API Key header, Basic credentials). That's what the message you are sharing appears to do.

So if you're getting that message, then I guess the username/password isn't being sent? I really don't know what --auth-no-challenge means or does.

Thanks,
Alana

Hi @it_9582,

I'm afraid this requires a code change and an external database will have no impact.

Thanks,
Alana

Hi @it_9582,

It's certainly possible :)

However, given the risk associated with the change, it could only happen in a Major Release. This would require editing a lot of code and trying to track down everywhere we might have trimmed/restricted to 200 characters.

I can add it this to our roadmap for consideration, but note that ProGet 2026 hasn't been targeted for a date yet, let decided what features we'll do.

I just want to be realistic about the timeline - let us know if you'd like to consider it. It hasn't come up in the very very many years this feature existed, so we're not even totally sure if we'll do it (if it's too much code / too much risk / too close to the deadline / etc).

Thanks,
Alana

Hi @Julian-huebner_9077,

This error is occurring while ProGet is trying to generate the "base url". There are a few inputs that go into this:

• Admin > Advanced Settings > Base URL
• X-Forwarded Headers, set by a reverse proxy like ngnix

If any of those have an invalid host name (which is what the error is indicating), then you'll get this error. In most cases, it's a typo in the X-forwarded headers.

Thanks,
Alana

Hi @dwynn_6489 ,

I was able to reproduce this issue; the issue is that the package's license declaration specifies a license file of package/license.txt, but that file does not exist in the package.

We will improve this error message via PG-3199 in the upcoming maintenance release, but in the meantime, the only workaround is to manually assign the license under SCA Licenses. The new version of ProGet will include a direct link to that page for convenience.

The Purl you'd need to add is as follows:

pkg:npm/%40progress/kendo-charts@2.9.0

Hope that helps,
Alana

Hi @it_9582 ,

I'm afraid this is a long-standing (since we first introduced the feature) limitation on the name. It's not changeable/configurable and would require a nontrivial code change to lengthen.

Thanks,
Alana

Hi @spencer-seebald_1146 ,

I was able to identify the issue.

When you visit the URL in ProGet, then ProGet will visit this URL (slightly trimmed) with the appropriate authorization header:

https://libraries.cgr.dev/javascript/..../lodash/-/lodash-4.17.20.tgz

However, that URL will issue a 307 redirect to the following:

/artifacts-downloads/javascript/namespaces/15f7d141c3b76b85/repositories/.../downloads/ABmYrfCH......KpxO1ducu3xmMRtw==

ProGet then follows the redirect, but does not send the authorization header. And thus, a 401 is issued. This is actually the default/expected behavior in HttpClient (i.e. the library in .NET we use) and most clients in other languages (Java, Go, Ruby, etc.) as well.

Of course it can be worked-around by disabling auto-redirect and implementing yourself to follow the URl with the same header. But that's not so common and, as such, it's not a common practice for servers to issue redirects that require authentication; we see other services handle the redirect using some kind of token in the querystring.

On our end, this has not been an issue to date. This is logic is buried pretty deep and it's not an easy fix without changing code everything relies on. I'm kind of surprised npm and pip override the default behavior in the fetch() and requests libraries.

Anyway, it sounds like you can make a change on the private repository server code... so I would here would be to just disable authentication on your artifacts-downloads endpoint. I mean that URL is basically authenticated anyway.... it's so long (I stripped like 1000 characters) that it's basically a password.

Thanks,
Alana

Hi @jlarionov_2030 ,

PG-3133 (which allowed pgutil settings to run without a license key) was applied to ProGet 2025.12 so I don't think it could have worked in ProGet 2024.39.

There were also no changes from ProGet 2025.12 to 2025.18 that would have caused this, and it works fine for me.

Are you sure you're running the pgutil settings command first to apply a license key?

Just based on the logs, it doesn't say...

Thanks,
Alana

Hi @aristo_4359 ,

This will happen from time to time and there's no great solution to fixing it.

The underlying issue is simple actually; the source data is incorrectly coded, and systems like PGVD that rely on that will display incorrect results.

Since sources routinely update data (and they may fix this... if you ask), PGVD will also update the ingested data. So it becomes quite complicated to try to "override" incorrect data, even though it's so obvious from reading the description and looking at it.

Without getting into too many details, here is how they encoded this at the source:

"database_specific": {
   "last_known_affected_version_range": "< 0.19.3"
}

Compare this to another vulnerability at the same source, and you will see this is the correct encoding:

{
   "last_affected": "2.0.13"
}

Given the infrequency that this happens, and the fact that it's an old, low-risk vulnerability (we would rate this as a "2 out of 5" on our upcoming scale FYI), we don't think it's worth worrying about.

Thanks,
Alana

Hi @spencer-seebald_1146 ,

Thanks for putting all the details together, this is really helpful! In theory, what you're doing should work... and I don't know why it's not. But it sounds like it'd be "trivial" to reproduce in a debug environment, so let's start there :)

All we really need are credentials. It looks like your end-user opened a ticket on this issue as well (EDO-12512), so I will just add your email to that ticket and respond there with the same request.

Once we have credentials, we'll try reproducing/fixing and hopefully get this working in no time :)

Cheers,
Alana

Hi @geraldizo_0690 ,

Thanks! And we appreciate your ideas/suggestion and detailed guidance on how to implement it.

It seems really simple and should be available in the upcoming maintenance release (next Friday) via PG-3196 -- we can also let you know when a prerelease is available if you wanted to try it sooner than that.

Cheers,
Alana

Hi @jonathan-werder_8656 ,

We actually don't have any Azure-specific recommendations (or Amazon, GCP, or any host really) -- so just the normal Windows or Linux (Docker) guidance would apply.

Happy to clarify that in the docs if you can think of a good pace to put that :)

Thanks,
Alana

Hi @jonathan-werder_8656,

Oooh that's definitely outdated, thanks for pointing that out! Perhaps we should just delete that article.... but I'll see if we can salvage it.

If you're setting up a new instance of ProGet, that article is not for you -- that's helping you migrate an existing instance. For a new instance, I would just do a standard Windows or Linux installation (use the Embedded database in either case) - there's nothing special about Azure.

For migrating... at this point (i.e. ProGet 2025+), I would just set-up ProGet on the new server using PostgreSQL (the default configuration). Then, export your database from the old server and import it into the new server.

You'll have to deal with the Package Files as well, which is discussed in this (slightly outdated) Migrate an Existing ProGet Installation to a New Server article.

Anyway we'll add these to the list, but let me know if you have any questions in the meantime.

Cheers,
Alana

Hi @rie_6529 ,

There is not -- this is not an action that should be performed regularly at all. It's more a troubleshooting thing that should only be done after some data problem.

If you find yourself having to run this often, it's indicating there's some other issue. In years past, no one really noticed this (and it didn't have any side-effects), but since we added Integrity Checks, the bad data is a lot more visible.

So it'd be best to troubleshoot that and see if we can correct it.

Thanks,
Alana

Hi @jeff-williams_1864 ,

We do not provide instructions/guidance for installing ProGet on Kubernetes / OpenShift. However, since it uses Docker behind the scenes, it is supported and works fine, and many users deploy ProGet to Kubernetes.

Here are the instructions for Docker:
https://docs.inedo.com/docs/installation/linux/docker-guide

Let us knkow if you have any questions or run into any issues/difficulties.

Thanks,
Alana

@jonathan-werder_8656 great point, we'll add that to our list to document! Thanks for pointing it out

Hi @koksime-yap_5909 ,

As long as the cluster can access the internet (our activation server), the license key should be auto-activated without noticing. This document explains the activation process a little further:
https://docs.inedo.com/docs/myinedo/activating-a-license-key

Help that helps,

Alana

Hi @kquinn_2909 ,

The "Recent TeamCity Builds" page should show a list of builds in the selected TeamCity project; it's a bit tricky to troubleshoot, but BuildMaster is essentially querying for builds using this locator string: defaultFilter:false,project:{Uri.EscapeDataString(project)}&fields=build(id,number,status,state,webUrl,startDate,buildTypeId)

Might be easier to see in the source code:
https://github.com/Inedo/inedox-teamcity/blob/master/TeamCity/InedoExtension/TeamCityClient.cs#L63

I believe the Project ID is being used, which in your case would be WebProjects_Replicator. I think the name would be "WebProjects Replicator". Though I'm not totally sure.

What builds do you see on the TeamCity side of things?

Thanks,
Alana

Hi @jw ,

Thanks for finding this; we'll get it fixed via PG-3180; it was problem when updating the vulnerability database and related to the case matching again. Hopefully this is the last place.

Thanks,
Alana

@kinedax339_3276 great news!! Appreciate the help

Thanks @kinedax339_3276, that was really helpful!

Easy fix to the regex, and I made sure the following work

• http://localhost:8624/cargo/pants/1/a
• http://localhost:8624/cargo/pants/2/cc
• http://localhost:8624/cargo/pants/3/s/syn
• http://localhost:8624/cargo/pants/an/yh/anyhow

Before, the first two returned the same 404.

Anyway this change should be in image 25.0.17-ci.7, which is building now! hopefully this will do the trick

@kinedax339_3276 thanks for checking!

Maybe it's a similar issue.... but honestly I've never used /crate before myself. There's a lot of overhead in figuring all that out for the first time.... so if you can find the URLs being invoked I could probably track it down really easily.

Is ther ea verbose mode we can see that shows urls ?

Here are our internal API notes on the implemented endpoints:

GET /config.json [CargoIndexHandler]
- generates a config.json file
  - "dl" - download URL for crates
  - "api" - API base url for the Web API
  - "auth-required" - boolean indicating if authentication is required to access the registry.
    - This is determined by if the feed has anonymous access for Feeds_DownloadPackage.

GET  /crates/{packagename}/{version}/download [CargoIndexHandler]
- Downloads a crate
  
GET /{prefix}/{packagename} [CargoIndexHandler]
- Downloads basic package version information
- Not true JSON, but each line is a JSON object representing a package version

Maybe it's that last one, with the {prefix} , since those were wrong elswhere. Maybe the matching regex is off?

    [GeneratedRegex(@"^(1-2)/(?<1>[^/]+)$|^(3)/./(?<1>[^/]+)$|^(?![1-3]/)../../(?<1>[^/]+)$", RegexOptions.ExplicitCapture)]

Cheers,
Alana

Hi @kinedax339_3276 ,

It looks like this is an error with the sparse index parsing for short names (e.g. a goes to
https://index.crates.io/1/a, cc goes to
https://index.crates.io/2/cc, syn goes to https://index.crates.io/3/s/syn, etc). Easy fix, we'll get it via PG-3177 in the upcoming maintenance release (Dec 19).

Or you can use the prerelease container image (25.0.17-ci.5) which is being built now.

Thanks,
Alana

Hi @rhowell_8827,

Looking at the code in both ProGet and pgutil, it looks like that simplified upload API only supports the distribution argument. We'll add component in the same manner via PG-3172 in an upcoming maintenance release -- ideally next Friday (should be relatively simple).

Thanks,
Alana

Hi @steviecoaster ,

Nice suggestion; I made a small change and you can now do pgutil apikeys create feed --feed=* to create such a key.

Thanks,
Alana

Hi @steviecoaster , FYI - I just a note to the license restriction page; it looks like we don't mention the restrictions on other APIs (delete, scan, etc), but it's something we'll consider next round of docs refactoring. I know we do call it out on the main documentation pages though.

Hi @steviecoaster ,

The pgutil security features are brand new API endpoints and we haven't had a chance to document them yet. Like other new API endpoints that make ProGet easier to manage, we decided to make the new feature only available for paid editions.

Our product management philosophy is that core functionality (curate open-source packages from public repositories, centrally manage packages and containers) is available in free edition, and others are in paid edition.

Thanks,
Alana

Hi @udi-moshe_0021,

Thanks for clarifying.

In this case, then someone may have disabled package caching on the feed or deleted the package using the "clear cache" button, a retention policy, or manually. That is the most likely scenario here.

There may have also been an error adding the package to the feed (file system error, etc), although those are very rare and would have been logged under Admin > Diagnostic Center.

Thanks,
Alana

Hi @udi-moshe_0021,

I'm afraid we don't have enough information to help troubleshoot, but I'll try to explain how ProGet works behind the scenes.

If you have package caching enabled (the default), then packages downloaded through ProGet will be automatically cached. They will still show up with the "remote" icon, but they will be stored on the ProGet server. You'll be able to tell that they're cached (instead of remote) because there will be a "delete cached package" option.

You can verify this behavior by simply downloading a package from the ProGet UI. It will cache the package. The same link/url is used by the npm client to download a package file.

So why is a package not cached then? The most likely case is that the npm client already had it internally cached, and thus it was never requested from the server. You may also have a scenario where cached packages are deleted with a retention policy.

Thanks,
Alana

Hi @jonathan-erlich_0694 ,

Based on the stack trace, there's something wrong with the data being returned via the API from the remote connector. Specifically, one/more of the version objects being returned is missing a name or version property,

Based on the URL, the invalid data is at the {repository-root-url}/browser-sync. Here's what it's supposed to look like, based on the public repository at least:
https://registry.npmjs.org/browser-sync

Thanks,
Alana

@pmsensi sure thing!

2025.16-rc.1 should be available now.

Here's how to download it:
https://docs.inedo.com/docs/installation/windows/inedo-hub/howto-install-prerelease-product-versions

Hi @pmsensi

Are you able to easily test a pre-release container? I wasn't sure if you're on Linux/Docker, but I just made a code change (PG-3164) that should show up soon as inedo/proget:25.0.16-ci.1

Let me know if you're able to try that -- if you're on Windows, I can push a package for the Ineod Hub to download as well.

Thanks,

Alana

Hi @parthu-reddy ,

This can particular occur when there are some issues with the database, such as outdated statistics or highly-fragmented indexes. This script should help fix this:
https://proget.inedo.com/endpoints/Public/content/DefragmentIndexesWithRowCount.sql

It coudl be something else, but the query that page uses seems to be mostly effected by those.

Thanks,
Alana

Hi @parthu-reddy ,

This error means that PowerShellGallery.com is taking too long to respond to that query. You can try increasing the connector timeout; it's 10 seconds by default. Maybe try 20 or 30 seconds? Just a guess.

Unfortunately the PowerShellGallery seems to be in a state of abandonment these days and it performs really poorly. It's pretty buggy too.

I would consider using a multi-feed, package-approval process to pull packages so you don't have to rely on the gallery's API.

Cheers,
Alana

Hi @jw,

Unfortunately there's no easy way to guess which name is "correct", so sometimes the "wrong" name gets de-duplicated. This also should have no real side-effect, except perhaps seeing the "wrong" casing in some places.

However, as you noticed, the name is overwritten when a package is added to a feed. So, if jquery is the package name stored in the database, that record will be updated to jQuery upon upload of a package.

This doesn't seem to impact many packages at all.

Thanks,
Alana

Hi @pmsensi,

Nice find. So we can't make it a configurable value, but we can try finding something that works with pipy.org, which is the main requirement.

According to the example posted in their docs, this might be what a Simple API might look like:

# Construct our list of acceptable content types, we want to prefer
# that we get a v1 response serialized using JSON, however we also
# can support a v1 response serialized using HTML. For compatibility
# we also request text/html, but we prefer it least of all since we
# don't know if it's actually a Simple API response, or just some
# random HTML page that we've gotten due to a misconfiguration.
CONTENT_TYPES = [
    "application/vnd.pypi.simple.v1+json",
    "application/vnd.pypi.simple.v1+html;q=0.2",
    "text/html;q=0.01",  # For legacy compatibility
]
ACCEPT = ", ".join(CONTENT_TYPES)

So I guess, could you try that header?

application/vnd.pypi.simple.v1+json, application/vnd.pypi.simple.v1+html;q=0.2, text/html;q=0.01

Thanks,
Alana

Hi @jw ,

Thanks for confirming that; we were able to identify the bug -- this time it ws SQL-server specific.

This is fixed via PG-3163, which we're shipping in this week's maintenance release. You'll still need to de-deduplication after however.

Tanks,
Alana

Hi @andreas_9392 ,

That configuration is not supported and will not work; You'll need to configure https://proget.mycompany.com/ or use a port.

Thanks,
Alana

@wechselberg-nisboerge_3629 great news, thanks! Well it'll be in the upcoming release (2025.13) in that case :)