Usare git su ISPConfig3: il problema della directory .ssh

Oggi abbiamo messo la testa su un problema che si è verificato durante la pubblicazione di un progetto in Laravel, problema risolvibile in pochi minuti seguendo il tutorial.
Total
0
Shares

Oggi abbiamo messo la testa su un problema che si è verificato durante la pubblicazione di un progetto in Laravel, problema che è risolvibile in pochi minuti ma che potrebbe far perdere un sacco di tempo a chi non ne è al corrente – e quindi ci piace condividerlo qui 🙂

Stavamo cercando di clonare in locale il codice che sta sul repository mediante git ed utilizzando un utente shell appositamente creato con ISPConfig, senza alcuna restrizione e senza chroot: un normalissimo utente shell, di quelli che si usano per dare un accesso SSH al dev che lavora su quel singolo progetto oppure per permettere al cliente di accedere mediante SFTP al proprio hosting.

Lanciando il comando git clone abbiamo ottenuto un messaggio inaspettato:

Il problema è stato quasi subito chiaro: il client git riteneva che la home dir dell’utente in uso, che a titolo di esempio chiamiamo utente_in_uso, fosse

quando invece è

Sorvoliamo sulle ragioni tecniche di questo misunderstanding – che comunque è imputabile ad un bug di ISPConfig – e passiamo subito alla soluzione: bisogna fare in modo che entrambi i punti di vista coincidano, creando un link simbolico tra la vera home dir e quella presupposta da git. In parole povere, basta accedere come root e lanciare questo comando:

Al primo tentativo però l’operazione fallisce con un bellissimo errore di Permission Denied: vi sembrerà impossibile, ma nemmeno root è autorizzato a creare un file nella posizione indicata dal comando.

La causa di questa anomalia sta nel fatto che ISPConfig protegge le directory con struttura

impedendo a chiunque – root compreso – di crearvi file o subdirectory.

E’ sufficiente ripetere l’operazione rimuovendo temporaneamente questa limitazione per poi ripristinarla immediatamente dopo avere creato il link simbolico di cui abbiamo bisogno:

Ora possiamo procedere con la clonazione da repository in locale mediante git clone.

1 commento
  1. un po’ criptico ma ci sono i comandi che mi servivano e quelli li capisco bene, in effetti ho avuto anche io lo stesso problema e avevo lasciato perdere ma leggendo il tuo post ho capito cosa non andava grazie

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ti potrebbe interessare anche

Kernel 2.6.22 con Debian Etch e Backports

Lavoro quotidianamente con Debian Etch: la utilizzo con estrema soddisfazione sia sui server aziendali che sul notebook personale (lo stesso con cui scrivo in questo momento). Sono un convinto difensore…