SegmentSmack: la rete del Kernel Linux è esposta ad attacchi DDOS

Facebooktwittergoogle_plusredditlinkedin

Come spiega questo articolo di Red Hat il Kernel Linux soffre di una falla che è stata battezzata SegmentSmack e riguarda la gestione di pacchetti TCP confezionati a regola per provocare denial of service.

A scoprire il problema, come spiega ZDNet, è stata la sezione CERT/CC della Carnegie Mellon University la quale ha fornito anche la lista delle implementazioni TCP che soffrono del problema e come appare chiaro… Non si salva praticamente nessuno.

Come specifica ZDNet:

But, given the widespread use of Linux, the bug could affect every vendor from Amazon and Apple through to Ubuntu and ZyXEL.

Data la grande diffusione di Linux il bug potrebbe affliggere ogni vendor, da Amazon ad Apple fino ad Ubuntu e ZyXEL.

Il motivo per cui tutto esplode è presto detto: la CPU viene saturata da queste chiamate TCP. Se questo è il principio stesso di DOS (Denial Of Service), quello che pare peggio in questa vulnerabilità è che per produrre il risultato non è necessario avere reti coordinate o grossa banda: a chi coordina l’attacco basta servirsi di quanto viene definito come “a relatively small bandwidth of the incoming network traffic“.

Workaround e rimedi? Al momento, nessuno. Prepariamoci quindi a seguiremo l’evoluzione di questa nuova con il consueto entusiasmo!

Un Leader non è per sempre… meglio non essere Chief di se stessi

Facebooktwittergoogle_plusredditlinkedin

Devo ammetterlo: non riesco a trattenermi dal sospirare ogni qual volta, in una organizzazione che si ispira all’Agile, incontro qualcuno che aggiunge ai ruoli specifici il suffisso “Chief”, trasformando di fatto quel ruolo in una posizione di implicito comando.
Se ho la fortuna di lavorare con persone che amano mettersi in gioco, e sono predisposte nello sfruttare l’ironia come strumento di crescita, spesso scherzo evidenziando come “Chief” mi ricordi il noto detersivo,

cif spruzzatore

e di come, tale suffisso, potrebbe indicare, in chiave Lean (DevOps), una persona che ispirandosi alle 5S e al concetto di Servant Leader, si occupi di pulire la scrivania dei propri colleghi per aiutarli a migliorare la propria organizzazione locale. Di certo non è il “capo”!

poster 5s leanproducts

Le 5S di Lean

Al di la del “suffisso” (che potrebbe essere anche “chief”, vista l’implicita accettazione che ormai gli si associa), è innegabile che una visione complessiva di un’azienda in chiave Lean/Agile richieda l’aggiunta di diversi ruoli di coordinamento, ma la loro “istituzione”, se avviene a freddo e senza coinvolgimento dal basso, rischia di trasformarsi in una nuova piramide organizzativain cui c’è un “capo” che da degli “ordini” espliciti ai subalterni, piuttosto che un Leaderin grado di ascoltare, risolvere le problematiche e guidare, quando necessario, le Persone con autorevolezza e raramente (se dicessi “mai” sarei poco realista) con autorità.

La questione, chiaramente, è riuscire a coltivare delle Persone che sviluppino le caratteristiche primarie di un Leader, riassunte nell’esplicita infografica di Alessandro Ferrari, andando al di là del titolo assegnato e dell’atteggiamento di aver raggiunto una “posizione” di comando sugli altri.

leader infografica

Un’azienda che ha la bravura, e un pizzico di fortuna, di far crescere i propri Leader, non ha bisogno di assegnargli titoli che richiamino il “comando”, perché queste Persone sono implicitamente riconosciute al suo interno come “trascinatori”, contemplando il fatto che ogni membro dell’organizzazione può diventare Leader in qualsiasi momento, catalizzando l’attenzione dei propri colleghi.  

Ciò, ovviamente, implica che un “Leader non è per sempre” solo perché è un “chief”, ma deve guadagnarsi tale riconoscimento giornalmente sul campo per non trasformarsi, nella migliore delle ipotesi, in “chief di se stessi”.

Stay tuned J

Micro Focus VM Explorer 7.1 con supporto per vSphere 6.7

