oggi ho iniziato a giocare con IPv6, sta finalmente arrivando l’ora di implementarlo sulla nostra rete, ma non posso certo farlo senza un po’ di laboratorio.

Allora ho messo sul mio EveNG un mini lab con questi elementi:

• 2 Mikrotik CHR 7.10 (ce1 e ce2)
• 2 Juniper Olive (pe1 e pe2)

I ce hanno indirizzamento IPv6 mentre i pe hanno indirizzamento IPv4: l’obiettivo è fare in modo di poter effettuare un ping da ce1 a ce2 passando per una rete IPv4.

Per quanto riguarda gli indirizzamenti IPv6 ho usato una classe con indirizzamento IPv4 like così da semplificare i test (da buon ingegnere!)

Questi gli indirizzi IP usati

PE1

em0: 10.1.1.5/30
em1: ::10.1.1.2/126
lo0: 10.1.1.2/32

PE2

em0: 10.1.1.6/30
em1: ::10.1.1.13/126
lo0: 10.1.1.3/32

CE1

ether1: ::10.1.1.1/126

CE2

ether1: ::10.1.1.14/126

I due router PE sono collegati con una sessione Multi-path BGP su IPv4 e scambiano le rotte IPv6 (value 2) AFI (address family indicator) e SAFI (subsequent AFI) (value 4). Ogni PE utilizzerà come next-hop per gli indirizzi IPv6 il proprio indirizzo IPv4 (useremo gli ip della loopback)

Inoltre per semplificare ulteriormente il lab (avremo tempo per complicare le cose!) la comunicazione tra CE e PE avverrà tramite rotte statiche (in particolare la default sui CE verso i PE) mentre per complicare un po’ le cose si potrebbe usare anche in questo caso il BGP (external)

La configurazione di MPLS e LDP servirà per abilitare la segnalazione tra i PE visto che le rotte IPv6 vengono scambiate mediante aggiunta di label (inner e outer)

Iniziamo le configurazioni delle interfaccie ethernet:

PE1

set interfaces em1 unit 0 family inet6 address ::10.1.1.2/126
set interfaces em1 unit 0 family mpls
set interfaces em0 unit 0 family inet address 10.1.1.5/30
set interfaces em0 unit 0 family inet6
set interfaces em0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.1.1.2/32

PE2

set interfaces em1 unit 0 family inet6 address ::10.1.1.13/126
set interfaces em1 unit 0 family mpls
set interfaces em0 unit 0 family inet address 10.1.1.6/30
set interfaces em0 unit 0 family inet6
set interfaces em0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.1.1.3/32

CE1

/ipv6 address
add address=::10.1.1.1/126 advertise=no interface=ether1
/ipv6 route
add dst-address=::/0 gateway=::10.1.1.2

CE2

/ipv6 address
add address=::10.1.1.14/126 advertise=no interface=ether1
/ipv6 route
add dst-address=::/0 gateway=::10.1.1.13

Come anticipato, non ho utilizzato BGP per propagare le subnet IPv6 ma delle semplici rotte statiche.

Imposto MPLS e LDP sui PE:

PE1

set protocols mpls ipv6-tunneling
set protocols mpls interface em0
set protocols mpls interface em1
set protocols ldp interface em0

PE2

set protocols mpls ipv6-tunneling
set protocols mpls interface em0
set protocols mpls interface em1
set protocols ldp interface em0

Prima di procedere con la configurazione dei protocolli di routing (OSPF e BGP) dobbiamo definire le policy per il BGP e altre info di base (router-id e autonomous-system) su entrambi i router:

PE1

set policy-options policy-statement next-hop-self then next-hop self
set policy-options policy-statement send-v6 from family inet6
set policy-options policy-statement send-v6 from protocol bgp
set policy-options policy-statement send-v6 from protocol direct
set policy-options policy-statement send-v6 then accept
set routing-options router-id 10.1.1.2
set routing-options autonomous-system 65002

PE2

