\documentclass{beamer}

\mode<presentation> {
  \usetheme{Darmstadt}
  \setbeamercovered{transparent}
}

\usepackage[spanish]{babel}
\usepackage[latin1]{inputenc}
\usepackage{pdfpages}
\usepackage{alltt}
\usepackage{verbatim}
\usepackage{hyperref}

\title[Debian - sysadmin]
{Aprovechando a Debian para la administración de sistemas}

\author[Gunnar Wolf]{Gunnar Wolf --- {\tt gwolf@debian.org}\\
\url{http://www.gwolf.org/soft/debian_sysadmin}}

\institute[IIEc - UNAM; Debian]
{Instituto de Investigaciones Económicas, UNAM\\
Desarrollador del proyecto Debian}

\date[CICOL 2006]{
  CICOL\\
  28 de junio del 2006
}

\pgfdeclareimage[height=2cm]{debian-logo}{debian-swirl}
\logo{\pgfuseimage{debian-logo}}

\AtBeginSection[]
{
  \begin{frame}<beamer>
    \frametitle{Contenidos}
    \tableofcontents[currentsection]
  \end{frame}
}

% If you wish to uncover everything in a step-wise fashion, uncomment
% the following command: 
%\beamerdefaultoverlayspecification{<+->}

\begin{document}

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
  \begin{alertblock}{Primera vez que presento esto}
    Para quien me conoce, no es ninguna novedad el que a últimas
    fechas ando a las carreras, o poco más que eso.
    \\
    \pause
    Me es vergonzoso, pero tengo que admitir que comencé a preparar
    este material el domingo 25 de junio - 4 días antes de
    presentarlo.
    \\
    \pause
    Hay aún varias lagunas en la presentación, varios puntos que no
    cubro a cabalidad. Conforme avance con este documento, lo iré
    actualizando en su URL.
    \pause
   \\
   ¿Que no te fijaste cuál es el URL? Ok, lo repito una última
   vez. Pero presta atención.
   \url{http://www.gwolf.org/soft/debian_sysadmin}
  \end{alertblock}
\end{frame}

\begin{frame}
  \begin{alertblock}{Nota}
    En esta plática vamos a hablar {\bf únicamente} acerca de algunas
    herramientas útiles que nos da Debian como administradores de
    sistemas. 
    \\
    No busco comparar a Debian con otras distribuciones, iniciar las
    famosas {\it guerras religiosas}, ni nada por el estilo. Estoy
    seguro que al menos la mayor parte de estas herramientas estarán
    también disponibles en otras distribuciones --- Yo hablo de lo que
    yo conozco.
    \pause \vskip 1.5em
    {\scriptsize Además, todos ya sabemos que Debian es la {\it mera
    neta} ;-) } 
  \end{alertblock}
\end{frame}

%% \begin{frame}
%%   \tableofcontents
%% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Paquetes útiles]{Breve reseña de algunos paquetes útiles al
  administrador} 

\begin{frame}
  \frametitle {Paquetitos, paquetotes por doquier}
  \begin{itemize}
    \item Si algo caracteriza a Debian es que tiene una cantidad
      tremenda de paquetes. Paquetes, además, para cualquier necesidad
      que un ser humano pueda tener. Bueno, {\it casi} cualquiera.
    \item Comencemos viendo algunos paquetes útiles para los
      administradores de sistemas en general.
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{¿Algo no funciona? ¡Repórtalo!}

\begin{frame}
  \frametitle {Mi primer necesidad: Que todo funcione cual debe}
  \begin{itemize}
    \item Como administrador de sistemas, lo más importante para
      mi vida diaria es que todo funcione como debe funcionar
    \item Que los demonios no mueran inesperadamente
    \item Que la documentación esté completa y refleje claramente
      el comportamiento de cada programa
    \item Que el sistema siga manteniendo una unidad general, que
      siga imperando el {\it prinicipio de mínima sorpresa} que rige
      en Debian
  \end{itemize}
  \uncover{Tenemos que familiarizarnos con el sistema de
    seguimiento de fallos ({\tt BTS}) de Debian}
\end{frame}

\begin{frame}
  \frametitle {Generalidades del BTS}
  \begin{itemize}
    \item La interfaz prinicpal para interactuar con el BTS es el
      correo
      \begin{itemize}
	\item Para enviar un nuevo reporte, {\tt
	  submit@bugs.debian.org}. Una vez reportado, le es asignado
	  un número identificador
	\item Para agregar información a un reporte (digamos, el
	  \#360792), escribo a {\tt 360792@bugs.debian.org}
	\item Para dar información adicional de control (como
	  cerrar, dividir, reasignar o clonar un reporte), escribo a
	  {\tt control@bugs.debian.org}
      \end{itemize}
    \item Claro, podemos también hacer consultas en línea, ya sea
      a los bugs relativos a un paquete ({\tt
      http://bugs.debian.org/{\it paquete}}) o los datos de un bug en
      específico ({\tt http://bugs.debian.org/{\it 360792}})
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {\tt reportbug}
  \begin{itemize}
    \item Reportar los bugs manualmente por correo no es la mejor
      manera.
    \item Hay que tomar en cuenta muchos detalles de formato, pues
      a fin de cuentas quien va a recibir el reporte es un programa
    \item {\tt reportbug} es un script bastante simple que nos
      simplifica el envío de estos reportes
      \begin{itemize}
        \item Verifica que el paquete esté instalado correctamente
          en el sistema
	\item Pide la información básica para levantar nuestro
	  reporte, así como algunos datos opcionales pero convenientes
	\item Muestra la lista de bugs activos que tiene el
	  paquete, para evitar que levantemos reportes repetidos
	\item Envía el reporte a través de nuestro MTA ---
	  \alert{que debe estar correctamente configurado}.
      \end{itemize}
  \end{itemize}
\end{frame}


\begin{frame}
  \frametitle {{\tt bts} y {\tt querybts}}
  \begin{itemize}
    \item Herramientas para interrogar o controlar al BTS desde la
      línea de comandos
    \item {\tt querybts} nos permite consultar el estado y los
      mensajes que forman parte de un reporte, facilitándonos
      consultar su estado
    \item {\tt bts} está principalmente orientado a los
      desarrolladores. Nos permite consultar al BTS, lanzando un
      navegador hacia la página adecuada, y genera los mensajes
      necesarios para enviarlos a control@bugs.debian.org
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Algunos paquetes que vale la pena conocer}

\begin{frame}
  \frametitle{{\tt systraq} - Monitorea nuestro sistema, reportándonos
    cambios}
  \begin{itemize}
    \item Nos envía un correo diario con varios indicadores del
      sistema (uptime, espacio en disco, uso de memoria, últimos
      logins, puertos abiertos, procesos en ejecución, verificación de
      los MD5 ante Debsums), para prevenirnos de posibles problemas
    \item Cada 30 minutos compara los archivos que le indiquemos
      (p. ej. todos los localizados dentro de /etc) contra la copia
      previa, y nos manda un correo con los cambios
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {{\tt apticron} - Mantiene al día nuestros sistemas}
  \begin{itemize}
    \item Está diseñado para ser invocado periódicamente (p.ej. a
      diario) desde el {\tt crontab}
    \item Busca y baja las actualizaciones al sistema disponibles
      \begin{itemize}
	\item \alert{No las instala}. Toda actualización de un sistema
	  en producción debe ser realizada con plena consciencia por
	  parte del administrador.
      \end{itemize}
    \item Envía un correo a la dirección de correo configurada
      indicando los paquetes a actualizar y la descripción de los
      cambios que incluyen.
    \item Basta con que entremos al equipo en cuestión y demos
      {\tt apt-get upgrade} - Los archivos ya están bajados y listos
      para instalar.
    \item \alert{No corras apticron más que en la versión
      estable}. Correrlo en testing o en inestable te va a llenar el
      buzón. Rápido. Muy rápido.
  \end{itemize}
\end{frame}


\begin{frame}
  \frametitle {{\tt sash} - Un shell para casos de emergencia}
  \begin{itemize}
    \item ¿Has borrado o renombrado alguna vez el directorio equivocado?
    \item Por más cuidadoso que sea un administrador, los errores
      siempre pueden ocurrir
    \item Sash ({\it Stand Alone Shell}) es un shell con todos los
      comandos básicos compilados como parte de la imagen en memoria
    \item Nos puede salvar en caso de que algo le pase a las
      bibliotecas base, y puede ser indispensable para revivir un
      sistema 
    \item Claro... Es sólo una herramienta más. Ha quedado ya
      ampliamente demostrado que ni los mayores avances en
      inteligencia artificial se comparan con los rudimentos de la
      estupidez natural.
    \item Instálalo, como sea. Son sólo 300k, no hacen daño. Y lo vas a agradecer un
      día. 
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{{\tt debootstrap} - Crea un sistema base Debian dentro
    de un directorio}
  \begin{itemize}
    \item Siempre es bueno tener un equipo o dos donde hacer nuestras
      pruebas antes de hacer cambios en los equipos en producción ---
      Pero no siempre tenemos los equipos disponibles
    \item Podemos querer compilar o probar determinado sisetma en un
      entorno limpio de una rama específica de la distribución
    \item {\tt debootstrap} crea un sistema base mínimo, de la rama de
      Debian que le indiquemos en un directorio. 
    \item Podemos hacer un {\tt chroot} a esta área, y tener un
      sistema completo para destrozar a gusto
    \item Con un poquito de trabajo adicional, podemos convertir estos
      entornos en servidores virtuales independientes y aislados
      \cite{SandinoVPS} 
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{{\tt lintian}, {\tt linda} y {\tt piuparts}}
  \begin{itemize}
    \item Cuando empaquetamos un programa, sea para uso nuestro o para
      contribuir a Debian, lo que buscamos es ahorrarnos trabajo
      \begin{itemize}
	\item Y, claro, brillar un poquito ;-)
      \end{itemize}
      \item {\tt lintian} y {\tt linda} hacen pruebas básicas sobre
	los paquetes que generamos, para asegurarse que cumplan con
	las políticas, que estén completos y que no haya errores
	obvios en los que caen
      \item {\tt piuparts} verifica (dentro de un {\tt chroot}) que
	los paquetes generados efectúen limpiamente su instalación,
	actualización y remoción. Ayuda a detectar muchos problemas
	antes de que se conviertan en bugs ;-)
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Paquetes .deb]{Breve no-tutorial de creación de paquetes
      .deb} 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Conceptos básicos}

\begin{frame}
  \frametitle{¿Qué necesito tener para crear un .deb?}
  \begin{itemize}
    \item Debian, o algo que huela muy similar
    \item Los contenidos del meta-paquete {\tt build-essential}
      \begin{itemize}
	\item Depende de los paquetes considerados indispensables para
	  construir un paquete
	\item En teoría, con {\tt build-essential} y los paquetes
	  esenciales instalados tendríamos suficiente para crear
	  paquetes... Obviamente, a esto se suman las dependencias
	  (ver más adelante)
      \end{itemize}
    \item Muy recomendado: El paquete {\tt devscripts}
      \begin{itemize}
	\item Depende de una gran cantidad de herramientas que
	  simplifican fuertemente el trabajo de creación y
	  mantenimiento de un paquete
      \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{¿Qué debo saber para crear un .deb?}
  \begin{itemize}
    \item Escribir un {\tt Makefile} relativamente simple
    \item Algo de programación en shell 
      \begin{itemize}
	\item Por mera tradición --- Ningún criterio técnico indica
	  que los scripts que forman parte de un paquete tengan que
	  estar en shell y no en otro lenguaje
	\item ...Pero hagamos fácil la vida de los demás: Apeguémonos
	  a la tradición. Eso impedirá algunos flamazos ;-)
      \end{itemize}
    \item Entender y juzgar si una licencia cumple con las DFSG
      (claro, sólo si me interesa que mi paquete forme parte de
      Debian) 
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{¿En qué consiste crear un paquete?}
  \begin{itemize}
    \item Cuatro archivos básicos (mas varios más opcionales) dentro
      del directorio {\tt debian/} del árbol original:
      \begin{itemize}
	\item {\tt changelog}
	\item {\tt control}
	\item {\tt copyright}
	\item {\tt rules}
      \end{itemize}
    \item Los demás archivos que hagan falta para su instalación ({\tt
      preinst}, {\tt postinst}), remoción ({\tt prerm}, {\tt postrm}),
      o cualquier otra cosa ({\tt init.d}, {\tt README}, {\tt
      logrotate}, etc.)
    \item Posiblemente, cambios o adecuaciones dentro del fuente original
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Componentes de un .deb}

