Comandos Basicos para VMware ESXi

En muchos casos es mucho mas rápido (y fácil) realizar algunas operaciones vía comandos que realizarlos mediante interface gráfica, otras veces hay algunas acciones que no se pueden realizar vía la interface gráfica, como por ejemplo, en el caso de VMWare no tenemos la opción apagar forzosamente una maquina virtual (o "force stop") en Vsphere Client. Por eso les dejo aquí algunos comandos para VMWare ESXi 4.1 y 5 que creo les podrían ser de utilidad, claro deben tener activado el acceso ssh en sus servidores, si aun no lo tienen pueden ver aquí como hacerlo.

• Listar las Maquinas Virtuales

Para ver el listado de las maquinas virtuales creadas en el host ejecutamos:

vim-cmd vmsvc/getallvms

Esto nos presentara el listado de las maquinas virtuales creadas con el ID de las maquinas (vmid) que se utilizara en los siguientes comandos, el nombre de la VM, la ruta del archivo y el DataStore donde se encuentra, el tipo de Sistema Operativo (el que se indica cuando se crea la VM) y la version de la maquina virtual.

• Ver status de una VM

Si queremos conocer si una de las maquinas virtuales que listamos con el comando anterior esta encendida o apagada, ejecutamos:

vim-cmd vmsvc/power.getstate <vmid>

Donde como ya imaginaran, remplazaremos  mid

> por el ID de la maquina virtual que queremos verificar.

• Encender una VM

Si una de las maquinas virtuales esta apada, podemos encenderla utilizando:

vim-cmd vmsvc/power.on <vmid>

• Apagar una VM

Si queremos apagar "amablemente" una de las maquinas virtuales, o sea, pidiéndole decentemente que por favor se apague, podemos usar el siguiente comando:

vim-cmd vmsvc/power.shutdown <vmid>

Si de la forma amable no responde, ejecutamos:

vim-cmd vmsvc/power.off <vmid>

• Forzar Apagado de una VM

Si al intentar apagar una maquina virtual, ya sea usando el Vsphere Client o usando los comandos anteriores, la maquina no responde y no llega a apagarse, podemos forzar el apagado usando la utilidad esxcli. Primero necesitaremos el "WorlNumber" de la maquina que queremos apagar, ejecutaremos:

Para ESXi 5:

esxcli vm process list

Para ESXi 4.1:

esxcli vms vm process list

Esto nos arrojara un listado con las VMs que tenemos actualmente y también veremos el "Worl ID" de cada una. Cuando hayamos identificado el que corresponde al equipo que queremos forzar a apagar ejecutamos entonces:

Para ESXi 5:

esxcli vm process kill --type=force --world-id=<WorldNumber>

Para ESXi 4:

esxcli vms vm process kill --type=force --word-id=<WorldNumber>

• Informacion del Hardware del Host

Para ver la información de hardware del host donde tenemos instalado VMWare ESXi, como la cantidad de procesadores y tipo, la cantidad de memoria RAM que soporta, la cantidad de slots que de memoria que tiene el Motherboard, el tamaño de cada DIMM de memoria, entre otros, podemos usar el siguiente comando:

smbiosDump

Este comando nos traerá una extensa lista de todos los componentes del equipo, esto es muy util si, por ejemplo, están planeando un upgrade de memoria para su servidor y quieren saber cuando les soporta, cuantos DIMMs tiene instalados y cuantos slots tienen disponible, etc.

Información Capacidad Memoria RAM  Soportada

Como ven esto nos muestra información del tipo de memoria que tenemos en el equipo y la cantidad que soportaría. Bueno como siempre espero que esto les sea de utilidad, hasta el próximo!

Exportar/Importar Permisos NTFS de Carpetas y Subcarpetas usando ICACLS

Aquí les tengo un corto post sobre algo que (como prácticamente todo lo que les escribo aqui) tuve que utilizar recientemente. Supongan que tienen una carpeta que contiene otras subcarpetas y archivos, cada subcarpeta tiene permisos específicos al igual que los archivos, y con el tiempo se han ido agregando otros usuarios a esta carpeta con diferentes privilegios, y que un día, este folder se borra (o lo borran) o lo tienes que copiar a (o restaurar desde) una unidad, por ejemplo FAT32 donde se perderán todos los permisos que se habían configurado. Normalmente esto no seria mucho problema, pero si la carpeta es usada por muchos usuarios y contiene muchos subfolders dentro, es posible que pases mucho tiempo determinando que usuario tenia acceso a cual folder, si tenia permiso de lectura o de escritura, si podía escribir pero no podía borrar, en fin determinar nuevamente todos los permisos NTFS y configurarlos para cada subfolder. Para estos casos podríamos exportar los permisos de la carpeta principal y de todas las subcarpetas y su contenido que contengan a un archivo .txt, el cual podremos luego importarlo nuevamente, ambas cosas usando el comando icacls de Windows.

El comando Icacls nos permite visualizar y modificar los permisos (o DACLs - discretionary access control lists- ) de un archivo o carpeta. El formato o notación en que están definidos estos permisos es SDDL (Security Descriptor Definition Lenguage), esta notación se vería mas o menos de esta forma ejecutando icacls a la carpeta "Program Files" y al archivo "C:\Windows\System32\cmd.exe":

Como ven el comando nos muestra los grupos o usuarios que tienen permisos definidos y el nivel de acceso que tienen sobre la carpeta o archivo, por ejemplo (F) para Full Permitions, solo lectura se expresaría como (R), lectura y ejecución como (RX), escritura como (W). También muestra si los permisos son heredados de folders superiores. Para mas detalles sobre esta notación pueden visitar este link.

Y bien, volviendo a lo que les mencione arriba, si quisiéramos exportar los permisos de una carpeta y sus subcarpetas, utilizaríamos:

C:\> icacls D:\MiFolderdeDatos /save permisosfolder.txt /t

Donde "D:\MiFolderdeDatos" es la carpeta de la cual quiero exportar los permisos, "/save" es la opción para indicarle a icalcs que queremos guardar estos permisos en el archivo "permisosfolder.txt", y con la opción "/t" le indicamos que queremos también los permisos de los subfolders de nuestra carpeta.

Ahora, una vez ya tenemos nuevamente nuestra carpeta con todos los datos restaurada (y claro, en una unidad NTFS), podemos importar todos los permisos, usando ahora:

C:\> icacls D:\ /restore permisosfolder.txt

Como habrán notado, ahora para restaurar los permisos no necesito incluir la carpeta, solo indico la ruta raiz, el sea el disco donde se encuentra el folder (D:\). Esto porque icacls al momento de exportar los permisos utiliza ruta relativa, o sea, por cada entrada de permisos solo escribiría, por ejemplo "MiFolderdeDatos\archivo1.doc" ; "MiFolderdeDatos\carpeta1", así que no necesitamos especificar la carpeta a restaurar. Y bien, como les dije era un post bien corto, espero que esto les sea de ayuda en algún momento, como lo fue para mi.

Hasta el Próximo!

Importar Datos en Active Directory desde un archivo de Texto con DSQUERY y DSMOD

