Tomcat, Glassfish on port 80 under Unix operating systems should the ports below 1024 are not used by normal users, but only by the root user. For security reasons, you want as few processes as possible as root run as a security hole that automatically means full access to the system. Apache web server, such help by the fact that a process with root privileges on the port 80 is listening, but the requests are processed by ordinary user processes. The functionality of the user change of a Java process is not possible. One can not trick via JNI, as used Java threads, and always include a common user. For example, 8080 - - run it and set up a suitable redirection
A possible solution to the Web server on a high port. This can be done via mod_jk or mod_proxy in Apache, or a redirection iptables:
iptables-t nat-A PREROUTING-i eth0-p tcp \\
- dport 80-j REDIRECT - to-ports 8080 Both approaches have the disadvantage that the Tomcat or GlassFish thinks he is Port addressed 8080th This can cause problems when complete URLs are displayed, because then they have 8080 in it. mod_jk and Tomcat know as the appropriate remedial options ("proxy-port") that are used to a different port indicated.
There is also a better way with any Java program can listen on privileged ports and still running as normal user: authbind and privbind. The decor is very simple, as an example, the Freigbe port 80 for the user GlassFish: authbind is SUID root and therefore can be run directly by the user. In an attempt to listen on a low port, it checks whether the user has write access to a particular file. In our example, the file would be
/ etc/autbind/byport/80 To create this need, the following commands are entered as root:
touch / etc/authbind/byport/80 chmod 500 / etc/authbind/byport/80 chown GlassFish / etc/authbind/byport/80 privbind For such a configuration is not necessary. Since it is not SUID root, it must It can be started by root directly. Moreover, it is not possible to restrict access to a port - there are always all possible. Unfortunately, both programs
have a major limitation: they do not work with IPv6, but only with IPv4. Java by default tries to use IPv6, also, what a mistake with the result. The Java process has therefore the option
-Djava.net.preferIPv4Stack = true
be given. When Tomcat writes this into the variable in the file CATALINA_OPTS setenv.sh setenv.bat /, you may still have to create. When this option is Glassfish in the corresponding domain.xml in the section with the JVM options:
\u0026lt;jvm-options>-Djava.net.preferIPv4Stack = true \u0026lt;/ jvm-options> example, started the Glassfish when using authbind GlassFish as a user authbind with
- deep asadmin start-domain domain1 The - deep is necessary because the Java command is a script the actual command calls the first and lost the rights to this port, otherwise,. Will you use privbind, the command is as follows:
privbind sudo-u glassfish $ (asadmin which) start-domain domain1 you Run the command as root, you can leave the sudo away.
this issue in both cases is this:
Starting Domain domain1, please wait. Log redirected to /opt/glassfish-v2ur2/domains/domain1/logs/server.log. Redirecting output to /opt/glassfish-v2ur2/domains/domain1/logs/server.log Domain domain1 is ready to receive client requests. Additional services are being started in background. Domain [domain1] is running [Sun Java System Application Server 9.1_02 (build b04-fcs)] with its configuration and logs at: [/opt/glassfish-v2ur2/domains]. Admin Console is available at [http://localhost:4848]. Use the same port [4848] for "asadmin" commands. User web applications are available at these URLs: [http://localhost:80 https://localhost:443 ]. Following web-contexts are available: [/web1 /__wstx-services ]. Standard JMX Clients (like JConsole) can connect to JMXServiceURL: [service:jmx:rmi:///jndi/rmi://pckurt:8686/jmxrmi] for domain management purposes. Domain listens on at least following ports for connections: [80 443 4848 3700 3820 3920 8686 ]. Domain does not support application server clusters and other stand-alone instances. was on this server and the SSL port changed from 8181 to 443, this is necessary when using authbind the file here.