\begin{frame}[fragile]
  \frametitle{\tt debian/changelog}
  \begin{itemize}
    \item Guarda el historial de cambios que ha tenido este paquete
    \item ...El historial de cambios {\it relativos al
      empaquetamiento} --- No los cambios generales al programa (que
      para eso está el changelog del autor)
    \item Siguen un formato rígido, analizable por las herramientas
    \item Pueden ser generados fácilmente con herramientas como {\tt
      dch} o con modos automáticos desde diferentes editores
    \item Puede incluir instrucciones para el {\it BTS} de Debian
  \end{itemize}
  \begin{example}[Una entrada de un {\tt debian/changelog} típico]
    {\tiny
      \begin{verbatim}
cherokee (0.5.3-1) unstable; urgency=low

  * New upstream release
  * Fixed: When upgrading from some older versions of Cherokee, the
    daemon failed to restart. (Closes: #363515)
  * Bumped up standards-version to 3.7.2

 -- Gunnar Wolf <gwolf@debian.org>  Thu,  1 Jun 2006 12:31:23 -0500

      \end{verbatim}
}
  \end{example}
\end{frame}

\begin{frame}
  \frametitle{\tt debian/control}
  \begin{itemize}
    \item Metadatos de los paquetes fuente y binarios que generaremos
    \item Declaramos los datos generales del paquete, sus dependencias
      de construcción y de uso, y otros varios detalles
    \item Es procesado también por una gran cantidad de scripts
  \end{itemize}
  \begin{example}[Un {\tt debian/control} simple]
    {\tiny \tt
      Source: ip2host\\
      Section: utils\\
      Priority: optional\\
      Maintainer: Gunnar Wolf $<$gwolf@debian.org$>$\\
      Build-Depends-Indep: debhelper ($>>$ 4.0.0)\\
      Standards-Version: 3.6.1
      \vskip 1em
      Package: ip2host\\
      Architecture: all\\
      Description: Resolve IPs to hostnames in web server logs\\
      \ This script is a drop-in replacement for the logresolve.pl\\
      \ script distributed with the Apache web server.\\
      \ 
    }
  \end{example}
\end{frame}

\begin{frame}
  \frametitle{\tt debian/copyright}
  \begin{itemize}
    \item Este archivo es para ser leído por humanos; el proceso de
      construcción de paquetes sólo lo requiere por ser información
      indispensable 
    \item Debe incluir el texto completo de la o las licencias que
      cubren al paquete (excepto para la Artística, GPL, LGPL y BSD,
      para las que basta referirse a {\tt /usr/share/common-licenses})
    \item Conviene incluir de dónde descargar el fuente original,
      quién realizó el empaquetado, etc.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{{\tt debian/rules} (1)}
  \begin{itemize}
    \item El archivo donde ocurre la magia del empaquetamiento
    \item Es un {\tt Makefile} con objetivos específicos:
      \begin{description}
	\item[build] Compila el programa
	\item[binary] Crea el paquete binario, instalando el programa
	  en {\tt debian/{\it paquete}} y los metadatos en {\tt
	  debian/{\it paquete}/DEBIAN}  
	\item[clean] Limpia el árbol
	\item[patch] Aplica los parches necesarios (si usamos dpatch ---
	  detalles más adelante)
	\item[unpatch] Revierte los parches necesarios (si usamos
	  dpatch --- detalles más adelante) 
      \end{description}
    \item Normalmente es creado valiéndose de ayudantes como {\tt
      debhelper} o {\tt cdbs} para simplificarlo
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{{\tt debian/rules} (2)}
  \begin{itemize}
    \item Para paquetes sencillos es muy simple
    \item Para paquetes múltiples que incluyen bibliotecas, y
      operaciones diversas post-construcción... No. ;-)
    \item Es a través de {\tt debian/rules} que transformamos la
      instalación default de un programa en una integrada con el resto
      del sistema, que cumple con las políticas de Debian, y que no va
      a romper nuestra lógica
    \item Y es importante hacer una última precisión: No por no estar
      haciendo paquetes oficiales para Debian debo ignorar las
      políticas --- Estas son recomendaciones de prácticas deseables
      para tener instalaciones limpias.
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Ayudantes}

