Archivo de la categoría: Sistemas

Modificando MTU…y no hablamos en vacuno

Al cambiar la MTU (tamaño máximo del paquete) de un equipo deberemos también cambiarla de todos los equipos del mismo segmento (o VLAN), ya que sino esperan paquetes mucho más pequeños. También deberemos tener en cuenta que si nos comunicamos con equipos de fuera de este segmento el router deberá trocear los paquetes, con la carga extra que supone.

 

Para Windows Server:

  • netsh interface ipv4 show interfaces
  • netsh interface ipv4 set subinterface “10” mtu=1454 store=persistent
  • ping google.com -f -l 1500

 

Para Linux:

  • Usando el comando ifconfig: ifconfig eth3 mtu 9000
  • Usando el comando ip: ip link set eth2 mtu 9000
  • nano /etc/sysconfig/network-scripts/ifcfg-eth2:
    DEVICE=eth2
    BOOTPROTO=static
    IPADDR=10.1.1.1
    NETMASK=255.0.0.0
    ONBOOT=yes
    ETHTOOL_OPTS=”autoneg on”
    MTU=9000
  • ping google.com -v -s 1500

 
Fuentes:

 

 


NFSv4 y ESXi, de verdad de la buena

NFSv4
Currently, there are three versions of NFS. NFS version 2 (NFSv2) is older and is widely supported. NFS version 3 (NFSv3) supports safe asynchronous writes and a more robust error handling than NFSv2; it also supports 64-bit file sizes and offsets, allowing clients to access more than 2Gb of file data.

NFS version 4 (NFSv4) works through firewalls and on the Internet, no longer requires an rpcbind service, supports ACLs, and utilizes stateful operations. Red Hat Enterprise Linux 6 supports NFSv2, NFSv3, and NFSv4 clients. When mounting a file system via NFS, Red Hat Enterprise Linux uses NFSv4 by default, if the server supports it.

All versions of NFS can use Transmission Control Protocol (TCP) running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3 can use the User Datagram Protocol (UDP) running over an IP network to provide a stateless network connection between the client and server.

When using NFSv2 or NFSv3 with UDP, the stateless UDP connection (under normal conditions) has less protocol overhead than TCP. This can translate into better performance on very clean, non-congested networks. However, because UDP is stateless, if the server goes down unexpectedly, UDP clients continue to saturate the network with requests for the server. In addition, when a frame is lost with UDP, the entire RPC request must be retransmitted; with TCP, only the lost frame needs to be resent. For these reasons, TCP is the preferred protocol when connecting to an NFS server.

The mounting and locking protocols have been incorporated into the NFSv4 protocol. The server also listens on the well-known TCP port 2049. As such, NFSv4 does not need to interact with rpcbind[2], lockd, and rpc.statd daemons. The rpc.mountd daemon is still required on the NFS server to set up the exports, but is not involved in any over-the-wire operations.

Fuente: http://forums.nas4free.org/viewtopic.php?t=259
NAS4Free soporta NFSv4, pero se ha de activar usando el checkbox. Sólo se podrán conectar los ESXi 6.0 o superiores.
Cómo activar NFSv4 en FreeBSD 9.1:
http://plone.lucidsolutions.co.nz/storage/network/nas4free/enable-nfs-v4-on-nas4free-v9.1/view

 

NFSv4 y ESXi

ESXi 5.5 no soporta NFSv4. Sólo NFSv3, el cual va por UDP.

ESX 6.0 sí soporta NFSv4.1:
If you are using NFS storage for VMs (either on a hardware NAS box or hosted on a VM) with your ESXi hosts then you might be interested in the new support for NFS version 4.1. Version 4.1 has superior new features (state management, improved locking, Kerberos authentication) and can be much more efficient and performant than 3.0 (which was exclusively supported with ESXi 5.x), but that depends very much on the client implementation. Time and the performance tests to come will tell how much you can gain from it with ESXi.

NAS4Free soporta NFSv4, pero se ha de activar usando el checkbox. Sólo se podrán conectar los ESXi 6.0 o superiores.

Guías de buenas práctica spara conectar ESXi a NFS:

NFS Best Practices – Part 1: Networking

NFS Best Practices – Part 2: Advanced Settings

Con ESXi 6.0 y NFSv4 ya se puede hacer un balanceo de carga accediendo al NFS por varias IPs. Antes todo el datastore NFS se comunicaba por una única conexión TCP/IP. En el NAS4Free podríamos usar LAACP para que pueda ser accedido por dos ips distintas: https://www.youtube.com/watch?v=4d_-JZyvdgw

Multipathing and Load-balancing:
Now onto the improvements. NFS v4.1 introduces better performance and availability through load balancing and multipathing. Note that this is not pNFS (parallel NFS). pNFS support is not in vSphere 6.0.
Setup NFSv4.1 datastoreIn the server(s) field, add a comma separate list of IP addresses for the server if you wish to use load-balancing and multipathing.

