Monthly Archives: giugno 2014

Resettare la password di root in mysql

mysql-icon-180x180Può capitare a volte di dover resettare la password di root in mysql, poichè ve la siete dimenticata oppure avete settato erroneamente i privilegi e quindi non potete più effettuare modifiche.Con pochi semplici passaggi, è possibile ripristinare sia password che permessi.

La sintassi che segue è riferita ad un server MySQL che gira in ambiente Linux. Per MySQL sotto Windows, il ripristino della password di root è estremamente semplice grazie ai tool grafici forniti in corredo.

L’unica cosa indispensabile, per eseguire l’operazione di ripristino, è conoscere la password di root del server Linux, infatti è necessario entrare in console, anche remota (ssh o telnet) con privilegi d’amministratore.

Una volta loggati come root, bisogna stoppare il processo MySQL con il comando:

/etc/init.d/mysql stop

oppure se non disponibile l’rc scrip si può procedere come segue:

kill `cat /mysql-data-directory/host_name.pid`

dove mysql-data-directory è la directory in cui sono contenuti i dati del server (normalmente /var/lib/mysql), mentre host_name.pid è il file che contiene il pid del server mysql il esecuzione.

Terminato il demone MySQL, bisogna rilanciarlo con il comando

mysqld_safe --skip-grant-tables &

a questo punto il demone riparte ignorando la tabella dei permessi, e possiamo accedere in mysql console come segue:

mysql -u root

e ripristinare la password:

mysql>UPDATE mysql.user SET Password=PASSWORD('nuova password') WHERE User='root';

oppure ripristinare i permessi:

mysql>GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED BY 'nuova password' WITH GRANT OPTION;

se la precedente operazione non da errori, dobbiamo confermare le modifiche con il comando:

mysql>FLUSH PRIVILEGES;

Terminate tutte le modifiche necessarie, possiamo riavviare normalmente mysql, ed usarlo con la nuova password.

5 alternative a putty

monitorPutty è il più popolare client SSH per Windows. È molto piccolo e le dimensioni facilitano l’utilizzo. La maggior parte delle persone nel mondo Linux preferiscono utilizzare putty. Ma sono consapevoli del fatto che ci sono molti strumenti a disposizione che offrono molte caratteristiche che putty non ha. Ho usato molti client ssh ma questi 5 dovrebbero essere i migliori.
1. MobaXterm

MobaXterm è un terminale avanzato per Windows con un server X11, fornisce un client SSH e molti altri strumenti di rete per la elaborazione remota. MobaXterm fornisce tutti i comandi Unix essenziali per il desktop di Windows, in un unico file eseguibile portatile che funziona out-of-the-box.

[Download o Acquista MobaXterm]

2. KiTTY

Kitty è un fork di putty a partire dalla versione 0.63, il miglior client telnet / SSH nel mondo.Kitty è un progettato solo per la piattaforma Microsoft Windows. Per ulteriori informazioni sul software originale, o binari pre-compilati su altri sistemi, si può andare alla pagina Simon Tatham PuTTY.

[Download KiTTY]
3. SecureCRT

SecureCRT per Windows, Mac e Linux fornisce l’emulazione di terminale rock-solid per i professionisti aumentando la produttività con la gestione delle sessioni avanzate e una miriade di modi per risparmiare tempo e semplificare le operazioni ripetitive. SecureCRT offre un accesso remoto sicuro, trasferimento file, e tunneling dei dati per tutti i membri dell’organizzazione.

[Download SecureCRT]
4. Xshell 4

Xshell è un emulatore di terminale potente che supporta SSH, SFTP, telnet, rlogin e SERIAL.

[Download o Acquista Xshell 4]
5. Bitvise SSH Client

Bitvise SSH Client viene utilizzato per avviare le connessioni ai server SSH. Di solito è usato in modo interattivo, in modo che verrà eseguito solo quando un utente lo esegue, ma può anche essere lanciato per eseguire comandi script o trasferimenti di file, o per mantenere una connessione SSH per il port forwarding. Il client SSH viene utilizzato per accedere ad una console di terminale su un server SSH, avviare port forwarding, o avviare i trasferimenti di file da e verso server SSH utilizzando SFTP.

[Download Bitvise SSH Client]

Installazione di un server ldap

stunningmesh-redhat

