Posts made by atripp

Sounds like a plan :)

Let us know if we can help , or if you run into any issues!

Hi @sbaeurle ,

That's definitely strange; there's really nothing in ProGet that would cause intermittent 403s.

If you aren't doing so already, I would suggest switching to using API Keys in ProGet instead of LDAP. Make sure they are not "Personal Keys" but Feed keys. That will eliminate any potential issue with LDAP queries returning inconsistent results.

Otherwise, you'd almost need to capture those bad requests and see how they're different. ProGet does not have a means of capturing HTTP traffic, so you'd have to use something like Fiddler or Wireshark.

Cheers,
Alana

@scampbell_8969 excellent, please stay tuned, we'll get back within a couple weeks

Hi @sergio-gonzalez_0157 ,

The easiest solution to this is to set the parent folder's as you'd desire. For example, if you're deploying everything to c:\Websites\<app_name> then just set c:\Websites to be [COMPUTER NAME]\Users .

You can also write a PowerShell script to change permissions, but that's more complex and I recommend just using the parent-folder

Thanks,
Alana

Hi @scampbell_8969 ,

The screenshot is not yet available, it's code that we're testing.

In the meantime, you need to navigate to the package in a ProGetfeed, then assign the license. It will add a special url like package:// that is used to associate the package with the license.

Can you email the files to support at inedo dot com, with the subject [QA-1368], then we can ffind it? Just let us know when you email the files

Hi @scampbell_8969,

It's hard to say without knowing which specific packages you're referring to, but there are several known issues with ProGet 2023's license detection. It is something we're currently redoing in ProGet 2024. We plan to get this new detection logic in ProGet 2023, at least as a preview feature, in the coming weeks

Here's a screenshot of working code:

I assume these are all publicly available packages. Can you share the SBOM files for your Releases? This will be extremely valuable for us to test with.

It's kinda hard to find packages with embedded licenses to be honest.

Thanks,
Alana

Hi @philippe-camelio_3885 ,

I think I understand your question; but just to make sure...

You have two servers with the inedo-runner role, and you're using the Acquire/Release operations like this:

Acquire-Server
(
    Role: inedo-runner,
    AcquiredServer => $AcquiredServer
);

###### code that uses $AcquiredServer some how #####

Release-Server
(
    Role: inedo-runner,
    Server: $AcquiredServer
);

However, you'd like the same server to be acquired more than once, so that you could run two or three simultaneous operations on inedo-runner servers, instead of just one?

I'm afraid that's not possible, and isn't something we plan to add to the roadmap any time soon. One option is to create a second role inedo-runner2, and then use that to Aquire servers half the time

Cheers,
Alana

Hi @mike_5084 ,

Note that running ProGet as a server cluster will require a ProGet Enterprise license. So I think you may want to use Azure Container Services? That's usually what we see most ProGet Basic users use on Azure (aside from a VM).

Under the hood, Azure Kubernetes/Container Services uses Docker. We support ProGet running on Docker, and have some instructions which you've certainly seen:
https://docs.inedo.com/docs/installation-linux-docker-guide

However, we don't support Azure directly, as we're not familiar enough with Azure to advise what Azure-specific commands are required, how to troubleshot Azure-errors, what networking configuration is required on Azure, etc.

Contrast this with Windows, where we can typically advise on how to do nearly all Windows admin/troubleshooting things, from managing the Windows certificate store to changing service configuration using sc.exe, etc.

That being said, if you can "translate" our documentation to Azure, and are comfortable setting it all up, then you should be fine.

Alana

Hi @jw,

According to the comments in our code...

   // kestrel will not do port sharing in .NET6 (despite what docs imply), so use http.sys
   // Revisit in .NET8 - https://github.com/dotnet/aspnetcore/issues/39640
   foreach (var u in urls)
   {
       var m = urlRegex.Match(u);
       if (m.Success && m.Groups[1].Value is not "*" and not "localhost")
       {
           useHttpSys = true;
           break;
       }
   }