Fuente: http://cormachogan.com/2015/02/04/vsphere-6-0-storage-features-part-1-nfs-v4-1/


XPEnology no tiene nada que ver con güindows

NAS4Free es mi NAS de cabecera, pero en un proyecto no he conseguido que se entendiera bien con los clientes windows en el tema de permisos. Mientras los permisos de ZFS decían que los usuarios del grupo podían escribir sin problemas en un fichero creado por otro usuario de ese mismo grupo, windows se empeñaba en pasar tres pueblos de ese aspecto y no dejar modificar ficheros cuyo propietario no fuera él mismo.

Este problema, pequeño, casi insignificante, ha hecho que casi se vaya al traste todo el proyecto.

Dejando de lado cuestiones como lo sencillo que es caminar sobre el agua y las especificaciones siempre y cuando estas estén congeladas y que no suelo vender humo sin haberlo fumado antes, este problema podría incrementar en más de mil napos el montante del proyecto tras ser aceptado. Sí: lo que cuesta un windows server 2012, vamos….

Así que ha habido que pasar por diversas alternativas:

  • windows 7 como servidor de ficheros: descartado, puesto que el número de usuarios supera los 10.
  • FreeNAS: descartado, puesto que precisamente NAS4Free es un fork del otro.
  • Otras distros NAS: a todas les termina de faltar algo.
  • Cabina de discos Synology: como softwware sería perfecto, pero el problema es que si casca la placa o fuente o tarjeta de red de la cabina…..el downtime es insostenible o incluso obliga a comprar una cabina nueva y rear por que se importe todo sin problemas.

 

Finalmente….se ve que existe un proyecto de dudosa moral….. que permite instalar el software de dichas cabinas, llamado DSM, en un PC. Cómo no?, nos pusimos a ello 🙂

Murphy estaba gracioso ese día. La verdad es que llevaba gracioso ya todo el proyecto. Pero a base de cabezazos y algunas dosis de antimurphys, conseguimos el objetivo: un DSM sobre el PC que el habíamos vendido al cliente.

A groso modo y para que no caiga en el olvido, existen varios puntos a destacar para entender el cotarro:

  • XPEnoboot es la base de todo, con lo que siemre se arranca, tanto en la instalación, como en un upgrade como en producción. Se puede grabar un ISO en CD físico o vrtual, se puede usar una IMG para con el WinDiskImager crear un USB de arranque o se puede descargar directamente un VMDK para virtualización.
  • Al arrancarlo por primera vez, seleccionar el boot de “install/upgrade”. Instalar en un PC el Synology Asistant (descargable gratis de la web de Synology). Usarlo para encontrar el PC en la red y con el botón dcho sobre él, subirle el fichero PAT con la versión del DSM a instalarle. Nunca usar el interfaz web para esta tarea, salvo en el caso de instalar un upgrade.
  • No importa que el teclado se quede bloqueado. No importa que nos diga que no ha encontrado red. Buscadlo, que aparece y le dais caza. Es muy puñetero.
  • Tras instalarlo, reinicia. En pantalla podéis ver si os podéis conectar ya o no. Eso sí, reinciia, usando el usb, pero desde la primera opción de arranque, la normal. Producción.
  • Desactivad las opciones de actualziación del software y tal y acordaos SIEMPRE de guardar una copia de la configuración, desactivar el halt on F1 de la bios y esas cosas.
  • Para actualizar a un update, reiniciáis desde la web (no se puede apagar desde l botón frotnal del PC; una pena). Arrancáis en el ercer mdoo de “install/upgrade”. Os conectáis a su web y le subís el fichero PAT de update. Reiniciará al acabar.

 

Lo bueno es que si la cagas, las configuraciones las tienes en backup y los discos y sus relaciones y carpetas compartidas están a salvo y serán reimportados cuando lo reinstaléis. Disfrutadlo.

 

Fuentes:

http://xpenology.me/downloads/

http://eddgarrojas.com/miblog/xpenology-convierte-tu-pc-en-un-nas/

https://juanjodominguez.wordpress.com/2015/02/02/montando-synology-dsm-nas-en-un-portatil/

https://www.profesionalreview.com/2015/06/15/como-instalar-xpenology-dsm-en-tu-nas-manual-completo/

 

 


Importar un volumen LVM en otro linux

El otro día cascó una minicabina de dos discos en espejo a un cliente.

Su software era incapaz de reimportar los discos. En su lugar los reformateaba al reagregarlos como espejos así que me dispuse a sacarlos y analizarlos individualemnte a ver qué podíamos hacer, ya que el cliente lo estaba usando como almacenamiento sin hacer backup, claro.

