Crear un nuevo usuario, que será el que tenga provilegios de root. Lo voy a llamar apagado:

useradd -u 1001 -g 10 -d /export/home/apagado -m -s /usr/bin/ksh apagado

Cambiamos su passwd:

passwd migracion

Comprobamos que se ha creado correctamente

cat /etc/passwd
cat /etc/shadow
ls -al /export/home/apagado

Crear el rol que se asignará al usuario (operaciones) y asignarle un passwd:

roleadd -u 1002 -g 10 -d /export/home/operaciones -m operaciones
passwd migracioncorreo

Comprobamos

cat /etc/passwd
cat /etc/user_attr
(debería estar la siguiente línea al final)
operaciones::::type=role;profiles=All
cat /etc/shadow

Crear el perfil para el rol:

vi /etc/security/prof_attr
(Se añaden las funciones al perfil. Lo siguiente son ejemplos)
Shut:::Able to shutdown the system:
Snoop:::Able to use the snoop command:

Se asignan los comandos al perfil:

vi /etc/security/exec_attr
(Añadimos)
Shut:suser:cmd:::/usr/sbin/shutdown:uid=0
Snoop:suser:cmd:::/usr/sbin/snoop:uid=0

NOTA: Los nombres contenidos en /etc/security/prof_attr y /etc/security/exec_attr deben ser los mismos

Se actualiza el rol:
rolemod -P Shut,Snoop,All operaciones

Comprobamos de nuevo

cat /etc/user_attr
(debería estar la siguiente línea al final)
operaciones::::type=role;profiles=Shut,Snoop,All

Asignar el rol al usuario:
usermod -R operaciones apagado

Comprobamos
cat /etc/user_attr
(debería estar la siguiente línea al final)
operaciones::::type=role;profiles=Shut,Snoop,All
apagado::::type=normal;roles=operaciones

Comprobar que el rol funciona, empleando los comandos que se han asignado.

De todas formas, seguramente será más útil para todo el mundo el empleo de sudo, que suele tener más flexibilidad.

Para cambiar la shell de root, no se debe editar el archivo /etc/passwd, como regla general. En su lugar, crearemos el archivo /.profile y escribimos dentro:

if [ -x /usr/bin/bash ]; then
SHELL=/usr/bin/bash
export SHELL
exec /usr/bin/bash
else
echo /usr/bin/bash not found using default shell of $SHELL
fi

Y ya tenemos todo el poder de bash al logarnos en el sistema. Recordemos que si nuestra preferencia es otra, se puede cambiar por ksh, csh o lo que se desee.

Recordemos, para los que se perdieran la clase, que VMware ofrece dos versiones de su hypervisor de virtualización. ESX, que fué el primero, cuenta con la Service Console para poder acceder a una shell mínima que nos permite una buena cantidad de comandos de control.

En el caso de ESXi esta consola ha desaparecido, en favor de una menor superficie de ataque del sistema. Es un poco latoso para los que estamos acostumbrados a trabajar con la consola por nuestro clienet ssh, pero como VMware ha dicho que a partir de ya mismo, nos vamos a quedar sin Service Console en todos los productos hypervisor, más vale que nos vayamos acostumbrando.

De esta manera, tendremos que emplear las CLI tools, disponibles en la página del proveedor. Procederemos a instalarlas en nuestro PC. Doble click y a correr.

Ya podemos descargar la actualización de ESXi (upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip). O el último disponible.

Lo primero que haremos será poner el host ESX en modo de mantenimiento, habiendo apagado o migrado mediante VMotion todas las máquinas virtuales que se encuentren en el host.

Lanzamos vSphere CLI desde Inicio –> Todos los programas –> VMware –> VMware vSphere CLI –> Command Prompt

Tras abrir la ventana de comandos, ejecutamos cd bin y ya podemos ejecutar la actualización con:

C:\Program Files\VMware\VMware vSphere CLI\bin>vihostupdate.pl -url https://ip.del.host.esx/sdk/webservice -i –bundle “c:\Ruta_del_archivo\upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip”

Enter username: root

Enter password:

Please wait patch installation is in progress …

The update completed successfully, but the system needs to be rebooted for the changes to be effective.

Facilitamos usuario y password y esperaremos a que concluya el proceso, siendo necesario reiniciar el host para que aplique la actualización.

Y ya podemos sacar el ESXi de modo mantenimiento y darle con el látigo para que se ponga a trabajar. So vago

