I’ve been looking forward to this for a while now, and today I’ve finally set up a Speckle v2 server!
I’m experiencing some issues though…
First of all, thanks for the clear Deploying a Server | Speckle Docs documentation. I’ve used the first method with docker-compose, works like a charm.
I can log into the front end, create streams, edit stream data, … using front end or clients.
I however cannot send objects to the stream using Grasshopper, Dynamo, …
FYI, I also tested sending data to the Speckle XYZ server, and there it works (so the problem is not the GH client), only it seems that the viewer has warped my greetings:
This means it’s something that we fixed, and we’ll make a new release so it propagates to xyz as soon as possible.
Issue 2: It might be due to some strange mismatches in the canonical url of the server. I spy a http there, are you sure it shouldn’t be https? Or the other way around? @cristi might be able to help, but I suspect he’s out for the day (he actually should be, it’s his name day).
Okay one more (@cristi thought about this): To make sure, you have your server’s account added in the speckle manager? That’s where all connectors source their credentials from. Just checking!
@dimitrie the weird curves issue on xyz is indeed solved.
For the canonical url I use the fully qualified name to the server, as needed to access the front-end in the browser. No trailing slash, no port number, no IP. It’s all on the local network, hence the http. Should anything be changed here?
@cristi account has been added to the Speckle manager (I can use grasshopper to read/create/edit streams, I can’t however create any objects).
The Speckle-Server logs don’t show anything out of the ordinary:
Checking with the code, looks like one of the following issues:
The HTTP request is malformed
The file uploaded to the server doesn’t contain valid JSON
The ContentType header is not set correctly.
I’ve made a note to include a more detailed error in the client’s error message.
To investigate this further, we should analyze the HTTP request / response that is being sent. Are you up to using a networking tool like Wireshark to see the actual request?
Basically you can start a packet capture on your network interface, make the request that is causing the error, then stop the capture and look at the /objects/[stream_id] HTTP POST request and the server response.
I tried to reproduce this issue with various setups, but I couldn’t: I was able to send objects.
I am inclined to believe it has something to do with the setup, triggering an unexpected issue.
We’d be happy to support you further but would need access to your environment, and that would require setting up a consultancy agreement. Please let us know how you’d like to proceed.
Thanks for the support. I’ll delve a bit deeper then into the problem from our side, try a few different server setups perhaps. If I can’t find a fix, I’ll surely contact you again regarding that consultancy agreement.
A different question (let me know if you’d prefer that I open a new topic for this):
On your “Deploying a Server” instructions you mention
This setup is not recommended for use in production[…]
Could you highlight the aspects that need further attention for a production environment?
I assume this mostly relates to the setup of the server or VM that hosts Speckle Server, and not to the speckle container itself?
Hi Kelvin! The container is the same - it doesn’t really change. The art of it is mostly what you’re looking for in a production server. @cristi might swoop in and correct me if I’m wrong.
We’re not recommending that setup for production purposes a few reasons, namely:
application level updates: we tend to move quite fast, and if things get busy, blink twice and you’re on an outdated server. this has security implications too.
guaranteed uptime: from my experience, vm’s tend to restart now and then (they need updates and reboots too), which results in downtime.
database backups - again this is up to you mostly on what’s your risk appetite when it comes to dealing with live data. we’re a bit more on the paranoid side, so we’ve set up replication, failover nodes and PITR.
end-to-end encryption: possibly less of daily concern - we’re offering from encryption at rest, to https security (SSL/TLS certs & renewal) - so whenever data travels between a client and the db it’s always encrypted, inc. inside the datacenter itself.
automatic scalability: for example, the preview service can be quite a monster; that setup can eat up all a vm’s resources, and starve other processes causing general system wide instability.
We’ve been burned in the past: insecure and unstable servers don’t make anyone happy, and this ended up in generalisations of “Speckle is insecure” or “Speckle is unstable”. Of course it is, if you forgot to renew your SSL cert! < insert frustration incomprehensible noises >
It’s impossible for us to manage all those aspects of making a server secure and stable for production for everybody - and develop the product, and pay the bills. As such, we’re now taking a wee bit more care in the messaging around this - and the resulting the “not recommended in production” flags. Hope this helps a bit!
No worries re event! We’ve shared our deck (finally we didn’t forget to…) so you can still catchup on it if you want. And yes, next time! We’ll try to announce it a bit earlier than on the week, to give others more time to prepare/flex schedules
PS: for some reason, 1/3rd of the conversations were around pets (this part is not in the deck).