Buscar

Linux: Mysql autocompletar

Una de las herramientas cliente para administrar sistemas de bases de datos mysql es el comando mysql.

La funcionalidad de autocompletar con el comando mysql, por defecto está desactivada y se llama: auto-rehash

Con auto-rehash podemos autocompletar utilizando la tecla tabulador (TAB).

Para iniciar el cliente mysql en modo auto-rehash, disponemos de dos posibilidades:

1) MYSQL autocompletar: Vía linea de comandos:


Ejecutamos el comando mysql seguido del parámetro: auto-rehash

mysql --auto-rehash -u root -p

2) MYSQL autocompletar: Vía fichero de configuración general (todos los usuarios)


En el interior del fichero: /etc/my.cnf

en el apartado:

[mysql]

Añadimos:

auto-rehash

Si quisiéramos desactivar el autocompletar en el fichero de configuración my.cnf:

en el apartado:

[mysql]

Añadimos:

no-auto-rehash

3) MYSQL autocompletar: Vía fichero de configuración a nivel de usuario.


En el interior del fichero: ~/.my.cnf (fichero oculto situado en el home-directory del usuario)

en el apartado:

[mysql]

Añadimos:

auto-rehash

Si quisiéramos desactivar el autocompletar en el fichero de configuración ~/.my.cnf:

en el apartado:

[mysql]

Añadimos:

no-auto-rehash


VMWare: ESXi requires the execute disable/no execute cpu feature to be enabled

A partir de la versión 5.1 de VMWare ESXi, se requiere habilitar en la BIOS del host, la siguiente funcionalidad:

Execute Disable Bit

Si no disponemos de la funcionalidad activada en la BIOS del sistema, nos encontraremos con el siguiente error al proceder a instalar o actualizar un host VMWare ESXi:

The system has found a problem on your machine and cannot continue.

VMware ESXi requires the Execute Disable/No Execute CPU feature to be enabled

La funcionalidad  "Execute Disable Bit" es una tecnología de seguridad basada en hardware de Intel que permite reducir la exposición de ejecución de código malicioso.

La idea de Execute Disable Bit es permitir a la CPU clasificar las áreas de memoria a las que una aplicación puede ejecutar o no código.

1) Para activar "Execute Disable Bit" en servidores HP:


Pulsamos F9 para entrar en la BIOS:

Advanced Options > Processor Options > No-Execute Memory Protection > Enabled 

VMWare: ESXi requires the execute disable/no execute cpu feature to be enabled

WiFi: Cifrado y autenticación - Buenas prácticas - Capítulo 9

El autor de este post es Pol Padrisa (@polpadrisa). 

En este artículo vamos a hablar de los distintos protocolos de autenticación y cifrado de red WiFi.

Cuando configuramos por primera vez una red Wifi nos encontramos frecuentemente con distintas opciones WEP, WPA, WPA2… en este artículo vamos a repasar las diferencias que hay entre ellos y en qué casos podemos utilizar cada uno de ellos.

WEP o  Wired Equivalent Privacy:


Se trata del sistema de cifrado incluido en el estándar IEEE 802.11 se implementó como primer modelo de cifrado Wifi pero con el tiempo fue hackeado y actualmente se considera altamente vulnerable.

Para obtener la clave solo necesitamos inspeccionar los paquetes con un sniffer y aplicar ciertos algoritmos sobre el tráfico capturado.

El protocolo de encriptación WEP definitivamente debe ser desactivado de cualquier WiFi que administremos.

WPA o Wi-Fi Protected Access:


WPA es un protocolo de migración para cubrir las deficiencias y vulnerabilidades de WEP.

Fue diseñado para utilizar un servidor de autenticación (normalmente un servidor RADIUS), que distribuye claves diferentes a cada usuario (a través del protocolo 802.1x) sin embargo, también se puede utilizar en un modo menos seguro de clave precompartida (handshake) para usuarios domésticos o pequeña oficina.

Una vez finalizado el nuevo estándar 802.11ie se crea el WPA2 basado en WPA.

WPA2:


