I am running Amazon EC2 #Ubuntu. I published my express application there and it is working good. Now I am trying to make access to static files through www.myurl.com/somefile so I can make SSL certificates public for nginx use.
I set up simple nginx as:
server {
listen 80;
sernver_name _;
location / {
proxy_pass: http://localhost:3000;
}
}
inside my express.js i put
app.use(express.static('wwwroot'))
When I start application locally, create folder wwwroot inside my project folder and add some file to it, i can access it through http://localhost:3000/file.txt but when I release project on my EC2, create folder, put file, it returns 404.
EDIT:
Just tried changing
app.use(express.static(path.join(__dirname, 'wwwroot'))
locally works, on EC2 ubuntu with nginx it doesn't
My Node.Js Bitnami Lightsail instance had its frontend code at /opt/apache/htdocs and http://example.com was working perfectly pointing to that directory (my backend located under opt/projects).
After executing Certbot LetsEncrypt my domain is now pointing to a different folder /var/www/html
Please advise on:
In certbot instruction page I choose Apache for "My HTTP website is running", there wasn't a Bitnami option, was that the right call?
Is this the right configuration and just move my code to html folder?
Does my backend code has to move too? if so where?
Any other well-known issues that I might face?
Cheers.
Bitnami Engineer here,
We do not have any guide to configure certbot and Bitnami, but we have a guide that helps you configure the Let's Encrypt SSL certificate using lego. We have a tool that configures everything so you do not need to worry about editing the Apache's conf files or setting the renew process.
sudo /opt/bitnami/bncert-tool
You can learn more about it here.
In case you want to manually create a SSL certificate, you can also run the lego tool directly
sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run
You will later need to configure the Apache's conf files to use that new certificate file. You can learn more about it here
Note: If you used certbot and it modified the Apache's configuration, you will need to undo those changes to use the proper folder. You will need to review the /opt/bitnami/apache2/conf/httpd.conf, /opt/bitnami/apache2/conf/bitnami/bitnami.conf and /opt/bitnami/apache2/conf/vhosts/* files
I'm running an app with heroku using their php buildpack.
Therefore my app starts with web: vendor/bin/heroku-php-nginx -C nginx.conf public/ where nginx.conf is my custom nginx config file that gets appended inside a server directive here: https://github.com/heroku/heroku-buildpack-php/blob/master/conf/nginx/heroku.conf.php#L60.
I'm wondering how I can set this up in a way where I can get ssl to work locally while still having a config that is consistent in both prod and dev?
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.
Currently I have lighttpd configured as a reverse proxy of apache. Lighttpd listens on the public IP while apache listens on 127.0.0.1. Lighttpd passes non-static contents to apache using the configuration
$HTTP["url"] !~ "\.(js|css|gif|jpg|png|ico|txt|swf|html|htm|gz)$" {
proxy.server = ( "" => (
( "host" => "127.0.0.1", "port" => 80 )))
expire.url = ( "/" => "access 5 minutes")
}
This simple setup works just fine with a vanilla wordpress install. Static files are being served by lighttpd while everything else is served by apache.
I want to take it to the next level so I installed wp-super-cache so that cache/html version of pages are created. The wp-super-cache plugin has been installed properly and its modification to the htacess file has been properly applied. I used the mod_rewrite mode of wp-super-cache and the custom permalink structure of wordpress is /%category%/%postname%.html. All works great. Cache/html pages are being created and served. There is just one little problem. It will only work if I remove the html file extesion in the above configuration. This means apache will serve the cache/html files and not lighttpd. One solution that I thought of is to have simliar rewrite rules on lighttpd when accessing html files. I do not know if it will gonna work but I searched for it anyway. I found http://tempe.st/2008/05/lightning-speed-wordpress-with-lighttpd-and-supercache-part-ii/ (you may need google cache to access it because it was not working today, but yesterday it did) thinking it may be the solution but the bad news is I am using a rpm based distro and the rpm repo that I use does not have mod_magnet for lighttpd. I searched for other repos that offer lighttpd with mod_magnet but found none. So I cannot use the one solution that I have found because my lighttpd does not have mod_magnet functionality.
What should I do to make lighttpd serve the cache/html files that were created by wp-super-cache? Is this possible?
Thanks!
I know, it's a little bit late, but you could try my version of rewrite.lua script for WP Super Cache. It works just like it must work. https://gist.github.com/1258096