El siguiente programa ilustra este punto. La variable "t" se usa como un contador el cual es incrementado por 1000 threads en tiempos relativamente aleatórios, lo mismo que la variable "t2". El resultado es estable para "t2" (1000) mientras que durante algunas ejecuciones se observa que "t" oscila entre 995 a 1000. Es muy probable que el resultado varíe según la implementación del JRE y de la cantidad de procesadores del computador, pero en general, no hay garantía del incremento atómico de "t".

public class Volatiles implements Runnable {

	static volatile long t;
	static AtomicLong t2 = new AtomicLong(0);

	public static void main(String[] args) throws InterruptedException {
		for(int z = 0; z < 100 ; z ++) {
			Thread.sleep(10);
			for(int j = 0 ; j < 10 ; j ++) {
				new Thread(new Volatiles()).start();
			}
		}
		Thread.sleep(2500);
		System.out.println("T=" + t + " T2=" + t2.get());
	}

	@Override
	public void run() {
		try {
			Thread.sleep(1000 + (int) (Math.random() * 100));
		} catch(InterruptedException ex) {}
		t ++;
		t2.incrementAndGet();
	}

}

Miento en parte. Mi interés era probar Flightgear versión 2 que está disponible en Ubuntu Natty, pero como valor agregado probaría por fin el tan mencionado asunto.

Al principio nada fuera de lo usual: el clásico instalador, con una agradable diferencia: solicita algunos valores de configuración (como el nombre de host) mientras va haciendo la copia de los archivos del CD (lo cual es lógico pues la configuración sólo se aplica al final.)

Tras el reboot, nada fuera de lo común (lo común es aquí Ubuntu 10.04) salvo esa extraña barra de botones de la izquierda (el "dash")... detección correcta de la red inalámbrica, y a buscar el terminal para pegarlo en la barra de tareas como vengo haciendo desde hace muchos Ubuntus.... recordemos: aplicaciones->accesorios.... mmm... no hay menú de aplicaciones... muy extraño, pero no hay problema: en la práctica el menú es poco utilizado pues tengo lanzadores directos a mis 10 aplicaciones que cubren el 99% de mi uso diario. Buscando en el menú me encuentro con una especie de popup para navegar y/o buscar las aplicaciones, evidentemente orientado al principiante que nunca ha utilizado Ubuntu o Linux. Tipeo "terminal" y se lanza el programa. Ya tengo línea de comando... pero he tardado mucho. Habrá que acostumbrarse?

Otra vez el "dash": consciente de estar perdiendo toda objetividad, me atrevo a mencionar que dicho elemento (que es quizá el central en Unity) me produjo un Dejavú: mi mente retrocedió más de una década a la época de los window-manager menores, concretamente a esto (que para nuestros días luce abominable, especialmente con ese icono inferior de Netscape):

El "dash" parece que tiene más inteligencia de lo que parece, y es evidente que de algún modo puedo agregarle lanzadores de aplicaciones. No puedo arrastrarla a otra zona de la pantalla (algo que -salvando distancias- sí se podía hacer con Windows 95) aunque viendo los foros aparentemente hay manera de lograrlo. Revisando algunos sites como este, descubro que hay muchas cosas ocultas (y según los escritores todas muy buenas y muy productivas), y que el famoso dash tiene más inteligencia e indicadores de lo que aparenta. No encuentro con rapidez cómo minimizar una ventana (luego leo que debe poderse hacer usando el menú...) y a cada momento percibo con más fuerza que la papelera ocupa un cuarto de la pantalla (cosa que no es cierto, pero el inconsciente es un exagerado total.) Los menús de la aplicación se han ido fuera de la aplicación, lo cual en mi opinión no es intuitivo pero evidentemente ahorra algo de espacio; sin embargo, es claro que la lógica de dicha decisión es "una aplicación a la vez", como bien suele ocurrir en un smartphone o en una netbook.. y Unity es el sistema (shell o como se denomine) que provee consistencia (unifica?) el computador con el netbook, al parecer en detrimento del primero.

En algunos documentos se justifican algunas decisiones por ser más "Mac-like" (similares al entorno de Apple), pero esto creo que está muy equivocado. Como leí en un foro: si quiero un sistema Mac-like, entonces compro una Mac.

Y para terminar de incrementar mi decepción, Flightgear sigue con los mismos problemas de siempre. Ha sido un domingo decepcionante.

Pero su resolución de dependencias puede ser muy útil. Cómo crear un proyecto para el cual conocemos las "dependencias maven" pero no los JARs específicos?

Podemos crear un proyecto auxiliar con maven y configurar el POM respectivo... por ejemplo con el arquetipo quickstart. Luego procedemos a crear un package. Esto descarga todos los JARs necesarios a $HOME/.m2.

mvn archetype:create -DgroupId=com.americati -DartifactId=PROYECTO.mvn