This was something that was considered for .NET7, but clearly that never happened :)

The general suggestion is to use a reverse proxy to reuse the ports.

Cheers,
Alana

Hi @stanislav-halchuk_7538 ,

Thanks for reporting this; we'll get this fixed the next maintenance release (shipping this friday) via PG-2544

Alana

Hi @chowarth_6088 ,

Can you give some more details about the errors that you're receiving, and how to reproduce this?

Thanks,
Alana

Hi @Justinvolved ,

The biggest consideration for using "separate applications" is versioning and independent deployment. For example, our extensions are all separate applications, but nearly all of them are bundled with product release. For example, see the the the %ExtensionVersions variable on a recent build of BuildMaster.

The Git::Checkout-Code will default to $Commit and $Repository variable functions for the BranchOrCommit and From arguments; those variable functions contain the values that you selected when creating a build. So you can just specify different values as needed.

See: https://docs.inedo.com/docs/buildmaster-git-source-control#build-scripts-operations

Likewise, the Deploy-Artifact operation defaults to $ApplicationName, $BuildNumber, Default, etc, so you can specify values as needed.

But like all things in software, no matter what approach you use, it will probably end up being "wrong" and you'll want to redo it later. So just plan on doing a "v2" down the line :)

Alana

Hi @sbaeurle ,

That is strange; ProGet will issue a 403 when the request is unauthorized, meaning that authentication (name/password) was correct, but the user/key doesn't have permission. That isn't really an error that would happen intermittently on the ProGet side.

It's possible that ProGet isn't issuing a 403 error. Is there some kind of authentication in front of ProGet, on the azure side? ProGet does not log these requests, so your best bet may be to monitor traffic and see if you identify what is issuing the 403.

Best,
Alana

Hi @devadmins_4004,

I haven't tried to reproduce this yet, but I looked the code briefly and am not sure why it wouldn't work. Is this ProGet 2023?

What is the specific response? Response code + body if possible.

I wonder if you could try to use the username of api and the password of your api key?

Thanks,
Alana

Hi @cshipley_6136 ,

We recommend using the /health monitoring endpoint. As you can see, it makes a connection to the database by calling that stored procedure.

We do not recommend calling other URLs; and there is no reason another page would work. Calling other pages will impact performance and likely yield incorrect results.

You're right, it might have to do with a "connection pool" problem -- but that's all managed at the driver level. You can control connection pool settings by changing connection string values, but to be honest we have no idea what the impact will be.

Your best bet is to open a case with Microsoft, who has the expertise to know how to troubleshoot these intermittent "error 40's". They may have specialized tools or "secret debugging commands" you can use.

This is all happening at the operating-system or driver-level, and while we're doing our absolute best to help you troubleshoot, but we have never seen this happen before and our main resource is searching google. And this is not an easy error to search for,..as you've probably noticed.

Please keep us in the loop.

Best,
Alana

Thanks @cshipley_6136 ; they're both the same "error 40" - which is a hostname/dns issue.

I doubt its a bug in the SQL Server driver (but it could be)... the most likely culprit is some kind of networking/configuration issues.

I would try to identify what's happening around that timestamp, network changes, etc. This is where our expertise in troubleshooting is not so strong. It's a really easy error to reproduce (just enter a wrong host name in the connection string, disable dns, unplug a network cable, etc), but tracing the underlying cause requires lots of poking around on the network.

Hi @cshipley_6136 ,

Unfortunately we're really at a loss for how to troubleshoot the SQL Server further, and it's happening at the driver level. I'm not trying to "pass the buck" here, but it's most definitely NOT a ProGet issue (as in, code that we wrote and have control over).

This must be happening at a lower-level (like the sql server driver, dns resolution, kubernetes, front-end caching, etc).

Most likely, the / vs /health is related to caching an error, or some "deep internal" behavior of the SQL server driver (or bug on Linux?) that we're not aware of.

