Capita di avere la necessità di cancellare la history dei comandi Powershell inviati con un account. A noi, per esempio, è capitato quando abbiamo dovuto preparare dei template per le virtual machine dei nostri clienti ed era necessario attivare un software prima di completare il template.

Sfortunatamente questa attivazione avveniva per mezzo console e bisogna quindi inserire un comando con il codice di attivazione. Questo faceva si che il codice potesse poi essere visibile per gli utenti che usavano quel template che potevano accedere alla history semplicemente premendo PgUp. Se si cerca una soluzione si scopre che Powershell ha un comando per la cancellazione della history:

Clear-History

Tuttavia non tutti i comandi vengono rimossi. Alcuni vengono rimossi, altri no oppure proprio nessuno. Probabilmente non vengono rimosse le invocazioni di eseguibili e comandi esterni. Ad ogni modo, questo lascia la history, o parte di essa, disponibile per gli altri utenti.

C’è però un comando che consente di visualizzare quale sia il file in cui Powershell memorizza la history dell’utente:

PS C:\Users\Administrator> (Get-PSReadlineOption).HistorySavePath C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

Il file mostrato è quello della history. Basta quindi modificarl e rimuovere le righe che non si vogliono rendere disponibili per gli altri utenti.

Un trucco semplice ma rimane il mistero sul perché esista un comando dedicato che non funziona come ci si aspetterebbe.

Avevamo capito prima di procederre cosa fosse successo alle due macchine ma quella spiegazione è fuori dall’obbiettivo di questo post che si incentra su come poter recuperare velocemente da quella situazione.

Qualche giorno fa abbiamo riscontrato uno strano problema su un paio di server dopo avere aggiornato gli agent di Acronis. La console non consentirva più l’esecuzione del piano di backup, sia in modo automatico che manuale, segnalando che l’agent non era più registrato. Sembrava molto strano visto che avevamo effettuato aggiornamenti degli agent diverse volte in passato senza riscontrare alcun problema ma questa volta gli agent non riuscivano più a registrarsi.

In realtà nello stesso ciclo di aggiornamenti avevamo avuto altri due problemi su macchine Linux ma questi erano spariti riavviando i due server. Inoltre, avevamo notato che i due server che presentavano questo problema erano installazioni di Windows Server Core che ospitavano SQL Server. Abbiamo quindi deciso di registrare nuovamente gli agent manualmente ma sorprendentemente non era possibile perchè l’agent si lamentava del fatto che il certificato dell’endpoint non fosse valido. Anzi, in maniera più specifica, che la Certification Authority fosse sconosciuta.

Quei due server funzionavano correttamente prima dell’aggiornamento e, cosa ancora più strana, sembrava che non fossimo in grado di registrare gli agent nemmeno usando l’endpoint di Acronis invece che il nostro endpoint specifico. Stesso errore. Se era possibile, anche se improbabile, che il nostro endpoint usasse un certificato che causava problemi – anche se funzionava correttamente con le altre macchine e nei browser – non era possibile che ci fosse qualche problema con quello di Acronis.

Aggiornamento autorità di root

L’errore riportato dall’agent era abbastanza indicativo ma noi avevamo problemi a collegarci agli endpoint anche in modo standard, usando per esempio Powershell

Invoke-WebRequest -UseBasicParsing -Uri https://cloud.acronis.com

C’era sicuramente un problema con le connessioni SSL. Anche se PowerShell restituiva un errore generico sull’impossibilità di completare la connessione, l’agent di Acronis riportava un errore di molto più specifico per il quale abbiamo deciso di aggiornare i certificati di root sulla macchina:

md C:\Temp cd C:\Temp # Scarica TUTTI i certificati di root da Windows Update certutil.exe -generateSSTFromWU roots.sst # Importa TUTTI i certificati nello store delle autorità di root $sstContainer = (Get-ChildItem -Path C:\temp\roots.sst) $sstContainer | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root

Dopo aver lanciato questo questi comandi sarà necessario riavviare la macchina per consentirle di ricaricare tutti i certificati.

Problemi di cifratura

Questo non ha risolto il problema di per sè. Quando la macchina è tornata online le connessioni agli endpoint di Acronis continuavano a non riuscire anche se con un errore diverso da parte dell’agent e lo stesso errore da parte di Powershell. Abbiamo quindi deciso di verificare meglio se fosse un problema di cifratura e di forzare le connessioni TLS1.2 in Powershell usando:

