The Lektor server is running on port 5000 on localhost. I want to make it accessible via an Apache URL at http://myhost.org/lektor. Therefore, I've tried the httpd config snippet
ProxyPass /lektor http://127.0.0.1:5000
ProxyPassReverse /lektor http://127.0.0.1:5000
The HTML for the welcome page is found, but the static pages referenced there (e.g., http://myhost.org/static/style.css) are not. How can I make the changed URL known to Lektor?
The development server is not intended to be used for production. The production deployments are based on entirely static content and will resolve static assets correctly if you use the |url filter.
I had success with just slightly different syntax:
ProxyPass / "http://localhost:5000/"
ProxyPassReverse / "http://localhost:5000/"
Seems the trailing slash is needed. I'm not sure whether you need the actual name "localhost" in there, but that's what worked for me.
I did the following additional items with my setup, and it's rather slick:
Set up Lektor on an internal private-ip webserver
Set up two virtual hosts, for example lektor-web-dev.my.domain and lektor-web.my.domain
Set up self-signed certificates on the -dev domain, and used the above ProxyPass items in its vhost config (Apache)
Set up basic authentication on the -dev domain, so there's at least a basic level of authentication
Set up rsync deploy to loop back to localhost using an SSH keypair, and copy the output files to lektor-web.my.domain's webroot
Now, lektor-web.my.domain is still on a private webserver without certificates. However, on my public-facing webserver, I SSL terminate and proxy through to lektor-web.my.domain. I get the certificate with letsencrypt.
This is expandable to any number of websites. Keep the Lektor admins running using supervisor or some other process management system. Use 'lektor server -p portnum' to pick a different port for each site's admin. You can do group-based access to various admins using HTTP basic authentication along with an htpasswd and htgroup file.
Related
Currently I'm trying to run both SpringBoot application and mediawiki server (but I assume it may be any other server) on one machine simultaniously. They are both accessed via different ports e.g. 8080 and 7734.
Now I want to be able to access my Spring app as usual on localhost:8080/homePage and if I type something like this (with wiki included in the beggining of the url) localhost:8080/wiki/faqPage there must be some setting (or maybe another proxy server?) to redirect requests to the mediawiki instance. So the request to localhost:8080/wiki/faqPage would actually go to localhost:7734/faqPage. What is the best practice for achieving this?
If it helps I'm using docker image and docker-compose util to run mediawiki instance
Okay. Apache's ProxyPass and ProxyPassReverse in the httpd.conf did the magic
I'm trying to figure out how to link my Apache2 server running on AWS Lightsail to an application I'm housing that uses http://localhost:3000 when activated—it's a simple Node.js based CMS called Vapid. I have the server linked to my domain name—bigsheepcollective.com—and I can get Vapid running through the AWS terminal, but it's only the Apache2 landing page that shows up on my domain name. I saw a tutorial here that goes over establishing a proxy pass on an Nginx ran server but I'm not sure how to do the same thing for one using Apache2.
I've tried using the Nginx tutorial and I've also don't some extensive searches into proxy setups for Apache2, but I'm confused about what type of proxy I need when it comes to running an application that uses http//:localhost:3000.
Hi Bitnami Engineer here.
You can include these lines in the /opt/bitnami/apache2/conf/bitnami/bitnami.conf file or in the specific .conf file you created for your application
ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/
This way you will access your application when accessing the public IP of your instance or its associated domain.
This guide in our documentation explains the whole process to configure a Node.js application on top of Bitnami.
https://docs.bitnami.com/aws/infrastructure/mean/administration/create-custom-application-nodejs/
I would like to deploy ember app in an EC2 ubuntu instance.
I have installed tomcat in EC2 ubuntu instance.
I have run ember build and generated dist files
I dont know how to make the tomcat run the dist files that is generated during the build.
Can someone explain it in a step by step so that I can understand clearly?
I don't think you should be serving the Ember app from Tomcat. At least in the past when I evaluated, Tomcat is much slower at SSL than Apache/Nginx, isn't as fast with static content, requires redeploys of the WAR file if you change static content, and lacks the configuration options of the more commonly used HTTP servers.
Better approach, reverse proxy to your app server (I assume you are running a java app since you are using Tomcat). Serve the Ember app from the reverse proxy. If you are running SSL, you would handle it all from the reverse proxy and not tomcat. This is how I serve my Ember app and my Spring Boot app (the api powering my ember app) from the same EC2 instance.
I'll show you how I do it on redhat but you'll have to translate for ubuntu (as in you have apt-get where i use yum, etc).
Install apache on your VM
yum install httpd -y
Configure apache as a reverse proxy in /etc/httpd/conf/httpd.conf
<VirtualHost *:80>
ProxyRequests Off
ProxyPass /api http://localhost:8080/api
ProxyPassReverse /api http://localhost:8080/api
</VirtualHost>
FallbackResource /index.html
This has two very important parts. First, you run your tomcat serve on http://localhost:8080/ (not on 80!) and have a servlet underneath api or something other subpath. You need this sort of distinction so that your ember urls do not conflict with your api urls. As in, if you are wanting your Ember app to run under / and you have an api endpoint under /users and an Ember route /users, how can you distinguish which should be served? I argue that your api should run under /api/users to avoid collisions.
Second, the FallbackResource /index.html allows unmatched directories to return your index.html file. See, when your browser makes the request: yourapp.com/someRoute to your server, you need your http server to simply return the index.html file. Ember will then take care of the routing on the client side. This means, regardless of what route you are on in Ember, when the browser asks for that url, you should always return index.html. I don't even know how you would configure a rule like this in tomcat (you'll have to research rewrite rules/directives if you don't want to use a reverse proxy).
Lastly, within http.conf find the document root: eg. DocumentRoot "/var/www/html". This is the path on your EC2 server where your static files are served from. This is where the contents of your dist folder belong. For me, a typical deployment means ember build, scp to the server, sudo rm -rf /var/www/html/ and sudo cp -r dist/. /var/www/html to replace the old ember app with the new. This works for me because the contents of my ember app are the only static files that I need to serve. If you have other needs, you can't just delete and replace the old document root like I do.
Make sure httpd/apache is running! service httpd start on redhat. You don't have to restart the server when changing out files.
Our Organization is using SonarQube application which is hosted in azure server which we are using internally and is not accessible via internet. For adding security we implement https for the application with the help of ssl certificate which is given by our internal certification authority.
But after i implement https we are getting "Your Connection to this Site is not Secure".
Is their is any way to make the connection secure? As we are using the application internally.
As per the SonarQube documentation, for adding security/Https their recommendation is to use a reverse proxy and not adding the SSL to the SonarQube website directly. Here is the official documentation and the link:
To run the SonarQube server over HTTPS, you must build a standard reverse proxy infrastructure.
The reverse proxy must be configured to set the value "X_FORWARDED_PROTO: https" in each HTTP request header. Without this property, redirection initiated by the SonarQube server will fall back on HTTP.
Using an Apache Proxy
We assume that you've already installed Apache 2 with module mod_proxy, that SonarQube is running and available on http://private_sonar_host:sonar_port/ and that you want to configure a Virtual Host for www.public_sonar.com.
At this point, edit the HTTPd configuration file for the www.public_sonar.com virtual host. Include the following to expose SonarQube via mod_proxy at http://www.public_sonar.com/:
ProxyRequests Off
ProxyPreserveHost On
<VirtualHost *:80>
ServerName www.public_sonar.com
ServerAdmin admin#somecompany.com
ProxyPass / http://private_sonar_host:sonar_port/
ProxyPassReverse / http://www.public_sonar.com/
ErrorLog logs/somecompany/sonar/error.log
CustomLog logs/somecompany/sonar/access.log common
</VirtualHost>
Using Nginx
We assume that you've already installed Nginx, that you are using a Virtual Host for www.somecompany.com and that SonarQube is running and available on http://sonarhost:sonarport/.
At this point, edit the Nginx configuration file. Include the following to expose SonarQube at http://www.somecompany.com/:
# the server directive is nginx's virtual host directive
server {
# port to listen on. Can also be set to an IP:PORT
listen 80;
# sets the domain[s] that this vhost server requests for
server_name www.somecompany.com;
location / {
proxy_pass http://sonarhost:sonarport;
}
}
Using IIS
SonarQube recommends the use of a Reverse Proxy to secure you sonar installation. With the help of IIS and the Url Rewrite module, that's a piece of cake to setup.
What you'll need:
IIS enabled on a machine (doesn't have to be the SonarQube machine, but I'm going to assume you're doing this on the same system)
The Url Rewite extension for IIS (https://www.iis.net/downloads/microsoft/url-rewrite)
The Application Based Routing extension for IIS (https://www.iis.net/downloads/microsoft/application-request-routing)
An SSL certificate (can be self signed or a real one)
First step is to create a IIS website which will act as the reverse proxy.
Unless you're required to do Kerberos authentication, you don't need to configure any form of authentication on your Reverse Proxy. It should forward the challenge from SonarQube if you've configured Active Directory integration there.
If you are using Kerberos or IIS Advanced protection, please look here for guidance on configuring that correctly. (https://blogs.technet.microsoft.com/latam/2015/06/24/kerberos-authentication-and-application-request-routing/)
Configure the binding to use SSL and setup the correct hostnames and the certificate. I'm cheating a little by using the IIS Express Development Certificate installed on my machine:
Next we'll open the URL Rewrite settings to configure reverse proxy:
Click Add Rule to create a new rule:
And pick "Reverse Proxy" from the list of templates:
Enter the destination server URL (can be http://localhost:9000, or even a remote server) and click OK to create the rule:
You're back in the URL Rewrite screen where we'll need to add an extra server variable which we'll send along with the request to the other server in order to tell SonarQube it's actually behind a Reverse Proxy that's doing the SSL offloading for it:
Click "Add..." to create the server variable:
Add the server variable "X_FORWARDED_PROTO" to allow the Rewrite Module to manipulate this header:
You should now have the variable listed in the Variable list. Click "Go back to Rules" to move back to the rules list:
Edit the URL Rewrite rule you've just created:
Expand the Server variables section of the rule definition:
Add the "X_FORWARDED_PROTO" header you've allowed in the previous step and give it the value "https":
Apply the changes:
And now you should be able to access SonarQube over SSL. You may want to configure the original SonarQube instance to only accept traffic from your reverse proxy or only accept traffic from localhost through the Windows Firewall.
Copied from:
USING IIS
Server setup documentation
I'm running my parse app on a naked domain. Parse is not making my life easy though.
At first I struggled to set it up because most DNS hosting services don't allow CNAMEs on the the root domain and Parse requires a CNAME.
Decided to try it out with CloudFlare's CNAME flattening and it ended up working by setting up the CNAME under [hostname key].example.com.
Parse wouldn't allow me to set it up without the hostname key because example.com was not a real CNAME (it's being translated to an A record under the wood by CloudFlare).
But I want to run my website under HTTPS so I registered a certificate that is valid for both "https:// example.com" and "https:// www.example.com".
Again Parse doesn't make it easy. First it didn't accept my certificate because the hostname wouldn't match. I thought that maybe it was trying to compare it with the subdomain of the cert (www.example.com) and that wouldn't match with my app domain (example.com).
I created another CNAME at [hostname key].www.example.com poiting to my parseapp.com url (didn't want to change www.domain.com because it's already poiting to another service that redirects to domain.com), changed my app hostname to www.example.com and it finally accepted my certificate! Yeahhh!
Changed the app hostname back to example.com and tried to access it in the browser, but it takes forever to load and ends failing.
If I change my app to run on "https:// www.example.com" (secure site with with the www subdomain) then it works fine.
So I'm able to run my app in http://example.com (not secure, without www) or "https:// www.example.com" (secure with www).
Why is it that Parse makes it so difficult to run an app on the root domain?
Is there something that I need to do to be able to run a secure app in the root domain?
Most of web services nowadays are designed around the idea of CNAMEs: they provide you a CNAME and you should alias your hostname to that name.
However, as you noted, the CNAME has certain limitations imposed by the DNS protocol RFC and it can't be used to map an apex domain.
Some DNS companies, such as DNSimple or DNS Made Easy, provides a CNAME-like record type that can be used to map the root domain to an hostname provided by a cloud service. Using these services will also make it easier to configure an SSL certificate.
Speaking of SSL certificates, beware that when you purchase a single-name certificate for example.com or www.example.com, it is only valid for that specific hostname. Most certificate authorities will also include the corresponding apex domain if you purchase www.example.com, but you need to check with your SSL certificate provider.
Last but not least, the ability to redirect HTTP to HTTPS traffic really depends on your service provider, in this case parse.com. Unfortunately, it's not uncommon for these services to not force HTTPS. Heroku is currently doing the same, they don't force HTTP to HTTPS when you enable HTTPS.
You should check with them if there is a way to apply such redirect, as the only way is to apply it either at server level or app level. You can't apply the redirect, for example, at DNS level.