He intentado añadir un comentario al artículo How to Connect to EC2 with SSM (Session Manager)? pero no ha habido manera…
El autor indica que es necesario configurar la instancia para aceptar tráfico de entrada HTTPS 443 desde cualquier origen…
Ops
Photo by Mabel Amber
Reducir el tamaño del disco en VirtualBox
- post
- Xavi Aznar
Los discos dinámicos en VirtualBox crecen automáticamente a medida que aumentan los datos que se guardan… Sin embargo, el tamaño no decrece aunque borremos ficheros. Esto significa que aunque el fichero del disco de una máquina virtual ocupe, en el sistema anfitrión, 50GB, por ejemplo, gran parte de esos 50GB pueden estar vacíos…
En esta entrada indico los pasos a seguir para reducir el tamaño del fichero del disco, eliminando todo ese espacio desaprovechado.
Tras solucionar los problemas con Vagrant al actualizar a PoP_OS! 22.04 (basada en Ubuntu 22.04), encuentro otro problema relacionado también con SSH :(
k3sup, el instalador de clústers de Kubernetes usando k3s, no puede conectar con las máquinas virtuales basadas en la imagen ubuntu/jammy64 (la nueva versión de Ubuntu 22.04).
La solución para el Error en Vagrant tras actualizar a Pop_Os! 22.04 es la instalación de una versión concreta del software, en este caso, la 2.2.19.
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…
Cockpit: Cannot refresh cache whilst offline
- post
- Xavi Aznar
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 formagcr.io/cloud-builders/gcloudy 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).
Las variables de entorno se definen para cada usuario; por tanto, para mi usuario
xavi, puedo configurar la variablehttps_proxymediante: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.