sábado, 3 de septiembre de 2011

Configurar el ingreso al setup en VM VMWare

How to force VM to enter BIOS Setup mode on next boot up

Algo tan necesario pero que me ocasiono un dolor de cabeza es ingresar al setup de un vm en vmware, mas aun sino se tiene las teclas directas F2, F3, etc.
Bueno algo bien simple es editar una opcion en las propiedades de la vm (Esta en ingles):

As you may aware, we all had difficulty before this to select the boot option or BIOS setup mode during a VM startup or reboot. That is because the virtual center console delay respond and others reason, we always miss the option we need. Now, we do not require to press or reset the VM for multiple time. It can be easily force to enter BIOS mode for a VM on next reboot. 1st, right click the VM you would like to configure and select edit settings. Click on the option tab and choose on the boot option. At your right hand site, you will see the force BIOS setup. Check the box to force the VM entry to BIOS setup screen and click ok. The setting is done after that. On the next reboot, the VM will automatically go in to BIOS setup mode and you can configure the boot option priority as you need.


Saludos





sábado, 19 de marzo de 2011

Libros basicos de todo Administrador Linux

.
.
.
Para aquellos que me estaban solicitando los libros de linux, aqui uno basico para todo aquel que quiera dar soluciones en redes linux.
Este libro es una guia avanzada y expresa con ejemplos las situaciones reales que pueden pasar en un entorno de produccion.
Los ejemplos y herramientas estan en linux, pero el analisis y los beneficios que le podemos sacar no se limita solo a linux, sino a cualquier sistema operativo, ya que la teoria no cambia pero la manera de tomar accion si.

Bueno yo le dia una leida y me sirvio bastante, hai te das cuenta lo poco que sabes.
Les recomiendo, incluso algunos pueden ahondar mas en temas especificos.

Y si eres docente este libro cae a pelo.

Pero que es lo que trae este libro:

1. Prólogo a unaGuía Práctica.
2. Protocolos de la capa de enlace.
3. Protocolos de la capa de Red.
4. Protocolos de la capa de Transporte.
5. Protocolos de la capa de Aplicación.
6. Un Patrón de solución de problemas.
7. Antes de que las cosas se estropeen, construcción de una Base.
8. En el momento, estudios de casos.
9. Herramientas de Resolución de Problemas.
10. Herramientas de Revisión.
11. Herramientas de Seguridad.
A. RFC-1122.
B. Requisitos de los hosts de internet, aplicación y transporte.
C. Licencia de publicación abierta.

Finalmente, este es la guia avanzada, esta en ustedes ayudarme a ubicar la guia basica y si ya sacaron nuevas versiones de este libro.

Datos Tecnicos:
Redes Linux con TCP/IP – Guia Avanzada (PRENTICE-HALL)
Editorial: Pearson Prentice Hall | October 2001 | ISBN: 8420531561 | 432 Pages | Language: Spanish | PDF | 16Mb | Pat Eyler (Author), Vox Populi, S.L. (Translator)


En espera de sus comentarios.

Google SSL


Si aprecias tus busquedas google y no quieres que te apliquen un "sniffer" usa google-ssl:

https://www.google.com

Es super util y protege el trafico de tus busquedas de todo intruso que quiera escuchar tu info.
Ademas debe ser de uso habitual de aquellos que trabajan en temas de seguridad o cuando estas en una empresa y no sabes que es lo que puede estar pasando en la red.
Recuerden, no hay que dar tregua a los intrusos.




lunes, 17 de enero de 2011

MAINFRAMES

Un dia me hice una pregunta al tratar de explicar la arquitectura que deberia tener un servidor para realizar algunas consultas (1000 al instante) y surgio una gran duda , ¿Que tanto influye esta concurrencia en la arquitectura de los sistemas ? Por ejemplo que cambio se debe realizar para pasar de 1000 consultas concurrentes a tener 10000? . Se que algunos diseños no se prestan para ello , tenemos empresas con redes segmentadas, con servicios que no son publicos, pero que de aquellos que estan aptas para todo el mundo o que de aquellas con gran volumen transaccional como los bancos.

A partir de ello me he cuestionado seriamente en descubir las arquitecturas de estos grandes sistemas (Algo que no lo encontrare en pdf en la Web). Sin embargo partiremos de los mas basico:

Que SO y/o Apps usan las grandes compañias, bancos, etc?

Qeu arquitectura soporta las aplicaciones que tenemos hoy (Facebook, Gmail, Hotmail, etc).

Pues quizas haya algunos diseños avanzados en ello, o quizas se esta hablando de procesamiento distribuido o de clustering.

He aqui una serie de post repasando estos grandes sistemas de procesamiento masivo y rapido en busca de enternder el como de las cosas.

Iniciaremos con una estracto de bibliografia sobre los mainframes de IBM ( z/Series) con su SO: Z/OS:


Su Sistema Operativo por excelencia es, hablando con propiedad, el único Sistema Operativo que existe (se trata del antiguo MVS, que tras varios cambios de nombre ahora se llama z/OS; IBM ofrecía también por aquella época, en los años 70 y 80, el DOS/VSE, igual que ahora también ofrece Linux para z/Series, ignoro con qué éxito comercial).

