Questa guida vuole essere una quick reference per installare un server di posta con antispam e gestione relativamente semplice di utenti e domini, tramite ubuntu 8.04 TLS 64bit.

Le feature principali sono:

- SMTP-AUTH e TLS

- password encrypted

- Amavisd, SpamAssassin e ClamAV

Read the rest of this entry »

Esco un po’ dai soliti howto, per dare un paio di link per poter utilizzare i propri backup con la wii.

Ripeto i propri backup, i giochi si comprano!!!

Comunque… chiuque avesse questa necessità segua questi due link qua:

1- Twilight hack: http://www.giardiniblog.it/2008/10/29/copie-di-backup-su-wii/

2- Homwbrew channel http://www.giardiniblog.it/2008/10/29/copie-di-backup-su-wii/

3- Bakcup Luncher:  http://www.giardiniblog.it/2008/11/16/backup_launcher_03_gamma/

li ho provati sulla mia con il firmware 3.4E, su molti siti ho letto che dicevano che non era possibile, ovviamente tutte cazzate.

Fate molta attenzione a utilizzare la vervsione corretta del CIoS che ammetto mi ha dato non pochi problemi, e se sbagliate dopo è da diventare pazzi a fare il downgrade.

P.s.: un ringraziamento anche a http://www.prime-news.info/ leggete pure ( http://www.prime-news.info/guide/guide-come-copiare-e-backuppare-i-giochi-della-nintendo-wii/ )

Di recente (neanche tanto a dire il vero) è stato resa nota una falla di molti dns che permette, tramite un attacco di dns poisoning, di manomettere i nomi host utlizzati da molti dns server sul pianeta.

Per fare un esempio pratico, ipotizziamo di voler aprire un sito come www.l.google.com che ha un indirizzo ip pari a 209.85.135.147, ora quello che fa un potenziale “hacker” non fa altro che sfruttare la falla del dns per fare risolvere www.l.google.com invece che con il suo indirizzo vero con un indirizzo qualunque tipo 127.0.0.1.

Ora per controllare se il proprio dns server è sicuro da questo tipo di problemi ci sono due strade:

1- collegarvi direttamente al sito DoxPara, sulla destra trovete la finestrella “dns checker” non dovrete fare altro che premere il pulsante Check My DNS.

2- oppure tramite linux mediante il comando dig.

Per il secondo punto il comando da lanciare è il seguente:

root@localhost:# dig +short @[your nameserver] porttest.dns-oarc.net txt

dove dovete sostituire [your nameserver] con l’indirizzo ip del dns di cui volete fare il controllo.

Esaminiamo ora i possibili risultati.

Se utilizziamo come dns uno dei dns del servizio OpenDNS otteniamo quanto segue:

root@localhost:# dig +short @208.67.222.222 porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"208.69.34.8 is GREAT: 26 queries in 4.1 seconds from 26 ports with std dev 15951"

se vedete scritta nell’ultima riga GREAT allora il dns è ok ed è stato correttamente patchato.

Nel caso contrario invece utilizzando uno dei dns Telecom STRANAMENTE, i dns non sono patchati e quindi vulnerabili a questo tipo di attacchi

root@localhost:# dig +short @151.99.125.1 porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"82.53.187.212 is POOR: 26 queries in 4.8 seconds from 1 ports with std dev 0"

come vedete questa volta nell’ultima riga trovate scritto POOR che indica che il dns non è correttamente aggiornato e quindi vulnerabile.

Su windows il comando è il seguente da lanciare da una console del DOS:

nslookup -querytype=TXT porttest.dns-oarc.net. ns1.nucleus.be

Saluti

Matteo

Può capitare a volte che sia necessario connettersi a mysql da remoto, pensiamo ad esempio a un sistema in cui il webserver e il server sql risiedano su due macchine differenti.

Dobbiamo quindi permettere al webserver di connettersi in remoto (o anche all’interno della stessa LAN), al server di mysql, per far questo dobbiamo editare il file my.cnf di mysql.

Il sistema che ho utilizzato è ubuntu server 8.04. Ipotizziamo di dover abilitare le connessioni per il nostro server, la macchina che hosta il servizio di mysql avrà indirizzo ip 172.16.46.251.

Editiamo il file

nano /etc/mysql/my.cnf

a questo punto cerchiamo la riga contentente

bind-address            = 127.0.0.1

e sostiuiamola con

bind-address            = 172.16.46.251

ed il gioco è fatto, non abbiamo fatto altro che cambiare il bind del servizio in modo che si mettesse in ascolto sull’ip pubblico invece che solo sul localhost.

Ricordate che dovete anche modificare i permessi di accesso sui database, in quanto sui database già creati l’accesso è consentito solamente da 127.0.0.1.

Se per ipotesi volete permettere connessioni remote dall’ip 172.16.46.250 sul database ‘mysql’ con l’utente root, dovrete eseguire i seguenti comandi

root@localhost #  mysql

mysql > use mysql;

mysql> update db set Host='172.16.46.250' where Db='mysql';

mysql> update user set Host='172.16.46.250' where user='root';

mysql> flush privileges;

Ora dovreste potervi connettere in remoto da mysql, vi ricordo inoltre che se volete usare phpmyadmin dovrete ricordarvi di modificare l’indirizzo ip del server direttametne dal file di configurazione, cambiando quindi l’ip anche li da 127.0.0.1 all’ip che vi interessa, nello specifico del nostro esempio 172.16.46.251.

