NetFilter – IPTABLES

situazione di partenza: tutte le policy sono ACCEPT.

inserisco le le regole manualmente, verifico con iptables -vnL, poi le salvo in un file con il comando iptables-save:

# inserisco le policy di base: tutto chiuso
iptables -P INPUT DROP
iptables -P FORWARD DROP
# lasciamo libero il traffico di loopback
iptables -A INPUT -i lo -j ACCEPT
# consento il traffico richiesto da noi:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -vnL
iptables-save > iptables.rules.up

ora le connessioni dall’esterno sono chiuse: bisogna aprire le porte dei servizi che ci interessano.

per vedere quali porte sono in ascolto, oltre a netstat è possibile usare lsof:

lsof -i

in output abbiamo le porte in ascolto in formato testuale: i corrispondenti valori numerici si trovano in /etc/services.

ad esempio, trovo che smbd ascolta su TCP *:microsoft-ds (Microsoft Naked CIFS) e TCP *:netbios-ssn (NETBIOS session service): sono le porte 139 e 445

invece nmbd ascolta su netbios-ns (NETBIOS Name Service) e netbios-dgm (NETBIOS Datagram Service), porte 137 e 138

  • UDP *:netbios-ns
  • UDP *:netbios-dgm
  • UDP nomehost.nomedominio:netbios-ns
  • UDP nomehost.nomedominio:netbios-dgm
  • UDP 192.168.1.255:netbios-ns
  • UDP 192.168.1.255:netbios-dgm

dunque devo solo aprire le porte 139 e 445 TCP e 137-138 UDP , limitando il traffico alla sola rete locale:

iptables -A INPUT -p tcp --dport 139 -m state --state NEW -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 445 -m state --state NEW -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 137 -m state --state NEW -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 138 -m state --state NEW -s 192.168.1.0/24 -j ACCEPT

per fare pulizia:

iptables -F #Cancellazione delle regole presenti nelle chains
iptables -X #Eliminazione delle chains non standard vuote
iptables -Z #Inizializzazione dei contatori (utile per il debugging)

per ripristinare le regole precedentemente salvate:

iptables-restore < iptables.up.rules

il file iptables.up.rules è simile a:

# Generated by iptables-save v1.6.2 on Xxx Xxx xx xx:xx:xx 2018
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 139 -m state --state NEW -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 445 -m state --state NEW -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 137 -m state --state NEW -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 138 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -m state --state NEW -j ACCEPT
COMMIT
# Completed on Xxx Xxx xx xx:xx:xx 2018

per gestire le regole:

# numerare le regole:
iptables -L INPUT --line-numbers
# cancellare una regola per numero, ad es. il 10:
iptables -D INPUT 10
# inserire una regola tra le esistenti 9 e 10:
# la 10ma diventa così 11esima
iptables -I INPUT 10 -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT

per caricare e rimuovere le regole di iptables quando si avvia o si disconnette una connessione di rete, ci sono gli script pre-up e pre-down di /etc/network/interfaces.

se le connessioni sono gestite da NetworkManager, vengono eseguiti gli script contenuti in /etc/networkManager/dispatcher.d , in particolare quelli contenuti nelle directories pre-up.d e pre-down.d: creo uno script iptables in ognuna di esse, e nel primo scrivo

#!/bin/sh
iptables-restore < /etc/iptables.up.rules

analogamente per il secondo, scrivo iptables.down.rules.
dò i permessi 0700 agli script e 0600 ai file delle regole.

NetworkManager può essere gestito da shell con nmcli:
soppando e riavviando la connessione possiamo testare gli script pre-up e pre-down delle regole iptables.

# senza argomenti fornisce una panoramica:
nmcli
# per vedere i dettagli delle connessioni
nmcli -p con show
nmcli con show
# per avviare|stoppare una connessione per nome
nmcli con up|down "Wired connection 1"

riferimenti

Annunci
Pubblicato in Debian | Contrassegnato , , , | Lascia un commento

Debian StrongSwan e MiniSSDPd

Appunti di configurazione:

MiniSSDPd

Il file /var/log/daemon.log era pieno di avvisi del tipo

minissdpd[30585]: peer 192.168.1.200:32500 is not from a LAN

Per correggerlo bisogna modificare il file /etc/default/minissdpd specificando l’interfaccia su cui ascoltare:

MiniSSDPd_INTERFACE_ADDRESS=enp2s0 # non 0.0.0.0

StrongSwan

https://www.strongswan.org/

Host Debian Buster (testing).
Configurazione di un “roadwarrior” Android 7 con client StrongSwan scaricabile da Play Store, con doppia autenticazione Certificato + EAP.

