☺
ansible usa ssh per connettersi a tutti i server ed eseguire le sue cose, e' agentless, sui server che vengono "gestiti" con ansible non c'e' nessun agente che riceve gli ordini, fa tutto via ssh.
le credenziali per il login ssh ho deciso di farle gestire al ssh-agent si puo configurare ansible per fare il login ssh con user/pwd ma non e' consigliato, si puo anche fare come dio comanda e mettere la chiave negli known_hosts ma volevo complicarmi la vita con ssh-agent.
dopo ogni riavvio basta rifare un ssh-add, immettere la passhprase una volta sola e da li in poi passwordless secure login fino al riavvio.
per quanto poi riguarda la configurazione vera e propria dei serer ansible si gestisce gli host e gli utenti con parametri tra i quali:
uno e' il nome utente per fare ssh ansible_user@hostip, l'altro e' il nome utente con il quale verra' fatto sudo una volta stabilita la connessione.
ho fatto un paio di test con dei singoli comandi da shell e con il paramentro "become=yes" da terminale o negli script potevo specificare se l'azione andava eseguito con sudo o meno, l'utente che fa il login via ssh e' l'utente che specifico nell'host file (webserver per il webserver e cosi' via), tutto ok. per un po di tempo sono andato avanti cosi ed in effetti era comodo fare cose come questa:
poi stasera d'improvviso ssh-add si e' lamentato che i permessi sulle chiavi erano troppo aperti, quindi chmod 400 sul file id_rsa.pub ed ssh-add era di nuovo contento, ha caricato le chiavi nell'agente, riprovato ad usare ansible e ssh sui vari server mi chiedeva la passhprase nonostante la chiave fosse correttamente caricata nell'agente del mio laptop. (ssh-add -l la mostrava).
Oltretutto non accettava la passphrase corretta per sbloccare il login (da notare che mi chiede la passphrase delle chiavi, non la password dell'utente che ha fatto il login ssh, la passhprase della chiave che gia' aveva)
ho realizzato che non mi ricordavo mica se avevo usato sudo o meno prima di ssh-copy-id e ssh-add, probabilmente una combinazione a caso delle due cose, infatti con sudo ansible andava di nuovo tutto, quindi ho pensato che per semplificarmi la vita questa sarebbe stata una mossa saggia:
lo ho fatto per tutti i server.
ha ricominciato a funzionare tutto, mi sentivo troppo un acaro russo, quindi ho scritto un playbook, che in realta' e' la parte piu' facile, invece che inserire tutit i comandi uno dietro l'altro li si formatta un po diversamente in uno script e poi lo si lancia con ansible, lo ho avviato e questo e' il risultato:
e questo mi sembrava strano, ho preso accesso manuale al webserver, ho provato ad installare firewalld e non era stato installato anche se ansible aveva detto di avercela fatta! a quel punto lo ho installato manualmente ed ho provato a riavviare il playbook per vedere cosa sarebbe successo, mi sono dimenticato di fargli fare il resume con --limit come mi aveva detto e questo e' stato il risultato:
quindi mi sa che ho fatto casino con i permessi, dal webserver i permessi di yum.repos.d sembrano giusti, l'utente webserver puo accederci con sudo, ansible non so perche' alla seconda run dello stesso script non ce la fa piu'.
merda, non so come raccapezzarmici adesso, pero' non voglio gettare la spugna e ricominciare ne semplificarmi la vita installando il coso omanualmente, cosa che so gia' fare ed ho gia' fatto con successo piu' volte, voglio riuscire a fixare i permessi che devo aver sputtanato da qualche parte e fare tutto con il playbook di ansible.
**Modificato dall'autore il 28.07.2017 21:48**
le credenziali per il login ssh ho deciso di farle gestire al ssh-agent si puo configurare ansible per fare il login ssh con user/pwd ma non e' consigliato, si puo anche fare come dio comanda e mettere la chiave negli known_hosts ma volevo complicarmi la vita con ssh-agent.
ssh-keygen -> le chiavi le mette in ~./.ssh/id_rsa.pub ssh-copy-id webserver@webserverip ssh-copy-id storage@storageip ssh-copy-id drone@droneip ssh-add
dopo ogni riavvio basta rifare un ssh-add, immettere la passhprase una volta sola e da li in poi passwordless secure login fino al riavvio.
per quanto poi riguarda la configurazione vera e propria dei serer ansible si gestisce gli host e gli utenti con parametri tra i quali:
ansible_user=webserver.storage,drone ansible_ssh_private_key_file= ~/.ssh/id_rsa.pub ansible_become_user=webserver,storage,drone ansible_become_pass=pass1,pass2,pass3 ansible_become_method=sudo
uno e' il nome utente per fare ssh ansible_user@hostip, l'altro e' il nome utente con il quale verra' fatto sudo una volta stabilita la connessione.
ho fatto un paio di test con dei singoli comandi da shell e con il paramentro "become=yes" da terminale o negli script potevo specificare se l'azione andava eseguito con sudo o meno, l'utente che fa il login via ssh e' l'utente che specifico nell'host file (webserver per il webserver e cosi' via), tutto ok. per un po di tempo sono andato avanti cosi ed in effetti era comodo fare cose come questa:
ansible network -m shell -a 'ss -tulpn' -become -K
SUDO password:
webserver1 | SUCCESS | rc=0 >>
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 0 10.10.10.XXX:22 *:* users:(("sshd",pid=4350,fd=3))
storage1 | SUCCESS | rc=0 >>
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 0 10.10.10.XXX:22 *:* users:(("sshd",pid=3713,fd=3))
drone1 | SUCCESS | rc=0 >>
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:12400 *:* users:(("openvpn",pid=2952,fd=6))
tcp LISTEN 0 0 10.10.10.XXX:22 *:* users:(("sshd",pid=8823,fd=3))
poi stasera d'improvviso ssh-add si e' lamentato che i permessi sulle chiavi erano troppo aperti, quindi chmod 400 sul file id_rsa.pub ed ssh-add era di nuovo contento, ha caricato le chiavi nell'agente, riprovato ad usare ansible e ssh sui vari server mi chiedeva la passhprase nonostante la chiave fosse correttamente caricata nell'agente del mio laptop. (ssh-add -l la mostrava).
Oltretutto non accettava la passphrase corretta per sbloccare il login (da notare che mi chiede la passphrase delle chiavi, non la password dell'utente che ha fatto il login ssh, la passhprase della chiave che gia' aveva)
ho realizzato che non mi ricordavo mica se avevo usato sudo o meno prima di ssh-copy-id e ssh-add, probabilmente una combinazione a caso delle due cose, infatti con sudo ansible andava di nuovo tutto, quindi ho pensato che per semplificarmi la vita questa sarebbe stata una mossa saggia:
ssh-copy-id root@serverip ssh-copy-id ansible_user@serverip sudo ssh-copy-id ansible_user@serverip
lo ho fatto per tutti i server.
ha ricominciato a funzionare tutto, mi sentivo troppo un acaro russo, quindi ho scritto un playbook, che in realta' e' la parte piu' facile, invece che inserire tutit i comandi uno dietro l'altro li si formatta un po diversamente in uno script e poi lo si lancia con ansible, lo ho avviato e questo e' il risultato:
ansible-playbook -f 1 -i hosts -v site.yml
Using /etc/ansible/ansible.cfg as config file
PLAY [Install WordPress, MariaDB, Nginx, and PHP-FPM] **************************
TASK [setup] *******************************************************************
ok: [webserver1]
TASK [common : Copy the NGINX repository definition] ***************************
changed: [webserver1] => {"changed": true, "dest": "/etc/yum.repos.d/", "src": "/home/dada/ansible/dada-wordpress-playbook/roles/common/files/nginx.repo"}
TASK [common : Copy the EPEL repository definition] ****************************
changed: [webserver1] => {"changed": true, "dest": "/etc/yum.repos.d/", "src": "/home/dada/ansible/dada-wordpress-playbook/roles/common/files/epel.repo"}
TASK [common : Copy the REMI repository definition] ****************************
changed: [webserver1] => {"changed": true, "dest": "/etc/yum.repos.d/", "src": "/home/dada/ansible/dada-wordpress-playbook/roles/common/files/remi.repo"}
TASK [common : Create the GPG key for NGINX] ***********************************
changed: [webserver1] => {"changed": true, "dest": "/etc/pki/rpm-gpg", "src": "/home/dada/ansible/dada-wordpress-playbook/roles/common/files/RPM-GPG-KEY-NGINX"}
TASK [common : Create the GPG key for EPEL] ************************************
changed: [webserver1] => {"changed": true, "dest": "/etc/pki/rpm-gpg", "src": "/home/dada/ansible/dada-wordpress-playbook/roles/common/files/RPM-GPG-KEY-EPEL-7"}
TASK [common : Create the GPG key for REMI] ************************************
changed: [webserver1] => {"changed": true, "dest": "/etc/pki/rpm-gpg", "src": "/home/dada/ansible/dada-wordpress-playbook/roles/common/files/RPM-GPG-KEY-remi"}
TASK [common : Install Firewalld] **********************************************
changed: [webserver1] => {"changed": true, "changes": {"installed": ["firewalld"]}, "results": []}
TASK [common : Firewalld service state] ****************************************
fatal: [webserver1]: FAILED! => {"changed": false, "failed": true, "msg": "Could not find the requested service firewalld: cannot enable"}
to retry, use: --limit @/home/dada/ansible/dada-wordpress-playbook/site.retry
PLAY RECAP *********************************************************************
webserver1 : ok=8 changed=7 unreachable=0 failed=1
e questo mi sembrava strano, ho preso accesso manuale al webserver, ho provato ad installare firewalld e non era stato installato anche se ansible aveva detto di avercela fatta! a quel punto lo ho installato manualmente ed ho provato a riavviare il playbook per vedere cosa sarebbe successo, mi sono dimenticato di fargli fare il resume con --limit come mi aveva detto e questo e' stato il risultato:
ansible-playbook -f 1 -i hosts -v site.yml
Using /etc/ansible/ansible.cfg as config file
PLAY [Install WordPress, MariaDB, Nginx, and PHP-FPM] **************************
TASK [setup] *******************************************************************
ok: [webserver1]
TASK [common : Copy the NGINX repository definition] ***************************
fatal: [webserver1]: FAILED! => {"changed": false, "checksum": "eb1ebf4320d557d75a25cd051cbbef5f3c6430c6", "failed": true, "msg": "Destination /etc/yum.repos.d not writable"}
to retry, use: --limit @/home/dada/ansible/dada-wordpress-playbook/site.retry
PLAY RECAP *********************************************************************
webserver1 : ok=1 changed=0 unreachable=0 failed=1
quindi mi sa che ho fatto casino con i permessi, dal webserver i permessi di yum.repos.d sembrano giusti, l'utente webserver puo accederci con sudo, ansible non so perche' alla seconda run dello stesso script non ce la fa piu'.
merda, non so come raccapezzarmici adesso, pero' non voglio gettare la spugna e ricominciare ne semplificarmi la vita installando il coso omanualmente, cosa che so gia' fare ed ho gia' fatto con successo piu' volte, voglio riuscire a fixare i permessi che devo aver sputtanato da qualche parte e fare tutto con il playbook di ansible.
**Modificato dall'autore il 28.07.2017 21:48**
Please consider the environment before printing this message, 50% of the above is useless!
-
-
■ @ 2017-07-29 13:17:23.0 di ::1
-
■ @ 2017-07-29 14:41:27.0 di dada216
-
■ @ 2017-07-29 14:45:08.0 di ::1
-
-
■ @ 2017-07-29 14:00:40.0 di dada216
-
-