Nei sistemi ONTAP 8.x e ONTAP 9.x esistono più file di log. Se si intende esaminare i log di ONTAP il miglior posto in cui cercare è il registro EMS. L’Event Management System(o EMS) raccoglie, in pratica, tutti gli eventi notificati dal sistema operativo ONTAP (https://en.wikipedia.org/wiki/ONTAP).

L’EMS fornisce, inoltre, anche un meccanismo di filtraggio per una facile revisione. Gli eventi EMS possono essere visualizzati direttamente dalla clustershell; di seguito qualche comando utile:

• event log show

Il comando presentato sopra mostra l’elenco degli ultimi eventi, possiamo anche scegliere di visualizzare gli eventi indicando un range temporale espresso in minuti, come ad esempio tutti gli eventi degli ultimi 15 minuti:

• event log show -time >15m

Oppure, per essere ancora più precisi nella ricerca, possiamo indicare un periodo temporale ben preciso con:

• event log show -time “2/1/2018 13:00:00″..”2/1/2018 14:00:00″

da notare che l’output parte dal valore indicato nella parte destra, cioè mostra gli eventi a partire dalle 14:00:00 in ordine decrescente.

Se, ad esempio, desiderassimo vedere solo tutti gli errori basterà invece indicare esplicitamente la severity corrispondente come segue:

• event log show -severity ERROR

Le voci di severity utilizzabili, per questo livello di filtraggio, sono le seguenti:

1.       emergency
2.       alter
3.       critical
4.       error
5.       warning
6.       notice
7.       informational
8.       debug

In questo breve post espongo le otto migliori pratiche di gestione di un progetto, apprese strada facendo. Qualora riteneste valide queste indicazioni potreste attuarle presso la vostra azienda, credo vi potrebbero aiutare a mantenere un flusso di lavoro snello, adeguato ed a motivare i vostri dipendenti.

Sono semplici riflessioni, nulla di accademico; ho infatti rivolto semplicemente, ai miei colleghi, una domanda: cosa odiano i programmatori? In pratica cosa li manda fuori di testa?

(1) I requisiti del software non chiari

Spesso il primo problema riscontrato è il gap dei requisiti. Un progetto non ben chiaro oppure una comunicazione non chiara tra il cliente, i responsabili di progetto e gli sviluppatori, conducono alla creazione di software difettosi oppure incompleti.

Se cliente ed il responsabile del progetto non sono abbastanza specifici sul prodotto richiesto, non dovrebbero aspettarsi che gli altri leggano le loro menti e facciano il lavoro che loro non hanno svolto correttamente. I programmatori non sono legilimens.

È il compito di un manager raccogliere le specifiche del progetto e renderlo più completo possibile, per cui gli sviluppatori non hanno bisogno di indovinare oppure chiedere più volte le specifiche.

(2) Le attività ripetitive

Il problema qui può essere, ad esempio, far lavorare un programmatore molto su un progetto per un lungo periodo. Può anche essere il caso di un cliente che cambi spesso la propria idea su una o più funzioni dello stesso software. In entrambi i casi, se uno sviluppatore si sente bruciato dalle attività ripetitive che sta facendo, forse è giunto il momento di parlarne.

Se possibile, spostare il dipendente in un altro progetto. A volte un semplice cambiamento dei task su cui uno sta lavorando può essere defaticante e serve a mantenere il dipendente motivato.

(3) L’entropia del software da debito di progettazione

Il debito di progettazione è l’effetto causato dall’adozione di una semplice soluzione senza però tener conto della futura scalabilità del progetto. In sintesi, riflette il lavoro di sviluppo aggiuntivo che si presenta quando viene utilizzato codice facile da implementare nel breve periodo anziché applicare la migliore soluzione a lungo termine. La ragione per cui gli sviluppatori odiano questo tipo di debito è semplice: proprio come il caso di un debito finanziario, ci sarà un momento per “restituirlo”, che in termini di sviluppo significa affrontare nuovamente lo stesso problema.

Per risolvere il problema, gli sviluppatori spesso devono riscrivere il codice per terminare “il lavoro non completato”. Inoltre, causa scadenze mancate, in quanto è chiaramente difficile stimare quanti lavori sono necessari per pagare il debito stesso maturato.

La soluzione da applicare è semplice: non cadere nella scelta più semplicistica solo perché più facile quando si pianifica. Pensate alla soluzione valida una volta per tutte. Questo debito non è necessariamente una cosa negativa, talvolta il debito di progettazione (o debito tecnico se preferite) è positivo e necessario per far evolvere i progetti.

Questo breve articolo vi fornirà utili informazioni su come controllare la versione di Bash presente sul vostro sistema operativo. Potrà sembrarvi banale ma al sottoscritto è capitato un paio di volte di dover risalire alla versione in uso della shell per adattare degli script.

1 – Controllo della versione utilizzando il comando bash

Il modo più semplice ed immediato per controllare la versione di Bash è eseguire il comando shell bash con l’opzione di comando –version:

dal comando appena usato si evince che la versione della Bash presente nel sistema è la 4.4.20, direi un metodo veloce ma con un output prolisso se vogliamo.

A volte capita di dover eseguire uno script PHP da command line; ed è ancora più frequente il dover ritoccare alcuni parametri del file di configurazione del PHP prima di eseguire il comando stesso. Per stabilire dove e quale sia il file da modificare basterà inserire in un terminale il comando:
php -r ‘phpinfo ();’| grep “Configuration File”
come output vedremo qualcosa di simile:
Configuration File (php.ini) Path => /etc/php5/cli
Loaded Configuration File => /etc/php5/cli/php.ini.

Buon PHP a tutti!

Redirigete il crontab attuale su un file:
$ crontab -l > filecron.txt

Modificate il file appena creato con un editor (VI, nano, ecc.):
$ vi filecron.txt

Infine, aggiornate il crontab con il nuovo file:
$ crontab filecron.txt

Tutto qui.

Quando si usa il comando su per diventare utente root oppure per assumere l’identità di un altro utente, si può usare il comando suspend per tornare momentaneamente alla sessione di shell precedente.

Per tornare alla sessione di root lasciata poco prima, si può invece usare il comando fg.

Nel caso si sia avviata una shell di login (per esempio con il comando su -), allora si può forzare il ritorno alla shell precedente, con il comando suspend -f.

Un messaggio per avvisare tutti gli utenti collegati di disconnettersi dal sistema:
# wall prego disconnettersi urgentemente dal sistema!!

Se gli utenti non si disconnettono da soli si può fare così:

1. si vedono i pid degli utenti ancora collegati alla macchina con:
# who -a | grep pts

2. quindi si procede con il comando:
# kill <pid utente>

Fuori tutti!

Il PHP è comunemente considerato un linguaggio di scripting sicuro. Questa convinzione deriva dalle innumerevoli funzioni messe a disposizione degli sviluppatori ed attivabili dal file di configurazione globale php.ini o direttamente dal codice con l’apposita funzione ini_set().
A dispetto dalla sua robustezza sotto questo profilo, il PHP rimane però uno dei linguaggi maggiormente sfruttati oggi da hacker, virus e malware writer per attaccare i server che lo supportano.
Quello che segue è un elenco delle funzioni più comuni del linguaggio, seguite da una breve descrizione e dal tipo di parametro che è consigliato specificare (on per attivare la funzionalità ed off per disattivarla):
- register_globals: consente agli utenti di indicare variabili e valori iniettandoli nel contesto del programma con il rischio di alterarne la logica (ad esempio far credere ad un’applicazione di essere un utente autenticato quando invece non lo è). E’ consigliato impostare questa opzione ad OFF.
- magic_quotes: è un processo che automaticamente effettua l’escaping (ovvero la messa in sicurezza) dei dati acquisiti in ingresso dagli script PHP. Pur l’apparente utilità di questa feature è consigliato effettuare un controllo dei dati a runtime impostandola quindi ad OFF.
- allow_url_fopen: questa opzione consente di accedere a file remoti attraverso i protocolli ftp o http. Per ragioni di sicurezza (vulnerabilità di tipo File Inclusion) è consigliato impostare quest’opzione ad OFF.
- safe_mode: abilita la modalità sicura del PHP. E’ consigliato impostare questa opzione ad ON. Essa fornisce accesso ad una serie di sotto opzioni. Con safe_mode_include_dir è ad esempio possibile specificare una o più directory in cui risiedono file di tipo include, mentre con safe_mode_exec_dir è possibile indicare dove sono localizzati gli eventuali file eseguibili richiamati dall’applicazione PHP. Tutti i file all’esterno di queste directory non potranno essere acceduti.
- safe_mode_gid: effettua una comparazione sul group id (GID) prima di accedere ad un file. E’ consigliato attivare questa opzione impostandola ad ON.
- open_basedir: limita i file che possono essere acceduti dagli script PHP ad una o più directory specifiche. E’ consigliato utilizzare questa opzione.
- session.auto_start: specifica se le sessioni sono avviate automaticamente o richiedono una fase di startup. Per motivi di sicurezza e praticità è consigliato disattivare questa opzione impostandola ad OFF.
- session.entropy_file: indica il percorso di una risorsa che può essere utilizzata come ulteriore fonte di entropia per il processo di generazione degli identificativi di sessione. E’ consigliato impostare questa opzione al file speciale “/dev/urandom”.
- session.cookie_secure: specifica se i cookie di sessione devono essere inviati solamente attraverso canali di comunicazione sicuri. E’ consigliato attivare questa opzione impostandola ad ON.
- session.cookie_httponly: preclude l’accesso al cookie di sessione da parte di javascript o altri linguaggi client-side. Per ragione di sicurezza è consigliato impostare questa opzione ad ON.
- display_errors: determina se gli eventuali errori generati dagli script PHP devono essere riportati all’utente nella pagina web richiesta. Per questioni di sicurezza (Information Leak) è consigliato disattivare questa opzione (OFF).
- expose_php: è consigliato disattivare questa opzione impostandola ad OFF. In questo modo si riduce le possibilità che il sistema possa essere individuato come web server vulnerabile da scansioni automatizzate degli header HTTP.

Alcuni consigli per sviluppare applicazioni sicure nel linguaggio PHP

Il PHP è un linguaggio interpretato ampiamente utilizzato per la creazione di script dinamici. Nato da un’idea di Rasmus Lerdorf nel 1994, è divenuto uno standard de facto per lo sviluppo di applicazioni web. Il PHP è considerato un linguaggio comunemente sicuro, ma nonostante questo è allo stesso tempo uno dei più sfruttato da hacker, virus e malware writer per diffondere software malevolo.
Gran parte delle vulnerabilità software è oggigiorno riconducibile allo scarso filtraggio dell’input utente.
Il presupposto comune è che i dati acquisiti in ingresso sono sempre consistenti e frutto di richieste provenienti da utenti autorizzati. Niente di più sbagliato! Nessuna variabile dovrebbe essere considerata costituita da dati la cui regolarità non può essere comprovata. Ciò si riduce a dire che tutto l’input utente deve sempre essere controllato/filtrato per accertare che sia conforme con il tipo, le logiche e le operazioni che su di esso l’applicazione deve svolgere. In particolare devono essere previste i seguenti accorgimenti:
• Tutti i caratteri che possono avere una qualche valenza per l’interprete dei comandi (! $ ^ & * ( ) ~ [ ] \ | { } ‘ ” ; < > ? – `) o l’helper SQL (# ? % ‘ “ — ;) devono essere filtrati. Poiché alcuni di questi caratteri sono anche utilizzati per rappresentare tag HTML validi è importante prescindere dal tipo di dato che si sta acquisendo in input prima di operare un adeguato filtraggio;
• Altri caratteri che potrebbero creare problemi, troncamenti o effetti indesiderati durante l’accesso a file o risorse DB sono il terminatore stringa (\0), il ritorno a carrello (\x10), la nuova riga (\x13) ed ASCII 26 (\x1a). Questi vanno opportunamente gestiti.
- La quantità di input che l’utente può inviare in una form deve essere sempre dimensionato in modo da non eccedere i limiti della direttiva memory_limit impostata nel file di configurazione del PHP (valore di default 8 MB);
- I nomi dei file hanno solitamente una dimensione limitata a 255 byte. Quando si progetta un’applicazione PHP che accede sul disco è sempre bene considerare questo elemento. Eventuali loro troncamenti dovuti ad un poco accorto dimensionamento dell’input utente potrebbe generare effetti disastrosi o inaspettati;
- Ogni script che invia e-mail verso l’esterno può essere potenzialmente abusato così come gli hidden field di una form. Bisogna sempre accertare i permessi assegnati all’utente prima di decidere se eseguire un’operazione;
- Tutte le variabili dichiarate nell’applicazione devono essere inizializzate;
- E’ consigliato offuscare tutte le pagine PHP dell’applicazione;
- I valori utilizzati con la funzione header() devono essere privati dei caratteri speciali “\r” (\x0a) ed “\n” (\x0c);
- I file inclusi nel codice PHP devono avere estensioni riconosciute dal web server come codice interpretabile e non come text/plain visualizzabile.

Ci sono 9 comodi usi per il comando find in Linux, che non tutti conoscono e che vengono spiegati in questo tutorial. Come path in ogni esempio verrà utilizzato /root ma e’ possibile utilizzare qualsiasi altro path.

1)Trovare directory vuote:
find /root -depth -type d -empty

2)Trovare file vuoti:
find /root -depth -type f -empty

3)Trovare file con nomi specifici:
find /root -name [name_of_file]

4)Trovare un file con una specifica estensione:
find /root -name “*.[given_extension]”

5)Trovare file con specifici permessi:
find /root -perm [permission bits]

6)Trovare file di determinate dimensioni:
find -size n[cwbkMG]
find /root -name ‘*.txt’ -size 4k -exec ls -l {} ;

7)Trovare un file con un certo nome ed una qualsiasi estensione:
find -name ‘[given_name].*’

8)Trovare un file modificato nelle ultime 24 ore:
find -mtime n
dove 0 sta per 24 ore, 1 per 48, 2 per 72 e cosi’ via.

9)Trovare file a cui si e’ acceduto nelle ultime 24 ore:
find -atime n
dove 0 sta per 24 ore, 1 per 48, 2 per 72 e cosi’ via.