El otro día intentando resolver algunos problemas en una "pequeña" red me encontré con una de esas cosas que hacía tiempo que no veía.
Tan acostumbrado a trabajar con distintas tecnologías y de distintas capas a veces cuesta diferenciar y resolver problemas de "capas" inferiores. Que se bloquea el equipo, cambialo, que se pierde conectividad, debe de ser el cable..etc..
Pero cuando todas las pruebas de campo son correctas, puede que, en una red conmutada de más de 15 switches, y con apilamientos de hasta 6 switches..a lo mejor se nos olvida algo. Tres switches más allá de donde yo me encontraba, allí estaba el error. Un pequeño cable mal conectado, en el switch equivocado, y toda la red, bloqueada.
El orígen de las tormetas de broadcast es dificil de detectar, sobretodo si la red es muy grande y los switches de los que dispones son de capa 2 y no gestionables.
Por eso una buena documentación y tener marcados el cableado (que aunque parezca mentira es demasiado habitual encontrarse un cableado "anónimo") es básico, desde mi punto de vista lo más importante en una situación de este tipo, por supuesto el uso de algún analizador de red si es necesario y mucha... paciencia. Al final, se consigue.
Un saludo a tod@s
jueves, 21 de octubre de 2010
miércoles, 6 de octubre de 2010
VirtualBox como servicio en Windows 2003 R2
Aunque existe bastante información al respecto esta es una de las maneras más sencillas. A priori es facil hacer que la máquina se inicie con cualquier script. El problema nos lo encontramos a la hora de apagarla. De esta manera la maquina se inicia automaticamente pero además cuando realizamos un reinicio o un apagado también se apaga la maquina virtual guardando el estado en el que estaba.
Fuente: http://forums.virtualbox.org/viewtopic.php?f=6&t=15164&p=63254#p106961
Thank you egoz.
Requerimientos:
- Oracle VM VirtualBox con al menos una máquina virtual
- Java SE Runtime
- vBoxProcrun: Preparado por egoz para integrar el servicio de virtualbox y basado en el proyecto Apache Daemon´s Procun, en la descarga se incluye el src para cualquier modificación. Descarga VboxProCrun
Pasos a seguir:
- Detener las maquinas virtuales activas
- Copiar la carpeta ".VirtualBox" del perfil del usuario al perfil LocalService o en su defecto copiar el archivo VirtualBox.xml y modificar las rutas en su interior a rutas absolutas que apunten a la ubicación de los discos y las máquinas virtuales.
Para poder acceder al perfil LocalService deberemos desmarcar "Ocultar archivos protegidos del sistema operativo" en Herramientas-Opciones de Carpeta-Ver
- Crear la variable de entorno de usuario JAVA_HOME.
Nombre de la variable: JAVA_HOME
Valor de la variable: C:\Archivos de programa\Java\jre6
- Crear la variable de entorno de sistema VBOX_USER_HOME
Nombre de la variable: VBOX_USER_HOME
Valor de la variable:C:\Documents and Settings\LocalService\.VirtualBox
Es importante crearla en las Varibles de sistema no de usuario.
- Descomprimir VBoxProcrun.zip en por ejemplo c:\VboxProcrun
- Modificar la clase ubicada en \classes\vboxprocrun\vboxprocrun.properties con las rutas correctas y el nombre de la máquina.
startupCommand= C:\\Archivos de programa\\Oracle\\VirtualBox\\VBoxHeadless.exe -startvm debian
shutdownCommand= C:\\Archivos de programa\\Oracle\\VirtualBox\\VBoxManage.exe controlvm debian savestate vBoxDir= C:\\Archivos de programa\\Oracle\\VirtualBox\\
- Instalar el servicio mediante el comando vboxprocrun.bat install nombre_servicio
- Configurar el servicio Tipo inicio: Automático
- Reiniciar el equipo. Sin reinciar es posible que no adquiera la configuración de las variables de entorno.
- Para realizar la desinstalación vboxprocrun.bat remove nombre_servicio
Se almacena un log en C:\VBoxProcrun\log.
Ante cualquier error verificar el nombre de la máquina en el archivo vboxprocrun.properties y que la variable de entorno de sistema esté correctamente creada ya que sino el servicio no tendrá acceso a la ubicación de las máquinas y obtendremos el error: Invalid machine name!
Un saludo a tod@s!
Fuente: http://forums.virtualbox.org/viewtopic.php?f=6&t=15164&p=63254#p106961
Thank you egoz.
Requerimientos:
- Oracle VM VirtualBox con al menos una máquina virtual
- Java SE Runtime
- vBoxProcrun: Preparado por egoz para integrar el servicio de virtualbox y basado en el proyecto Apache Daemon´s Procun, en la descarga se incluye el src para cualquier modificación. Descarga VboxProCrun
Pasos a seguir:
- Detener las maquinas virtuales activas
- Copiar la carpeta ".VirtualBox" del perfil del usuario al perfil LocalService o en su defecto copiar el archivo VirtualBox.xml y modificar las rutas en su interior a rutas absolutas que apunten a la ubicación de los discos y las máquinas virtuales.
Para poder acceder al perfil LocalService deberemos desmarcar "Ocultar archivos protegidos del sistema operativo" en Herramientas-Opciones de Carpeta-Ver
- Crear la variable de entorno de usuario JAVA_HOME.
Nombre de la variable: JAVA_HOME
Valor de la variable: C:\Archivos de programa\Java\jre6
- Crear la variable de entorno de sistema VBOX_USER_HOME
Nombre de la variable: VBOX_USER_HOME
Valor de la variable:C:\Documents and Settings\LocalService\.VirtualBox
Es importante crearla en las Varibles de sistema no de usuario.
- Descomprimir VBoxProcrun.zip en por ejemplo c:\VboxProcrun
- Modificar la clase ubicada en \classes\vboxprocrun\vboxprocrun.properties con las rutas correctas y el nombre de la máquina.
startupCommand= C:\\Archivos de programa\\Oracle\\VirtualBox\\VBoxHeadless.exe -startvm debian
shutdownCommand= C:\\Archivos de programa\\Oracle\\VirtualBox\\VBoxManage.exe controlvm debian savestate vBoxDir= C:\\Archivos de programa\\Oracle\\VirtualBox\\
- Instalar el servicio mediante el comando vboxprocrun.bat install nombre_servicio
- Configurar el servicio Tipo inicio: Automático
- Reiniciar el equipo. Sin reinciar es posible que no adquiera la configuración de las variables de entorno.
- Para realizar la desinstalación vboxprocrun.bat remove nombre_servicio
Se almacena un log en C:\VBoxProcrun\log.
Ante cualquier error verificar el nombre de la máquina en el archivo vboxprocrun.properties y que la variable de entorno de sistema esté correctamente creada ya que sino el servicio no tendrá acceso a la ubicación de las máquinas y obtendremos el error: Invalid machine name!
Un saludo a tod@s!
lunes, 4 de octubre de 2010
Subnetting práctico
Cuando comenzamos un proyecto siempre pensamos que las cosas van a poder llevarse a cabo como a nosotros nos gustarían...pero rara vez es así, a menudo existen muchas limitaciones que habitualmente habremos tenido en cuenta ;)
Hace poco llevé a cabo la ampliación de una red wifi de una población; que poco gusta ampliar sobretodo porque todo lo que hay de antes es.. "antiguo" y para poder "aprovechar" la infraestructura a veces hay que vérselas.
Entre otras cosas uno de los problemas que me encontré es que los actuales clientes (200 aprox.) tenían IP´s fijas y eso no podía cambiar por "comodidad" para ellos. A todos los nuevos clientes se les asignaría mediante dhcp y deberían validarse con usuario y contraseña para usar la wifi.
La solución elegida para llevar a cabo un control de los nuevos ap´s y ofrecer acceso a través de un portal cautivo requería que todos los equipos estuviesen en la misma red. Lo cual lleva a intentar proteger al máximo los intentos de acceso desde equipos cliente a los AP´s.
Además de limitar en los propios ap´s las direcciones desde donde acceder a ellos, estos ap´s tenían que estar visibles en la red para que el controlador wlan pudiese recuperar la información de cada ap, visibles en la misma red donde estaban todos los clientes.
El problema es que los antiguos clientes ya tenían su mascara y puerta de enlace configurada y el nuevo equipo tendría que llevar la misma dirección (x.x.0.1)
La solución adicional adoptada fueron subredes.
Subnet Controlador Wireless y clientes
Dirección: x.x.0.0 x.x.0000 0000.00000000
Mascara: 255.255.240.0 = 20 11111111.11111111.1111 0000.00000000
Subnet AP´s
Dirección: x.x.0.0 x.x.00000000.000 00000
Mascara: 255.255.255.224 = 27 11111111.11111111.11111111.111 00000
De esta manera mientras que los clientes tiene acceso a toda la red, los ap´s sólamente tienen acceso a los 30 primeros hosts de la red, 23 de esas direcciones ocupadas por los propios ap´s.
Con lo cual aunque en la práctica los clientes si acceden a los ap´s, nunca reciben respuesta de éstos.
No vamos a entrar en lo sencillo que sería para un usuario ligeramente avanzado conocer estos datos, pero si decir que es una solución rápida y eficaz de cara al usuario normal o el que simplemente tiene mucho tiempo libre.
Saludos a tod@s!
Hace poco llevé a cabo la ampliación de una red wifi de una población; que poco gusta ampliar sobretodo porque todo lo que hay de antes es.. "antiguo" y para poder "aprovechar" la infraestructura a veces hay que vérselas.
Entre otras cosas uno de los problemas que me encontré es que los actuales clientes (200 aprox.) tenían IP´s fijas y eso no podía cambiar por "comodidad" para ellos. A todos los nuevos clientes se les asignaría mediante dhcp y deberían validarse con usuario y contraseña para usar la wifi.
La solución elegida para llevar a cabo un control de los nuevos ap´s y ofrecer acceso a través de un portal cautivo requería que todos los equipos estuviesen en la misma red. Lo cual lleva a intentar proteger al máximo los intentos de acceso desde equipos cliente a los AP´s.
Además de limitar en los propios ap´s las direcciones desde donde acceder a ellos, estos ap´s tenían que estar visibles en la red para que el controlador wlan pudiese recuperar la información de cada ap, visibles en la misma red donde estaban todos los clientes.
El problema es que los antiguos clientes ya tenían su mascara y puerta de enlace configurada y el nuevo equipo tendría que llevar la misma dirección (x.x.0.1)
La solución adicional adoptada fueron subredes.
Subnet Controlador Wireless y clientes
Dirección: x.x.0.0 x.x.0000 0000.00000000
Mascara: 255.255.240.0 = 20 11111111.11111111.1111 0000.00000000
Subnet AP´s
Dirección: x.x.0.0 x.x.00000000.000 00000
Mascara: 255.255.255.224 = 27 11111111.11111111.11111111.111 00000
De esta manera mientras que los clientes tiene acceso a toda la red, los ap´s sólamente tienen acceso a los 30 primeros hosts de la red, 23 de esas direcciones ocupadas por los propios ap´s.
Con lo cual aunque en la práctica los clientes si acceden a los ap´s, nunca reciben respuesta de éstos.
No vamos a entrar en lo sencillo que sería para un usuario ligeramente avanzado conocer estos datos, pero si decir que es una solución rápida y eficaz de cara al usuario normal o el que simplemente tiene mucho tiempo libre.
Saludos a tod@s!
Suscribirse a:
Entradas (Atom)