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
Kimsufi has standards???
Not quite. But Kimsufis generally come with 3+ year old disks. That's what I meant by standards
For the love of god, people- learn about sshguard, and leave fail2ban for the Python wanks.
This has been a Kimsufi PSA brought to you by WSS, and the number 7.
i only learned from you there is sshguard ... any more tools hiding under the table
would you suggest iptables, ufw, csf or firewalld?
sure do, have a good read over there: https://kshlm.in/post/network-encryption-in-glusterfs/
there is no need to involve additional VPN or something alike, gluster supports this out of the box :-)
Plenty!
If you're trying to run thin (as is likely the case with a slow Atom):
You can always get rid of systemd.
There's a somewhat dated, but still useful wiki at:
http://without-systemd.org/wiki/index.php/Main_Page
If you are trying to be thin as possible, remove all but one virtual console, you don't have access to it- why waste RAM on gettys. Depending on your init system, you will likely edit inittab or make symlinks on systemd ttys, accordingly.
RAM a problem? Probably not in 4GB, but 'ash' is a perfectly useful shell (without command history), and busybox can replace most tools if you want to keep a very small footprint.
dropbear does a great job at completely replacing sshd- but make sure you have the latest version.
Really, if you're looking for other tools or to trim the fat, it doesn't hurt to look at things like how Free/Open/NetBSD do several tasks, and peering into the various forks of OpenWRT.
That depends on your needs and abilities. iptables is the underlying system utilized, but csf/firewalld/ufw are not without it's merit for many users who don't want to be quite so direct with their built rules.
If you were trying to make a statement about it essentially being the same thing, point taken- however, if you just want to block scans, sshguard doesn't require that you install an entire Python setup to run- which was the entire point of my statement.
I can't get OBSD to play nicely with the 2T disks, either- so don't bother asking again (for now).
Filesystem fsck's fine, and even newfs -N shows the superblocks properly. Some limitation within installboot that I'm not willing to tackle to make someone else's Atom work right now.
It's possible to install NetBSD 7.x on a Kimsufi 2E, but my god its so slow and NetBSD is fucktarded and likes to drop to a single (user) shell over anything that it's almost pointless to bother.
I'll look at sshguard but fail2ban has worked ok for me. I do want to have python around so that's not an issue. But Debian comes with it as part of the distro anyway. And with 2tb of disk space I don't think the install is a problem
.
My server was delivered 5h ago which I guess was late afternoon in Paris, no prob. I wasn't asked for ID. Relevant disk info:
They apparently ran several short disk self-tests when the drive was new and none since then. I guess I'll run a long test.
Box seems to work ok. Had a slight installation mishap, I selected Debian 8 and got Debian 7, maybe my own error (not sure). Reinstalled and got Debian 8 so it's ok now.
It occurs to me, I use ansible to do my initial configs so that also needs Python.
My suggestion was for the majority of WordPress/etc users. I don't do a lot of Python, and if you just want to block ports, you don't need Python for that- and neither do those folks. Obviously, if you're developing and doing admin- you probably know what you need.
As an aside, fail2ban doesn't only block ssh, but neither does sshguard.
You were stressing yesterday. Glad it worked out!
Thanks ;-). My main "stress" was about being asked for ID when I didn't even want the server that much. Waiting for the server was no big deal on its own, and it's easier to install it now than late last night when I was sleepy.
First project with this server will probably be back up my 1.7tb Hetzner partition which will be almost 48h of transfer with the silly 100mbps port. Then upgrade the OS with apt-get dist-upgrade and see what breaks. I'm leaning against de-raiding the Hetzner disks right now but might do that as my ever-growing storage appetite calls for it.
That 100mb/s port seems like enough of a bottleneck to decrease the server's usability and in retrospect I probably should have used Hetzner Storagebox (10 euro/mo for 2TB but pro-rated if you change the size during the month). Oh well.
Or nothing at all if you cancel within 14 days...
agreed ;-)
I suspect they'd get annoyed if someone did that more than once
. 100GB is €2.90/month while 2TB is €9.90, they are weird that way. But you can downgrade a bigger plan to 100GB when you're done with it and have deleted the contents, keeping costs low. If I weren't pinching nickels at the moment I'd probably just pay for the 2tb storagebox on an ongoing basis.
Two small irrelevant updates:
1) I downloaded and built ffmpeg on the box, which took about 37 minutes. On my Hetzner i7 it's about 3 minutes so I guess the Atom is slightly beating the estimate I'd get from the passmark ratio.
2) I got a renewal notice from OVH, saying the server would expire in less than 30 days (it's a 1 month rental of course). I went ahead and renewed it, shrug
. So now I have it for 2 months. I have an idea for something to do with the storage but will see if it goes anywhere.
Probably depends in how many active services you actually pay for in the same time I'd say ;-)
They do send multiple reminders like 30 days, 14 days, 7 days and so on... at least your renewal leverages the setup costs ;-)
They're still available. https://www.kimsufi.com/en/servers.xml?flash
Yeah, I'm sure they'll sell out but they're not as great a deal as some other promo offers have been. Like the KS3C of just a week or so ago. In fact maybe some of this KS2E buying is people who missed the KS3C. Maybe that explains why I got it.
Now I'm thinking about whether to cancel my other cheap dedi, the 3 euro/month Scaleway C1. In a way I like it better than the Atom though.
Probably they got much less folks in hands than expected at this time
It's on-par with the KS-1, except 10% of the space and no IPv6. Probably a similar monthly throughput, though.
You know, I think you're right, the C1 and the KS-2E (same cpu as KS-1) are about on a par. If anything the C1 is a little faster.
The Atom is faster at RSA but I think it compiles ffmpeg a little
slower. Interesting that the Atom gains quite a bit of speed
from hyperthreading in that test. With the i7 and e3 the
difference is much smaller. A lot of the RSA gain in the Atom over the C1 is probably from 64 bit arithmetic rather than 32. With other tests that won't matter as much.
I restarted the ffmpeg compilation on the atom with 4 threads. I had used 2 threads earlier since that's the # of physical cores and more threads on the i7 didn't help. But based on the RSA test it seems worth trying here. I'll update after it finishes, in maybe 25-30 minutes.
I'd be interested to know the results as well. For (big) compiles, matching compile threads to processor threads (not cores) [+/- 1] should be good because of the IO waits involved in a large source tree. That should nicely balance out giving you better throughput.
Of course having a small cache (like the Atoms) will in some sense negate that but in any case when you're running a big compile, the cache will likely be mercilessly trashed frequently.
One thing to really try (esp. on the big large memory Scaleways, preferably x86) would be to move the entire source tree to a ramdisk and then run the compile. Your IO waits will practically disappear and assuming that the entire build fits into RAM (with some to spare for OS etc.) you'll really be fffffffllllllllllllllllllllllllllyyyyyyyyyyyyyyyyyinnnnnnnnng!
(I do this often with the kernel and a 2GB ramdisk/tmpfs is great).
Wouldn't that be nice :-)
Result is it was somewhat slower than with 2 threads.
I do a similar ffmpeg compile (different configuration) all the time on an i7, and using 4 vs 8 threads doesn't make much difference. It takes around 3 minutes either way, with 8 threads being maybe a few seconds slower.
I'm now doing a large scp from Hetzner and steadily getting around 11MB/second. sshd on the Atom end is using around 60% of a cpu, and scp using another 11% (out of 200% available). Rsync would be considerably slower I think, because of the rolling checksum. But the inbound network appears to be fine.
I suspect IO still put on the brakes. Thanks for trying.
How "big" is the ffmpeg tree? Any hopes of it fitting in a ramdisk/tmpfs (esp. post compile)?
Thanks.
I usually fork ($NUMCPUTHREADS-1), assuming the master can handle both the weak task of forking processes, and the rest of the system necessities. You should actually be able to get 4 threads from a 2800 technically, but as slow as they are, well, I don't think I'd want to do anything else on the system.
Yeah, I wasn't doing anything else. Might try later (tomorrow maybe) with 3 threads.
791MB post compile, includes .o's, built libraries, and stuff. Downloaded tarball is around 10MB compressed.
Since the Atoms are so neutered, it's just going to get worse. I've relegated my Atoms to: Nameservice, mail, low impact dynamic sites, storage. They're a little bit better with recent microcode, but that may be psychosomatic. They feel a bit better under FreeBSD's SMP, but it's hard to equate with OBSD. They're basically completely useless under NetBSD.
If you do have the time or are interested, do try this on a 1G tmpfs/ramdisk. Hopefully you can do it without a hassle. The IO waits are practically gone and so it'll be a (almost) pure CPU test. It may help if you're frequently doing this sort of thing (and even on the faster CPUs, you'll find it'll make a world of difference).
Thanks.
That's going to take 25% of the total system memory on a KS-2E, or 50% on a KS-1, which will probably hinder as much as it helps since it's going to be swapping when linking the libraries anyhow..
Will see if I can try that tomorrow. It's late here and I'm signing off for the night any minute now
.
I think on the i7 everything hits the file cache, so there's not much i/o.