Instalando SLES9 vía red

Ayer tuve que reinstalar un server de mi datacenter y resulta que cuando instalé originalmente uno de los de su grupo, cargué ahí un repositorio Yast. El repositorio está abierto como un share NFS y cargado con todos los CDs de SLES más serv. pack 1 y 2.

La idea final es prescindir de los cds/dvd de instalación (el DVD hay que armarlo porque la licencia que compramos no incluía DVDs ni manuales, claro…pregunten a los ejecutivos), y poder instalar rápidamente (a velocidad de gigabit) el SLES9, plus serv.pack 2 level.

Lo hice rápido una vez que pude ver el (muy) simple procedimiento de instalación en red en SLES9 del que no pude encontrar ninguna entrada en Google, bah suponiendo que las palabras clave “SLES9 network install” y derivados en un par de idiomas fueran las indicadas para localizar algún tipo de tutorial sobre cómo lanzar efectivamente una instalación en red. En primera instancia lo que obtuve fueron muchas páginas contando cómo se arma un repositorio Yast.

Lo bueno de todo fue que al finalizar pocos minutos después tenía un SLES9 Serv. Pack 2 Level (lo certificó la release-note que se muestra al final de la instalación).

El punto clave para lanzar la ejecución de una instalación remota está en el GRUB del CD/imagen de instalación. En un costado, abajo dice “CDROM-F2″, si durante la selección “Installation” (para empezar a instalar), elegimos “F2″ antes de hacer enter, elegimos el tipo de medio a usar para la instalación. Más tarde, luego de autodetectar y cargar los módulos de la/s placas de red, se nos pregunta por los datos de conectividad de las varias eth’s. Puede usarse DHCP o cargarse una configuración estática típica. A partir de ahí solo queda ingresar la ip o nombre del server de instalación (para que el nombre del server funcione, claro, el DNS tiene que estar bien cargado).

Un tip para los primerizos con estas versiones viejas de Yast: el directorio de instalación remota exportado en el server del repositorio puede ser algo como:

/srv/sles9

sin embargo, al cargarlo generalmente tendrán otro directorio más que tipear hasta tener en el raíz relativo los directorios típicos de la estructura que pueden ver en cualquier CD 1 de instalación.

A partir de ahí con un enter ya se inicia la instalación típica. -

Powered by ScribeFire.

Uninstall files installed from a source code tar-ball

Another one from nixCraft:

Method # 1
(the classic usual)
Use command make uninstall or equivalent supported command, Read INSTALL or README file in source code file to find out more about this method.

# make uninstall

Sure, this method sounds very easy but not supported by all tar balls.

