Qualcuno ha mai fatto funzionare una JMX JConsole remota?


120

Sembra che non abbia mai funzionato in passato. Attualmente, SO che non funziona.

Ma avviamo il nostro processo Java:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=6002
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Posso telnet alla porta e "c'è qualcosa" (cioè, se non avvio il processo, niente risponde, ma se lo faccio, lo fa), ma non riesco a far funzionare JConsole riempiendo l'IP e porto.

Sembra che dovrebbe essere così semplice, ma nessun errore, nessun rumore, niente di niente. Semplicemente non funziona.

Qualcuno conosce il suggerimento per questo?


3
Se stai usando Tomcat, questa potrebbe essere la soluzione: stackoverflow.com/questions/1263991/…
Hajo Thelen

5
Hai dimenticato di accettare qualcosa qui @ Will?
Grigio

Risposte:


126

Ho una soluzione per questo:

Se il processo Java è in esecuzione su Linux dietro un firewall e si desidera avviare JConsole / Java VisualVM / Java Mission Control su Windows sulla macchina locale per collegarlo alla porta JMX del processo Java .

Devi accedere alla tua macchina Linux tramite login SSH. Tutte le comunicazioni verranno incanalate sulla connessione SSH.

SUGGERIMENTO: questa soluzione funziona indipendentemente dalla presenza o meno di un firewall.

Svantaggio: ogni volta che riavvii il processo Java, dovrai ripetere tutti i passaggi da 4 a 9.


1. Hai bisogno della suite putty per la tua macchina Windows da qui:

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Almeno il putty.exe


2. Definisci una porta libera sulla tua macchina Linux:

<jmx-remote-port>

Esempio:

jmx-remote-port = 15666      


3. Aggiungere argomenti al processo java sulla macchina Linux

