Edit Instalación de OPs Debian/Dell

Title:

Last edited: 10:44:52 am on 10 May 2024 by 3.0.1.3

+^_@
_
<tt>Friday, 10 May 2024, 10:42:59 am</tt>
Fallo en los ejecutables con Xrt con el error de que no encuentran el símbolo XmeStringIsValid

Para arreglarlo basta con ajustar en el <tt>.autostart</tt> el <tt>LD_LIBRARY_PATH</tt> para que tenga primero el <tt>/usr/local/sico/lib</tt>&nbsp;.

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

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
_
<tt>Wednesday, 28 March 2012, 6:47:10 pm</tt>
Actualizado el ISA en las ops de SICO Para poner la nueva versión que soporta comas escapadas. Se ha actualizado con un:
<tt>metro@manten01:/incoming/DistribOP$ ./patch_ops.sh @lista_ops_isa update_op_isatce.sh update_op_isatce.tar.gz</tt>

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:
<table border=1><tr><td><tt>From: Dario &lt;DarioRodriguez@sicosoft.es&gt;
To: "Pajuelo Utrera, José" &lt;jose.pajuelo@mail.metromadrid.es&gt;
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)]
</tt></td></tr></table>

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:
<table border=1><tr><td><tt>#!/bin/sh
cat /home/isa/FichCamaras/fich_video_estaciones | sed "s/^$[^,]&star;$,$[^,]&star;$,$[^,]&star;$,$[^,]&star;$,$.&star;$/\1\\\\,\2,\3\\\\,\4,\5/g" &gt; /home/isa/FichCamaras/filtered/fich_video_estaciones
</tt></td></tr></table>
_
<tt>Monday, 13 February 2012, 11:25:15 am</tt>
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

_
<tt>Monday, 4 October 2010, 11:35:19 am</tt>
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 &gt;&gt; /etc/modprobe.d/blacklist
(ver *Debian 4.0 etch y los dispositivos de red con nombres estables: udev>http://3.0.1.45:8000/HowTo/152*).
_
<tt>Tuesday, 15 June 2010, 12:22:10 pm</tt>
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
_
<tt>Wednesday, 21 October 2009, 5:23:57 pm</tt>
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>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370709* (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:
<blockquote><code>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</code></blockquote>
2. si hacíamos un attach contra el proceso de las X, siempre estaba parado en el NVSync():
<blockquote><code>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</code></blockquote>

Y se correspondía con lo del bug.

Arreglo: Se ha añadido al <tt>xorg.conf</tt> un
<blockquote><code>Option "NoAccel"</code></blockquote>
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)>http://bugs.freedesktop.org/show_bug.cgi?id=3168* también se evita el bug simplemente desactivando una aceleración específica:
<blockquote><code>Option "XaaNoScreenToScreenCopy"</code></blockquote>
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).

_
<tt>Thursday, 21 May 2009, 5:13:31 pm</tt>
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
<tt>$ 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 &star;.deb
$ ftp centralml
user: metro
pass:
ftp> bin
ftp> put nks.tgz
ftp> bye
</tt>

En centralml
</tt> # 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
</tt>
_
<tt>Wednesday, 28 May 2008, 4:30:55 pm</tt>
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 <tt>/etc/sudoers</tt>, 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:
<tt>metro@manten01:/incoming$ ./comando_interactivo_ops.sh "EDITOR=vi TERM=vt100 visudo ; bash"</tt>
_
<tt>Friday, 9 May 2008, 4:08:37 pm</tt>
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.
_
<tt>Thursday, 7 June 2007, 6:16:25 pm</tt>
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:
<tt> # (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 ) &gt; /tmp/files_list.txt 2&gt;/tmp/files_list.errors </tt>
_
<tt>Monday, 7 May 2007, 5:47:30 pm</tt>
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 <tt>/home/metro/.xsession</tt> de op1_ml y op2_ml. También he hecho dichos cambios (<tt>/etc/modules</tt> y <tt>/home/metro/.xsession</tt>) en la op3_ml, que estaban sin hacer.
_
<tt>Tuesday, 20 March 2007, 6:40:11 pm</tt>
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".
_
<tt>Monday, 26 February 2007, 1:15:34 pm</tt>
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 <tt>salchicha:/home/dario/Programacion/proyectos/sico-actualiza/op/20070226_amixer_support</tt> 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).
_
<tt>Friday, 23 February 2007, 1:29:38 pm</tt>
Instalo sox (comando play) en las siguientes op: op50-53, op30-33, op34-37, op54-57 <s>Excepto op51_mm</s>Incluída la op51_mm que tiene un problema con el apt-get. He usado <tt>salchicha:/home/dario/Programacion/proyectos/sico-actualiza/op/20070223_play_support</tt> para hacerlo.

