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
I'm not having issues in BG at this moment.
yep...
Yep SSH is refusing for me
I'm curious if at least one VPS on the host can provide sar logs that include the downtime.
Connection refused for SSH is weird. I would expect no response, or most likely no handshake.
Sometimes I get no response. Other times SSH refused.
Connect over VNC and run tcpdump while trying to establish an SSH connection.
Steal is even worse now, hovering at 70%. The Tor process, which normally takes under 50% CPU to relay ~50 Mbps, is taking 99% of the CPU to relay only 2 Mbps.
Ticket as been fulfilled as @MannDude was waiting for everything to stabilize. I can report that conditions have stabilized for me. New YABS
I'm still experiencing high CPU steal, 20-30% in the last 24 hours. Perhaps we are on different SE nodes?
Ran
topand watched for a few minutes. Steal never rose above 1%; usually just went to 0.3% every few seconds. It's possible we're on different SE nodes, but we'll need @MannDude to verify.Shoot me a ticket or PM with the server IP.
Issue has been resolved! It was residual throttling that hadn't yet been removed. It was removed and CPU steal is now well under 1% again!
@MannDude Is there any chance you could run a recursive DNS resolver on your host nodes and have it listen on the gateway so VPSes can use it? That would allow Tor exit operators to significantly improve DNS privacy. Operators cannot run it on their assigned IP because some nameservers will block Tor exits, so operators are forced to either purchase a second costly IPv4 just for DNS, or send their DNS queries to upstream, centralized services.
A simple Unbound config in
/etc/unbound/unbound.confthat provides a DNS server with caching with a 300 second TTL, strong anti-poisoning techniques, access control so only hosts on that node can use it, and a privacy-preserving local root zone (RFC 8806) would be:Then all you have to do is have cloud-init put
nameserver 203.0.113.1in/etc/resolv.confin the VPS guests (andnameserver 127.0.0.1on the host node itself) and everyone, including Tor exit operators, get fast, private DNS.In this example, 203.0.113.1 is the gateway that each VPS uses, 203.0.113.125 is a clean IP address on the node (e.g. the node's own IP, not assigned to any VPS), and 2001:db8:36ee:14::/64 is a routed IPv6 subnet with no Tor exits on it.
I used to but Tor bitched to us about filtering ads. It was the same blocklist we used for VPN, was just ads, trackers and malicious (malware, known phishing, etc) URLs. I couldn't be bothered to setup DNS without filtering for Tor only.
Exits can't have ad blocking DNS apparently so will set something up eventually. 👍
Shameless plug: There are dnscry.pt relays available in Amsterdam, Liberty Lake and Allentown which don't support plain DNS but DNSCrypt, DoT and DoH, if that helps.
That could be a way but tor exit relays generate a lot of dns requests which can cause issues for the dns server if it's unable to handle the load/traffic and of course less centralization. I would prefer just running one myself.
I prefer DoT and, if I need to, would use dns.sb which is a privacy-friendly provider. However that, and DNSCrypt, send the queries to a third party anyway. If the resolver is run on the same node that the exit is hosted on, then it's not being sent to any entity that doesn't already run the exit.
Unbound is highly optimized and can handle a tremendous rate of queries. Nothing a Tor exit could do would be able to overload it, and its caching would actually reduce total traffic compared to every VPS simply having 8.8.8.8 in their resolv.conf. Centralization, if it's not centralized to a third party, can actually help as a network-level adversary can no longer determine which lookup came from which exit.
I do run Unbound myself on all my exits, personally, but that requires a second IPv4 which is expensive.
If you are running only a couple exits having it run locally like mentioned in Tor docs is fine but if you are running a lot of them like some of the bigger operators are then, I would spin up a vps just for dns and it can be used across all the exits.
Been using VirtFusion for long enough now that it's time to bite the bullet and force all old legacy users to it.
If you are in LIBERTY LAKE, WA and want to migrate yourself, let me know. Will be happy to not have to manually do it for you. I'll create a new VPS for you of the same specs as your old one and let you manually migrate the data before I terminate your old legacy VPS. There will be an IP change with this method. I can reassign your old IP back to you after the migration, if you want. If you migrate yourself so we don't have to do it for you I'll give you $5 account credit just as a "thank you" for saving us some time.
Scheduled backups are coming soon. Probably be an opt-in at a slightly increased cost, but for those who want to stick to manually triggered offsite backups you should now have the option for 5 backup/restore slots instead of the previous 3.
Getting a new NA and EU backup server online right now to accommodate this.
I recommend waiting on this. We are about to release v7, which includes a completely new backup and restore system. It features incremental backups with deduplication and is significantly better. Unfortunately, it is not backwards compatible.
I'll wait
I plan on doing that with DoT eventually, although only for my European servers as that is where most of the exits are. Exits outside of the EU would have too much latency to round-trip DNS there.
You'll be happy once we get our Tor stuff updated, I think.
Unrelated: Virtualizor to VirtFusion migrations are a PITA. Slow going. Slowly but surely. Haven't lost any data yet. * knock on wood *
Actually, the Virtualizor to VirtFusion migration isn't that bad. It's tiring, as it's all manual tasks and data-entry, but for the curious.
qemu-img convert -f raw -O qcow2) with a .img filename that matches the new one created in VirtFusion (ex: abcd1234-69b0-0bs1-bd2c-f51ecd8db9d1_1.img )Fun times.
If only you had a bunch of interns to handle grunt work!
Neat to see the work checklist though, thanks for the insight.
VirtFusion should make a big red migrate button.
100% Agree! @VirtFusion Can this be a thing?
Sounds like the kind of thing you could automate.
The filetype conversation and migration of disk images can be automated with ease but needs to be done after WHMCS does stuff. Seems like a nightmare to automate based on three different products needing to do tasks back and forth and manually just feels safer at the moment and the only way to minimize downtime.
VirtFusion is aware of their position in the market and the desire for such a tool, knowing of an possible influx of Virtualizor refugees is possible. I've waited in the hopes something official may come out. In the end the safest method to do this now seems to be how I'm doing it. I'm not going to vibe code something that will require days of testing and may break stuff nor do I want to setup safe test environments for such a tool. I just want to migrate things one at a time for now, at my own pace.