Questo deve essere fatto esattamente in questo modo. Se è fatto come di seguito, funziona per macchine Linux dietro firewall (funziona a causa -Djava.rmi.server.hostname=localhostdell'argomento).

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<jmx-remote-port>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=localhost

Esempio:

java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=15666 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.local.only=false -Djava.rmi.server.hostname=localhost ch.sushicutta.jmxremote.Main


4. Ottieni Process-Id del tuo processo Java

ps -ef | grep <java-processname>

result ---> <process-id>

Esempio:

ps -ef | grep ch.sushicutta.jmxremote.Main

result ---> 24321


5. Trova la porta arbitraria per il download degli stub RMIServer

Il processo java apre una nuova porta TCP sulla macchina linux, dove gli RMI Server-Stub saranno disponibili per il download. Questa porta deve anche essere disponibile tramite SSH Tunnel per ottenere una connessione alla Java Virtual Machine.

Con netstat -lpquesta porta si possono trovare anche i lsof -isuggerimenti su quale porta è stata aperta dal processo java.

NOTA: questa porta cambia sempre quando viene avviato il processo java.

netstat -lp | grep <process-id>

tcp        0      0 *:<jmx-remote-port>     *:*     LISTEN      24321/java
tcp        0      0 *:<rmi-server-port>     *:*     LISTEN      24321/java


result ---> <rmi-server-port>

Esempio:

netstat -lp | grep 24321

tcp        0      0 *:15666     *:*     LISTEN      24321/java
tcp        0      0 *:37123     *:*     LISTEN      24321/java


result ---> 37123


6. Abilita due tunnel SSH dalla tua macchina Windows con putty

Source port: <jmx-remote-port>
Destination: localhost:<jmx-remote-port>
[x] Local       
[x] Auto       

Source port: <rmi-server-port>
Destination: localhost:<rmi-server-port>
[x] Local       
[x] Auto

Esempio:

Source port: 15666
Destination: localhost:15666
[x] Local       
[x] Auto       

Source port: 37123
Destination: localhost:37123
[x] Local       
[x] Auto


Impostazioni per aprire un tunnel SSL tramite Putty


7. Accedi alla tua macchina Linux con Putty con questo tunnel SSH abilitato.

Lascia aperta la sessione di mastice.

Una volta effettuato l'accesso, Putty eseguirà il tunneling di tutte le connessioni TCP alla macchina Linux sulla porta SSH 22.

JMX-Port:

Windows machine: localhost:15666   >>> SSH >>>   linux machine: localhost:15666

RMIServer-Stub-Port:

Windows Machine: localhost:37123   >>> SSH >>>   linux machine: localhost:37123


8. Avviare JConsole / Java VisualVM / Java Mission Control per connettersi al proprio processo Java utilizzando il seguente URL

Funziona, perché JConsole / Java VisualVM / Java Mission Control pensa che ti connetti a una porta sulla tua macchina Windows locale. ma Putty invia tutto il payload alla porta 15666 alla tua macchina Linux.

Sulla macchina Linux prima il processo java dà risposta e rimanda la porta RMIServer. In questo esempio 37123.

Quindi JConsole / Java VisualVM / Java Mission Control pensa di connettersi a localhost: 37123 e putty invierà l'intero payload alla macchina Linux

Il processo Java risponde e la connessione è aperta.

[x] Remote Process:
service:jmx:rmi:///jndi/rmi://localhost:<jndi-remote-port>/jmxrmi

Esempio:

[x] Remote Process:
service:jmx:rmi:///jndi/rmi://localhost:15666/jmxrmi


Connettiti tramite l'URL del servizio jmx


9. GODETEVI # 8-]


1
Solo una piccola domanda qui: non è possibile fare una connessione JMX senza rmi?
Kumar Vaibhav

5
Ho avuto un suggerimento, che possiamo impostare un rmi.port su un numero di porta fisso, quindi possiamo impostare la porta arbitraria per il download degli stub RMIServer. dovrebbe funzionare con la proprietà Java "com.sun.management.jmxremote.rmi.port = <rmi-server-port>". Sembra una funzionalità non documentata in Oracle Java VM.
sushicutta

1
Sicuramente batte dover configurare keystore e trustedstore
TekiusFanatikus

Lo stesso processo, ma non ho ottenuto tale oggetto nella tabella
Wener

2
@sushicutta puoi aggiungere questo suggerimento nella tua risposta, funziona perfettamente e puoi rimuovere i passaggi da 4 a 6, il problema è che la tua porta inoltrata deve essere la stessa della porta originale e sia la porta jmx che quella rmi devono anche farlo essere lo stesso
squallido

80

L'aggiunta ha -Djava.rmi.server.hostname='<host ip>'risolto questo problema per me.


2
Nel mio caso devo aggiungere l'indirizzo ip (-Djava.rmi.server.hostname = <ip>). hostname -i mi ha dato due indirizzi IP e quello corretto era il secondo nell'elenco.
Georgy Bolyuba,

4
non ha risolto il problema per me. il collegamento di windows-2-windows non è un problema per me MA quando provo a connettermi da una JVM Jvisualvm.exe su Windows per monitorare un servizio java in esecuzione su SUSE con Oracle JDK 1.6.024, la connessione non riesce. Per questo motivo penso che questa domanda delle persone sia ancora senza risposta.
Djangofan

Questo ha risolto il problema per me. Questo più il solito set di 3 (autenticazione / porta / ssl) e ora posso connettermi da remoto. La scatola è in ascolto su più interfacce virtuali, tuttavia, potrebbe essere stato il motivo per cui non specificare l'host ha confuso la jvm.
Nicholi

Finalmente ho risolto i miei problemi di connessione jconsole sul mio laptop osx. Grazie.
rado

Ha funzionato per me. Grazie!
Jeff

58

Ho provato con Java 8 e versioni successive

Questa soluzione funziona bene anche con i firewall

1. Aggiungilo allo script di avvio di java sull'host remoto:

-Dcom.sun.management.jmxremote.port=1616
-Dcom.sun.management.jmxremote.rmi.port=1616
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=localhost

2. Eseguilo sul tuo computer.

  • Utenti Windows :

    putty.exe -ssh user@remote-host -L 1616:remote-host:1616

  • Utenti Linux e Mac :

    ssh user@remote-host -L 1616:remote-host:1616

3. Avvia jconsolesul tuo computer

jconsole localhost:1616

4. Buon divertimento!

PS: durante il passaggio 2, utilizzando sshe -Lsi specifica che la porta 1616 sull'host locale (client) deve essere inoltrata al lato remoto. Questo è un tunnel ssh e aiuta a evitare firewall o vari problemi di rete.


1
ECCEZIONALE!! Sto provando per 6 + ore ora a jmx-remote su un'istanza ActiveMQ su java8. FINALMENTE QUALCOSA CHE HA FUNZIONATO !! Grazie! :)
Rop

Grazie, come te anch'io ho faticato per circa un giorno, e dopo tanto lavoro ho pensato: "Devo scrivere questa cosa a SO !!"
Freedev

2
Fa davvero schifo che Oracle non menzioni "com.sun.management.jmxremote.rmi.port", "java.rmi.server.hostname" docs.oracle.com/javase/8/docs/technotes/guides/management/… I immagino che fosse il mio problema.
Rop

Perché, per quanto ne so, questo problema non riguarda JMX, ma come funziona RMI. Ad esempio, dopo questo caso, ho avuto lo stesso problema con jmeter, che utilizza rmi nella sua implementazione client / server.
Freedev

2
Funziona. Aggiungendo solo la mia esperienza con i tunnel: 1) posso usare "localhost" in "-L 1616: localhost: 1616" 2) non posso cambiare la porta di origine, cioè questo non funzionerà: "-L 9999: localhost: 1616"
gargii

