Domanda Tomcat7 inizia troppo tardi su Ubuntu 14.04 x64 [Digitalocean]


sto usando digitalocean e sto provando ad installare e avviare tomcat su ubuntu ma sfortunatamente non posso farlo. (creato nuove gocce e provato 10 volte)

Disco RAM 30 GB SSD da 1 GB Amsterdam 2 Ubuntu 14.04 x64

Quando avvio Tomcat, viene visualizzato "Tomcat started". Ma non posso accedere alla pagina dal browser. e ./shutdown.sh restituisce errore.

Quale può essere il problema ?

Ho notato qualcosa ora. Mentre sto scrivendo questa domanda, viene visualizzata la pagina di Tomcat. ci sono voluti 28 minuti per visualizzare la pagina 

catalina.out dice: INFO: la creazione dell'istanza SecureRandom per la generazione dell'ID sessione utilizzando [SHA1PRNG] ha richiesto [1,718,769] millisecondi.

Ecco i miei passaggi di installazione (Questi passaggi funzionano su diversi vps ma non funzionano su droplet digitalocean):

Installa Oracle jdk

 sudo apt-get install python-software-properties
 sudo add-apt-repository ppa:webupd8team/java
 sudo apt-get update
 sudo apt-get install oracle-java7-installer
 sudo apt-get install oracle-java7-set-default
      java -version
      java version "1.7.0_72"
      Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
      Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

Imposta il percorso java

      sudo nano /etc/environment
      JAVA_HOME="/usr/lib/jvm/java-7-oracle"
      source /etc/environment
      wget http://ftp.itu.edu.tr/Mirror/Apache/tomcat/tomcat-7/v7.0.56/bin/apache-tomcat-7.0.56.tar.gz
      tar xvzf apache-tomcat-7.0.56.tar.gz
      mv apache-tomcat-7.0.56/ apache-tomcat-7.0.56-server-1/

Avvia Tomcat

        ./startup.sh
            Using CATALINA_BASE:   /usr/local/apache-tomcat-7.0.56-server-1
            Using CATALINA_HOME:   /usr/local/apache-tomcat-7.0.56-server-1
            Using CATALINA_TMPDIR: /usr/local/apache-tomcat-7.0.56-server-1/temp
            Using JRE_HOME:        /usr/lib/jvm/java-7-oracle/jre
            Using CLASSPATH:       /usr/local/apache-tomcat-7.0.56-server-1/bin/bootstrap.jar:/usr/local/apache-tomcat-7.0.56-server-1/bin/tomcat-juli.jar
            Tomcat started.

Checkout Port 8080

        netstat -ln 
            tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
            tcp6       0      0 :::8009                 :::*                    LISTEN
            tcp6       0      0 :::8080                 :::*                    LISTEN
            tcp6       0      0 :::22                   :::*                    LISTEN

Processo di checkout

            ps -ef | grep tomcat
            root      2825     1  1 14:23 pts/0    00:00:03 /usr/lib/jvm/java-7-oracle/jre/bin/java -Djava.util.logging.config.file=/usr/local/apache-tomcat-7.0.56-server-1/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/apache-tomcat-7.0.56-server-1/endorsed -classpath /usr/local/apache-tomcat-7.0.56-server-1/bin/bootstrap.jar:/usr/local/apache-tomcat-7.0.56-server-1/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/apache-tomcat-7.0.56-server-1 -Dcatalina.home=/usr/local/apache-tomcat-7.0.56-server-1 -Djava.io.tmpdir=/usr/local/apache-tomcat-7.0.56-server-1/temp org.apache.catalina.startup.Bootstrap start

Aprire il sito Web alla porta 8080 http://5.101.107.56:8080/  La pagina è in attesa ... [il contenuto viene visualizzato dopo 28 minuti o più]

Prova a chiudere tomcat se il contenuto non è ancora stato visualizzato (prima che tomcat sia avviato correttamente).

      ./shutdown.sh 
            SEVERE: Could not contact localhost:8005. Tomcat may not be running.
            Oct 17, 2014 2:40:29 PM org.apache.catalina.startup.Catalina stopServer
            SEVERE: Catalina.stop:
                java.net.ConnectException: Connection refused
                at java.net.PlainSocketImpl.socketConnect(Native Method)
                at java.net.AbstractPlainSoc

Log di verifica

      catalina.out
            Oct 17, 2014 2:31:47 PM org.apache.coyote.AbstractProtocol init
            INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
            Oct 17, 2014 2:31:47 PM org.apache.catalina.startup.Catalina load
            INFO: Initialization processed in 1492 ms
            Oct 17, 2014 2:31:47 PM org.apache.catalina.core.StandardService startInternal
            INFO: Starting service Catalina
            Oct 17, 2014 2:31:47 PM org.apache.catalina.core.StandardEngine startInternal
            INFO: Starting Servlet Engine: Apache Tomcat/7.0.56
            Oct 17, 2014 2:31:47 PM org.apache.catalina.startup.HostConfig deployDirectory
            INFO: Deploying web application directory /usr/local/apache-tomcat-7.0.56-server-1/webapps/host-manager

Ho anche installato nginx e naviga verso http://5.XXX.XXX.XX/ la pagina di benvenuto di nginx viene aperta immediatamente