Quizas les haya pasado esto, necesitan modificar la información o propiedades en Active Directory de multiples usuarios, por ejemplo, agregar la dirección de correo, números telefónicos, agregarlos a un grupo o cualquier otra información del usuario. Esto mismo se me presento hoy, tenia que agregar el código de empleado a todos los usuarios, se le iba a agregar en el campo "Description". Me dieron un archivo de Excel con la lista de usuarios y la información que debía agregar. Afortunadamente había una columna con el username del dominio, por lo que era mas fácil asociar la nueva información con active directory.

DSQUERY y DSMOD

Bien, la manera mas fácil que pensé para hacer esto fue utilizar los comandos "DSQUERY" y "DSMOD", estos comandos permiten como seguramente ya han intuido, hacer búsquedas de en Active Directoty (dsquery), ya sea usuarios, computadoras, etc., para y modificar parámetros (dsmod) como los que les mencione mas arriba (correo, nombre usuario, password, etc.). Para utilizarlos tendrian que instalar "Remote Server Administration Tools". Si queremos por ejemplo  listar todos los usuarios del dominio usaríamos "dsquery user", podemos también buscar todos los usuarios de un OU especifico, supongamos que queremos los usuarios del OU "Contabilidad" y que nuestro dominio Active Directory se llama "midominio.local", usaríamos esto:

C:\>dsquery user ou="Contabilidad,dc=midominio,dc=local"

Con esto tendríamos el listado de usuarios de este OU, lo bueno es que ahora podemos tomar la salida de este comando y pasárselo a DSMOD para cambiar los parámetros o atributos que necesitemos agregar o cambiar. Siguiendo el ejemplo anterior, supongamos que a los usuarios de ese OU queremos modificarles el atributo "Office", lo que hariamos es repeterir el mismo comando anterior, pero agregar un "pipe" al final para dirigir la salida del comando a DSMOD y agregar dsmod user -office "Oficina Principal":

C:\>dsquery user ou=Contabilidad,dc=midominio,dc=local" | dsmod user -office OficinaPrincipal

Así todos los usuarios del OU que indicamos tendrán el atributo modificado, pero ahora viene lo interesante. Volvamos al caso inicial de modificar un grupo de usuarios y agregar o modificar en cada uno un atributo, pero con valores diferentes. Como les dije tenia la lista de usuarios y los atributos que debía agregar, lo que hice fue tomar de este archivo las 3 columnas que me interesaban: username (el del dominio), correo electrónico y código. Lo que haremos sera utilizar este archivo de texto (cvs) con estas 3 columnas y alimentar con cada una de ellas estos comandos. Usaremos también el comando "FOR"  que sera quien leerá el archivo de texto y pasara la información a dsquery y dsmod. El archivo de texto se vería mas o menos de esta manera:

Donde como pueden ver tenemos en la primera columna el usuario, en la segunda su cuenta de correo y en la tercera el código del usuario que agregaremos en el campo "Description" de Active Directory. Como ven las columnas están separadas por coma (cvs), lo guardaremos en "C:\usuarios.cvs". Teniendo ya nuestro archivo listo y organizado, podemos hacer una prueba con el comando FOR ejecutando "for /F "tokens=1,2,3 delims=, " %a in (usuarios.csv) do echo %a %b %b" y obtendríamos:

Si la salida fue como el gráfico anterior, podemos ahora hacer unos cambios al comando, y quedaría de esta manera:

C:\>for /F "tokens=1,2,3 delims=, " %a in (C:\usuarios.cvs) do dsquery user -samid %a | dsmod user -email %b -desc %c

Vamos a ver entonces lo que pasa aqui. Si tienen nociones de programación estarán familiarizados con el comando FOR, lo que estamos haciendo es "iterando" sobre el archivo "usuarios.cvs" y por cada linea ejecutaremos una acción. El comando "For" lo que hará es asignar el contenido de cada columna en una linea a una variable, en este caso la primera columna de la primera fila (el nombre de usuario) se asignara a la variable "%a", la segunda (el correo) a la variable "%b" y la tercera (el código) a la variable "%c" (pero como ven solo especifique %a en el comando, ya el sabe que las otras columnas las almacenara en variables nombradas con la letra siguiente). Luego indicamos el parámetro "do" del comando for, que es entonces donde especificamos la acción que se ejecutara en cada iteración sobre el archivo, y es aqui entonces donde usamos los comandos "dsquery" y dsmod". Como ven, ejecuto "dsquery user -samid" y le paso como parametro la variable %a a la que FOR ya le ha asignado el valor de "user1" (con "-samid" le indicamos a dsquery que buscaremos en Active Directory por username). Luego hago un "pipe" (|) para redirigir el resultado de dsquery a dsmod, usando "dsmod user -email %b -desc %c". Aqui estamos modificando 2 atributos del usuario al mismo tiempo (email y descripcion) y los valores que le estamos pasando son las variables %b y %c, que FOR ya le asigno los valores "user1@midominio.local" y "00001" respectivamente.

Al presionar enter veremos que se irán ejecutando estos comando uno por uno por cada linea del archivo usuarios.cvs, si encuentra un error en una linea del archivo el error les saldrá en pantalla pero no se detendrá la ejecución, ya que FOR continuara ejecutandose por cada linea del archivo. Bien, con esto hemos importado datos o actualizado información de un grupo de usuarios en Active Directory usando un archivo de texto, espero haberles explicado bien, todo esto tiene mucho sentido en mi cabeza pero a veces la explicación no me sale tan clara :D. Les recomiendo explorar los comando "DSQUERY" y "DSMOD" usándolos con el parámetro  de ayuda "/?", verán todo lo que pueden hacer en Active Directory desde la linea de comandos con ellos y tambien con DSGET y DSMOD. Espero que les haya sido de utilidad!

Creando Symbolic Links en Windows con MKLink

En esta semana se presento un pequeño problema en la oficina. Uno de los programas usado por los usuarios llamaba al Internet Explorer para generar un reporte desde Reporting Services, pero por alguna razón se abría la versión de 64bits del navegador. Esto generalmente no seria problema, si no fuera porque algunos ActiveX solo funcionan en la version de 32bits. Después de probar varias cosas decidí, para no perder mucho tiempo, renombrar la capeta donde se encuentra la versión de 64bits de Internet Explorer ( de "Internet Explorer" a "Internet Explorer64" ) y crear un Symbolic Link en la misma ruta y con el nombre original de la carpeta apuntando a la versión de 32bits que se encuentra en "C:\Program Files (x86)\Internet Explorer", y de esto es que quiero hablarles hoy; de los Symbolics Links en Windows, como crearlos y cuando usarlos.

Un Symbolic Link (o softlink) es algo así como un Shortcut, simplemente es una dirección hacia otro archivo o carpeta, con la diferencia de que el shortcut que creamos en Windows es realmente un archivo de extension ".lnk", mientras que el Symbolic Link es una redireccion hecha a nivel del File System. Esto significa que, por ejemplo, si creamos un shortcut que apunte a la carpeta "C:\Users" lo que crearemos sera un archivo ".lnk" que dentro apunta a la carpeta que indicamos, una aplicación tendría que saber interpretar este tipo de archivos .lnk y generalmente no lo hacen. Windows Explorer si los reconoce y por eso podemos hacer doble clic sin problemas. En el caso de los Symbolic Link, la redireccion la crea el propio File System (NTLM) y les muestra esto a las aplicaciones como carpetas o archivos reales. Estos links podemos también crearlos entre diferentes discos, por ejemplo, podríamos hacer un Symbolic Link en "C:\Datos" que apunte realmente a "E:\Programa\Datos", y todas las aplicaciones verían este link como una ubicación real en el equipo y no como un shortcut. Lo que nos serviría por ejemplo para mover una carpeta de datos de un programa sin tener que hacer alguna configuración en este y que el piense que sigue escribiendo en su carpeta original.

