Attenzione alle truffe

commenti Commenti disabilitati su Attenzione alle truffe
di , mercoledì 3 Settembre 2014

Informo i visitatori che ignoti stanno utilizzando i miei dati personali, ottenuti presumibilmente da questo sito Internet, per perpetrare truffe telematiche mediante annunci pubblicati su noti portali di compravendita tra privati.

Rendo noto di non aver MAI pubblicato annunci di vendita per qualsivoglia articolo su tali portali.

Pertanto chiunque si presenti a nome mio, o si spacci per un mio fantomatico socio, per vendere merce con questo sistema sta cercando di truffarvi.

Invito pertanto chiunque sia incorso in annunci di questo genere a non effettuare alcun pagamento e a rivolgersi alle autorità competenti per sporgere denuncia. Invito inoltre a segnalare l’abuso ai gestori dei portali in questione per evitare che altre persone possano essere truffate.

Da parte mia ho già provveduto a sporgere formale denuncia alla sezione della Polizia Postale di Reggio Emilia.

Grazie,

Moris Notari

Repository Git via Https/WebDav con IIS 7.5

commenti Commenti disabilitati su Repository Git via Https/WebDav con IIS 7.5
di , lunedì 20 Agosto 2012

Nei giorni scorsi ho avuto la necessità di ospitare alcuni repostitory Git su un server Windows preso in hosting, generalmente l’accesso ai file contenuti nei repository avviene  mediante il protocollo SSH…purtroppo però Microsoft non integra client e server SSH nei suoi sistemi operativi. Il problema in sè potrebbe essere risolto installando ottimi programmi come: OpenSSH e PuTTY, nel mio caso però volevo lasciare il più possibile integra la configurazione di fabbrica del server quindi ho optato per una soluzione basata sul protocollo WebDAV e comunicazioni protette con HTTPS. Una soluzione di questo genere non richiede l’installazione di software accessori sui client Windows e sui PC dei colleghi che utilizzano MacOS o Linux.

Il processo descritto in questo articolo fa riferimento a Windows Server 2008 R2 versione inglese ma la procedura è sostanzialmente identica per Windows 8 .x o Windows 7 Professional.

Attenzione: utilizzate questa guida SOLO se avete familiarità con gli strumenti di gestione server Windows e IIS e/o SOLO sotto la supervisione di un sistemista Windows con esperienza.

Quello che vi servirà

Tutto quello che vi servirà è il programma d’installazione di Git nella sua declinazione per Windows e, opzionalmente, TortoiseGit per facilitare le operazioni sui vostri repository dai client. Scaricate quindi:

msysGit da: http://code.google.com/p/msysgit/downloads/list?q=full+installer+official+git

e TortoiseGit da: http://code.google.com/p/tortoisegit/downloads/list

 

Come configurare il server

1. Installazione di Git

Questa è la parte più semplice di tutto il processo…utilizzando il programma d’installazione di msysGit installate l’ambiente Git sul Server. Non dovendo lavorare direttamente sui repository l’integrazione con Windows Explorer sul server non interessa molto, la Git Bash fornita nel pacchetto è più che sufficiente:

Opzioni scelte per l'installazione di msysGit

Per quanto riguarda il resto dell’installazione potete mantenere le opzioni suggerite dal programma:

Opzioni d'installazione di msysGit Opzioni d'installazione di msysGit

2. Preparazione del filesystem

Per mantenere la configurazione del server il più pulita possibile potete creare un nuovo gruppo d’utenti chiamato “GIT Users” al quale verranno aggiunti gli utenti che potranno lavorare sui repository. Aprite il “Server Manager” e selezionate “Groups” dalla voce “Local Users and Groups”, quindi create il nuovo gruppo e aggiungete gli utenti membri:

Creazione del gruppo di utenti GIT Users

