I’m not sure if this is happening because of possible issues of the previous configuration (which was done 5 months ago and was not flawless), so I would like to try and re-install everything with the new bootstrap script. I’m wondering if this would have any drawback or if it would break any configuration in the IIS (the node.js web application is configured there) and / or Rhino / Grasshopper?
Hi Marco,
Thanks for your question. Did you run both update scripts (the one to update rhino.compute and the other to update Rhino)? Or just one of them? This could help determine where the error might be. It’s certainly possible that there might be a bug in the update script, so it might be helpful to know where the error might be coming from. I can try to take a look.
I don’t think it would be a problem to re-run the bootstrap script on the same VM (I honestly haven’t tried to run it twice)… however, it might be best if you could spin up a second VM and install it there. This way, you can keep your old setup for the time being while you try to setup the new instance.
Hi Andy, thanks for the quick reply.
I ran both the scripts (first updated Rhino, then Rhino.Compute).
That would be great, thank you. If you need any specific information on the configuration or other please let me know.
The server is managed by my client (big national agency) so I cannot easily create a new VM.
However I also have access to another server (Azure VM) which has the same configuration, I’m going to run the update there (and in case on a second VM) and then I’ll get back to you.
Unfortunately the Azure VM has been closed by my client, so I cannot run the test there.
I could setup a new Azure VM but it would be a brand new installation and I’m not sure it would be helpful.
In the meantime I was wondering if there is anything that we can check to understand how to solve that HTTP Error 500.32 that we get when we try to access localhost:8081
I believe that this is the problem that prevents the Rhino Compute service to be started/stopped automatically by IIS, which means that at the moment Rhino Compute must be started/stopped manually to avoid unnecessary costs which is obviously far from ideal.
Hi Marco. This thread seems to have some suggestions for this error… but I’m wondering if the folders which contain the rhino.compute files have the proper permissions set for the app pool profile. Normally the standard bootstrap script handles this but perhaps it got messed up in the update? Can you try right-clicking on the directories which contains the rhino.compute executable and see what permissions are set?
Not Marco but I ran into the same issues.
The rhino.compute folder was set to read only
After giving full access to everyone I could reach the IIS again and it was reporting back 1 child in /childcount
However I could not use the server as a Hops Compute Server
@blind There should be two folders… one called rhino.compute and another called compute.geometry. You may need to assign full access permissions for IIS for both of those folders. This should have been done automatically for you during the bootstrap process… but you may want to double check that IIS has permissions set for both of those folders.
