open your mind
Magari a qualcuno può interessare:
ecco la put:
HOST=hostname
USER=username
PASS=password
echo "Start of sftp put…"
lftp -u ${USER},${PASS} sftp://${HOST} <<EOF
cd directory_path
put filename
bye
EOF
ed ecco la get:
HOST=hostname
USER=username
PASS=password
echo "Start of sftp get…"
lftp -u ${USER},${PASS} sftp://${HOST} <<EOF
cd directory_path
get filename
bye
EOF
E per completare l'opera, dopo aver configurato una vpn pptp per avere il link verso la rete aziendale e dopo aver installato il comodissimo TouchMon Lite for Nagios per avere un'istantanea della nostra infrastruttura, ecco ciò che ci consentirà di aprire una shell sui nostri server aziendali: pTerm. Certamente lavorare sul display dell'iPhone non è come lavorare sul 22" dell'ufficio, ma in casi di estrema emergenza ci possiamo accontentare!:)
Premesso che sono OPINIONI personali, quindi potenzialmente screditabili e opinabili, ecco per quali motivi ritengo vantaggioso far scegliere all'azienda nella quale lavoro una soluzione basata sulla virtualizzazione anzichè una soluzione basata sul dogma "un servizio-una macchina":
1 ) procedura di backup più snella; inoltre il backup è completo, dell'intera macchina;
2 ) ripristino rapidissimo di una macchina in caso di caduta (proprio perchè il backup è dell'intera macchina, è possibile rimettere in piedi un server in pochi minuti); in una soluzione standalone impiegheremmo svariate ore a rifare da zero una macchina;
3 ) ci si slega completamente dall'hardware sottostante, in quanto la virtualizzazione è fatta su hardware standard; questo garantisce omogeneità nelle risorse hardware, che si traduce in maggiore flessibilità a livello software;
4 ) ottimizzazione delle risorse hardware attraverso il consolidamento delle stesse, che consente un bilanciamento delle risorse, potendo quindi quasi azzerare il tempo di idle delle cpu (e sfruttando i socket dual code, quad core e six core, che nella maggior parte dei casi, in soluzioni standalone, rimangono quasi inutilizzati); inoltre le risorse vengono allocate quando e dove necessario;
5 ) struttura controllabile completamente da remoto, attraverso la console di vmware (o xen, o altro prodotto alternativo);
6 ) espansione del parco macchine molto più flessibile, in quanto potrei creare (anche da remoto) un nuovo server e metterlo in produzione in pochi minuti;
7 ) costi più bassi, in quanto non ho bisogno di una nuova macchina fisica per ogni macchina logica; costi più bassi anche in termini di spazio, di consumi elettrici e di connettività;
8 ) è possibile evolvere facilmente l'intera struttura, spostandola su server di nuova generazione, senza dover reinstallare tutto, ma solamente reinstallando lo strato di emulazione e ripristinando i file delle macchine virtuali;
9 ) il testing e il debugging di nuove applicazioni è facilitato, in quanto è possibile testare e debuggare su macchine identiche alla produzione, senza spreco di risorse.
Già da qualche anno monitoriamo la rete aziendale con Nagios, un prodotto eccezionale, sviluppato inizialmente da Ethan Galstad, al quale si è affiancata con gli anni una foltissima community. Negli ultimi giorni abbiamo configurato una vpn PPTP che ci permette di collegarci alla nostra rete attraverso l'Iphone. Attraverso poi la comodissima applicazione Touchmon for Nagios abbiamo a disposizione una semplice interfaccia che ci permette di verificare lo stato della nostra infrastruttura attraverso una visualizzazione molto chiara di host, hostgroup, servizi e problemi. Esiste poi la possibilità di fare "Acknowledge" dei problemi e di schedulare dei downtime.
Ma veniamo alla configurazione… per prima installiamo il software che ci permette di configurare la vpn pptp (io ho utilizzato una macchina con ubuntu 9.10, ma la vpn è configurabile su ogni tipo di sistema *nix like):
apt-get install pptpd
editiamo il file /etc/pptpd.conf e specifichiamo l'indirizzp ip sul quale pptpd si metterà in ascolto e gli indirizzi ip che verrano assegnati ai client che si connetteranno alla vpn:
nano /etc/pptpd.conf
alla fine del file aggiungere:
localip 192.168.0.x (ip della macchina sulla quale è installato il demone pptpd)
remote 192.168.0.x-y (dove x-y è un range di indirizzi a nostra scelta, della stessa network di localip)
modifichiamo (se il file non esiste lo creiamo con il comando touch) ora il file /etc/ppp/pptpd-options:
##################################################
# $Id: pptpd-options 4643 2006-11-06 18:42:43Z rene $#
# Sample Poptop PPP options file /etc/ppp/pptpd-options
# Options used by PPP when a connection arrives from a client.
# This file is pointed to by /etc/pptpd.conf option keyword.
# Changes are effective on the next connection. See "man pppd".
#
# You are expected to change this file to suit your system. As
# packaged, it requires PPP 2.4.2 and the kernel MPPE module.
##################################################
# Authentication
# Name of the local system for authentication purposes
# (must match the second field in /etc/ppp/chap-secrets entries)
name pptpd
# Optional: domain name to use for authentication
# domain mydomain.net
# Strip the domain prefix from the username before authentication.
# (applies if you use pppd with chapms-strip-domain patch)
#chapms-strip-domain
# Encryption
# Debian: on systems with a kernel built with the package
# kernel-patch-mppe >= 2.4.2 and using ppp >= 2.4.2, …
# {{{
refuse-pap
refuse-chap
refuse-mschap
# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
require-mppe-128
# }}}
# Network and Routing
# If pppd is acting as a server for Microsoft Windows clients, this
# option allows pppd to supply one or two DNS (Domain Name Server)
# addresses to the clients. The first instance of this option
# specifies the primary DNS address; the second instance (if given)
# specifies the secondary DNS address.
# Attention! This information may not be taken into account by a Windows
# client. See KB311218 in Microsoft's knowledge base for more information.
ms-dns 10.133.0.236
#ms-dns 10.0.0.2
# If pppd is acting as a server for Microsoft Windows or "Samba"
# clients, this option allows pppd to supply one or two WINS (Windows
# Internet Name Services) server addresses to the clients. The first
# instance of this option specifies the primary WINS address; the
# second instance (if given) specifies the secondary WINS address.
#ms-wins 10.0.0.3
#ms-wins 10.0.0.4
# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system. This will have the effect of making the peer appear to other
# systems to be on the local ethernet.
# (you do not need this if your PPTP server is responsible for routing
# packets to the clients — James Cameron)
proxyarp
# Debian: do not replace the default route
nodefaultroute
# Logging
# Enable connection debugging facilities.
# (see your syslog configuration for where pppd sends to)
#debug
# Print out all the option values which have been set.
# (often requested by mailing list to verify options)
#dump
# Miscellaneous
# Create a UUCP-style lock file for the pseudo-tty to ensure exclusive
# access.
lock
# Disable BSD-Compress compression
nobsdcomp
sembra complicato ma l'unica cosa che ho avuto la necessità di modificare è stata la riga ms-dns, dove ho inserito l'indirizzo del server dns che risolve i nomi delle macchine della nostra rete. E' una comodità in più, ma non è assolutamente indispensabile ai fini dell'implementazione della nostra vpn.
Abilitiamo poi l'ip forwarding sulle interfacce di rete della nostra macchina, che permetterà all'interfaccia ppp (che verrà creata nel momento in cui il client attiverà la connessione vpn) di comunicare con l'interaccia eth0 e quindi di raggiungere la rete che sta dietro a questa macchina. Per fare questo nel file /etc/sysctl.conf aggiungiamo:
net.ipv4.ip_forward = 1
Ora settiamo una password condivisa (metodo di certo non molto sicuro, è preferibile l'autenticazione tramite certificati, che ho trovato un po' laboriosa per quanto riguarda la configurazione su Iphone e che magari sarà argomento di uno dei prossimi articoli) per l'accesso alla vpn. Nel file /etc/ppp/chap-secrets aggiungiamo:
utente pptpd password *
questo indica che l'utente "utente" (ovviamente modificabile a piacere, così come la password), con la password "password", è abilitato a connettersi alla vpn con qualsiasi ip sorgente ("*"). E' possibile, se ad esempio sappiamo che l'utente "pippo", che utilizza la password "pluto", si connette utilizzando un ip statico (www.xxx.yyy.zzz), settare il file in questo modo
pippo pptpd pluto www.xxx.yyy.zzz
Infine riavviamo il demone pptpd:
/etc/init.d/pptpd restart
Ora ci sposiamo sul nostro Iphone:
da General -> Network -> VPN scegliamo PPTP
impostiamo l'indirizzo del server (che sarà un indirizzo pubblico di un router connesso a internet, sul quale avremo configurato un nat 1:1 sull'ip della macchina dove abbiamo installato pptpd), l'utente e la password (quelli specificati nel file /etc/ppp/chap-secrets). Manteniamo RSA SecurID impostato a "Off". La seguente immagine può aiutare a rendere la spiegazione più chiara:
Ora scarichiamo e installiamo l'applicazione TouchMon Lite for Nagios (gratuita, ma esiste la versione a pagamento, che con soli 12,99$ consente di fare Acknowledge" dei problemi e di schedulare dei downtime), attiviamo la vpn, lanciamo TouchMon e… abbiamo la nostra infrastruttura di rete sotto controllo!:)
Chi si fosse chiesto che fine aveva fatto in Ubuntu 9.10 il file che gestisce il default runlevel, eccolo accontentato! Fino a qualche distribuzione fa (credo la 6.10) il file che gestiva il default runlevel era /etc/inittab, successivamente è diventato /etc/event.d/rc-default, mentre con la versione 9.10 si è passati a /etc/init/rc-sysinit.conf
Di seguito un paste dei formati dei 3 file, con la riga dove viene indicato il default runlevel.
/etc/inittab (attualmente utilizzato dalle distro Red Hat like)
# Default runlevel. The runlevels used by RHS are:
# 0 – halt (Do NOT set initdefault to this)
# 1 – Single user mode
# 2 – Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 – Full multiuser mode
# 4 – unused
# 5 – X11
# 6 – reboot (Do NOT set initdefault to this)
#
id:5:initdefault:
/etc/event.d/rc-default
script
runlevel –reboot || true
if grep -q -w — "-s\|single\|S" /proc/cmdline; then
telinit S
elif [ -r /etc/inittab ]; then
RL="$(sed -n -e "/^id:[0-9]*:initdefault:/{s/^id://;s/:.*//;p}" /etc/inittab || true)"
if [ -n "$RL" ]; then
telinit $RL
else
telinit 2
fi
else
telinit 2
fi
end script
/etc/init/rc-sysinit.conf
# Default runlevel, this may be overriden on the kernel command-line
# or by faking an old /etc/inittab entry
env DEFAULT_RUNLEVEL=2
# There can be no previous runlevel here, but there might be old
# information in /var/run/utmp that we pick up, and we don't want
# that.
#
# These override that
env RUNLEVEL=
env PREVLEVEL=
In riferimento al provvedimento relativo agli amministratori di sistema del 27 novembre 2008, ecco come è possibile risolvere la problematica utilizzando una soluzione totalmente free, consentendoci di risparmiare i parecchi soldini altrimenti richiesti da una soluzione prettamente commerciale.
Scarica il pdf (311,5 kb)
Questa mattina ho trovato sulla mia scrivania questo gioiellino da testare.
Si tratta di RamSan-620, un disco Flash SSD da 1,5TB della Texas Memory Systems, con un throughput da (udite udite!) 3GB, con latenza media da 80 a 200 ms, 25 volte superiore ai più veloci dischi non SSD. Caratteristica non da poco, occupa solamente 2U rack. Unico neo, non costa proprio 2 noccioline… ma circa 80k €
Entro il 15 dicembre ogni azienda dovrà adeguarsi al provvedimento del Garante della privacy relativo al controllo delle attività degli amministratori di sistema. In poche parole questo provvedimento ha come scopo quello di mettere qualche paletto all’attività degli amministratori di sistema, che in quanto “Deus ex machina” dei propri sistemi, hanno la possibilità di fare qualsiasi cosa sui sistemi stessi. Nelle intenzioni del Garante dal 22 dicembre in poi le attività degli amministratori, o meglio i log in e i log off sui sistemi, andranno loggati e di quei log dovrà essere garantita l’inalterabilità e la disponibilità per almeno 6 mesi. Ecco che allora in questi mesi si ha una vera e proprio proliferazione di prodotti in grado, a parole, di adempiere al contenuto del provvedimento. In azienda per il momento sono venuti un paio di vendor (dei quali risparmierò il nome) a proporre prodotti che per una cosa o per l’altra (funzionalitò e $$$) non mi hanno completamente convinto. Proprio questi giorni ho iniziato a dare un’occhiata a un prodotto alternativo, Splunk (www.splunk.com), che oltre ad adempiere al provvedimento, fa tutta una serie di cose carina in più, come la correlazione tra i vari eventi che logga. E, cosa importantissima in questo periodo di vacche non grasse, è free fino a 500mb di log indicizzati. Maggiori informazioni sul prodotto scelto nei prossimi giorni!
Da qualche tempo nei log di una macchina Wmware vedevo queste entry:
/dev/vmmon[5639]: host clock rate change request 147 -> 0
/dev/vmmon[5639]: host clock rate change request 0 -> 48
/dev/vmmon[5639]: host clock rate change request 48 -> 126
/dev/vmmon[5639]: host clock rate change request 126 -> 150
/dev/vmmon[5639]: host clock rate change request 150 -> 0
/dev/vmmon[5639]: host clock rate change request 0 -> 29
/dev/vmmon[5639]: host clock rate change request 29 -> 53
/dev/vmmon[5639]: host clock rate change request 53 -> 120
Dopo alcune ricerche su Google, ho trovato la soluzione. E' sufficiente editare il file /etc/vmware/config, aggiungendo le seguenti linee:
host.useFastClock = FALSE
host.cpukHz = 2700819
host.noTSC = TRUE ptsc.noTSC = TRUE
Per impostare correttamente il valore della cpu, dare prima un'occhiata al file /proc/cpuinfo, quindi moltiplicare per 1000 il valore di "cpu MHz".
Commenti recenti