Comunicazione di servizio

Andrea, per favore, puoi aggiornare la pagina http://www.ugidotnet.org/Home/Support inserendo l'IBAN del c/c sul quale fare il bonifico bancario di "contributo associativo"? Mille grazie!

Sulla gestione di UGIdotNet

La recentissima disavventura (che io chiamerei sfiga bulicante!) occorsa al sito UGIdotNet deve far riflettere. Io sono del parere che occorra contribuire alle spese di gestione della community, e spero di poter proporre una modalità che non susciti malumori ne tanto meno fiammate varie, come è già successo in passato. Se discussione ci dev'essere (com'è democraticamente auspicabile, in ogni community che si rispetti), prego gli interessati di usare il forum (quando tornerà ad essere attivo).

Alcune considerazioni iniziali, anche se banali:

  • Non esiste un solo modelo modello per fare community, ma in ognuno di essi vi sono fondamentalmente due aspetti che la caratterizzano:
    • L'aspetto economico, con le spese e i vari modi per farvi fronte
    • La gestione dell'operatività e delle attività svolte, con particolare riguardo a chi e come prende le decisioni.
  • Gli strumenti tipici di finanziamento sono:
    • Sponsorizzazione e supporto finanziario (nel caso di UGIdotNet, Microsoft in primis)
    • Pubblicità (banners)
    • Quota associativa
    • Donazioni
  • I modus operandi sono i più vari (provate a fare un compendio degli statuti delle varie associazioni culturali senza fine di lucro (ONLUS) esistenti in italia, e troverete più varianti delle voci dell'enciclopedia Tre Cani).

Per quanto riguarda la nostra community, credo che sia necessario essere molto chiari sul modus operandi:

UGIdotNET è stato fondato da Andrea Saltarello ed è una associazione no-profit, con uno statuto regolarmente depositato presso un tribunale, e del cui rispetto (come Presidente) Andrea è pienamente responsabile.

Ciò detto, la mia proposta è di lasciar perdere ogni argomento "legalese" e partire da un atto di fiducia, come spesso viene fatto per contributi a strutture note che operano da anni, come (a solo titolo d'esempio) Medici senza frontiere, WWF, Grenpeace, ecc. , senza alcun valore di paragone se non quello della fiducia.

Andrea e gli altri collaboratori stretti hanno dimostrato negli anni un'enorme dedizione alla community, con risultati evidenti che sono sotto gli occhi di tutti noi, e il super sfigato crash del sito (che ha convalidato le più bastarde leggi di Murphy) non credo abbia minimamente intaccato il rispetto e la gratitudine che sono certo ognuno di noi ha verso i loro confronti.

Io in particolare ho già avuto modo di esternare la mia gratitudine per questa community che mi ha aiutato e stimolato a studiare in modo fantastico.

Per questo motivo rinnovo l'invito a tutti i soci a donare un contributo per aiutare a coprire le spese, "senza obbigo di rendicontazione". La chiave è tutta qui, in questa frasetta, che dimostra la nostra fiducia non solo nelle capacità professionali di Andrea e soci, ma anche e specialmente nelle loro qualità etiche.

La fiducia e il rispetto sono merce rarissima al giorno d'oggi, e valgono infinitamente di più del denaro.

Infine una nota per Andrea: mettiamo sul muro UGIdotNet (nella colonna contenente l'elenco dei bloggers, in alto, subito dopo il blocco "Syndication") un riquadrino con un pulsante "Donate" che rimandi ad una pagina con le motivazioni e le modalità (paypal, IBAN del c/c su cui fare un bonifico con la causale "Donazione", e quant'altro ti viene in mente). Come a dire: se ti va, puoi farlo così.

Per quanto mi riguarda, non avendolo fatto prima (mea culpa!) al momento non so come devo fare per dare il mio contributo e per me la cosa più semplice sarebbe avere l'IBAN del c/c su cui fare un bonifico.

Non credo che i nostri contributi basteranno per coprire interamente le spese, ma anche pochi euro sarebbero un'importante testimonianza del valore che attribuiamo alla community.

Per finire, e solo come eccezione che conferma la regola, mi piacerebbe sapere quanto viene a costare l'eventuale recupero dei dati dei dischi rotti, perchè per questa singola evenienza, se la spesa non è tel tutto sproporzionata al valore dei dati contenuti, mi piacerebbe proporre una "colletta" a cui partecipare, anche in maniera significativa, per coprire le spese di ripristino.

Hyper-V e le reti virtuali esterne

Configurare una "rete virtuale esterna" con Windows Server 2008 e Hyper-V è molto facile, se si conoscono alcune semplici informazioni (cosa che ovviamente mi ha fatto penare, vista la mia totale ignoranza in materia...).

Per questo ho deciso di postare una breve guida illustrata, sperando possa essere utile a qualcun'altro.

Obiettivo prefissato: avere una o più Virtual Machine, ciascuna con la sua bella scheda virtuale con IP fisso, visibile dalla rete locale, equivalente a questo schema:

Ante Rete Virtuale Esterna 

Per consolidare i tre server contenuti nel riquadro in un'unico server fisico, con Hyper-V dobbiamo creare una "Rete Virtuale Esterna". Ecco come fare, passo per passo.

1) Apriamo il Server Manager del server che ospiterà le tre macchine virtuali (che in gergo Hyper-V si chiamano "Partition"), nel nostro esempio quello che contiene il Domain Controller. Selezioniamo il server Hyper-V e e facciamo click sull'azione "Gestione Reti Virtuali...":

Creazione Rete virtuale esterna (step 1)

2) Selezioniamo il tipo di rete virtuale (Esterna) e facciamo click sul pulsante "Aggiungi":

