AZLinux, Vitalinux y paquetería .deb Servicio Redes y Sistemas Grupo de Software Libre [email protected] Jose Antonio Chavarría [email protected] @jact_abcweb Abril de 2014
Disclaimer Lo que os voy a contar son una serie de directrices AS IS No soy un experto en enfardamiento Ante cualquier duda, remítase a la documentación oficial: Debian Policy ( www.debian.org/doc/debian-policy) https://wiki.debian.org/IntroDebianPackaging https://wiki.debian.org/es/IntroDebianPackaging
Objetivo → administrar un gran número de equipos 1º intento → cambios manuales en cada máquina (se modifican perfiles de usuario) Ventajas → rápido? No: inmediato Problemas de gestión: * cómo actualizar cada equipo a lo último? * los cambios no son reproducibles 2º intento → automatizar tareas haciendo scripts (se garantizan estados finales, como en Chef, Puppet) Ventajas → cambios reproducibles (y con suerte orientados al sistema) Problemas: * cómo revertir cambios? Haciendo otro script 3º intento → agrupar scripts de configuración en paquetes (cambios orientados a la organización) Ventajas: * Gestión controlada en repositorios * Se asegura la integridad del sistema * Aplicación de cambios controlada (instalación y actualización). Se puede volver atrás * Feedback (gestor de paquetes) * Control de versiones (changelog de los paquetes)
O M U Problemas: * Cómo asignar paquetes a cada máquina (no todas requieren los mismos cambios y los repositorios en linux están disponibles para todos) Solución: migasfree (mashup de conceptos ya inventados) → por eso es simple * asignación selectiva (propiedades y calendarios) * feedback (alertas) * recolección automática de datos de equipos (hardware y software)
AZLinux 1 En producción desde 2007 hasta 2010 Evolucionó desde maquetas manuales no actualizables hasta ser la primera en utilizar paquetes para la GCS y migasfree La única distro con cliente de Novell (con protocolo NCP mejorado)
AZLinux 2 En producción desde 2010 hasta la actualidad (680 equipos), pero desde finales de 2012 no se instala en equipos Injerto del cliente de Novell de SLED (y del kernel...) Novell nunca nos ha dado soporte para sus bugs La comunidad openSUSE dejó de dar soporte en 2012 (como XP ahora...) Desde entonces, imposibilidad de actualizar programas... sin hacer “ingeniería de paquetes”
AZLinux 3: openSUSE 11.4 Desarrollada en el verano de 2011, nunca llegó a producción Podíamos tener nuevas versiones de aplicaciones pero era más de lo mismo Sirvió para aclarar ideas...
AZLinux 12 En producción desde finales de 2012 (230 equipos en la actualidad) Independencia total del cliente de Novell → ncpfs Estabilidad y long support al ser LTS Si algo existe en Linux, está siempre para Ubuntu
¿Qué es? GNU/Linux ready to use... NO: es una excusa para... Publicar y difundir nuestro método de trabajo (AZLinux) Es una prueba de concepto para atraer a la gente (qué fácil es crear una distro...) http://github.com/vitalinux/ Las distros generalistas se quedan en el olvido → Augustux, Molinux, Asturix Pero lo realmente importante es que a mí, en mi casa (en mi organización), me funcione Porque yo conozco cómo es mi casa (mi organización), yo tengo el potencial de hacerlo funcionar y que sea práctico para los míos → este es el espíritu y lo que a nosotros nos ha funcionado Para ello se necesita trabajo diario (y mejor si el equipo es interno) * Cambia el hardware (equipos, impresoras, etc.) * Evoluciona el software (mejoras, bugs) * Necesidades distintas para distintas personas * No se puede aplicar la misma receta en todas las organizaciones
Debido a cómo funciona GitHub (no permite gestionar incidencias en organizaciones, sólo en repositorios de código), se crea el proyecto Issues, cuando no tiene lógica ninguna...
Etapas y herramientas Petición Cambio Liberación Sistema de incidencias * Redmine * Bugzilla * Tracker * GitHub El arte de saber pedir Editor de textos IDE (opcional) Estudiar el sistema El oráculo Probar, destrozar, arreglar y volver a probar Seguir las reglas de enfardado Fijarse en cómo están construidos otros paquetes Sistema de control de versiones Construir el paquete Subir el paquete a migasfree Distribuir El arte de saber pedir → como tal, quiero tal, para tal El meollo está en el cambio... Cada aplicación hace las cosas de una manera distinta * FF, TB * .d → sudo, apt * Gconf, Dconf * cups
¿Qué se puede enfardar? * Ficheros nuevos (es el caso más fácil y el menos común) * Dependencias (metapaquetes) (requisitos, obsoletos, conflictos) (directivas...) * Cambios en la configuración del sistema (ficheros de otros paquetes, ficheros generados por otros paquetes, configuración de servicios y apps) (vx- migasfree-client, vx-desktop-settings, vx- bootsplash) * Cambios en perfiles de usuario (ficheros generados por otros paquetes) AZLinux (pasión por el detalle) * Combinaciones de todo lo anterior
Reglas para empaquetar: * La instalación es un proceso SILENCIOSO y AUTOMÁTICO (sin intervención del usuario). Habrá que tomar algunas decisiones (debconf) (la organización manda sobre el usuario) * La instalación y la actualización de un paquete son procesos diferentes (se ejecutan diferentes scripts) * Evitar los conflictos entre paquetes que no pueda resolver el PMS (dependencias incumplidas, conflictos/obsoletos, cuidado al tocar archivos de otros paquetes) * Al desinstalar, dejar todo como estaba (o casi) * Se puede programar un paquete en cualquier lenguaje de script (sh, bash, perl, python, php, ruby) * Idempotencia: instalar N veces un paquete genera siempre el mismo resultado
aytozgz-utils-0.1-0.8.i586.rpm azl-utils-2-4.i586.rpm azl-utils_12.0-2_all.deb vx-utils_1.1-1_all.deb .- La importancia de unas reglas para establecer los criterios del versionado de paquetes
Estructura de un paquete deb control.tar.gz instrucciones → data.tar.gz archivos a instalar → control → imprescindible, directorio debian, cómo data → opcional, el qué
Petición Tenemos instalada una impresora virtual PDF, pero si imprimimos periódicamente una misma página web, se sobrescribe el PDF generado con el mismo nombre ¿Dónde debería recogerse la petición? → sistema de control de incidencias (Redmine, Bugzilla, etc...)
Cambio ● Saber cómo funciona la impresora PDF ● Buscar información sobre el fichero de configuración ● Crear un paquete con lo necesario 1. paquete cups-pdf 2. /etc/cups-pdf.conf http://www.debianadmin.com/howto-install-and- customize-cups-pdf-in-debian.html 3. vx-package-new vx-cups-pdf * explicar fichero control (Pre-Depends: cups- pdf, vx-utils) * README * install (¡este no viene en la plantilla!) * preinst, postinst, prerm, postrm * changelog * usr/bin/vx-cups-pdf-renamer * usr/share/vx-cups-pdf/divert/etc/cups-pdf.conf
Ficheros “divertidos” ¿Cómo modificar un fichero de otro paquete? ● vx-file ● vx-file-insert ● vx-file-delete ● vx-line-comment ● vx-file-get-key ● vx-file-set-key ● vx-text-get-line-number ● vx-divert-add ● vx-divert-remove ● vx-divert-list-files ¿Cuándo es mejor cada caso? → depende Si es un fichero que puede ser modificado por varios paquetes → no diverger Si sólo hay que comentar/descomentar una línea → no diverger Si es un XML → diverger (es lo más fácil) Si se modifican varios parámetros → diverger www.debian.org/doc/debian-policy/ap-pkg-diversions. html wiki.debian.org/Adding and removing diversions
Liberación ● Construir el paquete ● Asignarlo a un repositorio ● Distribuir /etc/migasfree.conf → packager, server vx-build-package vx-cups-pdf (comentar líneas de migasfree-upload) * lintian * errores Migasfree Todo el proceso debe reflejarse en la incidencia
Petición Una vez que se haya generado el PDF, abrir el documento para ver cómo queda Añadir xdg-open $FILE al final del script (freedesktop.org) Nueva versión del paquete Subir de nuevo a migasfree
Petición Añadir un favorito apuntando a unizar.es en Firefox unizar-firefox vs. unizar-firefox-bookmarks /usr/lib/firefox/defaults/pref/firefox-unizar.js pref("general.config.filename", "global-unizar- conf.js"); pref("general.config.obscure_value", 0); /usr/lib/firefox/global-unizar-conf.js lockPref(); → http://kb.mozillazine.org/Knowledge_Base /usr/lib/firefox/searchplugins/ / etc/skel/.mozilla/firefox//bookmarkbackups/bookm arks-.json Pero, ¿qué hacer con los usuarios ya creados? → postinst vx-user-get-mozilla-profile set -x
Petición Asegurar que la versión de un programa siempre es la misma ¿Alguna idea de cómo hacerlo? Quitar las versiones posteriores del repositorio es muy cutre... Ver la siguiente diapositiva explicando el pinning
Petición Tras instalar un paquete, notificar al sistema que es conveniente reiniciar la máquina Ejemplo: azl-pms /var/run/reboot-required /var/run/reboot-required.pkgs /var/lib/dpkg/info/linux-image...postinst /usr/share/update-notifier/notify-reboot-required
Petición Partiendo de un Vitalinux, cambiar el fondo de escritorio por uno más chulo de la Universidad Existe vx-desktop-settings → unizar-desktop-settings es la mejor opción? Estudiar el sistema → cómo funciona la BD de Dconf → z-unizar.dconf
Normas y directivas ● Una directiva es un conjunto de normas. ● Una norma es una política ó regla (habitualmente de seguridad) que controla lo que los usuarios o equipos pueden o no hacer. ● Un paquete virtual es un nombre genérico que se le asigna a un paquete para indicar que proporciona una determinada funcionalidad. Esto nos puede resultar útil para la creación de directivas y normas para equipos y usuarios. ● Una directiva puede hacerse fácilmente haciendo un paquete que tenga como dependencias un conjunto de normas.
Normas y directivas (II) ● Así, podemos crear dos paquetes con la misma funcionalidad denominada “rule-admin” donde en uno permitiremos el uso de “sudo su” y en el otro no. ● Package: vx-rule-admin-yes – Provides: rule-admin – Conflicts: rule-admin – Replaces: rule-admin ● Package: vx-rule-admin-no – Provides: rule-admin – Conflicts: rule-admin – Replaces: rule-admin
Operación a corazón abierto Efectos colaterales no deseados Hace 2 años que no se hacen paquetes oficiales para openSUSE 11.2 (TB 3.0) Conseguimos de un repositorio personal los paquetes de TB 17 Tuvimos problemas con glibc porque zypper no gestiona los cambios de arquitectura de paquetes (en algunos equipos) También problemas con la navegación en Firefox en ciertos sitios HTTPS (bug en mozilla-nss) Nunca jugar con: * kernel * glibc * el cliente de migasfree * conectividad red
Buscando el preimpreso perdido p Mala organización de la organización Afecta a unos 75 puestos de trabajo del Ayto (con Linux) (0.02 %) No se sabe qué preimpresos se usan en cada equipo Hay ficheros que se llaman igual pero el contenido es diferente Resultado: no se puede empaquetar una solución común y cada vez que hay un cambio en un preimpreso, hay que ir al equipo y actualizarlo
Todo poder conlleva una gran responsabilidad... migas Teníamos una propiedad que no estaba bien programada. Esto hizo que a la hora de distribuir paquetes, haciendo las demoras por esta propiedad, no consiguiéramos una distribución homogénea a través del tiempo (durante todo el calendario no se actualizaba ningún equipo y cuando llegaba al final, todos de golpe, unos 200 equipos) Cuidado al programar propiedades, fallas y consultas en migasfree!!!
vx-rule-profile-disposable Evita reinventar la rueda Vitalinux Kiosk Objetivo: perfil de usuario de un sólo uso Después de hacerlo, nos dimos cuenta que Ubuntu viene con uno por defecto (sesión de invitado) https://github.com/vitalinux-kiosk/vx-rule-profile- disposable/tree/d0a84651de22fcda18d2a54701970 01f7522c4d9
Incidencias a Canonical/Zentyal ● Firefox no abre enlaces apt:// ● Firefox no navega a IPs si se tiene un proxy configurado a nivel de sistema ● Deficiente rendimiento del chip gráfico intel 845 en Ubuntu 12.04 ● No arranca el gestor LDM en determinado hardware ● No se crea un lanzador correcto de LibreOffice al hacer drag & drop desde el menú de aplicaciones
Incidencias a Canonical/Zentyal (II) ● Imposible desmontar una partición NCP si no hay conexión (el equipo se queda frito) ● Lentitud de copia de ficheros vía NCP en Nautilus ● No se pueden borrar directorios en un montaje NCP
Cambio de chip Todos los días hay nuevos retos porque para hacer siempre lo mismo y de la misma forma, ya están las máquinas A mí me motivan los retos, y con este método de trabajo tengo tiempo para afrontarlos Tratamiento incidencias: * No tan inmediato como un cambio manual * Mantenimiento preventivo * Menos llamadas
Estos son nuestros principios. Si no os gustan... ...haceros los vuestros!!! ¿Qué nos falta? * Integración continua * Eliminar nuestros bus factors → tenéis que evitarlos a toda costa (hacer paquetes no es alquimia) * Desarrollar más en abierto → Vitalinux y Vitalinux Kiosk son sólo el comienzo La importancia de que el equipo sea interno y realice el ciclo integral * Homologación de equipamiento * Fabricación maquetas y paquetes * Formación de las plataformas * Soporte a usuarios
jact
hageyahhoo
lovee
harunakano
ymitsuki
syumme01
naltatis
n0bisuke2
sawagaku
yukima77
cibmc
chaletenboisfr
brianwarren
sugarenia
colly
skipperchong
mza
thoeni
maggiecrowley
productmarketing
chrisshort
hursman
lauravandoore
denniskardys