Facebooktwittergoogle_plusredditlinkedin

Micro Focus VM Explorer 7.1 con supporto per vSphere 6.7

vm-explorer-7-1-vsphere-6-7-support-01

Micro Focus ha recentemente rilasciato il nuovo VM Explorer 7.1, una soluzione di backup a costi contenuti per la protezione degli ambienti virtuali VMware vSphere e Hyper-V.

Micro Focus VM Explorer (precedentemente Trilead ed HPE) fornisce le funzioni necessarie per effettuare backup e repliche delle virtual machines in piattaforme cloud differenti come Amazon S3, Microsoft Azure, Rackspace ed OpenStack senza un gateway intermediario. VM Explorer è un valido prodotto adatto per business medio/piccoli ed è fornito di un’interfaccia web molto intuitiva che rende la gestione del software molto semplice.

 

Le novità nella versione 7.1

Supporto per VMware vSphere 6.7

La versione 7.1 introduce il pieno supporto per vSphere 6.7 permettendo la protezione delle virtual machine che girano sull’ultima release di VMware. Il VMware Virtual Disk Development Kit (VDDK) versione 6.7 deve essere installato per abilitare il supporto per i backup incrementali.

vm-explorer-7-1-vsphere-6-7-support-02

 

Supporto per lo storage HPE 3PAR 3.3.1

Micro Focus VM Explorer 7.1 ora supporta l’ultima versione 3.3.1 dello storage HPE 3PAR.

vm-explorer-7-1-vsphere-6-7-support-03

 

Risoluzione bug

La versione 7.1 risolve la problematica dell’operazione di browsing degli oggetti del database di Microsoft Exchange permettendo ora una lettura degli oggetti in maniera costante.

vm-explorer-7-1-vsphere-6-7-support-04

 

Aggiornamento di VM Explorer alla versione 7.1

Scaricare dal sito web Micro Focus l’ultima versione di VM Explorer ed eseguire l’installer. Accettare l’EULA e cliccare su Install per avviare il wizard.

vm-explorer-7-1-vsphere-6-7-support-05

Cliccare Next per procedere con l’installazione.

vm-explorer-7-1-vsphere-6-7-support-06

Lasciare la locazione di default e cliccare su Next.

vm-explorer-7-1-vsphere-6-7-support-07

Cliccare Install per avviare l’installazione.

vm-explorer-7-1-vsphere-6-7-support-08

Il software viene installato nel sistema.

vm-explorer-7-1-vsphere-6-7-support-09

Quando l’operazione di installazione viene correttamente completata, cliccare su Finish per uscire dal wizard ed avviare il software.

vm-explorer-7-1-vsphere-6-7-support-10

 

Aggiornare il VDDK

Quando VM Explorer viene eseguito dopo l’installazione/aggiornamento, è richiesto l’aggiornamento del VDDK per permettere l’esecuzione dei backup incrementali. Cliccare su Install/initialize VD Service.

vm-explorer-7-1-vsphere-6-7-support-11

Cliccare sul link per scaricare il VDDK corretto.

vm-explorer-7-1-vsphere-6-7-support-12

Dal sito web VMware, selezionare il VDDK richiesto e cliccare su Download Now.

vm-explorer-7-1-vsphere-6-7-support-13

Cliccare Browse e selezionare il file in formato .zip VDDK appena scaricato.

vm-explorer-7-1-vsphere-6-7-support-14

Una volta selezionato il VDDK richiesto, cliccare Initialize VD Service.

vm-explorer-7-1-vsphere-6-7-support-15

Il VDDK viene correttamente inizializzato. Cliccare su Close per uscire dalla schermata.

vm-explorer-7-1-vsphere-6-7-support-16

Inizializzato il VDDK inserire la chiave della licenza se è stata acquistata, altrimenti cliccare su OK per eseguire il software in modalità trial.

vm-explorer-7-1-vsphere-6-7-support-17

La dashboard di VM Explorer 7.1.

vm-explorer-7-1-vsphere-6-7-support-18

Completata l’installazione, è possibile procedere con la configurazione dei job di backup e replica. Una guida completa per la configurazione di VM Explorer è disponibile per la consultazione.

