l’FTP trasferisce userid e password in chiaro e per evitrare che un malandrino possa recuperare le info, si abilita l’TLS con certificato.

Per prima cosa creare un certificato self-signed con

sudo openssl req -x509 -days 365 -newkey rsa:2048 -nodes -keyout /etc/vsftpd.pem -out /etc/vsftpd.pem

Una volta creato bisogna dire a vsftpd di utilizzarlo in aggiungendo al /etc/vsftpd.conf queste righe:

# enable TLS/SSL
ssl_enable=YES

# force client to use TLS when logging in
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH

# specify SSL certificate/private key (Debian/Ubuntu)
# For CentOS/Fedora/RHEL, replace it with /etc/vsftpd/vsftpd.pem
rsa_cert_file=/etc/vsftpd.pem
rsa_private_key_file=/etc/vsftpd.pem

# define port range for passive mode connections
pasv_max_port=50000
pasv_min_port=5099

Ho settato a NO le due righe del “force_local…” in quanto voglio lasciare aperta la possibilità di ciollegarsi anche con il banale ftp

Far ripartire vsftpd con un

service vsftpd restart

Sono state anche inserite, tanto non fa male, le porte da utilizzare per l’ftp passivo.
Potrebbe essere terminato qui il tutto… ma non è così!
Il protocollo FTP è molto rognoso in quanto spostando la connessione su passive gira al client la coppia ip:porta sulla quale connettersi:
il server non sa di avere un l’indirizzo esterno e gira l’indirizzo che lui conosce, il suo ip interno

pasv_enable=YES
pasv_addr_resolve=YES 
#pasv_address=xxx.xxx.xxx.xxx <=my external Ip  
pasv_address=domain.com.com <= my domain

con le righe qui sopra, il server fornirà le corrette coordinate ip:porta senza possibilità di errore.

Lavorando con appliocazioni i log sono fondamentali, soprattutto pewr lo start di servi ed altro..

Per essere sicuri che tutto sia partito correttamente bisogna trovare nei log quella parolina magica che ti tranquillizza, tipo Started, Running … od altro

A me serviva una cosa che potesse funzionare e dopo aver cercato in rete ho generato questo mostro:

cd /home/user_APP/APP_HOME
export JAVA_HOME=/home/user_app/JAVA/jdk-14.0.2
if ! [[ "$PATH" =~ "user_app" ]]; then
export PATH=/home/user_app/jdk-14.0.2/bin:$PATH
fi
for app in app1 app2 app3 app3 app4 app5
do
pyfiglet -f poison $app
cd $app
./start.sh
while IFS= read -r LOGLINE || [[ -n "$LOGLINE" ]]; do
printf '%s\n' "$LOGLINE"
[[ "${LOGLINE}" =~ "Started" ]] && break
done < <(timeout 300 tail -f Service.out)
cd ..
done

In questo modo vengono lanciate in sequenza delle diverse appX , visualizzato l’out di spingboot per verificare che non ci siano problemi.

Una piccola nota, siccome dove si trova l’applicazione viene lanciata o a mano o dall’autoscaling group di AWS , ho dovuto mettere alcune variabili di ambiente all’interno dello script ed anche la verifica dell’impostazione della variabile PATH.

ancora la riga (timeout 300 tail -f Service.out) imposta a massimo 5 minuti l’attesa per aspettare la stringa Started che da la conferma della corretta partenza del microservizio.