Tool di Benchmarking per GPU (Utile con Remote FX)

Per chi volesse apprezzare e  rilevare le effettive performance delle schede GPU, anche in ambiente Hyper-V/RDS, un valido aiuto sono i software di test messi a disposizione da UNiGiNE

http://unigine.com/en/products/benchmarks

già le versioni disponibili in licenza grautita consentono di valutare le effettive differenze nell’impiego delle GPU anche in ambienti come RDS con RemoteFX.

 

 

 

Operations Management Suite configurazione dell’agente Linux come Syslog Collector gateway verso Log Analitycs

 Syslog è un protocollo che consente il trasporto di messaggi di log, e di informazione più in generale, è nato all’inizio degli anni ’80 tuttavia è stato definito come RFC dall’IETF soltanto vent’anni dopo. In questo lasso di tempo diverse implementazioni hanno generato differenti “servizi”, la prima  RFC che ne documenta il funzionamento è la 3164  mentre una sua evoluzione è descritta dalla RFC 5424

I servizi più comuni che lo utilizzano in ambienti *NIX hanno nome SYSLOG, SYLOG-NG, RSYSLOG ma molti altri prodotti, sia commerciali, che rilasciati sotto licenza Open Source lo implementano al fine di permettere la raccolta di eventi generati da molteplici apparati e sistemi.

Ormai non è affatto raro trovare apparati di rete, firewall, telecamere ma anche prodotti legati al mondo industriale, come ad esempio PLC e controllori di processo più in generale, che implementano il protocollo Syslog al fine di inviare ad un unico collettore i propri eventi di funzionamento.

Struttura del Sylog

Inizialmente implementato sul protocollo UDP, in porta 514 (recenti implementazioni lo rendono disponibile anche in TCP) il pacchetto trasporta le informazioni suddivise in:

  • Facility
  • Severity
  • Hostname
  • Timestamp
  • Message

Possiamo considerare le Facility come le entità che generano il messaggio di Syslog e ognuna di queste definisce poi una Severity che gradua la “gravità” dell’evento stesso.

Le Facility sono codificate da un numero e si riferiscono a componenti diverse del sistema; kernel, demoni di sistema, autenticazione ecc.

Cod. Facility
0 Kernel messages
1 User-level messages
2 Mail system
3 System daemons
4 Security/authorization messages
5 Messages generated internally by Syslogd
6 Line printer subsystem
7 Network news subsystem
8 UUCP subsystem
9 Clock daemon
10 Security/authorization messages
11 FTP daemon
12 NTP subsystem
13 Log audit
14 Log alert
15 Clock daemon
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

Le severity seguono la stessa struttura e sono:

Cod. Severity
0 Emergency: System is unusable.
1 Alert: Action must be taken immediately.
2 Critical: Critical conditions.
3 Error: Error conditions.
4 Warning: Warning conditions.
5 Notice: Normal but significant condition.
6 Informational: Informational messages.
7 Debug: Debug-level messages.

Un pacchetto Syslog potrà avere per ogni Facility un codice di Severity differente, l’informazione dell’hostname che lo ha generato,l’ora di generazione ed in aggiunta una descrizione ulteriore relativa all’evento.

Syslog è quindi un “mezzo di trasporto” che viene utilizzato da differenti mittenti che classificano i propri messaggi secondo la codifica delle Facility, dipende quindi da ognuno dei servizi che generano messaggi log classificare i propri secondo la struttura del protocollo stesso.

Ad esempio SSHD di default utilizza la facility AUTHPRIV per i suoi messaggi relativi al logon degli utenti e quindi all’interno della configurazione del syslog, relativamente a questa facility, è indicato il percorso del file dove vengono salvati gli eventi.

Configurazione del Servizio Rsyslog su Linux

Su sistemi Linux ( RH,Centos, Oracle Linux) normalmente il demone rsyslog ha il file di configurazione in /etc/rsyslog.conf e la struttura di default prevede il salvataggio in locale dei messaggi che vengono generati dal sistema

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* -/var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.

 

authpriv.* istruisce syslog a salvare tutte le severity di questa facility nel file /var/log/secure, se volessimo differenziare le varie severity in percorsi distinti dovremmo dichiararlo per ognuna

authpriv.info                     /var/log/file1

authpriv.notice                /var/log/file2

ecc.

 

Redirezione dei messaggi verso un collettore in rete