vm-explorer-7-1-vsphere-6-7-support-19

Micro Focus VM Explorer 7.1 è disponibile per il download come 30-day free trial per provare e testare il prodotto.

signature

Copyright Nolabnoparty. All Rights Reserved.

Le applicazioni Debian arrivano sui Chromebook

Facebooktwittergoogle_plusredditlinkedin

Ad inizio anno avevamo riportato la notizia riguardante Project Crostini, progetto Google volto a dare la possibilità agli utenti di avviare macchine virtuali Linux su ChromeOS.

Nei mesi successivi i produttori di Chromebook, ad esempio Samsung, hanno iniziato ad implementare questa possibilità, seppur su Chromebook di fascia alta.

Qualche settimana fa, XDA Developers ha segnalato che, controllando i commit sul codice di ChromeOS, la prossima feature sarebbe proprio stata il supporto nativo di pacchetti .deb. Ma non si tratta solamente dell’abilitazione di una feature, bensì della possibilità di installare i pacchetti tramite un paio di semplici click che si occuperanno di interagire col terminale, controllare le dipendenze, un vero e proprio installer insomma.

Gabriel Brangers di Chrome Unboxed, sito che si occupa esclusivamente di ChromeOS, ha deciso di testare questa possibilità, test conclusosi con successo.

Oltre a testare, banalmente, l’applicazione Chrome per Linux, ha pensato di provare qualcosa di più corposo, come Visual Studio Code, anche quest’ultimo perfettamente up and running in no time.

Project Crostini per ora è stato testato sul canale di sviluppo di ChromeOS ed è attivabile semplicemente tramite un’opzione nelle impostazioni del device.

Che questo possa aiutare la diffusione dei Chromebook (e delle basi di Linux) anche in Italia?

BIOS/UEFI Lenovo più facili da aggiornare grazie ad LVFS

Facebooktwittergoogle_plusredditlinkedin

Ottimo notizie per gli utenti Linux che utilizzano hardware Lenovo!

L’azienda cinese, infatti, è entrata ufficialmente nel LVFS (Linux Vendor Firmware Service) per offrire ai propri utenti Linux la possibilità di aggiornare in maniera semplice il firmware delle proprie macchine, utilizzando fwupd.

fwupd è un demone che gestisce l’installazione degli upgrade del firmare su sistemi  Linux, sviluppato da Richard Hughes a partire dal 2015.

L’annuncio è stato fatto direttamente dallo stesso Hughes sul blog di GNOME che conferma che nelle prossime settimane gli utenti di hardware Lenovo, ThinkPad, ThinkStation e ThinkCenter riceveranno la possibilita di aggiornare i propri firware utilizzando il semplice comando fwupdmgr update.

Ci tiene a specificare che gli aggiornamenti saranno disponibili solo su hardware UEFI recente, dunque vecchie glorie come i Think* di IBM rimarranno come sono. Riuscire a portare Lenovo in LVFS è stato un duro lavoro, tenuto “segreto” (causa embargo) per gran parte del tempo, ma alla fine il tanto impegno è stato ripagato.

Updating the firmware is slightly odd in that it sometimes needs to reboot a few times with some scary-sounding beeps, and on some hardware the first UEFI update you do might look less than beautiful.

Aggiornare il firmware è leggermente strano in quanto dev’essere ravviato piu volte, tra beep che possono suonare spaventosi, e su alcuni hardware, il primo aggiornamento UEFI potrebbe sembrare meno “elegante”.

Hughes non risparmia un appuntino ad HP, grande assente nella lista dei vendor che supportano il fwupd:

If anyone from HP is reading this, you’re now officially late.

Se qualcuno di HP sta leggendo, sappiate che ora siete ufficialmente in ritardo.

In attesa di poter aggiornare il firmware al nostro ThinkPad, qui trovate una lista dei vendor/device presenti in LVFS. Magari avete qualcosa da aggiornare e non lo sapete!

Le novità introdotte in Virtual Machine Manager 1807

Facebooktwittergoogle_plusredditlinkedin

In seguito al primo annuncio della Semi-Annual Channel release di System Center, avvenuto nel mese di febbraio con la versione 1801, nel mese di giugno è stata rilasciata la nuova update release: System Center 1807. In questo articolo saranno approfondite le nuove funzionalità introdotte in System Center Virtual Machine Manager (SCVMM) dall’update release 1807.