From here, it's going to make sense to bring in Microsoft, who will know how to troubleshoot/diagnose this further. The "TCP Provider, error: 40" is so generic, and means the same thing as Chrome's "name not resolved". Aside from the obvious, we have no idea what could cause such an error, nor do we know how to troubleshoot.

They may have some "secret flags" in the connection string that you can enable, etc.

I tried to search for help, but there are like one thousand results that are all over the place, from clearing DNS caching to rebooting, etc.

On our end, our code doesn't deal with any of these things... we just use the driver to invoke SQL Server commands. Here is the entirety of the /health code:

    private static readonly LazyCached<IList<Feed>> feeds = new(() => DB.Feeds_GetFeeds(false).Select(f => Feed.GetFeed(f)).ToList());

    protected override async Task ProcessRequestAsync(AhHttpContext context)
    {
        context.Response.ContentType = "application/json";

        using var writer = new JsonTextWriter(new StreamWriter(context.Response.OutputStream, InedoLib.UTF8Encoding)) { Formatting = Formatting.Indented };

        // added for specific customer and not documented (EDO-9257)
        if (string.Equals(context.Request.QueryString["dbcache"], "false", StringComparison.InvariantCultureIgnoreCase))
            feeds.Invalidate();

        writer.WriteStartObject();

        writer.WritePropertyName("applicationName");
        writer.WriteValue("ProGet");

        try
        {
            var _ = feeds.Value;

            writer.WritePropertyName("databaseStatus");
            writer.WriteValue("OK");

            writer.WritePropertyName("databaseStatusDetails");
            writer.WriteNull();
        }
        catch (Exception ex)
        {
            writer.WritePropertyName("databaseStatus");
            writer.WriteValue("Error");

            writer.WritePropertyName("databaseStatusDetails");
            writer.WriteValue(ex.Message);
        }

        writer.WritePropertyName("extensionsInstalled");
        writer.WriteStartObject();
        foreach (var e in ExtensionsManager.GetExtensions())
        {
            writer.WritePropertyName(e.Name);
            writer.WriteValue(e.Version.ToString());
        }
        writer.WriteEndObject();

        var license = LicensingInformation.Current;

        writer.WritePropertyName("licenseStatus");
        if (!license.IsValid)
        {
            writer.WriteValue("Error");

            writer.WritePropertyName("licenseStatusDetail");
            writer.WriteValue(license.LicenseKeyStatusDescription);
        }
        else
        {
            writer.WriteValue("OK");

            writer.WritePropertyName("licenseStatusDetail");
            writer.WriteNull();
        }

        writer.WritePropertyName("versionNumber");
        writer.WriteValue(versionNumber.Value);

        writer.WritePropertyName("releaseNumber");
        writer.WriteValue(releaseNumber.Value);

        var serviceStatus = await ProGetServiceMessenger.GetStatusAsync();

        writer.WritePropertyName("serviceStatus");
        writer.WriteValue(serviceStatus.Status == ExtendedServiceStatus.Running ? "OK" : "Error");

        writer.WritePropertyName("serviceStatusDetail");
        writer.WriteValue(serviceStatus.Status != ExtendedServiceStatus.Running ? serviceStatus.ErrorText : null);

        var r = replicationStatus.Value;
        writer.WritePropertyName("replicationStatus");
        if (r != null)
        {
            writer.WriteRawValue(JsonConvert.SerializeObject(r, Formatting.Indented));
        }
        else
        {
            writer.WriteNull();
        }


        writer.WriteEndObject();
       
    }

To "translate" what's happening, the stored procedure Feeds_GetFeeds is invoked to test database connectivity. It's invoked following all of Microsoft's guidance for using the SQL Server driver.

Hi @ivan-magdolen_6846,

An "Invalid credentials specified" basically translates to "invalid username/password". In this case, it doesn't matter that the user has permissions or not (authorization) -- they simply can't login (authentication).

I would try this without chocolatey; you can simply visit the API urls in an "incognito" browser directly, and enter the username/password prompts from the browser. This should be a browser-prompt, and not the ProGet log-in page.