19

Probabilmente stai riscontrando un problema con un firewall. Il "problema" è che la porta specificata non è l'unica porta utilizzata, utilizza 1 o forse anche 2 porte in più per RMI e quelle sono probabilmente bloccate da un firewall.

Una delle porte extra non sarà nota in anticipo se si utilizza la configurazione RMI predefinita, quindi è necessario aprire una vasta gamma di porte, il che potrebbe non divertire l'amministratore del server.

Esiste una soluzione che non richiede l'apertura di molte porte, tuttavia, l'ho fatta funzionare utilizzando i frammenti di codice sorgente combinati e i suggerimenti di

http://forums.sun.com/thread.jspa?threadID=5267091 - il collegamento non funziona più

http://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx

http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html

È anche possibile configurare un tunnel ssh e farlo funzionare ancora :-)


2
Sono stato in grado di aggirare il firewall utilizzando solo l'alias descritto in simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html insieme all'impostazione -Djava.rmi.server.hostname come menzionato in un'altra risposta qui.
Damien

Nota per i futuri lettori: il collegamento a forums.sun.comè interrotto
CDspace

1
Nota per i futuri lettori: il collegamento a blogs.oracle.comè interrotto.
Grimlock

17

Dopo aver messo alla prova il mio Google-fu negli ultimi due giorni, sono finalmente riuscito a farlo funzionare dopo aver compilato le risposte da Stack Overflow e questa pagina http://help.boomi.com/atomsphere/GUID-F787998C- 53C8-4662-AA06-8B1D32F9D55B.html .

Ripubblicare dalla pagina Dell Boomi:

To Enable Remote JMX on an Atom

If you want to monitor the status of an Atom, you need to turn on Remote JMX (Java Management Extensions) for the Atom.

Use a text editor to open the <atom_installation_directory>\bin\atom.vmoptions file.

Add the following lines to the file:

-Dcom.sun.management.jmxremote.port=5002
-Dcom.sun.management.jmxremote.rmi.port=5002
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

L'unica riga per cui non ho visto nessuna copertina di risposta di Stack Overflow è

-Dcom.sun.management.jmxremote.rmi.port=5002

Nel mio caso, stavo tentando di recuperare le metriche di Kakfa, quindi ho semplicemente cambiato l'opzione sopra per abbinare il -Dcom.sun.management.jmxremote.portvalore. Quindi, senza autenticazione di alcun tipo, la configurazione minima dovrebbe assomigliare a questa:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=(jmx remote port)

-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.rmi.port=(jmx remote port)
-Djava.rmi.server.hostname=(CNAME|IP Address)

1
Più uno per "Google-fu"
kevinarpe

"com.sun.management.jmxremote.rmi.port" è stata anche la chiave per me. Vedi anche questa risposta: stackoverflow.com/a/22306586/123205
David

Non avevo bisogno di "com.sun.management.jmxremote.local.only", quindi non credo che la tua configurazione sia veramente "minima"
David


7

I passaggi 4-7 di Sushicutta possono essere saltati aggiungendo la seguente riga al passaggio 3:

-Dcom.sun.management.jmxremote.rmi.port=<same port as jmx-remote-port>

ad es. Aggiungi per avviare i parametri:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.rmi.port=12345
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=localhost

Per il port forwarding, connettiti utilizzando:

ssh -L 12345:localhost:12345 <username>@<host>

se il tuo host è un trampolino di lancio, incatena semplicemente la porta in avanti eseguendo quanto segue sul gradino dopo quanto sopra:

ssh -L 12345:localhost:12345 <username>@<host2>

Tieni presente che hostname = localhost è necessario per assicurarti che jmxremote dica alla connessione rmi di utilizzare il tunnel. Altrimenti potrebbe provare a connettersi direttamente e colpire il firewall.


