Prendo spunto da un articolo pubblicato su Gioia e twittato dalla spumeggiante Denai per postare il mio punto di vista su un argomento piuttosto delicato, il mondo delle partite iva.
Lavoro ormai da quindici anni nel settore IT, terreno fertile per le piva (vere o false), iniziai giusto nella fase calante della cosidetta “bolla IT” dove le aziende macinavano utili a randa e la gente veniva pagata anche solo per generare costi e ridurre l’imponibile per le tasse.

Era un periodo in cui le aziendine informatiche spuntavano come funghi, bastava scrivere quattro tag html con un editor di testo per fatturare quelli che oggi sarebbero 1000 euro al giorno, insomma si facevano “i big money”.
Poi la bolla scoppiò e fu pianto e stridore di denti, ma fino ad allora per chi si affacciava sul mercato IT le due formule di assunzione più gettonate erano: tempo indeterminato o contratto di collaborazione continuativa.
Io delle due scelsi la prima, fui perculato da ex colleghi come ingenuo, poi la marea cambiò, i co.co.co divennero co.co.pro. con maggiori restrizioni, i suddetti piansero lacrime e sangue a causa della loro ingordigia (a me rise anche l’elastico delle mutande) e via di questo passo fino alla precarietà e invasione delle (in gran parte false) partite iva.

Ora, io non ho nessuna intenzione di scatenare flame o dare addosso in alcun modo a chi ha una partita iva e non si sente valorizzato (professionalmente o economicamente), lungi da me mancargli di rispetto o banalizzare gli oggettivi problemi (pagamenti in primis) che affliggono questa categoria… però francamente trovo l’articolo di Gioia banale e sbagliato.
Quello descritto delle piva è una faccenda complessa, pertanto non può essere liquidata in modo così netto e soprattutto generalizzando, ne dal punto di vista dei lavoratori autonomi ne di quello dei dipendenti.

Anzitutto imho occore distinguere tra piva vere e piva fasulle; le prime sono una scelta, le seconde sono una forzatura e un errore che deve sparire.
Chi è stato (o si è sentito obbligato) ad aprire la piva ma di fatto fa lavoro dipedente, degradante e sottopagato, non si deve azzardare a vomitare sui lavoratori dipendenti la propria condizione o il proprio disagio; uno può anche essersi trovato in questa condizione ma non è colpa di nessun altro, se non di se stesso, se decide di rimanere in questo stato, se non fa valere i propri diritti di lavoratore autonomo e subisce ogni cazzata che l’azienda/sfruttatore di turno gli rovescia addosso.
I propri diritti si fanno valere ANZITUTTO personalmente, facendosi aiutare da chi ne sa più (es sindacati, perchè no?) ma dandosi da fare, non scaricando sugli altri le proprie ingiustizie.

Chi invece la partita iva l’ha scelta di proposito e si comporta da vero libero professionista imho non ha diritto di lamentarsi tranne che per gli impedimenti burocratici (es lungaggini della giustizia per farsi riconoscere quanto dovuto, e qui mi piacerebbe parlare con i fan di mister B. e della sua fregola sulla giustizia penale, quando invece la vera piaga sta nella giustizia civile) e per quali non smetterò mai di essere solidale; per il resto, es retribuzione non adeguata o scarsità di clienti, mi spiace ma hai voluto la bicicletta?

Tema tasse, ci sono per tutti e fino a prova contraria in Italia l’unica categoria che le paga, le ha sempre pagate e le pagherà sempre sono i lavoratori dipendenti, e questo è un dato OGGETTIVO e INCONTROVERTIBILE.
Qui le piva si disperano, si sentono tartassate etc etc, e qui parte la whinata del secolo… poi non appena il lavoratore dipendente alza la cresta partono come piranha affamati in flame infiniti.
Amici liberi professionisti, permettete che vi dia un consiglio, se dovete incazzarvi (e ne avete tutto il diritto) fatelo con i vostri colleghi liberi professionisti che non hanno mai pagato un centesimo di quanto avrebbero dovuto, fatelo con gli “imprenditori” (le virgolette non sono un caso) che intestano alla società anche la cuccia del cane, fatelo con i vostri rappresentanti che sparano bordate contro i sindacati, salvo poi zittirsi di fronte alle aziende che frodano il fisco, che rastrellano finanziamenti pubblici per poi sparire, che si teletrasportano in Transnistria per spremere ogni centesimo di utile, che pagano il pizzo e non denunciano, che sono colluse con la malavita, che sfruttano i poveracci come schiavi (e di casi del genere da ragazzo ne ho visti anche nella “eccellente eccellenza lombarda”).
Voi state pagando ora le porcate che ieri (ma anche oggi) i vostri colleghi hanno causato, non certo i lavoratori dipendenti o i sindacati.

