inedo-engineer group

rhessinger

Unfortunately, this is still required. By default on Windows, HTTP.sys reserves all ports below port 1024. The netsh http add urlacl url=https://*:443/ user="NETWORK SERVICE" tells HTTP.sys that NETWORK SERVICE can register port 443 and listen to all traffic on it bypassing HTTP.sys.

If you specified a domain, https://my-domain.com:443 instead of https:://*:443, then HTTP.sys will handle all traffic but will allow NETWORK SERVICE to subscribe at that domain. HTTP.sys will still handle all traffic though. That will then cause the integrated web server (IWS) to use HTTP.sys instead of Kestrel, which is why we recommend the port binding method. This is all outside of IIS. That reason is also we added documentation on how to Use IIS as a reverse proxy.

Hope this helps!

Thanks,
Rich

rhessinger

Hi @sai.pabbareddy,

This has not gone through formal testing, but I just pushed a pre-release of the InedoCore extension that includes the referral following on Linux. Would you mine testing it out on your end and see if it fixes your issue with Samba 4?

The fix is included in InedoCore 4.0.6-rc.1. To install a pre-release extensions, see installing pre-release extension in ProGet's documentation.

Thanks,
Rich

atripp

Hi @jw ,

Can you share us a copy of your database bacakup or export?

I created a ticket that will allow you to upload this: EDO-13159

Once we have that, wecan investigate this further.

Thanks,
Alana

gdivis

Hi @jw,

The purge failure is unexpected, but I've seen something similar in the past with from an imported SQL Server database that had some invalid data in it. For now, leaving those IDs in the database shouldn't affect your performance. We'll look into adding more robust detection of invalid data to the cleanup page. Regardless, the order of cleanups performed shouldn't matter.

PackageAnalyzer does quite a bit more in ProGet 2026, so I would expect it to take a bit longer, but not that much.

I'll bring both of these up with the team and post again here with an update.

-Greg

gdivis

Hi @joris.guex,

Sorry for the delay - I've been out of the office for a bit.

I've logged this as PG-3379, scheduled for the next release of ProGet 2026.12 on Oct 2. I haven't looked at the code yet, but it should be another trivial fix to bring this fully up to spec.

Thanks!
-Greg

rhessinger

Hi @sai.pabbareddy,

Glad to hear it all works as expected!

Thanks,
Rich

rhessinger

Hi @sai.pabbareddy,

Thanks for the heads up. The cache fix should exist in 26.0.11-rc.15, but I'll be very interested to hear if you still see those issues after the upgrade. Please keeps us informed and we can look into it further.

Thanks,
Rich

rhessinger

Hi @sai.pabbareddy,

My apologies. Looks like I typoed the date on that other post. I had the day of Friday correct, but the date should have been Sept 18, 2026. It will be releasing later today (normally in the evening in EST). I updated that response also to have the correct date.

Thanks,
Rich

rhessinger

Hi @sai.pabbareddy,

I think it would be a good idea to have you send over the exact directory config. The code paths for searching for users and groups are virtually identical, with the only difference being the LDAP filter. You can see what we are doing directly by looking at the code in GitHub: https://github.com/Inedo/inedox-inedocore/blob/16155c425cf4b4d180e2e7ced7af90e36fb4ed35/InedoCore/InedoExtension/UserDirectories/OpenLdap/OpenLdapUserDirectory.cs#L300

I'm guessing there is something else going on that is causing this, maybe a hidden unicode character or something. When you paste in the ldap queries, can you make sure to include them using a markdown code block (``` ... ```)?

Thanks,
Rich

rhessinger

Hi @sai.pabbareddy,

Let me run some other tests. It could be related to the LDAP escaping that is happening, but that would be highly unlikely as we have many other users currently using the OpenLDAP/Generic LDAP user directory. I think the more peculiar thing is that when you hard coded the uid, the logs didn't show ?uid=, but with the %s it did. That makes me think that it does not like the value that is being passed in. Does the group search have the same issue and log message?

Thanks,
Rich

inedo-engineer

Posts

Member List