Archivi autore: Gianluigi

MSSQL Server 2019 on Docker e Full Text Search

Per impostazione predefinita, l’immagine contenuta nel container MSSQL Server 2019 non contiene il servizio Full Text Search. Per poter utilizzare questo servizio bisogna creare un’immagine personalizzata. Per fortuna ci sono immagini già preparate per MSSQL 2019, una di queste è presente qui:

https://schwabencode.com/blog/2019/10/27/MSSQL-Server-2017-Docker-Full-Text-Search

Utilizzando come base di partenza lo script presente al link, basta cambiare semplicemente 2017 in 2019 per avere uno script valido da salvare in un file DOCKERFILE.

## Source: https://github.com/Microsoft/mssql-docker/blob/master/linux/preview/examples/mssql-agent-fts-ha-tools/Dockerfile

# mssql-agent-fts-ha-tools
# Maintainers: Microsoft Corporation (twright-msft on GitHub)
# GitRepo: https://github.com/Microsoft/mssql-docker

# Base OS layer: Latest Ubuntu LTS
FROM ubuntu:16.04

# Install prerequistes since it is needed to get repo config for SQL server
RUN export DEBIAN_FRONTEND=noninteractive && \
    apt-get update && \
    apt-get install -yq curl apt-transport-https && \
    # Get official Microsoft repository configuration
    curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - && \
    curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2019.list | tee /etc/apt/sources.list.d/mssql-server.list && \
    apt-get update && \
    # Install SQL Server from apt
    apt-get install -y mssql-server && \
    # Install optional packages
    apt-get install -y mssql-server-ha && \
    apt-get install -y mssql-server-fts && \
    # Cleanup the Dockerfile
    apt-get clean && \
    rm -rf /var/lib/apt/lists

# Run SQL Server process
CMD /opt/mssql/bin/sqlservr

Basta creare l’immagine con il comando:

docker build -t gianluigisellitto/mssql-fts:2019-ubuntu .

L#importante è di ricordare quando si avvia il container di fornire il parametro “MSSQL_AGENT_ENABLED=True”, altrimenti l’agent non viene avviato.

Docker e WSL2

Uno dei framework più importanti che si sta imponendo per la distribuzione delle applicazioni è senza dubbio Docker.

Docker, in poche parole, rappresenta l’evoluzione delle Virtual Machine per la distribuzione delle applicazioni in maniera semplice è isolata. Fino a pochi anni fa, il modo più semplice per integrare su una sola macchina più applicazioni era quello di inserire ogni applicazione in una macchina virtuale, in modo da controllare in maniera precisa le interazioni tra le varie applicazioni. Il problema di questo approccio è dato dal fatto di dover avere in ogni macchina virtuale una copia del sistema operativo (SO) da utilizzare per l’applicazione, anche se ridotto all’osso, anche se il semplice Kernel. Con Docker, invece, le applicazioni vengono distribuite in “Containers” che possono essere viste come macchine virtuali senza SO. I servizi necessari a far girare effettivamente l’applicazione sono forniti dal Kernel della macchina host. Il Container Docker in pratica è costituito dall’applicazione vera e propria, più gli strati dell’SO originale per il quale l’applicazione è destinata, per far sembrare all’applicazione di avere a disposizione i servizi dell’SO.

Originariamente i Containers furono sviluppati per Linux, cioè Linux come SO guest. Poi venne la versione per Windows. Le versioni avanzate dei server Docker, possono far girare indifferentemente Containers Linux e Windows. La versione libera Docker per Windows, dedicata agli sviluppatori, permette di sviluppare container Linux o container Windows, ma non allo stesso momento, bisogna passare da un ambiente all’altro. La cosa positiva che una volta avviato un container, ad esempio Linux, si può passare allo sviluppo/debug di un container Windows senza interrompere l’esecuzione del container Linux già avviato. Ad esempio si può avviare un container Linux con SQL Server 2019, per poi passare all’assemblamento di un container Windows di una app che utilizza quel server.

Su Windows, per eseguire i container Linux, viene avviata una VM Linux, che fa da ponte. Una volta era una macchina VirtualBox, ora è una macchina Hyper-V. Ma adesso grazie al rilascio di WSL (Windows Subsystem for Linux) e con il prossimo rilascio di WSL 2, Docker per Windows nella versione beta offre la possibilità di utilizzare WSL per eseguire i container Linux. I risultati sembrano essere incoraggianti, i miglioramenti di velocità si notano a occhio nudo, il container Linux SQL Server 2019 ci mette pochi istanti a partire, contro qualche secondo della macchina Hyper-V. Di contro è più complicato, al momento, settare da Docker le risorse da dedicare al sottosistema Linux, bisogna ricorrere al comando WSL e al file di configurazione .wslconfig.