Once you can access the API urls, that will give you an idea of whether the LDAP is workikng or not.

Cheers,
Alana

Hi @philippe-camelio_3885 ,

First, note that ProGet 2023 requires a data migration, and if that failed then you will likely have a lot of other issues: https://docs.inedo.com/docs/proget-upgrade-2023

I don't have enough info with the errors reported to know where the problems are, but I'll share some general information.

ProGet 2022+ also uses a new platform (.NET6 vs .NET4); in general .NET6 performs better/faster, but .NET4 seems to handle "underpowered" hardware better. You can mimic the behavior of .NET4 by setting the Web.ConcurrentRequestLimit to between 200 to 500.

The "package not found" is a separate error, but may be related to a migration. It's hard to say, but it's easy to troubleshoot. You should be able to navigate to the package (string-width 4.2.3) and download it from the UI. If you get a file not found error, then investigate where that file is.

Cheers,
Alana

Hi @ivan-magdolen_6846,

If you're using Windows Integrated Authentication, then all requests will be already authenticated against the domain before reaching ProGet. So in this context, "Anonymous" really means "all domain users".

If you want to restrict only certain domain users, then you should create an active directory group. I believe the group "Domain Computers" is a special group (i.e. not a security group), and it's not returned in ordinary LDAP queries that ProGet makes.

Best,
Alana

Hi @paul_6112 ,

That's really peculiar; what must be happening is that PowerShell is returning multiple results, so the variable is automatically being being created as a list:
https://github.com/Inedo/inedox-scripting/blob/master/Scripting/InedoExtension/Functions/PsEvalVariableFunction.cs#L52

Digging further, it's like related to some issue with value detection/conversion:
https://github.com/Inedo/inedox-scripting/blob/master/Scripting/InedoExtension/PowerShell/PSUtil.cs#L205

Unfortunately it's a bit of rabbit hole from here; it's just as likely a bug in .NET6 powershell libraries as it is our code. But hopefully you can play around and find a work around? I'm at a loss, and we're pretty heads-down in ProGet 2024 planning at the moment, so hard to find the likely half-a-day to explore this further.

I'll add this to our BuildMaster 2024 roadmap, but if anyone else experiences this (or we get a ticket) we'll investigate it further.

Cheers,
Alana

Hi @paul_6112,

I'm not able to reproduce this; I tried something similar, a script that looks just like this:

Set-BuildVariable MyVar
(
    Value: $PSEval("(Get-TimeZone).Id")
);

There's a lot of moving parts in the case you gave, so best to use something simpler to try to repro. Like Get-TimeZone. It'd be good if you "play around" and figure out what specifically is causing the behavior.

Cheers,
Alana

Hi @pallavi-tarigonda_9617 ,

If you upgrade to ProGet Basic edition, you will no longer have those warnings.

One of the License Restrictions is how you've configured your connectors in ProGet (free edition cannot connect to ProGet) feeds, so that's what's triggering the warning.

Thanks,
Alana

Hi @pallavi-tarigonda_9617,

Note that replied to the ticket you submitted (EDO-9822), but I'll provide a partial reply ...

I can't find a paid license key associated with ProGet for your company

All I can see is a free license and a really old license -- however support was never renewed so it's not eligible for free upgrades to ProGet 2023. If you're using that, you'll need to purchase a license.

Happy to help with that of course!

Thanks,
Alana

Hi @paul_6112 ,

How can I justify to the security teams that I am running unsupported software version

Well.... technically none of your software is supported since you are a free user

But otherwise you can either upgrade the agents or link them to this post where an Inedo engineer advised it's fine in your scenario. Or if you can suggest a way to clarify the docs... we recently reformatted that download page and split into "supported" and "unsupported".

So I can actually test that the automatic upgrade does work, which version of the Agent should be installed to prove it would take place ?

Without digging in the code I'm not sure, but I'm pretty sure this functionality was disabled in BuildMaster 7 - the sentence mentioning it in the docs was obviously not removed. Instead, you will likely get some kind of warning on older versions.