Aprovecho para recordar que da igual cuántos NAS, discos, etc tengamos. Al final, SIEMPRE, vamos a depender en última instancia de un disco USB grande formateado de manera estándar y sin encriptación  de donde sacar nuestros datos.

Estos NAS pequeñitos suelen tener un linux con una relación de discos montada sobre un LVM. Se trata de una configuración estándar de windows y deberíamos pdoerla importar en cualquier Ubuntu, por ejemplo.

Desmonté el NAS y saqué los discos. Cómo no!: eran dos seagate. Puse uno delos discos en una base USB y arranqué un ubuntu liveCD (realmente era una VM arrancando con el iso bajo ESX y le agregué el usb device que le presentaba el ESX donde pinché la base usb, pero bueno).

Tras confirmar que el formato de las particiones no era estándar, pero sí que me daba información sobre que era un sistema LVM, me descargué el paquete de utilidades de LVM2 y ejecuté los comandos para importar el volumen, esperando fuera un espejo. Efectivamente resultó ser un espejo y pude rescatar los datos de uno de los discos copiándolos a otro USB. El otro disco del espejo estaba cascado y se llevó por delante el NAS entero. Gran seguridad, sí señor……

 

A continuación los comandos que usé y la fuente de información usada:

Fuente: http://ubuntuforums.org/showthread.php?t=1977488

Comenzamos con:

sudo apt-get install lvm2
sudo mkdir /mnt/destino

Y con sudo todo:

1. sudo fdisk -lu 
2. sudo pvscan
3. sudo vgscan
4. sudo vgchange -a y 
5. sudo lvscan
6. sudo mount /dev/lvmvolume/root /mnt/destino

El nombre “lvmvolume/root” variará en nuestro caso siempre, conociéndolo en el punto 5.

Luego montamos un disco externo usb en esa VM y le copiamos los datos a rescatar tranquilamente.


Eramos jóvenes e imprudentes…

….y esa imprudencia es la que te daba el empuje para no ver ningún límite y conseguir volar.

El otro día, con media hora de aburrimiento por delante, me propuse un problema. Y si alguien precisa de un radioenlace para coger wifi e internet desde una vivienda o edificio que no lo tuviera adecuado o no quisiera pagar dos veces por ello, etc….unir dos redes locales….. así que me puse al tajo.

 

Lo primero fue echar los dados en la gran G, claro… hasta que recordé un enfoque alternativo: mirar equipos que se vendean en una tienda tan espcializada como Ciudad Wireless.

 

Tras rematar con unas búsquedas en Youtube, hemos sacado varias conclusiones, aparte de que antes todo esto era un proyecto largo y se hacía casi todo a mano. Hoy hasta un lammer (aunque creo que ese término ya ni se acuña, porque hasta nosotros mismos nos hemos convertido en ello al poder buscarlo todo y copiarlo de los resultados de al gran G) podría montar un radioenlace de kilómetros sin mayor problema.

Estas gestas antes estaban reservadas para unos pocos. Era como conquistar el Himalaya….ahora….te llevan en helicóptero hasta la cumbre. Arf……

 

Soluciones para cobertura local wifi

Os acordáis de cuando salió el tema e las redes wifi mesh?. K grande, eh?. Hoy en día lo que se llevan son los repetidores wifi. Muy baratos y efectivos esos TP-Link de 25 euros. siemrpe es mejor cablear los APs, pero bueno…. casi nunca se puede hacer.

Pues hoy en día, esta gente del wifi mesh te vende ya aparatos diversos y con unos accesorios muy prácticos y muy bien pensados. En concreto, este es un producto genial:

OM2P-HS 300 Mbps Access Point 300 Mbps 802.11n (95$)

http://www.open-mesh.com/products/access-points/om2p-hs.html

Lo soporta todo, aunque se recomienda su cableado etehrnet directo al switch troncal de la red. Si se deja que interconecten en plan wifi mesh, en cada salto la velocidad se divide por 2. Así que podríamos tener movida si tiramos de una fuerte señal de video streaming o mediana, pero con usuarios concurrentes.

Si queremos usar un único AP para todo el edficio, siempre tenemos el fantástico Asus N66U (150 euros) y ese genial Toamto Firmware, incluso, por si queremos agregarle funciones muy profesionales.

Además, también disponemos de este platillo volante de primera fila:

Ubiquiti Networks UBIQUITI UAP-LR EnterpriseAP-LR, UniFi 300mbps (90 euros)

http://www.ciudadwireless.com/ubiquiti_networks_ubiquiti_uap-lr_enterpriseap-lr–p-4730.html

 

Soluciones para radioenlaces

Pues aquí la verdad es que ya no hay discusion. Ubiquity o una mezcla de una antena de ellos y un equipo Mikrotik.

Ubiquiti UBIQUITI PBE-M5-400 5GHz NanoBeam, AIRMAX, 400mm (95 euros)