cd PROYECTO.mvn

edit pom.xml

-> Agregar dependencias

Luego podemos "compilar", lo que descarga las dependencias.

mvn compile

Ahora podemos ejecutar el siguiente comando para extraer todas las dependencias (JARs) al directorio que querramos (por omision a target/dependency)

mvn dependency:copy-dependencies -DoutputDirectory=/tmp/mis-dependencias

Estos JARs se pueden agregar al classpath de nuestro proyecto real.

La autenticación normalmente se basa en un texto secreto (contraseña.) El caso más simple es el número de tarjeta de crédito, el cual en un pasado lejano sirvió para este propósito. Quién podría adivinar tremendos números? además, qué establecimiento serio intentaría hacer un fraude? Estas asunciones fueron perdiendo peso con el tiempo, y de manera total con el Internet. El PIN tiene la ventaja de haber sido concebido desde el principio como un valor secreto, pero las prácticas comerciales lo han invalidado. Por ejemplo, mi banco hasta hace poco me pedía tipear el PIN en el número de teléfono como parte de una llamada de servicio, como si la línea telefónica no fuera vulnerable.

La siguiente tendencia consiste en convertir al PIN en un elemento dinámico, con lo que obtenemos un token de generación temporal, o la remisión de un nuevo PIN por el servidor para cada transacción (la cual podría ser enviada por SMS.)  Esta autenticación múltiple ciertamente equivale a un password más difícil de comprometer, y brinda más seguridad al servidor. El problema es que no brinda más seguridad al usuario (phishing.)

La solución típica apunta al uso de certificados digitales que en teoría garantizarían que el usuario no sea engañado. Lamentablemente esto no funciona por sus graves fallos tanto en el cliente como en el servidor:

En el cliente

- Los usuarios no verifican que están accediendo mediante un canal seguro (el inocuo candado tan bien escondido en una esquina.)

- Los usuarios no comprenden la ventana de alerta con los problemas del certificado del servidor (cómo distinguirlo de un problema del disco duro? o de la línea de Internet? etc...)

