Posts made by rhessinger

Hi @Crimrose and @hyt5036_7430,

I just made some tweaks to our 1.9 packages and released the ProGet 5.3.16 compatible extensions as -RC versions. If you change your Extensions.UpdateFeedUrl to https://proget.inedo.com/feeds/PrereleaseExtensions you can install the latest RC version of these extensions and they will work with the proget or progetmono image. Since the proget and progetmono images include the exact same features, you can switch between them without loss of data.

Thanks,
Rich

Hi @churst,

It looks like this may be related to KB#1758. Could you please take a look at this first and let me know if this fixes your issue?

Thanks,
Rich

Hi @anrey-ne_0903,

Is this a new Docker feed you have created? IF so, this may be related to this other post https://forums.inedo.com/topic/3081/a-500-error-occurred-in-d-could-not-find-a-part-of-the-path-var-proget-packages-docker-f1. We currently have a bug that throws an error when pushing to the first feed created in each package type when using the proget Docker image. This will be fixed in ProGet 5.3.17, but that forums post has a manual work around to fix that issue.

If this is not the issue, then my next question would be is this a recent upgrade of the proget docker image?

Thanks,
Rich

Hi @Crimrose,

Chocolatey feeds are a form of NuGet feed that uses the standard NuGet API, but we optimize ProGet's UI to present it in a slightly different fashion. You can see the differences listed in our Chocolatey documentation. This means that you can push chocolatey packages via the NuGet CLI push command. Since you are running this on Linux, you will need to use the .NET Core or .NET 5 based CLI to perform this push.

Alternatively, you can upload this manually in the ProGet UI.

Thanks,
Rich

Hi @Crimrose and @hyt5036_7430,

The difference in the proget.inedo.com/productimages/inedo/proget and the proget.inedo.com/productimages/inedo/progetmono is that the proget image is built using .Net Core 3.1 (it will be .NET 5 in ProGet 5.3.17) and progetmono uses the Mono framework with our code compiled to .NET Framework 4.5.2 as @Crimrose has mentioned above. We actually have a blog post on this.

The issue you are running into is that the Kubernetes extension did not add support for .Net Core until version 1.9.0-CI.5 of the Kubernetes extension. Do not use 1.9.0-CI.6 because that includes on .NET 5 in preparation of ProGet 5.3.17. To install 1.9.0-CI.5, you will need to follow the Extension Manual Install Guide and you will need to make sure to copy the extension to the Extensions.ExtensionsPath inside the container using docker exec -it <image name> sh using the shell or copy it to the folder the container is mapped to on the Docker host.

The Whitesource and Sonatype extensions have this same issue currently.

I hope this helps! Please let me know if you have any questions.

Thanks,
Rich

Hi @harald-s-hanssen_2554 and @viceice,

I was able to finally track down this issue. It seems to only affect ProGet running on Linux (Docker) when attempting to look for existing packages prior to adding a package or image. I have created a ticket, PG-1852, to track this fix. It will be released this Friday, November 20, 2020, in ProGet 5.3.17. Thanks for all the help in troubleshooting this!

Thanks,
Rich

Hi @harald-s-hanssen_2554,

I have found that sometimes I will run into permission errors when created the folder on the host side when using WSL or WSL2. Sometimes if I create the folder on the host side, I end up having to manually chmod the folder inside the container. I have found different Linux OSes and Versions will vary based on this as well.

Thanks,
Rich

Hi @arozanski_1087,

I apologize for all the back and forth I'm struggling a bit to recreate this issue. I have even tried to just add a computer by searching it by name and I still cannot recreate this. Would you be able to perform a test search in the Advanced Settings of your Active Directory provider? Does that also return the computer accounts?

Thanks,
Rich

Hi @arozanski_1087,

You are correct. G is for group or gMSA. The only thing that makes sense is that your AD has a group or a gMSA for your user account with the same name and it is return the group first. You could manually change the DB record to remove the $ and that should then work. But that is an annoying manual step. Can you please verify that the user you are testing with does not have a Group of gMSA named as AROZANSKI$ in AD?

Thanks,
Rich

Hi @harald-s-hanssen_2554,

