View this PageEdit this PageUploads to this PageVersions of this PageHomeRecent ChangesSearchHelp Guide

Instalación de OPs Debian/Dell



Friday, 10 May 2024, 10:42:59 am
Fallo en los ejecutables con Xrt con el error de que no encuentran el símbolo XmeStringIsValid

Para arreglarlo basta con ajustar en el .autostart el LD_LIBRARY_PATH para que tenga primero el /usr/local/sico/lib .

El problema viene de que dicho símbolo no está en el lesstiff de /usr/lib y el Xrt lo usa. Dicho símbolo sí está en la libXm.so de /usr/local/sico/lib .

NOTA: para hacer una prueba de si arranca poniendo sólo ese símbolo, se puede usar
 salchicha:/home/dario/Programacion/proyectos/sico-xmestringisvalid/xmestringisvalid.so

con
 LD_PRELOAD=/path/al/xmestringisvalid.so nombreejecutableconxrt SinRPCs
Wednesday, 28 March 2012, 6:47:10 pm
Actualizado el ISA en las ops de SICO Para poner la nueva versión que soporta comas escapadas. Se ha actualizado con un:
metro@manten01:/incoming/DistribOP$ ./patch_ops.sh @lista_ops_isa update_op_isatce.sh update_op_isatce.tar.gz

SIN PING (y sin actualizar, por ende): op75_ml1 op77_ml1 op78_retros_ml1 op79_retros_ml1

Sobre la actualización, la manera más encilla de explicarlo es éste e-mail:
From: Dario <DarioRodriguez@sicosoft.es>
To: "Pajuelo Utrera, José" <jose.pajuelo@mail.metromadrid.es>
Cc: enrique_toledano@mail.metromadrid.es, javiersoler@sicosoft.es
Subject: RPM de nueva versión del ISA para las OPs de alto del arenal (relacionado con incidencia ST 52712275)
Date: Wed, 28 Mar 2012 18:01:33 +0200
Organization: SICOSOFT
X-Mailer: Sylpheed version 1.0.2 (GTK+ 1.2.10; i686-pc-linux-gnu)

Hola José,

Adjunto a este mensaje está el RPM de una versión actualizada del isa para las OPs de Alto del Arenal.

Es necsario actualizar todas las máquinas que tienen el ISA a la nueva versión para que no se de la situación descrita en la incidencia ST 52712275.

DESCRIPCION DEL PROBLEMA
------------------------

Esto está relacionado con la incidencia ST 52712275: recientemente se han empezado a usar rondas con nombre como "ALONSO MARTINEZ, VESTIBULOS y ESCALERAS", "ARGÜELLES, VESTIBULOS y ESCALERAS", etc y estas no se pueden usar con el ISA, ya que éste considera la coma como un carácter reservado.

En estos momentos, antes de enviar el fich_video_estaciones al ISA, en el crp01 se filtran dichas líneas para que no contengan comas, pero eso cambia el identificador de la cámara y termina provocando que no se puedan fijar.

SOLUCION PROPUESTA
------------------

En la nueva versión del ISA, se permite dicho carácter en los nombres de las rondas. Sin embargo, si se recibe dicho carácter en las rondas en la versión antigua del ISA, el ISA dejará de funcionar correctamente.

Así pues, para aceptar comas en los nombres de las rondas hay que hacerlo en dos pasos:

1. Actualizar todos los ISA a la nueva versión para que acepten el nuevo formato de fichero de configuración fich_video_estaciones con comas en los nombres de las rondas.

2. Cambiar el filtro de crp01 para que deje usar comas en los nombres de las rondas

===

Así pues, quedo a la espera de la confirmación de que se ha instalado el nuevo ISA en todas las OPs de Alto del Arenal.

Muchas gracias.

--
Saludos,
Dario
SICOSOFT

[sico-isacd-op-1.1-1.201203281752.i386.rpm application/x-redhat-package-manager (384561 bytes)]


Hay un script en crp01 que también habrá que actualizar una vez que confirmen desde metro que han actualziado sus máquinas:
 isa@crp01:/home/isa/filter-fich_video_estaciones
Que habrá que sustituir por uno que diga lo siguiente:
#!/bin/sh
cat /home/isa/FichCamaras/fich_video_estaciones | sed "s/^\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(.*\)/\1\\\\,\2,\3\\\\,\4,\5/g" > /home/isa/FichCamaras/filtered/fich_video_estaciones

