La storia

alessandro

Howto

Disco iSCSI visibile tra i dispositivi ma non tra i datastore

Nov 11, 2023 by alessandro 0 Commenti , , ,

Problema tra sistemi. Ho uno storage con TrueNAS che esporta verso un cluster due dischi iSCSI e una cartella NFS, utilizzati come datastore per le VM.

A causa di un problema con il disco di avvio dello storage ho dovuto reinstallare da zero TrueNAS, versione SCALE 23.10.0.1.

Nessun problema con la reimportazione dei volumi su TrueNAS, pochi aggiustamenti sui permessi e tutto pare tornato a posto.

I dischi iSCSI esportati verso il cluster, però, non sono visibili. Sono visibili i dispositivi fisici ma i datastore non vengono montati da nessun nodo.

In questo caso i dispositivi vengono erroneamente interpretati come snapshot. Possiamo montarli come datastore con il comando “esxcfg-volume -M xxxx“
Verifichiamo con “esxcli storage vmfs snapshot list“:

[root@alfa:~] esxcli storage vmfs snapshot list
63d4ea88-32fcf386-7e0e-yyyyyyyyyyyy
   Volume Name: iRaid
   VMFS UUID: 63d4ea88-32fcf386-7e0e-yyyyyyyyyyyy
   Can mount: true
   Reason for un-mountability: 
   Can resignature: true
   Reason for non-resignaturability: 
   Unresolved Extent Count: 1

63d7dc50-2758fd2c-fca2-xxxxxxxxxxxx
   Volume Name: iSSD
   VMFS UUID: 63d7dc50-2758fd2c-fca2-xxxxxxxxxxxx
   Can mount: true
   Reason for un-mountability: 
   Can resignature: true
   Reason for non-resignaturability: 
   Unresolved Extent Count: 1

In effetti i due dischi vengono visti come snapshot. Forziamo il mount dei datastore:

root@alfa:~] esxcfg-volume -M "63d4ea88-32fcf386-7e0e-yyyyyyyyyyyy"
Persistently mounting volume 63d4ea88-32fcf386-7e0e-yyyyyyyyyyyy

e

[root@alfa:~] esxcfg-volume -M "63d7dc50-2758fd2c-fca2-xxxxxxxxxxxx"
Persistently mounting volume 63d7dc50-2758fd2c-fca2-xxxxxxxxxxxx

Adesso è ok

Howto

Port forwarding su Fortinet firewall

Nov 3, 2023 by alessandro 0 Commenti ,

Piccola ricetta per effettuare un port forward su router Fortinet

Per inoltrare il traffico TCP o UDP ricevuto dall’interfaccia esterna di un FortiGate verso un server interno dobbiamo seguire questi due passi:

  • Aggiungere un Virtual IP
  • Aggiungere una regola sul firewall

In questo esempio configuriamo l’inoltro di una porta

This example describes how to configure port forwarding to allow access to an internal Windows Server PC with the Remote access protocol which uses the default port of 3389.

To add a virtual IP that forwards RDP packets

1) For FortiOS 6.0.x,6.2.x,7.0.x,7.2.x, Navigate to Policy & Objects > Virtual IPs.
1.1) Select Create New.
1.2) Add a name for the virtual IP.
1.3) Select the External Interface. This will typically be the interface that connects the FortiGate to the Internet.
1.4) Set the External IP Address/Range. The following can be used:

  • The FortiGate unit public IP.
  • If there is a cable or DSL connection with a dynamic IP, it is possible to use 0.0.0.0.
  • If the ISP provides a block of IPs that route to the FortiGate external interface, it is possible to add one of these IPs here.
    4) Set the Mapped IP Address to the internal IP address of the Windows Server PC.
    5) Select Port Forwarding.
    6) Set protocol to TCP.
    7) Set External Service Port and Map to Port. For this example, the RDP service uses port 3389. Set both External service port and Map to Port to 3389.
    8) Select OK.

Now all that’s left is to define a firewall policy that accepts RDP traffic from the Internet and forwards it to the internal Windows Server PC.

To add a firewall policy with a virtual IP.

1)In 6.0, Go to Policy & Objects -> IPv4 Policy.
In 6.4.x,7.0.x,7.2.x, Navigate to Policy & Objects => Firewall Policy.
2) Select Create New.
3) Set Source Interface to the WAN/Internet interface.
4) Set Source Addresses to all.
5) Set Destination Interface to internal.
6) Set the Destination Address to the name of the virtual IP.
7) Usually, the remainder of the options in this firewall policy does not need to be changed. For example, the Service can remain ANY, because the virtual IP only forwards packets using port 3389.
8) Select OK.

Senza categoria

Installazione di Windows 11 ARM su vmWare Fusion (Mac M1)

Giu 10, 2023 by alessandro 0 Commenti

L’installazione di Windows 11 ARM su vmWare Fusion su Mac M1 (e seguenti) si blocca, dopo la scelta della tastiera, per mancanza di rete.