Ora preparate il filesystem. Nella mia installazione è stata creata, direttamente nella radice del disco fisso, una cartella chiamata “git_repo” destinata a ospitare le sottocartelle corrispondenti ai vari repository. File e cartelle resteranno perciò esterni al percorso predefinito in IIS per i siti Internet (c:\inetpub\wwroot), e si ridurrà il pericolo che manovre maldestre nella configurazione di IIS espongano i sorgenti al mondo intero. Inoltre risulterà più semplice assegnare i permessi d’accesso ai file. Si dovranno poi assegnare alla cartella “c:\git_repo” tutti i permessi di lettura, modifica e cancellazione al gruppo “GIT Users”. Ho enfatizzato “tutti” perché nella mia installazione ho dovuto aggiungere il permesso “Delete subfolders and files” dal pannello dei permessi avanzati (premere il pulsante “Advanced” nella scheda “Security” della finestra delle proprietà della cartella, cliccare sul pulsante “Change permissions…” della finestra “Advanced SecurySettings” quindi selezionare il gruppo “GIT Users” e premere il pulsante “Edit…”, attivare tutti i permessi necessari e confermare con “Ok” in tutte le finestre), qui sotto riporto un paio di immagini illustrative del processo:

Permessi assegnati alla cartella git_repoPermessi avanzati per il gruppo GIT Users

A questo punto utenti, cartelle e permessi sono stati impostati procedete con la configurazione di IIS.

3. Preparazione di IIS

Per prima cosa vi dovrete assicurare che tutti i componenti di IIS necessari al funzionamento del protocollo WebDAV via HTTPS siano correttamente installati (do per scontato che IIS sia già installato sul server e pienamente funzionante). Aprite il programma “Server Manager” e selezionate “Web Server (IIS)” da “Roles” quindi scrollate la finestra verso il basso fino al pannello “Roles services”. Controllate che i componenti “WebDAV publising” e “Basic Authentication” siano stati installati, nel caso non lo fossero basterà selezionarli dall’elenco e cliccare sul link “Add Role Services”. I due servizi serviranno per attivare e configurare il protocollo WebDAV e per l’autenticazione di base degli utenti sul webserver. Qui sotto riporto un paio di immagini esemplificative:

Installazione del componente WebDav PublishingInstallazione del componente Basic Authentication

4. Configurazione di IIS

In questa prima parte verranno configurate le impostazioni di base per siti Internet serviti mediante connessioni sicure HTTPS. Se il vostro webserver dispone già di una configurazione di questo tipo potete saltare questi primi step e passare alla creazione dell’application pool impiegata per l’accesso ai repository Git.

Per poter configurare una connessione HTTPS vi occorrerà un certificato contenente una chiave crittografica che verrà utilizzata per proteggere la connessione, se non diponete di un certificato autenticato da una Certificate Authority (CA) potete crearne uno autofirmato utilizzando l’apposita funzione del pannello d’amministrazione di IIS. Nota: i certificati di questo tipo non vengono riconosciuti come validi da Git, verrà tuttavia spiegato come sopprimere il controllo di validità del certificato sui PC client. Per creare un vostro certificato aprite “Internet Information Services Manager”, selezionate il nodo del sever dall’elenco ad albero “Connections” e fate un doppio click sull’icona “Server certificates” per aprire l’apposito pannello di gestione. Cliccate ora su “Create Self-Signed Certificate…”, digitate un nome per il vostro certificato e premete il pulsante “Ok”.

Creazione di un certificato autofirmato su IISCreazione di un certificato autofirmato su IIS

In alternativa potete utilizzare le funzioni del pannello “Server Certificates” perimportare un certificato in vostro possesso o richiederne uno a una CA (servizio a pagamento). La trattazione di questi argomenti è però fuori dalla portata di questa guida.

Ora potete creare un nuovo set di impostazioni di base per siti Internet serviti mediante connessioni HTTPS. Selezionate il nodo “Sites” dall’albero “Connections” e cliccate sul link “Add new site..” dal pannello “Actions”, digitate un nome per il nuovo sito Internet e scegliete il percorso cui farà riferimento (nel mio caso “Default Secure Web Site” e “c:\inetpub\wwroot”). Selezionate quindi “https” nel combobox “type” del gruppo “Binding” e scegliete il certificato che avete precentemente creato (o importato) nel box “SSL Certificate”  poi premete il pulsante “Ok”.

Creazione di un nuovo sito base per le connessioni HTTPSA questo punto potete passare alla creazione dei vostri repository.

