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

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.

Veto Files y algo más

Evidentemente un requisito que se agregó al final a la compartición fue establecer un espacio de disco limitado por share, aunque se llegó a un compromiso al usar una cuota por grupo y ese grupo para dos shares.

Otro parámetro interesante para manejar qué archivos pueden crearse en un share samba:

veto files = /*.mp3/*.wma/*.avi/*wmv/*.mpg/*.mpeg/*.mov/

el anterior evita que se puedan crear archivos con las extensiones detalladas en los todos shares (hay que ubicarlo en la sección [Global] para ello).

Este otro que borrará cualquier archivo con las extensiones detalladas en “veto files” si es que ya estuvieran en los shares afectados por el “veto files“:

delete veto files = yes

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.

Compartición de archivos

Ok, los requerimientos del sistema fueron:

- una o más carpetas compartidas por grupos de no más de 20 pcs
- que no fueran accesibles desde fuera de su grupo de pcs
- que fueran invisibles dentro del entorno de red
- que no estuvieran en ningun cliente para garantizar siempre su disponibilidad
- que las carpetas cumplieran esos requisitos sin solicitar usuario ni contraseña de ninguna manera.

Al poco tiempo se agregó lo demás:

- que las impresoras compartidas fueran invisibles en el entorno de red
- que las impresoras compartidas pudieran ser configuradas por el usuario limitado desde cada PC que las tuviera instaladas.

y finalmente:

- que los usuarios no pudieran desconfigurar nada de lo anterior
- ni agregar ni quitar directorios compartidos ni impresoras desde cualquier cliente XP excepto con el usuario administrativo.

Prefetch files, revisited

del blog “Windows Incident Response”

I was listening to the latest CyberSpeak podcast (8 Apr) today, and picked up a little tidbit. With regards to those .pf files located in the Prefetch directory on Windows XP, Ovie and Bret stated that the DWORD located at offset 0×90 in the file records the number of times that particular application was launched, with the caveat that this does not apply to those applications autostarted (as via Registry entries). So this will tell you how many times the user launched that application.

Also, the guys said that the 2 DWORDs located at offset 0×78 is the FILETIME object for the time that the application was last launched. This should probably correlate with the last write time on the .pf file itself.

Anyone have any other tidbits like this that can be incorporated into a nice little Perl script?

FortiGate: como recuperar el password y la configuración de fábrica, sin variar la FortiOS

FortiGate de Fortinet es un equipo de cominucaciones que en sus diferente gamas permite a grandes líneas:

- Filtrado de contenido Web
- IPS
- Antivirus

Quizás no es una solución tan robusta como la que conforma en este campo los equipos de Symantec pero es la mejor opción cuando lo realmente crítico es el mantenimiento en todo momento del servicio en cuanto a capacidad de cortocircuitarse en caso de fallo y alta redundancia y en cuanto a capacidad de enrutamiento dinámico en redes complejas.

Pues bien, lo anoto aquí para no olvidarlo: cuando se pierde el password de gestión del equipo o cuando lo que se busca es recuperar la configuración de fabrica de forma rápida hay que conectarse por consola al equipo y poner:

Login: maintainer
Password: secuencia bcpb seguido del número de serie del equipo (casi siempre incluido en la parte de abajo del mismo)

Disfrutando el fin de semana

Jeje, en los países latinos hoy es el segundo día de un fin de semana de 4 (cuatro) días; en fin beneficios (que los hay pocos) del subdesarrollo.

Este sería el primer post de muchos espero. La temática del blog es que me sirva (y posiblemente les sirva también a Uds.) para archivar la información que voy reuniendo en el día a día de mi trabajo como administrador de sistemas (sysadmin).

Voy a intentar llenar este blog de contenido técnico y con algo más, lo que otros bloggers y sys/netadmins del ambiente denominan “la capa humana” en alusión a las capas del modelo OSI.

Tengo un nuevo trabajo donde estoy aplicando gran parte de las habilidades y conocimientos adquiridos en forma privada (sí, autodidacta y educación superior), y que hasta ahora no había tenido oportunidad de demostrar; sin embargo me encuentro con que caí en un ambiente de trabajo lo suficientemente extraño (o no) como para tener que añadir la “capa humana” a las explicaciones técnicas.

En fin, espero que se diviertan tanto como yo.