wiki-data/tecnica/milenium/datos_tecnica.md

# DATOS IMPORTANTES

## INFORMACION DE CONTACTO PROTEC

Existen dos tipos de eventos que tienen sus respectivos mecanismos de contacto; estos son:  
i- Teléfono: Este es el canal preferente, para el reporte de casos de emergencia y fuera del horario de oficina. Protecmedia: +56 2 26909090  
ii- Un evento considerado como una anomalía pero que no pone en peligro la salida del diario debe ser enviado al correo electrónico servicedesk_latam@protecmedia.com.  
  
Respecto de las actualizaciones de software, la gente de España nos deja los parches a instalar en su servidor FTP:  
ftp://ftpoperaciones.protecmedia.com  
Carpeta: Dia Plata  
Usuario: diaplata  
Pass: pr0tecPTdi  

## INSTALACION

Mile1 = 192.168.4.241  
Mile2 = 192.168.4.242  
Acceso radmin Usuario: milenium, pass PTP847Mile.  
Usuario del dominio: idem radmin  
discos:  
disco1 = E - base de datos, 276G  
disco2 = Q - quorum, 2G.  
disco3 = F - redologs, 198G.  
disco4 = G - hotfolders, 98G  
Las ips para el cluster son:  
192.168.4.184 gestión  
192.168.4.185 base de datos  
192.168.4.186 aplicaciones  
192.168.4.187 backup  
Mile3: IP 192.168.4.248 (Réplica)  
Piloto: IP 192.168.4.249  
  
En condiciones normales, en Mile1 debe estar corriendo los servicios (LSO, Monitor, Autophoto, Milenium Express, Input Server, Search Server, Security y Tracking).  
Si esto no se cumple, señal de que estamos en problemas.  
Mile3 es el servidor donde se hace la réplica online de la BD de producción (en realidad, se hace cada 1 hora) y ahí también copiamos las publicaciones cada 30’ que nos sirven también de backup.  
El backup de BD se copia a las 4:30am a Piloto todos los días.  
  
El dongle de producción (que tiene todas las licencias de las aplicaciones) está conectado al nodo 1, y el de emergencia al nodo2. Si, por alguna razón, las aplicaciones conmutaran al nodo2 al conectarse desde cualquier cliente aparecerá un cartel que indica “Quedan n días para que finalicen las licencias”. Esto no es impedimento para que los usuarios sigan trabajando normalmente pero es una alarma para nosotros que indica que algún servicio tuvo problemas en el nodo 1 y se produjo la conmutación al 2.  

## INSTALACION DE PARCHES Y ACTUALIZACIONES DE CLIENTES

### Actualización BD Milenium

i- arrancar el SQL Developer (En el NODO2 ir a  Programas \> Oracle – OraClient11g_home1 \> Desarrollo de aplicaciones \> SQL Developer)  
ii- Conectarse a la BD Milenium haciendo click en el más  
Usuario/clave: milenium/milenium  
iii- Copiar el primer script que nos hayan enviado.  
El orden es siempre el mismo: Edibase, Milenium y el resto de productos (ahí ya no importa el orden). Los parches son siempre acumulativos, por lo que al ejecutarlos enteros (que es como debemos hacerlo), siempre darán error las primeras líneas. No pasa nada pero, ante la duda, mandar el resultado a operaciones y te confirman que está todo bien.  
iv- De los dos iconos de Play, elegir el segundo para que muestre abajo el resultado de las operaciones que va haciendo. Te va diciendo lo que pasa: por ejemplo, ya existe un constraint con ese nombre (lo que indica que ya se ejecutó) y las últimas líneas son las correctas.  
v- Limpiar la pantalla, pasar al siguiente script, los errores son del mismo tipo: ya existen esos campos o restricciones. Así hasta ejecutar todos los scripts que nos hayan mandando.  
vi- Así ya estaría la base de datos actualizada  
==== Actualización de servidores ====

i- Parar los servicios  
ii- Pisar todos los ejecutables y dlls que nos hayan enviado dentro del parche, hacerlo en los 2 servidores.  
iii- Levantar los servicios nuevamente  
==== Actualización de clientes ====

i- Entrar a \\zeus\instalar\PROTEC, borrar el directorio “anterior” y hacer una copia del directorio “ultima” y renombrarlo “anterior”  
ii- Guardar los ejecutables y dlls nuevos en “ultima” pisando a los existentes  
iii- En cada máquina de usuario pisar los ejecutables y DLLs que correspondan  

## EXPORTACION A LA WEB

### Forzar a la BD a exportar una publicación ya exportada

Si ocurre algún evento que hace que debamos exportar nuevamente los XMLs de una publicación, la única forma es forzando a la base de datos a que crea que nunca se exportó dicha publicación. Esto se logra corriendo el siguiente comando en el SQL Developer\*  
UPDATE EDFECHACOPIAXML SET FECHACOPIAXML=NULL WHERE TRUNC(FECHACOPIAXML)=’11/09/2012’; (ojo con las comillas, corregirlas en el SQL)  
COMMIT;  
(reemplazar por la fecha de la publicación que corresponda)  
\*ver punto 3) a) i y ii  

### Liberar un proceso de publicación que se haya colgado

