tags/ubuntu

ntp-ntpdate

2009-01-22T04:24:04Z

En la oficina tenemos un server que entrega nfs; también tenemos mucha gente que compila cosas. Estos dos parámetros hacen que tener sincronizadas las horas de las máquinas sea una necesidad. Pra esto se pueden usar los paquetes ntpdate (para on-time-sync) y ntp (para keep-in-sync). Hoy estuve revisando bien como interactúan ambos, sobre todo al momento del booteo. antes una descripción de qué hace cada uno.

ntp se encarga de mantener la hora de la máquina mas-o-menos sincronizada con la de una fuente externa. Si llega a haber cierta diferencia, se encarga de ir acomodando la hora de a poco, para que el sistema no sufra por cambios bruscos. Un problema que tiene es que si la diferencia con la referencia externa es muy grande, ntp no es capaz de salvar las diferencias y entonces ''no hace nada''. ntpdate se encarga simplemente de setear incondicionalmente la hora local según la hora que consiga de esta referencia externa. El escenario ideal sólo haría uso de ntp, pero en general se podría usar también ntpdate para máquinas con el reloj para-el-carajo, como parece ser el caso de al menos una de nuestra máquinas.

El tema es que, por defecto, ntpdate utiliza un archivo de configuración de ntp, pero a su vez corre despúes de éste, en cuya condición falla pues el puerto UDP que usa ya está en uso por ntp. Desinstalando ntp nos deja sin el archivo de configuración, y en realidad tiene sentido quedarnos con él.

La solución que encontré es simplemente hacer un symlink al script de ntpdate en /etc/network/if-up.d a un nombre anterior al de ntp (por ejemplo, mntpdate). Voy a ver si en debian/ubuntu me dan pelota con lo de ponerles mejor orden que simplemente el nombre.

sysadmin ubuntu debian

dapper-feisty-II

2009-01-22T04:24:04Z

hoy finalmente hicimos el doble salto mortal en nuestras 11 máquinas. he aquí un reporte.

una de las máquinas volvió a tener el hipo de hwdb-client* que no podían instalarse por lo que comenté en el post anterior. el tema es que el truco de hacer dpkg -i hwdb-client* no funcionó poruqe hwdb-client a secas iba a ser removido luego de ser instalados los otros. para salir del paso, hubo que recurrir a la fuerza bruta:

dpkg --force-depends -P hwdb-client

en otra no anduvo porque no se pudo instalar python-central. sólo hubo que darle otra vielta por dselect antes de hacer la manganeta con dpkg. cabe aclarar que si bien todas son *buntus, la mayoría son ubuntus, hay una que otra kubuntu, y en general cada una tiene un montón de paquetes instalados para satisfacer las necesidades de aquellos que alguna vez la usaron.

ya a la cuarta máquina a la que le hacía el upgrade me sabía de memoria qué hacer cuándo y dónde. se volvió tan aburrido que en un momento dado estaba upgradeando 5 máquinas a la vez. el vinito del mediodía le puso un poco de pimienta al asunto.

salvo algunos detalles con una placa de video via k8m890 todo salió a la perfección. creo que esta pirueta no habría salido si no fuera por debian y ubuntu. estoy seguro que en alguna otra distro no debian-based aún estaría renegando.

sysadmin ubuntu

cups-ubuntu

2009-01-22T04:24:04Z

Hace más de dos años, un desarrollador de KPrinter (la parte de KDE que se encarga de abstraer la impresión) se dió de narices con que los paquetes de cups del Ubuntu Dapper estaban configurados de forma que no detectaban impresoras en la red automáticamente, la cual, según sus propias palabras, es una de las características más piolas de cups.

A principios del año pasado tuve que reconfigurar varios Dappers para que vieran la impresora de la empresa.

Año y medio después salió Ubuntu Feisty. Año y medio después, el bug sigue estando. Hoy pasé otro tanto de tiempo (más, porque ahora hay más máquinas) re-reconfigurando los Feistys a los que había actualizado hace poco más de dos meses. Esto me lleva a pensar en dos cosas.

