Service unable to start after upgrade

[Guest]

The installer isn't supposed to do anything with URL registrations on an upgrade - they are supposed to persist unmodified. I haven't seen this happen before. We'll do some tests with a 4.7.14->5.1.7/8 upgrade to see if we can reproduce this.

[Guest]

Sorry, I forgot to ask - was this the new Inedo Hub installer or the traditional/offline installer for ProGet 5.1?

[Guest]

It was Done using the Inedo Hub installer

[Guest]

I used the offline installer.

BTW, even though the server is on the internet, the hub installer couldn't get through the corporate firrwall/proxy...

[Guest]

I'm not sure but it could be that the existing install (v4.7.14) had the service configured to use LocalSystem account, and after upgrading the installer switched to NetworkService account.

[Guest]

Some extra info:

ProGet version we trying to upgrade from: 5.0.12

ProGet.Service.exe is running as NetworkService.

[Guest]

I've now reproduced this. In my testing the root cause was that the listen URL for the web server was not migrated to the new configuration file used in v5.1+. So essentially it was trying to listen on the wrong URL/port, and it may or may not even have access to do so (causing the crash if it does not).

To verify that this is the cause (and fix), open the ProGet config file as described here, and verify that the Urls attribute of the <WebServer> element is correct.

Does this help?

[Guest]

Our ProGet config has the following <WebServer> config:

<WebServer Enabled="true" Urls="http://*:8624/" />

Not exactly what I expected. We use the self-hosting feature of ProGet and is setup to listen on port 80, which it still does if we switch the service account to LocalSystem.

I'm a bit confused.

1. Should the <WebServer> config correspond to the url and port where I would like to contact the ProGet web app on?
2. Now that I changed the service account to a high-privilege type, why is the ProGet web app still accessible on port 80 when the ProGet config says port 8624?

[Guest]

We managed to upgrade, by

1. Install new version
2. Fix Urls in proget config file
3. start service

[Guest]

Hi Peter-

The integrated web server uses Windows' http.sys, which will only list on a host name and port if the listening user is registered to that URL with the system, unless the listening user is a local admin. Local admins can listen on any host name and port with no registrations.

ProGet's been around a while now, and over the years we've changed where the "listen URLs" for the web server get stored (this is apart from the actual URL registration, which is stored by the OS). A long time ago they were stored as a startup argument to the ProGet windows service (if you look in services.msc, you will likely see that ProGet.Service.exe has some argument like /Urls=myserver:80/) For compatibility, urls specified in this way are appended to the list used by more recent versions, so your installation was ultimately trying to listen to your original port 80 url, and the erroneous one generated as the default in that config file. Since there was never a reservation created for the second one, the process crashed.

It's a long-winded answer, but probably the best way to get your installation to continue to work going forward would be to delete and re-register the service so it doesn't pass that URL in anymore, and update the config file to have the URL copied from that argument.

We'll be updating the installer to properly migrate this as well.

Hope this is somewhat informative for everyone monitoring this thread. Let me know if I can provide any more information to help!

[Guest]

Thanks Greg,

That cleared it all up for me.