Posts made by rhessinger

Hi @Fred,

Does the HTTPS url (https://proget.xxx.com) work in your browser as well?

Thanks,
Rich

Hi @kichikawa_2913,

Sorry, this is actually expected. When we release our products, they include the extensions that were released at the time of the product release. In this case, I released this version of InedoCore after we did the product release.

If you look at our documentation for upgrading your docker image, the command includes --volumes-from=proget-old. This will auto migrate the previous volumes created from the previous version of ProGet and that will keep the updated extension (as long as the previous extensions is newer than the included extension version).

Also, in Administration -> Advanced Settings, you can change Extensions.ExtensionsPath to a mapped path and that will also do the same thing (if the version in this directory is newer than the included) and give you easier access to the extension files.

Thanks,
Rich

Hi @kichikawa_2913,

I'm sorry for not including that in my previous comment. You are correct 1.10.7 is the new version of the InedoCore extension that includes these fixes for LDAP and LDAPS on Docker.

Thanks,
Rich

Hi @kichikawa_2913,

I just released this extension to production now. Please let me know if you don't see an official release.

Thanks,
Rich

Hi @kichikawa_2913,

Did those users still experience the long initial login? Or did that go away?

Thanks,
Rich

Hi @kichikawa_2913,

You should just be able to remove the custom port and uncheck LDAPS then restart your container and that should remove LDAPS from your AD instance.

Thanks,
Rich

Hi @kichikawa_2913,

Thanks for the information and I'm glad you can log in now. Let me dig in and see what I can find on these Anti-CSRF errors. Normally these happen because a reverse proxy is not properly forwarding headers. Do you have a reverse proxy (like Nginx or apache) sitting in front of this container? Also, do you know if once they get logged in if ProGet seems to run fine, or does each page request take a while to load?

Would you be willing to test this without LDAPS so we can see if it is an LDAPS issue or not?

Thanks,
Rich

Hi @kichikawa_2913,

I'm going to attempt to recreate your error on my system as well and see if I can find this issue. LDAPS on Docker has not been a popular option with our customers so far due to the complexity in managing the AD certificates. I really appreciate your patience in working through this with us.

While I try to recreate this, could you try using an incognito browser and see if you are able to load and login? Also, can you try to restart your container again? Also, can you please verify the LDAPS connection is still working with the openssl command again?

Thanks,
Rich

Hi @kichikawa_2913,

I think I have identified the issue. I have just pushed another version of InedoCore, version 1.10.7-CI.2 . Could you update and give that a try? I also added an option to bypass the LDAPS certificate verification. It is something that I would only use while testing. The solution you have with adding your certificates as valid certs is a more secure solution. One last thing to make sure you set is the Domain Controller Host. It can just be set to your domain (ex: domain.network using your steps from above). Linux/Docker does not seem to translate domain URLs the same way windows does.

Thanks,
Rich

Hi @kichikawa_2913,

Unfortunately, these logs do not show any errors (outside of a couple of resource images failing to load). Do you see any errors in your Diagnostics Center in the administration page?

As for the port, upon further inspection, it looks like the port handling was removed when we upgraded ProGet to support .NET 5 on Docker. It used to parse it off the Domain Controller host address, I have now added it as a separate field that you can set. If you can upgrade your Inedo Core extension to 1.10.6-CI.13, that will give you the option to enter a custom port number. Could you please give that a try and see if that works?

Thanks,
Rich

Hi @kichikawa_2913,

Did you see any sort of error when using LDAPS? I don't see one in your previous logs message. Also, are you using the standard port (636) for LDAPS?

Thanks,
Rich

Hi @coskun_0070,

Thank you for your patience. I know how frustrating this can be, especially for something as simple as an installation. As Alana stated, this is the first time we have really seen this issue and your architecture is a very typical setup for our users. Normally the only thing you need to do is specify your SQL Connection string to your SQL Server and this install without issue.

Typically when installing using the Inedo Hub, if you have the connection string using Integrated Authentication it will use the current user's account to connect to the database and any file access needed while installing. Once it is installed, it will then use Network Service by default, but you can change the account the service and IIS run as. If you specify a SQL auth based username and password in the connection string to your SQL server in Inedo Hub, Inedo Hub will then use that account to connect to SQL server, the current user for any file access needed during the installation, and then it will default the Service and Web App to run as Network Service.

With all that being said, I don't think it is the Network Service account that is having issues because that will only be used after the installation. This almost sounds like the .NET Framework failed to install some needed components to connect to SQL Server. That would explain why installing SQL Express fixed the installation issue for you. Would it be possible to install SQL Server Express on your server then try to install ProGet using Inedo Hub with a connection string using sa pointing to your SQL Server instance on the other machine?

One last thing to try is to temporarily turn off Windows Firewall on your server. I'm wondering if Inedo Hub got blocked trying to communicate to SQL Server and that is causing this issue as well.

Thanks again for your patience and for working with us on this issue.

Thanks,
Rich

Hi @kichikawa_2913,

That's great! Thanks for giving me an update. LDAPS is definitely more of an advanced configuration option currently. The hardest piece of LDAPS is getting and keeping the certificate valid and up to date in the Docker container. It depends on how you have your AD server setup, but they typically regenerate their certs and distribute them automatically. We actually use a third-party library Novell.Directory.Ldap.NETStandard for our AD connection in Docker due to the LDAPS support missing from the built-in one for .NET 5.

As I stated before, creating a new image using the ProGet image as your base image tends to be the easiest way to add certificates to your container. Our image is built on top of dotnet/aspnet:5.0.5 (Debian 10 based). There are a handful of ways to do this.

• Using ProGet as a base image, add the domain cert file(s) in the DockerFile
• Using ProGet as a base image, add a mapping to the certificate folder in your DockerFile and manage that on your host.
• use docker exec to add the certificates after the image has started
• etc...

Stack Overflow can be helpful in adding certificates to your containers for your AD setup. Right now we have not determined a standard way of setting this up since each instance we have dealt with seems to be configured differently, but we always look for feedback in this configuration process.

Thanks,
Rich

Hi @philippe-camelio_3885,

I have just built a new CI version of the [Scripting Extension 1.10.3-CI.3] (https://proget.inedo.com/feeds/PrereleaseExtensions/inedox/Scripting/1.10.3-CI.3). This version includes the Minimum Version on Ensure PS Module and adds a new Ensure-PsRepository operation. Please take a look and let me know if you have any issues.

Thanks,
Rich

Hi @kichikawa_2913,

I have a build of the InedoCore extension 1.10.6-CI.11 that should resolve this issue. I have tested this in our lab and it has corrected the issue for me. Could you please try to upgrade this extension to see if this fixes your issue? The easiest way to install the pre-release extension on Docker is to follow the instruction listed in our pre-release extension guide.

Thanks,
Rich

Hi @kichikawa_2913,

We have identified the issue and are working on a solution. The good news is that this is an issue with our InedoCore extensions, so once we correct this, you will be able to just update that extension. I will let you know as soon as we have something for you to try (it should be tomorrow).

Thanks,
Rich

Hi @coskun_0070,

Yeah, that rules out an internet connection. We actually have a decent amount of logging during the process, but for whatever reason, this error is happening before we really start anything on the install process. As Alana stated, this is most likely happening during the initial package extraction. I'm going to talk with our installer team and see if we can add better error logging in those early stages of the install process. That should help with this process in the future.

Thanks,
Rich

Hi @bozho_2851,

You may have to restart your ProGet webserver (IIS or Integrated Web Server) to clear this message. You shouldn't need to but the violation may still be cached and restarting the webserver may correct this for you.

Thanks,
Rich

Hi @coskun_0070,

Glad that the traditional installer worked for you. I agree using the Inedo Hub is the preferred option since the traditional installer will be removed in the future.

Could you try to generate an offline installer using the InedoHub? That should at least tell us if it is a problem with the hub connecting to the internet or if it is a problem extracting the files locally. Also does your server have any sort of third party firewall it is connecting through? If so, it might be worthwhile to verify the connections are not getting blocked as well.

Thanks,
Rich

Hi @bozho_2851,

Does your ProGet instance sit behind a proxy, like nginx? We have seen this issue with self connectors when connecting to itself via the proxy address. If so, you can try to use the hostname of the server or 127.0.0.1 in your URL in place of the FQDN.

Thanks,
Rich

Hi @kichikawa_2913,

Thanks for providing this additional information. Please give me a bit of time to review this and get back to you. I was able to recreate this issue on the ProGet image, but I need to find the root cause of this first.

Thanks,
Rich

Hi @kichikawa_2913,

We don't have much experience with Podman, we typically use the Docker engine, but not having networks should be OK as long as you can access the database server from the container.

I think the first issue is that you will need to use the username as just user instead of user@domain.network.

The next piece is LDAPS. One thing that is tricky is that your domain has to have a valid certificate. Self-signed (or domain generated) certificates don't seem to work in most cases. We have had some success from customers who have registered the certificates inside the container. Typically you would add the certificate by creating a new docker image based on the ProGet image.

Hope this helps!

Thanks,
Rich

Hi @coskun_0070,

Are you using any sort of proxy on your server?

Thanks,
Rich

Hi @kichikawa_2913,

I have forwarded this over to our licensing team, they should be reaching out to you shortly.

Thanks,
Rich

Hi @philippe-camelio_3885,

Thanks for the information. I'll let you know when I get the minimum version added and you can give it a try.

Thanks,
Rich

Hi @flavio-campana_0936,

BuildMaster 7 currently supports SDK 1.12. When running in Docker, it supports a minimum SDK of 1.9. On Windows, it supports a minimum SDK of 1.0.

Thanks,
Rich

Hi @coskun_0070,

Do you see any errors in your windows event viewer?

Thanks,
Rich

Hi @flavio-campana_0936,

Thanks for bringing this up with us. We have fixed this issue in 7.0.0-rc.59 image. I will also be updating the documentation shortly for BUILDMASTER_SQL_CONNECTION_STRING.

Thanks,
Rich

Hi @philippe-camelio_3885,

Thanks for the information. I'll look at adding a new operation Ensure-PsRepository which at least should help with adding the repo for installing modules. I'll also add MinimumVersion to the Ensure-PsModule operation as well. I would expect it to take either version or minimum version but not both. Do you see any issues with that solution?

Thanks,
Rich

Hi @philippe-camelio_3885,

Thanks for bringing this to our attention. I have created a ticket, OT-414, because I believe this is a problem with the UI, not the underlying Git raft. If this ends up being an issue with the extension, I'll update this post and let you know.

Thanks,
Rich

Hi @philippe-camelio_3885,

What it looks like is happening is that the repository registered to the DSC module is not reachable via the Install-Module command. The Ensure-PsModule operation runs the Install-Module PowerShell command. I think the best way to test this is to run Get-PSRepository and see if your repository is listed in that operation.

It shouldn't be too difficult to use PSEnsure to make a script to add the repository to be used with Ensure-PSModule.

I do have a question though. Is there a reason you are using MinimumVersion over Version?

Thanks,
Rich

Hi @Stephen-Schaff,

I was finally able to recreate this error and I believe I fixed it in PG-1948. This is set to be released on Friday in ProGet 5.3.28. If you would like to apply the fix now, I have attached a SQL script to PG-1948 and you can run it against your ProGet database. If you run this script, it will not affect future upgrades of ProGet.

Thanks,
Rich

Hi @m-janssen_0802,

Thanks for sending this over, it was very helpful. From the looks of it, ProGet returned no results when searching for NUnit. If you retry your build again, does it pull the package again? Do you notice this only happening under heavy load on your ProGet server? Or does this seem to happen anytime?

Thanks,
Rich

Hi @m-janssen_0802,

Could you answer a few questions for me?

• What version did you upgrade from that did not have this issue?
• Do you have any connectors on this feed?
• The packages that are returning not found, are they local packages, remote (connector) packages, or both?
• Would you be able to provide us IIS logs and/or Fiddler logs (exported as .saz files)? You can email these to support@inedo.com and include [QA-561] in the subject, just let us know and we will keep an eye out for them.

Thanks,
Rich

Hi @philippe-camelio_3885,

Looks like I spoke too soon. The release team already corrected the link, so it should work with the default link now.

Thanks,
Rich

Hi @philippe-camelio_3885,

It looks like the InedoAgent files were uploaded with the wrong version tag. I have reached out to our release team to try to get this resolved, but in the meantime, if you change the download URL to http://cdn.inedo.com/downloads/inedo-agent/InedoAgent.49.0.0.zip, it should resolve this error.

Thanks,
Rich

Hi @philippe-camelio_3885,

You can update the config of the Inedo Hub to point to our pre-release feed and install using the InedoHub. To do this, please see our Prerelease Products portion of the Inedo Hub documentation. Hope this helps!

Thanks,
Rich

Hi @philippe-camelio_3885,

I have just built a pre-release version (3.0.5-ci.3) of Otter you can install to test out this feature. Please let me know if you have any issues.

Thanks,
Rich

Hi @philippe-camelio_3885,

Agent 49 will work with both Otter 2.2 and Otter 3.0. I'm not sure I understand your second question, but you should be able to use the same agent install on more than one intance (Otter 3 and Otter 2.2) at the same time without issue. Basically, you can add that same agent to both Otter instances you have.

Thanks,
Rich

Hi @Stephen-Schaff,

After looking into this further, the License Detection & Blocking feature is primarily intended for third-party developer packages; Helm charts are generally first-party, and even the third-party charts don't have a consistent license format. Due to the inconsistency in their license format, we are not able to leverage this in Helm charts. We have added a ticket, PG-1937, to remove the display of licenses from Helm charts.

Thanks,
Rich

Hi @Stephen-Schaff,

I was able to recreate this issue. It looks like ProGet is currently not parsing the LICENSE file. Let me discuss this with the products team and I will let you know how we plan to proceed.

Thanks,
Rich

Hi @nicolas-morissette_6285,

Always glad to help! Thanks for giving us an update and letting us know that this fixed your issue. Unfortunately, the package count is a side effect of ADO not implementing the search API. It does not give us the ability to get a package count.

Thanks,
Rich

Hi @nicolas-morissette_6285,

We have released this change in ProGet 5.3.26. I apologize for not replying sooner. If you upgrade your ProGet instance, then you can update your NPM connecter and select the Exact Match Only option on the connector configuration. That will then allow you to see all your local packages and still allow you to search by the exact name of your NPM packages on Azure DevOps Connector.

Thanks,
Rich

Hi @JonathanEngstrom,

You can find a list of the available arguments in the InedoHub CLI documentation.

Hope this helps!

Thanks,
Rich

Hi @nicolas-morissette_6285,

I'm still waiting for feedback from the products team, but my idea is to basically add a setting that allows you to disable listing/searching the packages on that connector and only allow exact name matches in the UI. We do a similar thing for Docker connectors because not all registries support listing or searching. The product change ticket tracking this fix is PG-1916. I will reply as soon as we have confirmed the fix and scheduled it for release. I'm hoping we can get it in for ProGet 5.3.26.

Thanks,
Rich

Hi @joshuagilman_1054,

I was able to reproduce this error and fixed it in ticket PG-1917. We will be making a ProGet release, 5.3.25, later today and this fix will be included.

Thanks,
Rich

Hi @nicolas-morissette_6285,

I took a look into this and what I have found is that Azure DevOps does not support the NPM search API which is why this errors. I created a connector to the Azure DevOps npm feed and then used a username of token, set the password to the PAT (not Base64Encoded), and then selected Basic authentication. The list of all packages will not work, but if you navigate directly to the package or pull through npm, it will access the package. In my case, I was able to navigate to http://PROGET_SERVER/feeds/NPM_FEED_NAME/PACKAGE_NAME/versions and it would load the package's page.

I'm currently working with the products team on a solution. I'll let you know when I have more information for you.

Thanks,
Rich

Hi @jerome-jolidon_1453,

Thanks for the extra information, we will make sure to get the UI fixed to properly show that the package is blocked and we will also get the documentation updated for this as well.

Thanks,
Rich

Hi @jerome-jolidon_1453 ,

If you navigate to the connector's overview page, you should see a link called configure filtering to the right of the Package Filters heading. That will show you your filtering level. I agree with your comments on our filtering documentation. I have also contacted our products team to do a rewrite of this documentation.

Thanks,
Rich