@AlwaysSkint said:
Perhaps you don't understand the technicalities of that LFD warning email ! tty1 means the console was accessed, either through the client area (which I only have access to), or internally by you via hypervisor/whatever means. This was not a mere let's check if a VPS is up but a direct login. Unannounced and/or unauthorised access constitutes a breach. Doesn't matter how you want to frame it.
If you hadn't skim read, you'll have noticed that I tried to raise a Ticket but couldn't! Hence posting on a public forum, which I would otherwise not do.
We have no e-mails on any of the three possible mailboxes we offer, either publicly or semi-publicly, regarding any "LFD warning e-mail", dating back to October 19th up to this very day. Zero. We also have no system that sends LFD e-mails to or for customers. Any failure of a mechanism that you implemented yourself, correctly or not, from within the VPS server, is your sole and exclusive responsibility.
We did not access any server nor do we access any server. It would be absurd, ridiculous, to access a server directly, with the plethora of mechanisms a hypervisor has to check multiple questions without logging in.
Your message is particularly ridiculous considering that your only paid-for server is in Alpha1 Amsterdam and most especially that, since the alleged breach had occurred in 22-10, and according to our registrations, Alpha1 Amsterdam was OFFLINE between 21-10, 15h27, and 29-10, 16h33. As, literally, all customers at that node will tell you, as they also were without service during that time. Literally stuck in a BIOS loop. Unreachable.
There are two movements registered by your account, with your login, in 22-10, to that server (all of them ineffective obviously, as the hypervisor was offline): from the WebStore, a restart attempt at 14h19. From the EagleKey VPS Portal, less than an hour later, you logged in yourself at 15:16:04 and there is a console attempt also strictly only done by yourself at 15:22:24, registered at EagleKey, possibly to check if the server was online - which obviously couldn't be, as the bare-metal barely was passing BIOS at the time, let alone load an OS.
Loading a console effectively loads a tty. Doesn't login to root. And even less does it login to any server when the hypervisor is offline on a BIOS post.
Your claim is therefore absurd and absolutely not supported by adequate evidence.
We have automated systems to track everything and can submit the claims, messaging timestamps, copies of messages and everything relevant to the moderation if necessary. There is an audit system, control mechanisms, just like on the previous panel.
A last word of caution: according to our Terms and Conditions, this may be considered social engineering, and that is not allowed per those. Consider yourself warned. Further insisting with all of this nonsense will have consequences.
Best regards.
PS - Your account is also registered with partial data, as you did not even provide your first name, only a letter of it and your last name. That's a creative interpretation of the field "Full Name"...
@2423750524 said:
Can your Ashburn server use IPv4? It seems to have hung up again
Sorted out The IPv4 networking session that allows the connectivity had dropped unexpectedly. IPv6 was always operational in the meantime, that session was up.
Live Chat was expanded from 14 to 21 automated functions. Some of the functions are that it now diagnoses the status of a VM or group of VMs of a given user, and compares it accross the host to see if others are in the same situation or not, on IPv4 and IPv6; on pending add-ons for CPU, disk, memory, traffic and IPs they're now automatically fixed upon user's request, which covers for WebStore automated failures; upgrades and downgrades are also corrected if necessary in the same way. Billing was also improved on the handling including some errors. Full E2E and A/B testing was done on the Live Chat, including some hands-on testing and some important feedback on opened tickets over the last days.
C-Servers is lab-testing personalized kernel compilation with BBRv3, to be served on all CHV-based VMs, distros and OS automatically, and changing the default TCP system from cubic to BBRv3. Tests have shown an excellent behaviour of BBRv3 compared to Cubic or BBRv1, with very significant speed and reliability improvements in all fronts in medium to long range scenarios, with or without any type of packet loss - which serves most especially our Asian customers, but also customers worldwide.
The kernels to be served will be entirely exact to the versions deployed by the distros in order to ensure 100% ABI compliance, and only the essential toolings to serve BBRv3 are added or adjusted. We will maintain multiple kernel variations in direct parity with the published variations of the original kernels, and update them continuously both from the original kernels, and the BBRv3 project. On our tests, the deployed kernel shows equal reliability in comparison with the stock one.
While we don't have direct data on that yet, this probably makes C-Servers the first provider to ever implement BBRv3 in production on a commercial VPS.
C-Servers is lab-testing personalized kernel compilation with BBRv3, to be served on all CHV-based VMs, distros and OS automatically, and changing the default TCP system from cubic to BBRv3.
C-Servers is lab-testing personalized kernel compilation with BBRv3, to be served on all CHV-based VMs, distros and OS automatically, and changing the default TCP system from cubic to BBRv3.
Which locations use Cloud Hypervisor?
All of them, without exception. It's OS-dependent and available on Debian 12/13, CentOS Stream 10, Alpine 3.21, AlmaLinux 10, Oracle Linux 9, Rocky 10 and all Ubuntu's (22.04, 24.04, 26.04). And Fedora.
Comments
We have no e-mails on any of the three possible mailboxes we offer, either publicly or semi-publicly, regarding any "LFD warning e-mail", dating back to October 19th up to this very day. Zero. We also have no system that sends LFD e-mails to or for customers. Any failure of a mechanism that you implemented yourself, correctly or not, from within the VPS server, is your sole and exclusive responsibility.
We did not access any server nor do we access any server. It would be absurd, ridiculous, to access a server directly, with the plethora of mechanisms a hypervisor has to check multiple questions without logging in.
Your message is particularly ridiculous considering that your only paid-for server is in Alpha1 Amsterdam and most especially that, since the alleged breach had occurred in 22-10, and according to our registrations, Alpha1 Amsterdam was OFFLINE between 21-10, 15h27, and 29-10, 16h33. As, literally, all customers at that node will tell you, as they also were without service during that time. Literally stuck in a BIOS loop. Unreachable.
There are two movements registered by your account, with your login, in 22-10, to that server (all of them ineffective obviously, as the hypervisor was offline): from the WebStore, a restart attempt at 14h19. From the EagleKey VPS Portal, less than an hour later, you logged in yourself at 15:16:04 and there is a console attempt also strictly only done by yourself at 15:22:24, registered at EagleKey, possibly to check if the server was online - which obviously couldn't be, as the bare-metal barely was passing BIOS at the time, let alone load an OS.
Loading a console effectively loads a tty. Doesn't login to root. And even less does it login to any server when the hypervisor is offline on a BIOS post.
Your claim is therefore absurd and absolutely not supported by adequate evidence.
We have automated systems to track everything and can submit the claims, messaging timestamps, copies of messages and everything relevant to the moderation if necessary. There is an audit system, control mechanisms, just like on the previous panel.
A last word of caution: according to our Terms and Conditions, this may be considered social engineering, and that is not allowed per those. Consider yourself warned. Further insisting with all of this nonsense will have consequences.
Best regards.
PS - Your account is also registered with partial data, as you did not even provide your first name, only a letter of it and your last name. That's a creative interpretation of the field "Full Name"...
@AlwaysSkint is your login password in the frequently-brute-forced password list?
AD: VPS Price Tracker
Can your Ashburn server use IPv4? It seems to have hung up again
https://ibb.co/k21LtsSw
Servers are so cheap that I bought a bunch even though I don't even need them
Sorted out
The IPv4 networking session that allows the connectivity had dropped unexpectedly. IPv6 was always operational in the meantime, that session was up.
I'm actually really curious about the breach of offline server, could read a bit more of it
Two interesting updates:
Live Chat was expanded from 14 to 21 automated functions. Some of the functions are that it now diagnoses the status of a VM or group of VMs of a given user, and compares it accross the host to see if others are in the same situation or not, on IPv4 and IPv6; on pending add-ons for CPU, disk, memory, traffic and IPs they're now automatically fixed upon user's request, which covers for WebStore automated failures; upgrades and downgrades are also corrected if necessary in the same way. Billing was also improved on the handling including some errors. Full E2E and A/B testing was done on the Live Chat, including some hands-on testing and some important feedback on opened tickets over the last days.
C-Servers is lab-testing personalized kernel compilation with BBRv3, to be served on all CHV-based VMs, distros and OS automatically, and changing the default TCP system from cubic to BBRv3. Tests have shown an excellent behaviour of BBRv3 compared to Cubic or BBRv1, with very significant speed and reliability improvements in all fronts in medium to long range scenarios, with or without any type of packet loss - which serves most especially our Asian customers, but also customers worldwide.
The kernels to be served will be entirely exact to the versions deployed by the distros in order to ensure 100% ABI compliance, and only the essential toolings to serve BBRv3 are added or adjusted. We will maintain multiple kernel variations in direct parity with the published variations of the original kernels, and update them continuously both from the original kernels, and the BBRv3 project. On our tests, the deployed kernel shows equal reliability in comparison with the stock one.
While we don't have direct data on that yet, this probably makes C-Servers the first provider to ever implement BBRv3 in production on a commercial VPS.
Stay tuned.
Which locations use Cloud Hypervisor?
All of them, without exception. It's OS-dependent and available on Debian 12/13, CentOS Stream 10, Alpine 3.21, AlmaLinux 10, Oracle Linux 9, Rocky 10 and all Ubuntu's (22.04, 24.04, 26.04). And Fedora.