Oltre ad installare il pacchetto StrongSwan con le sue dipendenze, ho dovuto installare manualmente altri due pacchetti:

  1. strongswan-pki : necessario per creare e gestire i certificati da linea di comando ipsec
  2. libcharon-extra-plugins : necessario per usare l’autenticazione EAP-MSCHAPv2

Configurazione di /etc/ipsec.conf

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
# strictcrlpolicy=yes
# uniqueids = no
conn
# Add connections here.

# Sample VPN connections

#conn sample-self-signed
#             leftsubnet=10.1.0.0/16
#             leftcert=selfCert.der
#             leftsendcert=never
#             right=192.168.0.2
#             rightsubnet=10.2.0.0/16
#             rightcert=peerCert.der
#             auto=start

#conn sample-with-ca-cert
#             leftsubnet=10.1.0.0/16
#             leftcert=myCert.pem
#             right=192.168.0.2
#             rightsubnet=10.2.0.0/16
#             rightid="C=CH, O=Linux strongSwan CN=peer name"
#             auto=start

conn roadwarrior
keyexchange=ikev2
auto=add

# Server Side
left=%any
leftauth=pubkey
leftcert=serverCert.pem
leftid=host.domain.xyz
leftsubnet=0.0.0.0/0

# Client side
right=%any
# rightsourceip=192.168.2.0/24
rightsourceip=%dhcp
rightauth=pubkey
rightauth2=eap-mschapv2
rightcert=clientCert.pem
rightdns=208.67.222.222,208.67.220.220

include /var/lib/strongswan/ipsec.conf.inc

Configurazione di /etc/ipsec.secrets

: RSA serverKey.pem
nomeutente : EAP "password"

I certificati sono stati creati con lo script:
(ATTENZIONE: verificare se i parametri –san possono essere impostati diversamente)
Copiare sul client sia il clientCert.p12 che il caCert.pem

#!/bin/sh
ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "C=IT, O=xyz.ddns.net, CN=Nome Autorità" --ca --outform pem > caCert.pem
ipsec pki --gen --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=IT, O=xyz.ddns.net, CN=xyz.ddns.net" --san="xyz.ddns.net" --flag serverAuth --flag ikeIntermediate --outform pem > serverCert.pem
ipsec pki --gen --outform pem > clientKey.pem
ipsec pki --pub --in clientKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=IT, O=xyz.ddns.net, CN=Nome Client" --san="client" --outform pem > clientCert.pem
openssl pkcs12 -export -inkey clientKey.pem -in clientCert.pem -name "client" -certfile caCert.pem -caname "xxxx" -out clientCert.p12

# where to put them...
mv caCert.pem /etc/ipsec.d/cacerts/
mv serverCert.pem /etc/ipsec.d/certs/
mv serverKey.pem /etc/ipsec.d/private/
mv clientCert.pem /etc/ipsec.d/certs/
mv clientKey.pem /etc/ipsec.d/private/
mv caKey.pem /etc/ipsec.d/private/

Sul firewall, ho impostato il forwarding delle porte UDP 500 e 4500.

Per riavviare il server VPN, il tunnel IPSec, o per ricaricare le credenziali:

systemctl restart|status|stop|start strongswan
ipsec reload
ipsec rereadsecrets

Configurazione del FORWARDING per il traffico verso il roadwarrior

situazione di partenza:

  • Tutte le CHAIN di IPTABLES sono ACCEPT
  • /proc/sys/net/ipv4/ip_forward è 0 (disabilitato)

situazione da raggiungere:

  • bloccare FORWARD di IPTABLES
  • abilitare /proc/sys/net/ipv4/ip_forward (impostare a 1)
  • aggiungere delle regole IPTABLES che consentono il FORWARD ai roadwarrior
  • manca il FORWARD per loopback !!!

Invece di modificare le interfacce di rete, scrivere script di iptables ecc…, la cosa più semplice è configurare strongswan a lanciare uno script updown usando il parametro leftupdown=<path dello script>.

nella sezione conn:

leftupdown="/etc/ipsecupdown.sh"

Lo script di default /usr/lib/ipsec/_updown ha già delle funzioni che funzionano perfettamente: lo prendo come modello e lo copio in /etc/ipsecupdown.sh, chmod 700.

Le sezioni dello script che ci interessano sono up-client e down-client, che vengono chiamate quando viene attivata/disattivata la subnet del roadwarrior. Le analoghe sezioni con il parametro :iptables non vengono eseguite !! solo nello script di default.

