Hi @martin-helgesen_8100 ,

Nothing new I'm afraid; you're the second user who's inquired about this so far.

We do have several customers using Terraform and ProGet, either using universal packages (like @jeff-miles_5073 suggested) or using Asset Directories. We asked them a while back if they had interest for a "proper" Private Registry, and the response was that even if it was available... they likely wouldn't use it because it would involve changing their system, and they saw no benefit to a feed.

We know basically nothing about Terraform and have done no research into the costs/complexity of implementing a registry. Do other products/vendors support this?

The first "red flag" on my end is this:

Terraform can use versioned modules from any service that implements the registry API. The Terraform open source project does not provide a server implementation, but we welcome community members to create their own private registries by following the published protocol.

In our experience, documentation is almost always outdated and inaccurate. So this means lots of reverse-engineering of API protocols and lots of debugging.

Not saying it's impossible, but we'd definitely need community support to make it happen. Check out how the rpm feeds came to be - if it's something you can prototype in Asset Directories (for example), that could go a long way in making it a first-class feed in ProGet :)

Cheers,
Steve

Hi @msimkin_1572 , good idea! I just added a small note at the bottom, where we specify manifest. To be honest, I didn't even know that was possible

Hi @itsoftware_2704 ,

We don't have instructions specific for Docker containers, but you basically just need to run the ProGet.Service.exe resetadminpassword command on the container. And then restart the container.

Here is more information on what this does:;
https://docs.inedo.com/docs/installation-security-ldap-active-directory

I'm not very well versed in Docker, so I don't know the exact way to run that command - but in the interest of giving you an answer right away, I wanted to share this. Hoping you know how to though :)

Feel free to share how you ran the command, in case someone else runs into this thread!

Cheers,
Steve

Hi @richard-carpenter_9650 ,

Thanks for confirming that; that is really strange. I just tried it msyefl and got the same result.

The technical answer is that PowerShell gallery is sorting the feed alphabetically, and is only returning the top 100 entries. Of those entries, all but two are unlisted. So that's all you see.

Not a great UX, so hopefully it goes away (i.e. they return the default sort order by downloads), or maybe we can sort differently ourselves. We're not too keen to change this, since it's the "very sensitive" legacy NuGet v2 API, but perhaps in v2023 we can alter this.

Cheers,
Steve

Hi @richard-carpenter_9650 ,

When you add a connector to your feed, it will display the packages from those connectors. There's no way to "remove" these packages, since they're on the PowerShell Gallery. But you can always add "connector filters" to show a subset of packages (by name).

The PowerShell recently changed the API sort order to show packages alphabetically (instead of by download count), which is why you see those packages first.

Cheers,
Steve

Hi @jwest_6990

What Windows server version is Otter installed on? That might help us narrow this down.

We have seen that error if RSAT is not enabled:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/remote-server-administration-tools

Cheers,
Steve

Hi @e-rotteveel_1850 ,

Thanks for all the details here! Very helpful, especially since we know very little about Conda.

In our code, we have a WriteChannelData and a WriteRepoDataAsync method, which write out these files on demand using the Newtonsoft.Json library for this.

So, I just specified a StringEscapeHandling of EscapeNonAscii, which will escape all properties. I don't think that will be a problem.

The change is PG-2295, and it will ship in next maintenance release (Friday, Mar 10). If you'd like to try in a prerelease, just let me know and I can promote our CI-build so you can use it sooner.

Cheers,
Steve

Hi @priyanka-m_4184 ,

That message usually indicates a network problem; are you seeing any issues on the ProGet side of things?

Can you try pushing a package with PowerShell directly instead of using upack.exe? That way you can see an error more clearly, hopefully.

Cheers,
Steve

Hi @OtterFanboy ,

I was able to identify/fix this as BM-3818; looks like the issue was purging a deployed build from a deployed release causes the overview page to crash.

You can work-around this by finding that release on the main "Releases" tab and purging it too.

Cheers,
Steve

@OtterFanboy forgot to mention, we did plan to build a first-class Gitea integration, so you could browse your repositories (just like GitHub etc.), but didn't get it in time. It's still on our list!

Hi @OtterFanboy ,

Thanks for all the details :)

Looks like this is a regression/bug with browsing Generic Git repositories. That's a brand-new 2022 feature, and we're still working out kinks with it. We'll investigate and get it fixed ASAP!

Stay tuned :)

Cheers,
Steve

Hi @testintergraph_2317,

We haven't specifically tested w/ OpenLDAP (I think), but the integration does work with other providers. One compatibility issue seems to that sAMAccountName isn't the Username property on all LDAP servers.

However, in v4 of the LDAP provider, you can now customize these queries. Have you tried this yet? https://docs.inedo.com/docs/en/various-ldap-v4-advanced