Monday, 13 February 2012, 11:25:15 am
Quitada la aceleración hardware en el vídeo de la op59 para evitar un bug que hacía que las X se quedasen pilladas Lo mismo que pasaba en la op33, tambíen lo hemos tenido que apañar en la op59

Monday, 4 October 2010, 11:35:19 am
Puesto el eth1394 en el blacklist para la op30_mm Mi conclusión es que en la op30_mm, a veces el interfaz firewire cogía el puesto de eth0 antes que el interfaz de red. Para arreglarlo he puesto:
# rmmod eth1394
# echo blacklist eth1394 >> /etc/modprobe.d/blacklist
(ver Debian 4.0 etch y los dispositivos de red con nombres estables: udev).
Tuesday, 15 June 2010, 12:22:10 pm
Quitada la aceleración hardware en el vídeo de la op56 para evitar un bug que hacía que las X se quedasen pilladas Lo mismo que pasaba en la op33, tambíen lo hemos tenido que apañar en la op56
Wednesday, 21 October 2009, 5:23:57 pm
Quitada la aceleración hardware en el vídeo de la op33 para evitar un bug que hacía que las X se quedasen pilladas Básicamente nos hemos topado con este bug (xserver-xorg-video-nv: system hang in NVSync() when scrolling programs or terminal windows). Hemos visto que era ese porque:
1. El top estaba al 100% en las X:
top - 17:19:14 up 11 min,  2 users,  load average: 0.83, 0.86, 0.50
Tasks:  85 total,   3 running,  82 sleeping,   0 stopped,   0 zombie
Cpu(s):100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2075040k total,   106824k used,  1968216k free,     5724k buffers
Swap:  1951736k total,        0k used,  1951736k free,    38576k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 5068 root      25   0  699m 6544 3188 R 99.9  0.3   0:27.22 Xorg
    1 root      16   0  1956  664  568 S  0.0  0.0   0:02.66 init

2. si hacíamos un attach contra el proceso de las X, siempre estaba parado en el NVSync():
op33_mm:/home/metro# gdb `which Xorg`
...
(gdb) attach 5068
Attaching to program: /usr/bin/Xorg, process 5068
...
(no debugging symbols found)
0xa79c79a2 in NVSync () from /usr/lib/xorg/modules/drivers/nv_drv.so
(gdb) bt
#0  0xa79c79a2 in NVSync () from /usr/lib/xorg/modules/drivers/nv_drv.so
#1  0xa6927452 in XAACopyAreaFallback () from /usr/lib/xorg/modules/libxaa.so
#2  0xa6928747 in XAACopyArea () from /usr/lib/xorg/modules/libxaa.so
#3  0x0814fc47 in DamageDamageRegion ()
#4  0x08084c89 in ProcCopyArea ()
#5  0x08086b8b in Dispatch ()
#6  0x0806e5de in main ()
(gdb) detach


Y se correspondía con lo del bug.

Arreglo: Se ha añadido al xorg.conf un
Option "NoAccel"

En la sección de driver de las tres tarjetas nvidia.

Ahora usa más CPU que otros puestos de operador,pero al menos no se bloquea.