Perciò copio da up-client:iptables e down-client:iptables l’intero blocco di istruzioni e lo metto in up-client e down-client.

Quindi, per ripristinare la situazione iniziale, aggiungo all’inizio di up-client le seguenti: (verificare comando logger dello script!!!)

echo "$0: roadwarrior subnet coming up" >> /var/log/iptables.log
iptables -P FORWARD DROP
echo 1 > /proc/sys/net/ipv4/ip_forward

alla fine di down-client le seguenti:

echo "$0: roadwarrior subnet going down" >> /var/log/iptables.log
echo 0 > /proc/sys/net/ipv4/ip_forward
iptables -P FORWARD ACCEPT

[VECCHIO] ho risolto così:

  1. ho creato lo script iptables modificato in /etc/NetworkManager/dispatcher.d/pre-up.d/
    #!/bin/sh
    
    LOGFILE=/var/log/iptables.log
    
    if [ "$1" = lo ]; then
        echo "$0: ignoring $1 for \`$2'" >> $LOGFILE
        exit 0
    fi
    
    case "$2" in
        pre-up)
            echo "$0: restoring iptables rules for $1" >> $LOGFILE
            /sbin/iptables-restore /etc/iptables.up.rules >> $LOGFILE 2>&1 && {
                    echo "$0: abilito ip_forward" >> $LOGFILE
                    echo 1 > /proc/sys/net/ipv4/ip_forward
            }
            #/sbin/ip6tables-restore /etc/network/ip6tables.up.rules >> $LOGFILE 2>&1
            ;;
        *)
            echo "$0: nothing to do with $1 for \`$2'" >> $LOGFILE
            ;;
    esac
    
    exit 0
    
  2. il file /etc/iptables.up.rules contiene la policy di DROP per il FORWARD, ovviamente può (e deve) essere rifinito meglio:
    *filter
    :INPUT ACCEPT
    :FORWARD DROP
    :OUTPUT ACCEPT
    COMMIT
    
  3. ho aggiunto a /etc/ipsec.conf l’opzione leftfirewall=yes che gestisce dinamicamente le regole di iptables per le connessioni IPSEC

RIFERIMENTI:

  1. abilitare ipv4 forwarding:
    echo 1 > /proc/sys/net/ipv4/ip_forward
    # per renderlo persistente:
    nano /etc/sysctl.conf
    net.ipv4.ip_forward = 1
  2. impostare le regole iptables:
    iptables -I INPUT -m policy –dir in –pol ipsec –proto esp -j ACCEPT
    iptables -I FORWARD -m policy –dir in –pol ipsec –proto esp -j ACCEPT
    iptables -I FORWARD -m policy –dir out –pol ipsec –proto esp -j ACCEPT
    iptables -I OUTPUT -m policy –dir out –pol ipsec –proto esp -j ACCEPT
  3. vedere https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
  4. vedere https://feeding.cloud.geek.nz/posts/using-iptables-with-network-manager/ :
    creare uno script in /etc/NetworkManager/dispatcher.d/pre-up.d/ con nome ad es. iptables,  renderlo eseguibile, ed inserire

    #!/bin/sh
    
    LOGFILE=/var/log/iptables.log
    
    if [ "$1" = lo ]; then
        echo "$0: ignoring $1 for \`$2'" >> $LOGFILE
        exit 0
    fi
    
    case "$2" in
        pre-up)
            echo "$0: restoring iptables rules for $1" >> $LOGFILE
            /sbin/iptables-restore /etc/network/iptables.up.rules >> $LOGFILE 2>&1
            /sbin/ip6tables-restore /etc/network/ip6tables.up.rules >> $LOGFILE 2>&1
            ;;
        *)
            echo "$0: nothing to do with $1 for \`$2'" >> $LOGFILE
            ;;
    esac
    
    exit 0
    

riferimenti:

  1. https://wiki.archlinux.org/index.php/StrongSwan
  2. https://wiki.openwrt.org/doc/howto/vpn.ipsec.roadwarrior
Pubblicato in Debian | Contrassegnato , , , , , | Lascia un commento

Cosa sono il Nazional-Socialismo e il Fascismo

Se qualcuno si fosse preso la briga di leggere il VERO Mein Kampf, edito soltanto a partire dal 2016, perchè fino ad allora i diritti d’autore erano detenuti dal Land di Baviera che ne aveva vietata la diffusione a causa del suo “alto potenziale evocativo”, capirebbe senza il minimo indugio che il Nazional-Socialismo e il suo omologo Fascismo si possono descrivere con questa splendida definizione data dal musicologo Luigi Magnani a riguardo dell’ideale Romantico:

