New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Welp either I made a complete mess of things or they've fixed it in the past few months
It's always been possible, afaict. As long as you don't renumber partitions, the uboot thingy does not explode.
No you are not. You can get and compile the kernel your self and some have reported that sysctl modifications help them with sorting out the 'speed' issues for the most part. It isn't a perfect fix, but the supposition with the newer OVH kernel release is this is what they implemented such a solution instead of actually fixing the driver (again guessing since haven't taken the time to really look). However, if you have enough skills to detect the driver regression you too could patch the driver and compile it fully working.
We also at some point will make the patches available, however, there was a good amount of developer time put into patching that correctly and there was some money invested in this in the background to make it so. So part of our goal is to get some donations for the project and once we meet our goal it will be released and my understanding is people have been reasonably generous, so this may be sooner than later.
The patches also needs some clean-up before they are put out as they were more a hack originally to make things work than a clean patch. Those who have used the custom kernel up until now and have kept up to date will have noticed as we have actually been progressively patching and trying to get up to the most recent kernel version possible.
As per security updates, the arm repos are actually updated pretty regularly and gasp you could always compile your own version if you need an upgrade that isn't available.
Not trying to take a dig at you, just trying to point out things are not as you have described them. There is a lot you can do if you have some moderate skills, but yeah if you want to complain that its not plug and play like x86, well....duh?!
Cheers!
You are also wrong on these points. If you are using cryptodev and your not lazy you should be compiling the package your self and also keeping it up to date in the same way. There is absolutely no reason you have to rely on packages, let alone the ones provided from our project.
Edit: reading back you probably meant it was a pain to build it your self and I mis-read the context, however, if the cost of a 25% performance gain is spending 10 minutes compiling openssl I think its a reasonable trade-off.
You can actually netboot a rescue image for the server, i'm sure you didn't take the time to figure out how, cause it does take a little bit of fumbling in their panel. However, you can boot it to rescue and make changes to things as you want. The one caveat is, yes, it uses uboot and you can't fuck up the uboot (bios) on there or you have to start over, it is written to the beginning of the drive.
You do not have to 'pay for a kvm' in fact doing so would be silly as the boards have no graphics card, only a serial console.
I mean, if you actually knew even 50% about what you were talking about I would have left it alone, but the things you are saying are quite unfounded.
Cheers!
That feeling when you see how that loser sadly cancelling those nice servers... Mmm, precious!
14 servers removed recently. By 6TB and 2TB mostly.
54.37.26.* - 6
51.75.2.* - 1
213.32.0.* - 3
51.255.90.* - 3
193.70.82.* - 1
In March, periodically began to appear more often.
where did you got that info? : P
I?
yea, it's kinda cool to know which server IPs got dumped.
Do you have an API or is it a providers thing?
Not. It's just that I did not renew it because there were rejections to customers.
he listed the ones he dropped
So I happened to grab one in canada, but ipv6 doesnt work, the /etc/network/interfaces and route table looks fine, do these suckers support ipv6?
>
Until you can run an official Debian ARM kernel on this hardware and receive updates via apt, all of this is moot. This is a server, not a typical ARM plaything. It needs official, regular patches - having to recompile kernels all the time (or rely on an unofficial source) is an activity for development boards and consumer hardware, not servers.
I know about this stuff from suffering with trying to improve the Linux situation on the Gemini PDA, so my opinion of linux on arm is very low.
I'm well aware you can do a lot with these machines, but my post was intended as a warning to the average member that these machines are not easy - you and me both know that, but do others?
Nope, no IPv6 on the upstream routers. Get yourself a tunnel by tunnelbroker.
Again my warning/complaint centres around the fact that you must compile openssl from source, coupled with the fact that this is a server. It's annoying extra work to keep the box secure
I'm obviously not referring to the netboot rescue, are you selectively ignoring the latter part of my sentence? On any Kimsufi box, even those without hardware virtualisation, you can netboot into rescue and then boot the hard disk inside QEMU. On these ARM boxes you can possibly do that, but not with the same kernel or uboot system (at least not easily), so it's missing all the reasons to do it in the first place, as issues beyond the kernel/uboot can be solved from the netboot rescue alone.
Fair play, I think my mistake then was trying to use LVM for the OS partition beyond /boot. That's still a shortcoming of sorts, but not as bad as being forced into ext4
If I could edit my post I would, hate that 4 hour delay system...
This is not related to "security", definitely not. And no one "must" compile anything.
The box is perfectly secure using the vanilla OpenSSL (or "as secure as any other system using crap OpenSSL" if you're a purist) - the only difference being that without cryptodev-enabled compiles, you may not benefit from (sluggish) hardware crypto acceleration (for those very few use cases where it may actually prove beneficial... hardly any actually).
I never said you must compile openssl full stop (taking my original post into account as well), only that you must compile it to use the hardware crypto acceleration. Having done so, it is a matter of security to keep that updated, considering the amount of network services it underpins
Just because you found few uses for it doesn't mean it isn't essential for the next person
Yep, but it's - mostly - pointless to recompile openssl to enable the crap cryptodev-backed HW accel. (The reason why it makes little sense is aptly explained on the "custom" kernel homepage - block sizes vs cpu and the such).
"Take home" summary: If you're concerned about security, just use the plain vanilla openssl, it's as safe as it gets, and there is definitely no practical drawback, speedwise.
--
Besides such limited, weird, and/or unnecessary use cases ("Ha! what if... a guy desperately needs cryptodev-enabled SSL for the beauty of it? or a custom string in the OpenSSL version number? He MUST recompile!"), it is worth mentioning HW crypto acceleration definitely works out-of-the-box (e.g. you get an impressive 60MB/s aes FDE instead of 30MB/s without compiling or hacking anything).
Altogether it makes for a wonderful glorified cellphone™ tied to spinning rust.
The Kimsufi offer much better overall peformance and oddly the speed seemed faster/more consistent for me at Kimsufi (both up and down) despite SYS having higher theoretical throughput. You can use this as very slow storage, any encryption overhead slows it down significantly. Other cons being 32bit and uses ARM architecture. Plus OVH and their custom kernel shit.
I forgot to add, the HDD for the ARM box I have has relatively low power on time. It loses SSH connections / connectivity throughout the day (it's an idle box). If this is any indication of their ARM lineup it's best to avoid IMO (in addition to the reasons in the above posts). It was my experiment to see if it would be of any use, I am not renewing it. If you need a dedicated machine with storage definitely don't use this, in comparison Kimsufi is highly stable/reliable -- their ARM lineup appears to be anything but that.
Actually, you again don't understand what this service was meant for. This was meant as a back-up appliance. If you actually go to archive.org and looked when they first sold these, they were 3x the cost and were basically sold as back-up targets. They were not even meant to really be "servers" to begin with. I think you had the wrong expectations going in.
For this purpose, OVH does provide you with regular operating system and kernel updates. In fact, they released one recently which actually seems to have a usable networking stack since they did some sysctl changes. Even before they 'fixed' the kernel, they supplied this. If you ask me, I think they may have even purposely left the network driver crippled on upload to 50Mbit to help them save money on the products bandwidth. I of course don't think they will ever come forward and admit this. They have said, however, that they are making close to nothing on it now and have discontinued their plans for adding to the platform. I would assume this is because they are losing their ass now since the kernel was patched by us and they are being used as seedboxes by half the users, which was never the intent to begin with. They only released their own 'fixed' kernel because it was pretty much already done by us and they didn't want customers to have to use a third party kernel.
Since your argument is that it needs 'official and regular patches', it is getting this and it is officially being done by OVH, the owner and maintainer of the platform.
ARM is in mainline and slowly getting bigger, the problem is, we have a bunch of people who like to complain instead of pitch in and help make things better and point the finger when things don't work exactly the same as x86. This isn't productive and is exactly the reason progression is so slow. It isn't helped by those who are lazy and want it all done for them out of the box, either.
my 2 cents.
Cheers!
I remember reading they are discontinuing the ARM storage lineup, probably because all the issues it has that made it not viable commercially. So I'm not sure how long these will be around. Good riddance IMO, YMMV.
It isn't about issues, it is about what the product was supposed to be and it's failure to succeed as such. It was never sold as a server, but a back-up service. An expensive back-up service. After paying the platform off, to sell out the platform, they had to drop the price by 75% and allow them to be used as actual servers instead of just back-up targets. Along with the kernel patch that removes the limits on the outbound bandwidth, we pretty much killed anything about the product that let them make money on it.
I mean seriously, think about it for a moment, 6 Euro a month (rounding) for 2TB disk (they purchase new for around 50-80$) plus bandwidth costs (unlimited gigabit), plus power costs, plus maintenance on the platform, plus kernel and distribution updates, they probably just barely break even.
The only way they afford to keep it online is that the hardware is actually most likely paid off as it had about a 2 year life span where they charged 21 Euro for the 2TB service and something like 40 Euro for the 4TB service, etc. If not, they probably would be losing their ass on it at these prices. This would also be why it would make no sense to add new servers, at the current cost, they would likely never pay off the new hardware and it would just be a loss for them.
The platform probably makes just enough to be sustainable and my understanding was that they are not going to discontinue the platform, they just are not doing any further upgrades to it (adding units, rolling out a newer version of the platform, etc) because it just doesn't make any cents.
my 2 cents.
Cheers!
If you have connectivity issues you should report them to OVH. I have never experienced any connection issues with the 5 servers I have. So this would be either related to your connectivity to OVH to begin with, or something is wrong.
All the servers I have have been stable and running just fine. My guess is your trying to do more on the server than it was built to handle. Again, it is only 2 x 1Ghz cores. That is it. It isn't like your getting threads from an E3 or an E5. So if your running some dumb seedbox crap and its using all the CPU time constantly (Network requires CPU, IO requires CPU, etc) then sure your gonna see connectivity issues. If this is the case, it wouldn't be the devices fault for not being stable, it would be yours for overwhelming the poor thing.
Cheers!
Pardon the very basic question, but how do you apply OVH's updates to these systems?
I've got two of them running Ubuntu 16.04 with kernel 4.5.2-armada375 since the summer of 2018, both with the unattended-upgrades package installed. As far as I can tell, neither one has downloaded and installed a single update in all that time.
Thanks for any tips.
I would have to go look but I believe the templates and packages they are actually keeping updated are for the Debian images not the Ubuntu one. The newest image for the servers is Debian 9 though and should include the newest kernel packages they provide as well.
For Ubuntu you may indeed be on your own as I believe that is an LTS release, they may not be supporting new Ubuntu images. May be worth ticketing and mentioning you have an interest in a new Ubuntu template / updates for it. I would imagine if they have a process for the Debian templates it can't be much harder to rebuild a new Ubuntu as well.
That said, you can probably check their repo and grab the kernel packages from the debian repo and install them on Ubuntu if that is your main concern. However, if kernel is concern I would suggest instead just taking advantage of the kernel #SYSarm linked in my signature instead.
Also, to be clear, I believe the main repos used by the images are actually Debian / Ubuntu repos, they do build and supply packages for ARM in their repos, I don't think that is something specific to OVH. So you probably can even go through an dist-upgrade if you wanted and it would probably be supported to some extent. Of course I would make back-ups before doing so, but I think it should be possible.
If you provision from their template they include their kernel packages from their internal repo during the process. So if you want their new kernels you would have to check their repo for the packages, download and install them. Somewhere in the other major sysarm thread we linked to their repo ftp for kernel sources, the packages should be located in the same place.
Cheers!
http://last.public.ovh.hdaas.snap.mirrors.ovh.net
edit: Looks like latest OVH kernel (4.9.160) is also available for Ubuntu.
Thanks a lot for the helpful replies, @Shot2 and @TheLinuxBug!
If anyone cares I've had a Scaleway C1 ARM dedicated server for 2+ years with no issues. It just has their usual 50GB network SSD but it shows that ARM servers can be stable.