NOTA: Según este bug (comment #22) también se evita el bug simplemente desactivando una aceleración específica:
Option "XaaNoScreenToScreenCopy"

Aunque al final de dicho report dan una solución (hay que modificar el fichero nv_local.h con lo que dicen ahí y recompilar el driver nvidia).


Thursday, 21 May 2009, 5:13:31 pm
Actualizado el nfsd de centralml desde el nfs-user-server a nfs-kernel-server Y así ha funionado el montar el NFS a través del firewall. Pasos realizados:
En salchicha
$ mkdir /tmp/nks
$ cd /tmp/nks
$ wget ftp://ftp.es.debian.org/debian/pool/main/n/nfs-utils/nfs-common_1.0.10-6+etch.1_i386.deb ftp://ftp.es.debian.org/debian/pool/main/n/nfs-utils/nfs-kernel-server_1.0.10-6+etch.1_i386.deb ftp://ftp.es.debian.org/debian/pool/main/libn/libnfsidmap/libnfsidmap2_0.18-0_i386.deb
$ tar -czvf nks.tgz *.deb
$ ftp centralml
user: metro
pass:
ftp> bin
ftp> put nks.tgz
ftp> bye


En centralml
# cd /var/cache/apt/archives/
# tar -xvf /home/metro/nks.tgz
# rm /home/metro/nks.tgz
# dpkg -r libnfsidmap1 librpcsecgss2 nfs-user-server
# dpkg -i libnfsidmap2_0.18-0_i386.deb nfs-common_1.0.10-6+etch.1_i386.deb nfs-kernel-server_1.0.10-6+etch.1_i386.deb librpcsecgss3_0.14-2_i386.deb
# /etc/init.d/nfs-kernel-server restart

Wednesday, 28 May 2008, 4:30:55 pm
Quito del "visudo" el /usr/bin/sudo que estaba de más para el "hwclock.sh stop", excepto en la op58 (sin ping) op78_retros_ml1(sin ping) Resulta que en el maestro de op está mal el /etc/sudoers, en donde dice:
metro   ALL=NOPASSWD:/usr/bin/sudo /etc/init.d/hwclock.sh stop
y debería decir
metro   ALL=NOPASSWD:/etc/init.d/hwclock.sh stop
Lo he hecho con un:
metro@manten01:/incoming$ ./comando_interactivo_ops.sh "EDITOR=vi TERM=vt100 visudo ; bash"
Friday, 9 May 2008, 4:08:37 pm
En la op31_mm sucenden cosas extrañas con el driver de la eth0 (tg3 para gigabit ethernet): algunas veces no levanta el interfaz Y rebotándola de botón no suele arreglar el problema, sino que reconfigurando el interfaz a mano sí que empezaba a funcionar.
Thursday, 7 June 2007, 6:16:25 pm
Hago un listado de ficheros en las OPs Ahora en una OP "recién instalada" (op1_ml23) y luego en la op1_ml23 original, con:
# (for i in bin boot dev etc home initrd lib opt root sbin srv usr var ; do find /$i -printf "%p %s %m %l \\n" ; done ) > /tmp/files_list.txt 2>/tmp/files_list.errors
Monday, 7 May 2007, 5:47:30 pm
Hago que las scripts de creción de ops activen el soporte oss y pongan el volumen Igual que se ha tenido que hacer en las ops de ml23. He puesto que se establezca el volumen en /home/metro/.xsession de op1_ml y op2_ml. También he hecho dichos cambios (/etc/modules y /home/metro/.xsession) en la op3_ml, que estaban sin hacer.
Tuesday, 20 March 2007, 6:40:11 pm
He instalado los drivers de sonido y activado el audio en las dos ops de la maqueta de ml en infoglobal He instalado los patch.001, 002 y 003 de debiandell, y a continuación he añadido al /home/metro/.xsession lo siguiente:
 /usr/bin/amixer sset Master unmute >/dev/null
Justo después del "mount -a".
Monday, 26 February 2007, 1:15:34 pm
Instalo alsa-utils(amixer) y modifico el .xsession para que haga un unmute en las siguientes op: op50-53, op30-33, op34-37, op54-57 He usado salchicha:/home/dario/Programacion/proyectos/sico-actualiza/op/20070226_amixer_support para hacerlo.

Actualizo las scripts de generación de discos en seraphim para incluir el paquete alsa-utils y su instalación He añadido plantillaopdell01-root.tar.gz.patch.003 con los .deb y modificado el script diskinit.sh en seraphim:/backups/debiandell, demanera que instale el paquete alsa-utils (con un "dpkg -i" de todos los paquetes de los que depende y del propio alsa-utils).
Friday, 23 February 2007, 1:29:38 pm
Instalo sox (comando play) en las siguientes op: op50-53, op30-33, op34-37, op54-57 Excepto op51_mmIncluída la op51_mm que tiene un problema con el apt-get. He usado salchicha:/home/dario/Programacion/proyectos/sico-actualiza/op/20070223_play_support para hacerlo.

Actualizo las scripts de generación de discos en seraphim para incluir el paquete sox y su instalación He añadido plantillaopdell01-root.tar.gz.patch.002 con los .deb y modificado el script diskinit.sh en seraphim:/backups/debiandell, demanera que instale el paquete sox (con un "dpkg -i" de todos los paquetes de los que depende y del propio sox).
Thursday, 21 December 2006, 12:09:53 pm
Instalo el rsync en op65_mm (y en metrosun2 también) siguiendo los pasos de Mantenimiento servicios internos (swiki, ical, etc)., para que sincronice el directorio de TCE de metrosun2 todas las noches (y no use nfs), he instalado el rsync_2.6.9-2_i386.deb en la op65_mm.
Procediemiento: para instalarlo en metrosun2:
  1. Bajar de sunfreeware los paquetes libgcc-3.4.6-sol8-sparc-local.gz libiconv-1.11-sol8-sparc-local.gz popt-1.7-sol8-sparc-local.gz rsync-2.6.9-sol8-sparc-local.gz (están en seraphim:/imgiso/rsync-sol8sparc).
  2. Instalarlos en ese orden un un gzip -d nombrepaquete ; pkgadd -d nombrepaquetesingz (y si hay que sobreescribir ficheros, decirle que no los sobreescriba pero que continúe con la instalación; en metrosun2 ya existia el /usr/local/lib/libgcc_s.so.1 y no ha habido problemas para que funcione el rsync con ese fichero "antiguo")
  3. generar el fichero de configuración
    /etc/rsyncd.conf
    motd file = /etc/rsyncd.motd
    log file = /var/log/rsyncd.log
    pid file = /var/run/rsyncd.pid
    lock file = /var/run/rsync.lock

    [tce]
            path = /captura/metro
            comment = TCE common files
            uid = metro
            gid = nobody
            read only = yes
            list = yes
  4. Hacer el script de arranque parada en /etc/init.d/rsync (basado en el del cron)
    #!/sbin/sh
    #
    # Based on files
    # Copyright (c) 1997-1998 by Sun Microsystems, Inc.
    # All rights reserved.
    #

    case "$1" in
    'start')
            if [ -x /usr/local/bin/rsync ]; then
                    /usr/local/bin/rsync --daemon
            fi
            ;;

    'stop')
            /usr/bin/kill `/usr/bin/ps -efa  | grep rsync | \
     grep -v grep | grep daemon | sed "s/^ *//g" |\
     sed "s/  */ /g" | cut -d " " -f 2` 2>/dev/null >/dev/null
            ;;

    *)
            echo "Usage: $0 { start | stop }"
            exit 1
            ;;
    esac
    exit 0
  5. Hacer los enlaces a dicho script para que arranque como un servicio más del sistema:
    # cd /etc
    # ln init.d/rsync rc0.d/K40rsync
    # ln init.d/rsync rc1.d/K40rsync
    # ln init.d/rsync rc2.d/S75rsync
    # ln init.d/rsync rcS.d/S75rsync
    # chmod 755 */*rsync
