Ha! You are right. I had never once seen the octocat until you pointed it out :D

I'll get something drafted up. Thanks!

Do you have a link to the repo to file said issue in?

We need to be careful with content about internalizing. Our commercial Package Internalizer feature handles this automatically, so our "Set up a Proxy repository" needs to point to vendor-specific content on that topic.

We definitely recommend an embedded package; however, where everything needed is included in the compiled nupkg!

For our purposes, a technical note on what to click in the ProGet UI to get a user to the place to set up the Proxy feed is good enough! We just want a specific place in the vendor documentation we can point to from our own documentation on configuring a proxy repository.

We're going through the same exercise with other repo vendors as well :D

We're currently writing documentation to guide users on how to set up a proxy repository that uses the Chocolatey Community Repository as its upstream.

You have existing documentation at https://docs.inedo.com/docs/proget/feeds/chocolatey that discusses the specific Chocolatey Feed type available within ProGet.

I'm wondering if you would be amenable to adding a section specifically about configuring a Proxied feed, with the Chocolatey community repository set as its upstream.

The important information to properly set up the feed would be that the NuGet version would need to be set to v2 on the upstream side, as that is currently what the CCR supports, and ensure that the upstream URL is https://community.chocolatey.org/api/v2. This will avoid redirects and other issues that may arise in making the connection.

I'm happy to collaborate with you folks to make this change. I think it will simply things for our users.

We have the full gamut of environments. Those with unfettered access to the unwashed internet, proxied environments, a single machine with access we can tunnel through, to, yes, SCIF-levels of lockdown.

In all of those scenarios, we offer an offline prep script that bundles everything needed for the installation into a zip file, which you can then sneaker-net into the environment and continue the installation.

I think we can make the offline installation work based on what I'm seeing in the documentation. I just wanted to make sure it was a "supported" mechanism of installation.

SQL Server is super fun!

So the account you initially installed ProGet with in Inedo Hub will have permissions in SSMS to modify permissions for the SQL instance. This is because Proget installs SQL for you if you don't already have it installed.

If you have the credentials the Proget service used to use, log in to SSMS with those credentials, then create the SQL Server login for the NetworkService account following @atripp's guidance above. Then, when you start the ProGet service, it should "see" the database.

Hello,

When it comes to installing to ProGet in an air-gapped environment where InedoHub will be unable to reach the internet to download the necessary Proget installation items, what level of support can be expected of Inedo should issues arise?

We are working to standardize on an Inedo Proget repository solution inside all of our pre-built environments here at Chocolatey, and I need to ensure that any method we put in place follows a supported path.

I understand that we will be deploying the free version of Inedo Proget to these environments, which provides an opportunity to upgrade to a paid version later for our customers, and as such "support" options are limited to these forums, but I'm curious how much support Inedo can and/or is willing to provide here should we opt to use the offline installation media to perform the Proget install.

Looking forward to the conversation!

Hi,

Fashionably late here, but what @atripp said is accurate. Chocolatey's moderation process on the Chocolatey Community Repository is a completely separate process to the vulnerability management features available in ProGet.

Our moderation process was put in place shortly after the Chocolatey Community Repository went live 15 years ago, and some packages were added to the feed and haven't received updates since then.

While our moderation process is really good, and we've never seen malicious content make it to approved status, you should always detonate-test a package in your own environment before promoting it to a production repository.

In the web interface I can create an API key for all feeds by selecting all feeds from the drop down menu.

This seems to be some sort of "special" handling, as via the HTTP api or pgutil I must specify a feed name, or feed group name. Dev tools wasn't too helpful in deciphering what was going on in the calls unfortunately, so I'm a bit confused on how best to do that. In the free version they'll apply to all feeds anyway, so for my particular use case I just pick a feed and use it, but I'd still like to just say "all" :)

I would only push back slightly in that I think securing the ProGet instance is core functionality, but that's a personal opinion and nothing more.

It may be an idea to provide a callout at the top of the pages to say something like:

Available in:

* ProGet Free
* ProGet Standard
* ProGet Enterprise

(or whatever the actual product names are) :)

I'm using the free version of ProGet, where I am able to create Groups, and add users to those groups via the web UI.

When attempting to do so via the API, using pgutil or Invoke-RestMethod against the api endpoint, I get this message: ProGet Free Edition does not support this API.

The documentation does not mention this. I would argue that if I can perform an action via the web interface in the free version of the product, it stands to reason that I should be able to use the API to do the same thing.

Is anyone deploying ProGet in Azure behind an application gateway? Looking for any gotchas or guidance on doing so.

I recently published a new version of Pagootle that supports working with Asset directories, includes some other fixes, and improves the documentation.

@Jonathan-Engstrom something like this? https://steviecoaster.github.io/Pagootle/Commands/Set-ProGetSslConfig/

Hey @atripp,

Thanks for the update! We've got a lot of customers moving from Sonatype to Inedo. How many of those will use connectors is unknown. Thanks for linking to your internal issue for this. We can provide that to customers so they can see the status of the fix.

@imm0rtalsupp0rt, it would be good to provide searches across both in case of a weird difference in the URLs. (That shouldn't be the case as this is an api, but I've been staring at code long enough to know that hamsters fall off wheels in the oddest places and most inopportune times!)

We're working on putting all the data together to share :)

choco search relies on the endpoint. If you use a nuget v2 url, we'll use v2, if you use a v3 source (meaning the url ends in index.json, we'll use v3.

Hey @erich_1530,

I wrote that Chocolatey package :)

If you accept the defaults, you'll be able to access the ProGet WebUI via http://localhost:8624.

I can see some possible enhancements to the package to allow for opening of firewall ports and emitting connection info to the console upon successful installation.

I'd suggest going to the package page and following the link to the Package Source and raising those changes as a feature request and I'll get them added!

If APIs are made available for things, I'd much prefer that route and will replace using Stored Procs as I can.

As pgutil.exe matures I see this module slowly becoming a Crescendo wrapper around it.