miércoles, 28 de agosto de 2019

Ampliar espacio en disco en Windows Server 2003



Cómo ampliar (o extender) un volumen (o disco duro) en Windows Server 2003.



A estas alturas del siglo XXI, usar Windows Server 2003 debería estar prohibido, pero mientras haya aplicaciones legacy que solo funcionen en ese sistema y nuestro empleador no quiera ejecutarlas en contenedores o no nos atrevamos a hacerlo, no nos queda más remedio que conservar estas máquinas virtuales y realizarles el mantenimiento que requieran.

Windows Server 2003 no dispone de la utilidad de Disk Management de la que disponen versiones más actuales de Windows Server para administrar discos, así que si queremos extender el tamaño de un disco en este sistema, deberemos usar la utilidad diskpart incluida en Windows 2000 / 2003 / XP.

Para extender un disco , abrimos el símbolo del sistema e iniciamos diskpart.exe:

C:\Documents and Settings\Administrador>diskpart.exe Microsoft DiskPart version 5.2.3790.3959 Copyright (C) 1999-2001 Microsoft Corporation. En el equipo: SERVER5 DISKPART>

Escribir list volume para mostrar los volúmenes existentes:

DISKPART> list volume Volumen ### Ltr    Etiqueta     Fs     Tipo       Tamaño    Estado    Info ----------- ---   -----------  ----- ----------   ------- --------- --------   Vol. 0     D                        DVD-ROM        0 B   Correcto   Vol. 1     F    Nuevo vol2   NTFS   Partición    60 GB   Correcto   Vol. 2     C                 NTFS   Partición   150 GB   Correcto  Sistema   Vol. 3     J    Nuevo vol6   NTFS   Partición   120 GB   Correcto   Vol. 4     H    Nuevo vol4   NTFS   Partición    60 GB   Correcto   Vol. 5     K    Nuevo vol7   NTFS   Partición    80 GB   Correcto   Vol. 6     L    Nuevo vol8   NTFS   Partición    60 GB   Correcto  Archivo   Vol. 7     G    Nuevo vol3   NTFS   Partición    50 GB   Correcto   Vol. 8     I    Nuevo vol5   NTFS   Partición   120 GB   Correcto

Escribir select volume seguido del número de volumen a extender. Elegimos, por ejemplo, el vol. 8:

DISKPART> select volume 8 El volumen 8 es el volumen seleccionado.

Escribir extend seguido de los valores opcionales [size=n] [disk=n] [noerr].

A continuación, una descripción de los parámetros opcionales:

size=n
Espacio, en megabytes (MB), que se agrega a la partición actual. Si no especifica un tamaño, el disco se extiende para usar todo el espacio contiguo sin asignar.

disk=n
El disco dinámico en el que extender el volumen. Se asigna en el disco un espacio igual a size=n. Si no se especifica ningún disco, el volumen se extiende en el actual.

noerr
Sólo para secuencias de comandos. Cuando se produce un error, este parámetro especifica que Diskpart continúa procesando los comandos como si el error no hubiera ocurrido. Sin el parámetro noerr, un error hace que Diskpart se cierre con un código de error.

Si queremos extender el disco I (volumen 8) al completo, simplemente usaremos extend:

DISKPART> extend DiskPart ha extendido el volumen satisfactoriamente.

Una vez haya aparecido este mensaje en pantalla, el nuevo espacio ya está disponible en la unidad.


Fuentes:

https://support.microsoft.com/es-es/help/325590/how-to-extend-a-data-volume-in-windows-server...
0

miércoles, 21 de agosto de 2019

NFS: Stale file handle



Cómo solucionar el error "NFS: Stale file handle" en un sistema Linux con carpetas remotas.



Al conectarme a una máquina Linux y dirigirme a una carpeta montada por NFS, vi que dicha carpeta no era accesible. Lancé entonces un df y me encontré con el siguiente mensaje:

HOST # df -h df: ‘/usr/mount’: Stale file handle Filesystem                   Size   Used   Avail   Use%   Mounted on /dev/sda2                     95G    29G     62G    32%   / devtmpfs                     119G   8.0K    119G     1%   /dev tmpfs                        119G    80K    119G     1%   /dev/shm tmpfs                        119G   114M    119G     1%   /run tmpfs                        119G      0    119G     0%   /sys/fs/cgroup /dev/sda1                    148M      0    148M     0%   /boot/efi

