![]() ![]() The User Data settings permits you to run a shell script on the launch of an EC2 instance. I went with the middle road and used “User Data” in my playbook. Creating an Ansible playbook requires more development time but can be reconfigured more easily. Put another way, it’s easier to port our solution to another provider the lower we are in the list.įor most businesses, I would figure vendor lock-in isn’t a big deal, since the development costs of being cloud-agnostic can be pretty high.Ĭreating my server and saving an AMI from it would be the fastest and have the lowest development cost - I can run commands till I get what I want. In the choices above, the lock-in to AWS decreases with each option. With cloud configuration, part of the decision process is how much vendor lock-in there will be. Attempt to streamline my typical bootstrap + software installation to make it a little less clunky.Use the “User Data” setting to run some commands while the server is being provisioned by Amazon.I don’t think this has as much flexibility as running Ansible and being able to change a config on the fly. Create the server how I want it, then turn it into an AWS AMI (Amazon Machine Image).Typically, I run a bootstrapping role to add a new user that can sudo, but I wanted to see if I could do a little more automating. By setting up passwordless sudo on the instance, I can use become and install my software as a sudo user. The catch is that to use become: yes in an Ansible playbook seems to require a password. The Ubuntu 22.04 distro provided by Amazon has a user “ubuntu” that can sudo su without a password. I wanted to bootstrap a server on an AWS EC2 instance in a fairly secure way, giving passwordless sudo to a user so that I could install software with Ansible. I think my enthusiasm for wanting to experiment with User Data made things a little tougher here, but I learned a few things. I found a much better, easier way to do this with Ansible. ![]() I assume sensu runs checks as its own user account.Passwordless Sudo on a Remote AWS Server on Setup May 1, 2023 It seems like this is a common use-case, so there must be something I am missing. Thanks Joe - I’ll be sure to add the “requiretty” part. You may use a /etc/sudoers.d/ file for granular* control. The Sensu user will need passwordless sudo. Thanks Sean! Is the way I am using sudo in the check the recommended sensu way? Or is there a way to tell sensu it should sudo to run a check? I assume by default it just runs as the normal user? On Thu, at 3:30 PM, Christopher Armstrong wrote: Sensu ALL = NOPASSWD: /etc/sensu/plugins/check-ping-private-gateway.rb So, how do we have it run checks as root or as another user?ĭefaults:sensu secure_path = /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin I assume sensu runs checks as its own user account. sudo: no tty present and no askpass program specified Sorry, try again. Sudo: no tty present and no askpass program specified Sorry, try again. So, in the check body, I am doing /usr/bin/sudo -u postgres /path/to/our/sql/check. I am trying to have sensu run checks as another user. On Thu, at 3:23 PM, Christopher Armstrong wrote: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |