E’ possibile recuperare la password di root eseguendo questi 5 passi:

Step # 1: Fermare il processo server MySQL

Step # 2: “Startare” il processo server MySQL con l’opzione –skip-grant-tables

Step # 3: Connettersi al server MySQL come utente root

Step # 4: Configuriamo la nuova password per l’account di root

Step # 5: Usiamo e “restartiamo” il server MySQL.

Per ogni step, di seguito è possibile visionarne i commandi (da eseguire loggati come utente root):

Step # 1 : Fermare il server MySQL

# /etc/init.d/mysql stop

Output:

Stopping MySQL database server: mysqld.

Step # 2: Avviare il server MySQL senza password:

# mysqld_safe --skip-grant-tables &

Output:

[1] 5988
Starting mysqld daemon with databases from /var/lib/mysql
mysqld_safe[6025]: started

Step # 3: Connessione al server MySQL usando il client MySQL:

# mysql -u root

Output:

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.15-Debian_1-log

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql>

Step # 4: Settiamo la nuova password per l’utenza root del server MySQL

mysql> use mysql;
mysql> update user set password=PASSWORD("NEW-ROOT-PASSWORD") where User='root';
mysql> flush privileges;
mysql> quit

Step # 5: Stoppiamo il server MySQL:

# /etc/init.d/mysql stop

Output:

Stopping MySQL database server: mysqld
STOPPING server from pid file /var/run/mysqld/mysqld.pid
mysqld_safe[6186]: ended

[1]+ Done mysqld_safe –skip-grant-tables

Step # 6: Avviamo il server MySQL ed effettuiamo il primo accesso

# /etc/init.d/mysql start
# mysql -u root -p

L’attività di promozione e di studio di visibilità di un portale web è un’attività molto complessa, interdisciplinare e che richiede costante lavoro, impegno e dunque anche un investimento economico. Proprio per questi motivi, è fondamentale non perdere il lavoro svolto, a fronte di una migrazione del portale, ad esempio, che può diventare necessaria per diversi motivi, che vanno da problemi del server alla necessità di fornire servizi più performanti ai proprio utenti.

Con questa premessa, diventa ovvio che lo spostamento o la migrazione di un servizio web non deve generare la perdita dell’indicizzazione e di tutte le informazioni ad essa correlate. Con questa finalità può essere sfruttato lo status HTTP 301, che indica appunto una il Redirect Permanent, che ci permette di avvisare i servizi quali motori di ricerca e social network che il nostro portale e i nostri contenuti non sono spariti nel nulla, ma sono stati “spostati” in modo permanente.

Lo status HTTP 301 può essere impostato attraverso il web server Apache, che ci permette diverse configurazioni possibili.

La prima è quella di utilizzare un file .htaccess incluso nella configurazione del dominio in questione, contenente la seguente direttiva:

Redirect 301 / http://www.nuovodominio.com/

dove il forward slash “/” indica che la pagina dal vecchio dominio sarà indirizzata sulla corrispondente contenuta nel nuovo dominio. Ovviamente si può specificare tale stato anche solo per una singola pagina, ad esempio con la seguente direttiva:

Redirect 301 /oldpage.php http://www.nuovodominio.com/newpage.php

Una soluzione molto importante da conoscere è quella fornita dal mod_rewrite di Apache, che torna utile soprattutto nei casi in cui è necessario anche modificare il nome del virtual host.In sostanza, con le seguenti direttive, non solo segnaliamo il redirect permanente dal vecchio dominio al nuovo, ma in più applicchiamo una “ri-scrizione” del vecchio nome di dominio sul nuovo, in modo che tutte le vecchie pagine possono ritrovare la loro corrispondente sul nuovo dominio:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} www.vecchiodominio.it [NC]
RewriteRule ^(.*)$ http://www.nuovodominio.it/$1 [L,R=301]

Ovviamente non è obbligatorio utilizzare un file .htaccess per configurare tali direttive, possono essere inserite direttamente all’interno del file httpd.conf del dominio in questione: teniamo prensente però che l’inclusione di file .htaccess in alcuni casi permette di lasciare inalterati i file originali di configurazione del dominio (anche se potrebbe rallentare il sistema), mentre in altri casi ancora non si ha accesso al file httpd.conf di configurazione del dominio e dunque rimane come una soluzione l’utilizzo dell’ .htaccess.

Il lavoro di squadra richiede da parte delle figure coinvolte pazienza e dedizione, e la strada da scegliere deve essere quelle del dialogo costruttivo e del rispetto delle idee di ognuno dei partecipanti.

Vi sono strumenti che è molto importante conoscere, perchè permettono di sincronizzare il lavoro del team e di gestire in modo professionale e ordinato progetti di dimensioni importanti. In questo articolo vedremo come configurare un ambiente di sviluppo professionale per il team development, ma non bisogna mai dimenticare un elemento importante: gli strumenti che vedremo sono molto potenti ed utili, ma non sono adatti a tutte le situazioni e a tutte le tipologie di progetto.

Uno strumento potente, ma inadatto alle caratteristiche dei progetti o dei movimenti produttivi interni dell’azienda, può provocare danni non indifferenti.

L’ambiente che andremo a configurare ha i seguenti requisiti:

1. un server linux (fedora 10)
2. Apache, PHP, MySql installati nel server e nella propria macchina
3. IDE Zend Studio for Eclipse (o anche solo Eclipse) installato nella propria macchina

Il sistema che andremo a configurare  è dunque composto da un server Linux su cui installaremo l’svn (subversion), e da una o più workstation su cui sarà configurato un ambiente di sviluppo in locale e l’IDE che ci permette di gestire i collegamenti con subversion e dunque di lavorare in team con i nostri colleghi.

Configurazione del SERVER

Avendo scelto come sistema operativo Fedora 10, possiamo utilizzare il tool yum per installare subversion su linux:

yum install subversion

Per renderlo avviabile in Apache, installiamo il modulo mod_dav_svn:

yum install mod_dav_svn

Nella directory root del server, creiamo le seguenti cartelle per il repository svn:

mkdir /svn/repos
svnadmin create /svn/repos/projects

Per questioni di permessi, è necessario cambiare il proprietario della cartella in “apache” :

chown -R apache.apache /svn

A questo punto, dobbiamo creare il file in cui verranno scritte le policy di sicurezza che controllano la metodologia di accesso ai progetti. Creiamo il file svnauth nella directory /svn/repos/projects/svnauth e inseriamo le utenze come da esempio seguente:

[/]
user1 = rw
user2 = r

user1 in questo caso avrà accesso in lettura-scrittura, mentre user2 avrà l’accesso in modalità in sola lettura in tutto il repository.

Il passo successivo è creare il file (/svn/repos/projects/svnpass) che conterrà le password degli utenti di cui sopra:

htpasswd -bcm /svn/repos/projects/svnpass user1 passwordUser1
htpasswd -bm /svn/repos/projects/svnpass user2 passwordUser2

Lanciando i comandi precedenti, creiamo un’associazione tra utente e password, e tale associazione verrà appunto scritta nel file svnpass. Importante: notate che i parametri del primo comando (-bcm) sono diversi dal secondo (-bm); questo perchè nel secondo caso andiamo solo ad aggiungere una riga al file svnpass, mentre nel primo caso è impostata anche la creazione opzionale del file nel caso in cui questo non esistesse. I parametri associati al comando htpassw hanno il seguento significato:

-c    creazione nuovo file

-m   forzare la crittografia MD5 della password

-b    usare la password inserita da linea di comando

Per ulteriori chiarimenti sul comando htpasswd consigliamo di leggerne la documentazione, anche perchè ci sono alcune differenza in base al sistema operativo in uso.

Ora è arrivato il momendo di configura Apache; aggiungiamo allora le seguenti righe al file di configurazione del server web:

<Location /svn/sandbox>
DAV svn
SVNPath /svn/repos/sandbox
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /svn/repos/sandbox/svnpass
Require valid-user
AuthzSVNAccessFile /svn/repos/sandbox/svnauth
</Location>

Riavviamo Apache, e l'ambiente server è pronto per essere utilizzato. Se tutto funziona regolarmente, il repository dovrà essere accessibile da browser al seguente indirizzo http://www.yourserver.com/svn/projects.

Sarà richiesta una login e una password, che ovviamente dovranno corrispondere a quelle che abbiamo procedentemente inserito.

Ora manca il passo finale, quello della configurazione del nostro IDE. Consideriamo a questo punto che su ogni macchina prediposta per il team development vi siamo già configurato un ambiente di sviluppo classico per lo sviluppo locale in PHP (Apache-PHP-MySql).

In questa sede sarebbe troppo dispersivo e lungo descrivere il procedimento passo per passo: vi sono diversi pacchetti com xxamp o wamp che si possono usare per configurare in pochi minuti un ambiente di sviluppo in PHP perfettamente funzionante in ambiente Windows (nelle release Linux più diffuse, è già tutto prediposto per una installazione di tale ambiente), anche se il nostro consiglio è di procedere con installazioni manuali di cui si ha il completo controllo. L’unico appunto è di far puntare la directory root di apache nel workspace che abbiamo scelto durante la configurazione della IDE: in questo modo rendiamo visibili i nostri progetti ZEND o ECLIPSE nel nostro localhost.

La configurazione che vedremo è esattamente la stessa sia che si utilizzi Zend Studio for Eclipse che Eclispe con il plugin Php. Quest’ultima, come la maggior parte degli utenti sapranno, è completamente gratuita, e fornisce gli stessi strumenti di Zend Studio per quando riguarda il team development. Chiaramente Zend Studio è la piattaforma specifica per lo sviluppo in PHP, e sicuramente per un web developper professionista è il top in quanto a strumenti forniti e comodità di sviluppo. Tuttavia, per chi sviluppa in più di un linguaggio di programmazione a livelli professionali, Eclipse, a nostro avviso, risulta essere la scelta più versatile e comoda.

Procediamo alla configurazione della nostra IDE:

1) Apriamo la prospettiva SVN Repositories

2) Nella colonna di destra, andiamo ad aggiungere il nostro repository (tasto destro + new)

2.1) Inserire l’URL  del repository http://www.tuoserver.com/svn/projects.

2.2) Inserire l’user e la pass dell’utente che utilizzerà tale ambiente e che rientrano in quelle precedentemente configurate

2.3) Clicchiamo su “Finish”

A questo punto il repository verrà importato nel nostro ambiente: concluso tale processo, apriamo la prospettiva “PHP Explorer” (o Resource), che sarà la prospettiva vera e propria che useremo per lo sviluppo. Creiamo un nuovo progetto:

1) New Project

2) Svn –> Project from SVN

3) Selezionare l’uso di un repository esistente

4) Scegliere il/i progetto/i, la data attuale e procedere cliccando su “Finish”

A questo punto verrà eseguito il checkout del progetto: questo procedimento impiegherà qualche minuti prima di concludere.

Siamo pronti per testare il meccanismo, tornando ad analizzare la sezione “PHP Explorer” della nostra IDE.

La prima cosa che notiamo sono dei “numeri” presenti su ogni risorsa all’interno del progetto: questo “numero” identifica la versione della risorsa: subversion, infatti, gestisce un potente e importante strumento di versioning, che facilita nelle operazioni di update o di recupero.

Cliccando con il tasto destro del mouse sul nome del progetto, e scegliendo “Team”, si apre un menu contestuale che ci mette a disposizione tutti gli strumenti potenti di gestione del team development e di subversion.

La operazioni principali sono UPDATE e COMMIT : la prima permette di ricevere le modifiche che gli altri membri del team hanno portato al progetto eseguendo un commit. Il COMMIT, appunto, è l’operazione più importante, perchè permette di scrivere sul progetto finale, direttamente sull’snv: bisogna per questo fare molto attenzione durante questa operazione, essere sicuri che ciò che si sta “commitando” sia perfettamente funzionante e ricordarsi sempre di commentare il proprio COMMIT per permettere una facile gestione del versioning.

Vi sono tantissime altre funzionalità molto importanti e potenti che possiamo sfruttatare per lavorare al meglio con questi strumenti, ma per ora riteniamo siamo meglio fermarci qui….abbiamo già abbastanza elementi da testare! Chiaramente, nel caso ci fossero domande o questione di qualsiasi tipo, siamo a  vostra disposizione!!

Questa utility legge i file /proc/net/dev e /proc/uptime per stampare a video la banda usata, anche determinati archi di tempo selezionati dall’utente, il valore massimo da quando è stato inizializzato il tool ed anche la media della banda utlizziata dall’ultimo reboot.

Il software necessario è reperibile al seguente link.

L’installazione è semplicissima e segue la classica compilazione. Per compilare, ci posizioniamo all’interno della cartella in cui abbiamo “unzippato” il file scaricato e digitiamo il comando make:

$ make

a questo punto possiamo installare il tool, digitando il comando:

$ make install

e bwmon è pronto per iniziare le sue analisi. Vi consigliamo di osservare l’help che fornisce il tool, raggiungibile con il comando bwmon -h:

$ ./bwmon -h

Linux Network Bandwidth Monitor $Revision: 1.3 $
by Kimmo Nupponen (kimmoon@users.sourceforge.net)
$Date: 2002/05/08 06:33:09 $

usage: ./bwmon [-b] [-h] [-a] [-m] [-u seconds]
-a Print bandwidth utiliasation in Kbytes rather than Kbits. The default
is to use Kbits
-a Print also average bandwidth since last boot per interface
-m Print maximum bandwidth since launch of this utility
-h Print this help message
-u Update timeout (integer value)

Use <space-bar> to refresh the screen before update timeout expires
Use ‘q’ or ‘Q’ to exit this utility

Questo è l’output che visualizzerà l’help. Ora possiamo finalmente iniziare le nostre analisi, appoggiandoci a questo comodo e preciso strumento.

Sul web vi sono molte informazioni e documentazione sulla gestione del server di posta, ma la maggior parte dei tutorial è legato a configurazioni specifiche che molto spesso si discostano parecchio da quella che si sta implementando.

Con questa guida impareremo non solo a configurare un server di posta, ma anche come si gestisce l’utenza della posta senza l’ausilio di un pannello di hosting, in modo da comprendere totalmente i meccanismi che guidano la gestione delle mail.

Su un sistema operativo linux, andremo a configurare il server di posta Postfix, il server Courier-Imap e la webmail horde come interfaccia grafica per la visione delle mail.

Noi abbiamo effettuato le prove su un sistema OpenSuse 10.2, ma ciò che vedremo andrà benissimo per qualsiasi sistema operativo linux.

Requisiti

La prima cosa da fare è ovviamente installare tutti i pacchetti che ci servono. Per chi è alle prime armi, consigliamo di utilizzare i meccanismi messi a disposizione da ogni sistema linux per effettuare tali installazione, come yast o smart per OpenSuse 10.2 o yum per i sistema Debian.

Ecco quello che ci occorre:

• Il server di posta Postix ( )
• Il server imap Courier
• La libreria courier-authlib-userdb del server imap Courier
• La webmail Horde ( o quella che si preferisce, squirrelmail, ecc. )

Installati i pacchetti necessari, procediamo alla configurazione.

Configurazione

Inziamo con la configurazione del Postfix: ovviamente vi sono moltissime configurazione possibili, ognugno è libero di scegliere quella che preferisce e che meglio si adatta alle proprie esigenze. Qui è possibile vedere alcuni esempi sulle diverse configurazioni di base: noi implementeremo quella che nel Postfix viene chiamata Domini MailBox Virtuali : questa configurazione permette di utilizzare un elenco di utenti e le corrispondenti mailbox in modo assolutamente indipendente dagli utenti del sistema (per maggiori dettagli leggete il link sopra indicato).

Editiamo il file principale che gestisce la configurazione del Postifx, main.cf , che solitamente di trova nella cartella /etc/postix/main.cf e inseriamo queste direttive:

virtual_mailbox_domains = mio_dominio.com
virtual_mailbox_base = /var/mailboxes/
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

Analizziamo come sempre riga per riga le direttive che abbiamo scritto. La direttiva virtual_mailbox_domains serve per specificare al Postfix i domini per i quali intendiamo creare le mailbox. Nel nostro caso abbiamo un solo dominio, mio_dominio.com .

virtual_mailbox_base specifica il prefisso per il percorso di tutte le mailbox virtuali. I tre parametri successivi

virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

sono molto importanti, perchè configurano il cuore del server di posta. Il primo, virtual_mailbox_maps, specifica il file che contiene l’elenco delle caselle di posta presenti nel dominio specificato (virtual_mailbox_domains), nel seguente formato:

user@mio_dominio.com user/

I seguenti due campi, virtual_uid_maps e virtual_gid_maps, sono riespettivamente userid e il groupid dell’utente che il delivery agent utilizza per scrivere nelle mailbox.

L’ultimo campo che rimane da vedere è il virtual_alias_maps : questo è da utilizzarsi quando tra le caselle specificate vi sono dei reindirizzamenti. Il formato è il seguente:

user@mio_dominio.com altro_user@altrodominio.com

in cui il primo elemento rappresenta l’origine, mentre il secondo rappresenta la destinazione, ovvero la casella di posta dove il messaggio per user@mio_dominio.com dovrà essere recapitato. Attenzione: quando modifichiamo il file /etc/postfix/virtual, è necessario eseguire il comando:

postmap /etc/postfix/virtual

affinchè le modfiche abbiamo effetto.

Creazione Utenti

Vediamo ora la procedura che bisogna eseguire dopo la configurazione del Postfix per creare effettivamente l’utenza mail: questo è il punto più importante dell’articolo, perchè in effetti non vi sono molte risorse disponibili al riguardo.

1. Inserisco la riga per la nuova casella di posta nel file di postfix /etc/postfix/virtual_mailbox:

   nome.cognome@mio_dominio.com nome.cognome/

   ovviamente al posto di nome.cognome è possibile utilizzre lo schema di gestione utenza che si preferisce.

2. E’ necessario ora rigenerare il file .db lanciando il comando:

   postmap virtual_mailbox

3.  

   Creaimo l’utenza imap(courier-auth), che viene scritta nel file /etc/authlib/userdb :

   userdb nome.cognome@mio_dominio.com set uid=5000 gid=5000 home=/var/mailboxes mail=/var/mailboxes/nome.cognome

   userdbpw -md5 | userdb nome.cognome@mio_dominio.com set systempw

4. makeuserdb

Il primo comando andrà specifica il nome utente e la rispettiva mailbox per il nuovo account di posta. Il secondo comando ci permette di assegnare una password per l’account in creazione, mentre il terzo e ultimo comando è necessario per scrivere nei relativi file rendendo così effettive le modifiche.

1. Per creare tali utenze, abbiamo usato la libreria libreria courier-authlib-userdb che ci siamo procurati durante la fase di installazione dei requisiti.
2. Per creare fisicamente (intendiamo le directory) le cartelle del nuovo utente è sufficiente che questo riceva un messaggio, sarà postfix stesso a crearle ed inserire il messaggio ricevuto nella giusta cartella. Nel caso in cui volessimo fare una prova, si può mandare una mail esterna (attraverso cioè una qualsiasi casella di posta funzionante) o interna (dal localhost tramite telnet o sendmail).Nel caso di telnet si procede nel seguente modo:S: telnet qualcheparte 25R: 220 qualcheparte Simple Mail Transfer Service ReadyS: HELO miohost
   R: 250 miohostS: MAIL FROM:<Marco@miohost>R: 250 OK

   S: RCPT TO:<Roberto@suohost>

   R: 250 OK

   S: DATA

   R: 354 Start mail input; end with <CRLF>.<CRLF>

   S: Blah blah blah…

   S: …etc. etc. etc.

   S: .

   R: 250 OK

   S: QUIT

   R: 221

   dove:

   * HELO tuohost
   (dove tuohost e’ il nome del server che spedisce il messaggio.
   Questo comando e’ usato per identificare il server mittente)

   * MAIL tuoindirizzo (dove tuo indirizzo e’ il tuo indirizzo di posta elettronica. Questo comando inizia una transazione di posta dove i dati vengono consegnati ad una o piu’ caselle di posta)

   * RCPT indirizzodestinatario (dove indirizzo destinatario e’ l’ indirizzo di posta elettronica del destinatario)

   * DATA (questo comando e’ usato per definire il testo del messaggio. Un testo di una e-mail puo’ contenere solo i caratteri compresi nel set dei 128 caratteri dello standard ASCII. La fine del messaggio e’ indicata da una riga contenente esclusivamente la sequenza di caratteri “<CRLF>.<CRLF>” . In altre parole devi premere il tasto invio, digitare un punto e premere di nuovo il tasto invio)

   * RSET (questo comando specifica che la transazione corrente deve essere interrotta)

   * NOOP (questo comando indica che non deve essere eseguita alcuna azione, tranne quella che permette al ricevente di inviare una risposta di OK)

   * QUIT (questo comando e’ usato per chiudere la connessione)

   E le risposte piu’ comuni:

   220 <dominio> Service ready
   221 <dominio> Service closing transmission channel
   250 Requested mail action okay, completed
   354 Start mail input; end with <CRLF>.<CRLF>
   421 <dominio> Service not available, closing transmission channel
   450 Requested mail action not taken: mailbox unavailable [Es. mailbox occupata]
   500 Syntax error, command unrecognized [Es. una riga di comando troppo lunga]
   501 Syntax error in parameters or arguments
   502 Command not implemented
   550 Requested action not taken: mailbox unavailable
   551 User not local; please try <indirizzo>
   554 Transaction failed

   Nel caso di sendmail si procede in questo modo:

   sendmail user@dominio.com<enter>
   From: user@altrodominio.com
   Subject: Oggetto messaggio
   (riga vuota)

   tutto il testo del messaggio

   .
   (un punto solo sulla riga)

