Due dritte per installare wmic in linux.

Per chi non conosce wmic possiamo dire che e’ un elenco di comandi eseguibili in windows per raccogliere informazioni. Questi comandi sono integrati nel sistema operativo microsoft nativamente e possono essere eseguiti anche da macchine remote nella propria rete. Per sapere cosa si puo’ interrogare bisogna lanciare dal prompt dei comandi windows wmic /?

Interessante e’ anche il set di comandi sviluppati in linux che permettono di interrogare macchine windows senza bisogno di agent. Un esempio potrebbe essere l’interrogazione dello spazio libero sul disco o la memoria utilizzata. Per usare questi comandi in linux ho cercato un po’ in giro e alla fine mi sono trovato bene seguendo questa guida, riepilogo i comandi (testati in debian e ubuntu in varie versioni):

ulimit -n 100000
cd /tmp
mkdir wmic
cd wmic

apt install autoconf gcc libdatetime-perl make build-essential g++ python-dev
wget http://www.opsview.com/sites/default/files/wmi-1.3.16.tar_.bz2
bunzip2 wmi-1.3.16.tar_.bz2
tar -xvf wmi-1.3.16.tar_
cd wmi-1.3.16/

vim Samba/source/pidl/pidl
:583 (to jump to line 583)
remove the word defined before @$pidl
:wq

export ZENHOME=/usr
make “CPP=gcc -E -ffreestanding”
cp Samba/source/bin/wmic /bin

 

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Problema Java – DatagramSocket tiene allocato il socket

Mi è capitato di scrivere del codice che scrive/legge da socket di rete ed ho riscontrato un baco (per me è un baco) che mi ha fatto perdere un sacco di tempo, il mio codice era simile a questo:

DatagramSocket s = new DatagramSocket(7777);
InetAddress indirizzo = s.getLocalAddress();
byte[] buf = new byte[65536];
DatagramPacket recv = new DatagramPacket(buf, buf.length);
s.receive(recv);
s.close

Sostanzialmente la prima riga crea un socket e fa il bind sulla porta locale 777 (prima riga in grassetto) poi il codice continua e aspetta dalla rete qualcosa (s.receive) e alla fine chiude e dealloca tutto (s.close). Il problema che ho riscontrato è che lui non deallocava un bel niente e rilanciando l’applicazione non riusciva più a fare il bind perchè rimaneva allocato dal giro di prima. Cercando in giro in internet ho risolto cambiando la prima riga così:

s = new DatagramSocket(null);
s.setReuseAddress(true);
s.bind(new InetSocketAddress(7777));

Sostanzialmente inizializza il socket a null poi fa il bind a mano. In questo caso quando fa la close (s.close) rilascia correttamente il socket a livello sistema operativo.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Configurazione di un controllo di versione per non esperti

Esistono tantissime guide dettagliate sull’installazione e la gestione del controllo di versione ma secondo me sono tutte molto dettagliate e all’inizio un non esperto in materia può fare fatica a capire la logica e quindi ad avvicinarsi all’argomento. In questa breve guida cercherò di spiegare le nozioni di base rimandando alle varie guide e tutorial per gli approfondimenti. Come software spiegherò mercurial. Come installazione prenderò una linux con i comandi base a riga comando, con strumenti  grafici come tortoise hg si fanno le medesime cose ma sono meno chiare da comprendere anche se forse più facili da usare in seguito. Dunque cominciamo:

  • Usare un cvs vuole dire tenere sotto controllo le modifiche effettuate a sorgenti di programma quindi sostanzialmente a file di testo. Quindi prendiamo come esempio la cartella sorgenti che sta nella nostra home directory.
  • Per prima cosa dobbiamo inizializzare la nostra cartella alla gestione con il comando hg init (se usate strumenti grafici qualcosa tipo tasto destro sulla cartella poi crea repository). Questo comando crea una sottocartella nel nostro progetto che si chiama .hg che contiene le cose necessarie a mercurial per tracciare le nostre modifiche.
  • Come seconda cosa dobbiamo aggiungere al sistema i file da monitorare e usiamo il comando hg add con questo comando è possibile selezionare i file da aggiungere.
  • Per questi file è bene sapere che esiste un file che si chiama .hgignore dove è possibile omettere dei file tipo i compilati o i file di backup, fare riferi mento alle guide ufficiali per i dettagli.
  • a questo punto è bene fare il nostro primo commit con il comando hg commit (è obbligatorio dare una descrizione per ogni commit effettuato), a questo punto il sistema ha congelato la situazione e la userà per confrontarla con altre situazioni per ripristinare eventuali danni.
  • Ora modificando i nostri sorgenti il sistema noterà delle differenze. per controllarle il comando sarà hg status , un altro comando utile è hg log che ci racconta la storia di quello che è successo.

A questo punto abbiamo sotto monitor lo stato del nostro sviluppo sarà possibile controllare e tornare indietro se qualche modifica è andata storta. Questa configurazione è tutta sul pc locale, non sfrutta quindi le potenzialità dello strumento per lo sviluppo in team. Per fare ciò sono disponibili i comandi hg pull e hg push che replicano le nostre modifiche o rollback su un server centralizzato e quindi sui pc dei nostri colleghi. Per la configurazione si rimanda ad un futuro post.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

Utilizzo i cookie per essere sicuro che tu possa avere la migliore esperienza sul mio sito. Se continui ad utilizzare questo sito assumo che tu ne sia felice.. maggiori informazioni

Questo sito utilizza i cookie per fonire la migliore esperienza di navigazione possibile. Continuando a utilizzare questo sito senza modificare le impostazioni dei cookie o clicchi su "Accetta" permetti al loro utilizzo.

Chiudi