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 [...]

While developing an application that will be hosted on Azure Service Fabric and adding a .NET Standard library or project, Visual Studio might display a warning like this one:

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.

Turned out that the problem is that the only supported platform for Azure Service Fabric is x64 so you receive that warning when your target CPU for building is AnyCPU. The library will probably work anyway but to solve that problem you must either choose x64 as a target in the Build section

or set the target processor architecture inside the .csproj file:

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

Save the file and build the library again: you should not see those warnings anymore.

Switching target processor architecture obviously makes that library unusable in 32bit context, something that you should be aware of.

A few days ago Microsoft introduced its new operating system designed for IoT devices: Azure Sphere OS. The new operating system aims at providing a secure-by-default platform to build IoT services and thus avoiding the pitfalls that made such devices so prone even to unsophisticated attacks that rogue organizations use them to build botnets or to compromise users’ privacy.

The new OS

Azure Sphere is just a part of a broader solution to provide a secure platform for IoT that also includes custom microcontrollers that implement Microsoft 7 rules for IoT security and a security service that runs on Azure to verify the status of each device and report any error or possible compromission. That service will also provide updates to the OS and possibly remediation services for misbehaving devices.

Considerations

While many users on the Internet focused on the fact that Azure Sphere OS is based on a modified Linux kernel, Microsoft solution is quite more complicated than that. Many have been surprised by the fact that Microsoft is essentially providing a Linux distribution, though it isn’t the first time that Microsoft is shipping Unix if one remembers Xenix old days, but there are more interesting things about this solution other than the kernel that OS is running.

For sure it is interesting that Microsoft decided that Windows is too heavy to run onto microcontrollers and it resorted to a Linux-based solution. While many speculate about the inability of Microsoft to create a lightweight version of Windows, I think that they choose Linux for a simple reason: to gain some traction into the IoT space they obviously need to open-source the OS and I don’t think that they would be ready to provide an open-source version of Windows, albeit highly customized. At the same time, it would be difficult to push IoT partners into its camp with a closed-source software, given that most of them rely on free and lightweight specialized Linux distributions.

Moreover, since when Azure started, Microsoft became more a services provider rather than a software maker so its main goal is to create software that could be plugged into Azure whatever it is based upon. So no surprises that they decided not to reinvent the wheel by using an highly customized Linux-based environment and extend it with “Windows-inspired security features”. Microsoft also ran custom chips for years in their Xbox consoles.

It would be difficult to push IoT partners into its camp with a closed-source software, given that most of them rely on free and lightweight specialized Linux distributions

What is more interesting is the fact that Microsoft used containers to secure that environment. While for sure Azure Sphere OS has a specialized version of containerization, containers are emerging as a key mechanism to save resources while providing a high degree of security. Microsoft already implemented containers into its Windows Server 2016 and refined the concept to be able to run Linux as a part of Windows and it also provides Linux containers on a Windows machine, thus dramatically improving productivity and [...]

We recently had a problem on a server since one of its services was randomly experiencing spikes in CPU load that required restarting the service. Such event was happening once in a while and only required a restart. While we were tracking the problem down, we needed a temporary solution that didn’t require us to manually restart the service. Luckily Powershell came to the rescue with a simple script:

$interval = 30 #seconds $counterSample = Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval $interval $avgLoad = $counterSample.CounterSamples.CookedValue Write-Output "Average CPU load : $avgLoad"

The tricky thing is that we didn’t want to measure CPU load as an instant value because such service could need to use all available resources for a short period of time so we couldn’t simply check if CPU was running at 80 or 100%. The script above measures average CPU load within a provided interval that has been set to 30 seconds in the sample.

Then, based on $avgLoad value, you could decide how to behave. In our case, we simply restart the service and notify our administrators. We simply scheduled a script like that to run every 5 minutes.

This sample has been taken from the Internet I don’t get credit for it but I hope it could be useful for someone else.

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 [...]