« Il nuovo regno, vagheggiato dai romantici come una nuova età dell’oro, se significava affermazione della libertà e della fraternità umana, esaltazione di tutti i valori dello spirito, appariva nondimeno quale ritorno agli ideali della Grecia antica […] Il diffuso umanesimo, mirante alla riconquista della integrità dell’uomo, poneva i poeti, i filosofi e i tragici greci quali modelli supremi e auspicava l’avvento dello «stato di natura», non inteso come primitiva selvaggia barbarie, ma come mitica “Arcadia” in cui la natura divinizzata si identificava con l’Ideale («Ideale è ciò che è Natura» diceva Hölderlin) ed in cui l’uomo, in accordo pieno con la società, avrebbe potuto attuare quella armonia degli spiriti che, per il poeta di Hyperion, avrebbe segnato l’inizio “di una nuova storia del mondo”, di un rinnovamento della umanità. »

Lo stesso spirito si trova ovviamente nella Nona Sinfonia di Beethoven:

« O amici, non questi suoni!
ma intoniamone altri
più piacevoli, e più gioiosi.

Gioia, bella scintilla divina,
figlia dell’Elisio,
noi entriamo ebbri e frementi,
celeste, nel tuo tempio.
Il tuo fascino riunisce
ciò che la moda separò
ogni uomo s’affratella
dove la tua ala soave freme.

L’uomo a cui la sorte benevola,
concesse il dono di un amico,
chi ha ottenuto una donna devota,
unisca il suo giubilo al nostro!
Sì, chi anche una sola anima
possa dir sua nel mondo!
Chi invece non c’è riuscito,
lasci piangente e furtivo questa compagnia!

Gioia bevono tutti i viventi
dai seni della natura;
vanno i buoni e i malvagi
sul sentiero suo di rose!
Baci ci ha dato e uva,
un amico, provato fino alla morte!
La voluttà fu concessa al verme,
e il cherubino sta davanti a Dio!

Lieti, come i suoi astri volano
attraverso la volta splendida del cielo,
percorrete, fratelli, la vostra strada,
gioiosi, come un eroe verso la vittoria.

Abbracciatevi, moltitudini!
Questo bacio vada al mondo intero!
Fratelli, sopra il cielo stellato
deve abitare un padre affettuoso.
Vi inginocchiate, moltitudini?
Intuisci il tuo creatore, mondo?
Cercalo sopra il cielo stellato!
Sopra le stelle deve abitare!

“Gioia” si chiama la forte molla
che sta nella natura eterna.
Gioia, gioia aziona le ruote
nel grande meccanismo del mondo.
Essa attrae fuori i fiori dalle gemme,
gli astri dal firmamento,
conduce le stelle nello spazio,
che il canocchiale dell’osservatore non vede. »

Pubblicato in Pensieri | Contrassegnato , , , , , , , , , , , , | Lascia un commento

Vini russi e di abbazia

http://press.russianews.it/press/la-produzione-locale-vino-russia/

Fornitore http://newwineco.ru

Abbazia Monte Oliveto, Siena

http://www.agricolamonteoliveto.com/

Pubblicato in Enogastronomia | Contrassegnato , , , , | Lascia un commento

Configurazione VGA passthrough con libvirt e qemu-kvm

  • creare una nuova macchina virtuale e impostare il chipset Q35 (forse non è necessario)
  • è necessario un BIOS di tipo UEFI: per la compatibilità con VGA passthrough, scaricare OVMF da https://github.com/tianocore/tianocore.github.io/wiki/OVMF e impostarlo per la VM
    esempio:

    <loader readonly='yes' type='pflash'>/raid/GESTIONE/ovmf-x64/OVMF-pure-efi.fd</loader>
    <nvram>/raid/GESTIONE/ovmf-x64/OVMF_VARS-pure-efi.fd</nvram>
  • CPU: scrivere ‘host-passthrough’ in virtmanager
  • cambiare BUS disco1 in VirtIO
  • scheda rete: ‘dispositivo host’ selezionare la macvlan creata (vedere in seguito), modello virtio
  • aggiungere i dispositivi pass-through PCI (NVIDIA) e USB (mouse e tastiera)
  • da shell, editare l’ XML della VM e aggiungere a <features>:
    <features>
            <hyperv>
                    ...
                    <vendor_id state='on' value='123456789abc'/>
                    ...
            </hyperv>
            ...
            <kvm>
            <hidden state='on'/>
            </kvm>
    </features>
    
  • in alternativa (ma è preferibile il precedente punto):
    <!-- modificare il namespace-->
    <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
    <!-- aggiungere i seguenti parametri -->
    <qemu:commandline>
    <qemu:arg value='-cpu'/>
    <qemu:arg value='host,hv_time,kvm=off,hv_vendor_id=null'/>
    </qemu:commandline>

