I am building a multi-tenant application where requests to multiple domains have to be serviced by the same nginx server.
In order to achieve this, a script creates nginx configs for each domain after a registration process and adds them into a folder. The base nginx configuration has been setup to read configs from this folder.
If I manually restart nginx using sudo service nginx restart the application works fine. However, I am looking for this to happen without a manual intervention. i.e. I want my script to refresh nginx config and I want to do it without entering a sudo password again.
Can someone help me achieve this?
I would strongly discourage using service ngnix restartto reload configs, especially in a multi-tenant environment. You risk interrupting ongoing requests, sessions, etc. That's potentially fine, but each tenant had to make that determination and has to do so at appropriate times. Nginx supports the command service ngnix reload to address this concern. Reload allows for configs to be reloaded without any downtime.
You could trigger the command at least 3 ways:
Periodic cron job (easiest to setup, least efficient)
Manually triggering the command
Trigger through filesystem monitoring
Option 2 would be good if, for example, you had some web interface that allows a tenant to modify a config and you know to manually trigger the command or to send a message to some other service that triggers it. You could avoid using sudo securely by granting the web application the ability to run a single command as root e.g. vi sudo and add the line www-data ALL=(ALL) NOPASSWD: /usr/sbin/service nginx reload where www-data should be whatever user your application runs under. Then you can just execute the shell command according to whatever api is appropriate for the language you are using.
Option 3 would be the most robust. There all several options for monitoring the filesystem but I would recommend incron. Here's a guide to install and configure incron. You could monitor changes to whichever directory you store configs in and use service nginx reload in place of the example command in the tutorial.
Related
I'm working on a small Flask based service behind Nginx that serves some content over HTTP. It will do so using two-way certificate authentication - which I understand how to do with Nginx - but users must log in and load their own certificate that will be used for the auth piece.
So the scenario is:
User has a server that generates a cert that is used for client authentication.
They log into the service to upload that cert for their server.
Systems that pull the cert from the user's server can now reach an endpoint on my service that serves the content and authenticates using the cert.
I can't find anything in the Nginx docs that says I can have a single keystore or directory that Nginx looks at to match the cert for an incoming request. I know I can configure this 'per-server' in Nginx.
The idea I currently have is that I allow the web app to trigger a script that reads the Nginx conf file, inserts a new server entry and a specified port with the path to the uploaded cert and the sends the HUP signal to reload Nginx.
I'm wondering if anyone in the community has done something similar to this before with Nginx or if they have a better solution for the odd scenario I'm presenting.
After a lot more research and reading some of the documentation on nginx.com I found that I was way over complicating this.
Instead of modifying my configuration in sites-available I should be adding and removing config files from /etc/nginx/conf.d/ and then telling Nginx to reload by calling sudo nginx -s reload.
I'll have the app call a script to run the needed commands and add the script into the sudoers file for the www-data user.
In order to automate build on a server, I had to do the following:
Make a user with root access on the destination server
Add rsa-gen public key to authorised_keys of destination server, for passwordless login.
Created script with 1st command being ssh user#dest.
The problem we are facing is that command execution still asks for sudo... How do we achieve this in a script or otherwise?
There is a plugin to make this simple.
SSH plugin can take server details along with credentials and can handle all of it for us.
To use it, follow these steps:
install SSH plugin on your jenkins from Manage plugins.
go to configure system, add under SSH remote hosts.
add all the details required to connect to server
In your job, add build step - Execute shell script in remote host using ssh.
Say I have a docker image, and I deployed it on some server. But I don't want other user to access this image. Is there a good way to encrypt the docker image ?
Realistically no, if a user has permission to run the docker daemon then they are going to have access to all of the images - this is due to the elevated permissions docker requires in order to run.
See the extract from the docker security guide for more info on why this is.
Docker daemon attack surface
Running containers (and applications)
with Docker implies running the Docker daemon. This daemon currently
requires root privileges, and you should therefore be aware of some
important details.
First of all, only trusted users should be allowed to control your
Docker daemon. This is a direct consequence of some powerful Docker
features. Specifically, Docker allows you to share a directory between
the Docker host and a guest container; and it allows you to do so
without limiting the access rights of the container. This means that
you can start a container where the /host directory will be the /
directory on your host; and the container will be able to alter your
host filesystem without any restriction. This is similar to how
virtualization systems allow filesystem resource sharing. Nothing
prevents you from sharing your root filesystem (or even your root
block device) with a virtual machine.
This has a strong security implication: for example, if you instrument
Docker from a web server to provision containers through an API, you
should be even more careful than usual with parameter checking, to
make sure that a malicious user cannot pass crafted parameters causing
Docker to create arbitrary containers.
For this reason, the REST API endpoint (used by the Docker CLI to
communicate with the Docker daemon) changed in Docker 0.5.2, and now
uses a UNIX socket instead of a TCP socket bound on 127.0.0.1 (the
latter being prone to cross-site request forgery attacks if you happen
to run Docker directly on your local machine, outside of a VM). You
can then use traditional UNIX permission checks to limit access to the
control socket.
You can also expose the REST API over HTTP if you explicitly decide to
do so. However, if you do that, being aware of the above mentioned
security implication, you should ensure that it will be reachable only
from a trusted network or VPN; or protected with e.g., stunnel and
client SSL certificates. You can also secure them with HTTPS and
certificates.
The daemon is also potentially vulnerable to other inputs, such as
image loading from either disk with ‘docker load’, or from the network
with ‘docker pull’. This has been a focus of improvement in the
community, especially for ‘pull’ security. While these overlap, it
should be noted that ‘docker load’ is a mechanism for backup and
restore and is not currently considered a secure mechanism for loading
images. As of Docker 1.3.2, images are now extracted in a chrooted
subprocess on Linux/Unix platforms, being the first-step in a wider
effort toward privilege separation.
Eventually, it is expected that the Docker daemon will run restricted
privileges, delegating operations well-audited sub-processes, each
with its own (very limited) scope of Linux capabilities, virtual
network setup, filesystem management, etc. That is, most likely,
pieces of the Docker engine itself will run inside of containers.
Finally, if you run Docker on a server, it is recommended to run
exclusively Docker in the server, and move all other services within
containers controlled by Docker. Of course, it is fine to keep your
favorite admin tools (probably at least an SSH server), as well as
existing monitoring/supervision processes (e.g., NRPE, collectd, etc).
Say if only some strings need to be encrypted. Could possibly encrypt this data using openssl or an alternative solution. Encryption solution should be setup inside the docker container. When building container - data is encrypted. When container is run - data is decrypted (possibly with the help of an entry using a passphrase passed from .env file). This way container can be stored safely.
I am going to play with it this week as time permits, as I am pretty curious myself.
I've struggled for couple of weeks on this configuration.What I want to achieve can be listed as follows.
1.I registered a domain not long ago.And I've set up some web service on my VPS,such as a blog,a forum and Owncloud. Now I want to configured the Nginx so that I can run all the service on one VPS and one IP address. In order to run owncloud,I have to modify the /etc/php5/fpm/pool.d/www.confto listen = 9000.In this case,I can only get one service (Owncloud)function,because if I want to run the forum I must uncomment the listen = /var/run/php5-fpm.sock.What's more,I've tried to uncomment both of them,Nginx showed 502 afterwards.
2.I'm using Hexo as my blog.When I start the server,I can access into my blog on IP:4000.So I wonder if I could run my blog server on background and edit the posts online via a subdomain which has been redirected to port 4000.If it's possible,should I modify the nginx.conf or add something in sites-available?
3.Can I deploy different web services on different subdomain?Which file is to modify?It's said that I can achieve this by using reverse proxy?
Sorry for the pathetic English and expression.Thanks in advance.
Going at it point by point:
The advantage of PHP-FPM, which you are using, is that you can have multiple separate interpreters running in your pool. To do so, simply copy the file at /etc/php5/fpm/pool.d/www.conf to somewhere else, say /etc/php5/fpm/pool.d/forum.conf, change the listen directive, and you've got a second php interpreter running, entirely separate from the first one. That way owncloud (www) and your forum (forum) have their own distinct php.
This is called reverse-proxying. nginx does that well. You simply add a new site definition in sites-available that does reverse-proxying to port 4000 on your server, then symlink (or copy) that site definition to sites-enabled and restart nginx. You will have to setup Hexo to start automatically for that to work.
You can deploy different web services on different subdomains. As long as the dns is configured to point that name to your server, you can configure the server to respond differently for every subdomain using site definitions. You need to modify the files in sites-enabled to determine which names nginx knows how to respond to.
We want to run a daemon that exposes itself via ASMX, using Mono 2.0 (or later). Instead of dealing with the ASP.NET hosting APIs, we're thinking about just starting a daemon thread in the Application_Start event. XSP2 shouldn't restart the appdomain, so our daemon will be safe.
Are there any downsides to this (besides being a bit odd)? Any other approaches that allow us to have our code running in the same appdomain as the ASMX requests?
Why do need XSP to run a daemon through calling an ASXM when you can just build a shell console application (with the same code or accepting arguments)? That can be called in terminal or called from any shell script and added to cron. Simple no server required to do this.
If you want to do this, not the way I would do it, you can setup a basic server instance (using nginx, lighty or apache) listing in a certain internal port, add that server to a dummy host and on cron/shell script you can do
WGET http://dummyhost/mydaemon.asmx