- Los certificados comprometidos tardan en ser detectados por ciertos clientes (http://blog.dayspring-tech.com/2009/09/browser-security-ocsp-crl/)

En el servidor

- Los certificados digitales se vencen y es responsabilidad de cada administrador estar pendiente de esto, lo que normalmente no ocurre, lo que acostumbra a los usuarios a ignorar la advertencia del certificado

- Los certificados digitales tienen (en apariencia) costo elevado, y muchas entidades medianas los evitan por tal motivo; se cree que los que no tienen costo elevado no tienen la calidad suficiente

La solución a estos problemas es difícil; a mi entender se requiere un mecanismo de alerta para vencimiento de certificados, nuevos navegadores que exclusivamente utilicen conexiones con certificados, y alguna extensión al HTTP para que los navegadores tradicionales NO se usen para este propósito.

Una alternativa a mi entender más razonable consiste en proporcionar más control al usuario (o en todo caso, hacia su extremo.) Por ejemplo, en lugar de que el token sea exclusivamente enviado desde el usuario al servidor, el servidor podría (complementariamente) proporcionar un token al usuario, el cual sería validado por este último.

En general, creo que el problema de la actual guerra contra el phishing consiste en pretender proteger al usuario mediante el agregado de más medidas diseñadas para proteger al servidor.

Concepto: Documentos en los que la estrategia de la organización se describe en lo concerniente a la confidencialidad, integridad y disponibilidad de la información.

-> En realidad el documento es la manera de plasmar esta estrategia para poder ser transmitida con facilidad. El documento no es palabra sagrada!!!

Objetivos

Confidencialidad: la información debe tenerla sólo quien (por el criterio elegido) debe tenerla

Integridad: Protección de modificación no autorizada

Disponibilidad: La información se puede utilizar cuando se requiere

-> Estos son objetivos generales de la seguridad. Hay otros que interactúan, por ejemplo, evitar las falsificaciones, reducir el consumo de recursos indebidos, etc. que no necesariamente están referidos a la información.

Beneficios

El documento permite involucrar concretamente a las gerencias, por ende, dar más peso a la seguridad

Es una prueba para clientes y/o inversionistas de que la seguridad tiene importancia en la organización

Sirven como patrón para medir las ventajas de los productos de seguridad (en qué medida están alineados con la política) así como para medir la efectividad de la administración de seguridad

Permite delimitar responsabilidades

Sirve como guía de seguridad

Da poder al equipo de seguridad para tomar decisiones impopulares

-> Todo en la medida que las personas valores los documentos y no sean vistos como más papelitos para justificar un puesto

Definición

Riesgo -> Valor de la información x vulnerabilidad

Risk Profile -> Financiamiento

-> El riesgo es algo subjetivo! la experiencia proporciona un primer estimado. Métodos formales objetivos son imprácticos.

Oficial de Seguridad / Security Task Force

Define la estrategia de seguridad (conjuntamente con Gerencia)

Definir política de seguridad corporativa

Definir políticas de seguridad para sistemas específicos

Campañas de involucramiento de usuarios

Interacción con auditores de seguridad

-> Debe ser alguien que vive la seguridad, que respire el olor de los ataques, que disfrute la paranoia, que  conozca a fondo los sistemas.

Niveles de Seguridad

Unclassified -> Accesible públicamente

Shared -> Datos compartidos con personas de fuera de la organización

Company-only -> Sólo miembros de la organización

Confidential -> La persona debe estar en una lista de acceso

-> Y quién define esto? hay tiempo para definirlo para cada pieza de información? para mantenerlo actualizado? (wikileaks!)

Contenido de Política

- Ámbito/alcance

- Validez

- Propietario

- Responsabilidades

- Documentación de soporte

- Especificaciones

- Condiciones y plazos de revisión

- Cumplimiento/consecuencias

-> Deseable pero impráctico: mucha burocracia para mantener esto al día; lectura aburrida = pasa desapercibida

Ámbitos a considerar (dominios)

- Physical seurity

- Network security

- Access control

- Encryption

- Compliance

- Auditing and review

- Security awarness

- Incident response and disaster contingency plan

- Acceptable use policy

- Software security

- Key management

-> Ver dominios ISO y norma técnica peruana. Está bien como para empezar a pensar.

$ free
               total          used        free         shared    buffers     cached
Mem:       3574884    2120140    1454744          0     124012    1112440
-/+ buffers/cache:     883688     2691196
Swap:      3540984     202188    3338796

Cuál es la relación entre estos valores? El siguiente diagrama puede ayudar:

$ free
               total          used        free         shared    buffers     cached
Mem:       T=U+F       U              F             0           B            C
-/+ buffers/cache:      U-(B+C)    F+(B+C)
Swap:      ST=SU+SF  SU           SF

El sistema cuenta con "F" kb de memoria sin utilizar (este número nunca llega a ser cero.) U representa el espacio consumido, por lo que U+F debe corresponder al total de la memoria reconocida por el sistema operativo (la cual a su vez debería coincidir con la memoria física instalada, con ciertas consideraciones.)
B+C es memoria dedicada a "caching", la cual no es estrictamente necesaria pero contribuye de manera sustancial a mejorar el rendimiento del sistema por lo que tiende a crecer y apropiarse de toda la memoria disponible (sin embargo, es liberada si un proceso lo requiere.) En ese sentido, no es una memoria "estrictamente consumida por los procesos", la cual corresponde a "U-(B+C)" (segunda línea.)
La tercera línea corresponde al uso de las áreas swap configuradas. Este uso se incrementará en la medida que el espacio libre de la memoria se agote.

Crearemos una implementación que contenga un método stop() el cual interrumpa todos los threads bloqueados y que además interrumpa automáticamente a cualquier thread que quisiera leer o escribir en el futuro (en mi opinión este comportamiento es muy útil.) En ese sentido, la cola queda en "estado detenido". A continuación una primera implementación:

public class StoppableArrayBlockingQueue<E> extends ArrayBlockingQueue<E> {

private final java.util.Set<Thread> threadSet = new java.util.HashSet<Thread>();

private volatile boolean shutdown = false;

public void stop() {

shutdown = true;

java.util.Iterator<Thread> it = threadSet.iterator();
while(it.hasNext()) {
Thread thread = it.next();
it.remove();
thread.interrupt();
}
}

public StoppableArrayBlockingQueue(int n) {
super(n);
}

@Override
public void put(E e) throws InterruptedException {

if(shutdown) throw new InterruptedException("Cola detenida");
threadSet.add(Thread.currentThread());
super.put(e);
threadSet.remove(Thread.currentThread());
}

El código es bastante evidente; hemos sobrecargado a "put()" pero las ideas son similares para otros métodos de BlockingQueue. La variable "shutdown" requiere ser volatile para evitar problemas de visibilidad entre threads. Este código funcionará bien "casi siempre" pero puede presentar algunos problemas:

La iteración puede fallar si el threadSet es modificado concurrentemente. Esto se puede resolver sincronizando el loop así como las operaciones de agregado y eliminación contra el mismo threadSet.

El stop() puede ocurrir tras la consulta de "shutdown" pero antes del add(), en cuyo caso este thread nunca será interrumpido. Esto puede solucionarse sincronizando la consulta con la adición al Set:

@Override
public void put(E e) throws InterruptedException {

synchronized(threadSet) {
if(shutdown) {
throw new InterruptedException("Queue is down");
}

threadSet.add(Thread.currentThread());
super.put(e);
synchronized(threadSet) {
threadSet.remove(Thread.currentThread());
}

}

Puesto que los threads que utilizan "shutdown" están sincronizados al mismo objeto, esta variable ya no require ser "volatile".

Finalmente, si la interrupción llega tras el put()  pero antes del remove() entonces el thread retornará en estado interrumpido (el remove() no eliminará nada pero esto no da problemas.) Puesto que el método declara "throws InterruptedException" lo convencional será lanzar esta excepción si el thread se interrumpe, por lo cual haremos un test complementario:

synchronized(threadSet) {
threadSet.remove(Thread.currentThread());
}
if(Thread.currentThread().isInterrupted()) {
throw new InterruptedException("Queue is down");
}

Notar que el análisis de estado del thread está tras el bloque sincronizado de remove(). Se podría colocar antes del remove() siempre y cuando esté dentro del bloque sincronizado:

synchronized(threadSet) {

if(Thread.currentThread().isInterrupted()) {
throw new InterruptedException("Queue is down");
}

threadSet.remove(Thread.currentThread());
}

Si estuviera fuera del bloque, la interrupción podría ocurrir tras dicho análisis pero antes de aquél.

Spring requiere commons-logging, el cual a su vez utiliza log4j o JUL. Para aplicaciones pequeñas no justifica agregar log4j por lo que asumimos el uso (implícito) de JUL. Spring genera mensajes informativos en el arranque del contexto. Para evitarlos, agregar esta línea antes de su inicialización:

Logger.getLogger("").setLevel(Level.WARNING);

/* following the spring-ws conventions for the creation of endpoints */

package com.mycompany.hr.ws;

import java.io.StringWriter;

import javax.xml.transform.Source;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.stream.StreamResult;

import org.springframework.core.io.Resource;
import org.springframework.core.io.FileSystemResource;
import org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition;
import org.springframework.xml.xsd.SimpleXsdSchema;

public class Prueba {

public static void main(String[] args) throws Exception {
new Prueba();
}
public Prueba() throws Exception {
Resource s = new FileSystemResource(new java.io.File("/tmp/my-schema.xsd"));

SimpleXsdSchema sxs = new SimpleXsdSchema();
sxs.setXsd(s);
sxs.afterPropertiesSet();
DefaultWsdl11Definition d = new DefaultWsdl11Definition();
d.setSchema(sxs);
d.setPortTypeName("Poporoto");
d.afterPropertiesSet();
Source src = d.getSource();
StringWriter sw = new StringWriter();
StreamResult result = new StreamResult(sw);

TransformerFactory transfac = TransformerFactory.newInstance();
Transformer trans = transfac.newTransformer();
trans.transform(src, result);
System.out.println(sw.toString());
}
}

Caso de muestra:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="sumandosType">
<xs:sequence>
<xs:element name="sumando" maxOccurs="unbounded" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/>
<xs:manInclusive value="1000.0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>

Xmlstarlet al rescate:

$ xmlstarlet val esquema.xsd
esquema.xsd - valid

Esto demuestra que el esquema es válido desde el punto de vista de un documento XML, pero no desde el punto de vista de que se trata de un esquema. Para esto podemos utilizar:

xmlstarlet val -e -s http://www.w3.org/2001/XMLSchema.xsd esquema.xsd
esquema.xsd:9: element manInclusive: Schemas validity error : Element '{http://www.w3.org/2001/XMLSchema}manInclusive': This element is not expected.
esquema.xsd - invalid

AJA! a corregir manInclusive (cambiar por maxInclusive.)

El problema de esto es que estamos forzando a xmlstarlet a consultar el esquema del esquema al website de W3. Podemos descargar el esquema a fin de hacer la validación localmente. Asimismo, necesitamos descargar el esquema xml:

wget http://www.w3.org/2001/XMLSchema.xsd

wget http://www.w3.org/2001/xml.xsd

Y modificar el XMLSchema.xsd para  que su schemaLocation apunte a nuestro xml.xsd local (puesto que normalmente apunta al archivo en el web server de W3):

...

</xs:annotation>
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd">
<xs:annotation>
...

Ahora nuestra validación es más veloz y no dependemos de un sitio web externo:

xmlstarlet val -e -s XMLSchema.xsd esquema.xsd

Mercado fragmentado: WinME? sólo para fanáticos de Windows; fracaso tras fracaso, pero esto no impide que algún día den en el blanco. HP/Palm? por aquí ya no suena. Apple? a comprar Macs y aprender Objective-C. Y por supuesto, el $dolor$ de comprar los iPhones. Blackberry? mercado pequeño aunque pudiente, sin embargo despierta poco interés a futuro. J2ME? aún no hay SDK para MIDP 3.0 en Linux aunque pocos celulares lo soportan todavía; no despierta interés pero vence en ubicuidad. Android? algún día llegarán estos teléfonos, pero google es cool. Symbian? nunca más C++ (en todo caso incluirlo dentro del J2ME); Samsung bada-bada-bada? ...sobrevivirá un año más?

Por lo pronto ya funcionan nuestros prototipos descargables desde la web.

Al parecer esto se debe a que mi conexión a Informix es exclusivamente un socket TCP y a que la red presenta algunos problemas (los que yo atribuyo al driver de la tarjeta de red wireless el cual es un driver Windows emulado.) Al parecer la conexión dbaccess es muy sensible a estos fallos (a diferencia de la conexión JDBC que al parecer sí reintenta con éxito.)

Solución propuesta: habilitar la conexión IPC  vía shared memory para el dbaccess. Para esto, según:

http://www.tek-tips.com/viewthread.cfm?qid=726357&page=18

Agregaremos otro "alias" al servername:
/opt/informix/etc/sqlhosts:
instance1  onipcshm  127.0.0.1  dummy        # For shared mem conn.
instance2  onsoctcp  127.0.0.1  informix_lop # For network conn.

/etc/services:
informix_lop  1545/tcp

/etc/hosts
127.0.0.1    localhost

/opt/informix/etc/onconfig
DBSERVERNAME      instance1
DBSERVERALIASES   instance2
NETTYPE           ipcshm,1,50,CPU

Hasta el momento, funciona.

informix> INFORMIXSERVER=instance1 dbaccess

I Introducción

Con relativa frecuencia es menester efectuar copias voluminosas de estructuras de directorios o filesystems entre sistemas Unix. El presente documento intenta describir algunas alternativas que han resultado exitosas para servidores Alpha.

De no ser posible aplicar estos procedimientos por cuestiones de red, siempre se tiene la alternativa de efectuar las copias a unidades de tape, o incluso el movimiento físico de discos duros internos.

Los procedimientos en general son los mismos para las versiones 4.0 y 5.0 de Tru64 Unix.

A lo largo del texto supondremos que se copiará la información desde el computador “server_origen” hacia el computador “server_destino”.

I Activación de relaciones de confianza

En tanto las copias reportan ejecutar comandos en computadores remotos, la forma más sencilla consiste en establecer relaciones de confianza. Una manera consiste en definir como “confiable” al computador de origen en el computador de destino, lo cual se tiene que hacer en este último:

1. login en server_destino
2. Inscribir al server_origen en /etc/hosts añadiendo una entrada:

Server_destino# vi /etc/hosts

...

172.19.x.x server_origen

...

1. Activar la relación de confianza en /.rhosts añadiendo una entrada (no hay espacios en /.rhosts):

Server_destino# vi /.rhosts

...

server_origen

...

1. En caso de que el servidor de origen esté en cluster, recomiendo inscribir adicionalmente en el /etc/hosts y en el /.rhosts los ip físicos, el ip default alias, y el ip del servicio de cluster. Particularmente el ip default alias es crítico en la versión 5.
2. Es necesario tener en cuenta que esto activa relaciones de confianza para el usuario “root” por lo que se debe tomar las previsiones del caso. Al terminar las copias, eliminar la entrada añadida en el archivo .rhosts.

II Probar la relación de confianza

1. login en server_origen
2. Inscribir el server_destino en el archivo /etc/hosts si se desea (no es imprescindible.)
3. Ejecutar un comando rsh con root:

server_origen# rsh server_destino ls

(usar la dirección ip si no se ha efectuado el paso “b”.)

En caso de obtener “permission denied”, recapitular el procedimiento anterior (especialmente ver punto “d”) y ver el manual de rshd (que jamás me ha ayudado.) En caso de éxito (se obtiene la salida de “ls”) se puede seguir.

III Copiar un filesystem completo del computador local hacia un directorio del computador remoto

Ejecutar:

Server_origen# vdump –0f - /punto_de_montaje | rsh server_destino \

/sbin/vrestore –xf - -D /directorio_destino

Nota: el /sbin de vrestore es imprescindible.

IV Copiar un directorio completo del computador local hacia un directorio del computador remoto

Asumimos que se va a copiar el subdirectorio “/xxx/yyy/zzz” hacia el directorio /www/qqq. Esto creará el directorio /www/qqq/zzz y todo el interior.

Server_origen# cd /xxx/yyy

Server_origen# tar cf – zzz | rsh server_destino '(cd /www/qqq ; tar xvf - )'

Si lo que se desea es copiar sólo el interior de “/xxx/yyy/zzz” hacia el directorio /www/qqq (sin crear el subdirectorio “zzz”) entonces:

Server_origen# cd /xxx/yyy/zzz

Server_origen# tar cf – * | rsh server_destino '(cd /www/qqq ; tar xvf - )'

Esto último es menos confiable en tanto no copia los archivos ocultos del directorio /xxx/yyy/zzz (aunque sí los que estuvieran al interior.)

V Hacer un backup a tape en un computador que no tiene unidad de tape

1. Suponemos que “server_destino” tiene unidad de tape, mas no “server_origen”. Entonces, tras establecer la relación de confianza:
2. Averiguar el nombre del dispositivo de tape en “server_destino” (le llamamos /dev/cinta.)

Versión 5:

Server_destino# hwmgr –v d

(buscar “tape”...)

Versión 4:

Server_destino# file /dev/rmt*h

(buscar el que responda algún status)

1. Para sacar un backup de fileset, clonar si es necesario y luego aplicar:

Server_origen# vdump –0f - /punto_de_montaje | rsh server_destino \

/sbin/vrestore –xf /dev/cinta

Otra forma documentada equivalente:

Server_origen# rvdump –0 –f server_destino:/dev/cinta /punto_de_montaje

1. Para copiar una estructura de directorios arbitraria:

Server_origen# cd /xxx/yyy

Server_origen# tar cf – zzz | rsh server_destino '(cd /www/qqq ; tar xvf /dev/cinta )'

Sistemas Afectados

Todos los sistemas Tru64 UNIX V4x y V5x.

Consideraciones

Se requiere tener conocimiento previo acerca de si en el sistema en cuestión se usan raw devices para alguna aplicación (por ejemplo Oracle.)

Detalle

1.Obtener un listado de los dominios y filesets activos en el sistema. Esto se puede obtener con el comando df (en multiuser) o a partir del archivo /etc/fstab. Lo ideal es que ambos proporcionen la misma información, caso contrario esto debe ser corregido previamente.

2.Para cada dominio así obtenido debe existir un directorio dentro de /etc/fdmns. Pueden presentarse dos posibilidades:

1. Dominios activos que no están reflejados en directorios de /etc/fdmns (ver paso 3)

2. Directorios de /etc/fdmns que no están reflejados en dominios activos (ver paso 4)

3.Este caso se puede deber a una incorrecta eliminación del directorio en cuestión. Asumiendo que el dominio se llama “DOM”, es imprescindible recrear el directorio /etc/fdmns/DOM de acuerdo a los escenarios 3.1, 3.2, 3.3. Sin embargo es muy recomendable hacer una copia previa de la información contenida en los filesets comprendidos en el dominio a un lugar seguro mientras sean accesibles.

3.1. Se dispone de un backup reciente fácilmente accesible del filesystem / de este computador que supuestamente contiene el contenido del directorio DOM.

En este caso lo más conveniente consiste en restaurarlo en cualquier lugar adecuado y copiar el directorio DOM recién restaurado a /etc/fdmns. La prueba final consiste en desmontar los filesets asociados y volverlos a montar.

3.2. No se dispone de un backup reciente pero se tiene información acerca de qué dispositivos correspondían al dominio DOM.

Asumiremos que el dominio estaba asociado a los dispositivos físicos /dev/disk/dskx y /dev/disk/dsky. Como se sabe, cada dominio está asociado siempre a uno o más dispositivos. En este caso el procedimiento es:

# cd /etc/fdmns

# mkdir DOM

# cd DOM

# ln –s /dev/disk/dskx dskx

# ln –s /dev/disk/dsky dsky (hacer lo mismo con el resto de dispositivos)

Finalmente probar a desmontar y remontar los filesets.

3.3 No se dispone de ninguna información acerca de qué dispositivos comprendían el dominio DOM

Usar el comando showfdmn:

# showfdmn DOM

Id Date Created LogPgs Version Domain Name

3c6bf0e3.00015960 Thu Feb 14 12:16:19 2002 512 4 DOM

Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name

1L 12889184 2599360 80% on 512 512 /dev/disk/dsk5c

El cual nos proporciona el(los) dispositivo(s) asociado(s) en la última columna. Con esta información podemos ejecutar el procedimiento del paso 3.2.

4 Supongamos que existe un directorio “sobrante” en /etc/fdmns llamado “DIR_EXTRA” (/etc/fdmns/DIR_EXTRA) conteniendo un enlace al dispositivo /dev/disk/dskX. Este directorio sobrante existe como producto de:

• Alguien creó un dominio llamado DIR_EXTRA para uso temporal y olvidó registrarlo en el /etc/fstab.

• El contenido de este dominio fue movido a otro lugar (quizá otro servidor u otro storage) y el dominio no se eliminó a fin de poder retroceder en la operación.

Es necesario verificar que este dominio no esté apuntando a dispositivos reutilizados con otros fines (posiblemente otros dominios.) En ese sentido, debemos contrastar /dev/disk/dskX contra:

• Dispositivos raw devices en uso por alguna aplicación

• Dispositivo usado como swap (swapon –s)

• Dispositivos usados por otros dominios (ls –lR /etc/fdmns)

4.1 De haber alguna coincidencia, entonces el dispositivo dskX ya tiene otro uso y el antiguo dominio ya está destruido. En este caso se debe eliminar este directorio:

# rm –rf /etc/fdmns/DIR_EXTRA

4.2 De no haber ninguna coincidencia el dispositivo dskX podría contener información importante. En este caso debemos averiguar qué filesets están creados en éste:

# showfsets DIR_EXTRA

De producirse un error entonces no hay información disponible y se debe eliminar el directorio como en el paso 4.1.

De obtenerse un resultado semejante al que se muestra a continuación, entonces es menester intentar acceder a la información señalada:

# showfsets DIR_EXTRA

oracle

Id : 3d373c3c.0003b599.1.8001

Files : 7299, SLim= 0, HLim= 0

Blocks (512) : 19337414, SLim= 0, HLim= 0

Quota Status : user=off group=off

Object Safety: off

Fragging : on

DMAPI : off

ppstat

Id : 3d373c3c.0003b599.2.8001

Files : 68, SLim= 0, HLim= 0

Blocks (512) : 20573344, SLim= 0, HLim= 0

Quota Status : user=off group=off

Object Safety: off

Fragging : on

DMAPI : off

ppwork

Id : 3d373c3c.0003b599.3.8001

Files : 1828, SLim= 0, HLim= 0

Blocks (512) : 24757778, SLim= 0, HLim= 0

Quota Status : user=off group=off

Object Safety: off

Fragging : on

DMAPI : off

#

Siguiendo el ejemplo, apreciamos la existencia de tres filesets para el dominio DIR_EXTRA. En ese sentido crearemos tres puntos de montaje /x1, /x2, /x3 e intentaremos el montaje:

# mount DIR_EXTRA#oracle /x1

# mount DIR_EXTRA#ppstat /x2

# mount DIR_EXTRA#ppwork /x3

Se analizará a continuación si la información contenida en /x1, /x2, /x3 es útil. De ser así, es conveniente configurar los filesets adecuadamente en el archivo /etc/fstab. Si nada de esta información es útil, entonces debemos eliminar el dominio (previamente debemos desmontar los filesets:)

# umount /x1

# umount /x2

# umount /x3

# rmfdmn DIR_EXTRA

Share ]]> http://americati.com/blog/?feed=rss2&p=520 0 http://americati.com/blog/?p=518 http://americati.com/blog/?p=518#comments Thu, 26 Aug 2010 00:13:08 +0000 diego http://americati.com/blog/?p=518 Esto podría servir para algún administrador a cargo de un legendario Tru64...

Sistemas Afectados

Todos los sistemas Tru64UNIX V4x y V5x.

Consideraciones

Se requiere tener conocimiento previo acerca del volumen máximo aproximado de archivos que se almacenarán en el dominio.

Detalle

1.Conocido el valor aproximado de la máxima cantidad de archivos que se almacenarán en el nuevo dominio (en todos los filesets) es necesario obtener los valores recomendados para BMT Growth Size y BMT Prealloc Size de acuerdo a la tabla siguiente. Esto es especialmente crítico si el número de archivos a almacenarse es muy elevado:

Número de archivos en el dominio	BMT Growth Size	BMT Prealloc Size
< 50000	128 (default)	3600
100000	256	7200
200000	512	14400
300000	768	21600
400000	1024	28800
800000	2048	57600

2. Crear el dominio usando las opciones –x y –p para designar el Growth Size y el BMT Prealloc Size respectivamente. Por ejemplo para un dominio que contendrá un millón de archivos podemos usar:

# mkfdmn –t advfs –x 2048 –p 57600 /dev/disk/dsk?? DOMAIN_NAME

3. De igual modo, si se añaden volúmenes al dominio debemos emplear los parámetros –x y –p:

# addvol –x 2048 –p 57600 /dev/disk/dsk?? DOMAIN_NAME

4. A fin de analizar con qué parámetros ha sido creado un dominio se puede usar el comando /sbin/advfs/vbmtpg.

Share ]]> http://americati.com/blog/?feed=rss2&p=518 0 http://americati.com/blog/?p=516 http://americati.com/blog/?p=516#comments Thu, 26 Aug 2010 00:11:48 +0000 diego http://americati.com/blog/?p=516 Este examen fue tomado el año 2003 o 2004; quizá le sea útil al interesado en el tema.