Per concludere permettetemi poi di sfatare la cazzata secondo cui chi apre una piva è un superuomo o un martire da venerare, mentre chi sceglie il lavoro dipendente un pavido fannullone.
Ci saranno casi ascrivibili a questi esempi, ma sono certamente una sparuta minoranza statisticamente non significativa.
La scelta imho non è solo economica, ma soprattutto di carattere e di obbiettivi che il singolo si pone nei confronti del lavoro; chi sceglie le piva lo fa per l’indipendenza, perchè non ama veder programmato il proprio lavoro da altri (cosa che comunque avviene in parte, visto che il cliente ha sempre ragione… e lo so bene lavorando come consulente presso clienti), chi sceglie il lavoro dipendente lo fa perchè ha altro nella testa, oppure perchè non ne vuole sapere di fare altro al di fuori del proprio lavoro.
Io sono tra questi ultimi, non voglio sapere nulla di fatture, margini, contrattazione, pagamenti, a me piace il mio lavoro, è la mia passione e il mio divertimento, io voglio fare solo quello, punto.
Se una persona apre la piva pensando di dedicarsi solo all’attività pratica senza pensare a tutto il resto o pensando che sia secondario… beh ha sbagliato di grosso.

Dimenticavo, se qualcuno (es Gioia) insiste sulla favoletta secondo cui i lavoratori dipendenti vivono sereni con i loro stipendi garantiti, gli consiglierei di farsi un giro nelle aziende (ormai la maggior parte) piene di lavoratori in cassa integrazione, di contratti di solidarietà, di lavoratori in mobilità, o nella migliore delle ipotesi in tutte quelle aziende (ormai si fa prima a contare quelle che non lo sono) che hanno mensilità arretrate da saldare, magari da anni…
Bella vita, eh?

Just my 2 cents.

Tra i millemila tool di backup basati su rsync che mi è capitato di usare su macchine GNU/Linux c’è anche Duplicity.

L’oggetto è certamente degno di nota per semplicità d’uso, per la sicurezza (supporta protocolli di trasferimento cifrati come sftp e la cifratura stessa dei backup mediante gpg) e per l’efficacia.
Certamente ha delle pecche, prima fra tutte la scarsa gestione delle eccezioni e le notifiche in caso di errore, però tutto sommato è uno strumento con delle buone potenzialità e margini di miglioramento.
Non mi sento di consigliarlo come il miglior tool di backup per server, lo trovo però ottimo per singole workstation o postazioni di lavoro su cui c’è una continua presenza umana (sia chiaro che però il software può e deve girare schedulato).

Ecco un esempio di sintassi per un semplice backup full settimanale delle directory /etc, /var/log, /root, /var/www, /backup effettuata tramite sftp…

#/bin/bash
 export PASSPHRASE=<VOSTRA PASSPHRASE>
 DEST="sftp://<UTENTE>@<HOST>:<PORTA>//directory/di/destinazione"

/usr/bin/duplicity --full-if-older-than 1W --timeout=100 \
 --ssh-backend pexpect \
 --use-scp \
 --volsize=100 \
 --include="/etc" \
 --include="/var/log" \
 --include="/root" \
 --include="/var/www" \
 --include="/backup" \
 --exclude="**" / \

$DEST

…seguita dalla sintassi per effettuare un altrettanto semplice repulisti dei backup più vecchi di un mese.

#/bin/bash
export PASSPHRASE=<VOSTRA PASSPHRASE>
DEST="sftp://<UTENTE>@<HOST>:<PORTA>//directory/di/destinazione"

/usr/bin/duplicity remove-all-but-n-full 4 --force $DEST

Ovviamente potete includere entrambi i comandi per schedulare le due operazioni con lo stesso script bash.

A volte può capitare che usando i consueti strumenti si rimanga incastrati in qualche assurda condizione apparentemente senza via d’uscita, guardacaso per un sistemista questo genere di situazioni si verificano quasi esclusivamente usando OS Windows Server…

Supponiamo ad esempio che vi ritroviate nella condizione di recuperare la password di Administrator di una macchina su cui è installato Windows Server 2012, di primo acchito verrebbe da utilizzare Offline Windows Password & Registry Editor, ottimo tool che permette di cancellare (blank) la password di Administrator mediante una piccola immagine live con cui fare il boot del sistema.
Peccato che in questo modo rischiate di schiantarvi contro l’assurda default policy di questa versione che non permetta di loggarsi con password nulla (l’amministratore di sistema deve poter fare TUTTO, anche la cosa più stupida come dimenticarsi un sistema con password di superuser nulla.), ritrovandovi quindi con la password recuperata (vuota) ma inservibile per fare il login.