Per impostare una interfaccia di rete virtuale che consenta la comunicazione tra il guest e l’ esterno (compreso il traffico verso l’ host), è necessario creare una interfaccia MAC-VLAN: questa interfaccia virtuale assume un proprio indirizzo MAC e IP, e le si assegna una route e il gateway

https://www.furorteutonicus.eu/2013/08/04/enabling-host-guest-networking-with-kvm-macvlan-and-macvtap/

#!/bin/bash

# let host and guests talk to each other over macvlan
# configures a macvlan interface on the hypervisor
# run this on the hypervisor (e.g. in /etc/rc.local)
# made for IPv4; need modification for IPv6
# meant for a simple network setup with only eth0,
# and a static (manual) ip config
# Evert Mouw, 2013

HWLINK=enp0s31f6
MACVLN=macvlan0
TESTHOST=www.google.com

# ------------
# wait for network availability
# ------------

while ! ping -q -c 1 $TESTHOST > /dev/null
do
    echo "$0: Cannot ping $TESTHOST, waiting another 5 secs..."
    sleep 5
done

# ------------
# get network config
# ------------

IP=$(ip address show dev $HWLINK | grep "inet " | awk '{print $2}')
NETWORK=$(ip -o route | grep $HWLINK | grep -v default | awk '{print $1}')
GATEWAY=$(ip -o route | grep default | awk '{print $3}')

# ------------
# setting up $MACVLN interface
# ------------

ip link add link $HWLINK $MACVLN type macvlan mode bridge
ip address add $IP dev $MACVLN
ip link set dev $MACVLN up

# ------------
# routing table
# ------------

# empty routes
ip route flush dev $HWLINK
ip route flush dev $MACVLN

# add routes
ip route add $NETWORK dev $MACVLN metric 0

# add the default gateway
ip route add default via $GATEWAY

vedere anche http://hicu.be/bridge-vs-macvlan

Pubblicato in Debian | Contrassegnato , , , , , , , , , , , , , | Lascia un commento

Strutture non dissipative

https://www.ordineingegneri.milano.it/ordine/organi-e-gruppi-di-lavoro/commissioni/altre-commissioni/commissione-strutture/pareri-tecnici/ntc-2008-domande-e-risposte/quesito-29-strutture-antisismiche-dissipative-o-non-risposta-del-6-marzo-2012

Quesito 29

Gentili Signori,ho qualche dubbio circa l’interpretazione delle norme NTC8 al cap 7 par. 7.2 relativo al comportamento strutturale nel caso di azione sismica e la loro applicazione. Riassumo le norme:
le costruzioni soggette all’azione sismica, non dotate di appositi dispositivi dissipativi, devono essere progettate in accordo con i seguenti comportamenti strutturali:
a) comportamento strutturale non-dissipativo;
b) comportamento strutturale dissipativo.

Nel comportamento strutturale non dissipativo, cui ci si riferisce quando si progetta per gli stati limite di esercizio, gli effetti combinati delle azioni sismiche e delle altre azioni sono calcolati, indipendentemente dalla tipologia strutturale adottata, senza tener conto delle non linearità di comportamento (di materiale e geometriche) se non rilevanti.
In tal caso gli effetti delle azioni sismiche sono calcolati, quale che sia la modellazione per esse utilizzata, riferendosi allo spettro di progetto ottenuto assumendo un fattore di struttura “q” unitario.
Nel comportamento strutturale dissipativo, cui ci si riferisce quando si progetta per gli stati limite ultimi, gli effetti combinati delle azioni sismiche e delle altre azioni sono calcolati, in funzione della tipologia strutturale adottata, tenendo conto delle non linearità di comportamento (di materiale sempre, geometriche quando rilevanti e comunque sempre quando precisato).
Nel caso la struttura abbia comportamento strutturale dissipativo (perché formulare tale ipotesi come se si trattasse di una possibile scelta del progettista quando invece è sempre obbligatorio considerare la struttura come dissipativa ogni qualvolta vi è l’obbligo di verifiche agli stati limite ultimi ?) si distinguono due livelli di Capacità: Dissipativa o Classi di Duttilità (CD):

– Classe di duttilità alta (CD “A “);
– Classe di duttilità bassa (CD “B “).