1 Cuando Ud. envía un mensaje de email a un destinatario cuya cuenta está en el servidor de correo local (el que Ud. emplea para el envío), el mensaje es enrutado usando:

1. El registro MX correspondiente a la parte de host de la dirección de destino
2. El archivo /etc/aliases o en su defecto el archivo /etc/mail/mailertables
3. No es enrutado pues queda en el servidor local hasta ser recogido por el usuario destinatario
4. El registro A correspondiente al mailserver al que apunta el registro MX
5. El registro A en el DNS correspondiente a la estación de trabajo donde está conectado el usuario destinatario

2 Si su computador Linux tiene una interfaz de red ethernet con un IP asignado por el administrador, así como una máscara definida, y asumiendo que está directamente conectado al Internet, qué es necesario además configurar (en su computador) para conectarse vía telnet a un servidor ubicado en Finlandia con dirección IP 67.38.12.123?

1. El ip del servidor DNS primario
2. El ip del default gateway
3. El archivo /etc/hosts

4. La MAC address de la interfaz ethernet

5. El demonio xinetd vía el comando setup

3 El guión (-) usado como archivo tar (tarfile) indica a este comando que debe emplear la salida o entrada estándar en lugar de una cinta o un archivo regular. Se quiere copiar el contenido del directorio /opt1 (con sus subdirectorios) hacia el directorio /mktu usando sólo este comando. ¿Cómo lo haría?