WSL2 per ora è in fase di test nel Fast ring, ed in fase di installazione di Docker EDGE ci potrebbero essere dei problemi, come descritto qui.

Docker 2.1.7.0 fail to start

Docker on Windows use Hyper-v virtual machine to run Linux Container. But with the new version of Windows there is the WSL (Windows subsystem for Linux). The new version WSL2 currently in beta, is used by the Edge version of Docker to run Linux Container without the virtual machine. This feature is an optional settings from version 2.1.6.0.

But on my development machine, the Edge installer suffer of the same problem of the stable one. The installation seems to complete without problem, but Docker do not works. The problem is the same: wrong version o Syste.Net.http, the installer ends with no problem, the Docker service seems to start but it is in not working state. Also the Doker Desktop client do not start. To solve the problem the solution is the same of the linked article, edit the config file for the service and Docker Desktop. After that you can anjoy Docker on WSL 2.

Docker and System.Net.Http

On my developing machine the installer for Docker for Windows hangs forever. The problem occur from stable version 2.1.0.1 to 2.1.0.5. After a little inspection, i discovered that the installer is waiting for the “Docker Desktop Service”. The log for the service show the error:

…cannot load assembly ‘System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ …

For the library System.Net.Http there are some version problem. If you take this library from Net Framework 4.6.2 (the framework used by Docker for Windows) this library have the Version=4.2.0.0. If you get this library from Nuget you get a library with version <4.2.0.0 (see this for details). So how to solve?

While the installer still hang, waiting for the service to start, follow this steps:

  • go to C:\Program Files\Docker\Docker
  • open the file com.docker.service.config
  • comment out or delete the part:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">      <dependentAssembly>        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />      </dependentAssembly>    </assemblyBinding>

  • go to Service Console and start the service “com.docker.service” or “Docker Desktop Service” (the name depend on version)

When the service start the installer complete succesfully. Close the installer. The Docker Service Client also do not start for the same reason, the solution is the same, comment out the same binding redirect in the file Docker Desktop.exe.config.

Docker and network on Windows

Developing and testing Docker container can be problematic on Windows 10 if you have different type of container. Suppose that you have one Linux container and one Windows Container that need to communicate, the simple solution to communicate through host ip address (Docker bridge actually is not working in mixed mode); but if your IP is not stable (you move on different network)? Do you need to change the hostname/IP in every configuration file. But there is a more simple solution: Microsoft loopback adatper. If you install this virtual adapter and assign a fixed IP, containers can communicate using this IP, that not change if you change network. Simple solution for speed-up developing process.

FileBeat, IIS LOG e X-Forwarded-For


Warning: A non-numeric value encountered in /web/htdocs/gianluigi.sellitto.it/home/wp-content/plugins/gutenberg/lib/block-supports/index.php on line 66

FileBeat è il ben noto log shipper di Elasticsearch per caricare log dalle più disparate fonti. Uno dei moduli di FileBeat serve a caricare i file di log di IIS. Bisogna ricordare però che i file di log di IIS possono avere un numero variabile di campi, liberamente selezionabili, oltre a poter aggiungere dei campi custom. Per poter far digerire correttamente i vostri file di log bisogna modificare il file:

%ProgramFiles%\filebeat\module\iis\access\ingest\default.json

Questo file contiene la sezione grok:

"grok": {                

"field": "message",                

"patterns": [                    

"%{TIMESTAMP_ISO8601:iis.access.time} %{IPORHOST:destination.address} %{WORD:http.request.method} %{NOTSPACE:url.path} %{NOTSPACE:url.query} %{NUMBER:destination.port:long} %{NOTSPACE:user.name} %{IPORHOST:source.address} %{NOTSPACE:user_agent.original} %{NOTSPACE:http.request.referrer} %{NUMBER:http.response.status_code:long} %{NUMBER:iis.access.sub_status:long} %{NUMBER:iis.access.win32_status:long} %{NUMBER:temp.duration:long}"                       

],

"ignore_missing": true            

}

Il campo patterns è un array di stringhe, ogni riga indica un paeern diverso di possibile interpretazione delle collonne del file di log verso le colonne interne di Elsticsearch. Nel caso evidenziato una riga del file di log inizia con la data e l’ora dell’evento, prosegue con l’IP del server di destinazione e così via. Per cui uno di questi pattern deve coincidere con il pattern del vostro file di log.

X-Forwarded-For