Ma è ovviamente molto difficile avere tutto sotto controllo senza un ausilio “esterno”: ecco a cosa servono i tool come Tiger, Nmap e Nessus.

Questi tool hanno diverse caratteristiche interessanti, alcuni sono più precisi, altri più approfonditi, ma comunque hanno uno scopo in comune: permettere all’amministratore di rete di monitorare il proprio sistema e scoprire le vulnerabilità prima che sia troppo tardi.

Tiger e Nmap sono in effetti più semplici da installare ed utilizzare, ma è anche vero che non raggiungono la profondità di analisi e la precisione di Nessus.

Quest’ultimo è eseguibile su diversi sistemi operativi, tra i quali ci sono i seguenti:

• Red Hat ES 3, ES 4, and ES 5 (i386 and x86-64)

• Fedora Core 7 and 8

• SUSE 9.3 and 10.0

• Debian 4 (i386 and amd64)

• FreeBSD 6.0

• Solaris 9 and 10

• Mac OS X 10.5

• Windows 2000, XP, Server 2003, Server 2008, and Vista

• Enterasys Dragon appliance running Dragon 7.2 or later

Anche gli altri due tool supportano diversi sistemi operativi, per questo motivo conviene leggere le rispettive documentazioni e le rispettive liste di plugin per capire quale sia il tool che meglio si addice all’analisi che vogliamo eseguire sul nostro sistema.

In particolare, i link a cui facciamo riferimento sono i seguenti:

• Documentazione Nmap
• Documenzione Nessus
• Documentazione Tiger

Non proseguiamo con ulteriori spiegazioni, visto che la documenzione di ogni tool è veramente esauriente ed intuitiva. Ad ogni modo, rimaniamo come sempre a disposizione per chi incontrasse difficoltà nella configurazione, nell’installazione o nell’utilizzo.

Supponendo di utilizzare un PC con una qualche versione di linux installata per effettuare la connessione remota, tutto ciò che ci occorre è aprire una finestra di terminale o shell (per chi utilizza windows, è possibile sfruttare tool come Putty per effettuare connessioni remote). Siccome è buona norma non utilizzare l’utente root per lavorare, supporremo che utilizziamo nel nostro sistema di casa un utente diverso, ad esempio user-007. Dunque, aprendo il terminale, a linea di comando vedremo un qualcosa di simile:

$user-007\

Ora, normalmente in remoto ci si collega come utente root, ma allora sorge un problema: nel sistema di casa che utilizziamo per effettuare la connessione remota siamo identificati con l’utente user-007, mentre nell’host remoto vogliamo essere identificati come utente root.

Allora il comando che dobbiamo utilizzare è il seguente:

ssh root@indirizzo_ip

dove al posto di indirizzo _ip ovviamente andremo a mettere l’ip del server con il quale vogliamo effettuare la connessione remota. A questo punto ci verrà richiesta la password di sistema relativa all’utente remoto root: una volta inserita, entreremo nel server e potremo gestirlo da linea di comando proprio come facciamo con il nostro sistema linux locale.

Utilizzare PC domestici con linux per lavorare ed effettuare connessioni SSH è decisamente la cosa più sicura ed efficiente per ammistrare un server da remoto: vi sono tool per windows che permettono di utilizzare meccanismi che simulano o lavorano in modo simile ad un sistema linux per amministrare server linux, ma provate per esempio ad uplodare sul server una grande quantità di dati (ad esempio video o altro materiale multimediale). La differenza che potrete osservare parla da sola.

