I pass a custom startup script when I instantiate a VM. This startup script can take a while to finish and I want to be able to block (or at least poll) on the host and wait for the VM to get to the end of the startup script before proceeding to next steps.
The official documents recommends using guest attributes for this exact purpose but as far as I can see you can only instantiate them from inside VM. This is fine but ideally I'd like to be able to read a ready=FALSE value from the beginning and then see it changing to TRUE instead of starting with "ready doesnt't exist" error.
Is it possible to provide an initial value for guest attributes when starting a VM?
For normal metadata there's a ?wait_for_change=true that allows a VM to block and react to changes made to the VM from the outside but I'm looking for the opposite.
We use cloud-init in the startup-script to configure some instances. Cloud-init modules run at multiple stages of the boot process, some very early such as bootcmd.
Perhaps you could put a curl command in the bootcmd module to set the desired guest attributes in the metadata?
Related
Problem: I want to apply patch updates in a VM instance which is not a part of a Managed Instance Group. The patch update could be-
A change in the version of the current OS of a VM instance, that is, change from Ubuntu-16-v1 to Ubuntu-16-v2.
An upgrade of the OS boot, that is, changing from Ubuntu-16 OS to Ubuntu-18 OS.
Installation of a new package in the existing machine.
Exploration:
For Problem 1 & 2 stated above
I have explored and tried the rolling update feature present in Managed Instance Group in the Google Cloud Platform and this seems to be a good approach for the problem stated, but what should be the best approach with best practices if someone is not using a Managed Instance Group? You may find the details here.
For Problem 3 stated above
I have tried the Os-patch Management service of GCP but is there any other method that I could use?
Create an "image" from the boot disks of your existing Compute Engine instances.
For updating with newer configurations and software, group images in "image family" which always points to the latest image.
See https://cloud.google.com/compute/docs/images/create-delete-deprecate-private-images#setting_families
For your use case, I think you should use IAC script like terraform to recreate similar VMs with the same name, disk, internal address, etc..and call the script from the repo directly on a scheduled date automatically or provide self patch instructions.
Here is the likely process:
Send Email Notification to all the VM owners that Auto-Patch is
scheduled on XYZ.
Email content should include an Instance list going to be
patched/update, list of action, patch team contact details.
An email should also include a link for skipping this auto-update and perform "Self Patching instruction"
documents
Self patching documents should have a command to call autopatch
wrapper script like: "curl -u "encrypted-auth:x-oauth-basic" -k -H 'Accept:
application/vnd.github.VERSION.raw'
'https://github.com/api/v3/repos/xyz/images/contents/gcp/patch_OS_update.sh?ref=master'
|bash -s -- -q"
The above script can also have other options like to query patchset available for particular VM or scan the VM for pending updates
I accidentally messed up the permissions of the file system, which shows the message sudo: /usr/local/bin/sudo must be owned by uid 0 and have the setuid bit set when attempting to use sudo, such as read protected files, etc.
Response from this answer (https://askubuntu.com/a/471503) suggest to login as root to do so, however I didn't setup a root password before and this answer (https://stackoverflow.com/a/35017164/4343317) suggest me to use sudo passwd. Obviously I am stuck in an infinite loop from the two answers above.
How can I read/get the files from Google Cloud Compute Engine's disk without logging in into the VM (I have full control of the VM instance and the disk as well)? Is there another "higher" way to login as root (such as from gcloud tool or the Google Cloud interface) to access the VM disk externally?
Thanks.
It looks like the following recipe may be of value:
https://cloud.google.com/compute/docs/disks/detach-reattach-boot-disk
What this article says is that you can shutdown your VM, detach its boot disk and then attach it as a data disk to a second VM. In that second VM you will have the ability to make changes. However, if you don't know what changes you need to make to restore the system to sanity, then as #John Hanley says, we might want to use this mounting technique to copy of your work and then destroy your tainted VM and recreate a new one fresh and copy back in your work and start from there.
I accidentaly enabled the UFW on my Google Cloud Compute debian instance and unfortunately port 22 is blocked now. I've tried every way to go inside the VM but i can't...
I'm trying to access trhougth the serial port but it's asking me for user and password that was never set.
Does anyone have any idea what can I do?
If I could 'edit' the files on disk, it would be possible to change firewall rules and disable it. Already thought on mounting the VM disk on another instance but Google doesn't allow to "hot detach" it.
Also tried to create another VM from a snapshot of VM disk, but of course, the new instance came with the same problem.
Lots of important files inside and can't go in...
This is the classical example when you close yourself outside of the house with the key inside.
There are several ways to get back inside a virtual machine when the ssh is not currently working in Google Cloud Platform, from my point of view the easiest is to make use of the startup script.
You can use them to run a script as Root when your machine starts, in this way you can basically change the configuration without accessing the virtual machine.
Therefore you can:
simply launch some command in order to deactivate UFW and then access again the machine
if it is not enough and you rally need to access to fix the configuration, you can set up username and password for the root user making use of the startup script and then accessing through the serial console therefore without ssh (basically it is like you had your keyboard directly connected to the hardware). Note as soon you access the instance remove or at least change the password you have just used was visible to the people having access to the project. A safer way is to write down the password in on a private file on a bucket and download it on the instance with the startup script.
Note that you can redirect the output of command to a file and then upload the file to a bucket if you need to debug the script, read the content of a file, understanding what is going on, etc.
The easiest way is to create a startup-script that disables ufw. which gets executed whenever the instance is booted:
Go into your Google Cloud Console. Go to your VM instance and click Edit button.
Scroll down to your "Custom metadata", and add a "startup-script" as key and the following script as value:
#! /bin/bash
/usr/sbin/ufw disable
Click save and reboot your instance.
Delete that startup-script and click Save, so that it won't get executed in future boots.
You can try google serial ports. From then you can enable the ssh
https://cloud.google.com/compute/docs/instances/interacting-with-serial-console
ufw allow ssh
I have a AWS EC2 Windows (2008 R2 instance) which I want to start-stop using command/script from my local machine and schedule as per my usage.
I also want couple of my programs running on the EC2 instance to get start when instance starts. These programs currently are started using a bat file present in the instance.
I did following till now for the same:
1- I have an AWS user created in AWS IAM and using auth_id and key for that user for using EC2 apis and command line utilities.
2- To start and stop instance I'm using command line utilities from EC2 Util.
start ->ec2-start-instances i-instanceID
stop ->ec2-stop-instances i-instanceID
3- To schedule it I've added this to my windows scheduler.
4- Added user data for the instance in the AWS management console. My user data looks like this:
<script>
C:\Services\my_application.lnk
</script>
5- I can see the user data is present in my EC2 instance at C:\ProgramFiles\Amazon\Ec2ConfigServer\Scripts\UserScript
6- In C:\Program Files\Amazon\Ec2ConfigService\Settings\confi.xml the values of Ec2SetPassword and Ec2HandleUserData were changed to enabled and added true was added as well.
I'm facing following issues:
1- The user data scripts does not execute every time the instance is started. I'm not able to figure out why.
2- The changes made in Ec2ConfigService\Settings\confi.xml are getting reverted to the default values when the instance is restarted.
I feel this is common use case, and would like to know the best practices and approach taken for automating EC2 operations.
I also need help in starting programs on my instance- where am I going wrong or missing, what else needs to be done etc?
userdata is only executed the very first time that the instance is created. This is by design.
You've got a couple of options - all of which use your userdata script
Copy the my_application.lnk to the startup folder
Register the application in the registry "run" start key (http://blogs.msdn.com/b/powershell/archive/2006/04/25/how-to-access-or-modify-startup-items-in-the-window-registry.aspx)
Register it with the task scheduler to configure it to execute on startup (http://technet.microsoft.com/en-us/library/bb490996.aspx)
i have virtual machines running on vmware ESXi and vmware workstation.
i need to execute "revert to snapshot" from inside the guest.
i have done so much searching, but all solutions proposed so far suggest doing it from "outside" - either some external machine or the host itself.
other workarounds suggest to enable automatic reverting to snapshot on power off event.
please do not suggest anything in that direction. i really need to execute it from within the guest. for example:
as scheduled task
as batch script (at the end of completing some other tasks)
edit:
this is the reason why i think there must be some way to achieve this: inside the guest there are "vmare tools" running as system service. so i would expect this component to also expose a functionality to trigger the host / hypervisor reverting the current VM to snapshot.
if this is not possible currently it should be implemented as new feature :)
in case it's currently not possible to execute it "from inside": that would also be an "answer" ...
I've actually done this pretty recently, try this:
Install VMware vSphere PowerCLI 5.1 (it's a command line scripting interface for ESX)
Write a script (perhaps in Notepad) that contains the following code:
Connect-VIServer <vCenter Server IP>
Set-VM <VM name> -Snapshot <Snapshot name> -Confirm:$false
This will connect to your vCenter server and revert your VM to the specified snapshot.
Save the script as revert_snapshot.ps1 (PowerShell file extension)
Using Windows Task Schedule, create a new tasks. The General and Triggers tabs are self
explanatory, but the Actions tab is where you'll configure the scheduled tasks to launch
your PowerShell script.
For 'Action' select 'Start a Program'. Under 'Program/script', enter the following:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
For the 'Add arguments' field, you'll specify the path of your PowerShell script:
-psc "C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1" "<path to your script>"
note: vim.psc1 is not available in the latest version of PowerCLI.
Save your task and run it manually as a test. Be patient as sometimes the cmdlet for logging into vCenter (Connect-VIServer) can take a few seconds to connect.