trusty releases descargar java tomcat ubuntu digital-ocean

java - releases - ubuntu intel 64



Tomcat7 comienza demasiado tarde en Ubuntu 14.04 x64 (3)

Estoy usando digitalocean y estoy tratando de instalar e iniciar tomcat en Ubuntu, pero desafortunadamente no puedo hacerlo. (creó nuevas gotas e intentó 10 veces)

Disco SSD Ram 30 GB de 1 GB Amsterdam 2 Ubuntu 14.04 x64

Cuando comienzo tomcat, dice "Tomcat comenzó". Pero no puedo acceder a la página desde el navegador. y ./shutdown.sh devuelve error.

Cual puede ser el problema ?

Me di cuenta de algo ahora. Mientras escribo esta pregunta, se muestra la página de Tomcat. demoró 28 minutos en mostrar la página

catalina.out dice: INFO: la creación de la instancia de SecureRandom para la generación de ID de sesión usando [SHA1PRNG] tomó [1,718,769] milisegundos.

Aquí están mis pasos de instalación (Estos pasos funcionan en diferentes vps pero no funcionan en las gotas digitalocean):

Instalar 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)

Establecer la ruta de 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/

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

Puerto de salida 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

Proceso de pago

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

Abra el sitio web en el puerto 8080 http://5.101.107.56:8080/ página está esperando ... [el contenido se muestra luego de 28 minutos o más]

Intente cerrar tomcat si el contenido aún no se muestra (antes de que tomcat se inicie correctamente).

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

Registros de caja

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

También instalé nginx y http://5.XXX.XXX.XX/ a http://5.XXX.XXX.XX/ página de bienvenida de nginx se abre de inmediato

Comprobé catalina.out cuando veo la página en el navegador, 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

Reemplazando securerandom.source=file:/dev/urandom con securerandom.source=file:/dev/./urandom en $JAVA_PATH/jre/lib/security/java.security ha resuelto mi problema.

Incluso cuando se especifica el file:/dev/urandom , JRE todavía usará /dev/random para SHA1PRNG (consulte el error JDK-4705093 ):

En SHA1PRNG, hay un SeedGenerator que hace varias cosas dependiendo de la configuración.

  1. Si java.security.egd o securerandom.source apuntan a "file: / dev / random" o "file: / dev / urandom", usaremos NativeSeedGenerator, que llama a super () que llama a SeedGenerator.URLSeedGenerator (/ dev / random ) (Una clase anidada dentro de SeedGenerator.) Lo único que cambió en este error fue que urandom también activará el uso de esta ruta de código.

  2. Si esas propiedades apuntan a otra URL que existe, iniciaremos SeedGenerator.URLSeedGenerator (url). Es por eso que "file: /// dev / urandom", "file: /./ dev / random", etc. funcionarán.

De Wikipedia en / dev / random :

En esta implementación, el generador mantiene una estimación del número de bits de ruido en el conjunto de entropía. A partir de este grupo de entropía, se crean números aleatorios. Cuando se lee, el dispositivo / dev / random solo devolverá bytes aleatorios dentro del número estimado de bits de ruido en el grupo de entropía. / dev / random debe ser adecuado para usos que requieren una aleatoriedad de muy alta calidad , como la generación de un pad o llave de una sola vez.

Cuando el grupo de entropía está vacío, las lecturas de / dev / random se bloquearán hasta que se recopile ruido ambiental adicional. La intención es servir como un generador de números pseudoaleatorios criptográficamente seguro, entregando resultados con entropía lo más grande posible. Se sugiere su uso para generar claves criptográficas para la protección de alto valor o de largo plazo.

Ruido ambiental?

El generador de números aleatorios reúne el ruido ambiental de los controladores de dispositivos y otras fuentes en un conjunto de entropía. El generador también mantiene una estimación de la cantidad de bits de ruido en el grupo de entropía. A partir de este grupo de entropía, se crean números aleatorios.

Eso significa que en la práctica, es posible bloquear tomcat durante un tiempo desconocido.

Si bien utilizar /dev/urandom como fuente de entropía es una solución que reduce el tiempo de inicio de Tomcat, no es una buena idea porque puede tener efectos secundarios no deseados.

Otros componentes que se ejecutan en el servidor Tomcat (por ejemplo, aplicaciones web) pueden depender de una instancia SecureRandom iniciada de forma segura y puede haber problemas de seguridad cuando la entropía para los números aleatorios no es suficiente.

En realidad, esta es una de las razones por las que usar /dev/urandom no funciona, pero /dev/./urandom sí /dev/./urandom hace. El SHA1PRNG depende en gran medida de una buena semilla. Si la semilla no es buena, los números aleatorios son predecibles. Por lo tanto, el desarrollador se aseguró de que /dev/random se use como fuente de entropía, incluso si la JVM está configurada para usar /dev/urandom . Hay dos informes de errores sobre esto ( error 1 , JDK-4705093 ).

Entonces, en lugar de cambiar la fuente de entropía a /dev/urandom , uno debería asegurarse de que /dev/random tenga suficiente entropía. Si el sistema tiene un RNG de hardware, instalar rng-tools debería ser el truco. De lo contrario, instalar haveged proporciona una muy buena fuente de entropía que no depende de un RNG de hardware especial para estar presente. En una máquina virtual, rng-tools puede usar entropía desde el host a través de un RNG de hardware virtual. Como alternativa a esto, EGD podría ser utilizado, pero por el momento este software no está incluido en los repositorios de Ubuntu, por lo que es molesto usarlo.