1. tar cvf - /mktu | tar xvf /opt1
2. (cd /opt1 ; tar cvf - . ) | (cd /mktu ; tar xvf - )

3. tar cvf - /opt1 | tar xvf -

4. tar cvf - /opt1 | tar xvf /mktu

5. N.A.

4 ¿En qué puerto “escucha” el servidor Web con que opera WEBMIN?

1. 80
2. 8000
3. 1000
4. 10000
5. 752

5 Cuál es el tiempo de vida de los registros DNS?

1. 1 día
2. 1 minuto
3. 2 minutos
4. 1 hora
5. Es configurable en cada zona y registro

6 El protocolo usado por sendmail en trasmisiones TCP/IP:

1. POP

2. IMAP

3. SMTP

4. SNMP

5. UDP

7 El mejor motivo para emplear la última versión de BIND (9.2.x) es:

1. Configuración simplificada
2. Seguridad mejorada
3. Performance elevada
4. Modesto consumo de recursos
5. Todas las anteriores

8 Para usar Virtual Hosting en Apache usando una sola dirección IP al que apuntan diversos dominios de modo simultáneo haciendo la diferenciación por el nombre del dominio, es necesario:

1. Web Browsers con HTTP 1.1

2. Crear alias para la interfaz de red por cada dominio
3. Usar un número de puerto distinto por cada dominio
4. Instalar APACHE desde la fuente
5. Usar NAT