Networking

Informazioni relative alla rete fisica

SCVMM 1807 ha introdotto un importante miglioramento in ambito network. Infatti, utilizzando il Link Layer Discovery Protocol (LLDP), SCVMM è in grado di fornire informazioni per quanto riguarda la connettività alla rete fisica degli host Hyper-V. Questi i dettagli che SCVMM 1807 è in grado di recuperare:

  • Chassis ID: Switch chassis ID
  • Port ID: Porta dello Switch alla quale la NIC è connessa
  • Port Description: Dettagli relative alla porta, come ad esempio il Type
  • System Name Manufacturer: Manufacturer e dettagli sulla versione Software
  • System Description
  • Available Capabilities: Funzionalità disponibili del sistema (come ad esempio switching, routing)
  • Enabled Capabilities: Funzionalità abilitate sul sistema (come ad esempio switching, routing)
  • VLAN ID: Virtual LAN identifier
  • Management Address: Indirizzo IP di management

La consultazione di queste informazioni può avvenire tramite Powershell oppure accedendo alla console di SCVMM: View > Host > Properties > Hardware Configuration > Network adapter.

Figura 1 – Informazioni fornite da SCVMM 1807 in merito alla connettività fisica degli host Hyper-V

Questi dettagli risultano molto utili per avere visibilità sulla rete fisica e per facilitare le operazioni di troubleshooting. Tali informazioni saranno rese disponibili per gli host Hyper-V che rispettano i seguenti requisiti:

  • Sistema operativo Windows Server 2016 o successivo.
  • Feature DataCenterBridging e DataCenterBridging-LLDP-Tools abilitate.

Conversione SET in Logical Switch

SCVMM 1807 consente di convertire un Virtual Switch di Hyper-V, creato nella modalità Switch Embedded Teaming (SET), in un logical switch, utilizzando direttamente la console di SCVMM. Nelle precedenti versioni di SCVMM tale operazione era fattibile solamente tramite comandi PowerShell. Questa conversione può risultare utile per generare un Logical Switch, utilizzabile come template su differenti host Hyper-V gestiti da SCVMM.  Per maggiori informazioni sui Switch Embedded Teaming (SET) vi invito a consultare l’articolo Windows Server 2016: La nuova modalità di creazione dei Virtual Switch in Hyper-V

Supporto per host VMware ESXi v6.5

SCVMM 1807 ha introdotto il supporto di host VMware ESXi v6.5 all’interno della propria fabric. Per quella che è la mia esperienza, anche in ambienti costituiti da più hypervisors, difficilmente si utilizza SCVMM per la gestione di host VMware. Tale supporto è però importante in quanto introduce la possibilità di convertire VMs ospitate su host VMWare ESXi 6.5 in VMs di Hyper-v.

 

Storage

Supporto per la selezione del CSV da utilizzare durante l’aggiunta di un nuovo disco

SCVMM 1807 consente di specificare, durante l’aggiunta di un nuovo disco virtuale a una VM esistente, in quale cluster shared volumes (CSV) posizionarlo. Nelle precedenti release di VMM non veniva fornita questa possibilità e i nuovi dischi virtuali di default venivano posizionati sullo stesso CSV dove erano presenti i dischi già associati alla macchina virtuale. In alcune circostanze, come ad esempio in presenza di CSV con poco spazio libero a disposizione, questo comportamento poteva risultare non adeguato e poco flessibile.

Figura 2 – Aggiunta di un nuovo disco a una VM selezionando su quale CSV posizionarlo

Supporto per l’update di cluster Storage Spaces Direct (S2D)

In Virtual Machine Manager 2016 è presente il supporto per effettuare il deployment di cluster Storage Spaces Direct (S2D). Con SCVMM 1807 è stata introdotta anche la possibilità di fare patching e update dei nodi di cluster Storage Spaces Direct, orchestrando l’intero processo di update, che sfrutterà le baseline configurate in Windows Server Update Services (WSUS). Questa funzionalità consente di gestire in modo più efficace l’ambiente Storage Spaces Direct, punto cardine del Software Defined Storage di casa Microsoft, che porta al raggiungimento del Software Defined Data Center.

 

