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 

Desmontar Vitalinux y volverlo a montar: # apt-get purge vx-* /var/lib/dpkg/info/vx-migasfree-client.prerm -> || : # apt-get purge vx-* # reboot entrar como guest entrar como alumno explicar perfil de usuario (.dmrc, .gconf, .gnome2) /etc/apt/source.list.d/vx-base.list # apt-get install vx-migasfree-client # migasfree-tags -s # reboot entrar como guest entrar como alumno 

Convertir Vitalinux en Vitalinux Kiosk y vuelta a Vitalinux: # apt-get install vx-kiosk-migasfree-client Paquetes virtuales intercambiables # migasfree-tags -s error del lightdm.conf -> renombrarlo /etc/apt/apt.conf.d/ --> Dpkg options conf-new # reboot $ su alumno - $ sudo su # apt-get install vx-migasfree-client # migasfree-tags -s error del lightdm.conf -> renombrarlo # reboot 

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) 

Nuestro peregrinaje AZLinux 1 70 paquetes SLED 10 SP2 (yum/rpm) AZLinux 2 76 paquetes openSUSE 11.2 (zypper/rpm) AZLinux 3 24 paquetes openSUSE 11.4 (zypper/rpm) AZLinux 12 ~73 paquetes Ubuntu 12.04 (apt/dpkg) 

No content

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” 

No content

No content

No content

Amoticidad, la palabra es a-mo-ti-ci-dad La clave para montar un sistema de paquetes como el de AZLinux es: Atomicidad 

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... 

No content

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 

No content

No content

No content

Pasión por el detalle 

Un remedio que no sirve para todo 

No content

Aparte de los paquetes, más de 80 scripts de creación propia para automatizar y simplificar tareas 

Ordenadores por versión Estado actual del parque de ordenadores del Ayuntamiento 

¿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 

No content

No content

No content

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... 

Petición Cambio Liberación Mantra 

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 

Pero lo más importante es tener un buen plan 

¿Es complicado enfardar? 

¿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 

dpkg survivor guide $ dpkg -S $ dpkg -s $ dpkg -l $ dpkg -l $ dpkg -l | grep $ dpkg -L # dpkg -i # dpkg -r # dpkg -P /var/lib/dpkg/info/ Diferencia entre remove y purge 

apt survivor guide $ apt-cache search $ apt-file search # apt-get update # apt-get dist-upgrade # apt-get install # apt-get install –reinstall # (no hace purge, sólo remove!!!) # apt-get -f install # apt-get autoremove # apt-get remove # apt-get purge /etc/apt/apt.conf.d/ /etc/apt/preferences.d/ Diferencia entre dpkg y apt → sólo el PMS puede resolver las dependencias 

__.deb 0ad_0.0.15-0ubuntu1~14.04~wfg2_armhf.deb acl_2.2.51-5ubuntu1_i386.deb alsa-base_1.0.25+dfsg-0ubuntu1.1_all.deb apache2.2-bin_2.2.22-1ubuntu1.5_i686.deb gcc-4.6_4.6.3-1ubuntu5_amd64.deb libcamel-1.2-29_3.2.3-0ubuntu7.1_i586.deb 

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 

Instalación de un paquete 1. Script preinst install 2. Copia de ficheros (install) 3. Script postinst configure 

Desinstalación de un paquete 1. Script prerm remove 2. Borrado de ficheros (conffiles?) 3. Script postrm remove 4.Script postrm purge 

Actualización de un paquete 

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 

Mimetypes ● Shared MIME-info Database ● /usr/share/applications/defaults.list ● /usr/share/applications/mimeapps.list ● Desktop Entry Specification 

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 

Pinning ● Apt preferences ● Pinning Howto ● /etc/apt/preferences.d/ Package: xxxx Pin: version xxxx Pin-priority: 1001 Ejemplo: azl-hold-opensc-0.11.13 

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 

Otros ejemplos ● azl-thunderbird ● azl-ldap ● vx-desktop-* 

Tip Diferenciar entre el proceso de instalación y actualización de un paquete postinst if [ -z “$2” ] then else fi Ver un postinst y decir los parámetros que se pasan al script → acción [y versión] 

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 

Grandes pifias de la historia de AZLinux 

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