Server-to-server anche dopo sblocco non permette collegamento

[Torpedo]

Ciao,

questa discussione è il seguito di un'altra mia precedente discussione (questa).
In buona sostanza, all'epoca, avevo il problema che non riuscivo ad installare dei plug-in, presenti su web hosting tipo Github.com, nel mio spazio web, il quale utilizza il servizio di wiki offerto da DokuWiki.org. In particolare, dopo aver scaricato nel mio computer il plug-in, usando il pannello di controllo apposito, non riuscivo a fare l'upload.

Il problema è stato risolto sbloccando l'elenco dei server ai quali AV limita le connessioni.

Segue un nuovo problema.
Questo pannello di gestione dei plug-in (che è presente in ogni distribuzione wiki e quindi è anche nel mio spazio web) offre la possibilità di passare direttamente il link del repository dal quale scaricare il plug-in (quindi mi eviterebbe di dover scaricare in locale il pacchetto per poi caricarlo in remoto). Tuttavia questa operazione non mi viene permessa ed ottengo il seguente messaggio di errore:

Unable to download the file: https://github.com/NOME/DEL/PLUGIN

A questo punto mi domando: in quali casi il servizio di sblocco server-to-server non funziona? Leggevo sul loro forum che potrebbe essere una questione di SSL. Esiste qualche altra opzione che qui, in AlterVista, è possibile sbloccare/attivare?

Grazie

Anche sbloccando le connessioni, queste sono permesse soltanto attraverso la porta 80 (HTTP) e 443 (HTTPS).
Altre porte non possono essere usate.
Che porta stai tentando di usare?

[Torpedo]

Per quanto riguarda i plug-in ospitati su Github.com la documentazione ufficiale dice che le porte usate sono 22, 80, 443, e 9418. Cercando in rete, comunque, sembra che la porta usata per indirizzi non git:// è la 443, il che sarebbe il caso mio. Quindi (se ciò è vero) non dovrebbe essere un problema di porta.

[karl94]

È un URL con protocollo HTTPS, quindi viene normalmente usata la porta 443 e non è un problema su AlterVista.
Quel messaggio di errore sembra venire generato qua: https://github.com/splitbrain/dokuwi...nsion.php#L840
Quindi è da ispezionare la funzione io_download, che può restituire false per differenti motivi. Per cominciare io aggiungerei del codice per controllare se il problema è relativo alla chiamata al metodo get in riga 585.

[Torpedo]

Onestamente non saprei come fare per controllare se il problema è relativo alla chiamata al metodo get. Se non è una cosa troppo difficile e avete tempo/modo/voglia di guidarmi, posso anche provare, ma 1) siccome questo è un problema molto comune agli utenti che utilizzano questo servizio di wiki su free web hosting e 2) siccome la risposta che tutti ricevono sul forum di DokuWiki.org è sempre la stessa (cioè è un problema legato alla comunicazione repository+servizio web hosting usato) mi viene il sospetto che l'inghippo non stà in quello script.

Dal basso della mia ignoranza in materia di script lato server ho voluto fare una prova utilizzando un altro servizio di free hosting, ma con tutte le funzioni per il server-to-server già attive. Li, il download dei plug-in, funziona senza alcun problema e senza bisogno di mettere mano ad alcuna configurazione. Allora avevo cominciato a guardare le differenze tra i file phpinfo() di Altervista e di quell'altro, solo che, molte direttive non le ho trovate nel phpinfo() di Altervista. Per questo ho il sospetto che qui, su Altervista, manchi la possibilità di attivare/sbloccare qualche ulteriore funzione. Se può servire posso incollare alcune delle direttive del phpinfo() che leggo sull'altro web hosting.

Ad ogni modo, l'aver risolto il problema che avevo postato nella precedente discussione (vedi link nel post #1 di questa discussione) già mi permette di lavorare. Solo volevo capire come mai lo sblocco server-to-server non è effettivamente totale.

[karl94]

Stiamo effettuando delle verifiche in merito.

[Torpedo]

Grazie mille.

