ago 142011
 

brokenDopo alcuni studi, o forse un corso specialistico o presentazione si desidera iniziare a implementare nella propria azienda le buone pratiche che si hanno imparato, e magari iniziare così una nuova. e migliore, era per il vostro reparto IT.

Ma sembra che qualcosa vada sempre nel modo sbagliato o ci siano difficoltà inattese che fanno fallire tutti i vostri progetti, e sogni, e dopo qualche combattimento di solito si finisce con il dire “ok, quella ERA la migliore pratica e siamo sicuri di non seguirla”.

Questa è la mia lista delle cose che ho trovato impossibile da realizzare in alcuni anni di lavoro.

Corretta pianificazione dei progetti.

Prima di iniziare qualsiasi cosa, mi piacerebbe sapere lo scopo principale di un progetto, i requisiti del cliente, il bilancio, per quanto tempo il progetto deve essere in linea o funzionare e quante persone possono lavorare su di esso. Dopo aver saputo tutte queste informazioni fare un progetto con tutti i software e hardware necessari e calcolare i tempi per completare tutte le fasi.

Con una corretta pianificazione tutto diventa più facile ed è possibile installare e gestire molti sistemi e servizi on-line senza troppi problemi.

Quello che mi capita di solito è:

“Abbiamo un nuovo cliente, vuole in 2 settimane il suo nuovo portale pronto, ha un sacco di accessi al suo sito web che deve essere sempre online quindi fai qualcosa che abbia l’alta disponibilità!”

“Abbiamo un nuovo cliente, dobbiamo finire in 2 settimane il suo mega progetto XX, ma sono solo un paio di macchine Linux con YYY (mettere una distro sconosciuta qui) che utilizzano questo software (mettere un software sconosciuto qui) con questo DB (mettere un DB sconosciuto qui). ”

“Abbiamo un nuovo cliente, vuole il suo sito e-commerce, con bilanciamento del carico tra 4 macchine, tutto replicato e mantenuto da noi, richiede un uptime del 99,9999%, il bilancio per il progetto è YYY (mettere un budget troppo basso qui ). ”

Sicurezza

La sicurezza è una cosa importante in ogni compagnia, è possibile avere buoni servizi, ma il cliente sarebbe felice di sapere che tutti i suoi dati sono stati rubati (Sony ?).
La sicurezza non è una cosa che si può fare nel tempo libero o 1 volta ogni 6 mesi, è un insieme di best practice, regole econfigurazioni che devono essere seguite ogni giorno, purtroppo, fino a quando è troppo tardi, nessuno sembra interessato alla sicurezza.

Ad esempio si potrebbe avere un insieme standard di regole per creare gli account sulle macchine e configurare il firewall su tutte le macchine Linux e un insieme standard di configurazioni, e questo è un buon punto di partenza, ma questo diventa inutile se si ricevono richieste quali:

“Aggiungi un account sul server di DB per John Smith, è un nuovo consulente, che deve essere in grado di fare start/stop del DB e modificarne i file di.”

“Apri queste porte sul firewall della macchina XX (o arresta il firewall), il team di sviluppo deve fare qualcosa e il firewall li blocca.”

“Non aggiornare il software su questi server, il team di sviluppo non è sicuro che con la nuova versione di libXX il loro software funzioni”.

E questo mi ricorda un altro punto

Aggiornamenti

Il mio motto potrebbe essere “meglio aggiornati che dispiaciuti”, sul mio desktop aggiorno il sistema operativo il giorno in cui diventa stabile e mi piacerebbe avere per i server un giorno previsto al mese per gli aggiornamenti, ed essere pronti a fare qualche aggiornamento in più se qualche grosso bug di sicurezza viene scoperto.

Avere un sistema aggiornato significa che siete al sicuro da bug di sicurezza conosciuti, da errori del codice ed avere tutte le ultime caratteristiche di questo software, naturalmente se avete usato un certo software si dovrebbe sapere cosa significa che “la funzione XX ora si chiama XX_h”, e sapere se il software che abbiamo prodotto potrebbe esserne influenzato o no.
In caso di dubbio utilizzare un server di prova per applicare gli aggiornamenti e se tutto va bene aggiornare i server di produzione.

Quello che succede molte volte, è che un sacco di manager usano il motto “Fino a quando funziona non lo toccare”, quindi ho visto installazioni di distribuzioni Linux fatte dal CD originale e mai aggiornate, “il servizio funziona, perché cambiare qualcosa” ?

O peggio, molte persone che non capiscono appieno l’open source utilizzano ora CMS di questo tipo (Drupal, Joomla, WP), perché sono ottimi e sono gratuiti, per loro la parola magica è gratis da licenza, ciò che queste persone non capiscono è che non si può tenere un CMS open source di 2 anni fa on-line, con tutto il mondo che conosce il suo bug di sicurezza e sperare che funzionerà per sempre, ho visto almeno una dozzina di siti violati con bug CMS conosciuti .

