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.

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.

9 modos de prevenir el espionaje industrial

Copia del original por motivos de consulta.
by Calum Macleod – European Director of Cyber-Ark – Wednesday, 2 August 2006.

If we‘re honest every one of us imagine what we’d do with a few million in the bank. The yacht in Cannes, the private jet in Nice, possibly our own football team, and maybe a few other high maintenance accessories top our list of must-haves. But of course the question is how to get there. Working till I’m too old to enjoy it is one option but of course there is an alternative; the lottery, online poker, a rich widow, stocks and shares – increasingly risky these days – or why not simply help myself to something very valuable.

Por qué Windows es más inseguro que Linux

Del post de zdnet:

“Windows is inherently harder to secure than Linux. There I said it. The simple truth.
Many millions of words have been written and said on this topic. I have a couple of pictures. The basic argument goes like this. In its long evolution, Windows has grown so complicated that it is harder to secure. Well these images make the point very well. Both images are a complete map of the system calls that occur when a web server serves up a single page of html with a single picture. The same page and picture. A system call is an opportunity to address memory. A hacker investigates each memory access to see if it is vulnerable to a buffer overflow attack. The developer must do QA on each of these entry points. The more system calls, the greater potential for vulnerability, the more effort needed to create secure applications.

The first picture is of the system calls that occur on a Linux server running Apache; the second image is of a Windows Server running IIS.

Thanks to Sana Security for generating and providing these images.”

Linux server running Apache

Windows server running IIS

Seguridad auspiciada

Hace poco tuve una reunión y fue al propósito de la visita de un experto en seguridad y redes contratado por la consultora que lleva adelante un proyecto en mi empresa. En cierto momento de la charla, el especialista recomendó ubicar equipos de diferente marca dentro del esquema de firewalls internos/externos para reducir la posibilidad de múltiples riesgos asociados al uso de equipos de la misma marca.

Monitoreo

Estuve probando las herramientas de monitoreo “Monit” y “Munin”, muy buenas. La implementación es bastante simple en ambos casos, aunque la seguridad de Monit depende directamente de la aplicación misma (en un puerto a designar, por defecto el 2812); en el caso de Munin, la seguridad se establece directamente desde el server web (Apache, .htaccess y .htpasswd) lo que lo hace un poco mejor. En particular Munin destaca en cuanto que la información de los nodos a monitorear pueden ir a través de un tunel SSL (stunnel), lo que hace factible su implementación fuera de la DMZ, e incluso – con ciertas reservas según el tipo de server – a través de Internet.

Estructura de disco del server

El particionamiento del server es una cuestión clave en cuanto a la futura aplicación y escalabilidad del sistema operativo. En particular se suele usar un esquema simple basado a pleno en la vieja escuela *nix de múltiples particiones asociadas a los directorios funcionales del árbol root (/), por ejemplo:
/
/home
/var
/tmp

,etc.

En SLES se puede hablar de dos más:

/opt
/srv

La idea es que /opt contiene los archivos de la GUI (KDE y Yast) y /srv contendría los archivos cuasi-estáticos de los server (configuraciones, y archivos estáticos: scripts, html estándar, etc.).

En cuanto a /srv sé que muchas distros en sus últimas versiones están implementando el directorio en sus esquemas de particionamiento “para servers” aunque el uso que le dan las aplicaciones instaladas es más o menos aleatorio: casi ningun paquete suele estar armado para trabajar con /srv….seguir viendo eso.

Tapes, placa raid scsi add-on y el bus scsi

El otro día tuvimos un problema con las unidades de cinta conectadas a los servers y aparentemente el problema se habría dado por un mal esquema de conexionado scsi. Es posible que el proveedor haya conectado las unidades en cada server previamente a instalar la placa raid add-on opcional adquirida.

En el canal primario estaría “enganchada” la placa raid scsi add-on, por eso al estar “ambos conectados” (la cinta físicamente y la placa raid lógicamente) en el primer canal, ello hacía que la unidad de cinta no fuese “vista” por el hardware, aunque el software sí la detectaba (dentro de SLES), jeje

La cuestión se solucionó conectando la unidad de cinta al canal secundario scsi de la placa madre.

Al final había más de un modo de solucionar el problema, pero el otro modo incluía el uso de un terminador y como no había 3 a mano, se pasó al anterior