martes, 30 de septiembre de 2014

Volvemos a la carga

Hola a todos,
este es un post de intenciones para el curso 2014-2015.
Voy a intentar publicar más a menudo cosas en este blog.
Me planteo los siguientes temas: 
  • Un monográfico sobre administración de sistemas  (que es, funciones, evolución ...). No se como lo enfocaria pero supongo que lo dividiria en diversos post.
  • Trucos, cosas que me suceden y recetas a problemas que me pasan en el trabajo.
  • Otro monográfico de como solucionar problemas, incidencias ( vamos pollos). Como afrontar estos para internar llegar a un diagnostico y/o una solucion. Vamos a lo que me dedico últimamente.
  • Opinión sobre temas de tecnología.
También estoy dispuesto ha escribir un post sobre cualquier cosa que queráis sobre GNU/Linux.
Escribir en los comentarios sobre los temas que esteis interesados que escriba.

Saludos y sed todo lo felices que podais ser.

Quitos

martes, 19 de noviembre de 2013

Eliminar un disco en linux ¿como identifico el disco?

Un compañero de trabajo que necesitaba eliminar unos discos de cabina que le habían eliminado los de storage sin avisarle (por suerte eran unos discos que no estaba utilizando),  teniendo en cuenta que lo único que pasa es que en /var/log/messages salen errores más estéticos que otra cosa y que en el siguiente reinicio se limpiara, pero el queria eliminarlos, pos nada repasando mis chuletas le indico que lo tiene que eliminar con la siguiente chuleta:


echo "scsi remove-single-device a b c d" > /proc/scsi/scsi

  donde

             a == host-adapter id
             b == SCSI channel on host-adapter
             c == ID
             d == LUN
  Esto lo podeis mirar con un lssd o lssg

Vale perfecto pero .... el lssd/lssg son herramientas del paquete hp-fiberutils ..... y esto es una maquina virtual primer fail. Joer que hacemos?
Siguiente comando, este más generico, lsscsi:

servhost:~# lsscsi
[0:0:1:0]    disk    ATA      ST31000524AS     JC4B  /dev/sda
[2:0:0:0]    disk    ATA      ST3320613AS      SD22  /dev/sdb
[3:0:0:0]    disk    ATA      ST31000524AS     JC4B  /dev/sdc
[4:0:0:0]    cd/dvd  PIONEER  DVD-RW  DVR-115D 1.13  /dev/sr0


Bueno, pero resulta que no lo esta instalado en este Red Hat, ademas que no esta conectado ni a la Red hat network ni a un satellite, de donde sacamos el paquete lsscsi?, pues busquemos alternativas que seguro que hay, objetivo el /dev y el /sys. Encontramos lo siguiente:

servhost:~# ls -l /dev/disk/by-path/
total 0
lrwxrwxrwx 1 root root  9 nov  3 19:49 pci-0000:00:1f.2-scsi-0:0:1:0 -> ../../sda
lrwxrwxrwx 1 root root 10 nov  3 19:50 pci-0000:00:1f.2-scsi-0:0:1:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 nov  3 19:49 pci-0000:00:1f.5-scsi-0:0:0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 nov  3 19:52 pci-0000:00:1f.5-scsi-0:0:0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 nov  3 19:49 pci-0000:00:1f.5-scsi-0:0:0:0-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 nov  3 19:49 pci-0000:00:1f.5-scsi-0:0:0:0-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 nov  3 19:49 pci-0000:00:1f.5-scsi-0:0:0:0-part4 -> ../../sdb4
lrwxrwxrwx 1 root root 10 nov  3 19:50 pci-0000:00:1f.5-scsi-0:0:0:0-part5 -> ../../sdb5
lrwxrwxrwx 1 root root 10 nov  3 19:50 pci-0000:00:1f.5-scsi-0:0:0:0-part6 -> ../../sdb6
lrwxrwxrwx 1 root root 10 nov  3 19:50 pci-0000:00:1f.5-scsi-0:0:0:0-part7 -> ../../sdb7
lrwxrwxrwx 1 root root  9 nov  3 19:49 pci-0000:00:1f.5-scsi-1:0:0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 nov  3 19:50 pci-0000:00:1f.5-scsi-1:0:0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root  9 nov  3 19:49 pci-0000:02:00.1-scsi-0:0:0:0 -> ../../sr0

OOOOOOOOOOOOOOOOOOOO