Cuando se enumeran las funciones y características que, teóricamente, debe tener todo Sistema Operativo, sólo MVS (perdón, z/OS; es que todos los que hemos trabajado con él le seguimos llamando “MVS”) cumple todas ellas. Por ejemplo:
1- Disponibilidad total. IBM dice en su marketing que tiene un 99,999% de disponibilidad, y no sólo es cierto, sino que yo creo que es un 100%. De hecho, los mainframes de IBM sólo suelen apagarse una vez al año (generalmente en Navidades, Viernes Santo, o así), más bien por el prurito de hacer un Arranque en Frío al menos una vez al año (o sea, apagar y encender, vaya) y así limpiar la memoria de posibles zonas muertas, que porque haga realmente falta.

2- Independencia del Sistema Operativo de las Aplicaciones (incluso las propias del Sistema).
Es decir, absolutamente todos los productos, sean cuales fueren, se pueden instalar en caliente, sin necesidad de apagar y encender nada. Esto reza incluso para el propio Sistema Operativo: se puede subir de versión sin necesidad de pararlo. Y desde luego, para todos los productos, por críticos que resulten: IMS, CICS, DB2, RACF, VTAM, etc. Y, por descontado, el MVS (perdón otra vez, el z/OS, la costumbre…) no se cae nunca. Al menos, yo no lo he visto en años.

3- Absoluta garantía de que una partición no puede acceder a datos de otra,
ni por error, ni a posta. Además, no hay virus (al menos, que yo conozca) para mainframes: la seguridad es máxima.

4- Capacidad de configurar varias máquinas lógicas (particiones) dentro de una única máquina física.
Con ello se puede trabajar como si tuviéramos tres o cuatro máquinas diferentes, más pequeñas, pero que se comportan a todos los efectos como si fueran máquinas físicas diferentes. Además, la partición se realiza no distribuyendo partes físicas de la máquina (canales o procesadores, por ejemplo) sino por MIPS. Podemos definir una máquina de 150 MIPS, otra de 400 MIPS y otra de 700 MIPS, por ejemplo. Y, naturalmente, se puede reconfigurar los tamaños de cada partición en cualquier momento… y sin parar nada, claro.

5- Rendimiento combinado inalcanzable para cualquier otra máquina.
Por ejemplo, un mainframe típico (no el más grande, repito) es capaz de dar servicio él solo a:
500 ó 600 trabajos batch (en la jerga “mainframera”, iniciadores), donde se están ejecutando trabajos batch: liquidaciones, extractos de cuentas, abonos de dividendo, tareas de backup, pruebas de programas, etc, todo lo que no necesite hacerse online. No 500 ó 600 al día, no. 500 ó 600 a la vez, continuamente, todo el día sin parar, todo el año sin parar.
Varios gestores de teleproceso diferentes (IMS ó CICS), sirviendo cada uno algunos millones de transacciones online diarias. Para que os hagáis una idea: un Banco nacional típico puede tener quizá diez o quince millones de transacciones online diarias, una operadora de Telecomunicaciones, quizá registre 80 millones de llamadas diarias, etc: se procesa online muchísima información hoy en día. ¿Os hacéis una idea de la tasa de transacciones por segundo que supone esta carga?… 200, 300, 400 transacciones por segundo, cada segundo, todos los segundos. Son realmente muchas. Estas transacciones, habitualmente subsegundo, pueden ser servidas por uno sólo de estos gestores, por ejemplo, un IMS. Y suele haber otros gestores de Teleproceso dedicados a otras cosas, como la Contabilidad, los Seguros, etc.
Varios centenares de particiones de time-sharing, el famoso TSO, (donde cada usuario ve la máquina como si fuera literalmente para él solo). Por ejemplo, programadores editando y compilando programas, usuarios finales lanzando peticiones de información, operadores gestionando el sistema, etc. Con tiempos de respuesta generalmente subsegundo también.
…SIMULTÁNEAMENTE. Es decir, todo lo anterior, a la vez. Un mainframe de IBM está habitualmente usando su CPU (todas ellas) al 100%. Horas y horas, días y días, meses y meses, sin parar. Es normal verlo incluso al 102% (cosa aparentemente imposible, debida al prefetch de instrucciones, que permite ganar algo de tiempo al solapar la ejecución de instrucciones consecutivas). Y no pasa nada. Muchos otros sistemas operativos, al llegar al 80% de uso de CPU comienzan a dar señales de lentitud. Y a partir del 90%, se vuelven inestables. El z/OS, no. Es más, casi todos los que trabajamos normalmente con ellos “sabemos” que cuando están a menos del 90%, están “vagos”, como si les costara más de lo normal despachar los diferentes trabajos… Vale, ya lo sé, es una sensación que no tiene base alguna, pero es que la tenemos mucha gente…

Como habeis observado este sistema ya habia hecho uso del concepto de virtualizacion desde hace mucho tiempo, sorprende tambien su sistema de alta disponibilidad.

Otra cosa es que son usados para proteger grandes negocios que su criticidad lo requeria y sea de un riesgo paranoico, desesperacion que es aprovechada por IBM que no te vende la solucion , mas bien te la "alquila" de hai la facturacion de esta empresa en el ranking mundial.

Bueno luego les traere otros estractos de estos grandes sistemas.