La differenza tra le due classi risiede nella entità delle plasticizzazioni cui ci si riconduce in fase di progettazione; per ambedue le classi però, onde assicurare alla struttura un comportamento dissipativo e duttile per evitare rotture fragili e la formazione di meccanismi instabili imprevisti, si deve fare ricorso ai procedimenti della gerarchia delle resistenze; ciò sempre in riferimento alle strutture dissipative, ovviamente.

Da quanto sopra appare pertanto che essendo sempre necessaria la verifica allo stato limite ultimo per una nuova costruzione (eccetto quella in zona 4, di tipo 1 e 2 e di classe I e II quando si adottano le T.A.) sia sempre da considerare la struttura come dissipativa e quindi con l’obbligo di adozione della duttilità e della gerarchia delle resistenze.

Inoltre non dovrebbe essere una scelta dello strutturista l’attribuzione di dissipativa e no ad un nuovo edificio ma una conseguenza insita nella struttura stessa, dovuta alla sua ubicazione e al metodo di verifica adottato (T.A. o s.l.u.)

Ciò premesso ci si domanda:

– cosa serve menzionare le strutture non dissipative visto che non si possono adottare come oggetto di calcoli, fatta eccezione di quelle in zona 4 e verificabili con le T.A.? (tipo 1 e 2 e classe I e II);
– inoltre a qual fine si afferma (cap 7) che le strutture da edificarsi in zona 4 possono essere calcolate con la metodologia indicata per le strutture non antisismiche dato che questo non devono formalmente più esistere sul territorio nazionale?

Mi permetto di aggiungere che, indipendentemente dalla esatta interpretazione delle norme sopra riassunte, mi sembra che le strutture in c.a. abbiano sempre una capacità di dissipare energia in campo inelastico per azioni cicliche ripetute senza che ciò comporti riduzioni significative della resistenza nei confronti delle azioni sia verticali che orizzontali, e che pertanto debbono essere sempre considerate dissipative e progettate con i procedimenti tipici della gerarchia delle resistenze per garantirne la duttilità (in classe di duttilità Alta o Bassa).
A maggior ragione la stessa problematica si presenta quando esiste la necessità reale di interventi su strutture esistenti.

Ed ancora, per quanto riguarda le strutture in acciaio si presenta la stessa dato che secondo il cap 7.5 si può progettare una struttura non dissipativa (come e quando?) e quindi senza soddisfare i requisiti di duttilità.

Ritengo tuttavia, contrariamente alla probabile impossibilità sopra espressa di studiare strutture non dissipative da verificarsi col metodo degli stati limite ultimi, che sia sempre possibile, anche se antieconomico, progettare strutture non dissipative con materiali di qualsiasi natura (anche se non fragili), adottando il fattore di struttura “q” unitario, insieme con l’utilizzo del livello di azione corrispondente allo Stato Limite Ultimo (SLU); in tal caso non è necessario l’utilizzo di accorgimenti tipici della gerarchia delle resistenze, il cui effetto si esplica solamente quando si supera il comportamento elastico della struttura.
Ciò anche nel caso di adeguamento di strutture esistenti rendendo possibile il metodo di analisi Pushover.
Ritengo altresì che in tal caso si debba garantire un livello significativo di duttilità secondo le prescrizioni contenute nel Capitolo 4 delle NTC 2008.

Ringrazio per l’attenzione, in attesa di una Vs. cortese delucidazione.

Risposta del 6 marzo 2012

La scelta di progettare una struttura dissipativa e non-dissipativa spetta al Progettista che per coerenza dovrà fare una serie di considerazioni (i.e. fare determinati tipi di analisi, adottare adeguati fattori di struttura, introdurre opportuni dettagli costruttivi e la “gerarchia delle resistenze”, …); pertanto si può sempre progettare strutture non-dissipative!
Una struttura può essere pensata come “non-dissipativa”,ma ovviamente sarà “più corposa” perché dovrà essere in grado di sopportare un sisma “da stato limite ultimo” (“SLV” o “SLC”) in campo elastico; tuttavia, nella realtà fisica, le strutture non-dissipative non esistono, perché la possibilità di “dissipare energia” in campo plastico è insita nei materiali indipendentemente dai dettagli costruttivi; si pensi ad esempio che l’EC8 afferma che il fattore q è sempre maggiore di 1,50 e pertanto le azioni sismiche da spettro elastico possono (secondo EC8) essere sempre abbattute di un 30% indipendentemente dai dettagli costruttivi.
Il concetto di poter progettare una struttura come “dissipativa” è una “possibilità” che la Normativa ci offre per “ridurre” le nostre strutture con certi accorgimenti (in particolare dettagli costruttivi e “gerarchia delle resistenze”) ma nessuno, tantomeno la Norma, vieta di fare di pensare strutture non-dissipative.