Ma come è possibile fare questo? Utilizzando il daemon Cron.

Cron è un demone che appunto può essere utilizzato per eseguire operazioni pianificate in base all’ora, al giorno del mese, al mese, al giorno della settimana.

Ovviamente l’utilizzo di Cron presuppone che il sistema sia sempre accesso: nel caso in cui risulti spento quando una operazione è pianificata, semplicemente questa non verrà eseguita. Per poter utilizzare Cron (che il più delle volte è disponibile già in ogni installazione di Linux) occorre che sia installato il pacchetto RPM vixie-cron e il servizio crond sia in secuzione. Per verificare che il pacchetto sia installato e che il servizio sia in esecuzione è sufficiente digitare i seguenti comandi:

rpm -q vixie-cron
/sbin/service

Ma arriviamo al punto fondamentale, ovvero a come configurare le operazioni con Cron. Il file di configurazione più importante di Cron, /etc/crontab, contiente le seguenti righe:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Nelle prime quattro righe vengono inizializzate alcune variabili utilizzate per configurare l’ambiente in cui vengono eseguiote le operazioni di Cron. La variabile SHELL indica al sistema quale ambiente shell utilizzare (nell’esempio è inidicata la bash shell) mentre la variabile PATH definisce il percorso utilizzato per eseguire le operazioni. L’ouput di ogni operazione Cron viene inviato tramite e-mail al nome utente specificato nella variabile MAILTO: se quest’ultima viene lasciata vuota non viene inviata alcuna mail. La variabile HOME indica la directory home per l’esecuzioni di eventuali script o comandi.

Ogni riga del file /etc/crontab può essere vista come un’operazione e ha il seguente formato:

* * * * * command
- - - - -
| | | | |
| | | | ----- giorno della settimana (0 - 6) (domenica=0)
| | | ------- mese (1 - 12)
| | --------- giorno del mese (1 - 31)
| ----------- ora (0 - 23)
------------- minuti (0 - 59)

Come di intuisce facilmente dalla figura sopra, il primo campo si riferisce ai minuti, il secondo all’ora, il terzo al giorno del mese, ecc. : in questo modo possiamo stabilire con esattezza il momento temporale in cui vogliamo che una determinata operazione (nell’esempio command) venga eseguita. Gli intervalli tra parentesi indicano i range di valori possibili, tenendo presente che qualsiasi valore può essere sostituito con il simbolo *, che indica tutti i valori validi. Per esempio, un asterisco per il valore del mese indica di eseguire ilk comando specificato ogni mese in base alle restrizioni degli altri valori.

Con il trattino “-” invece indichiamo un intervallo di valori, metre con la virgola “,” creiamo una lista: con il simbolo “/” indichiamo invece valori che vogliamo escludere. Vediamo alcuni esempi:

1-4 (1,2,3,4)

3,4,5,7,12,56 (lista)

0-45/2 (escludiamo il valore 2 da tutti i valori comresi tra 0 e 45 )

*/4 (utilizzato nel campo del mese, indica che l’operazione verrà effettuata ogni 4 mesi)

Vediamo un esempio. Visto che tutti i crontab definiti dall’utente vengono salvati nella directory /var/spool/cron/ ed eseguiti usando il nome utente di chi li ha creati, per creare un crontab con un determinato utente bisogna connettersi al sistema con il nome di questo utente e digitare il seguente comando:

crontab -e

Si aprirà il crontab realtivo pronto per le modifiche e aperto con l’editor specificato nella varibile VISUAL o EDITOR. Una volta modificato il file, lo salviamo e usciamo (se utilizzaimo VI, in modalità comando digitiamo :wq). Una volta salvate la mofidiche al crontab, questo viene salvato in base al nome dell’utente e scritto nel file /var/spool/cron/nomeutente.

Il file /etc/crontab utilizza lo script run-parts per eseguire gli script nelle seguenti directory:

/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly

rispettivamente in base oraria, giornaliera, settimanal, mensile. Nel caso in cui volessimo eseguire un file di cron con una fase oraria diversa, allora dovremmo aggiungerla nella directory /etc/cront.d . Tutti i file di questa directory utilizzano la medesima struttura del file /etc/crontab .