Como indica el nombre es la revisión de WPA mejorando algunos de sus aspectos los complementos aplicables a WPA (MGT, CCMP, TKIP…) suelen ser aplicables tanto a WPA como WPA2.

Autenticación WPA:


Para la autenticación WPA existen dos formas, una con un servidor de autenticación (MGT) y otra con una clave precompartida (PSK).

WPA-MGT  y WPA2-MGT (aka WPA-Enterprise y WPA2-Enterprise)


Cuando utilizamos un servidor de autenticación como RADIUS estamos utilizando WPA MGT o WPA2 MGT significa que la contraseña no es una clave pre compartida.

La red Wifi dispone de un servicio o servidor de autenticación.

Son las redes más seguras pero también son las que necesitan de más infraestructura y mantenimiento, es por este motivo que solo suele utilizarse en entornos corporativos.

WPA-PSK y WPA2-PSK (aka WPA-Personal y WPA2-Personal)


Cuando no hay servidor de autenticación y por tanto una clave precompartida estamos utilizando WPA PSK.
 
Lo más habitual en una red WiFi doméstica con seguridad WPA es que la autenticación se base en PSK, que son las siglas de Pre Shared Key (clave compartida previamente), es decir, la seguridad de la red WiFi se basa en un secreto compartido (la contraseña de la red WiFi), que conocen sus usuarios y el punto de acceso.

Para simplificarlo, una red WiFi WPA-PSK dispone de una contraseña conocida por todos y cada uno de los clientes que se conectan a la red WiFi.

Es la configuración de red es más utilizada en los routers WiFi que los ISPs facilitan con sus conexiones de ADSL/Cable/Fibra óptica.

TKIP:


Temporal Key Integrity Protocol es el mecanismo de cifrado diseñado para proteger las comunicaciones inalámbricas nacido tras la aparición de WPA como sustituto de WEP.

Cuando vemos WPA – TKIP significa que tenemos una validación vía WPA (con o sin servidor de autenticación) y que luego el tráfico es cifrado mediante el sistema TKIP.

En la actualidad TKIP se considera obsoleto, ya que fue sustituido por CCMP (AES).

El uso de TKIP con WPA2 PSK (WPA2-PSK-TKIP) es soportado por la mayoría de dispositivos por si es necesario dar compatibilidad a dispositivos anticuados pero no es lo recomendado por el estándar.

CCMP (aka AES):


Counter Mode CBC-MAC Protocol. CCMP, también conocido como AES CCMP.

Es el elemento de cifrado que reemplaza a TKIP y el estándar definido para WPA2. 

Las especificaciones dicen que las redes WPA2 deben usar CCMP por defecto con WPA2-CCMP (WPA2-PSK-CCMP). Dónde WPA2-PSK sería el sistema de validación y CCMP o AES sería el sistema de cifrado.

CCMP o AES es compatible con WPA para añadir un poco más de seguridad a WPA aún que es mucho más preferible usar siempre WPA2.


Como podéis apreciar en la tabla la solución más segura es WPA2-MGT-AES (aka WPA2-ENTERPRISE-CCMP-AES) el problema de esta implementación es que requiere de un servidor de autenticación (normalmente RADIUS).

Normalmente se suele dar por aceptable la configuración WPA2-PSK-AES (aka WPA2-PERSONAL-PSK-CCMP-AES) nos permite una autenticación bastante segura (atacable por fuerza bruta) y un cifrado de última generación CCMP-AES.

Así pues como conclusión deberíamos utilizar:

- Siempre que podamos mantener un servidor RADIUS: WPA2-MGT-AES

- Para instalaciones sin servidor RADIUS: WPA2-PSK-AES utilizando siempre una contraseña aleatoria de mínimo 12 caracteres para prevenir ataques de fuerza bruta.


Capítulos de la serie: "WiFi: Buenas prácticas":

WiFi: 802.11 b/g/n/ac - Buenas prácticas - Capítulo 1 (SYSADMIT.com)

WiFi: Elegir canal - Buenas prácticas - Capítulo 2 (SYSADMIT.com)

