@Pete-S said in ssh to new cloud instance?:

@scottalanmiller said in ssh to new cloud instance?:

@Pete-S said in ssh to new cloud instance?:

If you add another admin in the cloud control panel, is an account for that user created on all cloud instances that person can access?

In Vultr, there aren't users in the cloud panel at all. There are keys that you can choose to deploy at deploy time for root. Other than that, if we wanted to deploy keys (as an example), we'd do that through our management system (script, Salt, Ansible, etc.). I would not want the cloud platform to be touching my users.

OK, got it.

Does that also mean that only one person can have access to the actual Vultr account as well? I'm guessing it's multi-user.

Yeah, the cloud level is multi-user. But just as you can have multiple people with access to a data closet, and multiple people with access to a Windows instance housed in that closet, you don't want the physical closet to maintain the Windows logins. Same here, your cloud provider is like a data center or data closet with its own level of access unrelated to applications or other workloads running higher up the stack and 99.999% of the time, no association or commonality between them.

@skyetel said in Did you notice the Skyetel outage today?:

I put this on another forum, but I figured you guys would like to read this too:

For those interested, Our network operates in 4 AWS regions that we keep siloed from one another (meaning no region knows about the existence of another one). When the connectivity issues started, we disabled the network connectivity for all Skyetel assets in the two impacted AWS regions which caused our network to fully failover. (Because the impacted regions had partial connectivity, our network did not fully fail over and tried to limp along with all 4. This is by design; we don't want to automate disabling network routers of our network for obvious reasons... so an engineer needed to click the buttons).

The impact of this was some calls failed to establish, but if they did establish, they would work normally. This is because we are not in the audiopath of the calls. Once the distressed regions were fully down, our network could fully fail over and 100% of all calls completed normally.

The total impact time was 19 minutes, and we estimate about 7% of our calls failed to establish during that period. Sorry for the inconvenience 🙂

Did I mention @Skyetel is awesome lately? Being fixed almost before the customers noticed was insanely awesome.

Thanks for adding more technical content!

Yeah I got an announcement in my email about it. I was reading about it here:

https://aws.amazon.com/about-aws/whats-new/2019/12/announcing-new-amazon-ec2-m6g-c6g-and-r6g-instances-powered-by-next-generation-arm-based-aws-graviton2-processors

@Alex-Jones said in How to increase EBS volume size on AWS:

Thanks!

My pleasure! That can come in handy when dealing with the Clintons or reptilian aliens.