Cockpit es un gestor al estilo YaST pero para web. Está disponible al menos también para sistemas basados en Rhel . En openSUSE están disponibles para Tumbleweed/MicroOS, y empiezan a estar disponibles en Leap aunque en una prueba que hice para Leap 15.5 en una VM no me va muy allá.
Viendo que en una instalación de Almalinux tengo más paquetes de Cockpit que en mi Tumbleweed, he efectuado una búsqueda y he visto que algunos están disponibles en el repositorio personal home:ecsos:server
La primera pregunta es la obligada: ¿esos paquetes formarán parte de la distribución algún día próximo?
La segunda pregunta es una extensión de la primera. Después del esfuerzo de sacar Agama de Cockpit, ¿cuál es el futuro de este sistema en openSUSE?
Hola, no necesitas que el servidor esté funcionando, solo necesitas el puente y puedes conectarte con el cliente flatpak cockpit (org.cockpit_project.CockpitClient)
Tengo varios servidores MicroOS en ejecución y luego puedo conectarme a través de ssh (incluida la máquina TW local).
zypper se -i cockpit
S | Name | Summary | Type
---+------------------------+------------------------------------------------------------------------------+--------
i | cockpit-bridge | Cockpit bridge server-side component | package
i+ | cockpit-machines | Cockpit user interface for virtual machines | package
i | cockpit-networkmanager | Cockpit user interface for networking, using NetworkManager | package
i+ | cockpit-pcp | Cockpit PCP integration | package
i | cockpit-storaged | Cockpit user interface for storage, using udisks | package
i | cockpit-system | Cockpit admin interface package for configuring and troubleshooting a system | package
No estoy seguro de entender eso. Ahora mismo tengo un servidor levantado (enable cockpit.socket), pero según eso podría conectarme a una máquina que tiene cockpit si tengo el bridge instalado con el cliente org.cockpit_project.CockpitClient, ¿no?
Ahora en Tumbleweed lo que tengo es una pantalla negra en el cliente de Cockpit recién instalado. En la barra de título pone Cockpit cliente Login, y nada más.
¿Hay que hacer alguna configuración adicional? lo he instalado con Discover.
El error que me da en Leap es que no encuentra cockpit-askpass para adquirir privilegios de administrador. En Tumbleweed funciona como se espera.
Hola a todos ,muy chulo ,que servicios puedo hacer o cambiar desde cockpit client en mi servidor.
He podido abrir mi servidor odroid c1 -armv7 32 bits ,se puede abrir desde la red (www) o es solo para local.
Que os sigo y me divierto.
Salud y Saludos
La verdad es que no lo había usado hasta hoy, pero se ha instalado sin problema y se ha conectado perfectamente. Creo que lo puedo adoptar para los otros equipos y centralizarlos. Tendré que ponerme al día.
Es para red, incluso si lo estás ejecutando en local. Usa ssh y depende de su configuración. Por ejemplo, usarlo con certificados no es lo más cómodo del mundo pero funciona.
Los servicios disponibles depende de qué módulos instales y en buena parte es lo que me hace poner este hilo. Por ejemplo en el repositorio home de ecsos tienes un montón de módulos que no están en el repositorio de cockpit y menos aún en los oficiales.
Sin embargo, hay un módulo llamado cockpit-dashboard que no está en el repositorio de ecsos (lo está en uno llamado Frankthetank13). Como curiosidad, lo he probado en una MV. He añadido un servidor remoto y al cerrar sesión y volver a abrirla no me es capaz de conectarse a dicho servidor XD.
Entre los servicios que he probado está podman para contenedores, claro, machines para máquinas virtuales, navigator para administrar ficheros (y en una remota he podido cargar ficheros mucho más rápido que con sftp para dolphin)…
En Almalinux puedo actualizar, pero en Tumbleweed no -por defecto me pide usar actualizaciones transaccionales- aunque siempre puedes usar el terminal incorporado.
En la versión del repo de ecsos tienen un módulo para packagekit, entiendo que eso sí puede actualizar.
[edito]
El paquete de flatpak me funciona en otra instalación, así que algo estará mal en la mía, quizá alguna configuración de las librerías gráficas que usa (gtk?).
Hola karlggest ,gracias por su respuesta, yo a través de yast instale los rpm que malcolmlewis tenia marcados.
Tenia flathub desactivado ,me fui al lanzador de aplicaciones y en buscar puse cockpit clienty me salio instalar cockpit client al tener desactivado flathub me daba error ,active este ultimo y se instalo sin problemas, después me fui al lanzador de aplicaciones a internet pulse sobre cockpit client y arranco sin problemas.
Por lo que se ve se instala a través de flathub (contenedores) , en yast tienes el archivo cockpit tukit
cockpit-tukit - Cockpit module for Transactional Update.
no se si tiene algo que ver ,yo no lo tengo instalado.
Aunque veo que la instalación la tienes echa,pero tienes en blanco la pantalla de inicio.introducir el nombre de usuario @ y la ip, en mi caso node@192.168.0.36 después te pide la contraseña y se ejecuta todo bien ,todo esto en local .
a través de la red ,creo que cambiara,ya sabes que soy novato ,pero me ha funcionado bien de esta manera.
Salud y Saludos
Eso maneja justamente eso, las actualizaciones transaccionales. Entiendo que eso es para MicroOS.
En este equipo desde el que escribo ahora he probado a instalar el paquete flatpak de Cockpit Client y funciona correctamente. Funciona bien en general (como el cliente web) pero falla un poco si intento añadir varios servidores.
Acabo de darme cuenta de que por algún motivo no tengo los mismos paquetes disponibles en las dos máquinas , o al menos no recuerdo tener disponible cockpit-packagekit, así que tendré que revisar a ver qué me he pasado por alto.
Hola de nuevo ,una duda,se puede abrir al mismo tiempo varios servidores con cockpit , yo he conectado con dos pero cerrando sesión y conectándome después al otro.
Salud y saludos
Sí, de hecho es la idea. Otra cosa es lo bien que funcione la autentificación del usuario por la conexión.
Con el cliente flatpak he podido tener un par de ellos, pero no los he podido añadir en cualquier orden: una vez añadido uno, si añadía otro fallaba; así que lo que hice fue cerrar sesión, iniciar en el otro y añadir el primero y funcionó.
Usando el cliente web puedo tener varios sin problema aunque la gestión de los certificados digitales (si los usas para conexión ssh, claro) podría ser más cómoda.
nota: antes he mencionado el caso de cockpit-packagekit. He comprobado que en el escritorio lo tengo instalado pero que el sistema de actualización que está en marcha es el de tukit y entonces no va, a ver si quitándolo.
Pueden comprobar una cosa, el acceso via navegador, sin usar cockpit-client.
Me dió por hacerme un scan de puertos, haber por donde comunicaba con el cliente y en mi caso me dió que tenía el puerto 9090 abierto → 9090/tcp open ssl/zeus-admin?
es decir un nmap -T4 -A -v 192.168.1.3 en mi caso.
lo que me sorprendió fueron estos datos:
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6.32
OS details: Linux 2.6.32
Uptime guess: 49.077 days (since Tue Apr 23 00:08:12 2024)
Network Distance: 0 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
He puesto en firefox la ip local del navegador mas el puerto 9090 y accedo de la misma forma que con el cockpit-client. Ejemplo: https://192.168.1.3:9090/
Me imagino que abriendo puertos en el router y redirigiendo ip, podría acceder vía internet también y modificando algunos parámetrors añadirle un certificado let’s encrypt para el navegador. Pero creo que es crear una brecha de seguridad innecesaria.
Es que no había leído nada de que se pudiera acceder con el navegador.
paquetes instalados:
zypper se -i cockpit
Cargando datos del repositorio…
Leyendo los paquetes instalados…
S | Name | Summary | Type
—±-----------------------±-----------------------------------------------------------------------±-------
i+ | cockpit | Web Console for Linux servers | paquete
i | cockpit-bridge | Cockpit bridge server-side component | paquete
i+ | cockpit-devel | Development files for for Cockpit | paquete
i+ | cockpit-doc | Cockpit deployment and developer guide | paquete
i+ | cockpit-kdump | Cockpit user interface for kernel crash dumping | paquete
i+ | cockpit-machines | Cockpit user interface for virtual machines | paquete
i | cockpit-networkmanager | Cockpit user interface for networking, using NetworkManager | paquete
i | cockpit-packagekit | Cockpit user interface for packages | paquete
i+ | cockpit-pcp | Cockpit PCP integration | paquete
i | cockpit-podman | Cockpit component for Podman containers | paquete
i+ | cockpit-selinux | Cockpit SELinux package | paquete
i | cockpit-storaged | Cockpit user interface for storage, using udisks | paquete
i | cockpit-system | Cockpit admin interface package for configuring and troubleshooting → | paquete
i+ | cockpit-tukit | Cockpit module for Transactional Update | paquete
i | cockpit-ws | Cockpit Web Service | paquete
Cuanto más pasan los años, parece que peor me expreso o escribo. Cuando hablo del “cliente web” es en correspondencia a un “servidor web” que como Malcom ha dicho requiere un puerto para conectarse (el 9090) lo que añade un puerto… abierto. Si no me evoco, el servidor web es justo:
Y de hecho las configuraciones iniciales que veréis en la mayoría de documentaciones son para conectarse así, con el servicio web usando un navegador.
No creo que sea tanto problema si lo manejas con un proxy inverso, redirigiendo por ejemplo desde 443. Lo cual tiene sentido si tienes que tener 443 abierto de todas formas: cualquier servicio que no sea basado en web que tengas en tu servidor no requerirá tener ese puerto abierto.
Aquí mola el rollo de que puedes conectarte por ssh con certificado y bloquear completamente el registro (login) a ssh. Y en el caso de tener varios servicios, es justo lo que no me convence demasiado de cómo maneja: en mis pruebas, por lo que sea, tengo que “reactivar” cada certificado con su clave, antes de usarlo.
Aclaro que no es porque me pida la clave, lo que esperaba es que al intentar conectarme me la pidiese, justamente. Sin embargo, tengo que ir al menú claves ssh en la cuenta de usuario, activarla, seleccionar o borrar la clave y volver a escribirla.
Por lo demás, me gustaría que el módulo podman tuviera opciones de edición. El de máquinas virtuales está guay pero no estoy seguro de si maneja bien varias a la vez -pero lo he probado poco, uso virt-manager por costumbre. He probado que el módulo packagekit maneja los paquetes instalados, así que sí está quedando una buena herramienta de administración remota. En MicroOS puedes usar el módulo tukit que maneja las actualizaciones transaccionales -y actualizar implica reiniciar salvo que digas lo contrario!!. Hay más módulos, pero no sé si los van a incluir o qué hoja de ruta hay al respecto, de ahí el hilo.
, o al menos no recuerdo tener disponible cockpit-packagekit, así que tendré que revisar a ver qué me he pasado por alto.