Actualizo las scripts de generación de discos en seraphim para incluir el paquete sox y su instalación He añadido <tt>plantillaopdell01-root.tar.gz.patch.002</tt> con los .deb y modificado el script <tt>diskinit.sh</tt> en <tt>seraphim:/backups/debiandell</tt>, demanera que instale el paquete sox (con un "dpkg -i" de todos los paquetes de los que depende y del propio sox).
_
<tt>Thursday, 21 December 2006, 12:09:53 pm</tt>
Instalo el rsync en op65_mm (y en metrosun2 *también>http://everythingsolaris.org/articles/atour/index.html*) siguiendo los pasos de *Mantenimiento servicios internos (swiki, ical, etc).>http://3.0.1.45:8000/Diarios/39#rsync*, 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>ftp://ftp.es.debian.org/debian/pool/main/r/rsync/rsync_2.6.9-2_i386.deb* en la op65_mm.
Procediemiento: para instalarlo en metrosun2:
# 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 <tt>seraphim:/imgiso/rsync-sol8sparc</tt>).
# 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")
# generar el fichero de configuración <tt>/etc/rsyncd.conf</tt><table border=1><tr><td><tt>motd file = /etc/rsyncd.motd log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock [tce] &nbsp; &nbsp; &nbsp; &nbsp; path = /captura/metro &nbsp; &nbsp; &nbsp; &nbsp; comment = TCE common files &nbsp; &nbsp; &nbsp; &nbsp; uid = metro &nbsp; &nbsp; &nbsp; &nbsp; gid = nobody &nbsp; &nbsp; &nbsp; &nbsp; read only = yes &nbsp; &nbsp; &nbsp; &nbsp; list = yes</tt></td></td></table>
# Hacer el script de arranque parada en <tt>/etc/init.d/rsync</tt> (basado en el del cron) <table border=1><tr><td><tt>#!/sbin/sh # #&nbsp;Based&nbsp;on&nbsp;files #&nbsp;Copyright&nbsp;(c)&nbsp;1997-1998&nbsp;by&nbsp;Sun&nbsp;Microsystems,&nbsp;Inc. #&nbsp;All&nbsp;rights&nbsp;reserved. # case&nbsp;"$1"&nbsp;in 'start') &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;[&nbsp;-x&nbsp;/usr/local/bin/rsync&nbsp;];&nbsp;then &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/local/bin/rsync&nbsp;--daemon &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fi &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;; 'stop') &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/usr/bin/kill&nbsp;`/usr/bin/ps&nbsp;-efa&nbsp;&nbsp;|&nbsp;grep&nbsp;rsync&nbsp;| \ &nbsp;grep&nbsp;-v&nbsp;grep&nbsp;|&nbsp;grep&nbsp;daemon&nbsp;|&nbsp;sed&nbsp;"s/^&nbsp;&star;//g"&nbsp;|\ &nbsp;sed&nbsp;"s/&nbsp;&nbsp;&star;/&nbsp;/g"&nbsp;|&nbsp;cut&nbsp;-d&nbsp;"&nbsp;"&nbsp;-f&nbsp;2`&nbsp;2>/dev/null&nbsp;>/dev/null &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;; &star;) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo&nbsp;"Usage:&nbsp;$0&nbsp;{&nbsp;start&nbsp;|&nbsp;stop&nbsp;}" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;exit&nbsp;1 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;;; esac exit&nbsp;0 </tt></td></tr></table>
# Hacer los enlaces a dicho script para que arranque como un servicio más del sistema: <tt># 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 &star;/&star;rsync</tt>
Para instalarlo en la op65_mm:
# Instalar el paquete <tt># dpkg -i rsync_2.6.9-2_i386.deb</tt>
# Añadir el crontab de metro (<tt>crontab -e</tt>) la siguiente línea: <tt>10 04 &star; &star; rsync -a metrosun2::tce/ /usr/local/sico/tce/TCE.local/ 2>/dev/null >/dev/null</tt>
<blockquote>UPDATE 20091124 Se quita dicha línea del crontab de la op65_mm (ya no es necesario, el nfs ya funciona bien).</blockquote>

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

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

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

_
<tt>Friday, 15 December 2006, 10:58:26 am</tt>
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...
_
<tt>Friday, 15 December 2006, 9:21:42 am</tt>
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
_
<tt>Thursday, 14 December 2006, 5:51:06 pm</tt>
Actualizado el cron a todas excepto op37 (sin ping) Según sico-actualiza/op/20061214_cron/cron-update.sh op37_mm.
_
<tt>Tuesday, 28 November 2006, 6:05:47 pm</tt>
Actualizado fich_video_estaciones en op53 Ya que la acaba de reinstalar Santiago (hemos rehecho el HDD).
_
<tt>Friday, 24 November 2006, 4:44 pm</tt>
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

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|services:isa_crp|
|op50_mm (seguridad)|16.18.62.145|255.255.255.0|16.18.62.1|50|panelvga01|18.2.40.84|7200|
|op51_mm (estaciones)|16.18.62.148|255.255.255.0|16.18.62.1|51|panelvga01|18.2.40.84|7300|
|op52_mm (seguridad)|16.18.62.146|255.255.255.0|16.18.62.1|52|panelvga01|18.2.40.84|7200|
|op53_mm (estaciones)|16.18.62.149|255.255.255.0|16.18.62.1|53|panelvga01|18.2.40.84|7300|
NOTA: el puerto 7200 corresponde con seguridad y el 7300 con estaciones

! PSL Ventas

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|
|op30_mm|16.12.62.147|255.255.255.0|16.12.62.1|30|crp_pslventas_seguridad|16.12.62.11|
|op31_mm|16.12.62.148|255.255.255.0|16.12.62.1|31|crp_pslventas_seguridad|16.12.62.11|
|op32_mm|16.12.62.145|255.255.255.0|16.12.62.1|32|crp_pslventas_estaciones|16.12.62.11|
|op33_mm|16.12.62.146|255.255.255.0|16.12.62.1|33|crp_pslventas_estaciones|16.12.62.11|

! PSL Avda de américa

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|Particularidades|
|op34_mm|16.17.62.145|255.255.255.0|16.17.62.1|34|crp_aamerica_seguridad|16.17.62.11|L9, 1 sólo monitor, sin teleind|
|op35_mm|16.17.62.146|255.255.255.0|16.17.62.1|35|crp_aamerica_seguridad|16.17.62.11|
|op36_mm|16.17.62.149|255.255.255.0|16.17.62.1|36|crp_aamerica_estaciones|16.17.56.11|
|op37_mm|16.17.62.150|255.255.255.0|16.17.62.1|37|crp_aamerica_estaciones|16.17.56.11|

! PSL Moncloa

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|
|op54_mm (seguridad)|16.13.62.141|255.255.255.0|16.13.62.1|54|crp_moncloa_estaciones|16.13.62.143|
|op55_mm (estaciones)|16.13.62.142|255.255.255.0|16.13.62.1|55|crp_moncloa_seguridad|16.13.62.146|
|op56_mm (estaciones)|16.13.62.144|255.255.255.0|16.13.62.1|56|crp_moncloa_seguridad|16.13.62.146|
|op57_mm (seguridad))|16.13.62.145|255.255.255.0|16.13.62.1|57|crp_moncloa_estaciones|16.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

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|services:isa_crp|
|op65_mm (seguridad)|16.11.62.68|255.255.255.0|16.11.62.1|65|crp_psl_pacifico|16.11.62.64|7200|
|op66_mm (seguridad)|16.11.62.69|255.255.255.0|16.11.62.1|66|crp_psl_pacifico|16.11.62.64|7200|
|op67_mm (estaciones)|17.138.58.72|255.255.255.0|17.138.58.1|67|crp_psl_pacifico|16.11.62.64|7300|
|op68_mm (estaciones)|17.138.58.73|255.255.255.0|17.138.58.1|69|crp_psl_pacifico|16.11.62.64|7300|

! PSL Hortaliza (del ML1, solo seguridad)

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|
|op75_ml1|12.116.58.8|255.255.255.0|12.116.58.1|75|crp_ml1|12.116.58.11|
|op76_ml1|12.116.58.9|255.255.255.0|12.116.58.1|76|crp_ml1|12.116.58.11|
|op77_ml1|12.116.58.10|255.255.255.0|12.116.58.1|77|crp_ml1|12.116.58.11|

_
(por hacer)

! PCI (oper_pci)

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|
|oper_pci|36.78.76.8|255.255.255.0|36.78.76.1|70|crplocalhost|127.0.0.1|

! Canillejas (op59_mm)

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|
|op59_mm|16.4.254.179|255.0.0.0|58.100.63.98|59|panelvga02|16.4.254.130|

! Dr. Esquerdo (op58_mm)

|Nombre|IP|Netmask|Gateway|NumOpCfg|NombreCRP|IP CRP|
|op58_mm|36.78.58.229|255.255.255.0|36.78.58.1|58|????|36.78.58.228|

_
_
Para ML2/3 (*cfr. PCCML1&2/3>http://3.0.1.45:8000/Diarios/90*)

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: