21–30 of 160 posts
So far I'm 3 for 3 on stopped/started machines that come back no longer having the scheduled reboot event - maybe the problem isn't as annoying as we're thinking? (Edited because I said "reboot" and meant "stop/start")
I love how the amazon support person is absolutely not answering the very precise question.
Heh, I thought the answer was very clear: no.
Earlier quoted context omitted.
It's not the results of the script that I'm referring to, it's the contents of the script. If I hand you code that can look at your system and determine something about it, you can look at what the code is doing and identify what it is looking at, which tells you where the vulnerability is. It becomes moderately harder if it's compiled code, but still not very difficult.
So make the code query an opaque EC2 api, instead of testing the machine. You could still find a machine that is vulnerable and one that isn't and attempt to find out what the difference is, but that's a much harder task.
That said, if they were just checking software version or querying an Amazon API endpoint, I'd expect them to give out a tool or URL you could use that would give you the state for all your systems at once, rather than a script that you'd run on the machine itself.
So far I'm 3 for 3 on stopped/started machines that come back no longer having the scheduled reboot event - maybe the problem isn't as annoying as we're thinking? (Edited because I said "reboot" and meant "stop/start")
So far I'm 3 for 3 on stopped/started machines that come back no longer having the scheduled reboot event - maybe the problem isn't as annoying as we're thinking? (Edited because I said "reboot" and meant "stop/start")
A reboot won't address it at all (it also keeps you on the same host).. no point in doing that. From the e-mail notification: "You will not be able to stop/start or re-launch instances in order to avoid this maintenance update."
> While executing a stop/start is absolutely fine to do, there is not a guarantee that you will land on an updated host. We are periodically polling for new instances and those impacted will receive new maintenance notifications accordingly.
Which I take to mean there's a chance you could land on an updated host. I'll update if any of those machines come back to the Events view.
Anecdata, but a possible explanation.
Earlier quoted context omitted.
A reboot won't address it at all (it also keeps you on the same host).. no point in doing that. From the e-mail notification: "You will not be able to stop/start or re-launch instances in order to avoid this maintenance update."
Sorry, I should have phrased better. I issued a "stop and start". Per the AWS thread: > While executing a stop/start is absolutely fine to do, there is not a guarantee that you will land on an updated host. We are periodically polling for new instances and those impacted will receive new maintenance notifications accordingly. Which I take to mean there's a chance you could land on an updated host. I'll update if any…
I would have expected Amazon to rush out a tool you can use to check or add a little marker to the dashboard or a simple API to query. Some sort of synchronous option.
Having to wait possibly hours for an email to see if your vm migrated to patched host or not is a terrible solution.