Sysadmins should concentrate on managing and securing the devices and not the network. This is advantageous with todays mobile workforce where users expect the same experience at the office, coffee shop or home.
actually I'd find running my ansible playbook much, much easier than transferring GB of disk image about. I maintain the playbook so that I can keep work laptop and personal laptop in sync. Although I am looking at Nixos as a possible replacement.
It's double jeopardy, there is a case for a fresh vote because new facts (May's deal/No Deal) are present. If there are new facts after this vote (for example a new A50 or similar) then there is the case for another one.
As an example, if we look at https://github.com/GoogleCloudPlatform/container-vm-guestboo... then there are a couple of things here that are IPv4 only. The first is that the application is only configured to listen on the IPv4 address family, app.run(host='0.0.0.0', port=80), on linux if that was changed to app.run(host='::', port=80) this the application would be able to receive both IPv4 and IPv6 requests (on windows the situation is different however)
The second, and less important change, is that the redis connection is using 127.0.0.1, and if instead it was using "localhost" then that would resolve to the correct address family. This is less important as it is only relevant if there is no IPv4 on the server host, the first change would allow your app to accept IPv6 traffic.
Neither of these changes are required if there is a dual stack proxy or CDN that sits infront of your application, as they will most likely talk to your application over IPv4.
The other gotcha is if you try to interrogate clientIP for analytics, authorization, geo-ip etc, which may need a little more care.
It is slightly less secure than that as the password reset form has a notification mechanism built into it in that the next time you login you realise that you need to reset the password back to what you control, where the magic link does not have such a mechanism to let you know that a compromise has taken place. It is slight, and requires you to be paying attention.
It hasn't prevented a false alarm, which is why it hit the news... it's interesting that there is a lot of hang up on false negative (false alarm) and very little discussion about a false positive (hitting the test button instead of the real alarm)
I'm not scolding the ape, I'm scolding the organ grinder. When a drill deviates from the actions taken in an emergency it becomes a pantomime of little value.
I totally agree that the solution should leverage obviation to prevent human error in an emergency, that's what a drill is all about.
The point of a drill is to drill the procedure into people, so that when it is required the people are operating on autopilot without the need to actively think about the actions that they are performing.
I would prefer to see the only two tapes next to the transmitter are the emergency tapes. If there is a drill then the drill setup will replace these tapes with the test tapes, and maybe place a corrupt tape there once in a while.
With this fix, in an emergency situation it's suddenly someone has to remember to get the tape out of the cabinet (was it Alice's or Bob's cabinet that we put them in?) and use that rather than follow the process that has been rehearsed.
This whole scenario whiffs of improper drill setup, not a failure of following the drill.
We're currently looking at moving our applications to k8s, and was wondering what deployment tools people are using? This week we are evaluating spinnaker, helm and bash wrappers for kubectl. There is concern over adding too many layers of abstraction and that KISS is the best approach.
So, carry on with keeping bad actors off the network and ensuring that there is sufficient capacity and resilience in the network.