Hi @udi-moshe_0021,
Here is the license restrictions per edition:
https://docs.inedo.com/docs/proget-administration-license
Vulnerability Scanning is not available n ProGet Free; you would need a paid license for that. You may see some information in ProGet free, but it's mostly intended to bring awareness to the feature and encourage users to evaluate/purchase the software.
Cheers,
Alana
Hi @udi-moshe_0021 ,
Your configuration is not possible.
Your configuration is possible with ProGet Basic. ProGet paid editions include an offline vulnerability database that will be updated every time you upgrade ProGet.
Note that, after a steady decline in service and data quality, ProGet no longer relies on the free, third-party OSS Index. Instead, ProGet uses industry-leading vulnerability and malicious package detection from our own Inedo Security Labs. OSS Index integration will be fully removed in ProGet 2024.
Hi @udi-moshe_0021 ,
Microsoft no longer recommends using IIS for .NET anymore and similarly we've shifted our guidance to use the built-in web server (i.e. Kestrel) the same. There are no pros to IIS, only cons.
Thanks,
Alana
Hi @frei_zs ,
Thanks for clarifying; I'm not at all familiar with the ecosystem and I really don't know how to use deb/aptly/etc. I also don't know what a Packages-files file is.
However, I can say that ProGet provides provides endpoints for two "files":
These are dynamically generated by ProGet, and we've not run into any issues nor have other users expressed issues. That doesn't mean they're error-free, it just means we don't know what's wrong since we tried to follow the spec and it worked for us/others.
I don't know what the URL is for these offhand, but if you use a traffic capturing tool, you can see exactly what deb is requesting.
If you can help us identify what's wrong with the output generated by ProGet, there's probably good chance we can fix them. We'd also want to know why it "works on our machine" and others.
Thanks,
Alana
Hi @frei_zs ,
Unfortunately we don't know what aptly is doing behind-the-scenes and can't guess what could be going on here. I don't believe that ProGet is generating that file; it looks like something aptly is doing based on data downloaded from ProGet.
ProGet implements a Debian repository as specified here:
https://wiki.debian.org/DebianRepository
It's possible that there's a bug in our implementation, or a bug in aptly, or both. But we can't really track it down with the information here :(
Your best bet would be to start with the aptly team, and to see if they have any idea.
Cheers,
Alana
We haven't investigated or changed this code in very many years (especially within the last year), so I wouldn't expect a changed result.
Can you try the same troubleshooting steps as above? To find out where the invalid JSON is? Maybe it's comma again?
FYI - we use Newtonsoft.Json for both serializing and deserializing (as you can see from error). It's really odd to be generating invalid JSON, but that's what the message is
It could be related to an obscure bug, etc. We just have no idea and haven't investigated in past year.
Thanks,
Alana
@frei_zs I'm also replied to your ticket (EDO-10276), but wanted to reply here as well. I'm going to lock this thread after, since it's a different issue.
Unfortunately "tar" files are more of a convention than a standard, and not all libraries can read files created with different libraries. We are using one of the most "forgiving" tar libraries (we use four different ones!) in this particular scenario, but maybe aptly conventions aren't forgiving enough?
FYI - here is what we're doing with the library
public byte[] ReadControlBytes()
{
using var control = TarReader.Open(this.Control);
while (control.MoveToNextEntry())
{
if (control.Entry.Key == "./control")
{
var bytes = new byte[control.Entry.Size];
using var entry = control.OpenEntryStream();
ReadBlock(entry, bytes);
return bytes;
}
}
throw new InvalidPackageException("Package does not have a control file.");
}
We will need to inspect the file and see if we can determine what's wrong, and if it's an easy fix, we'll do it.
Thanks for sharing that, I was able to find the issue.
The two feeds - public-ubuntu are missing public-zabbix are missing the property feedType. This is a bug in BuildMaster for not validating the data in that case and in ProGet for not sending it. So we will fix both:
In the meantime, as a work-around, you can block those feeds from your API key, so they can't be read. They aren't usable in BuildMaster anyway, and that will prevent the bad data from being returned, which is what's making the API break.
Thanks,
Alana
@hashim-abu-gellban_3562 nice find, correct that was a typo :)
If you need to authenticate to the feed, you need to pass an API key using Basic authentication., with api as the username and your key as the password.
Here is one way to do this in PowerShell.
$user = 'api'
$pass = 'abcdefg12345'
$pair = "$($user):$($pass)"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$Headers = @{
Authorization = $basicAuthValue
}
$url = "https://myprogetserver/feeds/mynuggets/package/mypackage/1.0.0"
$destination = "c:\mypackages\mypackage-1.0.0.zip"
Invoke-WebRequest -Uri $url -OutFile $destination -Headers $Headers
I would recommend first getting your scripts to work without authentication, then add it in later.
Cheers,
Alana
Hi @rick-kramer_9238 ,
We have seen cases where LDAP/AD is painfully slow; one common reason is that "recursive group search" is enabled.
But before digging into that, I would just temporary disable Windows Auth (do this in IIS) and disable LDAP/AD, so that you're only loggin in with a built-in username/password. If it's still really slow, then you know it's unrelated.
Best,
Alana
Hi @v-makkenze_6348,
It's hard to say for sure, but there's clearly some kind of database timeout problem here when running Projects_GetReleaseAnalyzerData . I suppose you could try running that directly, and see if it takes a long time?
I suspect the issue is that you have too many active releases. This is a major issue with ProGet 2023's feature -- it was designed with the assumption that users would archive releases, but we've seen thousands in the field. If you have a lot of active releases, this cause some big performance issues.
ProGet 2024 auto-archives builds (the new word for releases).
Cheers,
Alana
Good news @m-karing_2439 ,
This works in ProGet 2024! More specifically, when rewriting/refactoring the PyPi feed, we added support for this "unconventional" repository - specifically, one that doesn't follow the /simple convention or use any of the JSON/warehouse api.
Cheers,
Alana
Can you share the results of /api/management/feeds/list (on ProGet) using the API token you specified?
With that we can hopefully spot something.
Thanks,
Alana
Hi @jw
You're correct, the general design philosophy is to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.
As you also might imagine, it's hard to get that right all the time and obviously it's not a high-priority in testing (internally) or reporting (users/externally).... so if you spot places where it's incorrect, let us know. We're always keen to improve the UI/UX :)
Best,
Alana
If you plan to use the NuGet API, it's best to familiarize yourself with how it works. We do not document this API nor provide examples, we simply implement Microsoft's API. Here area few links that may be helpful:
When Basic authentication is required, you can use api/{your-key} for username/password. You can learn more about API keys in ProGet here:
As an alternative, you may find ProGet's Common Package API to be easier to use; we also document it and have several examples:
Best,
Alana
@forbzie22_0253 you can use the same ProGet Free on multiple instances
Thanks for the bug report @philippe-camelio_3885 !
I logged as OT-508 , and we'll target it an upcoming maintenance release :)
Hi @scott-wright_8356 ,
You can ignore that message; not sure how/why it occurred, but the consequence is that the message that the license key was updated wasn't immediately dispatched to the other nodes due to some timint issue. So that means it could take a few minutes for the other nodes to reflect the new license key.
We should probably just ignore that error. let us know if you keep seeing "No primary service node has been registered." and we can investigate further.
Best,
Alana
Thanks @jw, we still aren't quite sure what's behind this, but we rewrote PgvdVulnerabilities_UpdateIndex procedure to run much faster:
This will be included in ProGet 2023.32 via PG-2615
I just published ProGet 2023.32-rc.1 as a pre-release ; would you mind to try it out on your test server, since you can reproduce it?
https://docs.inedo.com/docs/howto-install-prerelease-product-versions
Hi @v-makkenze_6348 ,
I wasn't sure what version you're on. I'm not able to reproduce this in ProGet 2023.32, so I wonder if it's a possibly a bug in an earlier version of ProGet 2023? We recently made some fixes.
How did you try to add the license as Package name?
Did you manually edit the license, or use the dialog to add the entry?
Thanks,
Alana
Hi @v-makkenze_6348,
Just want to confirm here -- it sounds like it's working, except the issue now that you're only seeing 634 packages but not 363?
One thing I suspect is that one of the packageurls in the SBOM is invalid (incorrect format). Are you able to find which item isn't being imported?
It might be missing a version or something else?
Thanks,
Alana
@jw That is so weird.
Is it always failing with the follow?
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
Looking over your Prod dates... did you happen to upgrade after 2024.03.14? Or maybe that's when you enabled the preview feature?
Could you try running sp_updatestats and cleaning fragmentation on those tables usig SQL Management Studio? Clearly there's something we're missing here... 
Thanks,
Alana
Hi @Justinvolved ,
This is not uncommon with PowerShell; in general the processes will be closed, but there are enough scenarios with long-running/hanging PowerShell scripts where those processes will report termination but the process will not be terminated. So they can stick around
I'd recommend using the Inedo Agent instead, even if it's on the same sever. That gives better process isolation compared to the local agent, and you shouldn't see this behavior for too long. The local agent runs in-process.
Cheers,
Alana
Hi @jw ,
This job should take like a minute tops. It's inserting/updating about 50k vulnerability records (PgvdVulnerabilities) and maybe 200k related package records (PgvdPackageNames). The later packages tend to have more related packages, but not that many. In either case that's not a lot for SQL Server.
Any help in troubleshooting would be appreciated, since we're kind of at a loss. Behind the scenes, the PgvdVulnerabilities_UpdateIndex procedure is being called with batches of 1000 vulnerability records, and it's exclusively locking both tables.
We noticed that micro-instances of SQL Server (e.g. 1 core / 512MB ram) would fail without batching, but otherwise it completes in about 5 minutes. I assume you're not running that?
One user reported an unpatched SQL 2016 had a severe performance issue with an OUTPUT clause we were using, so we stopped using that. Now it works in that version.
Maybe it's another SQL Server bug? Or perhaps something we're otherwise missing?
Maybe a forced sp_updatestats would do the trick? Or cleaning up fragmentation on those tables (again, shouldn't be a problem....)
Any insight would be helpful. We don't know how to rewrite this any more effectively, and batches of 1000 seem about as small as we want to make them.
Thanks,
Alana
Hi @m-karing_2439 ,
Unfortunately, this repository doesn't following PyPI repository conventions.
For example:
/simple listing (e.g. https://download.pytorch.org/whl/cu118/simple)I guess it "happens to work" in pip , or perhaps they install a plugin that allows it to work... but ProGet is designed around PyPi repository specs. which is why a non-confirming download site won't work very well.
I'll add a note to investigate this further, but for the time being you should just download the wheels and upload them to a feed in ProGet.
Cheers,
Alana
I looked into this further; for Maven feeds, the Connector Health Check simply queries the downloaded index. If there is no downloaded index, then it reports back as healthy. If there's an error with the index, it reports an error. However, most maven repositories don't have a downloadable index.
Anyway the health check is not very useful, and we plan to revisit the functionality in the future, since there's really no way to determine if ProGet can download an artifact unless you know the exact name.
Thanks,
Alana
@appplat_4310 thanks for the update!
We also applied the patch to the next maintenance release, so you shouldn't have any issues going forward then!
It's a bit hard to figure out how to help or troubleshoot with the information here, but a few key points:
To help on this, we'll need to know specifically where the issue is and have instructions on how to reproduce it on a new feed/instance of ProGet.
First, I would start by trying to download the .pom file and .jar files from Google (like that gradle one you found), then upload them to ProGet from the Web UI. If that doesn't work, then we know the POM file is probably bad, and we can investigate it.
Next, I would try to pull the pom/jar from a connector. If that doesn't work (but uploading it does), then maybe the "API" for that repository is incorrect. And we can investigate it.
Best,
Alana
Hi @scott-wright_8356 ,
I'm not sure, but based on this URL:
https://maven.google.com/web/index.html#android.arch.core:common:1.1.1
I can see that the POM for android.arch.core.common 1.1.1 is located here:
https://dl.google.com/android/maven2/android/arch/core/common/1.1.1/common-1.1.1.pom
So the base URL would be:
https://dl.google.com/android/maven2
That should work, since maven works by convention. You will not see a listing of artifacts unfortunately, since Maven does not provide an index. You just need to know the articats by name, then append maven-metadata.xml.
As expected, the metadata file for that artifact is here:
https://dl.google.com/android/maven2/android/arch/core/common/maven-metadata.xml
Cheers,
Alana
Hi @forbzie22_0253 , that's only possible in the one-off GUI option. It's not possible if you're using a drop path
Hello, just letting you know we're aware of the issue and plan to investigate/fix soon! And we hope then to get your feedback on the preview feature :)
Hi @scott-wright_8356 ,
Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy.
ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors.
Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later.
Best,
Alana
The use case you're describing (i.e. using drop paths as an intermediate to publish packages to ProGet) is not uncommon. It's fine, and can be simpler in many cases.
But since you asked... the downsides are that require file share access, new developers may be confused by the process (since the typical workflow is publishing directly), and that there is a lack of immediate feedback mechanism (just because file copy is success doesn't mean package is accepted). I guess those are all obvious.
As to your other questions...
Can ProGet handle situations where multiple computers are trying to install a module from the feed while at the same time that module is being updated by the dropPath feature?
Package versions are immutable and not meant to be overwritten. Instead you are supposed to publish new versions. If your workflow involves continuously overwriting the same version while continuously consuming it, you will get errors. Regardless of using drop paths or publishing.
Could these be potential file locking situations where a package is copied to the drop path and ProGet is trying to access it in the dropPath?
If the file in a drop path is locked for reading (since it's currently being written), ProGet will just try again later.
Hi @scott-wright_8356 ,
Can you try downgrading to 2023.30? I see some Maven changes, and any time there's a possibility of a regression. That will at least tell us where the issue might be.
Thanks,
Alana
Hi @scott-wright_8356 ,
You can change if you'd like, I'm not sure if it makes any difference with .NET6+ applications.
Cheers,
Alana
Hi @appplat_4310 ,
In 2023.31, we made made introduced various database performance improvements (deadlock, timeout reductions) via PG-2606, so it's possibly related to that. The query you identified most definitely helped, and it there's only one place it's called.
WE would be super-grateful if you could try running this?
ALTER PROCEDURE [NuGet_GetPackage]
(
@Feed_Id INT,
@Package_Id VARCHAR(255),
@Version_Text VARCHAR(255) = NULL
)
AS
BEGIN
SET NOCOUNT ON
SELECT *
FROM [NuGetFeedPackageVersions_Extended]
WHERE [Feed_Id] = @Feed_Id
AND [PackageGroup_Name] IS NULL
AND [PackageType_Name] = 'nuget'
AND [Package_Name_Lower] = LOWER(@Package_Id)
AND (@Version_Text IS NULL OR [Package_Version] = @Version_Text)
END
We believe that, for some reason, your query analyzer is following a different plan, but the new conditionals should force it to use the right index.
Let us know, and we'll get it fixed right away.
Thanks,
Alana
Hi @rick-kramer_9238 , you could certainly try to enable those and see if they help or make a change.
@scott-wright_8356 the Inedo Hub will upgrade the database code (stored procs, views) when doing an installation. So from the time you upgrade the first server to the last server of a cluster, the "database code" and "server code" will be "out of sync", yielding errors like this.
For most users it's okay, and they will typically (manually) upgrade all nodes over the course of a few minutes during a mtaintenance period etc.
Hi @jw , thanks for pointing this out! I added a note to review/investigate this in our run-up to finalizing ProGet 2024.
Without looking closer or testing it's hard to say, but that error sounds like the property isn't being set? You can see rom the the source code of Git::Checkout-Code, the BranchOrCommit argument (called Objectish in the code) will use DefaultValue of $commit unless a property is specified .
I guess just as a test, does set $commit = master make any difference?
Thanks,
Alana
Hi @rick-kramer_9238 ,
It's possible that the IIS App-pool is automatically shutting down, which can lead to a "warm up" time that's required on a first request. However, this is typically measured in seconds in slow cases, not minutes. So it shouldn't take that long to "warm up".
Unfortunately this isn't easy to troubleshoot, and it seems to be related to some kind of strange IIS configuration. We've heard of users solving it lots of different ways, from switching servers to uninstalling IIS, to switching to the Integrated Web Server. But no idea what actually works.
The easiest thing to do, you may want to consider switching to the Integrated Web Server. Microsoft recommends that over IIS these days as well. The quickest way to do this is to uninstall ProGet (this does not delete database or packages), then reinstall to use the integrated web server. Make sure to point to same database at install time. You can configure HTTPS later.
Best,
Alana
Hi @gurdip-sira_1271 ,
That message means that the Login for GLOBAL\GLOPROGET01$ does not exist at the SQL Server level; you can add this in SQL Server Management Stuiod, under Security > Logins.
Cheers,
Alana
Hello,
I am copy-pasting the same reply made to EDO-10211 -- feel free to reply to one or the other.
We'll do our best to help, but based on the information you provided, it sounds like your server might be "overloaded" and have more traffic than it can handle. I would recommend trying out ProGet 2023.31 (releasing later today) which has a few more performance tweaks, but if that doesn't solve the issue than it will involve looking at ways to expand server/clsuter capacity or reduce/throttle traffic.
The error you shared is unfortunately unrelated, and is just a generic "client disconnected" error - it will occur if a a client (web browser, etc) disconnects prior a request being received. These should not be logged, but due to a known issue in .NET6 they are. This should be fixed in .NET8 (ProGet 2024).
Best place to check is ProGet Diagnostic Center, under Admin. That will have the most relavent errors.
Best,
Alana
Hi @forbzie22_0253 ,
(Sorry this is basically a copy/paste of the same answer to @philippe-camelio_3885 's question)
We haven't run into any of these issues in our testing, but this error is a "generic database timeout", which is implying that "something" is going on with the database. That's the only information we have, "something".
To troubleshoot this, you'll need to use some of SQL Server's performance/activity monitoring tools to spot what's going on at the time. It could be anything from outdated statistics to a missing index to a bad query. Or who knows.
With ProGet, timeouts can happen during extremely high usage of feeds/server. We have also seen instances where SQL Server's auto-statistics aren't working, and rebooting the server will help -- you can try running sp_UpdateStatistics as well. I have never seen that personally, but two users reported this already.
Best,
Alana
We haven't run into any of these issues in our testing, but this error is a "generic database timeout", which is implying that "something" is going on with the database. That's the only information we have, "something".
To troubleshoot this, you'll need to use some of SQL Server's performance/activity monitoring tools to spot what's going on at the time. It could be anything from outdated statistics to a missing index to a bad query. Or who knows.
Best,
Alana
We do not support "sub-path content/URL Rewriting" in any of our products and strongly discourage even trying. It won't work and will just lead to lots of wasted time and headaches, since everything from javascript ajax requests to CSS background images to cookies assumes a well-known root path of / for the application.
Best,
Alana
In BuildMaster 2022, we redesigned the Git and Source Control experience, which required significant changes to the various Git extensions (Git, GitHub, GitLab, and AzureDevOps).
With these changes, instead of using service-specific operations like GitHub::Get-Source, you can simply use operations like Git::Checkout-Code. Behind the scenes, BuildMaster wires everything up using build variables like $Repository and $Commit.
In Otter, you'll need to specify those variables or To and BranchOrCommit properties, similar to this:
Git::Checkout-Code
(
To: $DossierVisHab,
From: gitlab-vishab
BranchOrCommit: master,
);
The extensions are indeed the same between BuildMAster and Otter, but they do different things than before. Now, the GitLab extension mostly just provides integration into Issue Tracking, and information intended for the BuildMaster UI, such as a list of organizations, repositories, etc.
Best,
Alana
I didn't realize it was possible to create those in Otter 
I thought only Generic Git repositories work. There's no GitLab/Github/etc.-specific functionality available in Otter, those are primarily intended for BuildMaster's integrations.
I would just use Generic Git repository, since the Git-base doperations will all be the same.
Cheers,
Alana