Per ovviare a questo problema dobbiamo eseguire una semplice procedura per installare i tools che permettono alla macchina virtuale di accedere alla rete e terminare l’installazione

Arrivati alla prima schermata:

Premiamo i tasti Shift-fn-F10 per aprire un prompt dei comandi
Dal prompt dei comandi digitiamo:

powershell

e da qui eseguiamo:

D:
Set-ExecutionPolicy RemoteSigned
.\setup.ps1

Al termine riavviamo la macchina che, al seguente avvio, potrà effettuare l’installazione regolarmente:

shutdown /r /t 0

Fatto 🙂

Qui i riferimenti

Senza categoria

Windows Server 2022 su vmware ESXi e patch KB5022842

Feb 21, 2023 by alessandro 0 Commenti , ,

L’installazione di un aggiornamento cumulativo (2023-02 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems (KB5022842)) impedisce il corretto avvio della VM:

Riavvio dopo l’installazione della KB5022842

Al momento non ci sono soluzioni ne da parte di vmware ne da parte di Microsoft.

I consigli sono essenzialmente due: non installare la patch oppure disabilitare l’avvio sicuro.

Per disabilitare l’avvio sicuro dobbiamo andare sulle impostazioni della macchina virtuale:

Accedere alla tab “Opzioni della macchina virtuale”:

e disabilitare l’opzione “Avvio sicuro” nelle opzioni di avvio

Senza categoria

Proxmox e swapspace (su zfs)

Feb 14, 2023 by alessandro 0 Commenti

Il corretto dimensionamento di un server che ospita Proxmox non dovrebbe coinvolgere l’utilizzo dello spazio di swap.
Capita però che sia necessario aggiungere dello spazio di swap quando la memoria non è sufficiente e dobbiamo tamponare la situazione, in attesa di espandere la memoria principale.
Capita infatti che l’OOM uccida un processo (e se vi siete posti il problema probabilmente era una VM in funzione) prima di rendere il sistema instabile.

In questo caso possiamo aggiungere uno spazio di swap per limitare il problema.

E’ buona norma dedicare una partizione allo swap e non impasticciare su filesystem esistenti ma a volte si procede per emergenze.

In questo caso creiamo uno spazio di swap da 24GB come ZVOL:

# zfs create rpool/swapspace -V 24G

verifichiamo con:

# zpool status

e:

# zfs list
# mkswap /dev/rpool/swapspace 
# swapon /dev/rpool/swapspace
# free

Per evitare che lo spazio di swap venga utilizzato senza una vera e stringente necessità possiamo impostare il parametro “swappiness”:

# sysctl -w vm.swappiness=10

E per renderlo effettivo al riavvio aggiungiamo una linea al file “/etc/sysctl.conf”

vm.swappiness = 10

Per aggiungere lo spazio di swap al file “/etc/fstab” aggiungiamo la seguente riga:

/dev/rpool/swapspace none swap defaults 0 0

fatto

Howto

vCenter Single Sign-On – no healthy upstream

Nov 2, 2022 by alessandro 0 Commenti ,

Tra le migliaia di cause per questo dannato errore di “no healthy upstream” c’è anche la possibilità che i certificati interni siano scaduti.

Ci troviamo con una pagina bianca (o scura, a seconda del tema…) e la sola dicitura “no healthy upstream”:

Tra le possibili soluzioni, prima di tentare una reinstallazione completa del vCenter, verifichiamo che i certificati siano ok. Da una sessione SSH proviamo a fare un controllo

root@vcenter [ /etc/vmware/vsphere-ui ]# for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo "[*] Store :" $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $store --text | grep -ie "Alias" -ie "Not After";done;

Otteniamo un elenco dei certificati e delle scadenze

[*] Store : MACHINE_SSL_CERT
Alias :	__MACHINE_CERT
            Not After : Nov  1 10:26:08 2022 GMT
[*] Store : TRUSTED_ROOTS
Alias :	b88fd8df2674612aaadccbac0140ace59464a9d0
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : machine
Alias :	machine
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : vsphere-webclient
Alias :	vsphere-webclient
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : vpxd
Alias :	vpxd
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : vpxd-extension
Alias :	vpxd-extension
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : hvc
Alias :	hvc
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : data-encipherment
Alias :	data-encipherment
            Not After : Oct 26 22:26:08 2030 GMT
[*] Store : APPLMGMT_PASSWORD
[*] Store : SMS
Alias :	sms_self_signed
            Not After : Oct 31 22:31:21 2030 GMT
[*] Store : wcp
Alias :	wcp
            Not After : Oct 31 22:23:31 2022 GMT

Ci sono un paio di certificati scaduti, dannato mondo. Andiamo nella cartella /usr/lib/vmware-vmca/bin e eseguiamo il certificate-manager

