Hi @atripp

Unfortunately the setApiKey is not supported by the dotnet CLI.

Dotnet tooling regarding package management is not ideal when it comes to nuget and dotnet nuget.

Thanks for your replies.

Hi @atripp ,

I already tried dotnet nuget add source and it works except it fills in our CI logs with full of the following warning.

warn : No API Key was provided and no API Key could be found for 'https://host/nuget/feed-name/package'. To save an API Key for a source use the 'setApiKey' command.

So I thought using the --api-key parameter would be a better choice and the a permission like the one I mentioned above would really help get this issue fixed.

Hello,

I realize that one has to grant Feeds_ViewFeed permission to the anonymous user in order for package publishing to work and the reason behind that is because dotnet nuget push... makes a request to the https://host/nuget/feed-name/v3/index.json URL first without passing in the api key provided using the --api-key parameter in order for getting the following response.

{
  "version": "3.0.0",
  "resources": [
    {
      "@id": "https://host/nuget/feed-name/v3/search",
      "@type": "SearchQueryService",
      "comment": "Query endpoint of NuGet Search service"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/search",
      "@type": "SearchQueryService/3.0.0-rc",
      "comment": "Query endpoint of NuGet Search service"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/search",
      "@type": "SearchQueryService/3.0.0-beta",
      "comment": "Query endpoint of NuGet Search service"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/autocomplete",
      "@type": "SearchAutocompleteService",
      "comment": "Autocomplete endpoint of NuGet Search service"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/autocomplete",
      "@type": "SearchAutocompleteService/3.0.0-rc",
      "comment": "Autocomplete endpoint of NuGet Search service"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/autocomplete",
      "@type": "SearchAutocompleteService/3.0.0-beta",
      "comment": "Autocomplete endpoint of NuGet Search service"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations/",
      "@type": "RegistrationsBaseUrl",
      "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations/",
      "@type": "RegistrationsBaseUrl/3.0.0-rc",
      "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations/",
      "@type": "RegistrationsBaseUrl/3.0.0-beta",
      "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations-gz/",
      "@type": "RegistrationsBaseUrl/3.4.0",
      "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations-gz/",
      "@type": "RegistrationsBaseUrl/3.6.0",
      "comment": "Base URL of Azure storage where NuGet package registration info is stored in GZIP format. This base URL includes SemVer 2.0.0 packages."
    },
    {
      "@id": "https://host/nuget/feed-name/v3/flatcontainer",
      "@type": "PackageBaseAddress/3.0.0",
      "comment": "Base URL of where NuGet packages are stored, in the format https://api.nuget.org/v3-flatcontainer/{id-lower}/{version-lower}/{id-lower}.{version-lower}.nupkg"
    },
    {
      "@id": "https://host/feeds/feed-name/{id}/{version}",
      "@type": "PackageDetailsUriTemplate/5.1.0",
      "comment": "URI template used by NuGet Client to construct details URL for packages"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations/{id-lower}/index.json",
      "@type": "PackageDisplayMetadataUriTemplate/3.0.0-rc",
      "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID"
    },
    {
      "@id": "https://host/nuget/feed-name/v3/registrations/{id-lower}/{version-lower}.json",
      "@type": "PackageVersionDisplayMetadataUriTemplate/3.0.0-rc",
      "comment": "URI template used by NuGet Client to construct display metadata for Packages using ID, Version"
    },
    {
      "@id": "https://host/nuget/feed-name/",
      "@type": "LegacyGallery"
    },
    {
      "@id": "https://host/nuget/feed-name/",
      "@type": "LegacyGallery/2.0.0"
    },
    {
      "@id": "https://host/nuget/feed-name/package",
      "@type": "PackagePublish/2.0.0"
    }
  ]
}

However, granting Feeds_ViewFeed permission to the anonymous user also grants permission to view feed pages where packages are listed. E.g.: https://host/feeds/feed-name.

Since viewing a feed and the packages inside it and requesting feed resources are two separate things, what about having another permission like Feeds_RequestResources that is separate from the Feeds_ViewFeed permission so that if a NuGet client directly sends a request to the https://host/nuget/feed-name/v3/index.json URL, anonymous users are allowed but if they want to view a feed, they are not.

That should be pretty easy for the ProGet team to understand if the request is a so called resources request since that is already what you are doing, you are correctly responding to the initial request by providing the resources.

May I have your opinion please?

P.S. Any workaround suggestion is welcome. My ProGet instance is running on Docker and is accessed using IIS ARR via rewrite.

Regards,
Coskun

Hi @atripp and @rhessinger

I gave up with the installer and decided to use the docker image. It works fine.

I suggest you test the installer in the exact scenario I described above. It might cause trouble for other users.

Thank you for your replies.

Hi @rhessinger

Thank you for your kind and informative reply.

This almost sounds like the .NET Framework failed to install some needed components to connect to SQL Server.

I am not sure. Installer verifies the connection before starting the connection successfully. Other "test apps" I created to test .NET apps' connections to the SQL instance works fine even when they are hosted under different credentials on IIS. E.g. App Pool Identity, Network Service, what not. SQL instance is set to use TCP port 1433, that is allowed on the firewall. SQL Browser uses UDP port 1434 and that is allowed as well. What is more, installation fails even when the firewalls are disabled on both the web server and the SQL server.

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?

Believe me I tried already. The .\INEDO instance is installed on the web server now but making a new installation that points to the remote SQL still doesn't work. Does having .\INEDO instance rule out this possibility? So, both servers have SQL installed now, installation on .\INEDO works, installation on 192.168.4.21\MSSQLSERVER2019 fails. But both other test applications and the SQL Server Management Studio can connect to 192.168.4.21\MSSQLSERVER2019 without any issues.

