Categoria: Senza categoria

Postfix SMTP auth e riscrittura FROM:

Classico server debian o proxmox con installazione base. L’invio delle mail di sistema rimbalza tra il server smtp, la destinazione e chissà cos’altro.
Facciamo le cose per bene e utilizziamo un SMTP autenticato, con la riscrittura del FROM:, quando il nostro caro sistema sembra fare quello che vuole.

Per prima cosa installiamo le librerie necessarie:

apt-get install libsasl2-2 libsasl2-modules

Prepariamo il file /etc/postfix/sasl/password con i dati di autenticazione al nostro SMTP

nostro.smtp.server utente@nostro.smtp.server:_password_

Prepariamo il file /etc/postfix/header_check, che contiene il replace da eseguire nell’header delle mail in uscita

/From:.*/ REPLACE From: utente@nostro.smtp.server

e prepariamo anche il file /etc/postfix/generic, con gli altri eventuali mapping

root@server.local utente@nostro.smtp.server

Compiliamo i file appena creati/modificati

postmap /etc/postfix/sasl/password
postmap /etc/postfix/header_check
postmap /etc/postfix/generic

a questo punto modifichiamo /etc/postfix/main.cf

smtp_header_checks = regexp:/etc/postfix/header_check
smtp_generic_maps = hash:/etc/postfix/generic
relayhost = nostro.smtp.server:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/password
smtp_sasl_security_options =

mettiamoci in coda al giornale di sistema per vedere cosa abbiamo combinato

journalctl -f

e riavviamo il postfix con

/etc/init.d/postfix restart

adesso proviamo ad inviare una mail dalla shell e vediamo se tutto funziona

echo "Prova di invio mail" | mail -s "prova" destinazione@da.qualche.parte

Arrivata?

Unable to negotiate with x.x.x.x port 22: no matching host key type found

Nella connessione con un vecchio ESXi ricevo questo errore:

Unable to negotiate with ip.add.of.esxi port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Per permettere la connessione dobbiamo aggiungere un paio di parametri al comando:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa root@ip.address

ecco fatto

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

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

Windows Server 2022 su vmware ESXi e patch KB5022842

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

Proxmox e swapspace (su zfs)

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