PDF de programación - AZLinux, Vitalinux y paquetería .deb

Abril de 2014

AZLinux, Vitalinux
y paquetería .deb

Jose Antonio Chavarría
[email protected]
@jact_abcweb



Servicio Redes y Sistemas
Grupo de Software Libre
[email protected]







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

AZLinux 2

76 paquetes

AZLinux 3

24 paquetes

AZLinux 12

~73 paquetes



SLED 10 SP2
(yum/rpm)

openSUSE 11.2
(zypper/rpm)

openSUSE 11.4
(zypper/rpm)

Ubuntu 12.04

(apt/dpkg)











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”

















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











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

















Pasión por el detalle





Un remedio que no sirve para todo











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



















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

Sistema de incidencias
* Redmine
* Bugzilla
* Tracker
* GitHub

El arte de saber pedir

Liberación

Sistema de control de
versiones

Construir el paquete

Subir el paquete a
migasfree

Distribuir

Cambio

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



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 <pattern>
$ dpkg -s <pkg>

$ dpkg -l
$ dpkg -l <pkg>
$ dpkg -l | grep <pattern>
$ dpkg -L <pkg>

# dpkg -i <file.deb>
# dpkg -r <pkg>
# dpkg -P <pkg>

/var/lib/dpkg/info/



Diferencia entre remove y purge





apt survivor guide

$ apt-cache search <pattern>
$ apt-file search <pattern>

# apt-get update
# apt-get dist-upgrade

# apt-get install <pkg>
# apt-get install –reinstall <pkg> # (no hace purge, sólo remove!!!)
# apt-get -f install

# apt-get autoremove
# apt-get remove <pkg>
# apt-get purge <pkg>

/etc/apt/apt.conf.d/
/etc/apt/preferences.d/



Diferencia entre dpkg y apt → sólo el PMS puede

resolver las dependencias





<name>_<version>_<architecture>.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





<mayor_version>.<minor_version>-<release>

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-