Si por alguna razón, durante el proceso de publicación se colgara el EDITOR y, al intentar publicar nuevamente, apareciera un cartel diciendo: “Ya hay un proceso activo de publicación en la web. Revise los procesos activos de publicación en la Web”, en ese caso deberán ir a: solapa @, en el blanco del árbol con botón derecho del mouse: Salida a Internet  Ver procesos activos de publicación en la web… Cancelar proceso  
![{{:tecnica:milenium:salida.jpg\|](/tecnica/milenium/salida.jpg)}}

## CONTROL DE VERSIONES, RECUPERACION DE CONTENIDOS

### Recuperación de estados anteriores de contenidos guardados

el Control de Versiones tendrá su primera versión del artículo cuando el usuario lo guarde por primera vez en base de datos (esto abarca tanto artículos en publicación o en adelanto). Para ello, debe hacer lo siguiente:  
- Si está trabajando con artículo en adelanto: tiene que apretar Ctrl+S o los disquetes de arriba (guardado en edición, o sea, sin liberar el artículo). Las dos opciones conducen a lo mismo. La forma de liberarlo es cerrando el artículo en edición. Si el programa se cuelga o se cierra en forma incorrecta sin haber cerrado antes el artículo, el mismo quedará reservado por el usuario y deberá liberarlo antes de volver a trabajar en él.  
- Si está trabajando con artículo en publicación: también tiene que apretar Ctrl+S o disquetes, o directamente con botón derecho guardar artículo (en este caso, luego de guardarlo lo libera). La anterior, sería la forma de recuperar una versión vieja del artículo, habrá tantas versiones como modificaciones seguidas de Ctrl+S se hayan realizado. Es importante saber que acá no tiene nada que ver el autoguardado cada 3 minutos. Esto depende únicamente del usuario, si no guarda, no hay versión anterior.  
==== Recuperación de contenidos en edición luego de un “cuelgue” ==== respecto del autoguardado cada 3 minutos (si abren un editor y van a Archivo \> Preferencias, verán que esto está seteado por defecto), esto sirve únicamente para recuperar contenidos que se estaban editando y no se habían guardado cuando, por alguna razón, se colgó el editor, se apagó la máquina o pasó algo que hizo que el usuario “perdiera” lo que estaba trabajando en el momento. Entonces, se vuelve a abrir el editor en la máquina del usuario, se va a Archivo\>Ver elementos en edición\>Propios, Solapa Componentes de Artículos y allí se seleccionan los contenidos que se desean recuperar. En este punto hay 2 alternativas:  
- Liberar edición: recuperará el último estado guardado por el usuario  
- Recuperar edición: recuperará el último estado guardado por el sistema (o sea, que si el usuario guardó y siguió trabajando y el sistema alcanzó a guardar algo más con el autoguardado cada 3 minutos, recuperará una versión más trabajada del artículo). Es importante saber que algo puede haber perdido, si alcanzó a editar algo antes de que el sistema volviera a guardar y ahí se colgó el programa. Pero la pérdida debiera ser mínima (un trabajo de menos de 3 minutos).  
Es importante saber que ese autoguardado cada 3 minutos se hace en archivos temporales de la máquina de usuario, por lo que la única forma de recuperar lo último es abriéndolo en la máquina del usuario.  
==== Autoborrado de artículos en adelanto ==== En Milenium Cross Media Manager del nodo 2 (usuario milenium, clave milenium), dentro de Configuración del Sistema se encuentran los seteos para los borrados automáticos.  
En el caso de los artículos en adelanto, está configurado para que se borren automáticamente a los 15 días de su creación, aunque, si no se utilizaron, no se borran nunca. El sistema considera que un artículo en adelanto fue utilizado si se “refunde” en un artículo de una publicación. Si, por el contrario, para utilizarlo en un artículo, se copian y pegan sus contenidos, el sistema no tiene forma de enterarse de esta acción y considera que no se utilizó, por lo que no los borrará.  
![bor.jpg](/tecnica/milenium/bor.jpg)  
Asimismo el periodista, desde el Editor, puede modificar o sacar la fecha de autoborrado cuando carga su artículo, de manera que se borre en otra fecha o nunca. ![bor2.png](/tecnica/milenium/bor2.png)  

#### Recuperación de páginas y publicaciones

cada 30’ se guarda en el disco G del clúster, directorio Security, todas las publicaciones en producción y sus páginas con los contenidos correspondientes al momento del guardado. Se guardan las 3 últimas medias horas, por lo que se podrían recuperar los contenidos de hasta 1 hora y media antes.  
Para recuperar páginas conviene usar, por ejemplo, las publicaciones AREA_TECNICA (DIA o EL PLATA) de manera de no afectar a la publicación en producción.  
i- En la solapa de Secciones, pararse sobre la publicación y, con botón derecho, agregar la sección que se desee recuperar  
ii- En la misma solapa, pararse sobre la sección y, con botón derecho, importar páginas:  
![imp.png](/tecnica/milenium/imp.png) Para recuperar una publicación completa: i- Archivo\>Importar  seleccionar la publicación deseada del disco G de Mile1  
ii- Elegir el primer archivo dentro de la carpeta (que corresponde a la publicación completa)  
iii- Tener la precaución de cambiar el nombre de la publicación para que no pise o entre en conflicto con una existente.  
iv- Apretar Abrir y comenzará la importación.  
![imp2.png](/tecnica/milenium/imp2.png)