Por un lado, cuando actualicé de Dapper a Feisty, por algún motivo se le dió por pisar la configuración que yo había modificado. Como dije en el post del upgrade, vaya a saberse lo que hace el instalador gráfico cuando no le pregunta nada al usuario. Por otro, 18 meses pasaron y no han cambiado de idea: cups sigue teniendo el browsing deshabilitado. Es que esta gente no aprende?

sysadmin ubuntu cups

python2.3-en-feisty

2009-01-22T04:24:04Z

a veces la vida del sysadmin lo pone uno frente a situaciones que sólo se pueden arreglar de la peor forma posible: con alambre.

resulta que upgradeamos a feisty hace poco más de una semana. ese upgrade se llevó puesto una versión de python que aún es usado en algunos proyectos viejos (agradézcoseló a nuestros queridísimos amigos zope 2.9.6 y plone 2.5), la 2.3. como es imprescindible para ese laburo, no quedó otra que tratar de instalarlo.

para casos como éste lo primero que intento es bajar el .deb más reciente que haya. en debian o ubuntu, visito la página de paquetes y me los bajo de ahí. la ventaja de esto sobre ir al repo directamente es que me manda al repo de actualizaciones de seguridad si esto llegara a ser necesario.

cuestión que me bajé el python2.3_2.3.5-9ubuntu1.2_i386.deb y le mandé un dpkg --dry-run -i. la salida era algo de esperarse:

 python conflicts with python2.3 (<< 2.3.5-14)
  python2.3 (version 2.3.5-9ubuntu1.2) is to be installed.

el segundo paso obvio es el *port (en este caso un forwardport!). para un backport apt-get source y apt-get build-dep suelen ser tus amigos, pero para un fwport no. así que a visitar las páginas de los paquetes y a resolver estas dependencias a mano. hubo que descomprimir las fuentes a mano con dpkg-source -x y luego el viejo y querido fakeroot ./debian/rules binary para compilar y crear el paquete. como era de esperarse, esto tampoco funcionó. lamentablemente no tengo el error acá.