Para instalarlo en la op65_mm:
  1. Instalar el paquete
    # dpkg -i rsync_2.6.9-2_i386.deb
  2. Añadir el crontab de metro (crontab -e) la siguiente línea:
    10 04 * * rsync -a metrosun2::tce/ /usr/local/sico/tce/TCE.local/ 2>/dev/null >/dev/null
UPDATE 20091124 Se quita dicha línea del crontab de la op65_mm (ya no es necesario, el nfs ya funciona bien).


Para arrancar el servidor en metrosun2:
# /usr/local/bin/rsync --daemon
Para hacer la copia en op65_mm
$ rsync -a metrosun2::tce/ /usr/local/sico/tce/TCE.local/

NOTA: esta configuración utiliza rsh para hacer la sincronización, ya que metrosun2 no tiene instalado el ssh.

UPDATE 20100302 Se configura el rsync en main2 para poder actualizar el Comun en frontpci02. Metrosun2 ha pasado a mejor vida...snif snif.


Friday, 15 December 2006, 10:58:26 am
Las ops 36 y 37 están sin configurar Según se desprende de una pasada rápida por las OPs para comprobar que el cron estaba funcionando correctamente...
Friday, 15 December 2006, 9:21:42 am
Estado de tarjetas gráficas
op50,51,52,53: 2xFX,1xQuadro
op30,31,32,33: 2xFX,1xQuadro
op34,35,36,¿37?: 2xG450
op54,55,56,57: 2xFX,1xQuadro
op65,op66: 2xG450
oper_pci: 1xFX, 1xQuadro

Total:
 FX: 2x4x3+1= 25
 Quadro: 1x4x3+1= 13
 G450: 4x2+2x2= 12
Thursday, 14 December 2006, 5:51:06 pm
Actualizado el cron a todas excepto op37 (sin ping) Según sico-actualiza/op/20061214_cron/cron-update.sh op37_mm.
Tuesday, 28 November 2006, 6:05:47 pm
Actualizado fich_video_estaciones en op53 Ya que la acaba de reinstalar Santiago (hemos rehecho el HDD).
Friday, 24 November 2006, 4:44 pm
Actualizado el fich_video_estaciones Falta en op53 y op37 (estaban apagadas).