O la cosa peggiore è quando chiedo aglii sviluppatori se posso aggiornare XX (mettere un modulo perl, php, o una JVM), di solito la loro risposta è “Noi certifichiamo solo la versione FF, quella che stiamo usando da 1 anno ” e quindi io non posso aggiornare nulla…

Ambiente Uniforme

Per rendere le cose semplici la soluzione migliore potrebbe essere: avere 1 distribuzione allo stesso livello su tutti i server ed usare solo 1 tipo di applicazione per fornire servizi (Java, Ruby, PHP).
Posso capire che questo può diventare troppo rigido, nel tempo usciranno nuove versioni della distribuzione e non è così facile aggiornare tutti i server, o nello sviluppo gruppi diversi potrebbero utilizzare software differenti.

Ciò che davvero non capisco è l’uso di molte soluzioni diverse nello stesso centro dati, per esempio: Red Hat per le macchine Jboss, Debian per i server Lamp, CentOS per la macchina dello sviluppo e Suse per il DB, e quando si chiede perché? A volte la risposta è “A l’ex sistemista XX piaceva questa Distro, o il consulente ci ha detto di usare quella distro” cose che per me non hanno alcun senso, avere più distro significa che il vostro amministratore di sistema deve avere molte più conoscenze.

E la stessa cosa si applica allo stack software per il servizio, di recente ho visto un servizio che usa Tomcat con un’applicazione Java per una sezione del sito, Apache e Perl per l’altro e php per eseguire delle operazioni pianificate tramite crontab. Una follia ai mie occhi…

Conclusioni

Mi piace essere un amministratore di sistema e nei miei sogni c’è una logica dietro a tutte le macchine ed i servizi di cui sono responsabile, ma come molti sogni questo si scontra con la realtà ..

Popular Posts:

flattr this!

  7 Responses to “I sogni infranti di un amministratore di sistema Linux”

  1. This is why I got out of IT. I was also tired of having to repeatedly explain why I didn’t arrive back at work before noon after being up past midnight working on the network. For some reason it didn’t seem logical to management to take the network offline after the majority of computer users went home. I guess they may have believed that most of the users were lazy so having their systems unusable for a few hours didn’t affect productivity.

    You should check out the IT horror stories at the Computerworld Shark Tank. Get yourself a free T-shirt for sharing one. I did.

  2. i am a developer ans system administrator, so i can understand both sides.
    the job of a sysadmin is to serve the users, because if you don’t serve them they will work around you and your job will be much worse.

    on your security points for example, i’d go find out why these requests are made. what is it that the db guy really needs to do? what are the developers trying to do? maybe they need to be put in a seperate subnet to protect the rest of the network while the developers are more exposed.

    as for the update of software, that’s sometimes an outside problem, sometimes it is just an issue of timing. not sure how it can be helped other than strengthening outside protection, maybe having policies that require developers machines to be uptodate, keep developers alerted about upcoming upgrades so they can prepare for it. i’d maybe also make the security team part of the development team and have them involved in decisions about which versions are best for supporting.

    as for the uniform environment, i simply disagree with that one.
    one of my clients had standardized on fedora. sure, not the best choice, but it worked.
    then asterisk came along.
    asterisk is best supported on centos. do you think i put it on a fedora machine? no way. that would have meant extra work for me for something that is meant to be extra stable.
    people can deal with a hickup on a desktop. but have the phones go down and they cry bloody murder.

    yes, tracking multiple distributions is more work if they all do the same job, but i found that some distributions are not suitable for some things. for servers i want something really stable, debian stable, centos, etc…
    but on desktops people want newer software, so we need something like ubuntu, fedora. or even foresight.

    developers are a mixed bag, on the one hand the need new versions of tools, and on the other they may need to deploy on stable servers. the best advice i have seen here recommends that every developer have a different system, that way ensuring that the product being developed runs on the widest selection of different systems (that includes mac os, windows and a few different linux distributions, maybe even bsd or solaris.)

    also, a homogeneous environment is easier to attack. if the attacker found a way itno one machine, then all machines are accessible, whereas in a heterogeneous system such attacks are less easy to exploit.

    greetings, eMBee.

    • Thanks for the long answer eMBee, i’m sure there are both side of the medals, and for the developers a sys admin with his weird idea could be a nightmare.

      And for distro, desktop and server should follow different paths IMO, just keep the same package manager if possible so Red hat/CentOS on server and fedora on Desktop, or Debian on server and Ubuntu on Desktop…

  3. Forse e’ il caso che tu segua anche qualche corso per imparare l’italiano!

    • Be di sicuro non mi farebbe male, avendo fatto solo studi tecnici ;)
      Rilancio con un ripasso generale dell’inglese dove faccio degli orrori :)

  4. Having multiple Linux distros never bothered me. Starting with Slackware seems to have helped with those kind of experiences. I’d love to have that situation over the multiple versions of windows and office that I’m stuck with.

  5. The upgrade hate also bugs me. Recently I was shown an ubuntu machine that served as a webserver and they want me to secure it… But it was so f**** old the support ended (not LTS even), so no repos no nothing.

 Leave a Reply

(required)

(required)


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>