9 Los directorios compartidos vía NFS se especifican en el archivo:

1. /etc/networks

2. /etc/nfsd.conf

3. /etc/nfs.conf

4. /etc/exports

5. /etc/mtab

10 ¿Cuál de los siguientes tipos de registros DNS no es normalmente empleado? (sug. Ver archivos de zonas creados por bindconf.)

1. SOA

2. NS

3. PTR

4. HINFO

5. MX

11 Si las direcciones de correo electrónico de su organización son de la forma: usuario@correo.oligoceno.macrobio.tg, y el servidor se llama ikarius.oligoceno.macrobio.tg, entonces debemos inscribir:

1. correo.oligoceno.macrobio.tg en /etc/mail/local-host-names
2. oligoceno.macrobio.tg en /etc/mail/local-host-names
3. macrobio.tg en /etc/mail/local-host-names
4. correo.oligoceno.macrobio.tg en /etc/aliases
5. oligoceno.macrobio.tg en /etc/aliases

Resuelva uno de los siguientes problemas. Ud. sólo debe escoger uno de ellos (10 puntos)

A En una organización se dispone de un conjunto de desarrolladores HTML, PERL y JAVA que desarrollan portales a publicarse en el servidor WEB apache de la misma. Estos usuarios han sido asignados al grupo webdevel a fin de facilitar la compartición de la información entre ellos.

