CloudAtCost legacy wiki
DC-1
You cannot build a machine in this 'Datacenter' as of May 4th, 2016 or earlier... We don't know.
DC-1 is the first known datacenter option offered by CloudAtCost for their CloudPro infrastructure. It's been interpreted by many as being their DC with the highest individual VPS uptime, however due to abuse (and the fact that DC-1 was the only option for a considerable length of time) it's likely the slowest option for disk I/O and network performance.
Contents
- <a href="https://wiki.eddyn.net.com/index.php?title=DC-1#I.2FO_speed_tests">1 I/O speed tests</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=DC-1#Speedtests">2 Speedtests</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=DC-1#rDNS">3 rDNS</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=DC-1#CPU_Options">4 CPU Options</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=DC-1#ESXi_Nodes">5 ESXi Nodes</a>
I/O speed tests[<a title="Edit section: I/O speed tests" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=DC-1&action=edit§ion=1">edit</a>]
High end
- I/O (1st run) : 54.9 MB/s
- I/O (2nd run) : 61.4 MB/s
- I/O (3rd run) : 59.0 MB/s
Average I/O : 58.4333 MB/s
Low end (average CaC I/O as submitted by users)
- Not enough data
Speedtests[<a title="Edit section: Speedtests" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=DC-1&action=edit§ion=2">edit</a>]
High end
Cachefly 7.93MB/s
Low end
Cachefly 849KB/s
rDNS[<a title="Edit section: rDNS" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=DC-1&action=edit§ion=3">edit</a>]
The following IP blocks for DC-1 currently have working rDNS:
- 104.167.x
- 104.233.x
CPU Options[<a title="Edit section: CPU Options" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=DC-1&action=edit§ion=4">edit</a>]
- Intel(R) Xeon(R) CPU L5520 @ 2.27GHz
- Intel(R) Xeon(R) CPU X7560 @ 2.27GHz
ESXi Nodes[<a title="Edit section: ESXi Nodes" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=DC-1&action=edit§ion=5">edit</a>]
<tbody></tbody>Node | CPU | Network | Console |
---|---|---|---|
esx62 | L5520 | OK | Working |
esx1027 | E7450 | OK | Working |
esx1028 | E7450 | OK | Working |
esx1033 | E7450 | OK | Working |
esx174 | ? | OK | Not Working |
Change ESX
If you're having connection, node-based issues, or your VM seems to have suddenly "disappeared", a simple reboot in most cases will fix the problem. In many cases, problematic VMWare vSphere ESXi nodes may cause problems with connectivity, incredibly slow node, etc.
To change the machine's ESXi:
1) You might want to safely power down your OS first.
In the <a rel="nofollow" class="external text" data-external="true" href="http://panel.cloudatcost.com/">CloudAtCost panel</a>:
2) Power Off VM
3) Power On VM
You can check if you've been moved by going into the "Console" and checking the URL, as shown:
http://panel.cloudatcost.com:40521/console.html?servername=cXXX-cloudpro-XXX<span class="err">&</span>hostname=esx3024.cloudatcost.com<span class="err">&</span>sshkey=XXX<span class="err">&</span>sha1hash=XXX
Based on the above link, the ESXi in this case would be 3024 (hostname=esx3024.cloudatcost.com).
Console
Console access with CloudAtCost is served over unsecured HTTP protocol allowing any user to copy his/her console URL and paste it to another user on a different network, resulting in a positive authentication.
Console access is incredibly unstable, you can build a machine, have access and later lose access only to regain it again. We recommend deleting any machine that doesn't initially have console access.
Console is also unencrypted, best practice is to only use the console for netinstalls and forcing fscks.
Alternate Console Access[<a title="Edit section: Alternate Console Access" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Console&action=edit§ion=1">edit</a>]
CloudAtCost uses noVNC for it's console connections. It is possible to connect to your server instance via noVNC's website.
Step 1
You will need to go to your CloudAtCost control panel and select console. A window will pop-up and begin to connect to the server.
Step 2 The URL will begin with "<a rel="nofollow" class="external free" data-external="true" href="https://panel.cloudatcost.com/console5/open-console.php">https://panel.cloudatcost.com/console5/open-console.php</a>" but this will soon change to something like
"<a rel="nofollow" class="external free" data-external="true" href="http://panel.cloudatcost.com:40000/console.html?servername=c#########-cloudpro-#########&hostname=esx3028.cloudatcost.com&sshkey=40000&sha1hash=ABCdEfG1HI">http://panel.cloudatcost.com:40000/console.html?servername=c#########-cloudpro-#########&hostname=esx3028.cloudatcost.com&sshkey=40000&sha1hash=ABCdEfG1HI</a>"
this is the URL we are interested in
Step 3
from this second URL we need to extract the following information: Hostname, Port number, and Password.
1. The Hostname should always be "panel.cloudatcost.com"
2. The Port Number is the sshkey in the URL. in the example the port is 40000
3. The Password is the sha1hash in the URL. in the example it is ABCdEfG1HI
Write these three things down.
Step 4
Go to "<a rel="nofollow" class="external free" data-external="true" href="http://novnc.com/">http://novnc.com</a>" then go to the 'Connect' button next to the settings button. Enter the hostname the port number and the password and then hit connect.
Done
CloudAtCost IP crisis
The CloudAtCost IP crisis is a name to describe the exhaustion of IP resources in the entire available pool.
People will frequently experience the following error when generating a new virtual machine:
Failed: Cant Get IP from DC-X. Please Try again.
The ASN used on these addresses is assigned to <a rel="nofollow" class="external text" data-external="true" href="http://bgp.he.net/AS55053">AS 55053</a>.
In more rare cases, some IP's may even be assigned to more than one customer. This generally results in packet collisions and VM's which have partial or no network functionality.
IP Ranges[<a title="Edit section: IP Ranges" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=CloudAtCost_IP_crisis&action=edit§ion=1">edit</a>]
Here are the following known IP ranges used in each DC.
DC-1:
<tbody></tbody>104.167.x.x |
104.233.x.x |
DC-2:
162.x.x.x |
167.x.x.x |
45.62.x.x |
64.137.x.x (crossover from DC-3) |
DC-3:
64.137.x.x |
Solutions[<a title="Edit section: Solutions" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=CloudAtCost_IP_crisis&action=edit§ion=2">edit</a>]
In most cases, just waiting a short period of time will generally be enough to free up IP space from destroyed instances. It is unknown whether IP space after an instance has been destroyed is immediately usable once more, or is allocated at another time.
However, if you're having continual issues, you might want to give the new <a title="Undocumented API" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Undocumented_API">Undocumented API</a> a try. It allows you to specify a DC which may have IP space available.
If you've been assigned a duplicate IP, you can either open a support ticket or just regenerate the VM until you're assigned an IP which is not already assigned. If you suspect a duplicated IP has been assigned to you, you can always check with "arping" on GNU/Linux or "Wireshark" on Windows systems.
Coupons
Contents
- <a href="https://wiki.eddyn.net.com/index.php?title=Coupons#Coupons">1 Coupons</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=Coupons#50.25_OFF_TODAY">2 50% OFF TODAY</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=Coupons#TAKE70">3 TAKE70</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=Coupons#TAKE80">4 TAKE80</a>
- <a href="https://wiki.eddyn.net.com/index.php?title=Coupons#End_of_Month_Sales">5 End of Month Sales</a>
Coupons[<a title="Edit section: Coupons" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Coupons&action=edit§ion=1">edit</a>]
This is a frivolous term thrown about all willy-nilly by CloudAtCost, alleging claims that the bearer of the coupon is entitled to XX discount or free resource
50% OFF TODAY[<a title="Edit section: 50% OFF TODAY" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Coupons&action=edit§ion=2">edit</a>]
This is a perpetual sale always on through Cloud At Cost, advertised at all times on the website. It is the default discount during checkout, always at 50%. It applies to all CloudPro tiers.
TAKE70[<a title="Edit section: TAKE70" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Coupons&action=edit§ion=3">edit</a>]
This is a perpetual coupon code. It can be entered on the Order Summary page. It will reduce the base price by 70%. Unknown tier compatibility.
TAKE80[<a title="Edit section: TAKE80" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Coupons&action=edit§ion=4">edit</a>]
This is a perpetual coupon code. It can be entered on the Order Summary page. It will reduce the base price by 80%. Unknown tier compatibility.
End of Month Sales[<a title="Edit section: End of Month Sales" data-external="true" href="https://wiki.eddyn.net.com/index.php?title=Coupons&action=edit§ion=5">edit</a>]
Cloud At Cost commonly puts out promotions on the last day of every month. The coupons will be released on the <a rel="nofollow" class="external text" data-external="true" href="https://twitter.com/cloudatcost">Twitter Page</a>, <a rel="nofollow" class="external text" data-external="true" href="https://members.cloudatcost.com/index.php">Members Page</a> , and sent as an email to registered users.
The promotion will begin with the release of a coupon code for a 100% discount code for any tier server. The code can only be used once per unique account. It will work for the first 100 accounts to claim it.
The promotion will then be updated on Twitter and Members Pages to have a 90% discount code. Compatibility with tiers, eligibility, and uses-per-account can vary with each promotion.
The promotion may be updated with 70% and 80% discount codes, but they add no more benefit over any other day to order the services.
CloudAtCost miracle
From wiki.eddyn.net
Jump to: navigation, search A CloudAtCost miracle is described as an instance in which a previous or current problem with CloudAtCost services have been miraculously solved.
The most common problems noticed are long waits for virtual machine deployment, loss of network connection, or total loss of a virtual machine. This is generally more common after major sales (such as the 2016 Black Friday sale).
Examples[edit]
A few examples:
Virtual instances notoriously take a profound amount of time to deploy, and in many instances, fail to deploy at all. This is especially prevalent in major sales (see 2016 Black Friday Sale). However, it is possible if you're persistent enough. If you successfully deploy a machine, you'll generally next face network issues (physical or virtual), R/O (read-only, especially on DC-3), and rather slow performance (as a result of abuse and virtual limitations). Rebooting your machine will meet mixed results, such as machines getting stuck during ESXi transitions, loss of network on another node, etc. However, in some cases, you'll land on a node which is actually pretty stable. This had generally been more common in DC-1 (and DC-2 sometimes). Contacting support generally entails your ticket being closed after waiting a long period of time. If you do get a response, it's a mixed bag whether they'll fix the issue at hand. However, they do actually fix issues (such as stuck virtual machines during ESXi power-off transitions, common issues, etc). In some cases, people do get their problems solved though. Experiences[edit]
Post your experiences here!
Retrieved from ‘http://www.wiki.eddyn.net.com/index.php?title=CloudAtCost_miracle&oldid=186’
Undocumented API
From wiki.eddyn.net
Jump to: navigation, search The API the panel uses includes a few improvements over the published "API v1".
Namely: - The ability to specify the data centre when building a VM
Regressions[edit]
Unfortunately, the new panel doesn't use a proper API-like structure. For example, the list of VMs is embedded in index.php, rather than being supplied in JSON and then interpreted. This gives the panel an old-world style behaviour. e.g. refreshing the whole page when things change.
URLs[edit]
https://panel.cloudatcost.com/panel/_config/pop/cloudpro.php?CNM=
https://panel.cloudatcost.com/build-cloud-pro.php [HTTP POST]
Params:
datacenter int Currently (1, 2, or 3) cpu int Number of CPUs ram int Amount of memory in MB storage int Amount of storage in GB os int Operating System to load (see below) cid int The customer ID - should be ~9 digits freecpu int Obviously remaining CPU in the account, but as to why we'd be posting this, I have no idea. freeram int Ditto for free RAM freestorage int Ditto for free storage btkn int An API token, presumeably
Operating Systems:
1 CentOS 6.7 64bit 15 CentOS-7-64bit 3 Debian-8-64bit 18 FreeBSD-10-1-64bit 16 Ubuntu-14.04.1-LTS-64bit 13 Windows 2008 R2 64bit 14 Windows 2012 R2 64bit 4 Windows 7 64bit Retrieved from ‘http://www.wiki.eddyn.net.com/index.php?title=Undocumented_API&oldid=138’
DC-2
From wiki.eddyn.net
Jump to: navigation, search DC-2 Arguably the best DC CloudAtCost has to offer (currently the only) RIP (Machines are Still Up)
Contents
1 I/O speed tests 2 Speedtests 3 rDNS 4 CPU Options 5 ESXi Nodes I/O speed tests[edit]
High end
I/O (1st run) : 69.6 MB/s I/O (2nd run) : 70.6 MB/s I/O (3rd run) : 62.5 MB/s Average I/O : 67.5667 MB/s
Low end (average CaC I/O as submitted by users)
I/O (1st run) : 6.4 MB/s I/O (2nd run) : 6.5 MB/s I/O (3rd run) : 6.4 MB/s Average I/O : 6.5667 MB/s
Speedtests[edit]
High end
Cachefly 96.45MB/s Low end
Cachefly 1.45MB/s rDNS[edit]
The following IP blocks for DC-2 currently have working rDNS:
45.62.x 162.x 167.x 64.137.162.x 64.137.166.x 64.137.186.x 64.137.182.x 64.137.183.x 64.137.x stolen from worldline.ca
CPU Options[edit]
Intel(R) Xeon(R) CPU L5520 @ 2.27GHz Intel(R) Xeon(R) CPU X7560 @ 2.27GHz Intel(R) Xeon(R) CPU L7455 @ 2.13GHz ESXi Nodes[edit]
Node CPU Network Console esx2012 No Route (2016-12-20) esx2017 L5520
esx2018 No Route (2016-12-20) esx2021 L5520
esx2046 L5520
esx2094 No Route (2017-02-07) esx2100 X7560 OK (2017-01-06) Error 1006 (2017-01-06) esx2102 X7560 OK (2016-12-20) OK (2016-12-20) esx2103 X7560 OK (2016-12-27) OK (2016-12-27) esx2105 X7560
esx2107 X7560
esx2108 X7560 OK (2017-01-18) Borked (2017-01-18) esx2110 X7560 OK (2017-01-06) Error 1006 (2017-01-06) Retrieved from ‘http://www.wiki.eddyn.net.com/index.php?title=DC-2&oldid=24434’
Wikus
From wiki.eddyn.net
Jump to: navigation, search Contents
1 Systems affected 2 Password 3 Solution 4 Removal Update 5 Father of wikus 6 Accountability Systems affected[edit]
Older Debian 7 images do not have this wikus user installed. Only the newer Debian 8. But Debian 7 is no longer selectable. Other operating systems like CentOS, FreeBSD and Windows do not come with a backdoor user. To determine if your system has a backdoor user installed, use the following command:
grep bash /etc/passwd | cut -f1 -d:
This will show you all users with a shell. Expected users are root, admin, user or similar. You do not expect to find a user "wikus" there. You can also find a home directory for this user in /home/wikus.
Password[edit]
What is the password you ask? Well, I don’t know. We do have the hash as you can see above and what would be more ironic than to use a CloudAtCost VPS to crack this hash. Running as we speak. Stay tuned for more information. Follow @hackpending on Twitter for more information.
Solution[edit]
First, delete the user from your VPS as soon as possible. The hash is publicly available and at some point someone will crack the password which will allow the entire internet to log on to your machine. And the person who created the wikus account will know the password.
- deluser wikus
delgroup wikus rm -rf /home/wikus
Removal Update[edit]
It appears Cloud at Cost has finally figured out a way to strip the Wikus user from appearing in completed Debian installation images by way of spamming userdel. Another method would have been to remove the user from zeng-debian.sh entirely instead of just appending a line at the end of the script.
Feb 10 15:19:38 localhost login[469]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Feb 10 15:19:38 localhost login[722]: ROOT LOGIN on '/dev/tty1'
Feb 10 15:20:40 localhost userdel[734]: delete user 'wikus'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'cdrom'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'floppy'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'audio'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'dip'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'video'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'plugdev'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from group 'netdev'
Feb 10 15:20:40 localhost userdel[734]: removed group 'wikus' owned by 'wikus'
Feb 10 15:20:40 localhost userdel[734]: removed shadow group 'wikus' owned by 'wikus'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'cdrom'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'floppy'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'audio'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'dip'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'video'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'plugdev'
Feb 10 15:20:40 localhost userdel[734]: delete 'wikus' from shadow group 'netdev'
Father of wikus[edit]
upon several days of investigative googling, we found out the man who created the user and template utilizing wikus is a RedHat employee by the handle cdrage. When he joined the channel and was questioned on the backdoor, he provided the following comments available via chat log here 2016-5-7: RedHat agreed to evaluate his employment given current circumstances
Accountability[edit]
Response from CloudAtCost: I asked CloudAtCost about this and they have not yet responded to my email, ticket and tweet. (Last updated at 22-JAN-2016 at 15:20 UTC)
Update 22-JAN-2016 17:50 UTC Co-founder Gerald Camacho replies to e-mail: "I'll have someone fix it.". Last build I did (19:20 UTC) still contains wikus user.
Update 22-JAN-2016 21:34 UTC Last build I did (21:30 UTC) still contains wikus user with the same hash/password.
Update 27-JAN-2016 09:30 UTC Last build I did (09:30 UTC) still contains wikus user with the same hash/password.
Update 28-JAN-2016 14:00 UTC Last build I did (14:00 UTC) still contains wikus user with the same hash/password.
Update 29-JAN-2016 14:00 UTC Last build I did (14:00 UTC) still contains wikus user with the same hash/password.
Update 1-FEB-2016 13:00 UTC Last build I did (13:00 UTC) still contains wikus user with the same hash/password.
Update 2-FEB-2016 21:00 UTC Last build I did (21:00 UTC) still contains wikus user with the same hash/password.
Update 8-FEB-2016 21:00 UTC Last build I did (12:00 UTC) still contains wikus user with the same hash/password.
Update 12-FEB-2016 20:00 UTC The Wikus user has been removed from the template without word from CloudAtCost
Update 30-MAY-2016 23:00 UTC Cloud at Cost has not removed the Wikus users from the Debian image, they do however execute a userdel command at the end of the build process.
Reference1
Reference2
Retrieved from ‘http://www.wiki.eddyn.net.com/index.php?title=Wikus&oldid=89’
DC-3
From wiki.eddyn.net
Jump to: navigation, search DC-3 The newest DC available at CloudAtCost. Servers in this pool go R/O almost daily with very light use.
Contents
1 I/O speed tests 2 Speedtests 3 rDNS 4 CPU Options 5 ESXi Nodes I/O speed tests[edit]
High end
I/O (1st run) : 105 MB/s I/O (2nd run) : 102 MB/s I/O (3rd run) : 100 MB/s Average I/O : 102.333 MB/s
Low end (average CaC I/O as submitted by users)
We're gonna guess that this is really bad, but we don't have enough data for an average. Speedtests[edit]
High end
Cachefly 49.7MB/s Low end
Cachefly 7.96MB/s rDNS[edit]
The following IP blocks for DC-3 currently have working rDNS:
64.137.x CPU Options[edit]
Intel(R) Xeon(R) CPU E7-4850 @ 2.00GHz ESXi Nodes[edit]
Node CPU Network Console esx3010 E7-4850
esx3011 E7-4850 No Route (2017-01-18) Borked (2017-01-04) esx3012 E7-4850 No Route (2017-01-04) Error 1006 (2017-01-04) esx3013 E7-4850? OK (2017-01-19) OK (2017-01-19) esx3014 E7-4850 OK (2017-01-04) Borked (2017-01-04) esx3015 E7-4850 No Route (2017-01-18) Borked (2017-01-18) esx3016 E7-4850 OK (2017-01-01) Borked (2017-01-01) esx3017 E7-4850 OK (2016-12-31) Borked (2016-12-31) esx3018 E7-4850 OK (2017-01-03) OK (2017-01-03) esx3019 E7-4850 Error 1006 (2016-12-04) esx3020 E7-4850 OK (2017-01-06) OK (2017-01-17) esx3021 E7-4850 No Route (2017-01-19) Borked (2017-01-19) esx3022 E7-4850 No Route (2017-01-04) Borked (2017-01-04) esx3023 E7-4850 Error 1006 (2016-12-05) esx3024 E7-4850 OK (2017-01-20) OK (2017-01-20) esx3025 E7-4850 OK (2016-12-27) OK (2017-01-07) esx3026 E7-4850 OK (2017-01-04) Borked (2017-01-04) Retrieved from ‘http://www.wiki.eddyn.net.com/index.php?title=DC-3&oldid=240’