In any case, we'd be happy to work with you on getting OpenLDAP working. Just let us know what specific issues you're having, and we can patching, etc.

Of course, you're welcome to try modifying the code yourself... and if you want to try I would start by forking the InedoCore extension and then using a custom build of that (just use a version number higher than published). Make sure to delete that custom version once we accept pullrequest or publish version with identical changes.

If you want a totally custom extension, just make one witha different name.

We don't have instructions for custom extensions with Docker, but it follows the same process as Windows (just restart container instead of AppPool/Service): https://docs.inedo.com/docs/proget-administration-extensions#manual-installation

Cheers,
Steve

Hi @testintergraph_2317 ,

I'm afraid that sample code is ancient and won't work in any modern version of ProGet...

Can you let me know how you found that repository? I've just now archived the repository.

Can you share the use case for implementing a custom directory? This is very rare requirement...

In any case, you can look at the user directories we implement here: https://github.com/Inedo/inedox-inedocore/tree/master/InedoCore/InedoExtension/UserDirectories

Cheers,
Steve

Hi @joacim-svensson_8194 ,

That should have worked, but it's of course possible there's a bug.

Can you confirm steps?

Is this basically what you did?

1. Create Two feeds (Feed1 and Feed2), download a vulnerable package in each feed
2. Create Two Vuln Sources (OssIndex1, OssIndex2), associate each to each feed
3. Run the "Vuln Downloader" Job, and see two identical vulnerabilities added to ProGet
4. Assess the vulnerabilities differently (1 = Block, 2= Ignore)
5. Package should Blocked on Feed1, and allowed on Feed2

I want to make sure we're following the steps you did, so we can test this.

Cheers,
Steve

Hi @osnibjunior ,

Oh I see -- I must have missed the part, "it seems it manages to list the package that is in Azure Artifact but fails to download when requested resulting in a 404."

Unfortunately it's hard to say what's wrong; Azure DevOps package registries are pretty buggy, and don't always follow the NuGet API specs.... we've worked-around a few of their glitches, but maybe they added one again?

Anyway, if you can provide us with (1) the Connector URL and PAT token and (2) a package that you can't download, we can attach a debugger and see if it's something we can identify/fix.

You can email that to support at inedo dot com, but please enter [QA-1021] in the subject so we can find the email. And please let us know when you send the email, as we don't regularly monitor that box.

Cheers,
Steve

Hi @smiller-circ_2844 ,

Product activation is required. If you're unable to keep the same MachineID, then you'll need to get an activation code from my.inedo.com.

While it's not officially supported and isn't documented, you could "listen" to the activation request that ProGet makes by using a proxy server like Fiddler, and make the same API request with your key. You would then need to add that value to the database.

I don't want to give specific instructions on how to do this, because like I mentioned it's not officially supported -- but it's not "too difficult" to do, if you're familiar with the above.

Cheers,
Steve

Hi @osnibjunior ,

Did you follow our AzureDevOps Migration tutorial?

Based on the information you've entered in the connector, I don't think it will work because your Connector URL looks incorrect (it should look something like https://pkgs.dev.azure.com/kharnagy/kharnagy/_packaging/internal-nuget/nuget/v3/index.json).

I'm not sure about the username/password but I understand you need to create a PAT and use that as well. I think it doesn't matter where you put the PAT (username or password field).

There's nothing in v2022 that should have impacted this

Cheers,
Steve

Hi @OtterFanboy ,

Under the hood, Otter runs PowerShell scripts through a custom PowerShell host that runs within the agent's process. While this generally leads to performance improvements, it can lead to memory leaks or worse if PowerShell scripts are created improperly. It sounds like this is the case here -- especially if your scripts are prompting for input, not terminating, etc.

This is where Process Isolation can come in. Instead of using the agent's process to run the PowerShell script, you can use OtterScript's with isolation feature. This creates a new process that runs the script.

Here is an example of an OtterScript plan that runs the same PowerShell script in different processes, even though it is the same script and runs on the same agent:

for server targetsv
{
    with isolation
    {
        PsExec >>Write-Host "Process ID: $pid">>;
    }
    with isolation
    {
        PsExec >>Write-Host "Process ID: $pid">>;
    }
}

Note that you can also specify timeouts with with timeout=1000 as well.

Cheers,
Steve

hi @cshipley_6136,

We chatted a bit about this as a team today.

We believe that the application failed during initialization (i.e. the first web request after starting the service); when this happens, the error message will be returned until you restart the application (container/service).

This is by design; there's no way to guess where or why the initialization failed, and if we "crash" the application (and trigger a restart), it can end up in a endless loop and make diagnosing really difficult.

In this case, the error is network related (server name not found). That error can be transient when you have network problems, or permanent if it's a typo in the connection string.

Since restarting the application (container) fixed it, then it was a transient network issue that happened during initialization.

Hope this helps,
Steve