error

Ansible: resolving error “Invalid callback for stdout specified: yaml”

If you are getting the following error when invoking an Ansible playbook or any of the Ansible related utilities: ERROR! Invalid callback for stdout specified: yaml This means Ansible is attempting to use the new YAML callback plugin, but cannot find the Ansible Galaxy community.general module.  This module is installed by the ‘ansible’ pip module, Ansible: resolving error “Invalid callback for stdout specified: yaml”

Ansible: resolving ‘could not initialize the preferred locale: unsupported locale setting’

If you are getting the following error when invoking ‘ansible’, ‘ansible-playbook’, ‘ansible-galaxy’ or any of the Ansible related utilities: ERROR: Ansible could not initialize the preferred locale: unsupported locale setting This means Ansible cannot find a locale ending in “.UTF-8”.  Check the currently installed locales: $ locale -a Then export the LC_ALL variable to one Ansible: resolving ‘could not initialize the preferred locale: unsupported locale setting’

Terraform: fixing error “querying Cloud Storage failed: storage: bucket doesn’t exist”

If you are attempting to run “terraform init” with a Google Cloud Storage backend and get the following error: Error: Failed to get existing workspaces: querying Cloud Storage failed: storage: bucket doesn’t exist The first check should be that the Google Cloud Storage bucket indeed exists, using gsutil. project_id=myproject-123 gsutil ls -p $project_id If the Terraform: fixing error “querying Cloud Storage failed: storage: bucket doesn’t exist”

Ubuntu: ‘Connection to the Snap Store failed’ during upgrade from Ubuntu 20 to 22

If you are upgrading from Ubuntu 20 to Ubuntu 22 using ‘do-release-upgrade’ and get a fatal error ‘Connection to the the Snap Store failed’, this may be resolved by removing the ‘lxd’ package which is a lightweight container supervisor. sudo /etc/init.d/lxd stop sudo rm -fr /var/lib/lxd sudo dpkg –force depends -P lxd; sudo dpkg –force Ubuntu: ‘Connection to the Snap Store failed’ during upgrade from Ubuntu 20 to 22

Kubernetes: ingress-nginx-controller-admission error, x509 certificate signed by unknown authority

If you delete the entire nginx namespace and reinstall again via helm chart, your nginx admission controller may throw a “x509 certificate signed by unknown authority” message when you attempt to create an nginx ingress. This will happen regardless if the ingress is using http only or secure https.  And also whether or not the Kubernetes: ingress-nginx-controller-admission error, x509 certificate signed by unknown authority

Terraform: converting ordered lists to sets to avoid errors with for_each

If you are using a Terraform “for_each” and get the error message below, it is most likely because you are sending an ordered list instead of an unordered set (which is not supported at the resource level). The given “for_each” argument value is unsuitable: the “for_each” argument must be a map, or set of strings, Terraform: converting ordered lists to sets to avoid errors with for_each

KVM: running qemu-img info without exclusive access using force-share flag

By default, ‘qemu-image info’ will throw an error if it cannot get exclusive access to the disk file it is trying to read. $ sudo qemu-img info mydisk.qcow2 qemu-img: Could not open ‘mydisk.qcow2’: Failed to get shared “write” lock Is another process using the image [mydisk.qcow2]? Although it is not listed in the man page, KVM: running qemu-img info without exclusive access using force-share flag

AppDynamics: Enabling verbose debug logs for Agents

Enabling verbose logs for an AppDynamics machine or database agents can be invaluable for troubleshooting connectivity or network issues. Luckily, this is easily done by editing the conf/logging/log4j.xml file.  By default, only the error level messages are sent to the logs: <root> <priority value=”error”/> <appender-ref ref=”FileAppender”/> </root> But you can modify this so that debug AppDynamics: Enabling verbose debug logs for Agents