I have a Ghost blog hosted on digitalocean, my domain can only be accessible with a secure connection (it's a .dev site).
My site is available when I access it with www, e.g. www.androidoss.dev, but not when accessed directly as androidoss.dev.
What could be the issue?
If you have deployed the Ghost on the DigitalOcean server then it's running behind the Nginx probably. So during the Ghost installation there a command is executed which is ghost setup nginx which setup Nginx for you and then run ghost setup ssl which set up Let's Encrypt SSL for the provided domain name and it doesn't create a redirection rule from non-www to www.
So you can do this by adding a redirection URI in your Nginx file.
You have to add these lines in the server block for http. It will look like this and the file-path is /etc/nginx/sites-available/ww.example.com
server {
listen 80;
...................
...................
}
you have to add the below lines at the place of dotted lines.
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
Seeing an issue after configuring a reverse proxy in my Apache web server and having a tough time finding a solution, hoping one of you may be able to assist.
Example:
I am trying to configure a reverse proxy to map the backend application URL http://appserver/app/ to the URL https://webserver/app/ on my public domain.
I noticed that any resources located under the http://appserver/app/ path (such as /app/images) are being served properly when accessed via corresponding reverse proxy URL (https://webserver/app/images).
However, some html files are being served from the backend application server root context path (http://appserver/test.html) and the requests for these files are returning 404 errors when the application is accessed via the reverse proxy URL
When reviewing the chrome dev tools network trace, I see Apache is serving these resources from the root context of the reverse proxy URL (https://webserver/test.html), instead of the reverse proxy path (https://webserver/app/test.html), as intended.
I believe this is the expected behavior in Apache, but I am trying to find a way to rewrite the URLs to serve these resources via the reverse proxy context path https://webserver/app/ instead of the root.
Below is my current configuration and I am aware that it will not work as intended when configured this way, but I have tried just about every combination of RewriteRule and ProxyPassReverse directives I can think of, to no avail.
RewriteRule ^/app/(.*)$ http://appserver/app/$1 [P,L]
ProxyPassReverse /app/ http://appserver/app/
I have also tried the following, with no luck.
RewriteRule ^/app/(.*)$ http://appserver/$1 [P,L]
ProxyPassReverse /app/ http://appserver/
Outside of the basics, I am a bit of a noob when it comes to Apache, so I apologize if this is a dumb question, but I have looked all over to find a solution, and still haven't found one :(
Any help is appreciated!
Thanks a lot
I'm using apache httpd v2.2 server as a frontend proxy for our actual tomcat web server which hosts the Java web application.
I want to forward all urls received by apache webserver other than those having the prefix /product to tomcat.
I've tried the following set up in httpd.conf but it' doesn't seem to work
<VirtualHost *:6111>
ServerName localhost
RewriteEngine on
RewriteRule !^(/product($|/)) http://localhost:1234/$1
Alias /product /opt/productdoc
</VirtualHost>
I tried to follow Redirect site with .htaccess but exclude one folder but was not successful
Basically all http://localhost:6111/product urls should serve from hard drive (using alias)
Any other url should be forwarded to http://localhost:1234/<original-path>
You probably want to use something like mod_jk http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html.
There are a ton of examples and tutorials and it should be pretty simple to setup and install. Now that you know the name of the connection technology, you should probably be able to find more information.
Using modjk also allows you to secure your tomcat server and keep the public off of it.
Been playing with nginx for about an hour trying to setup mass dynamic virtual hosts.
If you ever done it in apache you know what I mean.
Goal is to have dynamic subdomains for few people in the office (more than 50)
Perhaps doing this will get you where you want to be:
server {
root /sites/$http_host;
server_name $http_host;
...
}
I like this as I can literally create sites on the fly, just create new directory named after the domain and point the DNS to the server ip.
You will need some scripting knowledge to put this together. I would use PHP, but if you are good in bash scripting use that. I would do it like this:
First create some folder (/usr/local/etc/nginx/domain.com/).
In main nginx.conf add command : include /usr/local/etc/nginx/domain.com/*.conf;
Every file in this folder should be different vhost names subdomain.conf.
You do not need to restart nginx server for config to take action, you only need to reload it : /usr/local/etc/rc.d/nginx reload
OR you can make only one conf file, where all vhosts should be set. This is probably better so that nginx doesn't need to load up 50 files, but only one....
IF you have problems with scripting, then ask question about that...
Based on user2001260's answer, later edited by partlov, here's my outcome.
Bear in mind this is for a dev server located on a local virtual machine, where the .dev prefix is used at the end of each domain. If you want to remove it, or use something else, the \.dev part in the server_name directive could be edited or altogether removed.
server {
listen 80 default_server;
listen [::]:80 default_server;
# Match any server name with the format [subdomain.[.subdomain...]].domain.tld.dev
server_name ~^(?<subdomain>([\w-]+\.)*)?(?<domain>[\w-]+\.[\w-]+)\.dev$;
# Map by default to (projects_root_path)/(domain.tld)/www;
set $rootdir "/var/www/$domain/www";
# Check if a (projects_root_path)/(subdomain.)(domain.tld)/www directory exists
if (-f "/var/www/$subdomain.$domain/www"){
# in which case, set that directory as the root
set $rootdir "/var/www/$subdomain.$domain/www";
}
root $rootdir;
index index.php index.html index.htm index.nginx-debian.html;
# Front-controller pattern as recommended by the nginx docs
location / {
try_files $uri $uri/ /index.php;
}
# Standard php-fpm based on the default config below this point
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}
The regex in server_name captures the variables subdomain and domain. The subdomain part is optional and can be empty. I have set it so that by default, if you have a subdomain, say admin.mysite.com the root is set to the same root as mysite.com. This way, the same front-controller (in my case index.php) can route based on the subdomain. But if you want to keep an altogether different application in a subdomain, you can have a admin.mysite.com dir and it will use that directory for calls to admin.mysite.com.
Careful: The use of if is discouraged in the current nginx version, since it adds extra processing overhead for each request, but it should be fine for use in a dev environment, which is what this configuration is good for. In a production environment, I would recommend not using a mass virtual host configuration and configuring each site separately, for more control and better security.
server_name ~^(?<vhost>[^.]*)\.domain\.com$;
set $rootdir "/var/www/whatever/$vhost";
root $rootdir;
As #Samuurai suggested here is a short version Angular 5 with nginx build integration:
server {
server_name ~^(?<branch>.*)\.staging\.yourdomain\.com$;
access_log /var/log/nginx/branch-access.log;
error_log /var/log/nginx/branch-error.log;
index index.html;
try_files $uri$args $uri$args/ $uri $uri/ /index.html =404;
root /usr/share/nginx/html/www/theft/$branch/dist;
}
Another alternative is to have includes a few levels deep so that directories can be categorized as you see fit. For example:
include sites-enabled/*.conf;
include sites-enabled/*/*.conf;
include sites-enabled/*/*/*.conf;
include sites-enabled/*/*/*/*.conf;
As long as you are comfortable with scripting, it is not very hard to put together some scripts that will quickly set up vhosts in nginx. This slicehost article goes through setting up a couple of vhosts and does it in a way that is easily scriptable and keeps the configurations separate. The only downside is having to restart the server, but that's to be expected with config changes.
Update: If you don't want to do any of the config maintaining yourself, then your only 2 options (the safe ones anyways) would be to either find a program that will let your users manage their own chunk of their nginx config (which will let them create all the subdomains they want), or to create such a user-facing management console yourself.
Doing this yourself would not be too hard, especially if you already have the scripts to do the work of setting things up. The web-based interface can call out to the scripts to do the actual work so that all the web interface has to deal with is managing who has access to what things.
I'm running a site on AmazonEC2 instance, and so far everything is ok, except a single glitch. When I navigate to
www.mysite.com/somepage.html
, browser happily opens the desired page. But when I try
mysite.com/somepage.html
, I go to the root of my site, i.e. to
www.mysite.com
LiveHTTPHeaders tells me that 301 redirection occurs. So here's the question: what configuration files do I need to change to make redirection respect URL path?
Also, I noticed that nginx does the redirection. Does it mean that redirection is happening outside of EC2 instance or not?
Thank you in advance.
You should have some kind of settings that is redirecting your request from http://mysite.com/ to http://www.mysite.com/
Following is kind of conf. settings you should find in your nginx.conf or inside /etc/nginx/sites-enabled/<site-vhost-name>
server {
server_name example.com;
rewrite ^/(.*) http://www.example.com/$1 permanent;
}
This tells NGINX to redirect request from http://mysite.com/ to http://www.mysite.com/.
If yes?, then blindly remove those two lines of conf.