\begin{frame}
  \frametitle {\tt debhelper}
  \begin{itemize}
    \item Muchas de las tareas para la construcción de un paquete se
      repiten entre uno y otro
    \item Un paquete creado completamente a mano tiene que ser
      actualizado completamente a mano cuando cambian las políticas
    \item {\tt debhelper} fue creado para automatizar tareas desde el
      montado del paquete (provee un esqueleto genérico) hasta casi
      cada uno de los pasos dentro de {\tt debian/rules}
    \item Algunos componentes ejemplo: {\tt dh\_clean}, {\tt
      dh\_builddeb}, {\tt dh\_fixperms}, {\tt dh\_compress} 
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {\tt cdbs}
  \begin{itemize}
    \item Incluso con {\tt debhelper}, hay mucha duplicidad entre las
      reglas de construcción de casi cualquier paquete
    \item {\tt cdbs} es un conjunto de macros, que permite especificar
      sólamente cuando nuestro proceso {\it diverge} del default
  \end{itemize}
\end{frame}

\begin{frame} 
  \frametitle{{\tt dh-make-perl} y {\tt dh-make-php}}
  \begin{itemize}
    \item Los ayudantes {\tt dh-make-perl} y {\tt dh-make-php} son
      generadores de esta infraestructura, aprovechando las aún
      mayores similitudes entre los módulos de estos lenguajes,
      permitiéndonos crear paquetes utilizando un sólo comando
    \item Los paquetes generados por estos dos ayudantes usan las
      funciones de {\tt debhelper}.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {{\tt dpatch} - Racionaliza el mantenimiento de parches}
  \begin{itemize}
    \item Conforme pasa el tiempo, un paquete va adquiriendo
      modificaciones hechas por su mantenedor, corrigiendo algún bug o
      alterando al programa para adaptarse mejor a Debian
    \item Estas modificaciones pueden volverse inmanejables si no
      están organizadas coherentemente, se vuelve imposible saber para
      qué hicimos cada uno de los cambios
    \item {\tt dpatch} separa cada parche en un archivo diferente, y
      automatiza el aplicarlos o revertirlos desde {\tt debian/rules}
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Conceptos relacionados}