The failure rate was relatively low (~0.1% or so), but it's high enough that it's not worth risk for customers.

Thanks,
Alana

Hi @paul_6112 , we could definitely be more consistent here.

The listing is generally called "Deployments & Executions" , which we shorten to "Deploys".

I'll make a note in our roadmap to review this!

Hi @paul_6112 ,

It sounds like there is some kind of proxy issue. We will investigate this via the other ticket.

We don't plan on removing Inedo Samples... just the "Application Templates" feature, which basically allowed users to maintain a gallery of your own templates or samples.

Cheers,
Alana

Hi @paul_6112,

There are no issues w/ using v49 or v50 in newer versions of BuildMaster; the bug is just with older (but still supported) versions of BuildMaster.

The "critical bug" is that an improperly-formatted encryption key in the agent's configuration file will cause the agent to not crash, but instead fallback to unencrypted mode. Newer versions of BuildMaster will detect this configuration problem. v46 does not have this bug.

Cheers,
Alana

Hi @paul_6112 thanks for the report -- this is a known issue/regression in our internal UI library with focus- it only impacts a very few number of pages, but it's on our list to eventually address

Hi @paul_6112,

Thanks for the report; looks like this is a regression that can happen after upgrade; to work around this

1. Go to Admin > Resources
2. Click Add Secure Resource, then "Show All"
3. Select "[Deprecated] Universal Package Feed"
4. Name of Templates and API Endpoint Url of https://proget.inedo.com/upack/BuildMasterTemplates/

You can use a different URL if you have a ProGet universal feed of course.

This will be fixed in next maintenance release via BM-3908.

This should solve the issue. And as an FYI, application templates are now deprecated in favor of "cloning" a "template" application.

Hi @paul_6112 ,

I just updated the documentation to clarify our Inedo Agent Upgrade guidance:

You shouldn't upgrade unless you are directed by a version of your Inedo tool (Otter, BuildMaster, etc) or an Inedo support engineer.

In this case, you wouldn't be prompted to upgrade if you're using v46 or v49, so we really don't suggest upgrading. There's zero benefit and a nonzero cost (time to upgrade, risk of problems, etc).

Keep in mind that the Inedo Agent is really just a lightweight "agent host", and the "actual agent" is upgraded transparently all the time.

Cheers,
Alana

Hi @paul_6112

In that case, you may want to try restarting the service? It's possible the proxy change didn't get reflected...

Thanks,
Alana

Hi @paul_6112,

It definitely looks like the proxy settings need to be configured/changed. You can configure and test the Proxy settings under Admin > Proxy. That page also has a "Test" button that you can try different URLs.

With a Proxy configured and allowing;
my.indeo.com
proget.indeo.com

Now this is probably a typo on the forums, but just in case not... inedo.com not indeo.com

Hope that helps,
Alana

Hi @neo ,

If you haven't seen it already, here is our guide for migrating a ProGet instance:
https://docs.inedo.com/docs/migrate-a-proget-installation-to-a-new-server

That generalizes our advice as much as possible. And since you're using such an an older version of ProGet, you should also upgrade this as well.

Note that our professional services team can usually handle this for you for a very low cost; the service isn't listed on the page, but we offer it via the support channel.

Product Upgrade/Migration Service

Flat/fixed cost of $995. Eligible to ProGet users through Dec 31, 2023. Our professional services team will help every step of the way. Often, a migration/upgrade involve a lot of steps and back-and-forth, including:

• Meeting with your team to plan the migration/upgrade
• Review existing configuration and report on issues, like permissions, missing backups, security concerns, etc.
• Help resolve issues before migrating/upgrading
• Create a testing and rollback plan
• Answering questions/concerns before
• Execute the upgrade/migration plan (Assuming we have the access, otherwise we will direct where to click.)
• Follow and addressing issues after the fact
• Documenting issues and concerns for next time

If that's of interest, please fill out the form on this page (select "Other services not listed"):
https://inedo.com/professional-services