WiFi: WifiAnalyzer - Buenas prácticas - Capítulo 3 (SYSADMIT.com)

WiFi: Potencia y ubicación - Buenas prácticas - Capítulo 4 (SYSADMIT.com)

WiFi: Tipos de antena - Buenas prácticas - Capítulo 5 (SYSADMIT.com)

WiFi: Repetidor de red (Wireless uplink) - Buenas prácticas - Capítulo 6 (SYSADMIT.com)

WiFi: Roaming - Buenas prácticas - Capítulo 7 (SYSADMIT.com)

WiFi: Interferencias y reflejos - Buenas prácticas - Capítulo 8 (SYSADMIT.com)


"Ruta demasiado larga": Solución con GPO

Todo administrador de sistemas se ha encontrado en alguna ocasión con el siguiente problema:

Al intentar crear o eliminar o incluso leer una estructura de directorios de más allá de 256 caracteres aparece uno de los siguientes errores:

No se puede tener acceso a esta carpeta.

Ruta de acceso es demasiado larga.

No se puede crear la carpeta XXXX

El nombre de archivo o la extensión es demasiado largo.

En inglés: "file name too long" o bien "path too long".

Una vez nos encontramos con el error, si lo que queremos es eliminar la estructura, podemos utilizar, por ejemplo la siguiente técnica:

Pero de hecho el problema de "Ruta de acceso es demasiado larga" y los 256 caracteres no ocurre debido a una limitación en el sistema de ficheros NTFS o exFAT.

Los sistemas de ficheros NTFS o exFAT no tienen la limitación de los 256 caracteres.

El problema reside en la API de Windows y la variable MAX_PATH definida a 260 caracteres como máximo.

El valor de MAX_PATH no se puede cambiar.

Si para administrar la estructura (crear, eliminar, leer) la herramienta en cuestión utiliza la API (application programming interface) de Windows con la variable MAX_PATH tendremos el problema, por ejemplo, utilizando el Explorador de Windows.

Con Windows 10 a partir de los parches publicados en agosto de 2016 (Anniversary Update) o en Windows Server 2016 RTM se incorpora lo que podría resultar la solución definitiva del problema: Aplicar una directiva de grupo (GPO) de equipo.

Esta GPO de equipo la podremos encontrar como GPO local (gpedit.msc) o como GPO de dominio (gpmc.msc).

Ubicación de la GPO en inglés:

Policies > Computer Configuration > Administrative Templates > System > FileSystem > Enable Win32 long paths

GPO: Solución: "ruta demasiado larga"

Ubicación de la GPO en castellano:

Politicas > Configuración de equipo > Plantillas administrativas > Sistema > Sistema de ficheros > Habilitar rutas de acceso Win32 largas  

Especial atención con esta GPO porque si la activamos: La configuración queda guardada fuera de la zona del registro dedicada a las políticas.

Esto significa que la administración de la política deberá realizarse como si se tratase de una preferencia, por lo tanto, una vez activada y aplicada la política, para deshacer los cambios, será necesario realizar una GPO contradictoria.

Linux: Saber a qué grupos pertenece un usuario

En sistemas operativos Linux, los usuarios pueden pertenecer a mas de un grupo.

¿Cómo saber a qué grupos pertenece un usuario?


Veamos dos formas para saber a que grupos pertenece un usuario:

1) Comando groups:


Ejecutando el comando groups, nos aparecerán los grupos a los que pertenece el usuario actual.

Si ejecutamos groups seguido de un nombre de usuario, veremos los grupos a los que pertenece el usuario indicado.

Ejemplo:

[root@LINUX1 ~]# groups root
root : root bin daemon sys adm disk wheel

2) Comando id:


El comando id, nos muestra información acerca de la identidad del usuario.

Si ejecutamos el comando id, con los parámetros -Gn, conseguiremos obtener la lista de grupos a los que pertenece el usuario.

[root@LINUX1 ~]# id -Gn root
root bin daemon sys adm disk wheel

