We had a weird problem when moving a WordPress website for a customer: after DUMPing it out of MySQL, we noted that the wp_options table had a problem, namely the table had no primary key and no index on the option_name field. We noted that because the WordPress website, once moved, looked akward and wrong, missing some key pieces and it also seemed to use settings that were old. The reason was that, with primary key missing, lots of duplicate records were stored inside the table and I’m pretty sure it was not what the website was meant to do. Field option_id was set to 0 in most cases when it should have been an auto-incremented integer plus it seemed that the website was not updating settings, rather it was storing a new copy of them each time.

The akward look was probably due to WordPress not being able to load-up the most recent settings but the weird thing was that it was working like a charm on its existing server. However, we noticed that the source server was running MySQL 5.1 while the destination was instead running MySQL 5.7. MySQL is that weird beast where everything can happen but anyway that 5.1 version was really really old. I would expect such things not to happen in an enterprise world (never had such problems with SQL Server) but…

The problem

So the first problem we had to solve was re-enabling primary key for field option_id and its indices but we couldn’t add a primary key on that field since thousands of record were using the same key (zero) so we had to find a way to update them with a unique value. The best solution would be to have consecutive integers though that wouldn’t ensure that we are restoring the right order. But I’m afraid there’s no real way to be sure about that. However, when enumerating records one might assume that the table scan would populate results from the oldest to the newest. Not sure about this but we might try.

So we basically developed a stored procedure that would scan that table and update each record to set a new option_id. One of the key problems with this is that you need to perform only an update at a time because you cannot use any relevant key to uniquely get the record given that option_id is zero. Other fields might be the same for multiple records so for example if we try to select records based on option_name we might have multiple records update with the same option_id and we wouldn’t solve our problems.

We might just hope that we’re lucky enough so that scanning for zero keys and updating just a single record would just update in the same order. Anyway, the key to change the table design is to have different keys, it is not strictly necessary to have the same order though quirks might happen if we don’t do that. The real important thing is to ensure we won’t [...]

Sviluppando una applicazione per Azure Service Fabric e aggiungendo una libreria .NET Standard al progetto ci si potrebbe imbattere in una serie di warning di Visual Studio come questo

Warning MSB3270 There was a mismatch between the processor architecture of the project being built “MSIL” and the processor architecture of the reference “C:\[…]”, “AMD64”. This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

Si tratta di un warning che indica che l’architettura selezionata per la CPU non è l’unica supportata da Azure Service Fabric e cioè x64. Probabilmente l’impostazione è AnyCPU e la libreria funzionerà correttamente ma per fare sparire i warning è sufficiente modificare il target di compilazione nell’apposita sezione Build di Visual Studio:

oppure impostare l’architettura target direttamente nel file .csproj del progetto:

<PropertyGroup> <TargetFramework>netcoreapp2.0</TargetFramework> <PlatformTarget>x64</PlatformTarget> <RootNamespace>Microsoft.*.Tests</RootNamespace> </PropertyGroup>

E’ sufficiente salvare il file ed effettuare una nuova compilazione : non si dovrebbero visualizzare altri warning.

Ovviamente bisogna ricordare che questa modifica renderà inutilizzabile la libreria nel contesto di una applicazione a 32bit.

Qualche giorno fa Microsoft ha presentato il suo nuovo sistema operativo progettato per i dispositivi IoT: Azure Sphere OS. Il nuovo sistema operativo ha come obiettivo quello di fornire una piattaforma sicura-per-default per la costruzione di servizi IoT e superare i problemi che hanno reso i dispositivi IoT così sensibili anche ad attacchi di tipo non sofisticato tanto da consentire ad organizzazioni malevole la creazione di botnet o al possibilità di compromettere la privacy degli utenti.

Il nuovo sistema operativo

Azure Sphere è una soluzione più complessa che consente la creazione di una piattaforma per l’IoT ed include anche microcontroller personalizzati che implementano le 7 regole per la sicurezza dell’IoT stabilite da Microsoft, ed un servizio basato su Azure, la piattaforma cloud di Microsoft, che si occupa di verificare lo stato di ogni dispositivo e acquisire ogni errore o possibile compromissione. Questo servizio fornirà anche gli aggiornamenti per il sistema operativo di ogni dispositivo ed anche modalità di recupero di dispositivi che non stessero funzionando correttamente.

Considerazioni

Molti utenti su Internet hanno posto l’accento sul fatto che Azure Sphere OS fosse basato su un kernel Linux modificato ma la soluzione di Microsoft è ben più complicata del solo sistema operativo. Sebbene qualcuno sia rimasto sorpreso dal fatto che Microsoft sta sostanzialmente producendo una propria distribuzione Linux, anche se questa non è certamente la prima volta che l’azienda di Redmond distribuisce una propria versione di Unix se si ricordano i vecchi tempi di Xenix, ma ci sono cose più interessanti nell’offerta di Azure Sphere del solo kernel usato per il sistema operativo.