servhost:~# find /sys/devices -name "*block*" | grep -e "sd"
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/queue/logical_block_size
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0/block/sda/queue/physical_block_size
/sys/devices/pci0000:00/0000:00:1f.5/host2/target2:0:0/2:0:0:0/block/sdb/queue/logical_block_size
/sys/devices/pci0000:00/0000:00:1f.5/host2/target2:0:0/2:0:0:0/block/sdb/queue/physical_block_size
/sys/devices/pci0000:00/0000:00:1f.5/host3/target3:0:0/3:0:0:0/block/sdc/queue/logical_block_size
/sys/devices/pci0000:00/0000:00:1f.5/host3/target3:0:0/3:0:0:0/block/sdc/queue/physical_block_size


O ya lo tenemos!!!!

Lo dejo como chuleta definitiva!!!

Espero que le sirva a alguien de ayuda.

Saludos y sed todo lo felices que podáis ser.

Quitos.

viernes, 15 de noviembre de 2013

Gestion de servicios/scripts de inicio en debian

A raiz de querer deshabilitar el servicio de dhcp de mi "servidor" casero me he puesto a revisar el uso del update-rc.d, pero resulta que tenia un comportamiento extraño.
Bucenado por la web encuentro que la gestion a partir de debian 6.0 se realiza mediante el comando insserv  . Ademas revisando la documentación los scripts de inicio (vamos los que ponemos en le /etc/init.d/) han cambiado para que sigan la definición LSB 3.1 (Linux standard Base). 

Ahora para habilitar un servicio tenemos lo haremos con el comando insserv:

Habilitando el servicio, dejara el servicio de forma default

# insserv <servicio> 

Deshabilitando/eliminado el servicio (elimina los links de /etc/rc*./):

# insserv -r <servicio> 

Para determinar los runlevels y el numero de orden que tiene que seguir esta en el script de inicio del servicio situado en el /etc/init.d/servicio ahora el archivo que añadamos aqui tiene que tener la siguiente cabecera:

### BEGIN INIT INFO
# Provides:          <servicio>
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Should-Start:      $local_fs slapd $named
# Should-Stop:       $local_fs slapd
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Descripcion corta del servicio
# Description:       Descripcion del servicio
### END INIT INFO


Estos campos  indican lo siguiente:

### BEGIN INIT INFO -> Cabecera de inicio de la información del script de inicio
# Provides:          <servicio>  
-> Indica el servicio que se provee 

# Required-Start:    $remote_fs $network $syslog -> Servicios que tienen que estar arrancados antes de arrancar este servicio
# Required-Stop:     $remote_fs $network $syslog -> Servicios que tienen que estar arrancados antes de parar este servicio
# Should-Start:      $local_fs slapd $named ->(opcional) Servicios que si estan presentes tendrian que estar arrancados antes de arrancar este servicio 
# Should-Stop:       $local_fs slapd ->(opcional) Servicios que si estan presentes tendrian que estar arrancados antes de arrancar este servicio
# Default-Start:     2 3 4 5 -> Runlevels donde se arranca el servicio
# Default-Stop:      0 1 6 -> Runlevels donde se para el servicio
# Short-Description: Descripcion corta del servicio
# Description:       Descripcion del servicio
### END INIT INFO

Los servicios o "facilities" de los campos Require-start/stop y Should-start/stop son o nombres de servicios (por ejemplo sshd) del arranque o servicios definidos por el entandar LSB que vienen precedidos por $,  estos son los siguientes:

$local_fs     :todos los filesystems locales estan montadosall local file systems are mounted
$network      :el soporte de red esta disponible. basic networking support is available. Example: a server program could listen on a socket.
$named        :Els servicio de DNS esta disponible.
$portmap      :Los servicios que proveen SunRPC/ONCRPC portmapping estan arrancados
$remote_fs    :Los filesystems remotos estan montados.
$syslog       :el servicio de syslog esta arrancado
$time         :el reloj se ha puesto en hora
$all          :indica que se arranca despues de todos los demas servicios o que requiere todos los servicios para poder pararse

Con esto conseguiremos que el sistema arranque correctamente todos los servicios, sin tener que preocuparnos nosotros por crear los links simbolicos ni revisar el orden en que arranca o para un servicio, el con la definición que hemos realizado los creara en el orden correcto.

Espero que le sirva a alguien de ayuda.

Saludos y sed todo lo felices que podáis ser.

Quitos.

martes, 14 de septiembre de 2010

Semaphores exhausted