Con el paso del tiempo, la necesidad de realizar el encriptado de las comunicaciones ha llevado a desarrollar una serie de paquetes independientes que implementan el servicio SSH en esta versión de Solaris.

Vamos a ver como podemos instalar un ssh en Solaris 8 sin perder el juicio en el intento.

Los paquetes a instalar pueden descargarse desde el repositorio de sunfreeware y son los siguientes:

openssh-5.8p1-sol8-sparc-local.gz

openssl-1.0.0d-sol8-sparc-local.gz

zlib-1.2.5-sol8-sparc-local.gz

libgcc-3.4.6-sol8-sparc-local.gz

prngd-0.9.25-sol8-sparc-local.gz

egd-0.8-sol8-sparc-local.gz

Se llevarán los parches al servidor (dentro de /var/tmp) y procedemos a instalar los paquetes:

gzip -d *.gz
pkgadd -d .

Asimismo, es necesario actualizar el sistema con un parche editado por Sun que permite al sistema generar números aleatorios, a través de /dev/random, paso imprescindible para la generación de las claves pública y privada. El parche es 112438-03.zip y puede descargarse desde el patchfinder de Sun-QEPD (Ahora desde el soporte de Oracle).

unzip 112438-03.zip
patchadd 112438-03

Para acabar, será necesario regenerar y enlazar los dispositivos random a través de un script que ya ha creado un administrador con más mili que el guerrero del antifaz, de modo que procederé a enlazarlo sin más

chmod 755 setup_random.sh
./setup_random.sh
Checking for patch 112438... installed.
Removing random device from name_to_major
Adding driver to system
Finished. You now have the following random devices:
lrwxrwxrwx 1 root other 33 Sep 26 13:08 /dev/random ->
../devices/pseudo/random@0:random
lrwxrwxrwx 1 root other 34 Sep 26 13:08 /dev/urandom ->
../devices/pseudo/random@0:urandom
crw-r--r-- 1 root sys 266, 0 Sep 26 13:08 /devices/pseudo...
/random@0:random
crw-r--r-- 1 root sys 266, 1 Sep 26 13:08 /devices/pseudo...
 /random@0:urandom

Se responde y a la pregunta

Do you want to test the new device? (y/n) y
Running: dd if=/dev/random of=/tmp/.7003.10738 bs=512 count=1
1+0 records in
1+0 records out
Running: strings /tmp/.7003.10738
You should see a few lines of random garbage:
}LJZ
oK+2;
7rN],R
)k.^/
,(8T
!iXV
NgxLX
qe,g(S
kq gU(%_
PrA|
 *r-$

Se realiza la creación del usuario y el grupo del servicio ssh.

mkdir /var/empty
chown root:sys /var/empty
chmod 755 /var/empty
groupadd sshd
useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

La configuración por defecto se puede mantener. En caso de que se quisiera cambiar algún valor, se encuentra en /etc/ssh/sshd.conf

Ahora será necesario generar las claves públicas y privadas del servidor, para esto:

ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N ""
ssh-keygen -t dsa -f /usr/local/etc/ssh_host_dsa_key -N ""
ssh-keygen -t rsa -f /usr/local/etc/ssh_host_rsa_key -N ""

Ya podemos crear el script de arranque y parada. Se arrancará el servicio durante el runlevel 2

vi /etc/init.d/sshd
case "$1" in
'start')
 if [ -x /usr/local/sbin/sshd ]; then
 echo "Starting the secure shell daemon"
 /usr/local/sbin/sshd &
 fi
 ;;

'stop')
 echo "Stopping the secure shell daemon "
 pkill -TERM sshd
 ;;
*)
 echo "Usage: /etc/init.d/sshd { start | stop }"
 ;;
esac
 exit 0

Se enlaza el script para que arranque el servicio automáticamente.

chown root /etc/init.d/sshd
chgrp sys /etc/init.d/sshd
chmod 555 /etc/init.d/sshd
 ln -s /etc/init.d/sshd /etc/rc2.d/S98sshd

Ya podemos arrancar el proceso

/etc/rc2.d/S98sshd start

y comprobar su correcto funcionamiento

ps -e | grep sshd
 root  2294 22159  1 16:31:35 ?        0:00 /usr/local/sbin/sshd -R
 root  2160 22159  0 16:30:00 ?        0:00 /usr/local/sbin/sshd -R
 root  2332  2326  0 16:31:49 pts/4    0:00 grep sshd
 root 22159     1  0   Apr 04 ?        0:24 /usr/local/sbin/sshd