# Forza PowerShell ad usare TLS1.2 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Ovviamente devi ricordare di non chiudere la sessione o perderai l’impostazione effettuata e dovrai applicarla di nuovo. Un altro tentativo di connessione ai nostri endpoint e … bingo! Ora tutto funzionava correttamente!

PS C:\temp> Invoke-WebRequest -UseBasicParsing -Uri https://backup.vaisulweb.cloud [...]

La prima scelta che è stato necessario prendere mentre progettavamo il design di Skynet era ovviamente il framework o i framework da usare per lo sviluppo. Le soluzioni sono moltissime e sicuramente ognuno ha delle ragioni specifiche per pensare a questa o quella soluzione in modo da semplificare il lavoro ed ottenere magari una piattaforma aperta che possa includere altre tecnologie o soluzioni. Un esempio tipico è quello di partire da un progetto opensource o magari disegnare un frontend basato su WordPress e sviluppare estensioni e moduli per integrare le funzionalità che servono. Con tutte le tecnologie che esistono, non c’è un modo giusto o sbagliato ma semplicemente una preferenza in base ad alcune valutazioni che si fanno internamente e che dipendono anche dall’esperienza che il team ha acquisito nonché dall’integrazione che è possibile o meno con altre tecnologie che magari sono già presenti in azienda e che si vogliono riutilizzare o estendere.

I requisiti di Skynet

Come sempre, si parte da quelli che sono i requisiti del progetto. Il design di Skynet deve avere alcune caratteristiche che derivano dalla nostra esperienza nell’uso di decine o anche centinaia di tecnologie tra orchestration, pannelli di controllo, sistemi di gestione e così via.

Multipiattaforma

La tecnologia di cui avevamo bisogno doveva essere multipiattaforma in modo da consentire la gestione e soprattutto l’automazione dei sistemi più diffusi e quindi Windows e Linux. L’uso di un framework multipiattaforma doveva consentire anche il riutilizzo massiccio del codice che prevedevamo di scrivere per le decine di componenti che comporranno Skynet.

C’è inoltre da fare una ulteriore divisione all’interno del codice, prevedendo codice applicativo, che sarà indirizzato alle componenti principali, e un layer di interazione con i sistemi da gestire con i quali non sempre la scelta migliore è quella di usare un software ma spesso è più pratico affidarsi alle tecnologie di scripting. Inoltre, un layer di scripting consente – se messo in sicurezza – di prevedere anche un modo veloce per far evolvere singole funzionalità senza costringere al deployment dell’intero software.

Prevalentemente asincrono e durevole

Un sistema di gestione e di orchestrazione come quello che stiamo progettando deve necessariamente prevedere la possibilità di comunicare con diversi moduli che possano trovarsi non solo su sistemi diversi ma addirittura in datacenter diversi e distribuiti geograficamente e persino interagire con sistemi esterni alla nostra infrastruttura. Per la loro stessa natura queste interazioni non possono essere considerate come affidabili o parte di una rete costantemente connessa ma si deve dare per scontato che che questi sistemi possano essere saltuariamente disconnessi, ad esempio a causa di un temporaneo errore di rete, o incapaci di completare le azioni richieste al primo tentativo magari per un sovraccarico dei sistemi coinvolti o un altro problema saltuario.

Per questa ragione il framework che è stato scelto deve avere una forte impronta asincrona e non può essere basato su workflow che si aspettano di completare le operazioni in pochi secondi e senza una logica di retry/fail. Questo significa anche che i workflow che vengono eseguiti devono poter gestire questi possibili errori [...]

Come service provider VaiSulWeb ha sempre gestito al proprio interno un numero di tecnologie molto elevato e ci siamo sempre avvalsi di tanti strumenti, a volte più semplici da integrare, altre volte meno. C’è una tendenza molto diffusa oggi nel delegare ai cloud provider ipermassivi come Microsoft Azure o Amazon AWS la gestione di tante tecnologie, soprattutto quelle più complesse e principalmente da parte dei provider più piccoli. A VaiSulWeb abbiamo sempre gestito le nostre infrastrutture proprietarie e non prevediamo di cambiare questa visione che per noi è strategica tuttavia è cambiato lo scenario anche rispetto a pochissimi mesi fa e se prima veniva considerata probabile una crescita incontrastata dei provider cloud ipermassivi, oggi si ritiene che un approccio ibrido sia quello che verrà scelto dalla maggior parte delle aziende.

