GreenValueHost becoming ColoCrossing, dumping providers, etc.
- Thread starter drmike
- Start date
Spamhaus listed our entire /21 because of 3 emails recently. A quick response to them that the abuse was handled and what was being used on the /21 in different segments got us quickly delisted.
No ones arguing if spamhaus is a bunch of assholes. Given 500+ listings this year alone, and many very large, it isn't exactly like they're at fault.
@serverian - Well, do they have multiple AMS nodes? If so it could be an honest issue especially if people were getting randomly disconnected.
I'll give him the benefit of a doubt on the AMS stuff since the LAX stuff was already disclosed in a different posting.
Francisco
DomainBop
Dormant VPSB Pathogen
If the provider is honest and takes care of the problem the Spamhaus delisting process is usually quick. I ordered a server from SeFlow last fall and I checked the SBLs when the server was delivered and the main IP was on a Spamhaus SBL. I opened a ticket and 45 minutes later the IP was delisted...and this was late on a Saturday afternoon.
ColoCrossing isn't on Spamhaus shit list because as MPKossen and Biloh moronically claim "Spamhaus is living in 2001 and doesn't understand VPS/cloud/cheap servers/etc.". They're on the shit list because they have a track record of lying through their teeth to Spamhaus.
I've lost count of the number of times they've claimed to have terminated a spammer and then 2 days later the same spammer is spamming from the exact same IP address.
There also has been a very clear pattern of big time spammers being rotated through ranges belonging to HudsonValleyHost, New Wave Netconnect (ChicagoVPS), and unswiped IPs direct from ColoCrossing. If you go through the SBL's you'll see that the vast majority of CC SBL's are HVH/CVPS/unswiped.
ColoCrossing isn't the only provider trying to stay under the radar by rotating very profitable big time spammers through their IPs but they're on Spamhaus shit list because they're completely inept at trying to cover the evidence and got caught. If you want an example of a provider who plays the rotating IPs game on a daily basis with a very profitable megaspammer and stays under the radar google: '2360 Corporate Circle hosting' (this info courtesy of a little birdie)
Last edited by a moderator:
DomainBop
Dormant VPSB Pathogen
Probably having a stroke. E n z u is correct but their brand name starts with Budg... (ServerHub is unrelated to them and is owned by Eonix)
Last edited by a moderator:
Sound like Jon bailed and didn't pay his bills to EDIS... That is more likely.
Or does someone, more familiar with SolusVM, want to chime in and note if there is a known IP issuing bug that's gone unfixed for years?... :huh:
Last edited by a moderator:
I'm not ignoring you though
Aldryic C'boas
The Pony
Speaking as someone who spent a LOT of time having to deal with poor Solus code - newp, never saw _any_ evidence of such a bug.
Let's consider some other logical points while we're at it:
- If he's been assigning the same IP to multiple VMs, and this has been happening on a large enough scale that it requires a RENUMBER, you would have seen a lot of people complaining about constant MITM warnings.
- If he's been assigning the same IP to multiple VMs, and this has been happening on a large enough scale that it requires a RENUMBER, then obviously "Guru Network Master Vice President Extrordinaire" is not one of the positions he's filled.
- If he's been assigning the same IP to multiple VMs, and this has been happening on a large enough scale that it requires a RENUMBER, I wonder how many times his "staff" has unknowingly set new root passwords for VPSes and allowed random people access into VMs that aren't theirs.
And I can't *WAIT* to hear the excuse for this one:
- If he's been assigning the same IP to multiple VMs, and this has been happening on a large enough scale that it requires a RENUMBER, surely we can expect the SAME RANGES TO BE REUSED.
^ Except if said ranges are no longer available to him now that he can't afford to pay EDIS and has to run back to CC. So, keep a watch on the IPs after the renumbering passes.
GVH-Jon
Banned
IP renumbering is going to be done out of the same exact block. All IPs in the block would be taken back and put in an available pool, then assigned again. This is because there was a code error in our in-house developed automated mass OpenVZ VM migration/IP assign script that forgot to sync IPs in line with what Solus thought was the available pool.
Stop talking out of your ass Curtis.
Stop talking out of your ass Curtis.
Aldryic C'boas
The Pony
The "script" forgot? What you mean to say, is that you ran shitty code in a production environment, very likely without proper testing beforehand.
Funny how when you do an OpenVZ migration, even manually, the only thing that needs to be updated in Solus is the nodeid. You see, OpenVZ stores information such as what IPs are assigned to a VM in that VM's conf file, right on the node. And when you perform a migration, one of the first things OpenVZ does is recreate said conf on the new node, ensuring that all of the same specs/settings/ips are intact.
So what does this mean for little Jon's story? Well, if you strip the excessive BS and just look at what he's actually saying, you get "In-Use IPs were marked as available in Solus, and re-assigned to new VMs". Well, we just covered that OpenVZ migrations don't require screwing with Solus' ipaddresses table, so just what was going on there?
In order for Solus to reassign those IPs, the ipaddresses.vserverid field would've had to be set back to 0/''. This doesn't happen on its own - either someone removed and readded a range in Solus, or this "in-house developed script" was designed by someone that has no CLUE what they're doing. And those are the folks administrating the nodes, folks. Pretty damn scary.
Just to grind a little bit more salt in, and show just what a BS excuse this is - even if this 'automated script' nonsense is true (why the hell would you want 'automated mass migration'... do you even know what that means?), and a bunch of clients had duplicate IPs... why would you renumber entire locations? Out of (boredom, mostly), I wrote a couple of quick bash and perl scripts. The first one queried _EVERY_ one of our OpenVZ nodes, took note of containers sharing an IP. The second script, had the first found any matches, would've given the newest VPS of the pair a new IP, removed the duplicate, then hit the Stallion API to email the client letting them know what had happened. That's problem fully solved _AND_ affected client notified, all in under half an hour. Now, based on estimated runtime for processing say... 15,000 VPSes with duplicate IPs - I figure that whole process would've taken 3-4 hours.
But, no. He only has 3 nodes affected, and his solution? Mass-renumber, inconveniencing EVERY client on the node, and causing even more damaging PR when he has to *struggle* to get even backhanded compliments.
Honestly, anyone that believes his stories deserves to be his "client" at this point.
Funny how when you do an OpenVZ migration, even manually, the only thing that needs to be updated in Solus is the nodeid. You see, OpenVZ stores information such as what IPs are assigned to a VM in that VM's conf file, right on the node. And when you perform a migration, one of the first things OpenVZ does is recreate said conf on the new node, ensuring that all of the same specs/settings/ips are intact.
So what does this mean for little Jon's story? Well, if you strip the excessive BS and just look at what he's actually saying, you get "In-Use IPs were marked as available in Solus, and re-assigned to new VMs". Well, we just covered that OpenVZ migrations don't require screwing with Solus' ipaddresses table, so just what was going on there?
In order for Solus to reassign those IPs, the ipaddresses.vserverid field would've had to be set back to 0/''. This doesn't happen on its own - either someone removed and readded a range in Solus, or this "in-house developed script" was designed by someone that has no CLUE what they're doing. And those are the folks administrating the nodes, folks. Pretty damn scary.
Just to grind a little bit more salt in, and show just what a BS excuse this is - even if this 'automated script' nonsense is true (why the hell would you want 'automated mass migration'... do you even know what that means?), and a bunch of clients had duplicate IPs... why would you renumber entire locations? Out of (boredom, mostly), I wrote a couple of quick bash and perl scripts. The first one queried _EVERY_ one of our OpenVZ nodes, took note of containers sharing an IP. The second script, had the first found any matches, would've given the newest VPS of the pair a new IP, removed the duplicate, then hit the Stallion API to email the client letting them know what had happened. That's problem fully solved _AND_ affected client notified, all in under half an hour. Now, based on estimated runtime for processing say... 15,000 VPSes with duplicate IPs - I figure that whole process would've taken 3-4 hours.
But, no. He only has 3 nodes affected, and his solution? Mass-renumber, inconveniencing EVERY client on the node, and causing even more damaging PR when he has to *struggle* to get even backhanded compliments.
Honestly, anyone that believes his stories deserves to be his "client" at this point.
I can say that I have seen the issue happen before where for some reason solus does try to assign the same IP more than once, however it was not on a large scale. Just one here or there.
same thing with virtualizor plus sometime it will not assign ip
The only time we ever had this happen was when we'd have multiple PROVISIONS going at once, since solus doesn't issue an 'ORDER BY RAND' when they polled the IP table nor have any sort of queue runner.
Migrations won't cause this to happen since, as mentioned, the only thing you're updating (and maybe not even) is the node ID of the CT. The ipaddresses table still holds the vserverid assignment, etc.
Now, if they had suffered a fairly serious solusvm DB corruption and had to rebuild from scratch, then OK, I could see it happening if they didn't mark every IP properly.
Francisco
Francisco
Last edited by a moderator:
Again, this is provisions, not migrations.
It's possible it was what I mentioned above (multiple provisions at the same time with poor SQL queries/no job queue).
Francisco
drmike
100% Tier-1 Gogent
So this AMS snafu, the IPs people are getting are they new IPs?
Someone have a pre-existing one so I can look at ownership? Interested in the post even IP also, so we can debunk bugs, migrations from IP providers, etc. Lack of info means anyone can claim anything... But big picture, I have a bet on change of IP provider. Whether that's an invoice due or not, well...
Someone have a pre-existing one so I can look at ownership? Interested in the post even IP also, so we can debunk bugs, migrations from IP providers, etc. Lack of info means anyone can claim anything... But big picture, I have a bet on change of IP provider. Whether that's an invoice due or not, well...
drmike
100% Tier-1 Gogent
You mean like copying the live database tables over on a running MySQL instance
Ho hum, something like that happened back there... with other stuff... just saying, cause it has been said before ... and I have the memory of an elephant about some things.
SolusVM doesn't use innodb so it's possible to repair the DB and lose a couple rows at most.You mean like copying the live database tables over on a running MySQL instance
For the most part it'll work and not be a total melt down.
Francisco
Nick_A
Provider of the year (2014)
Thanks! Guess my questions are not valid though.I'm not ignoring you though