E’ sicuramente interessante che Microsoft abbia pensato che Windows fosse troppo pesante per girare su un microcontroller e che abbia deciso di passare ad una soluzione basata su Linux. Alcuni pensano che Microsoft non sia riuscita a produrre una versione di Windows sufficientemente leggera ma io credo che l’azienda statunitense abbia deciso di scegliere Linux per ragioni più semplici: per guadagnare sufficiente fiducia e spazio nel settore dell’IoT, Microsoft doveva usare un sistema open-source e non penso proprio che volessero fornire il codice di una versione di Windows, sebbene pesantemente modificata per girare su un microcontroller. Allo stesso modo, sarebbe stato difficile portare molti partner dalla propria parte con una versione commerciale di un sistema operativo, considerando che molti di questi già usano probabilmente distribuzioni Linux gratuite e leggere, progettate ad hoc.

Inoltre, da quando ha attivato Azure, lo scopo di Microsoft è diventato più quello di fornire servizi che non quello di vendere software e per questa ragione oggi Microsoft rilascia sostanzialmente software che consenta l’adozione di Azure, qualunque sia la sua origine. Non è sorprendente quindi che per tutte queste ragioni abbia deciso di non reinventare la ruota e di usare una versione molto personalizzata di un ambiente Linux, estendendolo con “funzionalità di sicurezza ispirate da Windows”. Microsoft inoltre ha usato chip personalizzati per anni nelle proprie console Xbox.

Sarebbe stato difficile portare molti partner dalla propria parte con una versione commerciale di un sistema operativo, considerando che molti di questi già [...]

Def

Già dal 2012, con l’introduzione di Windows Server 2012, Microsoft ha presentato ReFS (Resilient File System), un nuovo file system per gli ambienti Windows progettato per i workload moderni e, idealmente, per sostituire NTFS appena possibile. Le prime versioni di ReFS non brillavano per velocità ma con Windows Server 2016 ReFS è diventato il file system raccomandato per workload importanti come i cluster di storage S2D o per le infrastrutture iperconvergenti basate su Hyper-V, promuovendolo ormai senza riserve all’uso in produzione.

Nel mondo di Windows Server è certamente inusuale discutere di file-system alternativi a NTFS, discussioni più comuni nel mondo Linux nel quale le alternative sono numerose, ma se Microsoft ha deciso di introdurre una alternativa a NTFS lo ha fatto probabilmente per superare le limitazioni di una tecnologia disegnata tantissimi anni fa

ReFS include novità come l’introduzione dei B+ trees per incrementare le prestazioni, una tecnologia di block cloning che riduce la necessità di trasferire i dati da una parte all’altra del disco implementando l’operazione come una modifica di puntatori che possono essere aggiornati con pochissimo I/O e lo sparse VDL (Valid Data Length) che può inizializzare in modo super-veloce i nuovi file e che rende quindi la creazione di file molto grandi una operazione che dura pochissimi secondi. Accanto a questo, la dimensione massima di ogni volume passa a 1 yottabyte, cioè un miliardo di terabyte, garantendo il supporto per dati di dimensioni difficilmente immaginabili quando il vecchio NTFS fu progettato e proiettando ReFS nell’era del cloud.

Ci sono però 4 funzionalità killer che consentono al nuovo file system di fare da subito la differenza anche quando non si abbiano necessità particolari come l’implementazione di cluster di storage o di virtualizzazione o sistemi complessi. Alcune di queste non sono novità assolute ma richiedevano controller hardware per essere implementate mentre ReFS è un modulo completamente software che non usa i controller RAID hardware.

Funzionalità #1: chkdsk senza downtime Con l’avvento del cloud i workload sono diventati ancora più complessi e la mole di dati da gestire è aumentata a dismisura. In passato il danneggiamento di un file system richiedeva l’uso di chkdsk ma, soprattutto, la sospensione delle attività del volume per la correzione degli errori. L’unità doveva essere messa offline e verificata, una operazione che poteva durare anche decine di ore per volumi molto grandi e questo spesso incoraggiava e creare volumi più piccoli per rendere questi tempi accettabili.

Nell’era del cloud la sospensione dell’attività di un volume, e quindi l’indisponibilità dei relativi dati, per ore non è più accettabile. ReFS non ha quindi più bisogno di chkdsk e nemmeno di sospendere l’attività del volume perché il file system può correggere (se possibile) i problemi in modo automatico e, nei casi in cui la correzione non sia possibile, può rimuovere le aree danneggiate dalla gestione del volume senza andare ad intaccare gli altri dati.

Perchè è importante Chiunque si sia trovato davanti alla necessità di effettuare un chkdsk di un volume, magari a causa di un file danneggiato che non poteva essere rimosso nè rinominato, e abbia [...]