miércoles, 23 de septiembre de 2020

Qué es y cómo apuntarse a Windows Insider



¿Qué es Windows Insider? ¿Cómo enrolar un ordenador al programa?



Windows Insider es una iniciativa de Microsoft destinada a los usuarios de Windows que permite a quien esté apuntado en ella probar versiones preliminares (o nuevas características) del sistema operativo Windows antes de que estas sean lanzadas al gran público. A cambio, Microsoft pide a los Insiders sus opiniones respecto a las nuevas funcionalidades de cara a mejorar el producto.

Este programa fue anunciado el 30 de septiembre de 2014 junto con Windows 10. A finales de ese mismo año, alrededor de 1,5 millones de personas ya se habían instalado la primera preview de la siguiente build de Windows 10 y ya estaban flighting.


Flighting



Flighting es un término inventado por el departamento de marketing de Microsoft usado para denominar el proceso de ejecutar las compilaciones de Windows 10 Insider Preview. Este proceso incluye:

• Configurar nuestro dispositivo en uno de los canales de Windows Insider.
• Instalar las actualizaciones preview (de vista previa) de ese canal.
• Ejecutar y probar esas compilaciones previas.


Canales



Microsoft divide el programa Insider en 5 canales, donde 2 de ellos son sólo para uso interno, es decir, solo visibles por sus empleados.

El primer canal se llama Canary, y es donde los desarrolladores de Microsoft proponen y prueban por primera vez nuevas funciones para Windows.

Una vez creada una nuva función, esta llega al canal Dev y se libera al público para que de su feedback.

Una vez testeadas en el canal Dev, las actualizaciones vuelven a un canal interno, el canal Microsoft, donde además de los desarrolladores, el resto de empleados de Microsoft pueden también probarlas.

Una vez pulidas por los programadores tras el feedback recibido desde Dev, las actualizaciones pasan del canal Microsoft al canal Beta, volviendo a ser públicas.

En última instancia, las actualizaciones llegan al canal "Release Preview", donde los Insiders reciben las próximas actualizaciones acumulativas unos días antes de su lanzamiento oficial, para acabar de pulir incompatibilidades o problemas derivados de hardware poco común.

No hace falta decir que al canal Dev llegan muchas más actualizaciones que al canal Beta, pero cuando las actualizaciones llegan al canal Beta, estas ya han sido pulidas y funcionan mejor que cuando llegaron a Dev. Por último, las Release Preview apenas recibirán builds, aunque días antes de que se lance una gran actualización se envían allí para que puedan ser probadas anticipadamente por los Insiders.


Ventajas y desventajas



La ventaja principal de este programa es la posibilidad de ser una de las primeras personas en probar cada nueva función de Windows. Otra ventaja de Insider es que siendo miembro del programa tienes Windows gratis, pues una vez que inscritos en el programa podemos descargarnos la ISO de la última build disponible de Windows dntro del programa.

En el otro lado se encuentra la inestabilidad que puede padecer un PC al usar versiones no finales de un producto, con culegues ocasionales y problemas varios.


Cómo apuntarse a Windows Insider



Para apuntarse a Windows Insider, hace falta un ordenador con Windows 10.

Ir a Inicio, botón derecho y clic en configuración:


Una vez allí, ir a Actualización y seguridad y luego a Programa Windows Insider:


A continuación, clicar el botón "Comenzar" y acto seguido, vincular una cuenta:


Nos registramos en el programa Windows Insider y aceptamos las condiciones de uso:


Y por último, elegimos el canal que queramos probar.


A partir de este momento, ya recibiremos las actualizaciones lanzadas desde el canal seleccionado.


Fuentes:

https://insider.windows.com/es-es/
0

miércoles, 16 de septiembre de 2020

Rutas estáticas persistentes en SLES



Cómo crear (y eliminar) rutas estáticas persistentes en un SUSE Linux Enterprise Server.



Si añadimos una ruta estática a un SUSE Linux Enterprise Server con el comando ip route add y reiniciamos la máquina después, comprobaremos que las rutas añadidas de esta manera se pierden tras un reinicio, es decir, son temporales.

Para añadir rutas estáticas persistentes a un SLES, es decir, rutas que se mantengan en el sistema operativo tras reiniciar la máquina, deberemos editar dos archivos: /etc/sysconfig/network/routes y /etc/sysconfig/network/ifroute-* y añadirlas en uno de ellos.


