Terraform claims that my EC2 instance needs to be rebuilt due to changes in the ebs_block_device even though we haven't made any changes to the block device definition. Note the
ebs_block_device lines that claim 'forces new resource':
aws_instance.infosec-gatekeeper (new resource required) id: "i-01234567890123456" => <computed> (forces new resource) ami: "ami-0123456789abcdef0" => "ami-0123456789abcdef0" arn: "arn:aws:ec2:us-east-1:098765432109:instance/i-01234567890123456" => <computed> associate_public_ip_address: "false" => <computed> availability_zone: "us-east-1e => <computed> cpu_core_count: "1" => <computed> cpu_threads_per_core: "2" => <computed> ebs_block_device.#: "0" => "1" ebs_block_device.1357911171.delete_on_termination: "" => "true" (forces new resource) ebs_block_device.1357911171.device_name: "" => "/dev/xvda" (forces new resource) ebs_block_device.1357911171.encrypted: "" => <computed> (forces new resource) ebs_block_device.1357911171.iops: "" => "" ebs_block_device.1357911171.kms_key_id: "" => <computed> (forces new resource) ebs_block_device.1357911171.snapshot_id: "" => <computed> (forces new resource) ebs_block_device.1357911171.volume_id: "" => <computed> ebs_block_device.1357911171.volume_size: "" => "16" (forces new resource) ebs_block_device.1357911171.volume_type: "" => "gp2" (forces new resource)
This was in an environment with:
- terraform 0.11.14.7
- aws provider 2.56.0
My 'new' travel laptop had an issue with battery life and the issue was traced to power consumption of the Nvidia graphics card. Since I'm not gaming or doing graphics intensive work it makes more sense to stick to the 'integrated' Intel graphics to gain runtime. This is how to change the graphics mode in Ubuntu 20.04.
I have a Razer Blade Pro 17 inch laptop and found a behavior that bugged me with no clear way to turn it off: Display auto-dimming. The laptop screen would get dimmer when I switched between applications and darkened to an unacceptable degree when loading VMWare Workstation (full screen). Others have had similar issues with their Razer laptops and had mixed results in finding a resolution.
I've been a die hard Pebble Smartwatch fan for years now. Since they were acquired a few years back the
Pebble App has vanished from the Google App Store and I now need to extract the APK from my old Android device so I can install it on my new one.
The procedure is fairly straight-forward.
While performing an SMB share permissions review we discovered some fileshares with numeric permissions like
268435456 that did not translate to a Human-readable permission set (such as
ReadAndExecute). We wanted to better understand the numeric permissions.
I noticed something odd today while using a new laptop with Ubuntu 20.04 installed: A network printer was automatically detected and installed without any intervention on my part. The laptop was connected to a WiFi network where the screen was locked for a few minutes. When I came back I found a notification waiting for me on the login screen about a new printer. The notification disappeared after I entered my unlock password or I'd have included an image here.
In recent weeks I spent some time working on security analysis of Docker container images in an environment that used multiple container registries. The goal of the project was to ensure that application images are built against known-good / certified base images. There was an unforseen factor that complicated this work- the organizationally approved base images reside in an old Quay Enterprise 2.9.x server that does not support the latest Docker registry API (Image Manifest Version 2, Schema 2) which prohibited a simple check of image layer hashes as the hashes are calculated differently and don't match up.
To get around this I crafted a solution that calculates the 'new' hash for each layer of approved base images and used the calculated layers to compare against application images. If you want to jump to the code, see this repo: InferDockerRegistryHash. For more details, read on below
While attempting to upgrade a dockerized instance of giblab-ce I found a number of error messages like this that caused the upgrade to fail and a rollback to the previous version to fail:
7/6/2020 11:07:37 AMRunning handlers: 7/6/2020 11:07:37 AMThere was an error running gitlab-ctl reconfigure: 7/6/2020 11:07:37 AM 7/6/2020 11:07:37 AMrunit_service[redis] (redis::enable line 66) had an error: Errno::ENOENT: template[/var/log/gitlab/redis/config] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/runit/libraries/provider_runit_service.rb line 136) had an error: Errno::ENOENT: No such file or directory @ realpath_rec - /opt/gitlab/sv/redis/log/config
It's time to refresh one of my Minikube installations- I'd like to play around with Cilium some more and Minikube is the most direct route to a functioning test cluster. The last time I set up a Minikube/Cilium was back in 2018 and I hope the installation is more streamlined now.
My purpose in this is to minimize what is installed to my host workstation. I prefer a greater degree of isolation between my host and experiments.
While upgrading my home network's Unifi server installation I found that the upgrade hung for an abnormally long time and after it 'finished' the web console would not load. Investigating further it appears that somehow the port configuration for Mongo changed in this (or a prior?) version of the Unifi software which lead to it not being able to communicate with the Mongo Server. When addressing this configuration issue I found I had a disk space issue to contend with, so it's been a 'fun' morning.