Saluti

Matteo

1. Creiamo la nostra VM su vmware esx o infrastructure
Logghiamoci sul nostro vmware server o esx server e creiamo la la nostra macchina virtuale, che chiameremo V, dove vogliamo spostare la nostra macchina fisica che, chiameremo P.

2. Avviamo V e installaimo il server NFSD
Per fare questo procuriamoci una Live Distro (io ho usato RIP Linux, ma di fatto basta una distro che permetta di lanciare NFSD)
Una volta avviata la macchina andiamo a configurare la il disco dove vogliamo mettere il nostro sistema.
Ad esempio ipotizziamo che il disco della macchina V abbia due partizioni /dev/sda1 e /dev/sda2 rispettivamente una partizione ext3 e una di swap.

Quello che vogliamo fare ora è montare la partizione principale /dev/sda1 e poi condividerla via NSF, per fare questo procediamo come segue

# mkdir /mnt/sda1
# mount /dev/sda1 /mnt/sda1

e configuriamo lo share nfs editanto il file /etc/exports e aggiungiamo la seguente stringa

/mnt/sda1 *(rw,no_root_squash)

In questo modo abilitamo il nostro share a chiunque * , in modalità rw.

Ora per lanciare nfs dobbiamo eseguire i seguenti tre comandi in questo ordine

# rpc.portmap
# rpc.mountd
# rpc.nsf

se tutto è ok non dovreste ricevere alcun output.

Per fargli prendere le modifiche ai file di configurazione ad NFS dobbiamo lanciare il comando

# exportfs -a

per controllare la correttezza degli share date un

# exportfs

e otterrete qualcosa di simile a

/mnt/sda1 <world>

Ora a me non è servito però controllate la correttezza degli accessi delle varie acl nei file /etc/hosts.deny e /etc/hosts.allow

Andiamo ora sulla nostra macchina fisica P, e montiamo la nostra paritizione via NSF con il comando

# mount -t nsf 128.99.1.101:/mnt/sda1 /mnt/esx1remote

ora avremo montato via nsf la nostra macchina e non ci resterà altro da fare che copiare sopra i nostri file (ad esclusione di /proc ), nella partizione remota.

Il passo successivo, una volta copiati i file, è solo quello di entrare in chroot sulla nostra vm V ed operare le opportune modifiche per il corretto boot del sistema.

Salve a tutti oggi ci occupiamo di un problema, dal mio punto di vista molto interessante: come convertire il proprio server linux in una virtual machine e importarla sul nostro vmware esx server.

Pre-requisiti di questo articolo sono una buona conoscenza dei sistemi linux, conoscenze di base di virtualizzazione, disponibilità si un esx server già installato.

Per prima cosa avviamo la macchina linux con un cd di avvio (slackware, knoppix o cosa preferite), e assicuriamoci di avere un hard disk (interno o esterno) per poter creare l’immagine del nostro disco, che utilizzeremo successivamente per la conversione.

Una volta avviata la shell di emergenza ci accingiamo a creare la nostra immagine tramite il comando dd, ipotizzando che il nostro disco fisico dove è installato linux sia /dev/hda e che l’immagine la metteremo nella cartella /mnt/sda1 (ovviamente dopo aver montato il disco esterno tramite appositi comandi) procediamo come segue:

# mkdir /mnt/sda1

# mount /dev/sda1 /mnt/sda1

# dd if=/dev/hda conv=sync,noerror bs=64K > /mnt/sda1/hda.img

Avremo a questo punto un immagine perfetta del nostro disco nel file /mnt/sda1/hda.img, che sarà la base che useremo per la nostra conversione.

Scarichiamo ora sul nostro client il programma LiveView, che ci permetterà di creare una VM a partire dall’immagine che gli forniremo.

Tale programma è talmente facile da usare che evito di spiegarvi come fare, il frontend parla da solo.

A questo punto il gioco è fatto: abbiamo la VM che funziona perfettamente vmware server, ora tramite vmware converter (basta anche solo la versione free non l’enterprise), possiamo importare la macchina creata tramite LifeView direttaente sul nostro esx server, scegliendo opportunamente le informazioni che ci vengono chieste dal converter.

ATTENZIONE!!!!!: una volta avviata la macchina su esx, fate attenzione che probabilmente alcuni device saranno cambiati (es: i dischi saranno diventati /dev/sda mentre prima erano /dev/hda, dovrete quindi entrare in rescue mode anche sulla macchina virtualizzate e fixare il dovuto, solitamente /etc/fstab, /etc/mtab e /etc/lilo.conf), per il resto non ho avuto altri problemi.

Saluti

Matteo

Ebbene si, il mio blog non mi bastava! Sono stato contattato dall’amico marco, l’obiettivo è parlare in modo concreto di amministrazione di sistemi GNU/Linux prendendo spunto dai reali problemi affrontati nella vita lavorativa di ogni giorno, il sito è tuxblog.it.

Questo progetto non è un isola da sola in mezzo al nulla, fa parte infatti di una piccola rete di blog che si sta creando a cui collaborano daniel (PHP5Blog.it) e matteo (CSSBlog.it).

Il tutto riunito sotto la rete chiamata gagblog.it!