\begin{frame}
  \frametitle{Código original ({\it upstream})}
  \begin{itemize}
    \item Normalmente un .tar.gz bajado del sitio del autor
    \item A veces, el código está disponible sólo en formato diferente
      o sólo en un sistema de control de versiones, en cuyo caso es
      necesario crear el .tar.gz uno mismo 
    \item El nombre debe ser {\tt{\it foo}\_1.2.3.orig.tar.gz} - De ser
      posible, sólo renombra el archivo original 
    \item Siempre que sea posible, evita modificar el archivo
      original. Es preferible manejar {\it fuentes prístinas} 
      \begin{itemize}
	\item Por seguridad --- Toda auditoría de código hecha al
	  código original es directamente aplicable a la copia que yo
	  tengo 
	\item Por facilidad --- A la hora de actualizar, es más fácil
	  simplemente poder reemplazar un juego de fuentes por el otro
      \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Paquete fuente y paquete binario}
  \begin{itemize}
  \item {\it Paquete fuente}: conjunto de tres archivos:
    {\tt {\it paquete}\_x.y.z.orig.tar.gz}, {\tt {\it
    paquete}\_x.y.z-a.diff.gz} y {\tt {\it paquete}\_x.y.z-a.dsc}
  \item {\it Paquete binario}: El o los {\tt .deb}
    generados:
      \begin{itemize}
	\item {\tt {\it paquete}\_x.y.z-a\_i386.deb} indicaría un
	  paquete compilado para arquitectura i386 (PC)
	\item {\tt {\it paquete}\_x.y.z-a\_ppc.deb}, compilado para
	  arquitectura PowerPC (Macintosh)
	\item {\tt {\it paquete}\_x.y.z-a\_all.deb}, un paquete no
	  específico para ninguna arquitectura (como un módulo de
	  Perl, Python o algún otro lenguaje de script, documentación,
	  datos, etc.)
      \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {Paquete nativo y no nativo}
  \begin{itemize}
    \item Llamamos {\it paquetes nativos} a los paquetes que el autor
      original prepara específicamente para Debian, para los que no
      existe un trabajo aparte por parte del mantenedor
    \item Un paquete nativo {\it no lleva} la última parte de la
      versión - Esto es, puede ser versión {\tt x.y.z}, pero no {\tt
      x.y.z-a}
    \item Un paquete nativo en realidad debería ser sólo software
      desarrollado {\it ex-profeso para Debian}, no software
      cualquiera empaquetado. Esto por:
      \begin{description}
	\item[Flexibilidad] Normalmente el mantenedor puede hacer
	  cambios a lo largo de la vida de una misma versión {\it
	  upstream} --- Si amarramos el empaquetamiento al número de
	  versión del autor, esto se hace imposible
	\item[Manejo de la rama estable] Una vez liberada una nueva
	  distribución estable, no entran versiones nuevas de los
	  paquetes. 
      \end{description}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{¿Y por fin, cómo hago un {\tt .deb}?}
  \begin{alertblock}{Yo se los advertí...}
    Este fue meramente un {\it breve no-tutorial}. Para más detalles,
    les recomiendo:
    \begin{itemize}
      \item la Guía del Nuevo Desarrollador de Debian \cite{NewMaint}
      \item La referencia del desarrollador \cite{DebDevRef}
      \item Los manuales del DDP para desarrolladores \cite{DDP}
      \item El tutorial de creación de paquetes para Debian por Lars
	Wirzenius \cite{Lars}
    \end{itemize}
    \pause
    ...Si queda tiempo, con gusto jugamos un poquito.
  \end{alertblock}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Depósitos APT]{Manejando diferentes depósitos APT}