root@vcenter [ /usr/lib/vmware-vmca/bin ]# ./certificate-manager
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
|                                                                     |
|      *** Welcome to the vSphere 6.8 Certificate Manager  ***        |
|                                                                     |
|                   -- Select Operation --                            |
|                                                                     |
|      1. Replace Machine SSL certificate with Custom Certificate     |
|                                                                     |
|      2. Replace VMCA Root certificate with Custom Signing           |
|         Certificate and replace all Certificates                    |
|                                                                     |
|      3. Replace Machine SSL certificate with VMCA Certificate       |
|                                                                     |
|      4. Regenerate a new VMCA Root Certificate and                  |
|         replace all certificates                                    |
|                                                                     |
|      5. Replace Solution user certificates with                     |
|         Custom Certificate                                          |
|         NOTE: Solution user certs will be deprecated in a future    |
|         release of vCenter. Refer to release notes for more details.|
|                                                                     |
|      6. Replace Solution user certificates with VMCA certificates   |
|                                                                     |
|      7. Revert last performed operation by re-publishing old        |
|         certificates                                                |
|                                                                     |
|      8. Reset all Certificates                                      |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
Note : Use Ctrl-D to exit.
Option[1 to 8]: 8

Resettiamo tutto con l’opzione “8”, se serve possiamo:

# service-control --stop vsphere-ui
# service-control --start vsphere-ui

Dovrebbe essere tutto ok 🙂

Howto

Copiare la propria chiave pubblica ssh su un server senza ssh-copy-id

Set 3, 2022 by alessandro 0 Commenti , ,

Linux ha il comando ssh-copy-id che permette la copia della propia chiave pubblica ssh su un altro server, ma non tutte le varianti *nix hanno tale programma. Per copiare la propria chiave pubblica ssh su un server, da una macchina che non ha ssh-copy-id, ad esempio Mac OSX, di può ricorrere al seguente comando da lanciare nel terminale di OSX:

cat ~/.ssh/id_rsa.pub | ssh utente@dominio.estensione "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

dove utente@dominio.estensione rappresenta l’utente ed il server su cui attivare l’accesso senza dover inserire la password ogni volta.
Per consentire l’accesso SSH all’utente root solo con il certificato (bloccando la connessione con password), bisogna modificare il file /etc/ssh/sshd_config ed in particolare impostare la direttiva:

PermitRootLogin without-password

riavviare poi il servizio con il classico:

/etc/init.d/ssh restart
Howto

TrueNAS connessione a disco iSCSI

Lug 27, 2022 by alessandro 0 Commenti ,

Ho un box TrueNAS con 4 dischi da 3TB in RaidZ ma si sa, lo spazio non è mai abbastanza. Non potendo aggiungere altri dischi all’interno dello stesso server ho allestito un secondo box, con altrettanti dischi da 3TB ed esportato un disco iSCSI che ho montato (via rete) sul primo server.

Vediamo come.

Per prima cosa creiamo un volume all’interno di un pool, in questo caso “targetDisk”.

Adesso dobbiamo condividere il volume attraverso l’iSCSI, quindi partiamo da “Sharing” -> “Block Shares (iSCSI)“
Possiamo utilizzare il wizard, che ci aiuta a creare portale, iniziatore, target e extent:

La configurazione globale, da cui prendiamo il “Base Name“: “iqn.2005-10.org.freenas.ctl” (1)
Il portale con Group ID 1 e l’interfaccia (ip) su cui ascolta
Il gruppo di iniziatori, con le reti autorizzate a connettersi
Il Target, con il nome “targetDisk” che ci servirà tra poco
L’extent con il nome “targetdisk” (occhio che qui è tutto minuscolo)
Ed infine il target associato con nome “targetdisk” (2)

A questo punto è tutto ok, ricordiamoci di avviare la condivisione iSCSI dal pannello dei servizi.

Ci spostiamo sul nodo TrueNAS che deve importare il disco che abbiamo esportato sopra e ci connettiamo in SSH (oppure avviamo la Shell dal pannello web).
Dobbiamo creare (o modificare) il file /conf/base/etc/iscsi.conf così:

t0 {
  TargetAddress = 10.20.30.251
  TargetName = iqn.2005-10.org.freenas.ctl:targetdisk
}

In questo caso il TargetAddress è l’indirizzo del nodo che espone il disco iSCSI e il nome è composto dal BaseName del punto 1 e dal nome targetdisk, quello del target associato del punto 2, divisi da “:”
Dobbiamo anche modificare il file “/conf/base/etc/rc.conf” aggiungendo queste righe al termine del file:

iscsid_enable="YES"
iscsictl_enable="YES"
iscsictl_flags="-Aa"

Una ultima modifica al file “/conf/base/etc/ix.rc.d/ix-zfs” dove dobbiamo modificare la linea:

# REQUIRE: hostid mountcritlocal

con:

# REQUIRE: hostid mountcritlocal iscsictl

A questo punto possiamo riavviare il nodo e dovremmo trovare un nuovo disco “da0” tipo questo:

Possiamo aggiungere quindi un nuovo pool (Storage -> Pools) indicando il disco “da0” come unico membro del nuovo pool di nome “targetDisk“. La dashboard, adesso, ci permette di vedere entrambi i volumi:

Abbiamo un po’ più spazio.