ahora bien, el mensaje de error del dpkg -i de allá arriba me dió una idea: forzar la versión de python. yo ya sabía desarmar .debs a mano con ar -x (esto deja un control.tar.gz y un data.tar.gz que contienen los metadatos del paquete y los archivos del paquete respectivamente. notar que ar es parte de las binutils, por lo que si de repente se te rompió todo el sistema apt/dpkg en un debian, aún podés recurrir a estas herramientas para solucionarlo (no digo que haya sido el motivo por el cual lo usaron, sino que es una buena consecuencia; seguramente es porque era lo que había a mano :)

así que desarmé el paquete, desarmé el control.tar.gz, toqué el archivo control donde declaraba la versión (cambié el 9 por un 14), rearmé el control.tar.gz y rearmé el .deb con ar -r y traté de instalarlo con dpkg -i nuevamente. para mi sorpresa, dpkg se negó a consumir semejante frankenstein, lo cual se lo entiendo; debe haber encontrado piolines y grampas que usé para cerrar el paquete.

momentáneamente perdido, pregunté en #debian en freenode. allí me mostraron una versión distinta:

12:45 < jelly> StucKman: dunno about ar, but I do with with dpkg: 
    dpkg --extract foo.deb somedir; 
dpkg --control foo.deb somedir/DEBIAN; 
(mess with it); 
dpkg -b somedir .

hice exactamente eso, excepto que en el último comando tuve que agregar el nombre del archivo final. luego nuevamente usé dpkg --dry-run -i, y al confirmar que no se quejó, dpkg -i a secas. una vez instalado, me sercioré que el comando python siguiera apuntando al original (2.5.algo) y que python2.3 arrancara el correcto.

sysadmin python ubuntu

doble-o-nada

2009-01-22T04:24:04Z

recuerdan el upgrade a feisty? bueno, sigue jodiendo. hoy encontramos que algunas máquinas no tenían swap, con los problemas de trashing que eso acarrea cuiando se quedan sin ram. eso no es muy grave. el tema es que otras tenían, por algún motivo que con suerte lograré explicar, montado el mismo espacio de swap dos veces. esto es casi tan catastrófico como tener la ram pinchada: lleva a muertes mistarios s de software al azar y posiblemente corrupciones de sistemas de archivos, etc.

a la caza del bug salí. primero, obvio, me aseguré de que las máquinas que tenían el swap duplicado tuvieran sólo un uso. para eso me fijé con cat /proc/swaps qué swaps estaban activas. la salida típica era:

Filename                                Type            Size    Used    Priority
/dev/sda1                               partition       506008  81184   -1
/dev/mapper/sda1                        partition       506008  0       -2

por suerte una de las copias no se empezaba a llenar hasta que la otra se llenara, y que mis usuarios no comen tanta memoria (y que apenas 2 no tienen 1GiB de RAM en su máquina)

primero quise buscar el problema por mi cuenta, pero los imperantes tiempos (tenía que ir al médico) me hicieron desviarme a lo que tendría que haber hecho de un principio: buscar el bug en launchpad. y allí estaba, un poco escondido en un bug similar, el cual a su vez te lleva a este otro bug. parece no haber solución limpia, así que fui por la solución sucia: volver a /dev/'s en los fstab. no time is no time :(

PD: esto me va a volver a morder al primer upgrade de kelmer.

sysadmin ubuntu

dapper-feisty

2009-01-22T04:24:04Z

en la oficina tengo la suerte de ser el sysadmin (mi título oficial es "[ 浪人 - ronin ]". digo la suerte porque me gusta, y porque todo corre algun linux. en partuicular, las estaciones de trabajo son *buntus. dapper, para ser mas preciso.

el tema es que somos tan grosos que no solo tomamos gente (ya llegamos a los 13 changoas[1]) sino que ademas compramos maquinas nuevas. el tema es que el kelmer de dapper se queda corto, y ya van varias maquinas a las que le tengo que poner algo a medida. which sucks. ademas, vendrian bien un par de versiones mas nuevas de algunas cosas, como el inkscape de nuestra dise#adora.

tons desde ayer martes que estoy en la peque#a tarea de hacer el salto dapper->feisty. gutsy salio hace unas semanas y no me le animo. y feisty ya tiene muchos updates puestos, lo cual lo hace bastante estable.

soy debianero hace ya bastante. desde siempre que use dselect. cuando con *buntu y mas luego nuevos debians comenzo a venir ese mamarracho de aptitude, trate de usarlo. el tema es que si bien el motor de resoluciones de dependencias, conflictos y otras yerbas es mucho mejor, la forma de presentarle las soluciones al usuario suckea mal. he estado al frente de la pantalla una hora mas de una vez analizando las opciones que ofrece aptitude, siempre quedandome con el gusto en la boca de que nunca obtendre la que quiero, y que nunca volvere a encontrar esa que masomenos parecia aceptable. por eso, para este doble salto mortal, decidi hacer uso del viejo y querido dselect. ademas, escuche porai que el update-manager se muere antes de terminar el dist-upgrade por lo menos en los tres ultimos saltos.

la maquina de prueba me pidio bajar 1370MiB, actualizar 1689 paquetes, 378 nuevos (de paso le puse kubuntu-desktop) y sacar 102. entre las cosas grosas esta el cambio en python a python-support, por eso tanto paquete removido (los python2.4-something). y como estaba sacando sysvinit (es reemplazado por upstart), me pide que le confirme con "Yes, do as I say!".

algo que me llama la atencion es que empezaron a pasar pantallas de debconf. espero que sea dselect, y no que el update-manager le responda que si a todo (que de todas formas hace). si puedo, algun dia vere que negradas hace por detras. no fueron muchas (3 o 4) y luego comenzo la danza de los paquetes.

el primero en decir esteupgradenoesmio fue hwdb-client-gnome. quiso pisar un archivo que tambien era de hwdb-client. dselect hizo un parate y despues de un enter se puso a set up los paquetes. muchos se quejaron de que no estaba python-central. wodim (ex cdrecord) cambio de archivo de configuracion. tambien libqt3-mt y kdm.

finalmente fallo. revise que python-central se estuviera por instalar, lo cual era cierto, y le di una segunda vuelta (no es la primera vez que tengo que hacer eso). lo bueno es que empieza donde dejo. ahi fue metacity-common quien quiso pisar a metacity. nuevamente pasamos al setting up. scrollkeeper reconstruyendo la base de datos me dio un tiempito para ir a buscar un feca. initramfs con nuevo archivo de configuracion. hal fixea un bug en sus scripts de udev, pero dbus parece no estar corriendo. /etc/init.d/gdm logra hacer un reload, pero invoke-rc.d cree que no. hwdb-client-common falla porque un .py ya existe.

hacemos una tercera pasada. metacity-common vuelve a fallar por lo mismo. comienzo a ver el primer circulo vicioso. no me asusta el acertijo.

cuarta vuelta. no pasa de metacity-common. veamos que puedo hacer. si lo saco se cae medio gnome (talk about WM independence). el problema es tipico: A, si se upgradea, tiene un archivo C, que tambien tine la version vieja de B, que a su vez depende de A. ergo, B no se actualiza primero porque A aun no, y A tampoco porque pisa C de B. la solucion es hacer dpkg -i a mano sobre los tres (entra en la volteada libmetacity0) y volver a intentar con dselect.

quinta vuelta. still 1128 to go, 254 new, 71 to go away. veo pasar un app-install-data-commercial y un gran WTF?!?! se me dibuja en la cara. "a pretty application installer" me dice apt-cache show. "this package contains the data files for the commercial applications available in gnome-app-install", agrega luego de una pausa. tambien me dice que ubuntu-desktop depende de esa cosa. me tomo una garompa.

mientras la quinta vuelta estuvo laburando tranquila, hasta que kalzium-data y kontact no pueden entrar. no alcanzo a ver porque, asi que la pongo a set up. icecast (quecarajo hace instalado?!?!) tiene un nuevo archivo de configuracion. de fondo lo escucho a perrito poner un tema viejo de sergio denis. la gente cotorrea en el comedor. me voy a comer.

dhcp3-client dice que /etc/dhcp3/dhclient-script fue modificado, pero que ya no esta ahi, sino que ahora esta en /sbin. en el gdm.conf han terminado todas las frases con '.", por lo que leer el diff se hace un poco denso (960 lineas).

y entonces es cuando debconf comienza a usar dialog y soy un poquito mas feliz (soy mas rapido con las fleachsa y el enter que buscando teclas en el teclado), excepto porque el pager que usa para mostrar las diferencias no es less, sino una bonga hecha en dialog.

vuelta 6, 282 still to go, 71 new. mietras esta preconfigurando los paquetes me sale esto: "supported_versions: WARNING: Unknown Ubuntu release: 7.04". parece que entre los archivos de configuracion de los paquetes (de ubuntu?) hay uno que dice qu releases soporta el paquete, y que cuando antiguamente cuando el release era mas nuevo de lo que conocia, tiraba ese warning. o algo asi entiendo de esto.

finalmente temina. por las dudas actualizo el menu.lst del grub (no vi cuando se instalaron los kelmers) y reinicio. . lo que si es relevante es como reacciona aptitude (no dije que lo odio?) a una intromision de tal magnitud por parte de dselect. queriendo instalar lilo resulta que me quiere tirar abajo 84 paquetes. entre ellas cosas como dia, bonobo, gconf, kdevelop3 y otras gansada. como es una maquina de prueba, se van al joraca.

y entonces es cuando el cielo se cae sobre mi cabeza. este fue el motivo por el que termine volando a la mierda el *buntu de mis desktop en casa y volvi a debian: los UUIDs de ubuntu.

# /dev/sda2 -- converted during upgrade to edgy

hago unas cuantas manganetas y logro sacar lilo andando, que bootee del disco y otras yerbas. ahora la prueba de fuego: bootear. arranca. se toma mucho tiempo, en hacerlo, pero lo hace. eso es algo de la configuracion local, que depende mucho del servidor, y justo esta no esta en posicion de accederlo ahora.

y entonces no me da nigun login. el *dm no levanta porque la placa de video no es la que espera que sea (mea culpa, caga culpa) y los logins brillan por su ausencia. recuerdo haber visto una queja del inittab, asique reinicio en single a ver si lo puedo arreglar:

/etc/event.d/tty1:16: Unknown stanza

dado que dicho archivo parece estar relacionado a upstart, decido volver al viejo sysvinit, del que nuca tuve que salir. de paso con dselect me saco tanto soft obsoleto como me es posible (excepto por mplayer y dependencias).

miles de detalles aparte, parece iniciar sin problemas. los text logins han vuelto y arranca rapido. veamos por dentro. reconfiguro el X bien, y ademas pruebo la continudad de aptitude. me marca un monton de paquetes brokenitos, y quiere hacer todo tipo de animaladas, como desisntalar k3b y otras gansadas, pero no lo dejo. al final se queda contento y no hace ningun cambio. no deja de ser una bestia salvaje. instalo xserver-xorg-video-via y soy un poquito mas feliz.

al final el upgrade parece ser posible. el sistema levanta igual de bien que antes, los usuarios siguen tomandose por ldap, nfs anda, los permisos tambien. hasta NetworkManager parece aceptar la configuracion ya puesta y no hace negradas como solia hacer hace un a#o. y todo en poco mas de 4.5 horas. al mismo tiempo estuve probando el live cd de gutsy en una de las maquinas nuevas y parece andar muy bien. reconoce bastante bien las placas de video y audio y andar bien con el acpi, que son los problemas tipicos que tengo con las maquinas nuevas (bueno, tambien me han tocado placas de red, una realtek 8168, y controladoras sata, en placas intel). hablando con mis jefes, vamos a ver por cual nos decidimos.

cosas a tener en cuenta: me olvide por completo de poner la maquina en single mode. esto significa que todos los demonios estaban corriendo, cosa que podria haber hecho mas dificil la operacion. una cosa que si note es que a dselect no le hace ni media gracia que le manden un SIGSTOP. si bien tras un SIGCONT lo continua, luego no puede acceder al teclado, y todo input que requiera del usuario parece no llegarle.

sysadmin ubuntu

[1] esa moda de ser sexualmente neutro (o bi, no me queda claro) al hablar^Wescribir a veces se pega, pero eso de usar @ como en "chang@s" suckea.

nuevo-xkb-en-feisty

2009-01-22T04:24:04Z

como les contaba, el viernes puse feisty en la oficina. algunas cosas no quedaron tan bien, pero la más grave fue que el xkb dejó de andar. el resultado final es que kde no estaba poniendo un layout de teclado como corresponde. esto dejó a un par de usuarios con las teclas mirando al techo, y no podían escribir ni la ñ ni el |, cosa bastante molesta.

con strace descubro que setxkbmap -layout es estaba tratando de leer /etc/X11/xkb/xorg.lst, pero este archivo no existía. si había otras cosas en /etc/X11/xkb, todas a cargo del paquete xkeyboard-settings. usando apt-file descubro que hay un /usr/share/X11/xkb/xorg.lst en xkb-data. claramente la solución es ver si me puedo deshacer del xkeyboard-settings y hacer un par de symlinks.

por suerte xk-s es un dummy desinstalable, así que allá fué. aún quedaban algunas cosas en el directorio "falso", así que lo moví a un .old, hice el symlink, pero el archivo seguía sin existir. sin ganas de ver si el .postinst hacía esta magia o no, probé con un

apt-get install --reinstall xkb-data

et voilá! anduvo sin mas dramas.

sysadmin ubuntu