set policy-options policy-statement next-hop-self then next-hop self
set policy-options policy-statement send-v6 from family inet6
set policy-options policy-statement send-v6 from protocol bgp
set policy-options policy-statement send-v6 from protocol direct
set policy-options policy-statement send-v6 then accept
set routing-options router-id 10.1.1.3
set routing-options autonomous-system 65002

Le policy sopra create (next-hop-self e send-v6) servono per indicare rispettivamente chi sarà il next-hop dei neighbors e quali famiglie di protocolli annunciare.

Manca poco, dobbiamo solo creare i protocolli e far parlare i nostri PE (OSPF e BGP):

PE1

set protocols bgp group toPE2 family inet6 labeled-unicast explicit-null
set protocols bgp group toPE2 export next-hop-self
set protocols bgp group toPE2 export send-v6
set protocols bgp group toPE2 neighbor 10.1.1.3
set protocols ospf area 0.0.0.0 interface em0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

PE2

set protocols bgp group toPE2 family inet6 labeled-unicast explicit-null
set protocols bgp group toPE2 export next-hop-self
set protocols bgp group toPE2 export send-v6
set protocols bgp group toPE2 neighbor 10.1.1.2
set protocols ospf area 0.0.0.0 interface em0
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Una volta salita la sessione BGP, da verificare con il comando show bgp summary possiamo verificare le rotte ricevute dai rispettivi neighbor con il comando show route receive-protocol bgp IP_NEIGHBOR

La prova definitiva è il ping da CE1 a CE2:

Enjoy!

The post Juniper Howto – IPv6 su IPv4 Tunnel appeared first on paolodaniele.it - linux & networking.

Chi non muore si rivede direte voi, ho sempre troppo poco tempo per sperimentare (purtroppo!) e troppo lavoro da fare (per fortuna!)
Visto che a causa delle recenti decisioni di Broadcom su VMWare, tutti si stanno buttando su Proxmox, vi metto una semplice ma utile guida per installare un sistema operativo Windows Server brandizzato HPE su Proxmox.
Di base questi sistemi sono installabili solo se rilevano l’hardware HPE altrimenti, in fase di installazione, otteniamo il messaggio di errore seguente:

Proxmox è un sistema di virtualizzazione, ormai arrivato alla versione 8 (io lo uso dalla 2!!) basato su KVM e QEMU per la gestione delle macchine virtuali e su LXC per la gestione dei container.

E’ altamente personalizzabile, supporta la gestione in cluster (tramite quorum) e le configurazioni sono davvero semplicissime (prometto che scriverò qualche guida in seguito!)

Nel mio caso di esempio ho installato un Proxmox su un server HPE DL380 GEN10 sul quale volevo installare la versione customizzata fornita da HPE di Windows Server 2022.

Provando a caricare la iso e installarla, ottengo l’errore che vi ho mostrato sopra, questo perchè la virtualizzazione non fa passare le informazioni relative alla macchina fisica nel bios di quella virtuale.

Con VMWare il trucco è facile, basta creare un parametro da passare al bios virtuale, con Proxmox è un po’ più articolato, ma altrettanto semplice.

Per prima cosa dobbiamo ottenere alcune info sulla macchina fisica:

• Produttore
• Descrizione Prodotto
• Versione del Bios della macchina fisica
• Seriale
• SKU (o Product ID)

Se la macchina è nuova possiamo reperire tutte le info o nel momento in cui carica il sistema (si vedono facilmente versione del bios, produttore e descrizione prodotto) oppure direttamente dalla scatola (Seriale e SKU)

Tutte le informazioni sono comunque reperibili dal Proxmox stesso usando il comando dmidecode e recuperando con un grep tutti i valori richiesti.

Fatto questo si va nelle opzioni della macchina virtuale:

Fatto questo settiamo le impostazioni come segue:

e il gioco è fatto.

Enjoy!

The post Installazione Windows Server 2022 HPE ROK su Proxmox appeared first on paolodaniele.it - linux & networking.

