Photo by Mabel Amber
TL,DR; Solución en Vagrant up error on Ubuntu 22.04: pkeys are immutable on OpenSSL 3.0
Ayer actualicé a la nueva versión de PoP_OS!, basada en Ubuntu 22.04 LTS. Todo funcionó de maravilla, como debe ser. El único problema -por llamarlo de algún modo- identificado tras la actualización ha sido la pérdida de la configuración de Cool Retro Term; no big deal…
Hoy he instalado Cockpit y después de configurar una IP estática para el servidor que uso de laboratorio, la sección Software Updates ha dejado de funcionar, mostrando el mensaje de error Cannot refresh cache whilst offline.
La solución la he encontrado en Cockpit – “cannot refresh cache whilst offline”.
El título tiene una sonoridad un poco a click bait, así que explicaré rápidamente a qué me refiero.
Hace poco que hemos empezado a colaborar en un proyecto nuevo. Mientras nos vamos poniendo al día estoy ayudando a uno de mis compañeros -un crack en networking- con temas relacionados con contenedores, con los que está menos familiarizado.
Revisando los ficheros de configuración de Google Cloud Build, encontramos, en el mismo fichero, referencias a la imagen de un contenedor como hashicorp/terraform:latest, otras en las que el nombre es de la forma gcr.io/cloud-builders/gcloud y otras en las que es, simplemente, alpine.
Y claro, mi compañero no entiende nada…
Estaba leyendo las nuevas entradas en el foro de Kubernetes y me he encontrado con Getting Pod ID and container ID of a container when it restarts.
La pregunta es cómo obtener el identificador de un pod (y de un contenedor dentro del pod) cuando éste se reinicia. Lo curioso -al menos para mí- es que esa información es necesaria porque hay otro pod que monitoriza el primero que necesita esta información (supondo que para identificar el pod monitorizado).
Hoy en día es obligatorio usar un gestor de contraseñas. En mi caso, uso Bitwarden (la edición Personal).
Como cada vez paso más tiempo en la línea de comandos, he decido probar la versión CLI de Bitwarden.
Terraform almacena el estado de la configuración en un fichero. Este fichero es crítico para que Terraform pueda mantener la coherencia entre el estado definido en los ficheros de configuración y el estado real de la infraestructura desplegada.
Por defecto, Terraform almacena el estado de forma local; para facilitar la colaboración entre diferentes miembros de un equipo -entre otros casos de uso-, Terraform ofrece la posibilidad de usar otras ubicaciones para guardar el estado. Estas ubicaciones reciben el nombre de backends en Terraform (y hay unos cuantos disponibles, como puedes observar desplegando la entrada Available Backends en la web de Terraform).
Una opción habitual es la de usar un bucket en un servicio como S3 de AWS como remote backend. Pero si no tienes acceso a una cuenta de AWS, puedes usar MinIO para trabajar con un backend de tipo S3 de forma completamente offline (por ejemplo, para aprender cómo funciona Terraform ;-D )
He estado buscando información sobre cuál es la manera correcta a la hora de definir los nombres de las variables en Bash… Y como en el caso de la eterna batalla entre espacios vs tabs o Vim vs Emacs, parece que no hay una solución definitiva (o seguida por todo el mundo de forma generalizada).
Las variables de entorno se definen para cada usuario; por tanto, para mi usuario xavi, puedo configurar la variable https_proxy mediante:
En VSCode, cuando colocas el cursor sobre una palabra o para ser más exactos, sobre un “bloque de texto delimitado por espacios”, toda la palabra se destaca con un fondo de color más claro (en un tema oscuro).
El color del fondo es el mismo tanto si el todo el texto de la palabra está seleccionado como si simplemente el cursor está en alguna posición entre el principio y el final de la palbra, lo que no es lo mismo.
En esta entrada, indico cómo modificar el texto del resaltado que hace Visual Studio Code cuando seleccionamos una palabra o bloque de texto.
A raíz de la entrada anterior GitOps con ArgoCD - Instalación y acceso a la consola he visto que la versión desplegada en el clúster de laboratorio era la 2.2.1, mientras que la versión actual es la 2.2.5.
Antes de actualizar, al tratarse de una versión patch release, no es necesario tener en cuenta ninguna consideración especial, según se indica en la documentación oficial Upgrading > Overview.
Sin embargo, aplicando el fichero correspondiente a la última versión estable, se sobreescriben los ConfigMaps de configuración, por lo que las modificaciones realizadas se pierden; en mi caso, la configuración del modo inseguro necesario para el acceso a través de un ingress.
Como solución temporal, se puede aplicar de nuevo el fichero con el ConfigMap y ejecutar kubectl -n argocd rollout restart deploy argocd-server.