El parámetro -G, muestra todos los grupos a los que pertenece , mientras que el parámetro -n muestra el nombre en vez del número de grupo.


VMWare: Convertir vhdx en vmdk

Cada hipervisor utiliza un sistema de disco virtual distinto. 

Por ejemplo:

- Hyper-V: VHD (Virtual Hard Disk) / VHDX a partir de Windows Server 2012.

- VMWare: VMDK (Virtual Machine Disk)
 
Si somos administradores de infraestructuras virtuales VMWare, nos podemos encontrar con la necesidad de convertir discos virtuales de Hyper-V (vhd / vhdx) a VMWare (vmdk).

Un ejemplo de ello es si queremos implementar NanoServer en nuestra infraestructura VMWare vSphere ESXi.

La creación de una imagen de NanoServer desde PowerShell generará un fichero vhd o vhdx y está pensada para ser montada en una máquina virtual con el rol de Hyper-V.

Si queremos montar el fichero vhd o vhdx en una máquina virtual VMWare sin el rol de Hyper-V, deberemos convertir el fichero vhd o vhdx a vmdk.

Veamos las distintas posibilidades y herramientas para convertir ficheros VHD o VHDX a VMDK:

WiFi: Interferencias y reflejos - Buenas prácticas - Capítulo 8

El autor de este post es Pol Padrisa (@polpadrisa).

En este artículo vamos a centrarnos en las interferencias Wifi y con ello los elementos ambientales que debemos tener en cuenta en el momento en el que hagamos un estudio para determinar la ubicación de nuestros AP.

Muchos sysadmins basan la ubicación de sus AP sólo en términos de distancia y obvian elementos estructurales constructivos que pueden afectar al rendimiento de nuestra red.

Elementos arquitectónicos a tener en cuenta al diseñar la red WiFi:


Como ya explicamos en otros artículos los microondas de cocina tienen una frecuencia de trabajo situada en la misma banda 2.4Ghz (con ligeras variaciones).

Esto significa que la frecuencia utilizada por las redes Wi-Fi de esta banda está en la el rango de la resonancia de las moléculas de agua y, tal como ocurre con las generadas por el imán del microondas, será absorbida por todo objeto que contenga este elemento.

Es por este motivo que en entornos donde las ondas tengan que atravesar zonas húmedas, niebla, lluvia, arboles, cartón… es a priori más recomendable utilizar la banda de 5Ghz que la de 2.4GHz.

Cómo saber la versión de VMWare Tools

Podemos saber la versión de VMWare Tools a nivel de hipervisor ESXi o a nivel de máquina virtual (VM).

Es una buena práctica, disponer de la misma versión de VMWare Tools en todas las VMs y que esta sea una versión actualizada.

La forma más rápida y sencilla de obtener la versión de VMWare Tools de cada VM, es utilizando PowerCLI.


Con PowerCLI, podemos obtener una lista de cada VM y su versión de VMWare Tools:


Conectamos con PowerCLI al Virtual Center:

Connect-VIServer -Server XXX.XXX.XXX.XXX -User YYYYYYY -Password ZZZZZZZZ

y ejecutamos:

Get-View -ViewType VirtualMachine | select Name, @{ Name=”ToolsVersion”; Expression={$_.config.tools.toolsVersion}}

Cómo saber la versión de VMWare Tools con PowerCLI

Active Directory: Usuario no puede cambiar password

Una consulta técnica muy interesante que me han realizado es la siguiente:

Escenario:

En un entorno de Active Directory:

- Un usuario no puede cambiar el password, en cambio el administrador si puede hacerlo.

- La opción de la ficha del usuario: "El usuario no puede cambiar la contraseña" (*) está desmarcada.

(*) Usuarios y equipos de Active Directory (dsa.msc), propiedades sobre un usuario, pestaña "Cuenta", apartado "Opciones de cuenta", opción: "El usuario no puede cambiar la contraseña". 

Pre-VMWorld 2016 Barcelona

Un año mas, VMWare me ha invitado a asistir con un pase de blogger al VMWorld Europa, que tendrá lugar en Barcelona del 17 al 20 de Octubre.

