Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @gravufo,

Would you be able to rerun the database scripts on your database? You will just need to run the Run inedosql to update the database step of our manual install guide. Can you see if this fixes your issue?

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.

Thanks,
Rich

Hi @mcascone ,

We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.

Thanks,
Rich

Hi @viceice,

Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.

Thanks,
Rich

Hi @markus4830,

I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

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 @tkolb_7784,

If you are hosting on a windows machine, the easiest solution right now is to migrate your server to use IIS and then add an SSL binding to your site. If you do not want to purchase a new certificate and the self-signed certificate is too much work, you can use Let's Encrypt and configure it via winacme.

If you do not want to use IIS, then you will need to use a reverse proxy to handle SSL connections. Any reverse proxy can be used and a pretty simple one to configure is stunnel. Most reverse proxies can also be used with Let's Encrypt.

If you are hosting via Linux (Docker), then you will need to use a reverse proxy to handle SSL connections. We have a documentation page for different Linux-based reverse proxies including an example for setting up NGINX. These reverse proxies also support Let's Encrypt also.

Please let me know if you have any questions.

Thanks,
Rich

Hi @barnaby-williams_8489,

Please see our documentation for cloud storage. There is a subsection for migrating a feed to cloud storage.

Thanks,
Rich

Hi @caterina,

No problem, thanks for getting back to us. We have an upcoming release of pgutil that will include this flag. We also have improved this command a bit by allowing you to use the working directory which will search for the right files instead of --input having to specify the path to the file (although you still can). It will now also automatically audit the scan directly after, you can use --noaudit to skip the audit. We should have those updates pushed this week.

Thanks,
Rich

Hi @caterina,

We are working to add this back, but the hold up has been trying to properly document this. Here is our thoughts, but wanted to get your feedback.

We are looking to change the parameter name to --do-not-scan-node_modules with a command line description of:

Do not scan the node_modules directory when scanning for package-lock.json files

What are your thoughts on this?

Thanks,
Rich

Hi @jw,

I just pushed the latest version of Inedo.ProGet to NuGet.org. Please let us know if you have any issues using it.

Thanks,
Rich

Hi @caterina,

The fix in pgutil corrected the API to enure the proper parameter was passed to the SCA API. There looks to also be a regression on the ProGet side in the SCA API. I have created a ticket, PG-2805, which will be released next week on Friday Oct 4th that contains the fix. If you need the fix sooner, please let us know and we can get a pre-release build out for you.

Thanks,
Rich

Hi @jw,

I have added this to our ProGet 2025 roadmap. If there is a more immediate need for this, please let us know and I can discuss this with the products team.

Thanks,
Rich

Hi @v-makkenze_6348,

I was able to identify the issue, PG-2778, and will have this fixed in the next maintenance release of ProGet.

Thanks,
Rich

Hi @v-makkenze_6348,

Thanks for bringing this to our attention. I need to dig a bit deeper into this, I should have an update for you by tomorrow.

Thanks,
Rich

Hi @j-d-koning_0111,

Just wanted to check in if PG-2738 fixed your issue. We have also been working with another customer that has had similar issues. We determined this was related to setting to Map groups to SAML groups setting. If you have this enabled and do not have any groups claims sent, it was causing the error you saw above. This last issue, PG-2745, will be released in the next maintenance release. As a work around, make sure you have your SAML provider configured to send groups claims.

Thanks,
Rich

Hi @j-d-koning_0111,

I did some more testing and found another scenario where this could error, it's less common, but I'm guessing that is what is happening to you. In certain situations, an authentication cookie may be created for a new SAML user before the user was added to the system. This also would cause subsequent attempts to fail because the cookie was preventing the updated SAML logic from running. This issue has been fixed in PG-2738, which will be released on Friday.

Also, is your ProGet instance running in Docker or Windows?

Thanks,
Rich

Hi @jw,

Thanks for sending this over. I created PG-2731 to track the fix. It should be out within the next two maintenance releases of ProGet.

Thanks,
Rich