The current workaround is to manually create the feed folder. For example /var/proget/packages/.nugetv2/F1. This issue only happens when it is the first feed of that package type. We are still looking into the cause of the issue. It is only a problem with the docker image.

Thanks,
Rich

Hi @arozanski_1087,

Thanks for sending that over. I took a look into the code and checked some things and I don't see anything that would look up the computer name. Can you look at the [Privileges] table in the ProGet database? Do the usernames include the $ in there also? Also, do you have any sort of reverse-proxy sitting in front of ProGet?

Thanks,
Rich

Hi @nicolas-morissette_6285,

No problem. I'll let you know if anything is delayed in that release!

Thanks,
Rich

Hi @vaclav-nadrasky_0945,

It looks like there is a bug in the visual editor that is stripping that off. I have created a ticket, OT-382, to track the fix. As for if this is the best practice, I'm going to pass you over to @atripp for that. She is our Otter Script expert.

Thanks,
Rich

Hoi @arozanski_1087,

Can you please tell us what version of ProGet you are running and also, can you please tell us what version of the InedoCore extension is installed on your ProGet instance?

Thanks,
Rich

Hi @nicolas-morissette_6285,

I apologize for the back and forth with them. I just created a ticket, PG-1851, to add a special case for handling this kind of package from Azure DevOps Registry. It is set to release in ProGet 5.3.17 which is due out November 20, 2020.

Thanks,
Rich

Hi @arozanski_1087,

This is really peculiar because we have an explicit filter on all of our LDAP queries to be a user, msDS-GroupManagedServiceAccount, or group. Does each user account have their own group managed service account?

Thanks,
Rich

Hi @nkerifacclaud_6931,

Could you try disabling BitDefender temporarily to rule that out? Also, this could simply be related to the fact that Windows 7 is no longer in support and their may be a security patch to the .Net Framework which is causing the error. Since Windows 7 no longer gets updates, it would not get any new patches for the .Net Framework or the FTP server. We leverage the classes built-in to the .Net Framework for FTP connections.

Thanks,
Rich

Hi @arozanski_1087,

I didn't see this answer before, but are you using LDAP or Single Domain Active Directory (Legacy) or Active Directory (LDAP)?

Thanks,
Rich

Hi @nkerifacclaud_6931,

Thanks for confirming the permissions for me. As for adding the '' character in front of the folder names, I cannot see anywhere in our code that would do that. I do see that ServerPath will prepend a '/' character, but it is clear that the file list is working, so that would not be an issue.

I have been searching for the server returned 550 the specified network name is no longer available and I am seeing quite a lot of people saying this is actually an issue with Anti-Virus on servers or web protection in a Firewall or Network Proxy. This is an error coming directly from the FTP server. Do you have an anti-virus installed on the FTP server? If so, which one? Do you have BuildMaster configured to use a proxy? I see a lot of people complaining about this issue with AVG's resident shield.

@nkerifacclaud_6931 said in Inquiry about buildmaster FTP plugin:

Concerning the phrase "I would also check that your Get-Files operation is not happening until after the files have been put on the FTP server." i don't quite understand. Maybe you can explain again what you are expecting from my side.

Sorry about the confusion on this. I meant whatever tool is copying the files to the FTP server, just making sure the transfer has completed prior to trying to pull the files. Some FTP servers will list a file if a file is currently in transit, but not yet complete. Scenarios this can happen is with CI/CD tools (like BuildMaaster, TeamCity, Jenkins, Azure DevOps, etc...). When those tools are executing operations, scripts, pipelines, etc... in parallel, it can start the FTP file transfer and kick off a pull of these files at the same time. This is more to just rule that out as a possibility.

Hi @arozanski_1087,

Do you have multiple LDAP directories configured?

Thanks,
Rich

Hi @arozanski_1087,

Thanks for following up with us. I'm glad you got this working! Please don't hesitate to reach out if you have any other questions for us.

Thanks,
Rich

Hi @sbolisetty_3792,

I apologize for the delay in this response, but somehow my response never posted. I have assigned this to one of my colleagues to handle identifying the issue and planning the fix. @atripp will take this over from here and she will get back to you when an official fix has been scheduled. Thanks for all the help in troubleshooting this with me!

Thanks,
Rich