Para todos aquellos que no habéis podido asistir nunca, os invito a que lo hagáis si os es posible.

En el VMworld encontrareis todas las novedades que vendrán en los próximos meses y nos ayudará a construirnos una perspectiva técnica a largo plazo.

Es un evento que organiza VMWare pero no solo encontraremos información sobre productos de VMWare, si no que también hay cobertura de todo el ecosistema que hay a su alrededor, encontraremos distintos fabricantes de: antivirus, firewalls, storage, conectividad, backup y una larga lista.

VMWare: ESXi Apagar todas las VMs desde SSH

En infraestructuras virtuales donde no disponemos de Virtual Center, ni de PowerCLI, una de las formas para detener de forma ordenada todas las VMs de un host VMWare ESXi es vía VSphere Client, sin embargo si pretendemos automatizar el proceso podemos utilizar la shell de ESXi vía SSH.

Veamos el procedimiento para apagar VMs de un host VMWare ESXi desde SSH:

Para ello, utilizaremos el comando vim-cmd.

Ejemplo:

[root@ESX1:~] vim-cmd vmsvc/getallvms
Vmid   Name          File               Guest OS       Version  
1      SRV2   [NAS] SRV2/SRV2.vmx   winLonghornGuest   vmx-08
2      SRV1   [SAN] SRV1/SRV1.vmx   winLonghornGuest   vmx-08
 
[root@ESX1:~]  vim-cmd vmsvc/power.shutdown 2

Según el ejemplo, podemos ver como con el comando vim-cmd vmsvc/getallvms, listamos todas las VMs registradas en el host VMWare ESXi.

Para detener una VM, podemos ejecutar vim-cmd vmsvc/power.shutdown y a continuación el identificador (Vmid).

Si nuestra idea es detener todas las VMs que están funcionando sobre el host VMWare ESXi, podemos utilizar el script: /sbin/shutdown.sh

Veamos el procedimiento para apagar TODAS las VMs de un host VMWare ESXi desde SSH:

1) Instalar VMWare Tools en todas las VMs.

2) Modificar la configuración de apagado del host VMWare ESXi:

Desde VSphere Client, nos situamos sobre el host VMWare ESXi, pestaña "Conifguration", apartado "Virtual Machine Startup and Shutdown" y "Properties"

A continuación, dentro del apartado "System Settings", marcamos la opción:

"Allow virtual machines to start and stop automatically with the system"

después dentro del apartado: "Shutdown action", marcamos la opción: "Guest Shutdown".

La opción "Guest Shutdown" detendrá de forma ordenada las VMs utilizando las "VMWare Tools".

Windows: Carpeta descargas lenta

Uno de los problemas que vienen sucediendo desde Windows 7 y también lo encontraremos en versiones superiores como Windows 8.1 o Windows 10, es que la carpeta predeterminada de descargas va lenta al intentar acceder a ella desde el explorador de windows, especialmente cuando en su interior residen muchos ficheros.

Este comportamiento no sucede en las versiones servidor, por ejemplo: Windows Server 2008 o superiores.

También otro detalle de este comportamiento es que en una carpeta de descargas que va lenta desde el explorador de Windows, si accedemos desde CMD o PowerShell en la misma, vemos como el acceso va rápido.

Este problema puede ser debido a la personalización predeterminada de la vista de carpetas.

Si nos situamos con el explorador de Windows sobre la carpeta de descargas ubicada en el perfil del usuario y hacemos: botón derecho, propiedades, veremos la pestaña: "Personalizar".

A continuación leemos:

¿Qué clase de carpeta desea?

Optimizar esta carpeta para:

y al desplegar, vemos:

Elementos generales, Documentos, Imágenes, Música, Vídeos.

También veremos la opción:

"Aplicar también esta plantilla a todas las subcarpetas"

Si configuramos lo siguiente, no tendremos problemas de lentitud al explorar la carpeta debido a la vista:

Seleccionamos:  "Elementos generales" y marcamos: "Aplicar también esta plantilla a todas las subcarpetas".