Este problema se da cuando un sistema es apagado de forma brusca y no se desmontan correctamente los puntos de montaje del mismo, dando lugar a que la parte servidor crea que siguen montados.

Cuando la máquina cliente vuelve a estar operativa y trata de montar la carpeta compartida con ella, no puede montarla y muestra este error titulado "Stale file handle".

Para solucionar este problema, debemos conectarnos al sistema desde el que se exportan las carpetas (lado servidor) y re-exportar las carpetas compartidas.


Lado servidor



Primero, desmontamos los exports desde el lado servidor:

HOST # exportfs -ua

Luego, verificamos que no se está compartiendo ninguna carpeta:

HOST # cat /proc/fs/nfs/exports # Version 1.1 # Path Client(Flags) # IPs

Por último, re-exportamos todas las carpetas compartidas:

HOST # exportfs -a

Una vez hecho esto, el montaje de la carpeta ya debería ser posible en el sistema operativo cliente.


Lado cliente



Para montar las carpetas compartidas desde el lado cliente podemos hacerlo de forma individual o podemos desmontar y volver a montar todas las carpetas compartidas al mismo tiempo. Para desmontar/montar todas las carpetas al mismo tiempo, podemos usar la opción -a (all):

HOST # umount -fa

HOST # mount -a

Una vez hecho esto, ya deberíamos ver correctamente el punto de montaje al lanzar el comando df:

HOST # df -h Filesystem                   Size   Used   Avail   Use%   Mounted on /dev/sda2                     95G    29G     62G    32%   / devtmpfs                     119G   8.0K    119G     1%   /dev tmpfs                        119G    80K    119G     1%   /dev/shm tmpfs                        119G   114M    119G     1%   /run tmpfs                        119G      0    119G     0%   /sys/fs/cgroup /dev/sda1                    148M      0    148M     0%   /boot/efi srv1.dominio.com:/usr/mount   10G     5G      5G    50%   /usr/mount


Fuentes:

https://unix.stackexchange.com/a/447581
0

miércoles, 14 de agosto de 2019

ping / traceroute en un switch eligiendo IP origen



Cómo hacer un ping o un traceroute desde un switch Aruba eligiendo la IP de origen desde donde se inicia la conexión, para hacer pruebas de conectividad entre VLANs.



Si tenemos una red segmentada, es decir, una red donde diferentes dispositivos están ubicados en distintos rangos IP o VLANs, nos puede interesar probar si un dispositivo ubicado en un rango determinado tiene conectividad con otro dispositivo situado en otro rango, o si por el contrario, el dispositivo que estamos instalando no puede conectar con el otro extremo.

Imaginemos un switch con 3 VLANS, configurado de la siguiente manera:

Startup configuration: 3 ; J9729A Configuration Editor; Created on release #WB.15.12.0015 ; Ver #05:18.41.ff.35.0d:9b hostname "SWITCH-3" module 1 type j9729a ip default-gateway 192.168.101.10 snmp-server community "public" unrestricted vlan 1 name "DEFAULT_VLAN" untagged 1-48 ip address 192.168.101.11 255.255.255.0 exit vlan 2 name "VLAN2" untagged 1-48 ip address 192.168.102.11 255.255.255.0 exit vlan 3 name "VLAN3" tagged 1-48 ip address 192.168.103.11 255.255.255.0 qos priority 6 voice exit spanning-tree no tftp server no autorun no dhcp config-file-update no dhcp image-file-update

Como la VLAN 1 o DEFAULT_VLAN tiene la IP 192.168.101.11 asignada, si hacemos un ping desde el switch a una IP, por ejemplo ping 192.168.1.1, el ping siempre se realizará desde la IP origen 192.168.101.11, es decir, la IP de la VLAN por defecto.

Para comprobar si un dispositivo ubicado en la VLAN 2 o la VLAN 3 tiene conectividad con el dispositivo con IP 192.168.1.1, podemos modificar el origen de las peticiones de ping o traceroute.