Nella mia configurazione ho ritenuto opportuno creare una nuova application-pool con la quale far girare tutti i repository Git, in questo modo potrei decidere di interrompere l’accesso ai repository (ad esempio per interventi di manutenzione) senza dover sospendere la pubblicazione di altri siti Internet o applicazioni presenti sul server. Nel caso condividiate questa scelta dovrete selezionare il nodo “Application Pools” e cliccate sul link “Add Application Pool…” dal pannello “Actions”, digitate un nome al nuovo pool di applicazioni (nel mio caso “GIT AppPool”) e premere “Ok”. Nel mio caso ho tolto anche il supporto al framework .NET, qui sotto riporto un’immagine con le opzioni da me utilizzate:

Opzioni scelte per l'application-pool dei repository Git

Ora potete creare una nuova applicazione web e farla puntare alla cartella che conterrà i repository Git (“c:\git_repo” nella mia installazione). Cliccate con il tasto destro del mouse sul nodo corrispondente al sito Internet con le impostazioni di default per le comunicazioni HTTPS (nel caso di questa guida  “Default Secure Web Site”) e selezionate “Add Application”. Digitate un alias per la vostra applicazione (ad esempio “git”), scegliete l’application-pool appena creato (“GIT AppPool” oppure il pool di applicazioni già esistente che avete deciso di utilizzare) e selezionate la cartella creata in precedenza destinata a ospitare i repository Git (“c:\git_repo” in questa guida) quindi confermate con “Ok”. Nell’immagine qui sotto riposto le mie scelte:

Creazione della nuova applicazione web per i repository Git

Ora dovrete proteggere la cartella dei repository consentendone l’accesso ai soli utenti forniti di username e password validi. Per raggiungere questo scopo dovrete necessariamente utilizzare il sistema d’autenticazione di base di IIS (l’autenticazione Windows non funzionerà con i client Git), selezionate perciò il nodo corrispondente all’applicazione appena creata (“git”) e fate doppio click sull’icona “Authentication” quindi disattivate l’accesso anonimo selezionando “Anonymous Authentication” e cliccando sul link “Disable” (dal pannello “Actions” sulla destra), quindi selezionate “Basic Authentication” e cliccate sul link “enable” (sempre dal pannello “Actions”), assicuratevi che la “Windows Authentication” sia disabilitata e premete sul pulsante “Ok”. Dovreste avere una situazione simile a quella rappresentata dall’immagine qui sotto.

Impostationi per l'autenticazione degli utenti per i repository Git

Uscite dal pannello “Autentication” e aprite le impostazioni relative alla cifratura del canale HTTPS facendo doppio click sull’icona “SSL Settings”. Attivate l’opzione “Require SSL” per abilitare la cifratura dei dati e lasciate su “Ignore” la richiesta dei certificati per i client, come nell’immagine qui sotto:

Impostazioni SSL per la cartella dei repository Git

A questo punto dovrete abilitare il protocollo WebDAV, selezionate nuovamente il nodo corrispondente alle impostazioni di base per i siti Internet accessibili via HTTPS (“Default Secure Web Site” in questa guida) e fate doppio click sull’icona “WebDAV Authoring Rules”, quindi cliccate sul link “Enable” dal pannello “Actions” (sulla parte destra della finestra).

Apertura del pannello per la configurazione di WebDAVAbilitazione del protocollo WebDAV

Abilitato il protocollo WebDAV dovrete ora definire le regole di collaborazione su file e cartelle per gli utenti dei repository, selezionate l’applicazione creata in precedenza (“git” in questa guida) e, anche in questo caso, fate doppio click sull’icona “WebDAV Authoring Rules”.  Aggiungete una nuova regola di collaborazione cliccando sul link “Add Authoring Rule…”, permettete la modifica a tutti i tipi di file selezionando “All content” dal gruppo “Allow access to:” e restringete l’accesso ai soli utenti abilitati attivando l’opzione “Specified users:” del gruppo “Allow access to this content to:” e scrivendo i loro username nell’apposita casella. Nota: con l’autenticazione di base di IIS gli utenti che effettuano il login sul sito non vengono ricondotti al gruppo d’appartenenza di Windows, in questo caso perciò non funzionerebbe specificare “GIT Users” nella casella “Specified roles or user groups:”. Un’altra considerazione…questa regola varrà per ogni repository creato nella cartella “git_repo”, potrete in seguito restringere ulteriormente l’accesso creando altre regole di collaborazione WebDAV per ciascuna delle cartelle dei repository Git. Per finire concedere i permessi di lettura, scrittura accesso ai sorgenti attivando le opzioni “Read”, “Write” e “Source” nel gruppo “Permissions:” (il pemesso “Source” serve ad autorizzare o negare l’accesso ai file mappati agli handlers ASP, PHP, Perl, ecc… in IIS).