That being said, even the Traditional Installer you have works just fine with 192.168.4.21\MSSQLSERVER2019.

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.

It is currently fully disabled on both servers since they are just empty servers.

Please see the following screenshot, Azure Data Studio is connected (green dot) to both SQL servers (INEDO and my own). I can run queries and do what ever one can do on an SQL server instance.

Regarding the servers, they are pretty standard installations of Windows Server 2019 with latest patches installed. Web server has IIS and related stuff installed, including .NET Framework workloads. SQL server doesn't have anything installed except SQL Express 2019. Please remember that the same issue happened on another couple of servers - they were both Windows Server 2016, not 2019 but the result is the same.

I can assure you that there are no firewall issues involved here (both disabled), .NET Framework is installed and is not corrupted (other .NET Framework apps work fine), the servers can reach each other (no network issues, they are virtual machines sitting next to each other). The installer not reporting any error is not helping much of course.

Back to the Network Service user, thank you for the insights. However, I am talking about the installer trying to add Network Service login. It is not just that the service and web app are run as Network Service but the installer also adds the Network Service login to the SQL database. My servers are not in a domain environment, there is no domain controller. Please see the following, this instance was installed using a connection string that has SQL login, not Windows authentication. But you still add the mentioned login - even if it is disabled.

Finally, one reason I am so confident that everything is in place is because the traditional installer works fine and then ProGet also works fine as an ASP.NET app and a Windows Service.

Thank you for your patience as well.

Hi @atripp

I believe my assumptions are correct.

I installed management studio to check what is going on inside .\INEDO and realize that, no matter what kind of connection string I provide, you try to add NETWORK SERVICE as a user to the database, I might be wrong, just a rough assumption I can make is that you do so because the PROGET service is running as NETWORK SERVICE.

I believe, even if the service is running as NS, it should respect the connection string we provide during installation and shouldn't try creating additional logins and users for those logins.

Since NETWORK SERVICE can easily access C:\ProgramData\Inedo\SharedConfig\ProGet.config, why do you really need to work with NS login on SQL? Obviously that is causing problems.

@atripp if it was a connection issue, I would expect the traditional installer to complain as well. The firewall is configured properly, even disabled during the installation.

Have you tested the remote SQL scenario outside of a domain environment, which I believe completely eliminates the possibility to use Windows Authentication and somehow something within the installer insists on using Windows Authentication? Like the service running under Network Service account.

What makes me think that the problem might be related to account is the following statement from your manual installation documents.

Since most installations will use Integrated Authentication, a database server login for the ProGet user identity is required.

osql -E -S <db-server> -Q "CREATE LOGIN [domain\ProGetServiceUser] FROM WINDOWS"

Note that built-in accounts may be used, such as NT AUTHORITY\NETWORK SERVICE or NT AUTHORITY\LOCAL SYSTEM, though an actual domain account is recommended.

I wish your docs had detailed instructions. It is the 7th day I am simply trying to install an app :/
Don't get me wrong, I am not complaining, it is free and I appreciate your support but I would just expect at least good error messages so that I can fix the issue and move on.

Installing an app in an ideal environment where anything else works shouldn't be so hard. I even installed fresh servers because you said I am the only one having this issue because yes I could have something else blocking the installation but it looks not.

Imagine that an ASP.NET rMVP cannot install an ASP.NET app on freshly installed servers where Windows Defender and Firewall are both disabled :) And everything else works on these servers, I mean, other ASP.NET apps. They have no trouble connecting to the SQL server, etc.

Unfortunately I am almost giving up.

I appreciate and respect the support and assistance you provide though.

Hi @atripp and @rhessinger

In addition to my last post, it seems that it is not a permission issue. I decided to use the sa user out of curiosity and it doesn't work. sa user should have all the permissions the installer needs.

Do you think this is a bug within the installer that blocks installations when a remote SQL server instance is used?

Note that the same SQL instance works fine when I use the traditional installer.

Hi @atripp and @rhessinger

I have got some news.

I just freshly installed a Windows Server 2019 instance, tried the installer and got the same error.

Brand new server, brand new OS, brand new SQL Server instance (both 2019) and the result is the same.

However, I figured that if I use the integrated SQL Express instance, I can install ProGet successfully.

It seems that I am doing something wrong while configuring the database instance. Can you help me figure out what I am doing wrong?

The steps I take to configure the database is:

1. Create an empty database (ProGet)

2. Create a new SQL login (ProGetUser), set user mapping as "db_owner" for the database created in step one so that the user has rights to create and manage schemas, etc.

3. Start installation of ProGet

4. Select "Specify instance..." and set the connection string as

Server=192.168.4.21\MSSQLSERVER2019;Database=ProGet;User Id=ProGetUser;Password=P@ssw0rd

Please note that the SQL server instance is installed on another server within the same network.

5. Set "Database Name" option as "ProGet" (it was also specified in the previous step and they match)

6. Start the installation

The SQL login is set as db_owner so it should not have trouble accessing the ProGet database (it successfully validates the configuration before starting the installation).

Am I missing something while configuring the database or its security? Can it be because the SQL server is installed on another server and the network service cannot reach the database directly? And if so, probably not, shouldn’t it just use the username and password I provided within the connection string? Am I doing something wrong while trying to create the database myself and asking ProGet connect to it instead of allowing it to create the database? If I have to allow ProGet to create its own database on my SQL instance, how should I really specify the connection string that I mentioned in 4th step above?

@atripp said in ProGet installation issue without any logs:

Unfortunately, I don't know what we can do from here.

Better logging hopefully :)

Thank you for your assistance anyway.