MY Rust server will not go to the load plugins state.
https://hastebin.com/ekarinafik
http://prntscr.com/o0q2jj
https://hastebin.com/ekarinafik
http://prntscr.com/o0q2jj
Compiler not working with AMP control panel
That simply means the plugin is not loaded. If you are having trouble with a particular plugin, please use its support section.
but its not just one plugin its all the plugins
https://pastebin.com/pfew5jG6
https://pastebin.com/pfew5jG6
In response to ZepNius ():but its not just one plugin its all the plugins
https://pastebin.com/pfew5jG6
Your issue is that the machine your server is on is not configured properly.
I'd suggest checking on your server for the MONO_TLS_PROVIDER environment variable to see if/what it is set to. The issue you are having is not really related to Oxide itself, just that something is set on your server that is preventing the Mono version that comes with the game from connecting to any site using TLS for their HTTPS connection.
The URL we use with downloading our plugin compiler (Compiler.exe, Compiler.x86, and Compiler.x86_x64) is https://nyc3.digitaloceanspaces.com/umod-01/ which supports TLS 1.0, 1.1, and 1.2. We've been using this URL for at least half a year at this point, so we know that it isn't an issue with the URL as it is actively used daily during installs and update checks to the compiler.
You'd need to resolve that issue for it to work right. If you are using a hosted service, please contact your host.
I can't seem to find Compiler.exe, Compiler.x86, and Compiler.x86_x64 under /home/AMP/.ampdata/instances/Rust01/rust/258550/
And TLS should be enabled now http://prntscr.com/o1em6u
And TLS should be enabled now http://prntscr.com/o1em6u
In response to ZepNius ():I can't seem to find Compiler.exe, Compiler.x86, and Compiler.x86_x64 under /home/AMP/.ampdata/insta...
If you do not see the compiler, that means the above post I mentioned is still the issue. I'd suggest contacting AMP (make sure you are updated with them first), as this has been an ongoing issue with their control panel, which I thought they had already resolved.
Hi, AMP developer here.
We're setting the MONO_TLS_PROVIDER env var to "legacy" on Linux systems for the RustDedicated process (why aren't you using btls instead of the legacy provider? We can assist with how to change over) - I don't think this is the issue.
"legacy" only supports TLS 1.0 and 1.1, TLS 1.2 requires using the new 'btls' (Boring TLS) provider. If anything along the way is rejecting downgrades or otherwise forcing TLS 1.2 then the legacy provider would fail.
Unfortunately your error message obscures the actual exception/error/validation failure so I can't diagnose what's wrong. It could be a certifiates issue but our software does sync the system certificate store with where Mono wants it so that shouldn't be an issue either.
If you could add a flag/config entry/env var to make it actually write out the exception for TLS/connectivity issues it would be easier to diagnose or ideally upgrade to using the btls TLS provider (again we can offer assistance with how to go about doing this). Some extra logging that shows the complete set up startup flags/env vars/etc would be helpful too.
Our workaround for now is that AMP itself is downloading the compiler, but this is a band aid at best.
Cheers,
M
In response to CubeCodersMike ():Hi, AMP developer here.We're setting the MONO_TLS_PROVIDER env var to "legacy" on Linux systems for...
Thanks for the feedback, we'll be sure to look into more detailed output for uMod, which will not be using Mono that the game provides. Right now the web requests rely on what the game server provides, not Oxide.
The Oxide builds aren't going to be receiving any changes to the legacy compiler or itself though, so it's unlikely that we'll be able to provide any additional output for those builds at this time.
The Oxide builds aren't going to be receiving any changes to the legacy compiler or itself though, so it's unlikely that we'll be able to provide any additional output for those builds at this time.
Righto, the other trick is you can add a custom handler to `ServicePointManager.ServerCertificateValidationCallback += ...` to determine more precisely what's going on in the case of certificate issues. What domain it's from, who the issuer is, whether it's untrusted, invalid, etc etc.
In response to CubeCodersMike ():Righto, the other trick is you can add a custom handler to `ServicePointManager.ServerCertificateVal...
The provider we use for hosting our compiler is using TLS 1.2 due to limitations with Mono (older) provided with games such as Rust, newer security methods are not supported with it. The uMod builds no longer rely on what the games provide though, so this shouldn't be an issue down the road once uMod builds replace Oxide builds.
Any sort of setup on a machine though that forces Mono to utilize unsupported, newer technology will cause issues with the download process though with the current Oxide builds and game servers themselves.
Any sort of setup on a machine though that forces Mono to utilize unsupported, newer technology will cause issues with the download process though with the current Oxide builds and game servers themselves.
It'd be worth double checking which provider actually gets used then, since the legacy provider definitely doesn't support 1.2 (its why the Mono team switched to btls)