Questa cosa accade perchè il router non sta leggendo la configurazione dal registro di memoria corretto, ma magari dopo un’operazione di ROMMon è rimasto configurato il registro sbagliato (ovvero quello che bypassa la configurazione di startup presente nella NVRAM.

Come ci si accorge di questo?

Beh per prima cosa, cambiando qualunque cosa, al reload lo troviamo azzerato!

A parte questo ovvio particolare, ci si può accorgere della cosa facendo uno “show version” dal router Cisco, dove si vedrà una cosa del genere:

Router#show version
Cisco IOS XE Software, Version 16.10.01a
Cisco IOS Software [Gibraltar], ASR1000 Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.10.1a, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 by Cisco Systems, Inc.
Compiled Thu 29-Nov-18 03:47 by mcpre

Cisco IOS-XE software, Copyright (c) 2005-2018 by cisco Systems, Inc.
All rights reserved. Certain components of Cisco IOS-XE software are
licensed under the GNU General Public License ("GPL") Version 2.0. The
software code licensed under GPL Version 2.0 is free software that comes
with ABSOLUTELY NO WARRANTY. You can redistribute and/or modify such
GPL code under the terms of GPL Version 2.0. For more details, see the
documentation or "License Notice" file accompanying the IOS-XE software,
or the applicable URL provided on the flyer accompanying the IOS-XE
software.

ROM: IOS-XE ROMMON

Router uptime is 2 minutes
Uptime for this control processor is 5 minutes
System returned to ROM by Reload Command
System image file is "bootflash:asr1002x-universalk9.16.10.01a.SPA.bin"
Last reload reason: Reload Command

This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

License Type: Smart License is permanent
License Suite: AdvUCSuiteK9 
Next reload License Suite: AdvUCSuiteK9 
The current throughput level is 10000000 kbps 

Smart Licensing Status: UNREGISTERED/EVAL MODE

cisco ASR1002-X (2RU-X) processor (revision 2KP) with 1189381K/6147K bytes of memory.
Processor board ID FOX1719GE28
14 Gigabit Ethernet interfaces
1 Ten Gigabit Ethernet interface
32768K bytes of non-volatile configuration memory.
4194304K bytes of physical memory.
6684671K bytes of eUSB flash at bootflash:.
0K bytes of WebUI ODM Files at webui:.

Configuration register is 0x2142 

Il registro di configurazione è settato su 0x2142 (oppure in altre versioni è indicato con 0x142) questo significa che sta bypassando la normale procedura di funzionamento come si vede anche dalla tabella sotto indicata (fonte Cisco.com)

Per rimettere le cose apposto si procede quindi a configurare l’apparato per caricare i dati dal registro corretto.

Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.    
Router(config)#config-register 0x2102 
Router(config)#end

Ecco che facendo uno “show version” si vedrà quanto segue:

…

Configuration register is 0x2142 (will be 0x2102 at next reload)

Al prossimo riavvio del router il sistema partirà con le impostazioni corrette!

Enjoy!

The post Cisco Router – Configurazione di default al reboot appeared first on paolodaniele.it - linux & networking.

ritorno per fare alcune considerazioni sull’installazione di un certificato SSL e quindi l’abilitazione di HTTPS su JBoss.

Ormai diventato da qualche anno Wildfly è uno dei più diffusi application server insieme a Tomcat per quanto riguarda le applicazioni sviluppate in Java.

Oggi vediamo come configurare HTTPS.

La ricetta di oggi richiede:

• Certificato SSL
• Chiave privata usata per generare il CSR e quindi ottenere il Certificato
• Certificato della CA (Certification Authority) oppure CC (Chain Certificate)
• Una Password (che definiremo noi)
• JBoss Wildfly installato

Per farvi capire meglio la storia dei certificati (chi è più pratica può tranquillamente passare avanti)

Per prima cosa compattiamo tutti i certificati sopra indicati in un unico .pfx che conterrà tutte le informazioni riguardo il certificato, la ca e la chiave privata. Per fare questo servirà definire una password (perchè il pfx contiene tutte le info del certificato e nelle mani sbagliate potrebbe essere dannoso!)

Diamo quindi il comando da terminale:

openssl pkcs12 -export -out myapp.pfx -in mycert.crt -inkey myserverkey.key -certfile ca.crt

Spiegare il comando è abbastanza inutile perchè la sintassi parla da sola!

Ora che abbiamo il nostro myapp.pfx lo spostiamo nella cartella: (${WILDFLY_HOME}/standalone/configuration)

Modifichiamo adesso il file con config standalone.xml alla sezione ApplicationRealm (se non servono particolari configurazioni, altrimenti si può fare tranquillamente un Realm dedicato) come segue:

<security-realm name=”ApplicationRealm”>
    <server-identities>
        <ssl>
           <keystore path=”myapp.pfx” relative-to=”jboss.server.config.dir” keystore-password=”<your-password>” />
        </ssl>
    </server-identities>
</security-realm>

La password del keystore in realtà non è altro che la password con cui abbiamo esportato il pfx.

Di base JBoss utilizza, come anche Tomcat, la porta 8443 per la parte SSL.

Se per caso vogliamo forzare l’utilizzo della porta 443 (HTTPS) possiamo o mettere davanti a JBoss un reverse proxy fatto ad esempio con Apache o Nginx che fanno il redirect del traffico sulla 443 verso la 8443 locale (Soluzione consigliata) oppure con delle regole IPTABLES (Soluzione di laboratorio):

sudo iptables -t nat -A PREROUTING -p tcp –dport 443 -j REDIRECT –to-ports 8443
sudo iptables -t nat -A OUTPUT -p tcp –dport 443 -o lo -j REDIRECT –to-port 8443
sudo service iptables save

Abbiamo finito!

Adesso possiamo riavviare JBoss e andare sulla porta https://mydomain:8443 oppure https://mydomain

Enjoy!

The post Configurazione SSL/HTTPS Wildfly Application Server appeared first on paolodaniele.it - linux & networking.

a volte ritornano!

Dopo diverso tempo che non posto nulla (per motivi lavorativi!) sono finalmente riuscito a trovare il tempo di provare la versione 7 di RouterOS, ma soprattutto la funzionalità aggiuntiva che volevo testare ovvero la VPN con Wireguard.

Sicuramente il vantaggio, rispetto ad IPSec è la facilità di configurazione: è praticamente istantanea.

Se proprio devo trovare un difetto, sicuramente il fatto che sia UDP (che è uno dei motivi che la rende anche una vpn con latenza molto bassa) non mi fa entusiasmare: io rimango della vecchia scuola e amo il 3-way-handshake del TCP.

Torniamo a noi, come scenario utilizzerò questo:

Passiamo alla configurazione (vi faccio vedere prima la parte testuale e poi gli screen di Winbox)

Office1

/interface/wireguard
add listen-port=13231 name=wireguard_office1

Office2

/interface/wireguard
add listen-port=13231 name=wireguard_office2

Una volta configurati i peer sui singoli Office, si configurano i rispettivi peer:

Office1

/interface/wireguard/peers
add allowed-address=10.1.101.0/24 endpoint-address=192.168.80.1 endpoint-port=13231 interface=wireguard_office1 \
public-key=”PUBLIC_KEY_OFFICE2″

Office2

/interface/wireguard/peers
add allowed-address=10.1.102.0/24 endpoint-address=192.168.90.1 endpoint-port=13231 interface=wireguard_office2 \
public-key=”PUBLIC_KEY_OFFICE1″

Infine si aggiungono gli indirizzi IP sulle interfacce di Wireguard e le rotte statiche per raggiungere gli endpoint.

Office1

/ip/address add address=10.255.255.1/30 interface=wireguard_office1

/ip/route add dst-address=10.1.101.0/24 gateway=wireguard_office1

Office2

/ip/address add address=10.255.255.2/30 interface=wireguard_office2

/ip/route add dst-address=10.1.202.0/24 gateway=wireguard_office2

Infine le regole firewall per permettere la connessione solo dai rispettivi endpoint pubblici:

Office1

/ip/firewall/filter
add action=accept chain=input dst-port=13231 protocol=udp src-address=192.168.80.1

Office2

/ip/firewall/filter
add action=accept chain=input dst-port=13231 protocol=udp src-address=192.168.90.1

I siti adesso sono collegati.

Di seguito le schermate di Winbox:

Enjoy!

P.

The post Mikrotik Site to Site Wireguard VPN appeared first on paolodaniele.it - linux & networking.

è un po’ che non scrivo,ma oggi voglio iniziare una nuova sezione del sito dedicata al mondo Juniper. Chi mi segue sa che ho dedicato il sito principalmente a me stesso, per ricordarmi le configurazioni e le guide che possono sempre tornare utili in ogni momento e che applico in ambito lavorativo.

Visto che al lavoro stiamo cercando di fare un salto di qualità per offrire un servizio sempre migliore ( vi invito a visitare il nostro sito www.intendo.it ) abbiamo iniziato ad utilizzare Juniper come router edge (ovvero router di confine tra i nostri fornitori di connettività ed il nostro backbone interno)

Già a primo impatto, rispetto anche alla fascia alta mikrotik (CCR) non ci sono paragoni, specie quando si va a gestire la FIRT (Full Internet Routing Table): con Mikrotik cercare una rotta verso una destinazione comporta il blocco del dispositivo per 1-2 minuti, su JunOS è istantaneo. Al momento sui Juniper in produzione vengono gestire 2M di rotte senza nessun problema o rallentamento.

Vediamo alcuni comandi per l’inizializzazione, man mano cercherò di aggiungere qualche guida più complessa nell’ambito networking (vlan, ospf, bgp etc.)

Per prima cosa, il primo collegamento va fatto naturalmente con la seriale, in particolare con questi parametri di rete:

Baud Rate—9600
Flow Control—None
Data—8
Parity—None
Stop Bits—1
DCD State—Disregard

Una volta dentro, ci troviamo una schermata del genere:

root@core1:~ #

Questa è la prima shell (tipicamente Linux visto che è un sistema con base BSD)

Digitando il comando cli

root@core1:~ # cli
root@core1.my.domain> configure
root@core1.my.domain#

Adesso siamo in configurazione.

Vediamo le cose principali da configurare:

Impostazione Password di Root

root@core1.my.domain# set system root-authentication plain-text-password

Impostazione Hostname

root@core1.my.domain# set system host-name HOSTNAME_ROUTER

Impostazione IP Interfaccia Management

root@core1.my.domain# set interfaces fxp0 unit 0 family inet address 192.168.1.100/24

Configurazione Default Gateway

root@core1.my.domain# set routing-options static route default next-hop 192.168.1.254

Abilitazione SSH e Telnet

root@core1.my.domain# set system services ssh
root@core1.my.domain# set system services telnet

Una volta fatte tutte le modifiche per salvare si da il commit

root@core1.my.domain# commit

Update Firmware

Per l’aggiornamento firmware occorre avere un account valido, dal quale andare a scaricare il file. Generalmente le istruzioni si trovano direttamente in fase di download, ma giusto per promemoria le riepilogo di seguito:

root@core1.my.domain>file copy “https://cdn.juniper.net/software/ittest/software_target/agileEcotTest/Dev_Binary_Build.tar?SM_USER=XXXXXX=XXXXXXXXX” /var/tmp/image-name.tgz

root@core1.my.domain> request system software add /var/tmp/image-name.tgz

root@core1.my.domain:~ # reboot

Come vedete l’update non si fa dalla configurazione ma dalla cli.

Per questa panoramica è tutto, spero a breve di scrivere qualcosa di più complicato

Enjoy!

The post Juniper Router – introduzione appeared first on paolodaniele.it - linux & networking.

oggi parliamo della modalità Rommon (Rom Monitor) dei router/switch Cisco. La modalità ROMMON consiste in una modalità ibrida, è anche chiamata programma di bootstrap. Il firmware di ROM monitor viene lanciato quando il router viene acceso o resettato. Il firmware serve ad inizializzare il processore ed il sistema operativo (IOS) del router. Questo tipo di modalità è utilizzata per alcuni lavori di configurazioni, tipo il recupero di password e il download di un IOS attraverso la porta console. Se non vi è nessun IOS nella flash del router da essere caricato all’avvio, la modalità ROM monitor avvia il router.

Nel mio caso avevo bisogno di resettare una password persa da un potenziale cliente.

Per fare questo la modalità Rommon viene in nostro aiuto, ma esistono naturalmente diversi sistemi a seconda del tipo di routers/switch Cisco in questione.

La procedura iniziale è comune a tutti, ovvero collegarsi con un cavo Console e riavviare il dispositivo.

Quando arriva il messaggio:

***** The system will autoboot in 5 seconds ***** 

Send "break character" to prevent autobooting. 

Premere CTRL+PAUSE (ho dovuto collegare una tastiera usb classica perchè con i nuovi portatili ci sono diverse possibili combinazioni che non hanno funzionato nel mio caso)

Una volta dentro possiamo trovarci davanti a due tipi di schermate.

TIPO 1

rommon 1 >

TIPO 2

switch:

Vediamo di analizzare i due tipi.

TIPO 1

Per questo primo tipo la procedura da seguire è più rapida:

rommon 1 >
rommon 2 > confreg 0x2142
rommon 3 > boot

A seconda del tipo di router/switch il valore esadecimale da mettere dopo confreg potrebbe variare (es. a volte si mette 0x142) ma questo si può solo provare oppure verificare sul sito Cisco in base al proprio modello di apparato.

Invece il mio caso rientrava nel tipo 2

TIPO 2

switch:

Per primacosa carichiamo in memoria la flash:

switch: flash_init

Fatto questo procediamo con il vedere i files al suo interno:

   13  drwx         192   Mar 01 1993 22:30:48 me340x-metroipaccess-mz.122-25.EX
   11  -rwx        5825   Mar 01 1993 22:31:59  config.text
   18  -rwx         720   Mar 01 1993 02:21:30  vlan.dat
16128000 bytes total (10003456 bytes free) 

Nel file vlan.dat ci sono le info delle VLAN configurate sul sistema, mentre il file config.text è il file dove viene memorizzata la configurazione e quindi anche le pwd.

Per poterlo bypassare dobbiamo rinominarlo (oppure cancellarlo se non ci interessa la vecchia config)

switch: rename flash:config.text flash:config.text.old

fatto questo facciamo partire il sistema:

switch: boot

Una volta fatto il boot basta ricopiare la vecchia config in startup:

Switch# rename flash:config.text.old flash:config.text 

Switch# copy flash:config.text system:running-config 

Ecco fatto adesso lo switch/router ha di nuovo la sua config e noi possiamo tranquillamente cambiare la password per rimetterne una nuova!

Enjoy!

The post Cisco Rommon appeared first on paolodaniele.it - linux & networking.

Riguardo Kubernetes c’è poco da dire, è un orchestratore, probabilmente il migliore in circolazione che permette di ridefinire i concetti di applicazione utilizzando il paradigma ormai consolidato dei container (su Kubernetes sono i pods)

Per maggiori dettagli vi rimando alla documentazione ufficiale disponibile a questo link

Vediamo lo scenario che vogliamo raggiungere:

Per fare questo ho “costruito” 3 VM:

• Kube Master
• Kube Slave
• Kube Slave2

Su queste ho costruito un cluster e poi deployato i vari servizi come indicato in figura.

Il sistema operativo usato sulle 3 VM è Ubuntu 20.04 LTS con 2GB di RAM, 2 Processori (necessari per Docker e Kubernetes) e un disco da 25GB giusto per fare un po’ di prove. La scheda di rete di tutte e 3 le VM è in Bridge con la mia eth del pc così da avere i device disponibili il DHCP sulla mia rete interna.

Vediamo adesso i passaggi da seguire (Ci sono diverse scuole di pensiero, io ho preferito usare il deploy classico basato sui pacchetti, altri preferiscono Minikube)

Una volta installato il sistema operativo (con un utente non root) e avviato si procede con l’installazione dei pacchetti fondamentali:

sudo apt-get update && sudo apt-get install -y apt-transport-https

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add –

sudo bash -c ‘echo “deb http://apt.kubernetes.io/ kubernetes-xenial main” > /etc/apt/sources.list.d/kubernetes.list’

sudo apt-get update && sudo apt-get install -y kubelet kubeadm kubectl

Prima di inizializzare il nodo master dobbiamo aver installato Docker o un altro sistema che permetta la containerizzazione(lo stesso Virtual Box lo permette).

Una volta installato Docker procediamo con l’inizializzazione sul nodo master disattivando prima la Swap (anche se è possibile ignorare il preflight con il comando: –ignore-preflight-errors=Swap)

sudo swapoff -a

sudo kubeadm init

Fatto questo procediamo con la copia dei file di configurazione come indicato:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

Una volta che il nodo Master è stato inizializzato si può passare a fare la join dei nodi Slave con la stringa fornita in fase di fine inizializzazione del master:

kubeadm join IP_ADDRESS:6443 –token TOKEN_KEY \
–discovery-token-ca-cert-hash sha256:XXXXXXXXXXXXXXXXXX

Quando i due slave avranno terminato la join, dal master dando il comando:

kubectl get nodes

Vedremo un output del genere:

Benissimo, adesso il cluster Kubernetes è pronto per ospitare i Pods, ma prima di procedere dobbiamo installare un CNI (Container Network Interface) per far parlare master e slave.

I più diffusi sono Flannel e Calico. Per il mio esempio ho usato Calico che è facilmente installabile eseguendo questi due deploy:

kubectl create -f https://docs.projectcalico.org/manifests/tigera-operator.yaml
kubectl create -f https://docs.projectcalico.org/manifests/custom-resources.yaml

Una volta installato avremo una situazione del genere:

Adesso si può procedere con il deploy della nostra applicazione.

Per prima cosa andiamo a creare un Persistent Volume che sarà fondamentale per poter caricare su il DB MySQL e i file di WordPress. Anche in questo caso esistono diverse scuole di pensiero e tipologie di volumi installabili, io ho utilizzato il caso più semplice, ovvero con un volume locale sul nodo Master (altre soluzioni usano NFS, GlusterFS etc.)

Procediamo:

kubectl create -f https://github.com/IBM/Scalable-WordPress-deployment-on-Kubernetes/blob/master/local-volumes.yaml

Facendo così creo i volumi necessari che verranno poi “rivendicati” da WordPress e MySQL.

Questa operazione è fondamentale farla prima altrimenti le successive procedure non andranno a buon fine.

Ora creiamo un file dove indichiamo alcune personalizzazioni (es. la pwd di root di MySQL):

cat <<EOF >./kustomization.yaml
secretGenerator:
- name: mysql-pass
  literals:
  - password=YOUR_PASSWORD
EOF

Fatto questo scarichiamo i seguenti files:

curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml

curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml

Questi li aggiungeremo al file di kustomization:

cat <<EOF >>./kustomization.yaml
resources:
  - mysql-deployment.yaml
  - wordpress-deployment.yaml
EOF

Adesso abbiamo quasi terminato e possiamo procedere con:

kubectl apply -k ./

Se tutto è andato a buon fine potrete vedere alcune schermate come di seguito:

Ora per poter fare una installazione pulita di WordPress, dato che siamo in una LAN per cui l’EXTERNAL-IP non ce l’ho, possiamo aggirare il problema facendo questa mossa:

kubectl patch svc deployments/wordpress -p '{"spec":{"externalIPs":["192.168.XX.XX"]}}'

Facendo così e aggiungendomi nel mio file hosts la mappatura:

192.168.XX.XX paolodaniele.test

Posso installare il tutto andando dal mio browser al link http://paolodaniele.test

Abbiamo finito! Se vogliamo aumentare e quindi scalare il nostro WordPress ad esempio in caso ti traffico elevato basta fare così:

kubectl scale deployments/wordpress –replicas=8

Ed ecco quello che apparirà dopo poco:

Dietro Kubernetes e la containerizzazione c’è un mondo che piano piano sto cercando di scardinare

Enjoy!

The post Deploy WordPress e MySQL in un Cluster Kubernetes con Persistent Volumes appeared first on paolodaniele.it - linux & networking.

oggi vi spiego come risolvere un problema per chi utilizza certificati SSL firmati dalla CA AddTrust.

Questa CA infatti è scaduta il giorno 30 maggio e non è stata più rinnovata, per cui tutti i server (perchè a livello browser web e mobile non è cambiato nulla) devono revocare il certificato altrimenti otterranno sempre l’errore:

verify error:num=10:certificate has expired

Rimuovendo la entry ormai expired, i sistemi Linux provvederanno a rigenerare la chain dei certificati SSL utilizzando USERTrust RSA Certification Authority che è la nuova CA che sostituisce la vecchia ormai scaduta.

Vediamo come fare (testato su s.o. Debian):

Modificare il file: /etc/ca-certificates.conf come segue:

!mozilla/AddTrust_External_Root.crt

Ho aggiunto un ! alla riga mozilla/AddTrust_External_Root.crt

Fatto questo basta digitare da linea di comando:

update-ca-certificates

Enjoy!

The post Fix AddTrust External Root CA SSL scaduto appeared first on paolodaniele.it - linux & networking.

Questo non è solo un sistema di videoconferenza, ma permette di gestire anche la condivisione del desktop e la modalità di presentazione oltre all’editing multiplo di documenti tramite Etherpad.

Il sistema funziona direttamente dal loro sito internet, oppure, per chi è nel nostro settore, è possibile fornirlo in maniera self-hosted con pochi singoli passaggi.

Come sempre le mie prove sono fatte su distribuzione Debian (in questo caso ho usato la Stretch 9.9) ma è compatibile anche con le ultime versioni di Debian e Ubuntu. Vediamo come installare:

Source code

echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
 
wget -qO -  https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
 
apt-get install apt-transport-https
 
apt-get update

Aggiunto il repository di jitsi procediamo con l’installazione:

Source code

apt-get -y install jitsi-meet

In fase di installazione è fondamentale specificare un fqdn (es. conferenza.paolodaniele.it) che dovrà essere configurato su un DNS e risolvibile perchè Jitsi funziona su piattaforma HTTPS per cui dovremo munirci anche di Certificato SSL(vi spiego dopo come fare)

Finita l’installazione bisogna configurare la parte relativa al certificato SSL per cui basta semplicemente lanciare lo script:

Source code

/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

Specificando il nome inserito in fase di installazione. Una volta finito eseguiamo l’import come indicato (usate come password del keystore changeit )

Manca solo l’ultimo passaggio (lo può evitare chi ha installato Jitsi su una macchina non dietro NAT). Bisogna aggiungere al file /etc/jitsi/videobridge/sip-communicator.properties le seguenti stringhe:

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=xxx.xxx.xxx.xxx
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=yyy.yyy.yyy.yyy

Dove xxx.xxx.xxx.xxx è l’ip locale della vm con Jitsi mentre yyy.yyy.yyy.yyy è l’ip pubblico della vostra connessione.

Finito! Adesso possiamo collegarci su https://fqdn/ e avviare la nuova conferenza.

Vi ricordo che sono disponibili anche le APP per Android e iOS:

The post Jitsi Meet – Videoconferenze Open Source appeared first on paolodaniele.it - linux & networking.