Hi @nkerifacclaud_6931,

Good catch, I'm sorry for that, I actually did mean ** for the include property. The error is an interesting error though. I have seen this error commonly occur in two scenarios; 1. The file is deleted prior to the copy step (unlikely but possible) or 2. You have the permissions to list folder contents, but you do not have the permission to read the files. Can you verify that the account you are using for the FTP server has access to read the files on the FTP server? I would also check that your Get-Files operation is not happening until after the files have been put on the FTP server.

Thanks,
Rich

Hi @nkerifacclaud_6931,

I'm not sure I fully follow. Are you trying to download the entire contents of Folder? If so, use the Get-Files and set your ServerPath to /Folder and then Include to *. This should download the entire contents of the folder and its child folders and files. Is that what you are doing now?

Thanks,
Rich

Hi @arozanski_1087,

The errors you are showing here looks like a failure connecting to AD as a whole. One cannot connect to teh AD server at all, which indicates the server is not operational, a bad AD certificate, or a your DNS server still has a the IP address listed for your old domain controller tied to your local domain url (ex: mydomain.local).

The other error message shows a login error for network service. This could need the Set-SPN operation ran to give the server access to the domain, or you need to sepcify the login credentials in the AD settings.

You can reset your selected user directory back to the built in one using the resetadminpassword operation from the Service executable. You can then correct the issue and switch it back to your LDAP directory.

Thanks,
Rich

Hi @nkerifacclaud_6931,

Can you give me a little more detail in what you are trying to do? From what I can see you could specify your ServerPath as the folder you are looking to pull and include all files. Are you specifically looking for the include/exclude masks to work with folders? Or are you looking for something else entirely?

Thanks,
Rich

Hi @nicolas-morissette_6285,

I have dug through our connector code and this looks to be an issue with the Azure DevOps' implementation of the NuGet v3 API, specificially their RegistrationBaseUrl. If you notice in my example above, the dependencies property is an empty array. This is what we are expecting. Since Azure DevOps is actually populatating it with an object, we attempt to parse the dependency, and then the id property is empty which is causing our code to fail. I would submit this as an issue to Azure DevOps. I don't think this is an issue with your NuGet package considering it has the nuspec properly defined and works fine when uploading to ProGet.

Thanks,
Rich

Hi @arozanski_1087,

I'm sure we have asked you this before, but which LDAP user directory are you using?

Thanks,
Rich

Hi @Crimrose,

What version of the ProGet image are you running? Would you be able send over your docker start command? Based on your error message, it sounds like you might have flipped the port mapping in the stat command. When using docker you should be able to map the internal port 80 to any external port on your Docker host that is open.

Thanks,
Rich

Hi @nicolas-morissette_6285,

Could you try uploading you .nupkg directly into ProGet and see if you get any error?

Thanks,
Rich

Hi @antony-booth_1029,

Starting in version 6.2.21, we actually made a new variable function to create the URL for you. You can use the $BuildMasterUrl(build) function and that will generate the URL. If you are running that from within the context of a build, you will not need to specify any other parmaters. You can see more about its usage in the functions reference in BuildMaster by navigating to Administration -> Reference Documentation section -> Functions. We have also added a $BuildMasterId function if you need to get the BuildId directly.

Hope this helps!

Thanks,
Rich

Hi @nicolas-morissette_6285,

This is most certainly interesting to me. This does not seem to be an issue with ProGet from what I can see. I created a simple example based on Newtonsoft.json. I created nuspec file that looks like this:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata minClientVersion="2.12">
    <id>Newtonsoft.Json</id>
    <version>13.0.0</version>
    <title>Json.NET</title>
    <authors>James Newton-King</authors>
    <owners>James Newton-King</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <license type="expression">MIT</license>
    <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
    <icon>packageIcon.png</icon>
    <projectUrl>https://www.newtonsoft.com/json</projectUrl>
    <description>Json.NET is a popular high-performance JSON framework for .NET</description>
    <copyright>Copyright © James Newton-King 2008</copyright>
    <tags>json</tags>
    <repository type="git" url="https://github.com/JamesNK/Newtonsoft.Json" commit="7c3d7f8da7e35dde8fa74188b0decff70f8f10e3" />
    <dependencies>
      <group targetFramework=".NETStandard2.0" />
    </dependencies>
  </metadata>