\begin{frame}
  \frametitle{Más allá de paquetitos individuales}
  El trabajo de Debian va mucho más allá de proveer miles de
  paquetitos individuales. El trabajo de Debian busca:
  \begin{itemize}
    \item Facilitar la instalación de software
      \begin{itemize}
	\item Precompilado, configurado, legal y libre
	\item Dependencias, actualizaciones, seguridad
      \end{itemize}
    \item Facilitar la desinstalación de software
      \begin{itemize}
	\item ¿Qué paquetes realmente nos interesa tener instalados,
	  y cuáles tenemos únicamente por cubrir dependencias?
	\item ¿Qué paquete es responsable de cada archivo?
	\item ¿Qué quiere realmente hacer el usuario?
	  (diferencia entre desinstalar y purgar)
      \end{itemize}
    \item Asegurar que todo el software funciona
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{¡Los paquetes sueltos no son lo importante!}
  \begin{description}
    \item[Calidad] Debian busca garantizar que cada uno de sus
      componentes cumpla un mínimo de calidad. Esto no sólo se
      refiere a su operación en solitario, sino que a su
      relación con los demás componentes del sistema.
    \item[Integración] La labor principal de toda distribución
      es asegurar que una gran cantidad de programas puedan trabajar
      correctamente en conjunto, evitando sorpresas al administrador
    \item[Estándares] Todo el trabajo de integración se apega a
      documentos publicados y reconocidos, para evitar al
      administrador trabajar de más para resolver un problema,
      principalmente el {\it Manual de Políticas de Debian
      \cite{Policy}}, la {\it Jerarquía de archivos estándar (FHS)
      \cite{FHS}} y (a cierto grado) la {\it Base estándar de Linux
      (LSB) \cite{LSB}}. 
  \end{description}
\end{frame}

\subsection{Combinando software de diferentes depósitos}

\begin{frame}
  \frametitle{Pero a veces tenemos que abandonar la perfección}
  Hay, claro, varios motivos perfectamente válidos para dar un
  pasito de lado, renunciar a las ventajas que nos da esta
  interacción, e instalar software no empaquetado para nuestra
  versión de Debian. Los principales:
  \begin{description}
    \item[Actualización] La rama estable de Debian es la más
      adecuada para sistemas en producción --- Pero el software que
      ofrece no puede ser el más nuevo. Por ello nacen los {\it
      backports}. 
    \item[Licenciamiento] Debian es muy estricto en cuanto a la
      inclusión de software no estrictamente libre. El mundo real a
      veces exige mayor pragmatismo --- Además, no todos los usuarios
      tienen que estar tan convencidos de la libertad como los
      desarrolladores ;-)
  \end{description}
\end{frame}