In questi casi non occorre fare altro che recuperare una qualsiasi ISO di installazione di Windows Server e fare il boot da essa, alla prima finestra che presenta la selezione della linga proseguite.

Alla schermata successiva cliccate sul link “Ripristaina il computer”.

Proseguite poi fino ad aprire il prompt dei comandi.

Identificate il drive di sistema (nell’esempio D:).

Spostatevi nella directory Windows\System32 e fate un backup del file Utilman.exe (copy Utilman.exe Utilman.exe.bak), fatto questo sostituite il file Utilman.exe con cmd.exe (copy cmd.exe Utilman.exe).

Digitate exit al prompt e riavviate il sistema facendo il boot regolarmente da storage, arrivate alla schemata di logon premete tasto Windows + u oppure cliccate sulla icona di usabilità (evidenziata in rosso) per aprire una finestra di prompt.

Digitate il comando “net user administrator <NUOVA PASSWORD>” per modificare la password dell’utente Administrator locale (nell’esempio “Passw0rd”), dopo di che chiudete la finestra di prompt e loggatevi con la vostra nuova password.

Prima di vantarvi con colleghi, clienti e superiori ricordatevi di ripristinare il backup del file Utilman.exe (copy c:\Windows\System32\Utilman.exe.bak c:\Windows\System32\Utilman.exe).

Ok, ora che vi siete vantati con colleghi, clienti e superiori riflettete su quanto sarebbe stato più facile bootare in single user mode per cambiare password di root su un sistema GNU/Linux. :O

Di recente il protocollo HTTPS è al centro di attenzioni di cui purtroppo fin’ora non aveva mai goduto, per questo stanno emergendo una serie di vulnerabilità che fino ad oggi sono state sottovalutate dalla gran parte degli utenti e degli addetti ai lavori.

Per adeguarsi alle nuove best practice i browser si sono evoluti inserendo configurazioni sempre più restrittive nell’accesso https ai siti.
Tutto bene, tutto bello (e ci mancherebbe), purtroppo però come sappiamo il mondo dell’IT è tutt’altro che uniforme o allineato alle ultime versioni di ogni tecnologia; specialmente in ambito lavorativo capita di trovare prodotti vetusti, interfacce web per la gestione di dispositivi hardware, piuttosto che architetture che per mille motivi non possono essere aggiornate, e quindi utilizzano il vecchio e insicuro protocollo SSL2 o SSL3.
Sia chiaro, si tratta di servizi non esposti sul web, dove quindi il rischio di attacco è estremamente basso o comunque gestito mediante opportune politiche di accesso perimetrali (anche su più livelli).

Che fare quindi per riattivare la compatibilità con il vecchio protocollo e accedere in https a questi servizi ritenuti insicuri dai browser?
Firefox ci viene incontro dando la possibilità di riattivare manualmente la considetta fallback ssl3.

Aprire il browser e digitare nella barra degli indirizzi about:config, nel caso vi comparisse un warning di sicurezza come questo confermate premendo l’apposito pulsante.

Inserite nella campo cerca la stringa security.tls.version.min e settatene il valore a zero.

Fate lo stesso per il campo security.tls.version.fallback-limit settandone il valore a zero.

A questo punto non vi resta che riavviare il browser per rendere effettiva la modifica.

Ricordate di ripristinare il valori di questi due parametri di configurazione al termine dell’attività o comunque prima di accedere a siti web.

Spesso si sente ripetere in modo un po’ banale che la condizione necessaria per un backup consistente è il test di restore, io di solito considero necessarie queste condizioni:

• il backup deve essere fatto (…)
• va effettuato un test di restore periodico
• il backup deve essere schdulato e automatico (non deve dipendere da azioni manuali)
• il backup deve inviare notifiche su eventuali anomalie occorse durante la schedulazione

Quest’ultimo aspetto ahimè è spesso ignorato, oppure ci si affida a notifiche inviate a prescindere senza distinguere l’effettivo esito del processo (troppe informazioni che inevitabilmente comportano la mancata rilevazione di un problema).

Questa la premessa, come ho già avuto modo di dire mi capita spesso di sguazzare tra vecchi ruderi informatici sparsi per i datacenter più insospettabili, di recente mi è capitato di mettere le mani su un server MS SQL (brrr…) 2000 (brrr²….) con piani di manutenzione disastrati e backup in uno stato di completo abbandono.
Come solo i vecchi sistemisti ricorderanno MS SQL 2000 richiede ufficialmente l’utilizzo di Exchange (brrrr³…) per inviare notifiche email sull’esito dei maintenance plan, un autentico furto a mano armata…

Come alternativa propongo questa semplice soluzione che non comporta alcuno stravolgimento architetturale ed è applicabile anche a versioni più recenti del database MS (che per fortuna hanno colmato questa lacuna con apposite procedure).

Prosegui con la lettura »