VaiSulWeb ha sempre integrato molti strumenti diversi ma la complessità di questi nuovi scenari, nei quali si fondono insieme gestione on-premise e la partnership con molte aziende diverse anche nell’ambito di confini della singola applicazione (si pensi ad esempio ai servizi di AI o cognitivi integrati in applicazioni ospitate all’interno di altre infrastrutture) rende necessaria la creazione di strumenti che non solo consetano di gestire questa complessità ma che rendano possibile anche una personalizzazione di tali strumenti per allinearli con gli obiettivi aziendali. L’ingresso nel mercato dei servizi di aziende che avevano operato nella produzione di software, come Microsoft, ha infatti reso necessario lo sviluppo di strumenti indipendenti che non risentano degli obiettivi – a questo punto spesso conflittuali – tra i service provider come VaiSulWeb e quelli che sono i produttori dei software che abbiamo usato per fornire i nostri servizi ai clienti, ora trasformatisi anch’essi in fornitori di servizi e che, come tali, perseguono i propri obiettivi.

Se fino ad ora VaiSulWeb, come molti altri provider, ha operato spesso integrando le piattaforme di diversi produttori di software, la trasformazione di questi produttori in fornitori di servizi spesso comporta anche un differente approccio verso lo sviluppo di tali software e le loro possibilità di integrazione, con l’obiettivo (legittimo) di favorire i servizi del produttore stesso ma con l’effetto a catena di ridurre la qualità e la semplicità dell’integrazione di tali software in ambienti di service provider diversi. Diventa quindi strategico lo sviluppo di uno strumento completamente indipendente che consenta l’integrazione, l’orchestration, la gestione, il monitoraggio e la personalizzazione di molteplici tecnologie anche per garantire ai nostri clienti la sicurezza di una infrastruttura completamente indipendente e resistente ad eventuali mutamenti di condizioni da parte di fornitori che per buona parte sono oggi anche competitor.

La nuova piattaforma di VaiSulWeb

Per tutte queste ragioni abbiamo deciso quindi di investire nello sviluppo di una piattaforma tecnologica completamente indipendente e abbiamo deciso di procedere ad  uno sviluppo aperto, condividendo le nostre riflessioni, le nostre scelte tecnologiche e spunti che possano magari essere interessanti per altre realtà. Questa sezione di The Server-Side Technology seguirà quindi questo processo. Ad oggi non prevediamo di rilasciare l’intera piattaforma come open-source ma di rendere disponibili singoli elementi che abbiano un potenziale uso [...]

Windows sys admins have long relied on the very wide range of tools that Windows, especially its Server versions, made available to manage the operating system. Unlike many think, such tools were not black boxes but they have been built on APIs that were available to developers, in most cases, so that they could write their own tools and access the very same information that Microsoft tools have been providing and also perform the same actions. But the tools themselves were good enough so that admins have been using them in a way or another, even when implementing their own.

Microsoft also provided Server Manager, a tool that in its latest versions allowed to manage multiple servers at once and provided access to many information and actions to perform on to local or remote servers. It also acted as a container for other administration tools when it didn’t provide the capability to perform actions on its own. At some time, Microsoft probably thought about converting its desktop tools into plugins for the newer versions of Server Manager and also started such work by integrating some of them. That was no easy task because of the wide range of utilities that Microsoft provided over time but the effort made sense.

When Core (or Nano, as of Windows Server 2016) versions of Windows Server were introduced, sys admins had to rely on Powershell to perform the same tasks since no UI was available in Core versions of the OS. Actually, some of them were quickly converting Core versions into Desktop one when they needed to perform extensive maintenance actions, reverting back to Core when done. The reason for that is oh-so-simple: performing complicated tasks using the command line is way less productive than using graphics tools, whatever Linux sys admins would like you to believe. That’s the reason why the button you must pay attention to is red, the button to do a safe action is green and you have a wheelchair icon on a reserved parking instead of printing “This parking space is reserved to people with disabilities so you are forbidden to park here unless you have a disability your own. You will receive a fine if you park here abusively.”. Metaphors. We discovered that our mind is better at metaphors long ago. Well, not all of us. We are still waiting for Linux admins to evolve but we’re confident.

Yesterday Microsoft announced Project “Honolulu”, a new way to manage Windows systems through a new shell, this time a Web-based administration shell. I had the privilege to contribute to the design and testing of the tool and I will try to describe why I loved it and why it can become very relevant for Windows sys admins.

What Honolulu is

Honolulu is a Web-based Server Manager that can be installed on both desktop and server machines and provide access, that is to say “graphical access”, to one or more servers in your environment. The first thing to notice is that Honolulu doesn’t require anything “more” [...]