@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

Hi @joacim-svensson_8194 ,

A vulnerability is tied to a vulnerability source (you can see the source name on the vulnerability page), and a vulnerability source is tied to one or more feeds.

So when you create a second vulnerability source, then you'll see two sets of vulnerabilities and be able to assess each vulnerability differently.

Cheers,
Steve

Hi @cshipley_6136 ,

Based on this, it looks like there are some network problems between ProGet and your SQL Server:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.

It's really easy to reproduce this error (just make a typo in the server name) but when it's intermittently happening, it means the problem is happening within the network, between the two servers.

Unfortunately you won't be able to find any useful information on the SQL Server side, since the connection cannot be established. And the same is true on the ProGet side, for the same reason.

This is definitely something to bring up with your Network/Operations team. It could be anything from DNS issues to router configuration to a bad/failing switch.

Best,
Steve

Hi @cshipley_6136

Can you give more details about the error messages you were seeing? You mention it's a login error, like a bad SQL password or account or something?

The health check (/health) runs the Feeds_GetFeeds procedure... so it should have given a 500 error / crashed if the database couldn't be connected.

We'll try to reproduce the failed failure, and get it fixed asap.

Cheers,
Steve

Hi @tyler-engelhardt_8011 ,

I looked at the docs briefly, but I'm really not familiar enough Ansible to know what could be the issue, or how they try to run Chocolatey behind-the-scenes. It's most certainly a configuration issue in your Ansible script though.

So far as I can tell, Chocolatey is not installed on the server, so Ansible is trying to look for a file called install.ps1 on the ProGet server (which obviously wouldn't be there) to install Chocolatey. That file is located here: https://community.chocolatey.org/install.ps1

I would try contacting the Ansiblesupport team or play around with the parameters like bootstrap_script. Please let us know what you find.

Cheers,
Steve

Hi @lm ,

We don't track that information on the package history page at this time; you'll have to find it under Admin > Events.

It's definitely something we can consider with/after v2023, once we've centralized information about packages in the database. I'll make a note of that!

Cheers,
Steve

Hi @lm,

Unfortunately it's not trivial to get a reliable URL for the package within the webhook module/code now, so it's not something that's easy to add on our end. The URL you have works for NuGet, but for other formats (Ruby, Debian, etc.) you need to include more information I believe.

After v2023, where we plan to centralize a lot of this, it might be easier to reconsider this. But for now, what you have is the best/easiest solution.

Cheers,
Steve

Hi @lm ,

Can you give a little more insight into the use case for this? Why would you want to proxy these symbols?

There doesn't seem to be much gained by caching/proxying symbols, since the symbols basically contain a pointer to a public GitHub repository (or a public source server with the older format of PDB), which wouldn't be practical to cache/proxy.

Cheers,
Steve

Hi @lm ,

We've considered this over the years, but realized it'd be more engineering effort that just changing cookie duration; we'd want to track login sessions on the server side, allow them to be invalidated, etc.

It's possible, but it seems the "Remember me" function on most services (GitLab, etc.) seems to be very forgetful anyways (for security purposes), and with Integrated Windows Authentication and browsers managing passwords, it seems not so valuable for the effort.

Cheers,

Steve

Hi @paul_6112,

There is no built-in blocking to BuildMaster/Inedo agent, and each execution (deployment) uses a separate temporary directory, so there's no conflict on "our" side of things.

However, if you wanted blocking of sorts, you could create resource pools if you'd like to do that, or use lock statements.

Cheers,
Steve

Hi Scott,

Glad you could resolve it; definitely a strange error, I would have expected a better one than just 500.30.

How did you install ProGet? Using the Inedo Hub?

"The Module DLL C:\Windows\system32\inetsrv\aspnetcore.dll failed to load. The data is the error" -- this sounds like a sort of internal error, caused by the .NET6 hosting bundle not being installed, or not installed properly.

https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/hosting-bundle

The Inedo Hub will install this when you install/upgrade to v2022.

Thanks,
Steve