http://www.ciudadwireless.com/ubiquiti_ubiquiti_pbe-m5-400_nanobeam-_airmax–p-7019.html

Ubiquiti Rocket M5 Titanium airMAX

http://www.nv-networks.com/en/ubiquiti-rocket-m5-titanium-airmax.html

Y si quremos ser un WISP serio, nada de radioenlaces dedicados para un cliente, tenemos estas maravillas que ya comienzan a rascar el bolsillo (la AirFibre):

https://www.ubnt.com/broadband/#airmax

 

Y un par de videos para acojonar y quitarte el sincio:

WISP con Mikrotik

Point to Point Radio Link NanoBeam M5 400 Full Configuration (37 km)

Guía MIKROTIK + UBIQUITI – CONFIGURACION BASICA.

Subiendo torre a cambiar un Rocket M5 por Rocket Titanium


Protejamos a nuestros pequeñuelos

Los pequeñuelos. Esos simpáticos animalitos que se empeñan en hacer click en los emails de aviso de recogida de paquete que nunca pidieron. O en esos donde el banco les solicita un cambio de claves. O en esos que pone “NO PINCHES, SO GILIPOLLAS!”. Entrañables…..

Así que nuestro deber como cuidadores del zoo es poner medidas “por su propia seguridad”, sobre todo hoy en día que el ransomware está más de moda que nunca.

La cosa la acometeremos en varios niveles:

  • configurar los servidores DNS de Norton en el DHCP de nuestro router ADSL y su interfaz WAN, si se pudiere: 199.85.126.20 y 199.85.127.20
  • instalar un UTM: siempre hemos recomendado pfSense, pero hoy en día la mejor alternativa es SOPHOS UTM Home User. Con un máximo de 50 equipos LAN a proteger, las características que nos otorga son de mojar la pestaña, oigan.
    • darle ip fija y asegurarse que tira de dichos servidores DNS.
    • deshabilitar el DHCP en el router internet
    • habiltar el DHCP server en el UTM y que se autopublique de servidor DNS y gateway a los clientes DHCP de la red.
    • bloquear el uso de servidores DNS aparte de los de Norton.
    • bloquear países exóticos que etán muy bien para ir de vacaciones pero no para visitar sus maliciosas webs.
    • bloquear el tráfico típico irc 6666-6670/TCP
    • bloquear el tráfico al puerto 9001/TCP
    • ingeniárselas para bloquear el tráfico a la lista de nodos TOR, que cambia cada 31 minutos.
    • es sano mantener una lista negra de sitios y una lista blanca.
    • limitar en la medida de lo posible los servidores SMTP a los que podrá enviarse correo.
    • dejar sólo acceder al correo de gmail.
    • activar el filtrado antivirus en la navegación web.
    • activar las categorías de webs que se desean bloquear.
    • establecer credenciales para una conexión VPN desde internet.
  • se puede instalar en un servidor de máquinas virtuales o en una máquina física. Se recomienda dos tarjetas de red: una al router ADSL y otra a la LAN, aunque se podría poner una tercera para más cosas…balanceo de conexiones a internet, zona DMZ….
  • si además se quiere archiproteger la wifi, getionarla de manera centralizada, crear redes de invitados, credenciales temporales….se puede adquirir hotspots por unos 300 euros cada uno. Soportan PoE.

Fuentes:


Dear Mr. Melon: the hard disk will always FAIL

Pues eso: que los discos duros SIEMPRE fallarán. El único problema que no terminamos de solventar es saber exactamente cuándo.

Y Uds. se preguntarán cosas como, pero si el MTBF y el SMART ya nos lo indican, no?… pues léanse este resumen de un informe de G y verán que eso es una M. Pero de las gordotas, eh???…

Google’s Disk Failure Experience
http://storagemojo.com/2007/02/19/googles-disk-failure-experience/

 

Básicamente dice que:

  • los discos fallan en los primeros tres meses si traen “garbanzo”.
  • tras eso, no deberían dar guerra hasta cumplir dos años.
  • la temperatura de funcionamiento no superior a 45 grados es la ideal.

 

Sobre fiabilidades por marca, la gran pregunta al plantear un sitema de almacenamiento redundante, tenemos estas opiniones (basadas en BlackBlaze) que más o menos vienen a decir lo mismo: HGST Ultrastar

 

Y ya puestos…. un poco de Helio?

Pues parece que WD y HGST han sacado un disco relleno de helio en vez de aire sin partículas y la refrigeración debe permitir un rendimiento de vueltas de lo más mareante, aunque el editor lo duda. Anuncian que s de 6TB y que consume menos energía, aparte del sellado que le hace sumergible antes fugas de refrigeración líquida. Helio o vaporware?¿??:

http://www.extremetech.com/computing/170213-wd-releases-6tb-ultrastar-he6-the-worlds-first-helium-filled-hard-drive