Method # 2
(a) Make a list of all files on the system before installing software i.e. a pre-installation list of all files on your system.
find /* > packgetlist.b4

(b) Now install the software (use configure & make to compile it)
make
make install

(c) Now make a list of all files on the system after installing software i.e. postinstall list
find /* > packagelist.after

(d) Next, compare both lists using the diff utility to find out what files are placing where. This list can be use to uninstall all files installed using source tar ball.
diff packagelist.b4 packagelist.after > package.uninstall.list

(e) After some time if you wish to uninstall files then you need to get list of files from package.uninstall.list file. Use following small for loop at shell prompt to remove all files:
for i in $(grep “>” package.uninstall.list | awk ‘{ print $2 }’)
do
rm -i $i
done

How to extract an RPM package without installing it

From nixCraft

To be frank there is no direct RPM option available via rpm command to extract an RPM file. But there is a small nifty utility available called rpm2cpio. It Extract cpio archive from RPM Package Manager (RPM) package. With the following hack you will be able to extract an RPM file.

So rpm2cpio converts the .rpm file specified as a single argument to a cpio archive on standard out. If a – argument is given, an rpm stream is read from standard in.

Syntax is as follows:
rpm2cpio myrpmfile.rpm
rpm2cpio – < myrpmfile.rpm
rpm2cpio myrpmfile.rpm | cpio -idmv

Example

Download an RPM file:
$ mkdir test
$ cd test
$ wget http://www.cyberciti.biz/files/lighttpd/rhel4-php5-fastcgi/php-5.1.4-1.esp1.x86_64.rpm

Extract RPM file using rpm2cpio and cpio command:
$ rpm2cpio php-5.1.4-1.esp1.x86_64.rpm | cpio -idmv

Output:
/etc/httpd/conf.d/php.conf
./etc/php.d
./etc/php.ini
./usr/bin/php
./usr/bin/php-cgi
./usr/lib64/httpd/modules/libphp5.so
./usr/lib64/php
./usr/lib64/php/modules
….
…..
..
./var/lib/php/session
./var/www/icons/php.gif
19188 blocks

Output of rpm2cpio piped to cpio command (see how to use cpio) with following options:
i: Restore archive
d: Create leading directories where needed
m: Retain previous file modification times when creating files
v: Verbose i.e. display progress

Verify that you have extracted an RPM file in current directory:
$ ls

Output:
etc php-5.1.4-1.esp1.x86_64.rpm usr var

This is useful if you want to extract configuration file or other file w/o installing an RPM file.

Rescate típico: soft compilado “pisa” soft rpm

En un típico problema de server el otro día estuve viendo un CentOS (el server OS recompilado de los src.rpm de RHAT ES 4), que tenía un serio incoveniente: ningun binario dependiente de python funcionaba.

Bien, el problema se dió cuando el sysadmin del server instaló un python compilado a mano SOBRE el python original (el que se instala desde rpm). No me detuve mucho a ver qué había ocurrido y porqué el python compilado (exitosamente al parecer) no respondía bien, aunque presumo algun problema con los PATHs de carga de las librerías y el frecuente problema del linkeo a versiones específicas (la 1-0.8 aunque esté disponible la full-compatible-binaria 1-10).

Hay varias soluciones en este caso, en particular me inclino por el camino elegante de desinstalar el python compilado a mano (make uninstall), teniendo en cuenta que en este caso particular es posible sin ninguna consecuencia; luego lo idea sería forzar la instalación del/los rpms de python que sean necesarios (cuando alguna app diga q falta X o Y librería te entererás de que falta algo todavía!).

Un detalle, el comando rpm (ni hablar de yum) seguramente no va a funcionar antes de que esté en su lugar el viejo python. O sea que lo que hay que hacer es tomar (usando mc o algún cd de recuperación) el contenido del/los rpm de python que hicieran falta y sobreescribir manualmente los binarios y librerías a los directorios que corresponda (puedes ver cuales son en el rpm).

Aclaro que todo este trajín de borrado/copia manual no tendrá ninguna consecuencia sobre tu BD rpm ni tus dependencias ya que todo el tiempo estuviste trabajando con archivos y no alteraste la BD rpm en absoluto.

Este es un típico problema fácil de solucionar, pero que en principio produce pequeños espasmos cardíacos a los sysadmin novatos ya que su “navaja suiza” de reparación de problemas (la “reinstalación a cero” de cualq. paquete o aplicación) desaparece del mapa de soluciones factibles junto con el sist. de adm. de paquetes (YUM) y su subsist. base (RPM).

La idea de esta explicación puede ser fácilmente portada a equivalentes en comandos en Debian y otros Linux con sist. de adm. de paquetes. automatizados.

Herramientas de monitoreo en vivo

Las herramientas de monitoreo “live” nos permiten hechar un vistazo a las tripas de nuestro server/red/algo que necesitemos apreciar desde un punto de vista más informativo y especialmente enfocando sus posibles interrelaciones con otros factores.

El viejo top y netstat son un par de las primeras que se usan cuando un caso como el anterior se presenta, sin embargo la cosecha de herramientas de monitoreo para S.O. tipo *nix es tan variada como variadas son las necesidades de sus usuarios. Los datos que siguen fueron fielmente copiados de Planet Malasya Blog y son un listado bastante bueno de algunas herramientas de monitoreo en vivo no tan conocidas y sus características y utilidad consecuente.

Actualizando de MySQL 4.0 a 5.0 en Debian Unstable

Bien, resulta que estuve instalando desde cero un Joomla! (el CMS), y tenía un viejo Mambo en el server con algunos artículos cargados.

De inmediato no me interesó pasar por el proceso de ver el procedimiento y detalles potencialmente engorrosos de actualizar un (muy viejo) Mambo a Joomla! y elegí instalar desde cero.

Howto: Bonding de placas en SuSe Linux Enterprise

Bien, subo un howto adicional para colocar placas de red en bonding en SuSe Linux Enterprise Server, y debería funcionar igual en cualquier Suse 9.x en adelante.

El procedimiento es más bien lineal, sin ninguna complicación pero deberías tener en cuenta los requerimientos de tus sistemas y ponerlos en relación al esquema de bonding que elijas.

Tapes y Backups en Linux

A continuación el mirror local del artículo de Bulma que da un par de datos interesantes sobre manejo de cintas en Linux y de paso nos mete en Bacula, la solucion de backup por defecto al momento.

HOWTO: integrando Samba con Cuotas de Linux

Intro
Aquí no voy a explicar cómo se configura Samba para crear un share ni como se configuran cuotas de disco en Linux, sí voy a explicar cómo integrar ambos componentes de modo que permitan limitar el espacio en disco usado por shares samba.