Cheers,
Alana

@Srinidhi-Patwari_0272 here is some information about HTTPS support on Windows:
https://docs.inedo.com/docs/installation-windows-https-support

However.... as Dean mentioned, this is something you'll need to work with your network team (a domain administrator) on, as the cert needs to be trusted, etc.

Hi @Srinidhi-Patwari_0272 ,

I'm not totally sure I understand, but when you do a silent install you need to specify a connection string.

So you would just specify the connection string you need like this I guess

hub.exe install ProGet:5.2.3 --ConnectionString="Data Source=externals,qlserver.corp.local; Databse=ProGet;Integrated Security=True;"

Hi @nicholas-boltralik_3634 ,

One thing I'm thinking is that this is a UI-bug, in that an option is set on the rule that cannot be edited in the UI; can you try deleting that particular rule, then re-adding it?

Otherwise There's no easy way to delete these;

• You could tag them, and then browse in the UI, and delete.
• Or you could do a DELETE request using the API, but that's not really that easy to do due to how Docker API auth works.

But we should be able to fix this, just need to figure what's causing it.

FYI -- The bug fix you mentioned earlier ( PG-2477) had to do with tag matching. The specific case was, if you had the rule "Delete Images (not requested for 10 days, matching 0.0.0-*) from the feed" set-up, then an image with BOTH 0.5.0-abc4.1.1-posse7.4.2.2 and 0.0.0-issue-PC3-1507 would not be deleted. I don't think it's related.

Thanks,
Alana

Hi @cshipley_6136 ,

When you specify dbcache=false, then ProGet will immediately invalidate the cache used for database connection-testing. This is otherwise cached for up to 5 minutes. Otherwise, there isn't anything that ProGet (as in the code we write) that would cache or hold any connection.

So, this is ultimately related to ADO.NET's internal DNS caching / connection pooling /etc., and it would likely resolve within a few minutes on its own. But it's hard to say exactly what's going on. ADO.NET is the "driver" that's used by all .NET-based applications to connect to SQL Server, so I suspect this is solvable with configuration of some kind.

Unfortunately, I'm not sure on your configuration nor advanced SQL Clustering scenarios. On our end, we just "let the driver" do the work and follow ADO.NET best practices with regards to driver usage.

I did some initial searching, and I wonder if you just need additional configuration on your server connection string, like MultiSubnetFailover =true. They discuss a lot of information on it: https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/sqlclient-support-for-high-availability-disaster-recovery

Happy to help parse some of it, but please keep in mind this is a "driver" issue and we're learning about the internals for the first time, along with you. But the MultiSubnetFailover may help for a faster cut-over??

NOTE: if / failed but /health didn't, then it's most certainly related to this internal connection pooling, and it wouldn't be consistant at all. I would most definitely not hit the / page for a health check, as that will introduce a lot of load on your instance and cause reliability issues.