Con esto está terminado, ya podemos conectarnos a nuestro Solaris 8 de forma remota y segura. Como debe de ser

Vamos a ver cómo sincronizar nuestros hosts Solaris con un servidor externo. Procedimiento sencillo donde los haya.

Como primer paso, procedemos a la creación del fichero de configuración desde plantilla

cp /etc/inet/ntp.client /etc/inet/ntp.conf

Lo editamos en nuestro programa favorito y comentamos la línea relativa al multicast, para después añadir el servidor contra el que vamos a sincronizar. En este caso es una fuente externa, como es el del Real Observatorio de la Armada, pero podríamos hacerle acudir a un servidor NTP interno que ya tuviéramos configurado.

#multicastclient 224.0.1.1
server hora.roa.es

Tras ello, solo hay que reiniciar el servicio. Bajo Solaris 8 y 9

/etc/init.d/xntpd stop
/etc/init.d/xntpd start

Y bajo Solaris 10

svcadm disable ntp
svcadm enable ntp

Y ya se puede comprobar que la hora se está replicando correctamente

# ntpq -p
     remote      refid      st t when poll reach   delay   offset  jitter
==============================================================================
*hora.roa.es     .GPS.       1 u  420  512  377   42.158    1.858   2.464

Lo primero que se intenta en estos casos es desconectar el ESX como paso previo a volver a conectarlo. Sin embargo, al realizar la operativa, el trabajo no llegaba a completarse nunca. Sad panda
Afortunadamente, siempre tenemos la posibilidad de conectarnos por ssh al ESX y comprobar en qué estado se encuentran los procesos que controlan vmware

[root@esx4 root]# service mgmt-vmware status
vmware-hostd (pid 1804) is running...

¿Funcionando dices?. Yo no me fiaría mucho. Vamos a reiniciarlo, a ver como respira:

[root@esx4 root]# service mgmt-vmware restart
Stopping VMware ESX Server Management services:
   VMware ESX Server Host Agent Watchdog                   [  OK  ]
   VMware ESX Server Host Agent                            [  OK  ]
Starting VMware ESX Server Management services:
   VMware ESX Server Host Agent (background)               [  OK  ]
   Availability report startup (background)                [  OK  ]

Tras esto, se completa el proceso de desconexión, ya podemos volver a unir el host al virtual center sin mayor problema.

[...]

Jan 11 09:43:28 Madhatter ndo2db: mysql_error: ‘Incorrect information in file: ‘./centstatus/nagios_timedeventqueue.frm”

Jan 11 09:43:28 Madhatter ndo2db: Error: mysql_query() failed for ‘INSERT INTO nagios_servicestatus SET instance_id=’0′, service_object_id=’0′, status_update_time=FROM_UNIXTIME(1294735408), output=’Used: 45 MB \(4%\) Free: 905 MB \(95%\)’, long_output=”, perfdata=”, current_state=’0′,has_been_checked=’1′, should_be_scheduled=’1′, current_check_attempt=’1′, max_check_attempts=’5′, last_check=FROM_UNIXTIME(1294706008), next_check=FROM_UNIXTIME(1294706647), check_type=’0′, last_state_change=FROM_UNIXTIME(1294409964), last_hard_state_change=FROM_UNIXTIME(1294409964),last_hard_state=’0′, last_time_ok=FROM_UNIXTIME(1294706008), last_time_warning=FROM_UNIXTIME(0), last_time_unknown=FROM_UNIXTIME(0), last_time_critical=FROM_UNIXTIME(0), state_type=’1′, last_notification=FROM_UNIXTIME(0), next_notification=FROM_UNIXTIME(0), no_more_notifications=’0′, notifications_enabled=’1′, problem_has_been_acknowledged=’0′, acknowledgement_type=’0′, current_notification_number=’0′,passive_checks_enabled=’0′, active_checks_enabled

Jan 11 09:43:28 Madhatter ndo2db: mysql_error: ‘Incorrect information in file: ’./centstatus/nagios_servicestatus.frm”

Jan 11 09:43:28 Madhatter ndo2db: Error: mysql_query() failed for ‘INSERT INtO nagios_customvariablestatus SET instance_id=’0′, object_id=’0′,status_update_time=FROM_UNIXTIME(1294735408), has_been_modified=’0′, varname=’SERVICE_ID’, varvalue=’642′ ON DUPLICATE KEY UPDATE instance_id=’0′,object_id=’0′,status_update_time=FROM_UNIXTIME(1294735408), has_been_modified=’0′, varname=’SERVICE_ID’, varvalue=’642”