Provate a seguire queste istruzioni proprio perché la sintassi LDAP è talvolta ingombrante (maiuscole e minuscole, spazi, ecc) e incline ad errori (dn/dc/cn).
Supponiamo che usiamo il dominio example.com e il nome host instructor.example.com.

Installare i seguenti pacchetti:

yum install -y openldap openldap-servers migrationtools

Generare una password LDAP da una chiave segreta (qui redhat):

slappasswd -s redhat -n > /etc/openldap/passwd

Generare un certificato X509 valido per 365 giorni:

openssl req -new -x509 -nodes -out /etc/openldap/certs/cert.pem -keyout /etc/openldap/certs/priv.pem -days 365

output:

Generating a 2048 bit RSA private key
.....+++
..............+++
writing new private key to '/etc/openldap/certs/priv.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:instructor.example.com
Email Address []:

Modificare i pemessi dei file contenuti in /etc/openldap/certs/:

cd /etc/openldap/certs
chown ldap:ldap *
chmod 600 priv.pem

Preparare il database LDAP:

cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Avviare la configurazione del server LDAP:

cd /etc/openldap/slapd.d/cn=config

Modificare il olcDatabase = {2} bdb.ldif di file e sostituire / digitare i valori indicati in grassetto:

olcSuffix: dc=example,dc=com
olcRootDN: cn=Manager,dc=example,dc=com
olcRootPW: passwd # password previously generated
olcTLSCertificateFile: /etc/openldap/certs/cert.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/priv.pem

Modificare il olcDatabase = {1} file di monitor.ldif e sostituire / digitare i valori indicati in grassetto:

olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,dc=example,dc=com" read by * none

Modificare il file /etc/sysconfig/ldap e modificare la seguente opzione da ‘no‘ a ‘‘:

SLAPD_LDAPS=yes

Verificare la configurazione di LDAP (ci dovrebbe essere alcun messaggio di errore):

slaptest -u

Generare file di database (non preoccuparsi di eventuali messaggi di errore!):

slaptest

Cambiare i permessi della cartella LDAP:

chown ldap:ldap /var/lib/ldap/*

Attiva il servizio slapd all’avvio:

chkconfig slapd on

Avviare il servizio slapd:

service slapd start

Controllare l’attività LDAP:

netstat -lt | grep ldap

Creare il file /openldap/base.ldif  /etc con il seguente contenuto:

dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain

dn: ou=People,dc=example,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit

Costruisci la struttura del servizio di directory:

ldapadd -x -w redhat -D cn=Manager,dc=example,dc=com -f base.ldif

Creare due utenti per il test:

mkdir /home/guests
useradd -d /home/guests/ldapuser01 ldapuser01
passwd ldapuser01
useradd -d /home/guests/ldapuser02 ldapuser02
passwd ldapuser02

Passare alla directory per la migrazione degli account utente:

cd /usr/share/migrationtools

Modificare il file migrate_common.ph e sostituire le seguenti righe:

$DEFAULT_MAIL_DOMAIN = "example.com";
$DEFAULT_BASE = "dc=example,dc=com";

Creare gli utenti:

grep ":5[0-9][0-9]" /etc/passwd > passwd
./migrate_passwd.pl passwd users.ldif
ldapadd -x -w redhat -D cn=Manager,dc=example,dc=com -f users.ldif
grep ":5[0-9][0-9]" /etc/group > group
./migrate_group.pl group groups.ldif
ldapadd -x -w redhat -D cn=Manager,dc=example,dc=com -f groups.ldif

Verificare la configurazione con l’utente chiamato ldapuser01:

ldapsearch -x cn=ldapuser01 -b dc=example,dc=com

Aggiungere due nuove regole per il firewall:

iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT

Salvare la configurazione del firewall:

service iptables save

Modificare il file /etc/rsyslog.conf e aggiungere la seguente riga:

local4.* /var/log/ldap.log

Modificare il file /etc/openldap/slapd.d/ cn = config.ldif e aggiungere la seguente riga nel mezzo del file:

olcLogLevel: -1

Riavviare il servizio rsyslog:

service rsyslog restart

 

Installazione e configurazione di Kerberos

DebianKerberos è un protocollo di rete che permette l’autenticazione dell’utente mediante crittografia. Kerberos è uno dei protocolli che stanno alla base di Active Directory; tramite esso il controller Windows autentica gli utenti e implementa il meccanismo del Single sign-on (SSO), che permette agli utenti di autenticarsi una sola volta e, successivamente, di accedere alle risorse di rete senza fornire ulteriori credenziali. Ciò avviene grazie a dei ticket, che vengono rilasciati dal server Kerberos e che possono essere ripresentati dal client, anche ad altri server della rete, per ottenere l’accesso alle risorse.
Noi abbiamo bisogno del client Kerberos, per autenticarci sul controller di dominio Windows. Installiamolo:

sudo apt-get install krb5-user

Vengono mostrate un paio di schermate di configurazione:

 

Configurazione del pacchetto

 +--------------¦ Configurazione dell'autenticazione Kerberos +--------------+
 ¦ Quando gli utenti cercano di usare Kerberos specificando un principal o   ¦
 ¦ un nome utente e senza indicare a quale realm amministrativo Kerberos     ¦
 ¦ appartengono, il sistema aggiunge il realm predefinito. Il realm          ¦
 ¦ predefinito potrebbe anche essere usato come realm di un servizio         ¦
 ¦ Kerberos in esecuzione sulla macchina locale. Spesso, il realm            ¦
 ¦ predefinito, è la versione in maiuscolo del dominio DNS locale.           ¦
 ¦                                                                           ¦
 ¦ Realm predefinito per Kerberos versione 5:                                ¦
 ¦                                                                           ¦
 ¦ ACME.LOCAL_______________________________________________________________ ¦
 ¦                                                                           ¦
 ¦                                  <OK>                                     ¦
 ¦                                                                           ¦
 +---------------------------------------------------------------------------+

  Diamo ok…

Configurazione del pacchetto

 +--------------¦ Configurazione dell'autenticazione Kerberos +--------------+
 ¦                                                                           ¦
 ¦ Solitamente i client trovano i server Kerberos del proprio realm          ¦
 ¦ predefinito tramite il DNS. I server del proprio realm sono stati         ¦
 ¦ trovati nel DNS. Nella maggior parte dei casi è meglio usare il DNS per   ¦
 ¦ cercare questi server così quando l'insieme dei server del proprio realm  ¦
 ¦ cambia, non sarà necessario riconfigurare ogni macchina del realm. È      ¦
 ¦ comunque possibile, in casi particolari, configurare localmente           ¦
 ¦ l'insieme dei server del proprio realm Kerberos.                          ¦
 ¦                                                                           ¦
 ¦ Aggiungere i server Kerberos predefiniti in /etc/krb5.conf?               ¦
 ¦                                                                           ¦
 ¦                    <Sì>                        <No>                       ¦
 ¦                                                                           ¦
 +---------------------------------------------------------------------------+

…e scegliamo No. Lasciamo che sia il DNS a scovare il servizio Kerberos. Il protocollo Kerberos impone che il cosiddetto clock skew (differenza di orario) tra client e server sia inferiore a 5 minuti, per evitare che un utente possa resettare il proprio orologio e continuare ad usare un ticket Kerberos scaduto. Per questo motivo, è fondamentale che le due macchine Linux e Windows siano sincronizzate. Consiglio a tal proposito di installare NTP (Network Time Protocol), che assolve allo scopo in modo automatico e trasparente:

sudo apt-get install ntp

Editiamo il file di configurazione, per dire a ntp di leggere l’ora dal nostro server Windows:

sudo nano /etc/ntp.conf

Scendiamo di qualche riga. Troveremo queste direttive:

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

 

Commentiamole tutte mettendo un carattere # all’inizio della riga, e aggiungiamo il nostro server Windows:

#server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst
server 192.168.1.20 iburst

Riavviamo il servizio:

sudo service ntp restart

A questo punto dovremmo poter inizializzare un ticket per l’utente administrator:

kinit administrator
Password for administrator@ACME.LOCAL:

Inseriamo la password che abbiamo assegnato all’utente Administrator del dominio. Se abbiamo fatto tutto correttamente, non dovremmo vedere messaggi. Abbiamo un ticket Kerberos pronto per l’accesso ai servizi Active Directory di Windows. Ci manca solo Winbind per completare l’integrazione con il dominio, dopodiché passeremo a Samba.