\begin{frame}
  \frametitle {...Pero dentro de la arquitectura}
  \begin{itemize}
    \item Sin embargo, aún sabiendo que vamos a instalar software de
      fuera de Debian, nada nos obliga a salir del bellísimo mundo de
      APT --- Podemos acudir al maravilloso mundo de los {\it
      depósitos no oficiales}
    \item Basta con que agreguemos las referencias al depósito que
      necesitemos dentro de nuestro {\tt /etc/apt/sources.list}, a la
      altura que lo consideremos adecuado (más alto indica mayor
      prioridad), y {\tt apt-get}, {\tt aptitude} y las demás
      herramientas sabrán encontrarlo e integrarlo.
    \item ¿Dónde puedo encontrar depósitos APT útiles y confiables? Un
      par de ligas a continuación
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {\url{http://volatile.debian.net/}}
  \begin{itemize}
    \item Destinado a los paquetes que por su naturaleza tienen que
      ser actualizados, y para los que la versión de la rama estable
      necesariamente se hará inútil
      \begin{itemize}
        \item Antivirus (y sus firmas)
        \item Antispam (firmas y motores)
      \end{itemize}
    \item Los paquetes en {\tt volatile} exigen alto grado de
      integración
      \begin{itemize}
        \item Mantenido de acuerdo con el mantenedor oficial
	\item El usuario puede usar el BTS de Debian para estos
	  paquetes
	\item Compromiso de actualización limpio al actualizar a la
	  siguiente versión estable
      \end{itemize}

  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {\url{http://www.backports.org/}}
  \begin{itemize}
    \item Actualizaciones para paquetes independientes de la rama
      estable 
    \item Todos los paquetes de este depósito son creados y mantenidos
      por desarrolladores oficiales de Debian, típicamente (aunque no
      siempre) los mismos que mantienen cada uno de los paquetes en la
      distribución oficial 
    \item Los paquetes son de todas las categorías, y no hay garantía
      de que no vaya a haber conflictos (todos deben estar compilados
      contra la rama estable, pero puede haber inter-dependencias)
    \item Fuerte recomendación \cite{BackportsPinning} de usar un {\it
      apt-pinning} bajo (Sí, no he explicado qué es esto. Un poquito de
      paciencia ;-)
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {\url{http://www.apt-get.org/}}
  \begin{itemize}
    \item Directorio con ligas a depósitos APT
    \item Paquetes de todo tipo, para todas las ramas de Debian,
      mantenidos por todo tipo de gente
    \item Hay backports a Woody (¡hasta a Potato!), hay depósitos
      de cosas demasiado nuevas (y tal vez peligrosas) para inestable 
    \item Algunos depósitos ya huelen un poquito rancio, le hace falta
      una depuración
    \item ... ¡Pero resultan {\it muy} útiles a veces!
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle {¿No los necesitas? ¡No le rasques!}
  \begin{itemize}
    \item Aunque resultan muy útiles cuando hace falta, lo mejor es
      {\it evitar los depósitos no oficiales} a menos que tengamos una
      necesidad imperiosa que sólo podamos cumplir con ellos
    \item ...A fin de cuentas, sería una lástima desperdiciar el
      hermoso control de calidad de los debianeros ;-)
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Uso de software de diferentes ramas: Pinning}

\begin{frame}
  \frametitle {Depósitos con diferentes versiones del mismo paquete}
  ¿Qué hace {\tt apt-get} cuando más de un depósito ofrece el mismo
  paquete? (hasta donde ahora hemos visto)
  \begin{enumerate}
    \item Si la versión es diferente, instala el que tenga versión más alta
    \item Si la versión es igual, baja el paquete del depósito que
      esté más arriba en el {\tt sources.list}
  \end{enumerate}
  Con estas reglas, es obvio que no podemos añadir a nuestros
  depósitos otra rama de Debian, pues terminaríamos actualizando el
  sistema entero...
  \pause \vskip 1.5em
  ¿O sí?
\end{frame}

\begin{frame}[fragile]
  \frametitle {Presentando: APT pinning}
  A través del archivo {\tt /etc/apt/preferences}, podemos apuntar a
  más de un depósito APT que provea diferentes versiones del mismo paquete
  \begin{example}[{\tt /etc/apt/sources.list} que provee diferentes
      versiones del mismo paquete]
    {\scriptsize
      \begin{verbatim}
deb http://nisamox.fciencias.unam.mx/debian/ stable main contrib 
deb http://nisamox.fciencias.unam.mx/debian/ unstable main contrib 
deb http://nisamox.fciencias.unam.mx/debian/ experimental main contrib 

deb-src http://nisamox.fciencias.unam.mx/debian/ unstable main contrib
      \end{verbatim}
    }
  \end{example}
\end{frame}

\begin{frame}[fragile]
  \frametitle {Indicando nuestras preferencias para el pinning} 
  \begin{example}[{\tt /etc/apt/preferences} indicando preferencia
      por la rama estable]
    {\scriptsize
      \begin{verbatim}
Package: *
Pin: release a=stable
Pin-priority: 900
 
Package: *
Pin: release a=unstable
Pin-priority: 500

Package: *
Pin: release a=experimental
Pin-priority: 300
      \end{verbatim}
    }
  \end{example}
  Instalaremos los paquetes que estén disponibles de la familia de
  prioridad más alta posible (esto es, {\tt stable}).
\end{frame}

\begin{frame}
  \frametitle {Especificando la rama}
  \begin{itemize}
    \item Con la configuración de la lámina anterior, estaremos
      siguiendo estable, pero los paquetes que no formen parte de
      estable se instalarán de inestable, o de experimental en caso
      necesario. 
    \item ¿Y si quiero instalar (y seguir) la versión de inestable de
      un paquete en específico?
      \begin{example}[Especificando un paquete específico de una rama]
	{\tt \scriptsize
	  \# apt-get -t unstable install {\it paquete}
	}
      \end{example}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle {Et voil\`a... ?}
  \begin{itemize}
    \item Cuando esto funciona, es bello. Es lo mejor de todos los
      mundos. 
    \item Desgraciadamente, no siempre funciona. Inestable se tiende a
      separar demasiado de estable a lo largo del ciclo de liberación
  \end{itemize}
      \begin{example}[Cuando el pinning no es suficiente]
	{\tiny
	\begin{verbatim}
# apt-get -t experimental install mutt-ng
(...)
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
(...)
The following packages have unmet dependencies:
  mutt-ng: Depends: libc6 (>= 2.3.5-1) but 2.3.2.ds1-22sarge3 is to be installed
           Depends: libgnutls13 (>= 1.3.5) but it is not installable
           Depends: libgpg-error0 (>= 1.2) but 1.0-1 is to be installed
           Depends: libidn11 (>= 0.5.18) but 0.5.13-1.0 is to be installed
           Depends: libncursesw5 (>= 5.4-5) but 5.4-4 is to be installed
           Depends: libqdbm12 but it is not installable
           Depends: libsasl2 (>= 2.1.19.dfsg1) but 2.1.19-1.5sarge1 is to be installed
E: Broken packages

	\end{verbatim}
	}
      \end{example}
\end{frame}

\begin{frame}
  \frametitle {¿Cuál fue el problema?}
  \begin{itemize}
    \item {\tt muttng} depende de demasiados paquetes de versiones
      superiores a las disponibles
    \item Actualizar estos paquetes (especialmente {\tt libc6})
      supondría actualizar prácticamente todo el sistema --- Casi todo
      depende de {\tt libc6}. ¿Qué salida nos queda?
      \begin{itemize}
	\item Crear un {\tt chroot} de la rama deseada con {\tt
	  debootstrap} e instalar el paquete dentro de él --- Con todo
	  el enredo que eso significa cuando hay que compartir
	  información con el resto del sistema
	\item Recompilar nosotros el paquete. En una buena parte de
	  los casos, la dependencia es sobre el {\tt ABI} de las
	  bibliotecas, no sobre su {\tt API} --- ¡Pero ya hablamos de
	  las ventajas de tener los paquetes gestionados en una
	  arquitectura unificada!
      \end{itemize}
    \item ...Lo que nos lleva al siguiente punto.
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Creación de depósitos APT}

\begin{frame}
  \frametitle{Entendiendo a un depósito APT}
  La línea de un depósito APT en {\tt sources.list} está formada por:

  {\tt \scriptsize \onslide<1->deb
    \onslide<2->http://nisamox.fciencias.unam.mx/debian/
    \onslide<3->unstable \onslide<4->main contrib}
  \onslide<1->
  \begin{enumerate}
    \item<1-> Tipo de paquetes: Fuente ({\tt deb-src}) o binario ({\tt
      deb})
    \item<2-> URL base. A este URL se le agrega el directorio {\tt
      dists}
    \item<3-> Rama. Típicamente indica la rama para la cual están
      armados los paquetes, pero en realidad es una cadena arbitraria.
    \item<4-> Componentes. Divisiones lógicas que un depósito puede
      tener. En el caso de los depósitos oficiales de Debian, son {\tt
      main}, {\tt contrib} y {\tt non-free}, pero sólo son
      --nuevamente-- cadenas arbitrarias.
  \end{enumerate}
  Asumamos esta línea para nuestra explicación, para una arquitectura
  i386. 
\end{frame}

\begin{frame}
  \frametitle{¿Qué conforma a un depósito? {\tt (URL base)/{\it
	rama}/Release}} 
  Este archivo lleva la descripción del depósito. Incluye los campos:
  \begin{description}
  \item[Architectures] Las arquitecturas para las que está
    disponible este depósito (en el ejemplo, al meno {\tt i386}
    y {\tt source}) 
  \item[Codename] El nombre de la rama ({\tt sid})
  \item[Components] Los componentes que este depósito ofrece
    ({\tt main}, posiblemente otros)
  \item[Date] La fecha de última modificación
  \item[Label] Descripción del depósito
  \item[Origin] Origen de los paquetes --- Quién los prepara
  \item[Suite] Para qué rama de Debian están preparados los
    paquetes (nivel, no nombre)
  \item[MD5Sum] Verificación MD5 de todos los paquetes que
    forman parte del depósito
  \end{description}
\end{frame}

\begin{frame}
  \frametitle{¿Qué conforma a un depósito? {\tt dists/{\it
    rama}/Contents-{\it arq}.gz} y {\tt .bz2}}
  Lista de archivos provistos por cada uno de los paquetes del
    depósito. Cada línea lleva el nombre del archivo, la sección del
    paquete, y el nombre del paquete.
    \vskip 3em
    \pause
    ¡Qué friega generar todo esto a mano! ¿O no?
\end{frame}

\begin{frame}[fragile]
  \frametitle{{\tt apt-ftparchive}: Crea los metadatos de un depósito
    APT sencillo}
  Para crear depósitos simples, {\tt apt-ftparchive} es posiblemente
  el mecanismo más sencillo. Requiere que creemos un archivo por
  componente, y se encarga de ensamblar una configuración maestra y
  los archivos {\tt Releases} y {\tt Contents}
  \begin{example}[Archivo de configuración para {\tt apt-ftparchive}
    que generaría un depósito simple]
    \scriptsize
    \begin{verbatim}
APT::FTPArchive::Release::Origin "Debian";
APT::FTPArchive::Release::Label "Debian";
APT::FTPArchive::Release::Suite "unstable";
APT::FTPArchive::Release::Codename "sid";
APT::FTPArchive::Release::Architectures "i386 source";
APT::FTPArchive::Release::Components "main contrib non-free";
APT::FTPArchive::Release::Description "Debian Unstable - Not released";
    \end{verbatim}
  \end{example}
\end{frame}

\begin{frame}
  \frametitle{Más allá de {\tt apt-ftparchive}}
  \begin{itemize}
    \item {\tt apt-ftparchive} es adecuado para depósitos chicos ---
      Les aseguro que el depósito ejemplo no es generado con esta
      herramienta. 
    \item Eso sí, es más que suficiente para mi depósito personal
    \item Otras alternativas que llegan más allá
      \begin{itemize}
	\item {\tt reprepro} maneja depósitos APT, construye una
	  jerarquía basada en un {\tt pool} similar a la utilizada en
	  los depósitos oficiales. Guarda los datos de los paquetes en 
	  una base de datos basada en DB3. Maneja firmas de depósitos, 
	  mirrors, generación de índices firmados. Puede ser
	  configurado para manejar una cola de entrada
	  \cite{Reprepro}.
	\item {\tt mini-dinstall} monitorea un depósito y actualiza
	  periódicamente {\tt Release} y {\tt Contents}. Basado en la
	  funcionalidad que ofrece {\tt dinstall} en Debian, menos
	  algunas restricciones para hacerlo más ligero y adecuado a
	  depósitos personales.
      \end{itemize}
  \end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section[Refinando nuestros paquetes]{Refinando la inteligencia de nuestros paquetes}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Divergencias, Alternativas y bichos similares}

\begin{frame}
  \frametitle{Divergencias, alternativas, {\tt debconf} y bichos similares}
  \begin{itemize}
    \item No hay material preparado para este tema, disculpen.
      \pause
    \item Pero bueno, hagan de cuenta que sí lo hay. Me comprometo a
      explicar lo que de todos modos explicaría.
      \pause
    \item ... ¡Oportunidad perfecta para ver a un Gunnar nervioso y
      tartamudeante! ;-)
  \end{itemize}
\end{frame}

%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% \subsection{Debconf}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Fin}

\begin{frame}
  \frametitle{Bibliografía}
  \begin{thebibliography}{10}
  \bibitem{SandinoVPS}
    \htmladdnormallink{Seguridad por virtualización (Sandino Araico)}
		      {http://registro.cicol.org.mx/comas/general/proposals/53}
  \bibitem{BuildEssential}
    \htmladdnormallink{Lista de paquetes {\it build-essential}}
    {http://www.us.debian.org/doc/packaging-manuals/build-essential}  
  \bibitem{NewMaint}
    \htmladdnormallink{Guía del Nuevo Desarrollador de Debian}
		      {http://www.us.debian.org/doc/maint-guide/}
  \bibitem{DebDevRef}
    \htmladdnormallink{La referencia del desarrollador}
	      {http://www.us.debian.org/doc/manuals/developers-reference/}
  \bibitem{DDP}
    \htmladdnormallink{Manuales del DDP para desarrolladores}
		      {http://www.debian.org/doc/devel-manuals.es.html} 
  \bibitem{Lars}
    \htmladdnormallink{Tutorial de creación de paquetes para Debian por
      Lars Wirzenius}
      {http://liw.iki.fi/liw/talks/debian-packaging-tutorial.pdf}, 
      y su \htmladdnormallink{traducción al español por Isaac
      Clerencia}
      {http://people.warp.es/~isaac/debian-packaging-tutorial-es.pdf} 
  \framebreak
  \bibitem{Policy}
    \htmladdnormallink{Manual de políticas de Debian}
		      {http://www.us.debian.org/doc/debian-policy/}
  \bibitem{FHS}
    \htmladdnormallink{Jerarquía de archivos estándar (FHS)}
		      {http://www.pathname.com/fhs/}
  \bibitem{LSB}
    \htmladdnormallink{Base estándar de Linux (LSB)}
		      {http://lsb.freestandards.org/}
  \bibitem{BackportsPinning}
    \htmladdnormallink{Especificando pinning para los backports}
		      {http://www.backports.org/instructions.html} 
  \bibitem{PinningForBeginners}
    \htmladdnormallink{Apt-pinning for beginners}
		      {http://jaqque.sbih.org/kplug/apt-pinning.html}
  \bibitem{PinningMultiple}
    \htmladdnormallink{Using APT with more than 2 sources}
		      {http://www.argon.org/~roderick/apt-pinning.html}
  \bibitem{Reprepro}
    \htmladdnormallink{Setting up your own APT repository with upload
      support} {http://www.debian-administration.org/articles/286} 
  \end{thebibliography}
\end{frame}

\begin{frame}
  \frametitle{¿Dudas?}
  \begin{itemize}
    \item Sí, como primer duda sé que viene un {\it ¿Y el resto del
      material prometido?} 
    \item ...Fuera de eso... ¿Alguna duda?
  \end{itemize}
  \vskip 2em
  {\Large ¡Gracias!}
  \vskip 1em
  Gunnar Wolf --- {\tt gwolf@gwolf.org}\\
  \url{http://www.gwolf.org/soft/debian_sysadmin}
\end{frame}

\end{document}