Ho controllato catalina.out quando vedo la pagina nel browser, dice:

    Oct 17, 2014 2:31:47 PM org.apache.catalina.startup.HostConfig deployDirectory
    INFO: Deploying web application directory /usr/local/apache-tomcat-7.0.56-server-1/webapps/host-manager
    Oct 17, 2014 3:00:27 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom
    INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took **[1,718,769] milliseconds.**

Memoria:

               total       used       free     shared    buffers     cached
  Mem:       1017912     849512     168400        332      18780     688468

44
2017-10-17 19:17


origine


risposte:


Sostituzione securerandom.source=file:/dev/urandom con securerandom.source=file:/dev/./urandom in $JAVA_PATH/jre/lib/security/java.security ha risolto il mio problema.

Anche quando file:/dev/urandom è specificato, JRE continuerà a essere utilizzato /dev/random per SHA1PRNG (vedi bug JDK-4705093):

In SHA1PRNG c'è un SeedGenerator che fa varie cose   a seconda della configurazione.

  1. Se java.security.egd o securerandom.source puntano a "file: / dev / random" o "file: / dev / urandom", useremo   NativeSeedGenerator, che chiama super () che chiama   SeedGenerator.URLSeedGenerator (/ dev / random). (Una classe annidata all'interno   SeedGenerator.) Le uniche cose che sono cambiate in questo bug erano quelle   urandom attiverà anche l'uso di questo percorso del codice.

  2. Se tali proprietà puntano a un altro URL esistente, inizializzeremo SeedGenerator.URLSeedGenerator (url). Ecco perché   "file: /// dev / urandom", "file: /./ dev / random", ecc. funzionerà.

A partire dal Wikipedia su / dev / random:

In questa implementazione, il generatore mantiene una stima del numero   di bit di rumore nel pool di entropia. Da questa pozza di entropia casuale   i numeri sono creati. Quando letto, il dispositivo / dev / random solo   restituisce byte casuali all'interno del numero stimato di bit di rumore in   la piscina di entropia. / Dev / random dovrebbe essere adatto per usi che necessitano    casualità di altissima qualità come una volta pad o generazione di chiavi.

Quando il pool di entropia è vuoto, legge da / dev / random bloccherà   fino a quando non si raccolgono ulteriori rumori ambientali. L'intento è quello di   funge da generatore di numeri pseudocasuali crittograficamente sicuro,   fornire output con entropia il più ampio possibile. Questo è suggerito   per l'uso nella generazione di chiavi crittografiche per alto valore o lungo termine   protezione.

Rumore ambientale?

Il generatore di numeri casuali si raggruppa rumore ambientale  dal dispositivo   autisti e altre fonti in una pozza di entropia. Anche il generatore   mantiene una stima del numero di bit di rumore nel pool di entropia.   Da questo pool di entropia vengono creati numeri casuali.

Ciò significa che in pratica è possibile bloccare Tomcat per un periodo di tempo sconosciuto.


72
2017-10-17 19:56



Questo funziona anche:

In realtà, impostando quanto segue in / etc / default / tomcat7, stavo bene:

JAVA_OPTS = "- Djava.security.egd = file: / dev /./ urandom -Djava.awt.headless = true -Xmx1024m -XX: MaxPermSize = 512m -XX: + UseConcMarkSweepGC"

Commento da:

https://www.digitalocean.com/community/tutorials/how-to-install-apache-tomcat-7-on-ubuntu-14-04-via-apt-get


17
2017-12-02 13:31



Durante l'utilizzo /dev/urandom poiché la fonte di entropy è una soluzione alternativa che riduce il tempo di avvio di Tomcat, non è una buona idea perché può avere effetti collaterali indesiderati.

Altri componenti in esecuzione nel server Tomcat (ad esempio applicazioni Web) potrebbero dipendere da un'inizializzazione protetta SecureRandom istanza e potrebbero esserci problemi di sicurezza quando l'entropia per i numeri casuali non è sufficiente.

In realtà, questo è uno dei motivi per cui l'uso /dev/urandom non funziona, ma /dev/./urandom lo fa. SHA1PRNG fa molto affidamento su un buon seme. Se il seme non è buono, i numeri casuali sono prevedibili. Pertanto, lo sviluppatore ha assicurato che per questo scopo /dev/random è usato come fonte di entropia, anche se la JVM è configurata per l'uso /dev/urandom. Ci sono due segnalazioni di bug su questo (bug 1, bug 2).

Quindi, invece di cambiare la fonte di entropia in /dev/urandom, uno dovrebbe piuttosto assicurarsi che /dev/random ha abbastanza entropia Se il sistema ha un RNG hardware, l'installazione rng-tools dovrebbe fare il trucco Altrimenti, l'installazione haveged fornisce un'ottima fonte di entropia che non si basa su un RNG hardware speciale per essere presente. In una macchina virtuale, rng-tools può utilizzare entropia dall'host tramite un RNG hardware virtuale. In alternativa a questo, EGD potrebbe essere usato, ma al momento questo software non è incluso nei repository di Ubuntu, quindi è fastidioso usarlo.


12
2018-03-25 18:39