Windows: Carpeta descargas lenta

WiFi: Roaming - Buenas prácticas - Capítulo 7

El autor de este post es Pol Padrisa (@polpadrisa).
 
Cuando configuramos una red WiFi con varios AP, lo primero que nos viene a la cabeza es si debería poner o no el mismo nombre de red o SSID en todos los APs.

En este artículo vamos a ver cómo podemos configurar nuestra Wifi en el llamado roaming o itinerancia para que los usuarios no tengan que estar decidiendo a qué AP conectarse.

Múltiples SSID


Algunas veces hemos visto en un hotel con la nomenclatura:

WIFI-HOTEL-PLANTA-3
WIFI-HOTEL-PLANTA2
WIFI-HOTEL-HALL
ETC.

Mediante el SSID o nombre de red, el usuario puede distinguir qué Wifi debería ser mejor para su conexión, si se encuentra en el HALL seleccionará la red llamada WIFI-HOTEL-HALL y debería tener la mejor señal y canal para su conexión.

Este modelo se utilizaba bastante en los inicios del mundo WiFi, pero ahora mismo es bastante raro de encontrar. Los usuarios quieren desplazarse mientras usan servicios de llamada o videollamada.

Cuando el Wifi se utilizaba desde portátiles, este modelo era bastante funcional, en el momento en que empezamos a utilizar smarphones y tablets empezamos a necesitar una cobertura en itinerancia o roaming.

El principal problema de usar distintos SSID es que los usuarios debían conectarse manualmente a cada red según se encontraban en una u otra zona del hotel es decir no había roaming.

El concepto de roaming (itinerancia) está descrito en la Wikipedia como “utilizado en las redes Wi-Fi significa que el dispositivo Wi-Fi del cliente puede desplazarse e ir registrándose en diferentes bases o puntos de acceso.”.

La idea es que el cliente se valide en nuestra red WiFi en cualquier lugar y pueda desplazarse, es decir, que las decisiones sobre qué AP usar deja de tomarlas el usuario y pasan a tomarlas los AP.

Red Wifi con itinerancia o roaming:

SSID común:

Para conseguir una red Wifi con
itinerancia debemos utilizar el mismo SSID en todos los AP:

Ej. WIFI-HOTEL

Olvidándonos de planta, hall, etc. Ya que nuestra red ahora será global.

Solapamiento de cobertura:

Es bastante evidente pero para poder ofrecer roaming, necesitamos que todas las zonas estén con cobertura de tal forma que no haya saltos sin cobertura entre la zona de un AP y otro:

WiFi: Roaming - Buenas prácticas - Capítulo 7

VMWare: Abrir vmdk desde Windows

En ocasiones podemos tener la necesidad de montar un fichero VMDK (Virtual Machine Disk) desde Windows para poder extraer información de su interior.

En primer lugar deberemos descargar el fichero VMDK al equipo Windows, para ello, podemos utilizar vSphere Client, hacer un browse datastore, seleccionar el fichero VMDK y descargarlo.

Hemos de tener en cuenta que al descargarlo, tanto si el disco fue provisionado como Thick o como Thin, al descargarlo sobre un sistema de ficheros NTFS, el fichero VMDK ocupará como si se tratase de un disco Thick.

En este post, veremos varios métodos para abrir un fichero VMDK desde Windows:

Método 1: Abrir un fichero VMDK desde Windows con VMWare Workstation:


Abrimos "VMWare Workstation": Nos situamos en el menú "File" y seleccionamos la opción: "Map Virtual Disks...", a continuación, pulsamos sobre el botón "Map" y nos aparece otra ventana: "Map Virtual Disk".

En la ventana "Map Virtual Disk", pulsamos sobre el botón "Browse" y seleccionamos el fichero VMDK que queremos abrir.

También mantenemos marcado el check de: "Open file in read-only mode (recommended)", de esta forma conseguimos que no se hagan modificaciones en el interior del fichero VMDK.

Finalmente en "Map to", seleccionamos una letra de unidad libre donde se montará el fichero VMDK.