Il campo X-Forwarded-For è il campo (oppure True-Client-IP ) viene utilizzato dai vari reverse-proxy o load balancer per trasmettere l’ip originale dal quale viene la richiesta, infatti in questa situazione il campo c-ip di IIS contiene l’IP del reverse proxy. Per inserire il valore del X-Forwarded-For nel file di log bisogna:

Aprire IIS Manager
Espandere il nodo server
Espandere il nodo siti
Cliccare sul proprio sito web
Doppio click su Registrazione
Cliccare su Seleziona campi...
Cliaccare Aggiungi campo... in fondo nella dialog
Mettere X-Forwarded-For sia in Nome campo che in  Origine.
lascaire Intestazione richiesta come Tipo di origine
Cliccare OK nella dialog Aggiungi campo personalizzato
Cliccare OK nella dialog Campi di registrazione
Cliccare Applica sulla destra.

In questo modo IIS preleverà il campo dalle instestazioni delle richieste e lo scriverà nel file di log.

Ritornando al nostro pattern dell’array patterns, bisogna creare un pattern con il campo %{IPORHOST:iis.access.remote_ip}} piazzato nella posizione in cui si trova il campo X-Forwarded-For.

Modifiche su Elasticsearch

Una volta modificato il file %ProgramFiles%\filebeat\module\iis\access\ingest\default.json, bisogna aggiornare la pipeline di ingest sul server. Siccome la pipeline si chiama in modo diverso a seconda della versione di FileBeat, la cosa migliore è eseguire la richiesta (con la consolle di Kibana o con curl)

GET _ingest/pipeline

Vi verrà restituita la lista completa delle pipeline, una di queste sarà del tipo “filebeat-7.4.2-iis-error-default” dove il numero di versione può variare, a questo punto con la richiesta

PUT _ingest/pipeline/filebeat-7.4.2-iis-error-default {contenuto del file default .json}

A questo punto anche Elasticsearch sarà pronto a recepire gli eventi nel formato da voi prescelto.

P.S.

Per testare se il pattern cattura il vostro file di log, c’è il sito http://grokconstructor.appspot.com che permette di testare il tutto prima di installare il tutto.

Internal server error

IISNODE and encryption

IISNODE is a well know IIS extension module for hosting NodeJS application inside IIS. Recently i needed to install a small NodeJS app as submodule of .Net application. The integration between the two app was realized by JSON Web Token. The NodeJS app was installed as virtual application on the same machine. On test machine everything worked fine. On production machine IISNode throws “HTTP Error 500.0 – Internal Server Error”. There was no solution to the problem, until i noticed that the root web.config was encrypted by aspnet_regiis. I discovered that this is a know issue of IISNODE.

So for now is not possible have IISNODE and encrypted web.config on the same web.

Sbloccare la stampa di un file PDF

Molto spesso ci vengono forniti dei file PDF che possono solamente essere letti. Volendo stamparli bisogna conoscere la password. Molti cercano tra diversi servizi online o programmi a pagamento. Ma c’è un semplice programma che può servire al caso:

QPDF http://qpdf.sourceforge.net/

Si tratta tra l’altro di un programmino che si installa semplicemente copiando la cartella in cui è contenuto, per cui si può installare e trasportare dovunque. Una volta installato per togliere la password da un file basta dare il comando:

qpdf.exe --decrypt <percorso al file da sbloccare> <percorso al file di uscita>

Tutto qui.

JSON Web Token and RSA with C#

JWT is a well know open standard to share information among several services in a secure way. Information are signed with some signing key, so information in the payload are protected against tampering.

Most of samples are based on HS256 encryption scheme. With this encryption scheme two service the want to share some token, must share a secret key, for generate and validate token. This option is useful if you want share token between different service of your application. But if you want share information with application from third party or more? You need to share a secret password with every service, a nightmare of (password,service) to remember. But there is a simple solution: RSA private/public key. With RSA encryption, keys came in couple, if you sign with private key, the verification can be done with the public key, or the other way round. In JWT this means that after generating the couple (private key,public key), the private key must be stored in a safe place and can be used to generate every token. The public key can be made public available and used to verify JWT toke integrity. 

Following this sample, i have extended the library to use RS256 signing scheme. The library is complete:

  1. generation of (private key,public key), the private key is stored in a encrypted file with BlowFish cipher. Public key is stored in XML format and PEM format;
  2. Generation of JWT token with username and userid identifier;
  3. verification of token end claims extraction from JWT token;

 The source code for the library is here, is based on Microsoft JWT implementation fo .Net and Net Core.

For an introduction on JWT with Python see here.