Regola di collaborazione WebDAV per la cartella principale dei repository

Come ultima cosa occorrerà segnalare a IIS come comportarsi con i file del repository privi di estensione (per default IIS notifica un errore 404…non proprio l’effetto desiderato). Tornate al pannello principale della vostra applicazione web (“git” nel mio caso) e fate doppio click sull’icona “MIME Types”, cliccate poi sul link “Add..” nel pannello delle “Actions”. Nella finestra relativa al nuovo MIME Type digitate “.” nella casella “File name extension:” e “application/octet-stream” in “MIME Type” come nell’immagine riportata qui sotto.

Specifa del MIME type per i file privi di estensione

La configurazione di IIS è finita…o quasi. Per ogni singolo repository potrete successivamente intervenire sulla configurazione di IIS per consentire l’accesso solo ad alcuni utenti, variare le regole di collaborazione WebDAV, ecc…

5. Creazione di un repository Git

Finita la configurazione del server non resta che creare i repository Git. Per prima cosa create una nuova cartella all’interno di quella destinata a ospitre i vostri repository e chiamatela con il nome che desiderate ed estensione “.git” (come esempio utilizzerò il repository di un’applicazione chiamata “MyToDo”, creerò quindi la cartella “c:\git_repo\MyToDo.git”). Aprite ora la “Git Bash” utilizzando l’icona creata dal programma d’installazione di Git e posizionatevi all’interno della cartella del repository utilizzando il comando “cd”, nel mio caso: “cd /c/git_repo/MyToDo.git” (ricordatevi che questa è una shell GNU/Linux, comandi e relative sintassi sono quelle del sistema operativo open source).

Git Bash

A questo punto non resta altro che inizializzare il repository specificando l’opzione “bare”, obbligatorio per consentire le operazioni di push. Digitate perciò il comando “git –bare init” e poi “git update-server-info”, il repository verrà inizializzato con tutte le cartelle e i file necessari a Git, qui sotto trovate un’immagine del contenuto del repository di test dopo l’inizializzazione.

Inizializzazione repository GitRisultato dell'inizializzazione del repository Git

Il repository è finalmente pronto, ora dovrete configurare i client.

Come configurare i client

1. Installazione di Git

L’installazione di Git sui client è simile a quella effettuata sul server, l’unica cosa che potreste voler cambiare è l’integrazione con Window Explorer. Il programma d’installazione è infatti in grado di aggiungere i comandi “Git Bash Here” o “Git GUI Here” ai menù di contesto di Windows Explorer, rispettivamente per aprire una shell Git Bash nella cartella nella quale siete posizionati o aprire una rudimentale interfaccia grafica che potreste utilizzare per creare, clonare o aprire un repository. In alternativa msysGit propone l’installazione di Git Cheetah un’estensione cross-platform per file manager che prende a modello Tortoise SVN…al momento però il progetto sembra molto lontano dal raggiungimento dell’obbiettivo. Nel mio caso ho deciso di attivare la sola estensione “Git Bash Here”, per le altre fasi dell’installazione ho invece conservato le opzioni suggerite.

Opzioni d'installazione di Git sul client

2. Installazione di Tortoise Git

Essendo abituato a utilizzare le estensioni Tortoise CVS e Tortoise SVN in Windows Eplorer la scelta del client GUI da installare non è stata difficile per me… Questo passaggio è facoltativo ma vivamente consigliato. Tortoise Git, come i suoi “cugini”, può darvi una grossa mano nel gestire le operazioni di commit, push, pull e gestione dei conflitti. L’installazione di Tortoise Git e molto semplice l’unica scelta che vi verrà proposta riguarderà il client SSH da utilizzare (scelta comunque non importante ai fini di questa guida), ToroisePlink (discendente da PuTTY)  o OpenSSH fornito con Git.