</package>

I navigated to the URL you specified aboved and got this:

{
  "count": 1,
  "items": [
    {
      "count": 1,
      "items": [
        {
          "@id": "http://proget.localhost/nuget/NoConnPublic/v3/registrations-gz/newtonsoft.json/13.0.0.json",
          "@type": "Package",
          "catalogEntry": {
            "@id": "http://proget.localhost/nuget/NoConnPublic/v3/catalog/newtonsoft.json/13.0.0.json",
            "@type": "PackageDetails",
            "authors": "James Newton-King",
            "dependencyGroups": [
              {
                "targetFramework": ".NETStandard2.0",
                "dependencies": []
              }
            ],
            "description": "Json.NET is a popular high-performance JSON framework for .NET",
            "id": "Newtonsoft.Json",
            "licenseUrl": "https://licenses.nuget.org/MIT",
            "licenseExpression": "MIT",
            "minClientVersion": "2.12",
            "projectUrl": "https://www.newtonsoft.com/json",
            "published": "2020-11-06T20:09:19.47Z",
            "tags": "json",
            "title": "Json.NET",
            "version": "13.0.0"
          },
          "packageContent": "http://proget.localhost/nuget/NoConnPublic/v3/flatcontainer/Newtonsoft.Json/13.0.0/Newtonsoft.Json.13.0.0.nupkg",
          "registration": "http://proget.localhost/nuget/NoConnPublic/v3/registrations-gz/newtonsoft.json/index.json"
        }
      ],
      "parent": "http://proget.localhost/nuget/NoConnPublic/v3/registrations-gz/newtonsoft.json/index.json",
      "lower": "13.0.0",
      "upper": "13.0.0"
    }
  ]
}

My guess is this is most likely an issue with the AzureDevOps registry returning the dependencyGroups incorrectly through the connector. The fact that id and range are specified but do not have a value is definitely what is breaking ProGet because if it is specified we expect it to exist. Are you able to get that registration JSON directly from Azure DevOps' registry and see if you see that empty id and range in there?

Thanks,
Rich

Hi @sbolisetty_3792,

What version of BuildMaster are you running? It looks like the third-party Slack extension was built using the legacy SDK and extension model, which will not work in BuildMaster 6.2.

We recently added documentation on how to POST to Micorosft Team's Webhook connectors. You could very easily adapt this to Slack by creating a new WebHook in Slack and posting to the Slack WebHook URL instead of the Teams Web Hook URL and tweaking the message text you are POSTing.

Here would be an example Slack JSON to POST:

{"text": "**BuildMaster - New Build** $ApplicationName $ReleaseNumber.$BuildNumber has completed. View it at [Build $BuildNumber]($BuildMasterUrl(release))."}

Note: $BuildMasterUrl() is only available in 6.2.21+

Hope this helps!

Thanks,
Rich

Hi @viceice,

I did a few searches and have you tried setting the hostsProxyHeaders> Maybe something like this: traefik.frontend.headers.hostsProxyHeaders=www-authenticate? The docs make it sound like it will look in those headers for URLs that are proxied. You could give that a shot.

Thanks,
Rich

Hi @bju_2095,

Are you using a Nuget.config file for specifying your multiple feeds? From what I can see is Azure DevOps wants you to use the NuGet.config when specifying multiple NuGet feeds. I would lean towards this being an issue with Azure DevOps. Can I confirm that you are using ProGet 3.2? You could create a new feed in ProGet with connectors pointing to the existing two feeds you need. Then Azure DevOps would only need to connect to one feed.

Thanks,
Rich

Hi @harald-somnes-hanssen_2204,

The fix is scheduled for release in ProGet 5.3.16 which is due out on Friday. I'll reply back if anything changes.

Thanks,
Rich

Hi @bju_2095,

It looks like Azure DevOps is looking to use a username and password with ProGet but the username is not set. If you are using an API key, then you would need to use api for the username and then your API key as the password. Is that what you are currently using to connect to ProGet?

Thanks,
Rich

Hi @viceice,

Thanks for sending this over. I will be debugging this issue more this week.