Il deamon Cron controlla il file /etc/crontab, le directory /etc/cront.d e /var/spool/cron ogni minuto per rilevare eventuali modifiche. Nel caso in cui vengano rilevate delle modifiche, il file e le directory vengono ricaricati in memoria. Nota bene: se un file crontab viene modificato, non è necessario riavviare il daemon Cron.

Prima di procedere con l’installazione, è bene che studiate bene i requisiti presentati al seguente indirizzo.

Vediamo come installarlo e configurarlo correttemente. Dopo averlo scaricato al seguente indirizzo, procediamo con la ‘decomprensione’ del file archivio e sistemandoci nella cartella di installazione:

tar xvfz ISPConfig*.tar.gz
cd install_ispconfig

A questo punto siamo pronti per partire con il processo di installazione, lanciando il comando

./setup

A questo punto l’installatore si preoccuperà di tutto il processo, a noi non resterà che rispondere a delle domande che nella maggior parte dei casi sono semplici e chiare. La prima cosa che farà l’installatore sarà compilare Apache con il modulo PHP5: questa compilazioni non modificherà eventuali precedenti personalizzazioni nella configurazione del server wev

Una volta conclusa questa prima fase, sarà necessario creare un certificato SSL: a questo proposito verranno sottoposte una serie di domande, alle quali si può rispondere accettando i valori di default o inserendone di personali.

Bisogna fare attenzione quando raggiungiamo i seguenti punti :

Encrypting RSA private key of CA with a pass phrase for security [ca.key]

Encrypting RSA private key of SERVER with a pass phrase for security [server.key]

del processo di creazione del certificato, perchè qui possiamo chiedere se vogliamo crittografare la password realativa. E’ importante scegliere no, perchè altrimenti ogni qualvolta intendiamo riavviare il sistema ISPConfig ci verrà chiesta una password, e questo comporta che non è possibile riavviare il sistema senza un intervento umano.

Se ci troviamo di fronte un fallimento della compilazione, il processo di setup viene interrotto e i file finora compilati vengono rimossi. Dal messaggio di errore, dovrebbe essere chiaro il problema: una volta risolto, si può procedere nuovamente con il processo di setup.

In caso di successo, invece, ci verrà chiesto di scegliere una lingua: questa scelta si riferisce al linguaggio dell’interfaccia di ISPConfig. Una volta accetta la licenza, che consigliamo di leggere bene, viene chiesta la modalità di installazione: sarebbe meglio scegliere la modalità expert, perchè permette un maggior controllo sull’installazione. Quindi digitiamo 2 e proseguiamo con il processo di installazione.

Segue il riconscimento del daemon postfix, e la scelta della web-root: se non ci va bene la proposta di default, digitiamo n ed inseriamo la cartella che preferiamo. Inserita la web-root verranno richiesti ulteriori dati di configurazione:

Please enter your MySQL server: localhost
Please enter your MySQL user: root
Please enter your MySQL password: (inserire la pass scelta durante l’installazione del MySQL Server)

Please enter a name for the ISPConfig database (e.g. db_ispconfig): db_ispconfig
Please enter the IP address of the ISPConfig web (e.g. 192.168.0.1): xxx.xxx.xxx.xxx (Inserire il proprio IP)
Please enter the host name (e.g. www): www
Please enter the domain (e.g. xyz.de): tuodominio.com

Please select the protocol (http or https (SSL encryption)) to use to access the ISPConfig system:
1) HTTPS
2) HTTP
Your Choice: 1

Se stiamo procedendo ad una installazione di test, il nome host lo possiamo lasciare vuoto, e al posto del nome di dominio possiamo inserire l’indirizzo IP.

Una volta completati tutti i passaggi ISPConfig sarà finalmente installato sul proprio server. Se durante l’installazione abbiamo indicato www come nome host e tuodominio.com come dominio, allora l’interfaccia di ISPConfig sarà raggiungibile al seguente indirizzo:

https://www.tuodominio.com:81 o http://www.tuodominio.com:81

Il primo login andrà fatto inserendo admin come username e password. Ovviamente la prima cosa da fare una volta installato il pannello, è proprio quello di cambiare questi dati, viato che quelli di default non sono mai sicuri.

L’installazione è conclusa, e al seguente indirizzo potete trovare il manuale di utilizzo del pannello. Le istruzioni di installazione dettagliate per ogni sistema operativo linux sono disponibili qui.