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.
★ VirMach ★ RYZEN ★ NVMe ★★ $8.88/YR- 384MB ★★ $21.85/YR- 2.5GB ★ Instant ★ Japan Pre-order ★ & More
This discussion has been closed.
Comments
@VirMach
Please check the VNC of PHXZ001, it cannot be used normally, and the prompt: Failed to connect to server (code: 1006), in addition, when will the paid migration be processed? I've been waiting for a long time, and I'm still waiting patiently.
I m sorry, it seems that my prev quote was wrong.
In sum, I cannot reinstall os using solus panel caused by "No media found for this virtual server"
That mass update issue is already fixed for anyone migrated before a few days ago, this is an entirely different issue.
I hope you're feeling better now
have you considered maybe the above VPN tunnel is your issue? multiple people using the same VPN and trying to login to different account would raise a red flag.
How am I going to be able to fix this, without ssh access, without being able to login to vnc, and now I can't even reinstall the OS on the solus panel ? ( No media found for this virtual server )
And remember... not everyone has the skills to do more complex things..
Cheers
I'm not sure but I think that depends a little on how much memory your system has too. I haven't tested scientifically yet but I know that some of my little guys don't seem to like netboot.xyz but will install via ISO.
I just checked all my VPS all are online 14 from 14 (all random locations as I wanted as that), sure there where dozen of fuckup as 2xIP change on one VPS and one needed to be migrated ...
in past there where also network glitches ... let see if they are sorted with this change
and yeah few VPS did not have IP change yet, not sure if they will
Man you should chill out otherwise you're going to have a heart attack, m'kay?
Where are you guys moving to after this?
Tokyo if possible?
@VirMach ban ip issue
I am the only user on a cable Internet connection. I have Google Chrome open with a single tab when I login to the VirMach customer portal. Pass the reCaptha and 2FA.
Fact: In one 24 hour period I logged in to check VPS status approximately 8-9 times. This got my IP banned for 24 hours with a notice that my IP had 74 failed login attempts.
Here's what I think is happening with the VirMach webportal detection system.
https://www.softwaretesttips.com/why-does-the-task-manager-show-multiple-chrome-processes/
I think the client portal is picking up multiple processes, so if 9 chrome processes are running, the VirMach webportal detection system will count a single successful login as 7-8 failed login attempts. So 8 successful logins are seen as 64 failed attempts.
So I stand by my previous assessment. The VirMach customer portal penalizes legitimate customers with draconian 24 hour bans for normal fequent login's.
Pls fix it asap
Well, mine has like 2 weeks there, my VM gets the IP form the DHCP fine, but I cannot ping the gateway, or having internet.
Any ETA?
Nowhere. Mine are some game servers, VPNs, and dev. And for the price, I wont move.
Nope, I never used the VPN tunnel to login to the customer portal. I have several VPS servers running openVPN-server so I can surf without my ISP tracking my activities. When my IP was banned for 24 hours that just made me fire up a VPN so I could login with a non banned IP to see if VirMach had added media to the panel so I could reINstall an OS on two of my dozen VPS's.
Had a single malt and a Cohiba cigar right after that post, the smoke and beverage was much more enjoyable.
So just to be clear, it doesn't count failed login attempts, it just counts login attempts. I apologize if the ban reason says failed login attempts, if it does say that anywhere, let me know and I'll change the message.
It shouldn't count 9 if you have 9 chrome processes, unless those 9 processes are all our website. It only counts login calls. We didn't code the system and we didn't code Chrome, but in testing, one login attempt counts as one login attempt but we definitely have confirmed when we have a lot of tabs open, for example, that it will eventually start spamming requests for whatever specific reason. Unfortunately unless we build a much more sophisticated system on top of it instead of just monitoring the requests to the webserver, that would take a lot of development time we don't have right now, it would potentially have loopholes, and in the end it may still end up with the same results if our billing system says that there are further login authorizations. If we try to make it more specific by using other arbitrary behavior that matches a login attempt better, then again, it opens it up for abuse by the attackers.
The only other thing we could really do, which is in the works, is modifying the timers, to make it more lenient for false positives, but then we'd have to be careful as if the consequences are reduced and logging period is reduced, then it would activate sooner and with a lower quantity of requests, which means instead of locking you out for several hours after several hours of usage, it could end up locking more people out every 5 minutes for 15 minutes (just an example, those aren't our actual planned changes.)
The other solution we tried is forcing two factor on clients, but that went very poorly as well. We could try to allow two factor accounts to bypass the ban, except the system is not tied to accounts but instead IP addresses (we have another system for accounts that acts differently, and does not block access to the site.)
Assuming that 1 request gets counted as 9 requests, and we assume that's the average, just for this hypothetical fix, and we increase the amount by 9 times, then the abusers could take advantage of that by ensuring each login is only one request.
We do monitor the bans every once in a while to ensure that the false positives remain extremely low. For example, yesterday, the banned IP addresses were proportional to under 1% of all successful logins.
Taking a look at all nodes facing network problems to try to alleviate them at least partially again, and hopefully by tomorrow we start seeing some network configuration changes from the datacenter(s)
It's on the to-do list for today, pretty high up there. I'm almost getting to it.
Why can't my Phoenix SSH connect? It's been a few weeks and no one has responded to my ticket
I have to VMs that I can login, but on the control panel, it cannot connect to Solus. Do I need to raise a ticket? Or do you know those problems already?
Okay, I think you guys are working on it because I finally saw it go from offline to online and things are getting better. We'll continue to wait for your fix.
SEAZ005
ATLZ005
At present, these nodes only have the old IP ( ColoCrossing ), the vps network is not accessible , please check whether the new IP is not assigned. Thanks.
@VirMach
Hahaha ... hard working boss
Seeing that solusvm is updated, I tried starting the vps, still doesn't work! The ping also times out and the panel doesn't work #233805
It seems to be worth waiting. After @VirMach migrating to Ryzen, the drive IO performance is almost 100 times better than before. Hope the server won't go down again from now on.
CPU Model : AMD Ryzen 9 5950X 16-Core Processor
CPU Cores : 2 @ 3393.588 MHz
CPU Cache : 512 KB
AES-NI : Enabled
VM-x/AMD-V : Enabled
OS : Debian GNU/Linux 11
Arch : x86_64 (64 Bit)
Kernel : 5.10.0-16-amd64
Virtualization : KVM
Organization : AS8100 QuadraNet Enterprises LLC
Location : Los Angeles / US
Region : California
I/O Speed(1st run) : 1.1 GB/s
I/O Speed(2nd run) : 1.1 GB/s
I/O Speed(3rd run) : 1.4 GB/s
I/O Speed(average) : 1228.8 MB/s
Node Name Upload Speed Download Speed Latency
Speedtest.net 726.71 Mbps 751.38 Mbps 56.80 ms
Los Angeles, US 936.26 Mbps 935.80 Mbps 1.60 ms
Dallas, US 915.82 Mbps 841.63 Mbps 29.63 ms
Montreal, CA 785.91 Mbps 936.00 Mbps 68.60 ms
Paris, FR 747.60 Mbps 378.84 Mbps 147.93 ms
Amsterdam, NL 520.47 Mbps 420.35 Mbps 141.48 ms
Seoul, KR 611.53 Mbps 800.84 Mbps 147.66 ms
Singapore, SG 524.86 Mbps 632.33 Mbps 162.52 ms
Tokyo, JP 668.23 Mbps 448.37 Mbps 99.85 ms
Anyone's VM got moved from AMS to FF without opting-in for migration?
@VirMach DALZ008 is down for 2 weeks+ ,VNC is working but cannot ping through default gateway,cannot ssh . take a look for my ticket if you want more detail: #669461
Everyone, as AMS was emergency migration due to shit happening there
.
I assume they still have plans to open 'change location one time' soon and you will be able to migrate it back to (Ryzen) Amsterdam.
All the old nodes are facing this problem. Ryzen we were able to update quickly since we have them pulled up already. Old nodes couldn't but they were all fixed last night.
We're aware of all these, they occurred on nodes facing a higher load as the script that changed the IP addresses ran into problems. We mitigated this on newer migrations by processing the change afterward but it's still not perfect. Only a small amount are left in this state and we should hopefully clear most if not all of it up by tomorrow.
Still haven't slept since we last spoke, outside of a 30 minute involuntary nap in my office chair. A lot of the issues have been resolved. I'm going to try to work on VMs that have broken disks next, as in the ones stuck for multiple weeks now from the Ryzen migrate without data button.
Yes, everyone. The majority were moved a few months ago already, only a few leftovers and we ran out of space in Amsterdam by then. I described it better somewhere above but it will be difficult to find. You'll be able to move back to Amsterdam without data using the Ryzen Migrate button, or with data at a later time (we haven't planned this part out yet.)
DALZ008 isn't down for 2 weeks but it's possible your service is facing that issue.