In altri termini:
il principio ispiratore della progettazione sismica è contenuto tra le varie righe del capitolo 7 della norma tecnica, dove oltre a regole generali della progettazione secondo i principali criteri antisismici (per esempio costruire strutture più regolari possibili, dotate di sistemi resistenti in due direzioni ortogonali, e facendo attenzione a limitare i moti torsionali per effetto di eccentricità tra centro di massa e rigidezza della struttura) vengono illustrati i concetti base di cosa vuol dire azione sismica e cosa vuol dire risposta strutturale nei confronti dell’azione sismica.

La norma ammette un livello di danneggiamento esteso e controllato delle costruzioni (SLC, SLV) e un livello di danneggiamento minore, comunque limitato (SLD, SLO): nel primo caso la risposta della struttura è affidata oltre che alla sua naturale resistenza (setti, muri, pilastri, nuclei), alla sua capacità di dissipare energia in campo plastico (o inelastico) in maniera ciclica secondo dissipazioni controllate e veicolabili dal progettista stesso in punti ben precisi della struttura, pur tuttavia considerando che nei riguardi degli stati limite di esercizio (un livello “diverso” di sollecitazione, corrispondente al secondo caso) la struttura possiede invece un comportamento fondamentalmente elastico e NON dissipativo.

Il fatto che la capacità dissipativa sia messa in conto nella progettazione avviene nel momento in cui si quantifica l’intensità dell’azione sismica (cioè il fattore di risposta al sisma), dove a partire dalle azioni cosiddette elastiche si estrapolano delle azioni di progetto in grado di rappresentare in maniera estremamente semplificata la capacità di dissipazione anelastica più o meno accentuata (strutture più o meno iperstatiche) della medesima struttura a seguito di plasticizzazioni localizzate, che esplicano la loro attivazione prima del verificarsi di meccanismi fragili (criteri di progettazione del Capacity Design o di “gerarchia”).

Pertanto:
Nel caso di nuove costruzioni
Il calcolo di una struttura è normalmente eseguito al primo ordine (condizione indeformata) e in campo lineare. La norma consente di poter progettare le nuove strutture sotto sisma secondo tre livelli di duttilità:
strutture non duttili;
strutture mediamente duttili (CD”B”, equivalente alla classe LDC – MDC, low and medium ductility class);
strutture fortemente duttili (CD”A”, equivalente alla classe HDC, high ductility class).

Quindi non è vero che non si possa progettare le strutture come non duttili, ma è sufficiente invece verificare a posteriori che tali strutture siano adeguatamente resistenti al sisma in campo elastico.
Se invece il progettista ipotizza che esistano particolari zone delle struttura a cui affidare la risposta alle azioni orizzontali in maniera che esse abbiano a comportarsi come non duttili, allora la norma, a patto di adottare particolari provvedimenti e criteri (particolari) costruttivi, mi concede di considerare un’azione sismica “progettualmente” ridotta.

Quanto alla progettazione alle T.A. in accordo con il par. 2.7 delle NTC è necessario precisare che al capoverso 4 del presente paragrafo si dice che è necessario assumere “le modalità costruttive e di calcolo di cui al D.M. LL. PP. citato (D.M. LL. PP. 16.01.1996, NdR)); ciò comporta l’introduzione di un certo grado di duttilità anche nelle strutture progettate alle T.A..
Le strutture in zona ex 4 (tipo 1 e 2, classi d’uso I e II) sono comunque soggette ad azioni sismiche molto basse, pertanto si dice che, ragionevolmente, e sotto particolari accorgimenti (che richiamano concetti comunque della strategia di progettazione antisismica), possano essere progettate secondo criteri non sismici.

Quesito 29 bis
Egregio Ingegnere, rileggendo il mio messaggio qui sotto riportato mi accorgo di essere incorso in una affermazione errata; la seguente in corsivo:

Aggiungo che, così come sopra espresso, risulta chiaro che le zone duttili (ad esempio i pilastri dei telai) debbano essere ancora resistenti dopo che le zone fragili siano collassate (le travi), o meglio che le cerniere plastiche si formino sulle travi essendo i pilastri ancora in regime elastico.

Credo invece che nelle strutture antismiche, per quello che si intende per Capacity Design, debbano essere esaminati tutti i possibili meccanismi di rottura, affidando la maggiore resistenza agli elementi più fragili affinché la loro rottura avvenga dopo la massima deformazione dell’insieme strutturale coesistente col sisma di progetto e permessa dagli elementi più duttili snervati ma ancora sufficientemente resistenti; pertanto alcuni elementi strutturali dovranno essere progettati non in base alle sollecitazioni di calcolo ma aumentandone opportunamente le loro resistenze (quelli ritenuti più fragili).