Creazione Rete virtuale esterna (step 2)

3) Cambiamo il nome alla rete virtuale appena creata da "Nuova rete virtuale" a qualcosa di nostro gradimento (io ho optato per "Rete virtuale esterna") e facciamo click sul pulsante "OK":

Creazione Rete virtuale esterna (step 3)

Nel creare la rete virtuale esterna, Hyper-V utilizza la "scheda di rete fisica" come switch, e crea una "scheda di rete virtuale" per ciascuna partizione, secondo il seguente schema:

Rete Virtuale esterna

Infatti, se apriamo le connessioni di rete della Parent Partition, troviamo due connessioni che ho rinominato "Switch (Physical NIC)" e "Scheda rete locale (Virtual NIC)":

Switch e NIC (su Parent Partition))

Ovviamente nelle Child Partition troveremo solo la scheda di rete locale (Virtual NIC) e non quella fisica, che come abbiamo visto agisce da switch e risiede solo nella Parent Partition.

Aprendo la finestra delle proprietà dello Switch troviamo:

Proprietà SWITCH

Da notare che la connessione è effettuata tramite Intel(R) 82562V 10/100, quindi si tratta proprio della scheda fisica, e che l'unico elemento utilizzato ("bindato" alla connessione) è il protocollo commutatore di rete virtuale (IMHO orrenda traduzione di switch di rete virtuale).

Aprendo invece la finestra delle proprietà della scheda di rete locale, troviamo:

Proprietà NIC Virtuale

Da notare che la connessione è effettuata tramite "Rete virtuale esterna", quella che abbiamo appena creato. Tutti gli elementi necessari al funzionamento del server vanno abilitati (ovviamente escludendo il protocollo commutatore di rete virtuale che è già in funzione nell'altra connessione). In questo esempio per semplicità non viene usato il protocollo IPv6, mentre vengono impostate le proprietà di IPv4 come per un normale server fisico. Per ottenere l'obiettivo prefissato del nostro esempio, l'indirizzo IP della scheda virtuale della Parent Partition è stato impostato a 192.168.0.1, quello della scheda virtuale della Child Partition su cui è installato SQL Server a 192.168.0.2 e quello della scheda virtuale della Child Partition in cui è installato il WEB Server a 192.168.0.3 , ovviamente con 255.255.255.0 come valore di subnet per tutti e tre i casi. Sempre nel nostro esempio, poichè nella Parent Partition oltre al Domain Server gira anche il DNS, in tutte le tre schede virtuali l'indirizzo IP del DNS è stato impostato a 192.168.0.1 mentre l'indirizzo IP del gateway è stato impostato a 192.168.0.101 (indirizzo IP del Server ISA 2006).

Note:

  • Lo schema proposto è solo un esempio, perchè in produzione sembra non sia consigliabile virtualizzare il Domain Controller, neanche in una Parent Partition (al riguardo, vedi: Considerations when hosting Active Directory domain controller in virtual hosting environments);
  • In acuni casi, può capitare di non riuscire a creare la rete virtuale esterna e ricevere questo errore (dopo aver fatto click sul pulsante "OK" come descritto nel precedente passo 3):
    Errore Commutatore
    In questo caso basta modificare le proprietà della scheda di rete fisica e togliere tutti i bindings ad eccezione del protocollo di commutatore virtuale e riprovare. E' superfluo ricordare che occorre annotare tutte le varie impostazioni eventualmente già presenti nelle proprietà dei suddetti bindings, che andremo poi a reimpostare sulla scheda di rete virtuale una volta completata la creazione della rete virtuale esterna.

Link utili:

«ottobre»
domlunmarmergiovensab
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678