digilux.es

Hoy vamos a ver como se realiza el mirror del vg00 en un HP-UX bajo itanium. Esta operación consiste en particionar el disco, copiar los ficheros de la EFI, añadir una partición del disco al vg00, crear mirror a nivel LVM de cada lvol y establecer las distintas areas de swap, dump etc… . De tal manera que si un disco fallara, tendríamos alta disponibilidad por lo que se podría reemplazar el disco dañado por otro nuevo y reconstruir el mirror, además de poder realizar un split del vg para realizar una intervención garantizando la marcha atrás.

Para llevar a cabo el mirror a parte de requisito imprescindible tener dos discos (da igual si son locales o de SAN) también hace falta tener licenciado el Mirrordisk/UX, vamos a chequearlo:

#swlist | grep -i mirrordisk
B2491BA B.11.23 MirrorDisk/UX (Server)

Es de vital importancia que reconozcamos sin lugar a errores el disco del sistema operativo y cual va a ser el disco de mirror. En el ejemplo que vamos a ver a continuación tenemos el disco c0t6d0 en el cual está instalado el sistema operativo y el disco c28t5d0 que está vacio sobre el que haremos el mirror.

Una vez tenemos claros los discos a usar, tenemos que particionar el disco que está vacio, haremos tres particiones en el siguiente orden: EFI, sistema operativo y HPSP.

1. En la primera partición (s1) de 500MB irá la EFI la cual es la implementación moderna de la BIOS sobre máquinas itanium aunque hace tiempo que ha dejado de estar presente en exclusiva en servidores y se usa también en algunos ordenadores domésticos como por ejemplo en toda la gama de macs basados en intel.
2. En la segunda partición (s2) que ocupará todo lo que quede libre entre la primera y tercera partición en la cual irá el sistema operativo.
3. Y como tercera partición (s3) de 400MB la HPSP (HP Service Partition) que estará destinada a instalar unas herramientas de diagnóstico hardware offline.

Una vez tenemos claro la distribución de las particiones y que albergaremos en cada una de ellas, vamos a particionar nuestro disco,. Para ello creamos un fichero temporal en el cual indicaremos dicha tristribución de la siguiente manera: Read more…

Comprendiendo el funcionamiento de los grupos protegidos del directorio Activo. Como son y como funcionan: Propagador SD, FixUpInheritance, AdminSDHolder, SDPRO, AdminSDProtectFrequency, Problemas con la delegación de privilegios en Active Directory

Si has llegado hasta este artículo, probablemente tengas algún tipo de noción de directorio activo, y es probable que, lo que aquí contemos, lo sepas o por lo menos lo intuyas.

Tras varios años dando soporte a infraestructuras de directorio activo, han aparecido en varias ocasiones problemas relacionados con los grupos protegidos. Por lo tanto, la pregunta, a priori, es muy sencilla… ¿Porqué se elimina lo que configuro en las ACL’s de ciertos objetos del directorio, si he asignado que reciban los privilegios por herencia? según aclaremos conceptos iremos complicando el escenario para entender el alcance de todos estos conceptos y como se combinan unos con otros.

¿Qué son los grupos protegidos del directorio activo?

Los grupos protegidos del directorio activo son aquellos grupos sensibles de tener delegados ciertos privilegios especiales, y por tanto sus miembros no están sujetos a las mismas normas que otros usuarios. Mas adelante veremos el detalle de cuales son

¿Qué efectos tiene la membresía a grupos protegidos del directorio activo?

Cuando un objeto del AD pertenece a un grupo protegido, este objeto recibirá cada vez que ocurra una propagación SD (por defecto cada 60 minutos) la herencia de las entradas ACL’s de seguridad explícitamente indicadas en la ACL de AdminSDHolder

Clarito, verdad? Volvamos hacia atrás.

¿Qué es una propagación SD, SD Propagador?
Read more…

Tras una alarma de alta ocupación en el /var descubro que hay muchísimo mensajes encolados:

# ls -la /var/spool/mqueue/  | wc -l
62855

Al mirar cualquiera de los correos encolados, aparece el siguiente error:

Deferred: local mailer (/usr/bin/rmail) exited with EX_TEMPFAIL

Revisamos los permisos del /var/mail:

# ls -lad /var/mail
drwxrwxr-x   2 bin     mail          8192 Jun 23 13:09 /var/mail

Tras hacer una prueba y cambiar los permisos de /var/mail a root:bin empieza a descender la cantidad de correos encolados. Es importante que los permisos sean 775:

# chown root:mail /var/mail
# ls -lad /var/mail
drwxrwxr-x   2 root       mail          8192 Jun 23 13:09 /var/mail
# ls -la /var/spool/mqueue/  | wc -l
36425

Unos minutos después, no quedaban correos encolados.

Se va a hacer de rogar el post de CPU Costing de Ricardo, pero es que tengo un pequeño detalle que intenté dejarle a un comentario a Tanel Poder del post que puso hace unos días, pero al final no pude. Así que primero, incentivarlos leer el blog de Tanel Poder que me parece genial, y decirles que allí hay un buen post sobre los errores 4031 y de la shared pool y los sub-pools en:

ORA-04031 errors and monitoring shared pool subpool memory utilization with sgastatx.sql

El caso es que se habla de una sub-pool 0, y que es memoria que no se le da al resto de las sub-pools de la shared pool. Bueno solo añadir que este espacio de memoria que describe Tanel en su blog no existe cuando está desactivado el manejo automático de memoria conocido como ASMM (Automatic Shared Memory Management), que pasa cuando tienes el parámetro SGA_TARGET a 0 ó el parametro STATISTICS_LEVEL en “BASIC”. Realicé una pequeña prueba y este fue el resultado:
Read more…

Buenas de nuevo, escribo algo muy sencillo, pero que he visto que está extendido en varias bases de datos que he tocado. Lo llamaré “El gran misterio log_buffer”. Y es que he visto en más de una ocasión que el valor de este parámetro está puesto a 10M y hasta 32M. Y me pregunto ¿Por qué y para qué?
Read more…

Supongamos que tenemos un sistema con muchas impresoras y tenemos que replicarlas a una nueva máquina. Vamos a ver un método sencillo y seguro para llevar esta tarea a cabo.

La manera de hacerlo es mediante lpmgr, con la opción “-S” exportamos la configuración en el destino que le indiquemos mediante “-xsavedir=/path/destino” y si usamos la opción “-R” restauraremos la configuración. Veamos un ejemplo.

Lo primero de todo es exportar las impresoras en el sistema de origen:

/usr/sam/lbin/lpmgr -S -v -xsavedir=/var/sam/lp/
tar -cvf printers.tar /var/sam/lp

Ahora nos llevamos el fichero printers.tar a la máquina de destino, lo desempaquetamos y lo importamos parando previamente el scheduler para finalmente dejarlo arrancado:

lpshut
tar -xvf printers.tar
/usr/sam/lbin/lpmgr -R -xsavedir=/var/sam/lp/
lpsched -v

Esto mismo se puede hacer mediante SAM el cual recomiendo no usar a no ser que sea absolutamente necesario.