3. Preparazione del repository locale

Ora potete creare la versione locale del repository sul PC client. Innanzitutto posizionatevi nel percorso dove desiderate creare il repository e aprite la Git Bash utilizzando l’apposita icona o o il comando “Git Bash Here” dal menù di contesto in Windows Explorer. Se avete utilizzato un certificato non autenticato da una CA per cifrare la connessione HTTPS sul server (come nel caso di questa guida), dovrete comunicate a Git di non verificarne la validità. Digitate quindi il comando: “git config –global http.sslVerify false” (purtroppo nella mia installazione è stato necessario sopprimere il controlle dei certificati a livello globale, Git ignorava questa impotazione a livello di singolo repository e non sono riuscito a stabilire se questo fosse un comportamento desiderato di Git, un mio problema di configurazione o un bug…).

Sopprimere il controllo dei certificati SSL in Git

Ora potete clonate il repository (anche se ancora vuoto) utilizzando il comando “git clone https://<server_host_name>/<repository_git> <nome_repository_locale>”, nel mio caso: “git clone https://<host_server>/git/MyToDo.git” e digitate la password dell’utente quando richiesto. Nota: se la vostra connessione passa attraverso un proxy server dovrete prima comunicare a Git i parametri del proxy utilizzando il comando: “git config http.proxy http://<proxy_host_name>:<porta_proxy>”.

Inizializzazione di un repository Git

Attenzione: al momento della scrittura di questo articolo sembra esserci un problema in Windows con l’autenticazione di base via HTTPS/WebDAV per le operazioni di push. Sembra infatti che al comando “curl” non vengano passati correttamente username/password…Per ovviare a questo problema dovrete creare nella cartella principale del vostro utente (dal prompt dei comandi di Windows digitate “set HOMEPATH” per controllare l’esatta posizione) un file chiamato “_netrc” (senza estensione) e aprirlo con un qualunque editor di testi, dovrete po aggiungere una linea del tipo: “machine <host_name_server> login <vostro_utente> password <vostra_password>” e salvate il file. Nella configurazione di Git non potrete inoltre specificare username e/o password direttamente nell’URL del repository remoto utilizzando una sintassi del tipo: “https://<username>:<password>@<server_url>”. Utilizzando questo sistema le operazioni di push funzioneranno senza problemi ma avrete scritto in chiaro vostri dati d’accesso al server…Una soluzione veramente poco accettabile, il file potrebbe essere letto da qualsiasi programma malevolo e passato in chissà quali mani…credo proprio che realizzerò un mio stub per il comando curl che decifri il file prima di eseguire un comando e lo torni a cifrare al termine.

Le stesse operazioni sopra descritte possono essere eseguite anche con TortoiseGit. Per prima modificate la configurazione di Git per sopprimere il controllo di validità dei certificati SSL, in Windows Explorer premete il tasto destro del mouse nella cartella scelta per contenere i repository e selezionate “Settings” dal menù “TortoiseGit”.

Menù di contesto di TortoiseGit

Nella finestra di configurazione di TortoiseGit selezionate il nodo “Git” e premete il pulsante “Edit global .gitconfig”, quindi aggiungete l’impostazione “sslVerify = false” nella sezione “[http]” (se non sono presenti aggiungetele voi), salvate le modifiche e premete il pulsante “Ok”.

Finestra delle opzioni di TortoiseGitFile di configurazione di Git

