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

Hi @aneequaye_1868,

I apologize, I was speaking from the mapped folder on the Docker host. Inside the container, it is still /var/proget/packages. Does this still happen on the latest version of ProGet? We did make some changes to how the headers are returned in the latest version, especially for feeds that require authentication.

Thanks,
Rich

Hi @viceice,

I was just about to link you to another forums post about X-Forward-* headers, but I realize that post was with you. Just out of curiosity. Are you using a different URL for your docker feed than your nuget feed? Also in your docker client, do you have your URL registered as an insecure registry?

Thanks,
Rich

Hi @viceice,

Thanks for the information. Let me dig into this a bit further and let me work on recreating it. Hang tight!

Thanks,
Rich

Hello @viceice,

What version of ProGet are you running? There was a bug that was fixed on ProGet 5.3.15 that corrected the headers in the docker login process when using the proget image. Also, please make sure that you set the Web.BaseUrl to the https reverse proxy URL in the Administration -> Advanced Settings section.

Thanks,
Rich

Hi @viceice,

How many docker feeds do you have configured on the fresh ProGet instance? I have seen one other user who has seen a similar issue, but it only happened on the one feed and manually creating the folder has resolved it. Any other docker feeds that were created did not seem to have the issue. Also, how did create the folder? Did you create it from within the ProGet container?

Thanks,
Rich

Hi @atillio-menegoni_1334,

If you navigate to that artifact version in the UI and verify that cdd-application-5.7.0.5.zip exists in the list of files? If it does, can you click the file and see if it downloads manually for you?

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

Do you have any other applications connecting to your SQL enterprise instance? Do you see any timeouts in those applications? Would you be able to run a docker stats when these timeouts are occuring? Could you also up your timeout in ProGet's SQL Server connection string?

Also, what version of SQL server are you running?

Thanks,
Rich