Para crear estos links, usamos en el comando mklink. Lo ejecutamos de la siguiente manera:

mklink /D ruta-donde-se-creara-el-link ruta-donde-apuntara-el-link 

Como ven es muy sencillo de usar, "/D" es la opción que le indica que se creara un Symbolic Link, luego le indicamos donde queremos crear el link seguido de a donde apuntara el link. Este comando requiere elevación de privilegios, así que tendrán que abrir una ventana de comandos (CMD) como Administrador. Para el caso que les mencione arriba, ejecute el comando de la siguiente manera:

Como ven renombre la carpeta de Internet Explorer a "Internet Explorer64" y dentro de esta misma ruta cree un Symbolic Link llamado "Internet Explorer" apuntando a la ubicación de la versión de 32bits. Si hacemos un "dir" aquí veremos ahora que la carpeta "Internet Explorer" es un SYMLINKD:

Y como ven, se nos muestra hacia donde apunta. Bueno, hasta aquí este post, espero como siempre que les sea de utilidad.

Programar Backups Routers Cisco

Regularmente hago copias de la conflagración de los Routers de mi red, lo hago copiando la "running-config" a un archivo de texto vía TFTP con el comando "copy running-config tftp:". En estos dias pense "mm, seguro que debe haber una forma de programar esto, alguna especie de cron", y efectivamente, se pueden programar tareas en los equipos Cisco con el comando Kron. El procedimiento es bastante sencillo,  primero se crea una lista de los comandos que queremos ejecutar y luego se especifica cuando se realizara esta tarea creando un "ocurrence". Bien, lo primero que necesitaran es un servidor TFTP, les recomiendo este. Luego que tengan su TFTP server funcionando, se logean a su Router para configurar el Kron. Una vez estén dentro, crearemos la lista de comandos que queremos ejecutar:

Router(config)#kron policy-list NombrePolitica

Donde "NombrePolitica" es el nombre que le daremos al listado que estamos creando. Presionamos enter y como podremos ver en el Promp, estaremos dentro del "Policy-list" que acabamos de crear. Aquí entonces agregaremos los comandos o acciones que queremos que se realicen automaticamente, en nuestro caso, sera copiar la configuración del Router al servidor TFTP. Ejecutaremos entonces lo siguiente:

Router(config-kron-policy)#cli sh run | redirect tftp://IP-TFTP-SERVER/nombre-archivo.cfg

luego:

Router(config-kron-policy)#exit

En la primera de las 2 lineas anteriores, iniciamos escribiendo "cli" y luego escribimos "sh run", como saben este comando mostrara la configuracion actual del router. Luego agregamos " | redirect tftp://ip-tftp-server/archivo.conf", lo que hacemos con esto es tomar la salida del comando anterior y redireccionarla a nuestro TFTP server. Como se imaginaran tendran que sustituir "IP-TFTP-SERVER" por la dirección IP de su servidor TFTP, luego escriben el nombre del archivo que se creara con la conflagración del router. Esto sera un archivo de texto, pueden ponerle o no extensión, en mi caso prefiero ponerle ".cfg". Como en este caso solo queremos programar la copia de la configuración, salimos de la edición de la lista con la segunda linea: "exit". En caso de que quieran programar otros comandos, deben tener pendiente que kron no soporta comandos interactivos, o sea, comandos que necesiten alguna acción o respuesta del usuario. Ya tenemos el listado de las acciones que realizara kron, ahora tenemos que indicarle cuando las realizara. Para esto ejecutamos el siguiente comando:

Router(config)#kron occurrence Nombre-ocurrance at 23:00 Sun recurring

luego:

Router(config-kron-occurrence)#policy-list NombrePolitica

En las lineas anteriores creamos el "occurrence" con el comando "kron occurrence", a este tambien le asignaremos un nombre que no tiene necesariamente que coincidir con el listado que creamos anteriormente. Luego especificamos el horario en que se ejecutara, en el caso de este ejemplo correra a las 11 de la noche de cada Domingo (23:00 Sun), como queremos que estas acciones se realicen recurrentemente agregamos al final "recurring", y presionamos "enter". Como pueden ver, el promp cambiara nuevamente indicando que estamos dentro de la configuracion del "occurrence". Aqui entonces indicaremos el listado que creamos anteriormente con el comando "policy-list NombrePolitica", y que como se imaginaran tienen que remplazar "NombrePolitica" por el nombre que le hayan puesto al listado (Policy-list) que crearon al inicio. Con esto ya tenemos nuestra "tarea" programada en nuestro router o switch. Podemos confirmar o verificar que se haya programado correctamente con el siguiente comando:

Router#sh kron schedule

Con esto veremos la fecha próxima en que se realizara la tarea que acabamos de programar. Bueno, hasta aqui este post, el primero del 2013, y como siempre espero que les haya sido de utilidad. En caso de que no hayan entendido mi explicación pueden leer mas sobre esto en esta pagina.

Un Poco de IPTables (Parte 2)

En el post anterior sobre IPTables vimos de manera rápida lo que, a mi entender, es necesario conocer antes de empezar a utilizar IPTables. Ahora les voy a decir las cosas que he aprendido de IPTables. Las funciones del Firewall de Linux están integradas en el Kernel del sistema operativo en un modulo llamado “NetFilter”, este modulo del kernel se maneja a través de un conjunto de herramientas llamadas iptables que utilizamos para crear las reglas de Firewall. iptables también es el comando que se utiliza para modificar o crear estas reglas. Este comando nos permite definir reglas las cuales se aplicaran a los paquetes basándose en la información de la cabeceras (o headers) de los protocolos, y nos permiten indicarle al Kernel la acción que queremos que realice sobre los paquetes, estas acciones pueden ser, por ejemplo, aceptar el paquete, rechazarlo, entre otras. Cada paquete que llega al equipo es comparado con cada una de estas reglas en el orden en que estén definidas, hasta encontrar un "match", o sea, hasta que el paquete coincida con una de las reglas con las cuales se esta evaluando. Cuando el paquete coincide con lo que describe la regla, entonces se ejecutara la acción que la regla especifica para ese tipo de paquete.

Estas reglas están organizadas en grupos llamados "Cadenas". Las cadenas (o "chains" en ingles) son agrupaciones de reglas, todas estas reglas comparten características comunes, por ejemplo, hay una cadena de reglas que se aplicaran solamente a los paquetes que se dirigen hacia el equipo que corre IPTables, otra cadena compara los paquetes salen del equipo que ejecuta IPTables hacia cualquier otro equipo. Las cadenas a su vez están organizadas o agrupadas dentro de "Tablas". En IPTables existen básicamente 3 tablas: MANGLE, NAT, y FILTER. Cada una de esas tablas contiene su respectivo grupo de cadenas que realizan diferentes operaciones en los paquetes:

• Filter: esta es la tabla por defecto y es la que se utiliza para las tareas de filtrado de paquetes. Esta es la regla que mas utilizaremos, y donde se definen las reglas que permitirán o no el acceso de los paquetes al equipo que corre IPTables o a la red.
• Nat: esta tabla se utiliza para alterar las direcciones y los puertos de los paquetes y crear reglas de NAT (Network Address Translations) en el equipo.
• Mangle: esta tabla también se utiliza para la alteración de paquetes, pero alteraciones mas especificas, como QoS. No es muy común su uso, particularmente nunca he tenido que utilizarla.

Como había mencionado, estas tablas contienen "cadenas". Cuando el equipo recibe un paquete, el paquete pasa por las 3 tablas de IPTables pero no necesariamente por todas las cadenas que contienen las tablas. El kernel analiza el paquete y lo envía a la cadena que corresponda. La tabla "Filter" contiene por defecto 3 cadenas:

• INPUT: las reglas contenidas dentro de esta cadena se aplicaran solamente a los paquetes destinados al equipo que ejecuta IPTables. Por ejemplo, supongamos que en nuestro equipo Linux instalamos un servidor Web y lo configuramos para que escuche en el puerto TCP 89 y queremos descartar cualquier paquete entrante a nuestro equipo que no sea destinado a ese puerto. En esta cadena es donde debemos crear la regla que permita acceso al puerto TCP 89 y descarte todo lo demás. Mas adelante veremos como crear las reglas.
• FORWARD: las reglas que contiene esta cadena se aplicaran a los paquetes que son ruteados a través de nuestro equipo. Esto es en el caso de que instalemos nuestro equipo Linux con IPTables configurado entre dos redes, o por ejemplo, entre Internet y nuestra red interna, donde los paquetes pasaran por el Firewall para llegar a la red interna, o desde la red interna hacia el Internet. Aquí definíamos reglas como por ejemplo, que ninguna computadora de nuestra red pueda conectarse a un determinado equipo en Internet.
• OUTPUT: esta cadena contiene las reglas que se aplicaran a los paquetes que salgan desde el mismo equipo, o sea, los paquetes generados localmente.

La tabla NAT también contiene 3 cadenas por defecto:

• PREROUTING: esta cadena contiene las reglas que modificaran el paquete al momento de entrar al equipo. En esta cadena crearemos las reglas que, por ejemplo, cambiaran el puerto y la IP de destino de paquetes destinados a equipos en nuestra red interna.
• OUTPUT: esta contiene reglas para modificar los paquetes generados internamente en el equipo antes de ser enrrutados.
• POSTROUTING: esta cadena contiene las reglas que modificaran los paquetes que saldrán del equipo una vez que se han tomado las decisiones de ruteo de hacia donde se enviara el paquete.

Esas son las cadenas por defecto de la tabla Filter y Nat, pero podemos también crear nuestras propias cadenas si queremos. Cuando IPTables evalúa los paquetes contra cada una de las reglas contenidas dentro de estas cadenas y no encuentra una regla que coincida con el paquete, entonces tomara una "Acción por Defecto" la cual es definida en cada cadena. Podemos por ejemplo especificar que la acción por defecto de la cadena "INPUT" sea descartar el paquete, en este caso, si al analizar un paquete destinado a nuestro firewall no se encuentra una regla que coincida con el paquete, el paquete sera descartado.

Bien, creo que eso ha sido suficiente preámbulo, ahora vamos a ver como crear algunas reglas básicas de IPTables, estoy seguro que luego de ver un par de estas reglas se entenderá mejor todo esto. La mejor forma de entenderlo es con casos de uso prácticos, y para este caso voy a utilizar un caso de uso de IPTables básico y muy común. Observemos el siguiente gráfico: 

Tenemos nuestro equipo Linux corriendo IPTables funcionando como firewall. Nuestro firewall tiene 2 tarjetas de red, con una conecta a la red Interna (192.168.1.1) y con la otra conecta a Internet (172.23.45.7). Vamos a configurar IPTables de forma de que los equipos de la red interna tengan acceso a Internet a través de nuestro Firewall. Lo primero que vamos a hacer sera crear una regla en la tabla NAT y configurar Network Address Translation (NAT) en nuestro equipo, de modo que los equipos de la red interna compartan la dirección IP de Internet de nuestro Firewall. Para esto ejecutamos:

root@firewall:~# iptables -F

root@firewall:~# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 0/0 -j MASQUERADE

Ahora la explicación de las reglas que creamos anteriormente:

iptables: Este es el comando que permite agregar las reglas al modulo netfilter

-t: Esta opción especifica la tabla que vamos a modificar, en este caso la tabla NAT.

-A: especifica la cadena en la que se quiere agregar la regla, en este caso cadena POSTROUTING.

-s: Esta opción especifica el origen de los paquetes que se rutearan, en este caso es la red interna.

-d: Esta opción específica el destino al cual se dirigen los paquetes.

-j: Esta opción se utiliza para decirle al Firewall que acción tomar con los paquetes que coincidan con lo antes citado.

Lo hicimos con la primera linea de comando fue borrar cualquier otra regla que haya sido creada en nuestro firewall utilizando el comando "iptables -F". Luego creamos una regla en la cadena POSTROUTING (usando la opción "-A") de la tabla NAT (usando la opción "-t"), esta regla le indica a IPTables que los paquetes provinientes de la red 192.168.1.0/24 (usando la opción "-s" que significa "source" u "origen") y que se dirijan hacia cualquier destino, o sea, hacia Internet (utilizando la opción "-d" que significa "destino") se les aplique la acción "MASQUERADE" (utilizando la opción "-j"). Esta acción hace que el firewall altere los paquetes que saldrán a Internet y que proceden de los equipos de red interna cambiando en el header del paquete el campo "IP de origen" sutituyendola por su propia dirección IP externa (172.23.45.7). De esta forma, los paquetes salen a Internet como si se originaran desde nuestro Firewall, o sea, hemos configurado NAT en nuestro equipo. Pero esto no es todo, para que los equipos de la red interna puedan salir hacia Internet a través de nuestro Firewall debemos crear reglas de FORWARD en la tabla FILTER. Supongamos que vamos a permitirles a los equipos de la red interna que puedan navegar en Internet, para esto necesitamos permitirles conexiones al puerto TCP 80 (puerto de http) a cualquier equipo en Internet. Para esto ejecutamos:

root@firewall:~# iptables -t filter -A FORWARD -p tcp -s 192.168.1.0/24 -d 0/0 --dport 80 -j ACCEPT

Como de lo que se trata ahora no es de modificación de paquetes, sino de determinar cuales paquetes estarán permitidos a salir de la red a través de nuestro Firewall, utilizaremos la tabla "Filter" y la especificamos utilizando la opción "-t filter". Como los paquetes que se analizaran no son dirigidos al firewall mismo sino que serán ruteados a través de el utilizaremos la cadena FORWARD, y la especificamos con la opción "-A FORWARD". Ahora bien, el tipo de paquete que permitiremos serán paquetes TCP, por lo que utilizamos la opcion "-p tcp". Utilizamos nuevamente las opciones "-s" y "-d" para especificar el origen y destino de los paquetes (192.168.1.0/24 y 0/0 respectivamente). Luego utilizamos la opción "--dport" para especificar el puerto de destino del paquete, para el caso de nuestra regla como estaremos permitiendo las conexiones a servidores Web en Internet, el puerto http es el puerto 80. Por ultimo especificamos la acción que queremos que ejecute IPTables sobre los paquetes que coincidan con la regla que acabamos de definir, en este caso aceptaremos que los paquetes salgan hacia Internet, por eso indicaremos la acción "ACCEPT". Vamos a hacer otro ejemplo, supongamos que queremos evitar que la computadora con la IP 192.168.1.2 haga conexiones FTP a un servidor en Internet con la IP 66.77.88.99, vamos a hacer una regla que bloque este tipo de trafico solo para esa IP pero que permita a las demás hacerlo:

root@firewall:~# iptables -t filter -A FORWARD -p tcp -s 192.168.1.2 -d 66.77.88.99 --dport 21 -j DROP

root@firewall:~# iptables -t filter -A FORWARD -p tcp -s 192.168.1.0/24 -d 66.77.88.99 --dport 21 -j ACCEPT

Como las reglas se van evaluando en el orden en que van siendo creadas, lo primero que hice fue crear la regla que bloquea el acceso al equipo especificado, como ven especifique la acción "DROP", esta acción bloqueara los paquetes que coincidan con lo que especificamos en la regla. Luego cree una regla que permite a cualquier otro equipo el trafico FTP pero solo lo permite al equipo especificado (66.77.88.99).  Supongamos ahora que instalamos SSH en nuestro Firewall para tener acceso remoto a el desde Internet. Tenemos que crear una regla en IPTables para que este permita conexiones SSH al equipo a través de su IP externa, para esto ejecutamos:

root@firewall:~# iptables -t filter -A INPUT -p tcp -s 0/0 -d 172.23.45.7 --dport 22 -j ACCEPT

Como pueden ver ahora utilizamos la cadena INPUT, porque se trata de paquetes que irán dirigidos al Firewall, no a algún equipo detrás de el. Como queremos conectarnos desde Internet y puede que no siempre lleguemos a nuestro firewall usando la misma dirección IP, indicamos en el "source IP" (opción -s) "0/0" esto le indica a IPTables que las conexiones pueden ser desde cualquier dirección IP. Supongamos ahora que no queremos que desde Internet se pueda acceder al servidor SSH que tenemos corriendo en nuestro Firewall, sino que solo se pueda acceder a este desde la red interna. Para esto tendríamos que crear 2 reglas, una que bloque el acceso SSH desde Internet y otra que lo permita desde la red interna:

root@firewall:~# iptables -t filter -A INPUT -p tcp -s 0/0 -d 172.23.45.7 --dport 22 -j DROP

root@firewall:~# iptables -t filter -A INPUT -p tcp -s 192.168.1.0/24 -d 192.168.1.1 --dport 22 -j ACCEPT

Ok, supongamos que ya hemos creado las reglas que necesitamos en nuestro Firewall, ahora debemos especificar la acción por defecto que queremos para cada cadena. Como les mencione la acción por defecto es la acción que tomara IPTables sobre los paquetes que no coincidan con ninguna de las reglas especificadas en la cadena. Le diremos a IPTables que descarte todo paquete que no coincida con ninguna regla, para esto ejecutamos:

root@firewall:~# iptables -t filter -P INPUT DROP

root@firewall:~# iptables -t filter -P FORWARD DROP

Utilicé la opción "-P" para definir la acción o política por defecto, como ven utilice 2 comandos, uno por cada cadena. Ahora, para ver las reglas que se han definido en el firewall ejecutamos el siguiente comando:

root@firewall:~# iptables -nL

Si ejecutamos este comando tal como esta aquí, nos mostrara solamente información de la tabla FILTER, que es la tabla por defecto. Si queremos información sobre otra tabla solo tenemos que incluir la opción "-t" y el nombre de la tabla que queremos. Bueno, hasta aquí este intento de tutorial de IPTables, espero que hayan podido entender mis explicaciones y que los minutos dedicados a leer esto no hayan sido en vano. Mas adelante continuare hablando sobre otras cosas de IPTables, como por ejemplo, como cargar las reglas al iniciar el equipo, como hacer "baclup" de las reglas que hemos definido, módulos, etc.

Fin de Semana en el Centro de Servidores (Parte 2: Acceso SSH y Backup de VMWare ESX 3i)

Bueno, siguiendo con la historia que empecé en el pasado post, les voy a hablar ahora de como hacer Backups o copias de seguridad de las maquinas virtuales en VMWare ESX 3i. Como les había dicho en el post anterior, una vez había encontrado que lo que estaba provocando el problema de performance en el servidor era el hecho de que estaba utilizando discos SATA en lugar de SAS, debía reemplazar los discos del equipo, por lo cual necesitaba sacar primero los archivos de las maquinas virtuales para luego copiarlas nuevamente al servidor una vez haya reemplazado los discos. A continuación los pasos:

• Habilitando SSH en VMWare ESX 3i

Para poder hacer backup de las maquinas virtuales en ESX 3i, debemos primero habilitar el acceso SSH, para esto:

1. En la consola del equipo con VMWare ESX (en mi caso el servidor al que le debía reemplazar los discos), presionamos ALT+F1 y luego escribimos "unsupported".
2. Nos presentara una advertencia y un promp donde introduciremos el password de "root" (este es el password que utilizamos con el cliente de VMWare para crear las maquinas virtuales y demas funciones).
3. Una vez hayamos introducido el password de root, editamos el archivo inetd.conf. Para esto ejecutamos "vi /etc/inetd.conf".
4. Dentro de este archivo buscaremos la linea que empieza con #ssh y presionamos la tecla "Insert", luego nos ponemos enfrente del signo de numero ("#") y presionamos backspace para borrarlo.
5. Cuando lo hayamos borrado, presionamos la tecla "ESC" y luego escribimos ":wq" y presionamos "ENTER" para salvar los cambios y salir del editor. En caso de que hayan cometido algún error en la edición y quieran salir sin guardar cambios, en lugar de escribir ":wq" pueden escribir ":q!" para salir del editor sin guardar los cambios.
6. Ejecutamos entonces "/sbin/services.sh restart" y ya con esto hemos habilitado SSH en nuestro VMWare ESX 3i

Para hacer la copia de las maquinas virtuales que residían en el equipo utilice un programa llamado Veeam FastSCP que permite hacer copias atraves de SSH, es rápido, fácil de usar y lo mas interesante es que es gratis!! Pueden descargarlo haciendo clic aqui, (necesitaran registrarse). El proceso de instalación es bastante sencillo, lo que deben tener pendiente es que en la instalación le solicitara las credenciales de un usuario con el privilegio "Log on as a Service", el cual podrían o agregarselo a su propio usuario o crear un nuevo usuario y asignarle ese permiso, de esta forma esta aplicacion correra bajo las credenciales del nuevo usuario. Una vez hayan instalado y ejecutado Veeam FastSCP les abrirá la siguiente ventana:

Para agregar nuestro equipo VMWare y empezar el proceso de copia, hacemos clic en el icono "Add Server" (encerrado en el circulo rojo en el gráfico). En la siguiente ventana escribimos el nombre o dirección IP del equipo donde se encuentran las maquinas virtuales. Como podrán ver nos presenta varias opciones de Servidor: VirtualCenter, ESX o ESXi y también Linux Server, ya que podríamos usar este programa como un "scp" grafico y copiar datos desde cualquier equipo Linux a traves de SSH. En mi caso, y seguro también el de ustedes, elegiremos "ESX or ESXi host" y hacemos clic en Next.