Archivos



La tabla de rutas persistentes de un SUSE Linux Enterprise Server se encuentra en el archivo:

/etc/sysconfig/network/routes

Adicionalmente, se pueden añadir rutas a un adpatador específico editando un archivo del tipo:

/etc/sysconfig/network/ifroute-*

Es decir, si tenemos un adaptador llamado eth0 configurado en el archivo ifcfg-eth0, podemos crear rutas estáticas que afecten solamente a este adaptador editando el archivo:

/etc/sysconfig/network/ifroute-eth0


Añadir ruta estática



Las entradas en los archivos de configuración de enrutamiento pueden seguir uno de estos 3 patrones:

DESTINO GATEWAY MÁSCARA INTERFAZ
DESTINO GATEWAY PREFIJO INTERFAZ
DESTINO/PREFIJO GATEWAY INTERFAZ

Para omitir el GATEWAY, MÁSCARA o PREFIJO escribir - (guión).

El destino siempre se escribe en la primera columna. Este puede ser tanto un host como una red, así como un FQDN que la máquina sepa resolver (por ejemplo, host.dominio.com).

La segunda columna contiene el gateway (desde donde se enviará el tráfico al destino).
La palabra clave default, por su parte, indica que la ruta usa la puerta de enlace predeterminada.

La tercera columna está obsoleta; solía contener la máscara de red IPv4 del destino, del tipo máscara (por ejemplo 255.255.255.0) o prefijo (/24). Hoy en día se usa una combinación de host o red con su prefijo directamente en la primera columna. Por ejemplo, 192.168.0.0/16 para IPv4 o fc00::/ 7 para IPv6.

Por último, la cuarta columna nos indica la interfaz a usar.


Mostrar rutas



Hay dos formas de visualizar las rutas estáticas persistentes de un sistema: por comando o por archivo.

Podemos usar el comando ip route show para ver las rutas estáticas configuradas en un sistema:

HOST# ip route show default via 192.168.4.1 dev eth0 192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.2 192.168.7.0/24 dev eth1 proto kernel scope link src 192.168.7.2

(Recordar que el comando ip route sustituye el antiguo comando netstat -nr).

De otro modo, podemos mirar el contenido de uno de los archivos mencionados anteriormente:

HOST# cat /etc/sysconfig/network/routes 192.168.4.0 192.168.4.1 255.255.255.0 eth0 192.168.7.0 192.168.7.1 255.255.255.0 eth1

Sea cual sea el método elegido, deberíamos ver las mismas rutas.


Eliminar ruta estática



Para eliminar alguna ruta, basta simplemente con borrarla del archivo en cuestión.


Fuentes:

https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-network.html#sec-network-man...
https://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch14s05.html
0

miércoles, 9 de septiembre de 2020

Especificar IP de origen desde proxy NGINX



Cómo enviar peticiones desde una IP de origen concreta en un proxy inverso NGINX.



Puede que tengamos un servidor web que solo acepte conexiones de un determinado rango IP y que tengamos un NGINX por delante actuando de reverse proxy que no disponga de una IP de ese rango o que sí disponga de ella, pero no la use a la hora de enviar tráfico a dicho servidor, por lo que los paquetes no lleguen desde el NGINX al servidor final.

Para solucionar este problema, podemos asignar una IP secundaria a nuestro NGINX y especificar que para ese servidor, usaremos esa IP secundaria como origen a la hora de enviarle tráfico.

Para especificar desde qué IP se envía tráfico hacia un servidor web final, podemos usar la directiva proxy_bind antes de proxy_pass en el bloque location dentro del bloque server de un dominio:

server { server_name dominio1.com; ... location /app1/ { proxy_bind 127.0.0.1; proxy_pass http://example.com/app1/; } } server { server_name dominio2.com; ... location /app2/ { proxy_bind 127.0.0.2; proxy_pass http://example.com/app2/; } }

La dirección IP también se puede especificar con una variable, p.e $server_addr.

Primero declaramos la variable y su valor:

set $server_addr "127.0.0.1";

A partir de aquí, ya la podemos usar dentro de la directiva proxy_bind de cuantos dominios queramos:

server { server_name dominio3.com; ... location /app3/ { proxy_bind $server_addr; proxy_pass http://example.com/app3/; } } server { server_name dominio4.com; ... location /app4/ { proxy_bind $server_addr; proxy_pass http://example.com/app4/; } } ...

De esta forma, podemos usar dicha variable en varios dominios y si algún día cambiamos la IP desde la que se origina el tráfico, no hará falta ir línea por línea cambiando su valor sino que podremos cambiarla una sola vez en la declaración de la variable.


Fuentes:

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
0

miércoles, 2 de septiembre de 2020

Acceder a Google Drive desde el escritorio



Cómo acceder a Google Drive desde nuestro explorador de Windows, Mac o Linux.



Google Drive es un servicio de alojamiento de archivos en la nube creado por Google en 2012. Este servicio nos permite disponer de hasta 15 GB por cuenta para guardar fotos, documentos, copias de seguridad, etc. alojados en servidores de Google sin gasto alguno.

Para disfrutar de Google Drive, deberemos usar una cuenta de gmail o vincular una cuenta de correo electrónico existente con Google. Una vez hecho esto, ya podremos usar Google Drive desde el navegador web y/o desde la aplicación de escritorio.

Para acceder a Google Drive desde el escritorio de nuestro ordenador como si de una carpeta más del sistema se tratara, deberemos descargar "Backp and Sync" (Copia de seguridad y sincronización) desde:

https://www.google.com/intl/es-419_ALL/drive/download/backup-and-sync/

Al inicio de la instalación, el programa nos pide iniciar sesión a nuestra cuenta Google:



Luego debemos elegir si queremos maneter sincronizadas las carpetas de fotos, vídeos y documentos de nuestro sistema operativo o si queremos mantener Google Drive como una carpeta independiente:



A continuación, y muy importante, debemos marcar "sincronizar mi unidad con este ordenador". Si no lo marcamos, no veremos los cambios que hagamos en nuestro PC en el Drive ni viceversa.



Una vez hecho esto, ya podremos acceder a nuestros archivos contenidos en el Drive como si de una carpeta más del ordenador se tratase:



Solo recordar que el límite de espacio del plan gratuito para este servicio es 15 GB.
0

miércoles, 26 de agosto de 2020

Incrementar tamaño de / en EC2 Linux



Cómo incrementar el tamaño de la partición raíz ( / ) de un EC2 Linux en Amazon Web Services.



Si tenemos una instancia Linux en AWS, puede pasarnos que nos quedemos sin espacio en el disco principal de la máquina y no tengamos más remedio que ampliar el número de GB del disco.

Antes de ampliar la partición raíz, debemos averiguar en qué disco está situada la partición:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Listamos los discos del sistema con el comando lsblk y encontramos el disco xvda:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 100G 0 disk └─xvda1 202:1 0 100G 0 part /

Ahora ampliamos el espacio del disco xvda desde la consola de AWS.

Volvemos a lanzar el comando lsblk y vemos como xvda ha subido de tamaño:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 100G 0 part /

Llegados a este punto, tenemos un disco ampliado, pero la partición raíz sigue igual:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 99G 60G 35G 64% / tmpfs 799M 0 799M 0% /run/user/1000

Ampliamos la partición /dev/xvda1:

ip-10-250-4-103:/home/ec2-user # sudo growpart /dev/xvda 1 CHANGED: partition=1 start=2048 old: size=209713119 end=209715167 new: size=524285919,end=524287967

Comprobamos que haya cogido el nuevo espacio asignado:

ip-10-250-4-103:/home/ec2-user # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 250G 0 disk └─xvda1 202:1 0 250G 0 part /


EXT4



Si el disco está particionado con EXT4, usamos resize2fs para acabar de ampliar la partición raíz:

ip-10-250-4-103:/home/ec2-user # sudo resize2fs /dev/xvda1 resize2fs 1.42.11 (09-Jul-2014) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 7, new_desc_blocks = 16 The filesystem on /dev/xvda1 is now 65535739 blocks long.

Vemos como la partición raíz ya ve el nuevo espacio en disco:

ip-10-250-4-103:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 18M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda1 246G 60G 177G 26% / tmpfs 799M 0 799M 0% /run/user/1000


XFS



Si ampliamos una partición no EXT4 usando el comando resize2fs veremos el siguiente error en pantalla:

ip-10-250-4-94:/home/ec2-user # sudo resize2fs /dev/xvda2 resize2fs 1.43.8 (1-Jan-2018) resize2fs: Bad magic number in super-block while trying to open /dev/xvda2 Couldn't find valid filesystem superblock.

Buscamos el tipo de partición del sistema operativo:

ip-10-250-4-94:/home/ec2-user # df -Th Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 3.9G 0 3.9G 0% /dev tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs tmpfs 3.9G 375M 3.6G 10% /run tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 xfs 100G 58G 42G 58% / /dev/xvda1 xfs 297M 90M 208M 31% /boot tmpfs tmpfs 797M 0 797M 0% /run/user/1000

Vemos que es XFS. Usamos xfs_growfs para ampliar nuestra partición raíz:

ip-10-250-4-94:/home/ec2-user # sudo xfs_growfs -d / meta-data=/dev/xvda2 isize=512 agcount=42, agsize=636096 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0 spinodes=0 rmapbt=0 = reflink=0 data = bsize=4096 blocks=26137339, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 26137339 to 65458939

Ahora ya vemos el nuevo espacio en la partición raíz:

ip-10-250-4-94:/home/ec2-user # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 375M 3.6G 10% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvda2 250G 58G 192G 24% / /dev/xvda1 297M 90M 208M 31% /boot tmpfs 797M 0 797M 0% /run/user/1000


Fuentes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
0

miércoles, 19 de agosto de 2020

Qué es un bind mount y cómo crearlo en Linux



¿Qué es un bind mount? ¿Qué diferencia hay entre un bind mount y un enlace simbólico?



Los montajes "bind" (bind mounts) de Linux permiten montar una ruta del sistema de archivos en otra ubicación, es decir, hacen que dos rutas vayan al mismo directorio. Se suelen usar para restringir el acceso de usuarios específicos a ciertas rutas de un servidor.

Por ejemplo, si queremos que un usuario sólo pueda acceder a una ruta específica vía SFTP y esta muestre archivos contenidos en otra parte del sistema, podemos usar un bind mount, lo cual le permitirá al usuario ver los archivos de esa ruta a la que no tendría acceso de otra forma.


Configurar bind mount



Para crear un bind mount, debemos usar la siguiente sintaxis:

HOST# mount --bind /ruta/original/ /nueva/ruta

Tambien podemos usar esta otra sintaxis:

HOST# mount -o bind /ruta/original/ /nueva/ruta

Una vez hecho esto, cada vez que nos dirijamos a /nueva/ruta, veremos los archivos situados en /ruta/original, como si hubieramos accedido a /ruta/original.


Montaje persistente



Cuando reiniciemos la máquina, los bind mount se perderán. Para hacerlos persistentes (perdurables después de reinicios), deberemos editar el archivo /etc/fstab del sistema y decirle a este que los monte:

/ruta/original /nueva/ruta none bind,nobootwait 0 0

Agregar nobootwait a la sección de opciones de la configuración de fstab garantiza que el sistema se inicie incluso si el directorio original se ha eliminado del sistema.


Diferencias entre bind mount y enlaces simbólicos



Un enlace simbólico es un inodo que apunta a un determinado objeto del sistema de archivos. Por otro lado, si se monta un directorio con un bind mount, se crea un segundo punto de montaje para un directorio ya existente dentro del sistema de archivos.

Si un enlace simbólico se podría ver como una redirección, un bind mount se podría ver como otra puerta de enlace a los datos de un directorio ya existente.

Varios programas pueden distinguir entre enlaces simbólicos y directorios o archivos reales. Pocos pueden distinguir entre un directorio o archivo y el que está montado en él (bind mount). Un software de backup, por ejemplo, creará dos copias de cada archivo ubicado en un directorio doblemente montado mediante bind mount, ya que tratará a ambos directorios como rutas independientes.

En un chroot, por su parte, si el objetivo del enlace está fuera del chroot, el enlace simbólico quedará muerto. El bind mount, en cambio, funcionará y permitirá que se acceda a los datos ubicados fuera del chroot. Además, los enlaces simbólicos sobreviven a un reinicio mientras que los mount bind no lo hacen a menos que se edite /etc/fstab para hacerlos persistentes.

Por último, los bind mount permiten un acceso más rápido a su destino que los enlaces simbólicos.


Fuentes:

https://support.rackspace.com/how-to/bind-mounts-in-linux/
https://serverfault.com/questions/613179/how-do-i-do-mount-bind-in-etc-fstab
https://unix.stackexchange.com/questions/53456/what-is-the-difference-between-nobootwait...
0