[...]

El propio MySQL también se quejaba de que le apretaba el zapato:

[...]

110112  1:01:33 [ERROR] /usr/libexec/mysqld: Table ‘./centstorage/log_archive_host’ is marked as crashed and should be repaired

110112  1:01:33 [ERROR] /usr/libexec/mysqld: Table ‘./centstorage/log_archive_host’ is marked as crashed and should be repaired

110112  1:01:33 [ERROR] /usr/libexec/mysqld: Table ‘./centstorage/log_archive_host’ is marked as crashed and should be repaired [...]

Lo primero que le pasa a uno por la cabeza es que la tabla está en un estado inconsistente y que ya podemos tirar de backup, pero la realidad es bien distinta, ya que este poco amigable error puede deberse a una de estas tres cosas:

• Si se han estado haciendo cambios en my.cnf sin parar el servicio, va a ser necesario borrar los ficheros ib_logfile* que se encuentran dentro del directorio de MySQL (Haciendo backup antes, como siempre) y posteriormente reiniciar MySQL. Mano de santo.
• En caso de que se esté usando innodb, comprobar dentro de my.cnf si esta variable está exactamente así: innodb_data_file_path = ibdata1:10M:autoextend
• Problemas en /tmp: Bien porque se haya borrado accidentalmente o no tenga los permisos adecuados. En caso contrario, crearlo y asignarle permisos 1777 curará todos nuestros males.

Y es que hay ocasiones en que parece que los mensajes de error los crea nuestro peor enemigo.

Las actualizaciones son el pan nuestro de cada día en esta casa de locos que es la administración de sistemas y, por supuesto, muy necesarias si queremos que todo funcione más o menos bien. Hoy vamos a ver como actualizar de versión los hosts ESX o ESXi empleando la servcie console.
El fichero de actualización (En este caso es para ESX 3.5 de update 2 a update 5 (La última versión disponible), pero puede darse a cualquier otra versión) debe ser copiado a la Service COnsole del ESX y descomprimido en un directorio independiente (A mí me va bien /var/tmp pero cada cual tiene sus manías)
Tras descomprimirlo y navegar hasta el hemos de poner el host ESX en modo de mantenimiento, esto se puede realizar desde la consola de Virtual Center o empleando como root el comando

# vimsh -n -e /hostsvc/maintenance_mode_enter

Tras ello, ya podemos realizar el upgrade

# esxupdate update

El solito se encargará de realizar la descarga e instalación necesaria y, si somos muy, muy buenos, hasta rebotará el host al acabar:

INFO: | Transaction(s) Complete
INFO: Running esxcfg-pciid to update the PCI ID tables...
INFO: Running esxcfg-boot to regenerate initrds...
INFO: --- TOTALS: 77 packages installed, 0 pending or failed, 0 removed, 0 excluded ---
INFO: Install succeeded - please standby for reboot.INFO: Rebooting in 5 seconds...
Broadcast message from root (pts/1) (Fri Dec 17 10:54:18 2010):
The system is going down for reboot NOW!

En todo caso, si no hay un reboot atomático, siempre se puede hacer a mano. Cuando obtengamos de nuevo acceso, ya podremos sacar el host de modo mantenimiento y comprobar que todo ha funcionado correctamente:

# vimsh -n -e /hostsvc/maintenance_mode_exit

Aprovecharemos las tribulaciones de parte del equipo de Sybase para comentar un par de trucos sobre puertos y procesos, que es algo que viste mucho y resulta muy útil y facil.

Supongamos una situación más que típica. Una instancia de base de datos ha dado un error y se está intentando parar. Como el error ha dejado un montón de procesos colgando de un puerto, no se puede parar hasta que se eliminen uno a uno. Pero ¿cuales son esos procesos?.

Partamos de la base de que conocemos cual es el puerto de la aplicación. No me digan que o lo saben, porque cualquier administrador de bases de datos digno de su nombre deberia conocer ese dato. Hombre ya.

Emplearemos lsof para ver qué está escuchando por ahí

root@madhatter # lsof |grep -i esta|grep 2640
dataserve 15366   sybase   51u  IPv4 0x513f9aec060  0t0  TCP madhatter-ce0:45880->madhatter-ce0:2640 (ESTABLISHED)

Bueno, pues podemos ver que se trata de una instancia Sybase lanzada con un par de dataservers por debajo.

En fin, vamos al meollo de la cuestión, averiguar cuales son todos los procesos que están escuchando. Filtremos un poco las opciones de lsof, buscando un puerto concreto y un estado concreto: LISTEN. En caso necesario, también se podría buscar procesos vinculados a un puerto buscando por BOUND.