Luego tenemos que escribir el username y password para conectarnos al equipo VMWare, el cual es el mismo que utilizamos para conectarnos al equipo via la consola y que utilizamos para logearnos y habilitar SSH.

Si escribimos bien las credenciales de "root", al hacer clic en Next el programa intentara conectarse al equipo y veremos una ventana como la siguiente, la cual nos muestra un resumen de la información del equipo al cual estamos conectado (donde se encuentran las VM's), diciendo el nombre o IP del equipo, el tipo de servidor y versión, el usuario con el cual estamos conectados y el puerto. Seleccionaremos entonces en esa ventana el cuadro "Connect when I click Finish" y luego hacemos clic en Finish.

Ya que hemos agregado nuestro equipo VMWare a Veeam FasSCP, lo único que tenemos que hacer es movernos hacia los archivos de la maquina virtual que queremos copiar y moverlos hacia nuestra computadora, como cuando transferimos archivos vía FTP o SCP. Cuando la ventana de Veeam FastSCP abre nos mostrará a mano izquierda el servidor VMWare que hemos agregado y los discos que posee nuestra computadora, hacia los cuales podemos arrastrar los archivos de las VM's.

Como se puede ver en el grafico, el programa nos presenta debajo del nombre del servidor las maquinas virtuales presentes. En el caso del server del ejemplo, tiene 2 maquinas virtuales. A mano derecha nos presenta un archivo representando el "Data Storage" (vmDisk1) que fue creado en VMWare. Solamente tenemos que arrastrar las carpetas con el nombre de la maquina virtual que queremos hacia uno de nuestros discos y listo, al finalizar ya tenemos nuestro backup.

Y bueno, volviendo a mi historia, el proceso descrito anteriormente me tomo varias horas porque una de las maquinas virtuales que estaba copiando tenia mas de 1TB y la otra algunos 80GB. Luego de concluir esta fase y tener mis maquinas virtuales seguras en una unidad externa, procedí entonces a apagar el servidor, reemplazar los discos SATA por los nuevos SAS y crear la nueva unidad RAID10 donde copiaría devuelta las maquinas virtuales. En el próximo post les diré entonces como crear estas unidades en los servidores Dell PowerEdge 2950 y el proceso de restauración de las maquinas virtuales. Espero como siempre que esto les haya sido de utilidad.

Fin de Semana en el Centro de Servidores (Parte 1: Desempeño de discos en Linux)

Hola nuevamente!

Lo que les voy a narrar a continuación lo hago con la intensión no solo de desahogarme y de  tener escrito las cosas que hice ese fin de semana en caso que tenga que repetirlo, sino también para evitarles a ustedes algunos de mis errores. Si les contara todo en un solo post seria un cuento demasiado largo, por eso la dividire en base a las tareas principales que realice y que creo podrían ser de utilidad para ustedes, por ejemplo, en este les hablare acerca del monitoreo del desempeño de equipos Linux,  en el proximo como hacer un Backup de las maquinas virtuales de VMWare ESX 3i, y quizás algunas otras cosas que espero les sea de importancia. Es posible que en algún momento necesiten hacer lo que yo estuve haciendo, aunque seguramente ustedes tienen mejor planeacion que yo y mas experiencia. Pero quizás haya algún otro "Tipo de Informática" que necesite esta información, así que aquí les va.

Recientemente, tuve uno de esos "fines de semana con todo pago" en el cuarto de servidores haciendo un upgrade a uno de los servidores, bueno, quizás se podría decir a 3 servidores, porque era un servidor de Virtualizacion en el cual residen 2 maquinas virtuales. El upgrade consistía en reemplazar los 6 discos duros SATA a 7.2K rpm de este servidor por discos SAS 15K rpm debido a un problema de Performance que se venia presentando hacía unos meses atras. Este upgrade también incluía cambiar el nivel RAID que estábamos utilizando (RAID 5) por RAID 10 para obtener todavía mejor desempeño de los nuevos discos. El sistema operativo que utilizamos para la virtualizacion es VMWare ESX 3i, el cual esta instalado en un stick USB interno del servidor, por lo que la unidad RAID se utiliza para almacenamiento, o sea, crear en ella las maquinas virtuales. Para hacer este upgrade debía primero hacer un backup de las maquinas virtuales, luego reemplazar los discos, crear la nueva unidad RAID10 en el servidor, restaurar los backups de las maquinas virtuales a la nueva unidad RAID, arrancarlas y listo! así de simple. y habia que hacerlo en ese fin de semana, de viernes a domingo a mas tardar. Pero como siempre aparece Murphy y sus leyes y con ellas las complicaciones, además claro de los errores de un "Tipo de Informática" inexperto.

Creo que seria bueno empezar desde el principio y contarles como conseguí mi ticket para este fin de semana. Hace poco mas de un año, se decidió comprar un servidor en la compañía donde trabajo. Este servidor se utilizaría básicamente para alojar un Mail Server, pero se decidió también que este mail server corra virtualizado sobre el equipo que se iba a adquirir, asi que debia cotizar y presentar una propuesta de servidor para estos fines. Bueno, me decido por un Dell PowerEdge 2950 III, con 2 procesadores Intel Xeon Quad Core, 16 GB de RAM y 6 discos SATA a 7.2 K rpm, y esto ultimo fue lo que pago el fin de semana que da origen a este post. Para disminuir el costo del servidor y hacer el presupuesto un poco mas atractivo para la Gerencia, me decidí por los discos SATA en lugar de los discos SAS, claro, en ese tiempo no le daba mucha importancia a los discos y a su velocidad, en ese momento me preocupe mas por el espacio de almacenamiento y el presupuesto. El software que se iba a utilizar como servidor de Email es un programa llamado Kerio MailServer, es un software de colaboración, parecido a Microsoft Exchange, que permite a los usuarios tener sus buzones sincronizados con el servidor a través de un programa cliente que trabaja junto a Microsoft Outlook. Este tipo de softwares (Mail servers) requieren de mucha velocidad de acceso a los discos en el servidor, porque realiza muuuchas operaciones I/O (o lectura/escritura) en los discos, y aquí es donde radica la diferencia entre los discos SATA y SAS: los discos SAS ofrecen mucho mas operaciones I/O y a mayor velocidad (15,000 revoluciones por segundo) que los discos SATA (7,000 revoluciones), y también tienen un tiempo de vida mas largo. Los discos SATA pueden utilizarse en servidores, digamos de Backups, o servidores que demanden de mas capacidad de almacenaje que velocidad. Así que ahí esta la primera lección de este post, elegir bien el hardware que se utilizara tomando en cuenta la función que el servidor desempeñara.

• Determinando el Problema

Comando top

Ahora se que mi problema eran los discos que estaba utilizando, pero en esos días no tenia una idea clara del problema, solo sabia que el trabajar con emails se había puesto bastante lento. Cada vez que un usuario intentaba moverse de folder en el Outlook, o simplemente abrir un mensaje, moverlo, borrarlo, etc, tenían que esperar varios minutos para poder realizar la tarea. Así que empecé a revisar que estaba pasando en el servidor, con la herramienta que empecé fue el muy conocido comando "top",este comando nos muestra en tiempo real todos los procesos que que esta ejecutando el servidor y nos muestra, entre muchas otras cosas, el porciento de CPU y memoria que estos están utilizando. A continuación les muestro lo que me devolvió "top" cuando lo ejecute en el servidor:

Este screenshot fue tomado en un momento en que el servidor estaba bastante ocupado (y bastante lento). Como pueden ver el comando top muestra todos los procesos corriendo así también como los recursos que están consumiendo (en cuanto a memoria y procesador), también muestra el PID de los procesos. Como se imaginaran el proceso "mailserver" es el correspondiente al servidor de email que esta corriendo en el servidor y como se ve en el gráfico esta consumiendo el 191% del CPU. Al principio pensé que el problema estaba aquí, en el quizás la capacidad de procesamiento del servidor no era suficiente para el software, pero vi que en otras ocasiones el uso del CPU estaba bajo y de todas formas había lentitud en el servidor. Así que seguí buscando e incluso envié el screenshot al foro de usuarios del Mailserver y alguien me señalo algo en lo que no me había fijado en la salida de este comando; el "Load Average" (parte superior derecha del gráfico). Si se fijan este indicador muestra un "porcentaje de carga" de 68. Comencé a investigar en Internet para ver que significaba este medidor y mas o menos lo que pude entender es que esto muestra el porcentaje de procesos en cola esperando por recursos del sistema, por ejemplo, esperando tiempo del CPU, esperando acceso al sistema de discos, etc. y que lo recomendable es que se encuentre por debajo del 10%. Si se fijan este medidor esta separado en 3, lo cual expresa el valor del momento actual, la carga en los próximos 5 minutos y luego en los próximo 15 minutos. En el gráfico se ven los números 68.37, 61.71 y 55.27. Una lectura alta en ese medidor generalmente indica un cuello de botella, o sea, que algún recurso del sistema esta, digamos, quedando pequeño o que no esta respondiendo a tiempo las solicitudes, por esta razón empecé entonces a monitorear la actividad en el sistema de discos para ver si el "cuello de botella" se encontraba en los discos.

Comando iostat

Fue entonces cuando empecé a utilizar la herramienta "iostat". El comando iostat brinda "las métricas de desempeño de las interfaces de almacenamiento". Este comando, entre otras informaciones, nos muestra el porcentaje de utilizacion del disco o partición (%b), el tiempo que tarda en responder a una solicitud (service time o svc_t),  y la longitud promedio de la cola de solicitudes para el dispositivo monitoreado (queue). Ejecute iostat con las siguientes opciones:

# iostat sda7 -x 3

Esto le indica a iostat que nos muestre información extendida (-x) de la partición sda7 y que muestre la información en intervalos de 3 segundos hasta que cancelemos el comando con CTRL-C. A continuación lo que me mostró iostat al ejecutarlo en el servidor:

Como se puede ver en el gráfico, iostat me mostró que el cuello de botella se encontraba realmente en el sistema de discos: el porciento de utilizacion (%b) no bajaba de un 100%, la cola de procesos siempre se encontraba por encima de los 100 (actualmente difícilmente llega a 10). Claro, esta lectura también podría indicar que uno de los discos del arreglo (RAID5 en ese momento) estaba defectuoso o algún problema en la partición, por lo que primero me asegure de que este no sea el problema (usando fsck). Al comprobar que tanto los discos como la partición estaban funcionando correctamente, solo quedaba la opción de hacer un upgrade al sistema de discos reemplazando los discos actuales, SATA 7.2K RPM, por discos SAS a 15K RPM y gracias a la información provista por iostat ya tenia las pruebas para solicitar el cambio.

Creo que la moraleja es que a la hora de hacer una recomendación, debemos siempre recomendar lo óptimo para el trabajo y no basarnos solamente en lo económico, debemos presentar, claro esta, la justificacion de porque se recomienda tal o cual dispositivo (o servidor en este caso) y las consecuencias de inclinar la balanza solamente por el lado económico, que fue el error que yo cometí. En caso de que la gerencia o las personas que deben tomar la decisión se inclinen por la solución mas barata pero no la mas óptima para el trabajo, bueno, eso ya debe quedar a responsabilidad de ellos, pero por lo menos nosotros cumplimos con recomendar el equipo adecuado, y hay que tratar de hacer la recomendación por escrito como evidencia para cuando explote el problema :D. Claro, a fin de cuentas de todas formas nos tocara a nosotros, los "Tipos de Informática", cargar con las consecuencias de su elección, pero por lo menos podremos decir (aunque sea solo en nuestra mente) "Se lo dije!!"

Bueno, todo esto fue lo que motivo que me pasara el fin de semana aquí en el cuarto de los Servidores haciendo el trabajo de Upgrade de los discos. En los próximos post les contare entonces el proceso de cambio y algunos problemas que se presentaron. Espero como siempre que esto les haya sido de provecho y que no hayan perdido su tiempo leyendome. Hasta el próximo!!

(Fin de Semana en el Centro de Servidores Parte 2)

Correr Aplicaciones como Servicios en Windows Server 2003

Recientemente en el trabajo se me presento el siguiente caso: Debia instalar en uno de los servidores un programa que usarian un grupo de usuarios, este programa revisaria periodicamente un sitio FTP y si habia algun archivo nuevo lo descargaria a un determinado folder, con el que los usuarios luego trabajarian. El problema es que el sistema con el que trabajarian los usuarios se a traves Terminal Services, y el programa que alimentaria a este sistema a traves de la descarga de archivos FTP no estaba diseñado para trabajar como servicio, lo que significa que cada usuario debia iniciar la aplicacion FTP una vez logeado al servidor.

Bueno, no es tan problematico el hecho de que los usuarios tengan que iniciar ellos mismos esa aplicacion, el problema es que si 15 usuarios se logeaban al servidor e iniciaban la aplicacion, tendria 15 instancias de la misma aplicacion corriendo en el servidor de Terminal Services, y todos haciendo la misma tarea. La solucion: hacerlo correr como un servicio, asi los usuarios no tendrian que lidiar con abrir la aplicacion [mientas menos hagan los usuarios en el servidor mejor] y tendria una sola instancia de la aplicacion corriendo. Para hacer esto, utilizamos los comandos INSTSRV.EXE y SRVANY.EXE, ambos incluidos en el Windows Server 2003 Resource Kit Tools. Instsrv.exe crea o remueve servicios en el sistema y Srvany.exe nos permite correr las aplicaciones como servicio. Para crear entonces nuestro nuevo servicio ejecutamos:

ruta-al-comando-INSTSRV.EXE Mi Servicio ruta-al-comando-SRVANY.EXE

Donde "ruta-al-comando-instsrv.exe" es, como ya se habran imaginado, la ruta donde se encuentra dicho comando. Claro, esto tenemos que especificarlo en caso de que no hayamos incluido ese comando comando en la variable del sistema "PATH". Luego escribimos el nombre que queremos dar a nuestro nuevo servicio ("Mi Servicio"). Y por ultimo la ruta hacia el comando "srvany.exe". Por ejemplo, supongamos que llamaremos a nuestro nuevo servicio "Sftp", el comando seria de esta forma:

C:\Program Files\Windows\windows Resource Kits\Tools\instsrv.exe Sftp C:\Program Files\Windows\windows Resource Kits\Tools\srvany.exe

Con esto hemos creado nuestro servicio, ahora debemos indicar en el registro la ruta hacia la aplicacion. Para esto abrimos en editor del registro (regedit.exe). Y nos movemos hacia la siguiente clave del registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

Aqui buscamos la clave correspondiente al servicio que acabamos de crear, de acuerdo a este ejemplo debe llamarse "Sftp". Una vez estemos sobre esta clave, crearemos una nueva sub-clave haciendo clic derecho encima de "Sftp", moviendonos hacia "New" y luego seleccionando "Key", a la que renombraremos "Parameters". Hacemos clic derecho nuevamente encima de "Parameters", nos movemos encima de "New" y seleccionamos "String Value", a esta estrada la llamaremos "Application". Esta clave del registro sera la que indicara la ruta hacia el ejecutable de la aplicacion que queremos correr como servicio, asi que haremos doble clic enicima de "Application" y escribiremos la ruta hacia nuestro ejecutable, por ejemplo, C:\Program Files\Sftp\Sftp.exe".

El grafico anterior muestra los cambios dentro de la clave del registro correspondiente a nuestro nuevo servicio. Una vez hemos hecho estos cambios, solo nos resta iniciar nuestro servicio, para esto nos vamos a la consola de administracion de servicios (podemos acceder ejecutando services.msc) e iniciandolo como cualquier otro servicio (clic derecho encima del servicio y seleccionando "start").

Ya con esto tenemos nuestra aplicacion corriendo como servicio. Espero que esta informacion les haya sido de utilidad. Hasta el Proximo!

Manejando los Servicios de Windows desde la consola con Sc

Vamos a hacer una pequeña pausa en la instalación de nuestro “Proxy Linux con Autenticación en Active Directory” del que hemos estado hablando en los últimos 3 post, y vamos a ver una utilidad de Windows que nos permite manejar los servicios de este. Y cuando digo "manejar" no me refiero a solo iniciarlos o detenerlos como hacemos con el comando "net start" y "net stop", sino también a listar todos los servicios, modificar su forma de inicio e incluso modificar la acción a tomar en caso de que el servicio presente algún error y hasta la descripción del servicio, en fin, todo lo que podemos hacer con los servicios desde la consola grafica (services.msc), pero desde una ventana de comandos.

SC es un comando utilizado para comunicarnos con el administrador de servicios, lo que nos permite manejar los estados de los servicios rápidamente. También tiene la ventaja de poder integrarlo en scripts. SC contiene también una serie de subcomandos, los cuales se utilizan dependiendo del tipo de acción que se realizaran en el servicio. Para ver el listado ejecutamos “sc /?”, al lado de los subcomandos veremos una descripción de lo que hace el comando.

Ejemplos de SC

Vamos a ver ejemplos de algunas de las funciones que podemos hacer con “Sc”. Vamos a empezar con el uso más simple, iniciar o detener un servicio. Para este ejemplo utilizaremos el servicio “Spooler”, para detenerlo utilizando “Sc”, ejecutamos:

C:\> sc stop spooler

Y si queremos iniciarlo:

C:\> sc stop spooler

También con “Sc” podemos conseguir el listado de los servicios de nuestro sistema y sus estados actuales, para lo utilizamos:

C:\> sc query

Esto nos devolverá el siguiente resultado:

Como pueden ver, en este listado nos aparece el nombre del servicio (Service_Name) y, digamos, el nombre completo del servicio o “Dsiplay_Name”. Para trabajar con SC, usaremos el nombre del servicio o “Service_Name”. Podemos también conseguir el estado de un servicio en particular usando, por ejemplo, “sc query spooler” en caso del servicio Spooler. También podemos exportar esta lista de servicios a un archivo .txt usando: “sq query > lista.txt”. Otro uso de “Sc” es cambiar la forma de inicio del servicio, o sea, si queremos hacer que el servicio inicie al bootear el equipo, hacemos:
 

C:\ sc config spooler start= auto

 

Bueno, creo que con esto ya tienen una idea de lo que pueden hacer con “Sc”, esto es solo lo básico que podemos hacer. Espero que esto les haya sido de utilidad, en el próximo post volveremos al tema de prepara el Web Proxy con Squid, asi que hasta el próximo!

Configuracion TCP/IP a traves de linea de comandos usando "Netsh" (Windows)

En ocaciones necesitamos hacer modificaciones a la configuracion TCP/IP de un equipo (local o remotamente) o un grupo de equipos, como por ejemplo, cambiar la dirección del DNS, Gateway, Subnet Mask, etc, tambien puede darse el caso que necesitemos cambiar, agregar o eliminar alguna regla en el Firewall de Windows, ya sea para abrir un determinado puerto o cerrarlo. Todas estas configuraciones podemos realizarlas desde la comodidad de nuestra ventana de comandos (para los que nos gusta trabajar desde la consola) utilizando la herramienta "NETSH". Netsh (o "Network Shell") se utiliza a través de la linea de comandos y permite visualizar y modificar la configuracion de red de un equipo local o remoto y viene integrada en los sistemas operativos Windows a partir de Windows XP. Podemos utilizar Netsh en scripts que al ser ejecutados modifiquen la configuracion IP de un determinado equipo o grupo de equipos.

A continuación algunas de las tareas básicas que podemos hacer con Netsh:

* Configurar IP estatica: En este ejemplo le asignaremos una dirección IP estática a la interface de red "Local Area Connection", la IP que le asignaremos sera "192.168.1.10", subnet mask "255.255.255.0", Gateway "192.168.1.1" y la metrica "1"

netsh interface ip set address "local area connection" static 192.168.1.10 255.255.255.0 192.168.1.1 1

* Configurar DNS primario: En el ejemplo anterior solo agregamos la direccion IP del equipo, en este agregaremos el DNS primario (192.168.1.2) para esta conexion:

netsh interface ip set dnsserver "Local Area Connection" static 192.168.1.2 primary

* Configurar IP usando DHCP: En este ejemplo configuraremos la tarjeta de red para que reciba de la configuracion IP desde un servidor DHCP.

netsh interface ip set address name="Local Area Connection" source=dhcp

* Abrir puertos en el Firewall: En este ejemplo configuraremos el Firewall de Windows para que permita conexiones VNC al equipo en el cual estamos haciendo los cambios, este protocolo utiliza el puerto TCP 5900:

netsh firewall add portopening TCP 5900 "VNC"

Esta es la forma basica y mas permisiva de abrir un puerto en el Firewall ya que permite acceso a cualquier equipo establecer una conexion con este equipo a traves de este puerto. Podemos crear una regla mas detallada en el Firewall tambien con Netsh especificando un rango de direcciones IP que podrán conectarse a este equipo (generalmente el rango IP de la red interna), podemos también especificar el protocolo a usar (TCP o UDP). Para esto usamos el siguiente comando:

netsh firewall add portopening protocol=tcp port=5900 name=VNC mode=enable scope=custom addresses=192.168.1.0/255.255.255.0

Estos son solo usos básicos de Netsh, si quieren mas información acerca de este y que mas se puede hacer con el visiten este link. Es muy útil también utilizarlo junto con PsExec, así podemos conseguir una consola remoto en un equipo y ejecutar desde esta los comandos de Netsh. Bueno, espero que esto les sea de utilidad y que hayan perdido su tiempo en este Blog, nos leeremos luego!!.