Can we have an OSS instance of elasticsearch with SSL/https?
I tried this solution, but likely we will need an x-pack that is not available in OSS.
The idea is to have just SSL working in HTTPS, no Authentication required (for testing HTTPS client purposes only)
The security features in elasticseach are not included in the OSS version, only in the versions that uses at least the Basic free Elastic License.
To use HTTPS in the OSS version you will need to have a proxy in front of your nodes, like HAProxy and NGINX.
Related
Thanks for taking the time to read this :)
My web app (grimoirelab) contains multiple services spun up using docker-compose which contains elasticsearch and kibana . Port 5601 (kibana) is open and accessible through the web.
I want to enable SSL / TLS in the Kibana container , i.e , change the URL from http to https
Kibana and Elasticsearch are both of Version : 6.8.6
I have very less experience in web security so would really appreciate any guidance on the same...
You can follow this elasticsearch documentation for configuration of SSL and TLS, and it is available as free after 6.8 version.
Please check Configuring SSL, TLS, and HTTPS to secure Elasticsearch, Kibana, Beats, and Logstash blog.
Please check this documentation for how to setup SSL and TLS with Elasticsearch Docker Container.
There are few questions around Reverse Proxy on Server in Presentation Zone (PZ).
I'm trying to setup a reverse proxy on the IIS 7.x Windows 2012 Server(PZ). Do we really need ARR plugin to configure Reverse Proxy? Can you please suggest enable reverse proxy on the IIS 7.x without using ARR?
Is there any option to enable reverse proxy even without URL Re writer also?
How rewriting rules can be validated, captured, and maintained? asking this in context of deployment perspective.
ARRProxy is Microsoft's load balancing / reverse proxy solution. There are of course 3rd party solutions, like haProxy / nGinx, so you need it for a reverse proxy implementation unless you are going to use one of those.
You need the URL rewrite module, AFAIK.
Not sure. I guess you could have some unit testing on web.config where the rules are stored in the rules node?
My web application runs on https with http1.1 protocol. It was built using php5.4.27 and mysql5.0 and running on apache 2.2 in Centos 6.5 32bit system.
I want to upgrade the request protocol to http2 from http1.1 with https.
I would like to know the process for updating to http2 and supported versions for php & mysql
This is handled by webserver not PHP or MySQL.
Your current version of Apache (2.2) doesn't handle HTTP/2 - only Apache 2.4.18 and above (but would recommend latest version as this is changing quite a bit and is still marked as experimental). Note there are quite a few differences between Apache 2.2 and 2.4.
An alternative, if you don't want to upgrade, is to stick a CDN with HTTP/2 support in front of your site. Some of them (e.g. Cloudflare) even offer free tiers with HTTP/2 support.
I'm using both JIRA and Confluence on the same server, running on Windows, using Apache Tomcat.
I have two domains pointing at the server, jira.company.com and confluence.company.com.
JIRA is running fine on port 80 in the Apache Tomcat instance, and I can get to that on the JIRA.company.com domain just fine.
Confluence is currently running on port 8090 on the same machine. What I'm trying to do is get Confluence working on the confluence.company.com domain.
Most of the documentation I can see is about configuring virtual hosts and reverse proxies in httpd.conf, however in Apache Tomcat all I have to work with is the server.xml file.
I understand I can add another host to the JIRA server.xml file to point to a different docBase for Confluence, but I have a feeling this breaks Atlassian's own recommendations found here.
When I add an additional host entry into Confluence's server.xml it's ignored, and the confluence.company.com domain sends me through to JIRA.
I've done some searching and found similar questions but they don't seem to apply to my configuration - they all mention httpd.conf which isn't present on my server.
My questions:
Can I run Confluence on the subdomain by adding an extra entry in JIRA's server.xml? If possible, is this bad?
Is there another way to get my Confluence Apache instance listening on port 80 but on it's own domain name?
I can do all this on IIS with my eyes shut, but in Apache/Tomcat I'm a little lost. Thanks in advance!
Tomcat is not really meant to directly handle incoming requests as usually an Apache or other proxy is put in front of it to hide the ports and provide other useful features you would need for Single Sign On etc. Note that there is a difference between the Apache Webserver, which is commonly only called "Apache" and "Apache Tomcat", which is only an application server made by the Apache Foundation community and named "Tomcat". Tomcat only supports basic webserver functionality.
In any case, you can use the IIS as a webserver and proxy to forward the requests and at the same time hide the ports of the applications. I personally haven't used IIS but Atlassian offers a thorough explanation for the Confluence and/or JIRA integration with IIS as a proxy: https://confluence.atlassian.com/adminjiraserver071/integrating-jira-applications-with-iis-802593039.html
The page covers JIRA for the most part but section 4 also has additional information if you want to hook up both JIRA and Confluence on the same server, which is exactly your use case.
What is the difference between Apache HTTP Server and Oracle HTTP Server. What are the advantages/disadvantages of using Apache server , Oracle HTTP Server? Any insight into it is really appreciated.
Thanks,
Narendra
It's helpful to know that Oracle HTTP Server (OHS) is the Apache HTTP Server (Apache). Specifically OHS is Apache 2.2.22 including critical bug fixes from higher Apache versions. https://docs.oracle.com/middleware/1213/webtier/HSADM/intro_ohs.htm#HSADM102
* This has been updated with OHS 12.2.1 now to Apache 2.4.
https://docs.oracle.com/middleware/1221/webtier/administer-ohs/whats_new.htm#HSADM1277
OHS includes the WebLogic Server Proxy plugin (mod_wl_ohs) which brings frontend hosting to WebLogic application servers. OHS also includes configuration from the Fusion Middleware Control. Aside, this is of dubious value because you'll be editing the httpd.conf file through the advanced server configuration pages. An additional plus on the OHS side is all of the scripts and setup are generally in one place so there's less assembly of different bits such as with Apache. Finally, the control of OHS rests with the NodeManager daemon (usually) so that's one place to control WLS "Machines".
Bottom line OHS: OHS is a kinder-gentler way to be introduced to a slightly older version of Apache if you don't know Apache well. WLS plugins are included and if you're a WebLogic admin the Oracle docs are better. OHS is licensed by Oracle so it's not necessarily free, certainly not for support.
So to Apache's advantages. Since the mod_wl_ohs plugin can be downloaded separately, it can also be incorporated in an Apache installation. The configuration of the plugin is as involved as "normal" Apache httpd.conf edits, which is to say above-average complexity for those who have never worked with Apache HTTP Server. The server is also controlled from either init.d or systemd directly, as opposed to being controlled by nodemanager (which in turn is controlled by init.d/systemd).
Bottom line Apache: If you're a sysadmin who has already invested a lot in Apache, adding the WLS proxy plugin is pretty straight forward and you've gained everything OHS has to offer. But you'll have to kit it together yourself if you're a WLS administrator. Apache is licensed under the Apache 2.0, which is sort of a way of saying it's "free".
I will kindly direct you here.
Its also important to note that if you maintain a valid support contract with Oracle and you user their HTTP server they will support that tier as well. So its another way you can lump as many products as you can into a support contract.