Statement di supporto

Supporto per SQL Server 2017

In SCVMM 1807 è stato introdotto il supporto per SQL Server 2017 per ospitare il relativo database. Questo consente di effettuare l’upgrade da SQL Server 2016 a SQL Server 2017.

 

Conclusioni

L’update release 1807 introduce in Virtual Machine Manager diverse novità che lo arricchiscono notevolmente in termini di funzionalità. Inoltre, questo aggiornamento risolve anche una serie di problematiche riportate nella documentazione ufficiale Microsoft. Si consiglia quindi di valutare un aggiornamento delle implementazioni di Virtual Machine Manager, per avere una maggiore stabilità e per poter usufruire delle nuove features introdotte. Si ricorda che le release appartenenti al Semi-Annual Channel hanno un periodo di supporto di 18 mesi.

Per provare System Center Virtual Machine Manager è necessario accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

OpenShift Origin cambia nome in OKD con la versione 3.10

Facebooktwittergoogle_plusredditlinkedin

Grandi novità alle porte per la versione community della blasonata piattaforma per container di Red Hat, OpenShift. Infatti con la versione 3.10 di OpenShift Origin il progetto cambia nome, diventando OKD.

Sul blog del progetto la scelta viene così motivata:

… to better represent our project as a distribution of Kubernetes, align our terminology with the larger cloud-native community naming conventions, and clarifies how this upstream project functions within the Red Hat OpenShift product line

Per meglio rappresentare il nostro progetto come una distribuzione di Kubernetes, per allineare la nostra terminologia con le naming convention utilizzate dalla maggioranza dei progetti community cloud-nativi e chiarire come questo progetto upstream si relaziona all’interno della linea di prodotti Red Hat OpenShift.

Quindi un nuovo nome, un nuovo sito, https://okd.io/ ed un nuovo logo a partire dalla versione attualmente disponibile, la 3.10.

Gli stessi manutentori del progetto si aspettano un poco di confusione all’inizio, ma grandi benefici a tendere in quanto la motivazione principale di questa mossa è proprio garantire la chiarezza e la continuità del progetto, anche perché il codice rimarrà nel repository GitHub openshift/origin pertanto nessuna reale modifica andrà effettuata da parte di chi usualmente collabora con il progetto.

E particolare enfasi è posta in quest’ultimo aspetto nel post:

We are not forsaking our origins.

Non abbandoniamo le nostre origini.

Avanti così quindi!

per

OpenSource Hardware Association revoca il primo certificato

Facebooktwittergoogle_plusredditlinkedin

Sono diversi anni che ormai seguiamo l’evoluzione dell’Open Source Hardware Association e poco meno di un mese fa raccontavamo di come l’associazione avesse creato il certification logo, atto a dimostrare che l’hardware in questione rispettasse i dogmi imposti in fatto di apertura delle specifiche.

Ebbene, in questo articolo apparso sul blog della OSHWA viene raccontato come, per la prima volta nella storia del programma di certificazione Open Source Hardware, sia stata revocata una certificazione precedentemente assegnata.

Il caso riguarda la stampante 3d MOTEDIS XYZ, e la motivazione è la seguente:

…we have been unable to obtain a copy of the documentation to post publicly. Without the documentation, the XYZ is no longer in compliance with the program. Therefore OSWHA revoked the certification.

Non siamo stati in grado di recuperare una copia della documentazione pubblicata pubblicamente. Senza la documentazione, la XYZ non è più conforme al programma. Pertanto OSWHA ha revocato la certificazione.

Nessuna documentazione, nessuna certificazione. Semplicissimo.

Ciò che si sta discutendo ora all’interno dell’associazione è però un altro tema, direttamente collegato a questa vicenda: chi deve mantenere le documentazioni? È giusto che se ne faccia carico OSWHA (con i benefici, ma anche i costi che ne deriverebbero) oppure sono i produttori a doversene fare carico?

Per ora OSWHA ritiene corretto l’approccio decentralizzato, ma la discussione continuerà sul forum dell’associazione.

Staremo a vedere!

Blog italiani (e in italiano) nel mondo IT/ICT