Visualizzazione risultati 1 fino 9 di 9

Discussione: Server-to-server anche dopo sblocco non permette collegamento

  1. #1
    Torpedo non è connesso Utente giovane
    Data registrazione
    16-07-2003
    Messaggi
    50

    Predefinito Server-to-server anche dopo sblocco non permette collegamento

    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



    -La cosa con la quale o senza la quale resta tutto tale e quale-

  2. #2
    Guest

    Predefinito

    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?

  3. #3
    Torpedo non è connesso Utente giovane
    Data registrazione
    16-07-2003
    Messaggi
    50

    Predefinito

    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.



    -La cosa con la quale o senza la quale resta tutto tale e quale-

  4. #4
    karl94 non è connesso Staff AV
    Data registrazione
    03-10-2005
    Messaggi
    17,744

    Predefinito

    È 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.

  5. #5
    Torpedo non è connesso Utente giovane
    Data registrazione
    16-07-2003
    Messaggi
    50

    Predefinito

    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.



    -La cosa con la quale o senza la quale resta tutto tale e quale-

  6. #6
    karl94 non è connesso Staff AV
    Data registrazione
    03-10-2005
    Messaggi
    17,744

    Predefinito

    Stiamo effettuando delle verifiche in merito.

  7. #7
    Torpedo non è connesso Utente giovane
    Data registrazione
    16-07-2003
    Messaggi
    50

    Predefinito

    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:
    Codice:
    <?php
    var_dump(openssl_get_cert_locations());
    ?>
    Ottenendo il seguente output:
    Codice:
    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:
    Codice:
    openssl version -d
    che nel mio caso ha restituito:
    Codice:
    /usr/lib/ssl/
    il quale è un link simbolico a:
    Codice:
    /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):
    Codice:
    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.



    -La cosa con la quale o senza la quale resta tutto tale e quale-

  8. #8
    Guest

    Predefinito

    Citazione Originalmente inviato da Torpedo Visualizza messaggio
    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:
    Codice:
    <?php
    var_dump(openssl_get_cert_locations());
    ?>
    Ottenendo il seguente output:
    Codice:
    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:
    Codice:
    openssl version -d
    che nel mio caso ha restituito:
    Codice:
    /usr/lib/ssl/
    il quale è un link simbolico a:
    Codice:
    /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):
    Codice:
    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

  9. #9
    karl94 non è connesso Staff AV
    Data registrazione
    03-10-2005
    Messaggi
    17,744

    Predefinito

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

Regole di scrittura

  • Non puoi creare nuove discussioni
  • Non puoi rispondere ai messaggi
  • Non puoi inserire allegati.
  • Non puoi modificare i tuoi messaggi
  •