Descripción del proyecto


Aquí se detalla la configuración e instalación de las diferentes ops.

PSL N.Ministerios


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRPservices:isa_crp
op50_mm
(seguridad)		16.18.62.145255.255.255.016.18.62.150panelvga0118.2.40.847200
op51_mm
(estaciones)		16.18.62.148255.255.255.016.18.62.151panelvga0118.2.40.847300
op52_mm
(seguridad)		16.18.62.146255.255.255.016.18.62.152panelvga0118.2.40.847200
op53_mm
(estaciones)		16.18.62.149255.255.255.016.18.62.153panelvga0118.2.40.847300
NOTA: el puerto 7200 corresponde con seguridad y el 7300 con estaciones

PSL Ventas


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op30_mm16.12.62.147255.255.255.016.12.62.130crp_pslventas_seguridad16.12.62.11
op31_mm16.12.62.148255.255.255.016.12.62.131crp_pslventas_seguridad16.12.62.11
op32_mm16.12.62.145255.255.255.016.12.62.132crp_pslventas_estaciones16.12.62.11
op33_mm16.12.62.146255.255.255.016.12.62.133crp_pslventas_estaciones16.12.62.11

PSL Avda de américa


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRPParticularidades
op34_mm16.17.62.145255.255.255.016.17.62.134crp_aamerica_seguridad16.17.62.11L9, 1 sólo monitor, sin teleind
op35_mm16.17.62.146255.255.255.016.17.62.135crp_aamerica_seguridad16.17.62.11
op36_mm16.17.62.149255.255.255.016.17.62.136crp_aamerica_estaciones16.17.56.11
op37_mm16.17.62.150255.255.255.016.17.62.137crp_aamerica_estaciones16.17.56.11

PSL Moncloa


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op54_mm
(seguridad)		16.13.62.141255.255.255.016.13.62.154crp_moncloa_estaciones16.13.62.143
op55_mm
(estaciones)		16.13.62.142255.255.255.016.13.62.155crp_moncloa_seguridad16.13.62.146
op56_mm
(estaciones)		16.13.62.144255.255.255.016.13.62.156crp_moncloa_seguridad16.13.62.146
op57_mm
(seguridad))		16.13.62.145255.255.255.016.13.62.157crp_moncloa_estaciones16.13.62.143
NOTA: Los crps de moncloa tienen el nombre contrario a su funcion: crp_moncloa_estaciones se usa para seguridad y crp_moncloa_seguridad se usa para estaciones.

PSL Pacífico


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRPservices:isa_crp
op65_mm
(seguridad)		16.11.62.68255.255.255.016.11.62.165crp_psl_pacifico16.11.62.647200
op66_mm
(seguridad)		16.11.62.69255.255.255.016.11.62.166crp_psl_pacifico16.11.62.647200
op67_mm
(estaciones)		17.138.58.72255.255.255.017.138.58.167crp_psl_pacifico16.11.62.647300
op68_mm
(estaciones)		17.138.58.73255.255.255.017.138.58.169crp_psl_pacifico16.11.62.647300

PSL Hortaliza (del ML1, solo seguridad)


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op75_ml112.116.58.8255.255.255.012.116.58.175crp_ml112.116.58.11
op76_ml112.116.58.9255.255.255.012.116.58.176crp_ml112.116.58.11
op77_ml112.116.58.10255.255.255.012.116.58.177crp_ml112.116.58.11

(por hacer)

PCI (oper_pci)


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
oper_pci36.78.76.8255.255.255.036.78.76.170crplocalhost127.0.0.1

Canillejas (op59_mm)


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op59_mm16.4.254.179255.0.0.058.100.63.9859panelvga0216.4.254.130

Dr. Esquerdo (op58_mm)


NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op58_mm36.78.58.229255.255.255.036.78.58.158????36.78.58.228

Para ML2/3 (cfr. PCCML1&2/3)

NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op1_ml23
op2_ml23
op3_ml23
op4_ml23 (retros1)
op5_ml23 (retros2)
Para ML1 (cfr. PCCML1&2/3)

NombreIPNetmaskGatewayNumOpCfgNombreCRPIP CRP
op75_ml1(ver arriba)
op76_ml1(ver arriba)
op77_ml1(ver arriba)
op78_ml1 (retros1)
op79_ml1 (retros2)