In sostanza: nel caso di un telaio a pilastri e travi i primi devono essere sufficientemente duttili da consentire la deformazione del telaio fino all’ insorgere delle cerniere plastiche agli estremi delle travi sovra-resistenti.

La struttura deve essere concepita in modo che le modalità di collasso delle zone dotate di duttilità, capacità deformative e dissipative precedano le modalità di collasso fragili; è così ?

Se è così si dovrà esaminare la struttura mediante analisi non lineare e la stessa dovrà essere dissipativa.

Risposta del 12 marzo 2012
Il concetto da Lei espresso (i.e. La struttura deve essere concepita in modo che le modalità di collasso delle zone dotate di duttilità, capacità deformative e dissipative precedano le modalità di collasso fragili) è condivisibile e presuppone che la struttura sia progettata adottando degli opportuni fattori di struttura q (>1). Ovviamente qualora si optasse a “pensare” ad una struttura come “non-dissipativa” (i.e. q=1) il discorso decade, perché la stessa rimane in campo elastico anche sotto l’azione sismica, quindi la “duttilità” non è più necessaria.
Quanto alle analisi da svolgere si rimanda al paragrafo 7.3 delle NTC, dove vengono presentate tutte le scelte possibili; si evidenzia che anche in presenza di analisi lineari è possibile tener conto della duttilità (che è legata a concetti di non-linearità) adottando le prescrizioni in termini di calcolo delle sollecitazioni, verifiche, dettagli costruttivi, … previsti nel capitolo 7 delle NTC (ed annessa circolare esplicativa).

Pubblicato in Uncategorized | Contrassegnato , , , , , , , , , , , , , | Lascia un commento

VGA passthrough con OVMF e QEMU-KVM

libvirt: parametri per QEMU

Bisogna modificare lo XML creato da virt-manager:

virsh edit nome_della_VM

per modificare i parametri passati a QEMU per fare lo spoof per i driver NVIDIA:

https://forum.level1techs.com/t/play-games-in-windows-on-linux-pci-passthrough-quick-guide/108981?source_topic_id=110696

<!-- modificare il namespace-->
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<!-- aggiungere i seguenti parametri -->
<qemu:commandline>
<qemu:arg value='-cpu'/>
<qemu:arg value='host,hv_time,kvm=off,hv_vendor_id=null'/>
</qemu:commandline>

Installare i driver VirtIO

Scaricare la ISO da:  https://fedoraproject.org/wiki/Windows_Virtio_Drivers, e cercare i driver nelle seguenti directory:

  • NetKVM/: Virtio Network driver
  • viostor/: Virtio Block driver
  • guest-agent/: QEMU Guest Agent 32bit and 64bit MSI installers
  • qemupciserial/: QEMU PCI serial device driver
  • Balloon/: Virtio Memory Balloon driver

https://forum.proxmox.com/threads/ovmf-uefi-windows-10-boot-option-wont-stick.27376/

How I setup the VM

  1. Set up VM
  2. Select Windows 10
  3. Add a new vDisk using Virtio Bus (iothread + Write back Cache) as Virtio0
  4. add Qemu agent -> yes
  5. Add windows 10 Iso as First DVD on Sata0
  6. Add Virtio-win-0.1.117 as secondary DVD on Sata1
  7. Select Virtio Controller via Options Tab (afaik best practice is to use SCSI ontop of Virtio controller for Windows on SSDs)
  8. Verify your boot Orders. —> Disk then CD-Rom
  9. Install windows 10
  10. Start Windows VM
  11. Boot from Windows ISO (press any key to start from DVD/CD . . .) select “Install Now”, select windows 10 pro x64, custom install, “load Driver” option
  12. Select Virtio-DVD > Viostor > w8.1 > amd64
  13. Install Red Hat VirtIO SCSI controller (driver for your virtio0)
    “load Driver” option
  14. Select Virtio-DVD > VioSCSI > w8.1 > amd64
    uncheck the checkbox
  15. Install Red Hat VirtIO SCSI pass-through controller (in case you need it later)
    “load Driver” option
  16. Select Virtio-DVD > netKVM > w8.1 > amd64
    uncheck the checkbox
  17. Install Red Hat VirtIO Ethernet Adapter (you will need this later)
  18. Install windows regularly (like you’d normally do)
Pubblicato in Debian, Uncategorized | Contrassegnato , , , , , , , , | Lascia un commento