Come detto in precedenza il protocollo syslog è in grado di trasportare i vari messaggi verso un collettore, ossia un ulteriore syslog che riceve ed archivia.

Per configurare un sistema in modo che invii tutti o solamente alcuni messaggi verso un altro server è sufficiente nel file .conf dichiarare l’host anziché un file locale come visto sopra.

La facility AUTHPRIV archiviata verso l’host 192.168.0.1 diventerà così:

authpriv.*                                           @192.168.0.1

mentre se l’host di destinazione invece che in UDP fosse configurato per ricevere in TCP dovremmo impostare

authpriv.*                                           @@192.168.0.1

ed ancora, se la porta di destinazione dell’host ricevente non fosse la standard 514 ma supponiamo la 25224 TCP dovremmo dichiarare

authpriv.*                                           @@192.168.0.1:25224

Operations Management Suite Agent in Linux

L’agente OMS per Linux quando installato sul sistema si comporta come un ricevitore di messaggi Syslog che poi redirige verso il servizio di log analizer in cloud. Il file di configurazione è in:

/etc/opt/microsoft/omsagent/conf/omsagent.conf

e per impostazione predefinita riceve i messaggi che sono generati localmente al sistema secondo questa configurazione:

<source>
type syslog
port 25224
bind 127.0.0.1
protocol_type udp
tag oms.syslog
</source>

Questo richiede (se si vogliono redirigere eventi Syslog verso il Log Analyzer) che il file di configurazione del Syslog venga modificato in modo da reindirizzare gli eventi sulla porta ed indirizzo su cui è configurato l’agente stesso.

Secondo quanto visto sopra, se volessimo inviare ad OMS i messaggi relativi a SSH configurato per utilizzare la Facility AUTHPRIV, dovremo impostare il file conf di Syslog in questo modo

authpriv.*                                           @127.0.0.1:25224

Modificando ulteriormente la configurazione dell’agente OMS, è possibile fare sì che questo diventi a sua volta un gateway di messaggi raccolti da vari Syslog verso il servizio di Log Analyzer di OMS, impostando omsagent.conf in questo modo:

<source>
type syslog
port 25224
bind 192.168.0.1   ( ip del sistema )
protocol_type udp
tag oms.syslog
</source>

e configurando i vari sitemi ad inviare i messaggi verso l’agente, otterremo il risultato di avere un gateway unico verso OMS senza dover installare ulteriori agenti.

Chiaramente così facendo si perde la possibilità, offerta dall’installazione diretta dell’agente sul sistema, di avere a disposizione ulteriori dati come ad esempio valori di occupazione dischi, ram, cpu etc.

 

20160916-oms-agnt-lnx-1

report ottenuto eseguendo il monitoraggio degli accessi in SSH su sistemi linux con le configurazioni descritte sopra

Problemi riscontrati

Durante la configurazione di alcuni sistemi (abbastanza datati) con demone Syslog, non era possibile cambiare la porta di destinazione sia TCP che UDP

 

Riferimenti

OMS agent su GitHub

Portale OMS esecuzione di query

OMS agent considerazioni generali

 

 

Microsoft Operations Management Suite ricercare eventi particolari

Lo stumento di Microsoft che prende il nome di Operations Management Suite è effettivamente un ambiente molto potente ed articolato che può essere di aiuto per gli amministratori di sistema.

Nella console del portale sono disponibili già preconfigurate una buona serie di query legate alla sicurezza, così come viene eseguito in automatico un “Assesment” del sistema, ad esempio nel mio caso, relativamente ad un Domain Controller, sono sato “avvisato” che questo non aveva le impostazioni di rete corrette per la parte DNS.

Uno strumento molto potente è la ricerca all’interno del mare di eventi che sono archiviati dai vari agent, in questo articolo sono forntite una serie di informazioni ed esempi che possono aiutare molto chi dovesse iniziare con questo strumento.

Personalmente ho voluto realizzare una query che evidenzi tutti gli eventi di logon relativamente ad un gruppo di utenti amministratori il cui nome contiene “_” e due lettere “as”, l’evento codificato per il login di un utente corrisponde all’id 4624 quindi impostando la quey

Type=SecurityEvent AccountType=user Account=*_*as EventID=4624| measure count() as Logons by Account

ho potuto in modo semplice avere in evidenza gli accessi effettuati da questo gruppo di utenti.