Ne aprofitto per aggiungere qualche info che magari può aiutare a capire dove cercare il problema (se veramente c'è ne è uno).

Io utilizzo il servizio wiki di DokuWiki.org anche in locale utilizzando Xampp ed avevo lo stesso problema di connettività che ho, tutt'ora, qui su Altervista.
In particolare, questo è il mio scenario:
XAMPP per Linux 64bit che include:

• PHP 5.6.3
• MySQL 5.6.21
• phpMyAdmin 4.2.11
• OpenSSL 1.0.1j

Pacchetti Linux già installati:

• libcurl3 7.35.0-1ubuntu2.3
• libssl1.0.0 1.0.1f-1ubuntu2.8
• php5-curl 5.5.9+dfsg-1ubuntu4.6
• php5-cli 5.5.9+dfsg-1ubuntu4.6
• openssl 1.0.1f-1ubuntu2.8
• ssl-cert 1.0.33

Come riportato qui:
http://php.net/manual/de/migration56...tificate-paths
ho eseguito un file .php con questo codice:

<?php
var_dump(openssl_get_cert_locations());
?>

Ottenendo il seguente output:

array(8) {
 ["default_cert_file"]=> string(33) "/opt/lampp/share/openssl/cert.pem"
 ["default_cert_file_env"]=> string(13) "SSL_CERT_FILE"
 ["default_cert_dir"]=> string(30) "/opt/lampp/share/openssl/certs"
 ["default_cert_dir_env"]=> string(12) "SSL_CERT_DIR"
 ["default_private_dir"]=> string(32) "/opt/lampp/share/openssl/private"
 ["default_default_cert_area"]=> string(24) "/opt/lampp/share/openssl"
 ["ini_cafile"]=> string(0) ""
 ["ini_capath"]=> string(14) ""
 }

Ma:

• in /opt/lampp/share/openssl non c'è alcun file chiamato cert.pem
• in /opt/lampp/share/openssl/certs c'è solo un file vuoi chiamato NOTEMPTY
• in /opt/lampp/share/openssl/private c'è solo un file vuoi chiamato NOTEMPTY

Quindi PHP stava cercando dei certificati nel posto sbagliato. Questo era il problema!

Di seguito quello che ho fatto per risolvere il problema.
Da:
http://curl.haxx.se/docs/caextract.html
ho scaricato il file:
cacert.pem

Per capire dove installarlo ho usato il comando da terminale:

openssl version -d

che nel mio caso ha restituito:

/usr/lib/ssl/

il quale è un link simbolico a:

/etc/ssl/

Quindi ho messo cacert.pem in /etc/ssl/certs.
Quindi, in /opt/lampp/etc/php.ini ho aggiunto le seguenti due righe (vedi http://docs.php.net/manual/en/contex...ext.ssl.cafile):

openssl.cafile=/etc/ssl/certs/cacert.pem
openssl.capath=/etc/ssl/certs

Ho salvato il file e riavviato Apche.

Ora riesco a collegarmi ai vari repository dove si trovano i vari plugins senza alcun impedimento.

Anche se quanto ho appena descritto è relativo PHP 5.6, mentre la versione di PHP che ho qui su Altervista è la 5.4, penso che controllare dove vengano cercati i certificati, quantomeno, tolga qualche dubbio.

Grazie mille.

Ne aprofitto per aggiungere qualche info che magari può aiutare a capire dove cercare il problema (se veramente c'è ne è uno).

Io utilizzo il servizio wiki di DokuWiki.org anche in locale utilizzando Xampp ed avevo lo stesso problema di connettività che ho, tutt'ora, qui su Altervista.
In particolare, questo è il mio scenario:
XAMPP per Linux 64bit che include:

• PHP 5.6.3
• MySQL 5.6.21
• phpMyAdmin 4.2.11
• OpenSSL 1.0.1j

Pacchetti Linux già installati:

• libcurl3 7.35.0-1ubuntu2.3
• libssl1.0.0 1.0.1f-1ubuntu2.8
• php5-curl 5.5.9+dfsg-1ubuntu4.6
• php5-cli 5.5.9+dfsg-1ubuntu4.6
• openssl 1.0.1f-1ubuntu2.8
• ssl-cert 1.0.33

Come riportato qui:
http://php.net/manual/de/migration56...tificate-paths
ho eseguito un file .php con questo codice:

<?php
var_dump(openssl_get_cert_locations());
?>

Ottenendo il seguente output:

array(8) {
 ["default_cert_file"]=> string(33) "/opt/lampp/share/openssl/cert.pem"
 ["default_cert_file_env"]=> string(13) "SSL_CERT_FILE"
 ["default_cert_dir"]=> string(30) "/opt/lampp/share/openssl/certs"
 ["default_cert_dir_env"]=> string(12) "SSL_CERT_DIR"
 ["default_private_dir"]=> string(32) "/opt/lampp/share/openssl/private"
 ["default_default_cert_area"]=> string(24) "/opt/lampp/share/openssl"
 ["ini_cafile"]=> string(0) ""
 ["ini_capath"]=> string(14) ""
 }

Ma:

• in /opt/lampp/share/openssl non c'è alcun file chiamato cert.pem
• in /opt/lampp/share/openssl/certs c'è solo un file vuoi chiamato NOTEMPTY
• in /opt/lampp/share/openssl/private c'è solo un file vuoi chiamato NOTEMPTY

Quindi PHP stava cercando dei certificati nel posto sbagliato. Questo era il problema!

Di seguito quello che ho fatto per risolvere il problema.
Da:
http://curl.haxx.se/docs/caextract.html
ho scaricato il file:
cacert.pem

Per capire dove installarlo ho usato il comando da terminale:

openssl version -d

che nel mio caso ha restituito:

/usr/lib/ssl/

il quale è un link simbolico a:

/etc/ssl/

Quindi ho messo cacert.pem in /etc/ssl/certs.
Quindi, in /opt/lampp/etc/php.ini ho aggiunto le seguenti due righe (vedi http://docs.php.net/manual/en/contex...ext.ssl.cafile):

openssl.cafile=/etc/ssl/certs/cacert.pem
openssl.capath=/etc/ssl/certs

Ho salvato il file e riavviato Apche.

Ora riesco a collegarmi ai vari repository dove si trovano i vari plugins senza alcun impedimento.

Anche se quanto ho appena descritto è relativo PHP 5.6, mentre la versione di PHP che ho qui su Altervista è la 5.4, penso che controllare dove vengano cercati i certificati, quantomeno, tolga qualche dubbio.

ciAO! ho lo stesso problema, ma non capisco come modificare il file php.ini
puoi darmi qualche dritta?
grazie

[karl94]

Legasal: apri una nuova discussione spiegando dettagliatamente che problema incontri. Questa discussione è estremamente vecchia e sono cambiate diverse cose da quando è stata aperta.