Per clonare il repository utilizzate il comando “Git clone…” dal menù di contesto di Window Explorer, copilate il campo “URL” con l’indirizzo del repository remoto (nel mio caso “https://<host_server>/git/MyToDo.git”), controllate che il percorso del repository locale sia corretto nel campo “Directory” quindi confermate con “Ok”. TortoiseGit eseguirà per voi gli opportuni comandi Git e recupererà i file dal repository remoto comunicandovi l’esito delle operazioni.

Menù di contesto di TortoiseGit per clonare un repositoryFinestra di TortoiseGit perimpostare l'URL del repository remoto e il percorso di quello locale

Finito! Da questo momento in poi potrete lavorare sul vostro repository locale ed effettuare tutte le operazioni di commit, push, pull, ecc. che desiderate!

Il mio primo programma…30 anni dopo

di , lunedì 6 Agosto 2012

Dopo 30 anni (sic!) ho avuto l’emozione di riscrivere il mio primo programma su un Commodore 64 appena restaurato!

10 ?"COMMODORE 64"
20 GOTO 10
RUN
Il mio primo programma su Commodore 64

Eccolo…in tutto lo spendore dei suoi 8 bit!

10° Anniversario

di , mercoledì 20 Ottobre 2010

Il 20 Ottobre 2000 iniziava ufficialmente la mia avventura di libero professionista nel settore informatico. Dieci anni passati ad una velocità sorprendente, nei quali ho avuto il privilegio di dedicarmi al lavoro che avevo fortemente inseguito fin da giovanissimo e finalmente svolto in completa libertà. Un privilegio che non capita a tutti…

In questa occasione vorrei perciò ringraziare tutti i miei clienti che, con la loro fiducia, hanno permesso il raggiungimento di questo primo splendido traguardo.

Per il prossimo decennio prometto altrettanta passione e impegno di quello ormai passato.

Delphi 2010 e la “Package Cache” indigesta…

di , martedì 28 Settembre 2010

Il titolo fa riferimento a un errore che si verifica con la mia installazione di Delphi 2010 ogni volta che aggiorno la suite di componenti ExpressQuantumGrid e/o ExpressBars mediante setup del fornitore. Terminata la procedura d’installazione Delphi puntualmente rifiuta di avviarsi lamentando un:

Access violation at address 500115A7 in module ‘rtl140.bpl’. Read of address 00000000.

Se vi è appena capitato questo genere di errore e siete alla ricerca di una soluzione…sappiate che il problema non è grave e fortunatamente il rimedio è davvero molto semplice da applicare. A quanto pare Delphi 2010 non “digerisce” bene i nuovi BPL installati quando conserva in cache dati relativi a versioni precedenti dei medesimi. Per ovviare al problema è sufficiente rinominare (per cancellare una volta verificato che tutto sia tornato alla normalità) la chiave "HKEY_CURRENT_USER\Software\CodeGear\BDS\7.0\Package Cache" del registro di sistema e riavviare Delphi.

La chiave e tutti i suoi valori verranno ricostruiti automaticamente e Delphi tornerà a funzionare correttamente…o almeno lo farà nel maggiorparte dei casi.

Per la restante parte meno fortunata occorrerà modificare il collegamento utilizzato per lanciare Delphi e aggiungere il parametro -nocahce in coda al percorso dell’eseguibile (es.: "%ProgramFiles%\Embarcadero\RAD Studio\7.0\bin\bds.exe" -pDelphi -nocache).

Nuova veste grafica

di , martedì 24 Agosto 2010

Ad un paio d’anni abbondanti dalla pubblicazione mi sembrava giusto rinnovare la veste grafica al sito…

Dopo una paziente ricerca tra le innumerevoli alternative che la comunità legata a WordPress mette a disposizione degli affezionati utilizzatori, la scelta del nuovo tema è caduta su “Panorama” realizzato da Themocracy (io mi sono limitato a ritagliare gli inserti grafici e ad apportare qualche piccolo ritocco ai sorgenti PHP). Spero apprezziate questo nuovo stile grafico e vi rimando alla pagina dei credits per maggiori informazioni.

Con l’occasione ho inoltre provveduto ad aggiornare i contenuti delle pagine e preso la decisione di pubblicare, di tanto in tanto, qualche articolo sulle mie esperienze di sviluppatore…con la speranza che possiate trovarli interessanti.

Benvenuti!

di , lunedì 29 Ottobre 2007

In questo sito Internet potete trovare informazioni relative alla mia attività di consulente informatico, specializzato in analisi, progettazione e sviluppo software, che svolgo nelle province di Reggio Emilia, Modena e Parma.

Le pagine del sito riportano una breve descrizione di chi sono, delle principali competenze informatiche che posseggo, di come mi mantengo al “passo coi tempi” e di come tutto questo si traduca in “strumenti di lavoro quotidiano” per i mie clienti…

Grazie per la visita
Moris Notari

Powered by WordPress - Panorama Theme by Themocracy - Credits page