Bueno, hoy voy a poner una pequeña chuleta tanto para revisar los semáforos o aumentar estos en un linux.
Un poco de información, simplificando un poco (o mucho), un semaforo es una variable que se utiliza para gestionar el bloqueo de un recurso (más info wikipedia-semaforos ) y de esta manera evitar un deadlock o abrazo de la muerte (más info wikipedia-Bloqueo mutuo). Estos son utilizados sobre todo por la Base de Datos, servidores web, ...etc.
Teniendo en cuenta esto, quedarnos sin semáforos, puede implicar que se nos bloquee la BBDD, el servidor web o la aplicación que los utilice.
Ahora vamos a ver como revisar los semáforos de un servidor y como aumentarlos.
Para ver los limites de los semáforos se pueden ver de la siguiente manera:

# ipcs -ls

------ Semaphore Limits --------
max number of arrays = 250
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 100
semaphore max value = 32767



Aqui podemos ver que nos indica los limites que tenemos en el sistema.
Podemos mirar los semáforos en uso:

# ipcs -su

------ Semaphore Status --------
used arrays = 241
allocated semaphores = 3718


En este caso estamos en el limite de arrays usados y este es el valor que deberíamos aumentar. Para hacerlo utilizaremos el comando sysctl , revisando la configuración actual:
# /sbin/sysctl kernel.sem
kernel.sem = 250 32000 100 250


Donde cada parametro indica lo siguiente:
SEMMSL - The maximum number of semaphores in a sempahore set
SEMMNS - The maximum number of sempahores in the system
SEMOPM - The maximum number of operations in a single semop call
SEMMNI - The maximum number of sempahore sets
Para ampliarlo tendremos que aumentar el ultimo parámetro:
#/sbin/sysctl -w kernel.sem="250 3200 100 300"
Y revisamos que se ha realizado los cambios:
# ipcs -sl

------ Semaphore Limits --------
max number of arrays = 300
max semaphores per array = 250
max semaphores system wide = 3200
max ops per semop call = 100
semaphore max value = 32767


Por ultimo modificamos el fichero /etc/sysctl.conf para que se mantengan los cambios en el próximo reinicio. Para eso añadimos o modificamos la siguiente linea en el fichero /etc/sysctl.conf:
kernel.sem=250 3200 100 300

Y eso es todo.
Un saludo a todos y recordad:
Ser todo lo felices que podáis ser.

Quitos.

miércoles, 16 de abril de 2008

Renombrar un VG en HP-UX

Bueno, hoy voy a poner un procedimiento para renombrar un volume group en HP-UX.
Que motivación tiene?
En entornos donde los nombres de los vg están intimamente relacionados con lo que contienen, no es bonito tener varias aplicaciones en un vg con nombre softvg.
Desmontamos los filesystems :
#umount /app/depg3pre/exports
#umount /app/depg3pre/arch
#umount /app/depg4pre/arch
#umount /app/depg4pre/exports
- Desactivamos el vg:
#vgchange -a n /dev/golfvg

- Exportamos el mapfile del vg:
#vgexport -s -m /tmp/golfvgmap /dev/golfvg
- Creamos el directorio nuevo del vg el /dev y el fichero de dispositivo. OJO con el identificador minor que ponemos hay que buscar uno libre en este caso el 0x030000 :
#mkdir /dev/oraclevg
#mknod /dev/oraclevg/group c 64 0x030000
- Importamos el vg y lo activamos:
#vgimport -s -m /tmp/golfvgmap /dev/oraclevg
#vgchange -a y /dev/oraclevg
Bueno en este punto ya solo nos queda primero modificar las entradas del /etc/fstab para tener en cuenta la nuevas rutas de los lv que serán en mi caso:
/dev/oraclevg/lvdepg3pre_exp
/dev/oraclevg/lvdepg3pre_arch
/dev/oraclevg/depg4pre_archlv
/dev/oraclevg/depg4pre_explv

Solo nos quedara montar con mount y levantar las aplicaciones.

Como ultimo comentar que he estado mirando como se tendria que hacer en linux, bueno parece ser que con un vgrename ya estaria listo (cada vez pienso más que los unix antiguos son muy arcaicos y nada de sistemas modernos).

Un saludo a todos y recordad:
Ser todo lo felices que podáis ser.

Quitos.

PD: Ya se que posiblemente conozcáis como hacerlo pero siempre hay alguien que lo tiene que hacer, además así me sirve de apuntes.