Nel caso in cui fosse, come è necessario, rilevare anche i tentativi di accesso falliti,  sempre di questo gruppo di utenti, sarà sufficiente modificare la query con l’id evento che viene generato all’atto di un tentativo fallito di login ossia il 4625

Type=SecurityEvent AccountType=user Account=*_*as EventID=4625| measure count() as Logons by Account

se volessimo poi restringere la ricerca agli eventi di questo tipo occorsi nelle utime 6 ore sarà sufficiente modificare le query aggiungendo il seguente “filtro” TimeGenerated>NOW-6HOURS

e la query diventerà così:

Type=SecurityEvent AccountType=user Account=*_*as EventID=4625 TimeGenerated>NOW-24HOURS | measure count() by Account

nel caso in cui si debbano utilizzare caratteri jolly per la ricerca di determinati valori è bene ricordare che questi non possono esssere immessi come parte di una stringa racchiusa tra “” altrimenti verranno interpretati come caratteri oggetto essi stessi di ricerca.

Recentemente nel portale OMS è stata introdotta la possibilità di creare query personalizzate ed organizzarle in un pannello che può essere visualizzato direttamente da console, questo strumento si chiama View Designer e deve essere abilitato dalla gestione delle impostazioni nelle preview

 

20160911-oms-query-1

qui sotto è riportato un pannello composto da query personalizzate che può essere utile attivare per il controllo della propria infrastruttura

20160911-oms-query-2

OMS è valutabile gratuitamente per un periodo illimitato, ma con la limitiazione di conservazione dei dati di 7 giorni e per un massimo di 5oo MB giornalieri di log archiviati

TTG Torino & ICTPower MeetUp (7 luglio)

Nano Server Meetup TTG – ICTPower, giovedì 7 luglio | ICT Power
http://www.ictpower.it/wp-content/themes/TechNews/js/html5.js

Windows Server 2016 introduce una nuova modalità d’installazione denominata Nano Server il cui obbiettivo è l’erogazione di servizi a fronte di un basso utilizzo di risorse ottenuto tramite l’eliminazione della User Interface e di altri componenti di sistema. Nano Server rappresenta quindi non solo una delle principali novità della prossima versione del sistema operativo Microsoft, ma anche il futuro Microsoft Cloud Platform Server.

Nel meetup del 7 luglio organizzato da Torino Technologies Group in collaborazione con ICTPower.it Ermanno Goletto (MVP Cloud and Datacenter Management e MVP Enterprise Mobility) e Roberto Massa (MVP Cloud and Datacenter Management) discuteranno quali sono gli scenari Cloud e On-Premises che possono beneficiare di questa nuova modalità d’installazione, le procedure di deployment e configurazione e la Developer Experience.

Oltre alla sessione divulgativa, ci sarà spazio per domande e risposte per chi è interessato ad approfondire questo argomento.

L’evento inizia alle 18 e termina alle 20 e si terrà presso il Microsoft Innovation Center (MIC) di Torino in c/o ISMB Via Pier Carlo Boggio 61 10138 Torino. Dopo le 20.00 per chi desidera continuare a chiacchierare può concludere la serata in pizzeria.

Di seguito l’agenda della sessione:

  • Scenari di utilizzo di Nano Server
  • Installazione di Nano server e configurazioni post installazione
  • Gestione remota di Nano Server
  • Deep dive e Roadmap

Utilizzo di una connessione Java tramite Proxy

Nel caso sia necessario effettuare connessioni di applicativi che utilizzano l’ambiente Java Runtime e ci si debba appoggiare ad un proxy per le connessioni, è possibile dichiarare all’interno del batch di avvio il Proxy Host e la relativa porta.

-Dhttp.proxyHost=n.n.n.n 
-Dhttp.proxyPort=n
-Dhttp.nonProxyHosts="localhost|127.0.0.1|10.*.*.*" 

Importante gestire le esclusioni per non pregiuducare l’utilizzo di eventuali applicativi non raggiungibili tramite il Proxy

esempio di file batch:

jre\bin\java -jar InitConfiguration.jar 7.3 jre\bin\java -Xms128m -Xmx1024m -Dhttp.proxyHost=proxy.lan.local -Dhttp.proxyPort=80

 

Per Approfondimenti:

http://docs.oracle.com/javase/6/docs/technotes/guides/net/proxies.html