root@madhatter # lsof -i | egrep LISTEN|grep 2640
aocarga_S  5770   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  6742   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  7303   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  7982   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  9387   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S  9574   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 10571   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12052   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12063   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12066   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12070   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12071   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12074   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12075   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12078   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12080   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12084   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
sleep     12085   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 16192   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 20088   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     22710   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 22714   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
aocarga_S 22715   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     22768   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     27050   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)
fcunw     27372   root  101u  IPv4 0x3079c7fa4b8   0t0  TCP *:2640 (LISTEN)

Quizás deberíamos hablar un día del fascinante mundo de los puertos…

Y como gran final, lo unimos todo en una línea gracias a la magia de UNIX

root@madhatter # lsof -i | egrep LISTEN|grep 2640 |nawk ' {print $2}'

Caballeros, ya pueden empezar a mandar kills a estos procesos para que mueran ordenadamente. Ar!.

Esta es una máxima bastante extendida en el proceloso mundo de la administración de máquinas. Las copia de seguridad son una lata, pero en caso de desastre nos salvan la vida. Literalmente.

Existen cantidad de métodos para realizar una buena política de salvados. Hoy vamos a dedicarle un pequeño espacio de tiempo a una de las más comunes. Ufsdump y Ufsrestores en combinación con nuestras aliadas. Las unidades de cinta.

Es importante conocer qué es lo que queremos salvar. mi experiencia me dice que no es necesario realizar un backup completo de una máquina, sino determinadas piezas de información contenida en ella. Por ejemplo, /var /opt /export/home /oracle, etc…

Conviene determinar claramente cuales son los ficheros y configuraciones impresccindibles y guardarlo a buen recaudo. Un apache se puede instalar desde cero en caso necesario, pero la configuración de cada servidor y el contenido de las páginas son temas más peliagudos.

Por otra parte, no tendremos que copiarlo todo todos los días. Hay archivos y directorios que no sufren variaciones en su contenido, mientras que otros van teniendo información nueva cada día, como una tabla de una base de datos.

Normalmente, hay dos tipos de backup:

• Completo: A realizar el primer día en que hacemos backup
• Incremental: A realizar en los días subsiguientes, y que incluirá únicamente los archivos que hayan sido modificados.

Por último, un pequeño procedimiento para copiado de filesystem completos a cinta. Solo para sus ojos…

Se copian los archivos a la cinta mediante ufsdump completo. En este caso, se realizaría un ufsdump por cada filesystem independiente.

# ufsdump 0uf /dev/rmt/numero_de_cinta /filesyetem

Ejemplos:

# ufsdump 0uf /dev/rmt/0 /
# ufsdump 0uf /dev/rmt/0 /var
# ufsdump 0uf /dev/rmt/0 /export/home

… etc

Si el salvado que deseamos hacer es incremental, hay que prestar atencion al dump level, que es un valor desde 0 a 9, y establece los ficheros que se van a a copiar que hayan sido modificados desde el último backup realizado a un nivel de dump inferior. Por ejemplo: Si el lunes hemos realizado un dump a nivel 2, y el martes hacemos un dump a nivel 4, en caso de que hagamos un dump a nivel 3 el miércoles copiaría asimismo todos los ficheros modificados o añadidos al sistema desde el backup del lunes.

Hay diferentes combinaciones, pero la que encuentro más adecuada es el llamado modelo de Torres de Hanoi y que viene a ser:

L: Nivel 3 M: Nivel 2 X: Nivel 5 J: Nivel 4 V: Nivel 7 S: Nivel 6 D: Nivel 0

En caso de que se quiera restaurar en un punto fijo, el comando sería:

Desde un directorio creado para contener los FS copiados (Ej: /var/tmp/restauracion)

# ufsrestore rvf /dev/rmt/numero_de_cinta ./filesyetem

Ejemplos:

# ufsrestore rvf /dev/rmt/0 ./
# ufsrestore rvf /dev/rmt/0 ./var
# ufsrestore rvf /dev/rmt/0 ./export/home

Recuerden que estas cintas han de guardarse como oro en paño. En caso de que se destruyan o deterioren, es mucho trabajo tirado a la basura

Si quieren mayor información, lo cual es muy inteligente ya que estas breve pinceladas apenas explican nada, les recomiendo el muy chulo (y divertido) manual Backup & Recovery de W. Preston publicado por O’Reilly.