La sintaxis en estos casos es:

comando <ip_destino> source <ip_origen>

Por ejemplo, para realizar un ping a 192.168.1.1 desde la VLAN 2:

# ping 192.168.1.1 source 192.168.102.1

O también:

# ping 192.168.1.1 source 2

Para realizar un traceroute, sería la misma sintaxis:

# traceroute 192.168.1.1 source 192.168.102.1

O el número de VLAN:

# traceroute 192.168.1.1 source 2

A partir de aquí, si desde la VLAN 1 hay conectividad, pero desde las otras VLAN no, ya podemos ir haciendo los cambios de routing pertinentes en los dispositivos intermedios de la red (firewalls, routers, switches, etc.) para establecer conectividad entre ambos lados.

Fuentes:

https://community.hpe.com/t5/LAN-Routing/source-ping-from-HP-devices/td-p/5348859#.XVFCtHtS-Uk
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c02920971
0

miércoles, 7 de agosto de 2019

Cómo activar / desactivar módulos en un SLES



Cómo registrar un módulo vía línea de comandos en SUSE Linux Enterpirse Server 15.



Al tratar de instalar un Service Pack en un SUSE Linux Enterprise Server me encontré con este error:

HOST# zypper migration ... Can't get available migrations from server: SUSE::Connect::ApiError: The requested products 'Desktop Applications Module 15 x86_64, Development Tools Module 15 x86_64, Legacy Module 15 x86_64, Public Cloud Module 15 x86_64, Web and Scripting Module 15 x86_64' are not activated on the system. '/usr/lib/zypper/commands/zypper-migration' exited with status 1

Para poder continuar con la instalación, tenía que activar manualmente cada uno de los módulos.

Para ver cómo activarlos, lo mejor es listar primero los módulos instalados en el sistema:

HOST# SUSEConnect --list-extensions AVAILABLE EXTENSIONS AND MODULES Basesystem Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-basesystem/15/x86_64 Containers Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-containers/15/x86_64 Desktop Applications Module 15 x86_64 Activate with: SUSEConnect -p sle-module-desktop-applications/15/x86_64 Development Tools Module 15 x86_64 Activate with: SUSEConnect -p sle-module-development-tools/15/x86_64 SUSE Cloud Application Platform Tools Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-cap-tools/15/x86_64 SUSE Package Hub 15 x86_64 Activate with: SUSEConnect -p PackageHub/15/x86_64 Server Applications Module 15 x86_64 (Activated) Deactivate with: SUSEConnect -d -p sle-module-server-applications/15/x86_64 Legacy Module 15 x86_64 Activate with: SUSEConnect -p sle-module-legacy/15/x86_64 Public Cloud Module 15 x86_64 Activate with: SUSEConnect -p sle-module-public-cloud/15/x86_64 SUSE Linux Enterprise High Availability Extension 15 x86_64 Activate with: SUSEConnect -p sle-ha/15/x86_64 Web and Scripting Module 15 x86_64 Activate with: SUSEConnect -p sle-module-web-scripting/15/x86_64 REMARKS (Not available) The module/extension is not enabled on your RMT/SMT (Activated)     The module/extension is activated on your system MORE INFORMATION You can find more information about available modules here: https://www.suse.com/products/server/features/modules.html

Llegados a este punto, sólo quedaba ir activando los diferentes módulos no activados con el comando proporcionado en la lista anterior, valiéndome de la utilidad propietaria de SUSE SUSEConnect:

HOST# SUSEConnect -p sle-module-web-scripting/15/x86_64 Registering system to registration proxy https://smt-ec2.susecloud.net Updating system details on https://smt-ec2.susecloud.net ... Activating sle-module-web-scripting 15 x86_64 ... -> Adding service to system ... -> Installing release package ... Successfully registered system

Una vez activados todos los módulos, ya pude efectuar la instalación del Service Pack sin problemas.

Si lo que queremos es desactivar un módulo, debemos seguir las instruciones proporcionadas en la lista de extensiones, y usar la opción -d junto al nombre de módulo, tal y como se indica.


Fuentes:

https://www.suse.com/support/kb/doc/?id=7018790
https://www.suse.com/products/server/features/modules.html
0