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
That's really strange and not inline with the experience that I have with them. Sorry to read this.
I was a bit surprised, after seeing everyone praising them. Every so often, it happens, and I'll just assume there was some other issue at play. The I/O was abysmal, though. I'll play with it later, since I have actual work to accomplish today.
Ive also experienced better woth netcup ;/
I am interested in netcup's storage offer but unfortunately I don't speak German, can anyone tell me if storage VPS are also discounted or maybe it is better to wait for Blackfridat for storage offer, as of now I have ZXhost storage 1 year but I am not satisfied and I want to find something else.
Storage atleast seems cheaper atm than their regular pricing so I guess it is also discounted.
I found some 5 euro vouchers online:
Why not take the ones from @Falzo ?
Since being migrated, the system is finally what I'd consider usable, but I still haven't been able to get a LE setup for my new .de, despite testing HTTP/HTTPS and ensuring DNS was all up to date. What the hell.
there is no need to 'find' them. any customer (like me) can generate them for others as a referral. it's just affiliates, nothing more - so of course he likes everyone to take his coupons rather than mine ;-)
Yes, the storage VPSes are also discounted:
https://www.netcup.de/vserver/vstorage.php
I think that these discounted prices are attractive for such KVM storage VPSes (that also have a decent amount of RAM), but if a NAT OpenVZ VPS works for you, you'll probably be able to find cheaper prices elsewhere, especially on Black Friday.
they have been even cheaper during the easter holidays though. I have one 1.5 TB box running for as low as 12€ a month (yearly contract) - so maybe relax and wait for the advent calendar?
@falzo so 4.99/m (on annual) is the discounted price for 3gb/240SAS?looks like it.I only regret missing out on that old 640GB-SAS offer a while ago. I guess I'll wait.
... and by breaking it down and renewing the certificates manually; everything's OK again.
Despite having no issues with resolving domains before- with this 3GB beast, I've ended up setting up dnsmasq as a local caching nameserver so Apache doesn't take 10 seconds to restart. DHCP/etc are disabled, and it's a much lower-resources config than unbound for this simple use.
On the whole, I've managed to really pare down my overhead (Deb 9 systemd poo-poo):
That offer was in 2016. I'm not sure that it'll return as such.
This is one sexy offer
For whatever reason, the .win TLD does not like my new NetCup IPv6 space.
try .fail
It's already a .win TLD, so fail is implied.
Anyone else experience strange issues with IPv6 on their VPS-not-rootserver setup?
The setup is exactly the same on both, but only on the VPS line do I see it adding a timeout to my default gateway (fe80::1), which is out of my own /64 space- with precisely the same KVM setup, albeit with more RAM and disk space.
This is what you should get from
ip -6 route
:If you see a timeout for your default gateway value set, your system is likely making it a temporary link as the link-local is not within your /64.
Make sure you disable IPv6 autoconf
This fixed it for me, but I didn't have this problem until they migrated my host to a new node (by request).
You can also fix this yourself by making your if-up statement similarly- after removing the default route for IPv6;
ip -6 route add default via fe80::1 dev $IFACE onlink
+1
Do you have any insider info about the actual host nodes? I'm genuinely curious to see why these virtually-indistinguishable KVMs act differently, even with same virtualized interface.
No sorry was just about ipv6. Autoconf so far has always been the first thing to turn off... can't why you got two different cups of tea though
I just checked, and the VPS are actually root-servers, too. I didn't think it directly correlated since the migration.
I also got a couple lower-resource nameservers, and that 3GB beast for serving my pointless interweb pages. Since my nameserver TLD is rejecting my netcup IPv6, I assume that may be why it's taking longer to resolve using external nameservers, but running dnsmasq as a cacher on my HTTP/HTTPs VPS took care of that rather quickly.
I wish I had made up my mind about downsizing before I prepaid for a few months of @Dacentec.
I wanted to say that I think that you have a Root-Server ...
fe80::/64 dev ens3 proto kernel metric 256 pref medium
default via fe80::1 dev ens3 metric 1024 pref medium
FYI, I have a vServer, and I get the following as the output of
ip -6 route
:I've haven't adjusted IPv6 autoconf explicitly, but I'm pretty sure that it's disabled by default. (I'm running Slackware. :-D )
See that?
Thanks for the heads up -- I wasn't paying sufficient attention earlier.
ip -6 route
now shows:This is better, no? :-)
However, after experimenting a bit, I found that I didn't have to mess around with
sysctl
parameters at all, which I'd prefer not to unless absolutely necessary.The following sufficed (the device in my case is
eth0
):The second line is what you proposed but without
onlink
(which doesn't seem to be necessary, and I'm not sure what unintended behavior the addition ofonlink
might have).The first line is my contribution, which simply deletes the route implicitly set by the system.
This seems to work.
Neither were you now. I said that the ip route statement addition statement should easily fix the issue at hand. It's still a good idea to disable autoconf, because it's just another Linux TCP stupidity to have enabled by default.
onlink is kind of a boolean, which tells you if the subnet is on the same link or not. It's deprecated with networkd (which shouldn't exist).
Neither was I what now?
Okay, then I misunderstood the logic of your suggestion: I thought that you were saying that both were needed.
What I didn't say above is that during my experimenting, I found that I couldn't merely add your suggested
route add
statement (with or without the suggestedsysctl
parameters). The problem was that this statement alone yielded the errorRTNETLINK answers: File exists
, and the new route wasn't set as a result. By first deleting the default route, and then applying yourroute add
statement, it worked.(It's not that I'm against disabling IPv6 autoconf in principle, but I was just looking for a solution of the smallest intervention necessary for the problem at hand. Thanks again for pointing out the original problem.)
Paying attention.
You need less sugar, and more bran. Glad it worked!
Okay, touché, I guess that I really wasn't paying attention! You win this one.
But by misreading you, I discovered that I didn't need to disable IPv6 autoconf (which I'd prefer not to do). :-)