Hi.
On 14.03.2018 18:21, Cheltenham, Chris wrote:
Ok , I thank you guys for being so helpful.
I would never expect that.
Speaking as a user myself, I would not be so surprised. This list is quite exceptional in
terms of the general quality of the people trying to answer user questions, and in terms
of the general quality of the answers themselves. The contributors here, in general, will
try to respond as well as they can, and to really help resolving user issues to the best
of their abilities, even when they do not stricly concern tomcat per se (like your issue).
(Full disclosure : I am occasionally one of these guys, although my own qualifications
pale somewhat in comparison to most of the others.)
As for the help supplicant, there are only a few rules, and they are listed
here :
http://tomcat.apache.org/lists.html#tomcat-users
Basically I am have tomcat running on port 8443 as user tomcat.
I am trying to find ways to redirect them to 443 WITHOUT using iptables or
the firewall or the load balancer.
I have no control over any of those tools and I cannot use a reverse proxy
wither because I do not have control of apache.
I think that leaves me basically with authbind or set cap , locally.
However, I cannot get either to work.
Set cap seemed easiest.
You start the tomcat server and then I ran this
setcap cap_net_bind_service=+ep /opt/jdk1.8.0_161/jre/bin/java
So now what?
How does it know to bind java process to 443?
$netstat -an says 443 is not open and it does not work using curl.
That is where I am right now.
What we cannot do here is resolving organisational issues within your work
environment.
Without entering into the reasons why you cannot ask whoever is responsible for whatever
is in front of tomcat to really help you and direct these client calls to port 8443 of
your server (although that would in principle the kind of thing for which they are paid),
I am wondering why you do not try the iptables method outlined at :
https://wiki.apache.org/httpd/NonRootPortBinding
-> Alternative method (iptables/linux): NAT
If you can run the setcap command, it means that you have root access to your server, so
you can run the iptables command also. And it seems simpler (and with less side-effects)
than any of the other methods, in this case.
(On the other hand, if you do not have root access, then pretty much any command or
utility that would allow you to redirect port 443 to something else, will not be
accessible to you either; because if you could do that, then what would be the point of
protecting these lower ports ?).
I just tried this (as root) on a Linux Debian server, which is running tomcat on its
default HTTP port 8080 :
# iptables -t nat -A PREROUTING -d 127.0.0.1 -p tcp --dport 500 -m addrtype --dst-type
LOCAL -j DNAT --to-destination 127.0.0.1:8080
# iptables -t nat -A OUTPUT -d 127.0.0.1 -p tcp --dport 500 -m addrtype --dst-type LOCAL
-j DNAT --to-destination 127.0.0.1:8080
and then, *from the same host*, I can access "http://locahost:500/"; and get the tomcat
default welcome page, without changing the Tomcat configuration.
(In the above, I just used the origin port 500, because it is below 1024, and happened to
be unused on my server.)
To make this work in your case and from outside the host itself,
- replace all "127.0.0.1" above, by the external IP address of your server (which you can
see via "ipconfig -a")
- replace all "500" by "443"
- replace all "8080" by "8443"
As per above, these rules are temporary and will not survive a system reboot.
However, if you do a "man iptables", you should find somewhere the way to make these rules
persistent. (Or search Google for "make iptables permanent").
tips :
- to see if these rules have "stuck", use the command "iptables -L -t dnat -n"
- to delete the above rules, use exactly the same command as for setting them, but change
the "-A" into "-D"
- rules implemented via iptables will not be visible when you do "netstat -pan --tcp |
grep LISTEN", because there is not really any process listening on the port which you
redirect in that way. iptables works at a lower level, modifying the ip packets themselves
as they enter and exit your system. tomcat still listens on its original port, and still
thinks it is reading from and writing to that same port (kind of).
You may also have to be careful that your application is never sending back to the
clients, a link which would contain the port :8443, or that would seriously confuse
everything.
And again, if you do not have root access to your tomcat host, AND you cannot get help
from the people managing whatever is in front of your server, then you are in an
impossible situation, and you should probably report this to your managers and ask them
for help.
In French we say : "à l'impossible, nul n'est tenu"
===========================
Thank You;
Chris Cheltenham
Technology Services
The School District of Philadelphia
Work # 215-400-5025
Cell # 215-301-6571
-----Original Message-----
From: Olaf Kock [mailto:tom...@olafkock.de]
Sent: Wednesday, March 14, 2018 11:59 AM
To: users@tomcat.apache.org
Subject: Re: Binding a non root user to port 443
On 14.03.2018 16:02, Cheltenham, Chris wrote:
Chris,
I am kind of lost. I am not sure what you guys are asking.
If I asked the same thing twice its because whatever was sent by
someone else other than you did not work or I cannot use.
well, I'm also lost. It would help to know what didn't work for you and, if
possible, why. It doesn't help anyone if we're giving the same answers
again, not knowing any of the aspects that need to be changed, or anything
about what you can't use.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