Thanks,
Rich

Hi @viceice,

Thanks for testing this for me. I think I may see your issue. When the Web.BaseUrl is set to https://proget-test.kriese.eu, the connector should use the URL https://proget-test.kriese.eu/nuget/b/v3/inedx.json. If you set it up that way, do you still get the license violations?

I'll look into the license key issue. It should work as the documentation describes it.

Thanks,
Rich

Hi @harald-somnes-hanssen_2204,

Thanks for following up with this. I have currently updated that documentation to clarify that the Free/Open Source Packages Feed usage requires at least one connector configured before packages will be displayed. Hope this helps!

Thanks,
Rich

Hi @viceice,

Looking back at your other forums post. The last fix we released should allow you to set the Web.BaseUrl and with the addition of X-Forward* headers in your reverse proxy, it should not give you those license errors any more? Were you able to verify that it still does give oyu the licenses errors?

Thanks,
Rich

Hi @arozanski_1087,

Technically they do not need to run as the same account, but it does simplify things. Especially since they share the configuration file that contains the connection string. Also, please make sure that your IIS has the correct features installed. You can see the Configuring IIS Roles & Features for Inedo Products documentation for that information. Were you using that exact service account previously on the integrated web server install? If you were there shouldn't be any iossue connecting from IIS then.

Thanks,
Rich

@viceice Good catch! @csyy321_2677 Could you update your port as @viceice has described and let me know if that works?

Thanks,
Rich

Hi @arozanski_1087,

Thanks for clarifying that for me. You will also need to make the ProGet windows service run as that account also.

Your SQL Server Connection string should look similar to this:

Persist Security Info=False;Integrated Security=true;  
    Initial Catalog=ProGet;Server=<SQL SErver Name>

When you add your service account to SQL server, are you using the UI or are you using a SQL script? I ran into some weird issues using a service account where the only way SQL Server would format it correctly was by adding it through the UI. This was probably due to the unique environment at that company, but I have seen that happen.

As long as the Application Pool and Windows Service run as that account and you add that service account to have the ProGet database access as you listed above, there should not be any issues authenticating. I have also seen some companies that have GPO require users to run as a service to be setup within Group Policy. Can you verify you do not have any run as a service restrictions? You can also try to add that user to run as a service locally on that computer (you don't typically need that, but service accounts operate slightly different.)

Thanks,
Rich

Hi @arozanski_1087,

I apologize, can you please clarify this for me? Are you referring to ProGet connecting to SQL Server altogether or a user logging in with integrated authentication?

If it is ProGet connecting to SQL Server, please check the user on the Application Pool in IIS has access to the database. You may either need to change what user the application pool is running as or you will need to add the application pool user to the SQL Server database (ex: IIS APPPOOL\ProGet) You can only add an App Pool user if SQL Server in on the same server).

Thanks,
Rich

Hi @arozanski_1087,

It may be easier to disable Integrate Windows Authentication and then try to migrate it to IIS. If you do that, does everything work? Or do you see errors? If you see errors, what are they?

Thanks,
Rich

Hi @sbolisetty_3792,

Thanks for sending this over. I see what is happening but I need a little bit of time to diagnose it furthur. It looks like the issue is when you sepcify an environment on the Secure credential. If you remove the environment on the secure credential (but leave it on the server), it will work fine. I'm going to dig in furthur to determine what is going on. I'll let you know when I have more information.

Thanks,
Rich

Hi @viceice,

This is very weird to me. When you call docker login, you said it is initially doing a get to http://proget-test.kriese.eu/v2/ not https://proget-test.kriese.eu/v2/. This means that there is something configured in your docker client to not use https in docker requests. The reason ProGet is returning an http:// based realm is because the initial request is being made non-https URL.

Can you send a screenshot of your command output in the docker login process?

Thanks,
Rich

Hi @sbolisetty_3792,

Would you be able to share a screenshot of your Private Key credentials modal and your server configuration modal? Also, do you have an environment configured on either your server or your private key?

Thanks,
Rich

Hi @viceice,

What about your docker daemon.json? By default, docker will use https, unless if the host is listed within the insecure-registries in your docker daemon.json. Can you please verify that URL does not exist in that list?

Thanks,
Rich