Questo metodo mi aiuta: (1) aggiungo i parametri JMX persi e riavvio l'app (2) Quindi ssh -L <JMX_port>:localhost:<JMX_port> <remote_user>@<remote_host>jconsole <remote_host>:<JMX_port>
eseguo

6

PROTIP:

La porta RMI viene aperta da portnr arbitrari. Se si dispone di un firewall e non si desidera aprire le porte 1024-65535 (o utilizzare vpn), è necessario eseguire le seguenti operazioni.

È necessario correggere (come se si avesse un numero noto) il registro RMI e le porte del server JMX / RMI. Puoi farlo inserendo un file jar (catalina-jmx-remote.jar è negli extra) nella lib-dir e configurando un listener speciale sotto il server:

<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
      rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002" />

(E ovviamente i soliti flag per l'attivazione di JMX

    -Dcom.sun.management.jmxremote  \
    -Dcom.sun.management.jmxremote.ssl=false \
    -Dcom.sun.management.jmxremote.authenticate=false \
    -Djava.rmi.server.hostname=<HOSTNAME> \

Vedere: JMX Remote Lifecycle Listener su http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Quindi puoi connetterti usando questo orribile URL:

service:jmx:rmi://<hostname>:10002/jndi/rmi://<hostname>:10001/jmxrmi

Ho provato quanto sopra con il jar extra e puoi vedere le porte RMI in ascolto come specificato, ma le porte casuali sono ancora utilizzate da RMI dopo la connessione alla porta JVM con VisualVM. Soluzione alternativa: controlla le porte con "lsof -i" e apri quelle con connessioni bloccate.
Joseph Lust

5

Controlla se il tuo server è dietro il firewall. JMX è basato su RMI, che apre due porte all'avvio. Uno è la porta del registro, il valore predefinito è 1099 e può essere specificato com.sun.management.jmxremote.portdall'opzione. L'altro è per la comunicazione dei dati ed è casuale, che è la causa del problema. Una buona notizia è che, da JDK6, questa porta casuale può essere specificata com.sun.management.jmxremote.rmi.portdall'opzione.

export CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8991 -Dcom.sun.management.jmxremote.rmi.port=8991 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

4

Ottenere JMX attraverso il firewall è davvero difficile. Il problema è che RMI standard utilizza una seconda porta assegnata casualmente (accanto al registro RMI).

Abbiamo tre soluzioni che funzionano, ma ogni caso necessita di una diversa:

  1. JMX su tunnel SSH con proxy Socks, utilizza RMI standard con SSH magic http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html

  2. JMX MP (alternativa allo standard RMI), utilizza solo una porta fissa, ma necessita di un jar speciale su server e client http://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/

  3. Avvia il codice del modulo JMX Server, lì è possibile utilizzare RMI standard e utilizzare una seconda porta fissa: https://issues.apache.org/bugzilla/show_bug.cgi?id=39055


Tutte le altre risposte dovrebbero essere un'aggiunta a questa
ruruskyi

2

Durante il test / debug / diagnosi di problemi JMX remoti , prima provare sempre a connettersi sullo stesso host che contiene MBeanServer (cioè localhost), per escludere problemi di rete e altri non specifici JMX.


2

Ci sono già alcune ottime risposte qui, ma c'è un approccio leggermente più semplice che penso valga la pena condividere.

L'approccio di sushicutta è buono, ma è molto manuale in quanto devi ottenere la porta RMI ogni volta. Per fortuna, possiamo aggirare questo problema utilizzando un proxy SOCKS piuttosto che aprire esplicitamente i tunnel delle porte. Lo svantaggio di questo approccio è che l'app JMX che esegui sulla tua macchina deve essere configurata per utilizzare un proxy. La maggior parte dei processi può essere eseguita aggiungendo proprietà java, ma alcune app non lo supportano.

passi:

  1. Aggiungi le opzioni JMX allo script di avvio per il tuo servizio Java remoto:

    -Dcom.sun.management.jmxremote=true
    -Dcom.sun.management.jmxremote.port=8090
    -Dcom.sun.management.jmxremote.ssl=false
    -Dcom.sun.management.jmxremote.authenticate=false
    
  2. Configura una connessione proxy SOCKS alla tua macchina remota:

    ssh -D 9696 user@remotemachine.com
    
  3. Configura la tua app di monitoraggio Java locale per utilizzare il proxy SOCKS (localhost: 9696). Nota: a volte puoi farlo dalla riga di comando, ad esempio:

    jconsole -J-DsocksProxyHost=localhost -J-DsocksProxyPort=9696
    

2

Quanto segue ha funzionato per me (anche se penso che la porta 2101 non abbia davvero contribuito a questo):

-Dcom.sun.management.jmxremote.port=2100
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.rmi.port=2101
-Djava.rmi.server.hostname=<IP_ADDRESS>OR<HOSTNAME>

Mi sto collegando da una macchina remota a un server su cui è in esecuzione Docker e il processo è all'interno del contenitore. Inoltre, ho fermato firewallD ma non credo che fosse questo il problema dato che potevo telnet al 2100 anche con il firewall aperto. Spero che sia d'aiuto.


1

Sto eseguendo JConsole / JVisualVm su Windows che si aggancia a Tomcat con Linux Redhat ES3.

Disabilitare il filtraggio dei pacchetti utilizzando il seguente comando ha fatto il trucco per me:

/usr/sbin/iptables -I INPUT -s jconsole-host -p tcp --destination-port jmxremote-port -j ACCEPT

dove jconsole-host è il nome host o l'indirizzo host su cui viene eseguito JConsole e jmxremote-port è il numero di porta impostato per com.sun.management.jmxremote.port per la gestione remota.


2
non ha funzionato per me su un'istanza SUSE Amazon EC2. Penso che il problema sia altrove.
Djangofan

1

Sto usando boot2docker per eseguire container Docker con Tomcat all'interno e ho lo stesso problema, la soluzione era:

  • Inserisci -Djava.rmi.server.hostname=192.168.59.103
  • Utilizzare la stessa porta JMX in un contenitore ospite e finestra mobile, per esempio: docker run ... -p 9999:9999 .... L'uso di porte diverse non funziona.

0

È inoltre necessario assicurarsi che il nome della macchina si risolva nell'IP a cui JMX si sta associando; NON localhost né 127.0.0.1. Per me, è stato utile inserire una voce negli host che lo definisca esplicitamente.


0

Ottenere JMX attraverso il firewall non è affatto difficile. C'è un piccolo problema. Devi inoltrare sia la tua porta configurata JMX che. 9010 e una delle porte dinamiche che ascolta sulla mia macchina era> 30000


0

Questi sono i passaggi che hanno funzionato per me (debian dietro il firewall sul lato server, raggiunto tramite VPN dal mio Mac locale):

controlla l'ip del server

hostname -i

usa i parametri JVM:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=[jmx port]
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=[server ip from step 1]

eseguire l'applicazione

trova il pid del processo java in esecuzione

controlla tutte le porte utilizzate da JMX / RMI

netstat -lp | grep [pid from step 4]

aprire tutte le porte dal passaggio 5 sul firewall

Ecco.


0

Per dare un contributo, questo è quello che ho fatto su CentOS 6.4 per Tomcat 6.

  1. Arresta il servizio iptables

    service iptables stop
    
  2. Aggiungi la seguente riga a tomcat6.conf

    CATALINA_OPTS="${CATALINA_OPTS} -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8085 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=[host_ip]"
    

In questo modo sono stato in grado di connettermi da un altro PC utilizzando JConsole.


0

Sto provando a JMC per eseguire il Flight Recorder (JFR) per profilare NiFi su un server remoto che non offre un ambiente grafico su cui eseguire JMC.

Sulla base delle altre risposte fornite qui e dopo molti tentativi ed errori, ecco cosa sto fornendo alla JVM ( conf / bootstrap.conf ) quando avvio NiFi:

java.arg.90=-Dcom.sun.management.jmxremote=true
java.arg.91=-Dcom.sun.management.jmxremote.port=9098
java.arg.92=-Dcom.sun.management.jmxremote.rmi.port=9098
java.arg.93=-Dcom.sun.management.jmxremote.authenticate=false
java.arg.94=-Dcom.sun.management.jmxremote.ssl=false
java.arg.95=-Dcom.sun.management.jmxremote.local.only=false
java.arg.96=-Djava.rmi.server.hostname=10.10.10.92  (the IP address of my server running NiFi)

L'ho inserito in / etc / hosts , anche se dubito che sia necessario:

10.10.10.92   localhost

Quindi, all'avvio di JMC, creo una connessione remota con queste proprietà:

Host: 10.10.10.92
Port: 9098
User: (nothing)
Password: (ibid)

Per inciso, se faccio clic sull'URL del servizio JMX personalizzato, vedo:

service:jmx:rmi:///jndi/rmi://10.10.10.92:9098/jmxrmi

Questo alla fine lo ha fatto per me.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.