Se desea que todos los usuarios pertenecientes al grupo webdevel puedan modificar los documentos servidos por Apache. Asuma que los usuarios ya existen y son muchos. Asuma que también existe el grupo webdevel. Asuma que Apache ha sido instalado de modo estándar desde un RPM en RedHat. Escriba todos los comandos necesarios para lograr esto, justificando cada uno de estos. Ud. puede realizar diversas asunciones (si no contradicen el presente enunciado), las cuales deberán indicarse.

B Se dispone de un conjunto de sistemas con espacio reducido de disco. Se desea aprovechar NFS para montar remotamente el directorio /usr al momento de boot. Un sistema (llamado server-01) contiene una instalación full de Linux. Los otros fueron instalados en forma normal, sin embargo la partición asignada a /usr se reasignará al filesystem /oracle para almacenar información local, por lo que se empleará el /usr de server-01 en todos los casos.

En el servidor ya está compartido el directorio /usr para toda la red. Ud. debe escribir todos los pasos necesarios a realizarse en los clientes para lograr este cometido. Asuma que el cliente todavía tiene la partición del futuro filesystem /oracle asignada a /usr. Los sistemas cliente no se reparticionarán (se mantienen los tamaños de las particiones.) El esquema actual en los clientes es:

Share ]]> http://americati.com/blog/?feed=rss2&p=516 0