@nicholas-boltralik_3634 thanks for sharing the other details; nothing is jumping out as off to me in the code (and i can't reproduce this with a trivial case), so please give us some time to do a little more investigation - it's most certain we won't get this in the upcoming maintenance release (this Friday), but we have one on Nov 17 that hopefully we'll be able to figure this out in

Hi @A-Schoder_7166 ,

It sounds like your installation is somehow corrupt?? I can't imagine what would cause that error but it's basically saying that the upack.json file within the extension file (xxx.upack) is corrupt.

Maybe some antivirus tool went and "quarantined" zip files on disk that contained executable code? Really hard to guess. The file sare loaded , typically in c:\Program Files\ProGet\Extensions, and they are part of the installation.

I would uninstall and reinstall, and hopefully that will fix the issue.

Thanks,
Alana

Hi @nicholas-boltralik_3634 ,

Do you have anything else defined on the other tabs? That could have an impact if so...

Otherwise, best way to troubleshoot this would be to look at the retention logs. That should give an idea of what's happening in the policy. And then if you can find a specific example of an untagged image, that would definitely help to track it down...

Cheers,
Alana

Hi @mharen,

You can try to enable Windows Integrated Authentication in ProGet, and then use two sites in IIS (once with WIA, one without), but that will only work for NuGet packages. Other client (npm, docker) do not support WIA.

Otherwise, you can take a "DMZ" approach, and configure two instances of ProGet - one for Devs, one for CI systems - then use a connector. The two-instance approach also has the benefit of reducing load, though not quite as much as a load balancing configurating.

Cheers,
Alana

Hi @jw ,

Thanks for reporting these!

We'll get the fixed in hopefully the next upcoming maintenance release via PG-2520 and PG-2521

Cheers,
Alana

Hi @lucas-almeida_8120 ,

This error implies that there's some kind of database corruption or other error that happened while updating the database a while ago. But it's hard to say; this is the first time I've seen this error.

Unfortunately, unless I were to analyze a backup of your database and try to reproduce the installation/upgrade, I won't be able to offer any guidance or scripts that could repair the state of things.

From here, I would recommend rolling back to whatever version was working, then starting a new ProGet server and importing your packages.

Best,
Alana

Hi @Srinidhi-Patwari_0272,

To accomplish this, I would recommend writing a script that does the following:

1. Installs SQL Express with the configuration you desire
2. Download latest version of Inedo Hub
3. Run hub.exe to perform silent installation

Installing SQL Server in an automated manner is not trivial, and you will need to research the best way to do that in your environment. Here is an article I found when searching for that: SQL Server Unattended Installation with PowerShell.

AS for steps #2 and #3, here is an example script from our Silent/Automated Installation Guide that you can adapt as you need:

# create working directories
mkdir C:\InedoHub
cd C:\InedoHub

# download and extract file to working directory
Invoke-WebRequest "https://proget.inedo.com/upack/Products/download/InedoReleases/DesktopHub?contentOnly=zip&latest" -OutFile C:\InedoHub\InedoHub.zip
Expand-Archive -Path InedoHub.zip -DestinationPath C:\InedoHub

# perform silent installation
hub.exe install ProGet:5.2.3 --ConnectionString="Data Source=localhost; Integrated Security=True;"

Best,
Alana

Hi @jw ,

With the way things are "wired up" today, there are some edge cases when this will not show up right away. This is primarily for performance reasons, and it's something we absolutely plan to address in ProGet 2024.

The "trick" is that the PackageAnalyzer job needs to be run to do some back-end linking in the database; this is typically done on a nightly basis (there is a scheduled job for this), and in practice it's rarely something you'll spot outside of testing.

For example, after that job runs... if you were to delete then recreate TestProject 1.0.0 by pushing an SBOM, it should show the vulnerability.

Thanks,
Alana

Hi @rob-leadbeater_2457 ,

Good timing! This is something we plan to ship in the next or following maintenance release.

Actually, we had to completely reimplement Debian/APT feeds from scratch, so there will be a "Debian" and a "Debian (Legacy)" feed type, and a way to migrate from the legacy to the standard feed types.

I added a note to update this post once we have it ready to ship.

Cheers,
Alana

Hi @haralambop_0645 ,

A 403 error means that the user does not have the required permission to perform the action. So you'll need to make sure that feeduser is authorized to push packages to the feed, which you can do under Admin > Tasks.

Cheers,
Alana

Hi @gunmaden_7628 ,

The Common Packages API does not work with Maven feeds, since they are not a package-based feed. Otherwise... it's hard to say what the issue is with Python or Debian, but most likely it's missing a parameter that identifies which file to delete?

If you can share more details about the calls you are making and the packages we may be able to help.

Cheers,
Alana

@haralambop_0645 oh see - in this case, you'll need to add a source with the username api and password of your key using dotnet nuget add source

dotnet nuget add source https://myProGetServer.local/nuget/myFeed/v3/index.json -n myFeed -u api -p myApiKey --store-password-in-clear-text

This is because NuGet does not send an api key during list, it uses the name/password in the source file.