davidnelson.net

Tag: nginx

  • Mastodon discoverability on your domain using the nginx location directive

    tl;dr: Puts the .well-known/webfinger content in your server config instead of the filesystem.

    This setup is inspired by Maarten Balliauw‘s Mastodon on your own domain without hosting a server. Please read the linked post for details. The general idea is you can create a special file on your website that allows people to find you on Mastodon by searching for @you@yourdomain.tld even though you don’t run an instance on your domain.

    Here’s my twist: What if you can’t or don’t want to add this file directly to the filesystem where your web content lives? Maybe your site is running a CMS that precludes adding arbitrary files. Or you just don’t want to forget to preserve the file between software upgrades and reinstalls. Whatever your reason, you can do this by putting the file content inside of a location directive in your nginx config instead.

    These instructions assume you have a working knowledge of nginx configuration and server administration.

    1. In a browser navigate to https://<your mastodon server>/.well-known/webfinger?resource=acct:<your account>@<your mastodon server>
    2. Select and copy the json text that appears on the page.
    3. Edit the nginx config file that contains the server block for your domain.
    4. Add a new location directive like below, replacing your-code-here with the json that was copied in step 2. 
      location /.well-known/webfinger {
     return 200 'your-code-here'; 
}
    5. Save your config and restart nginx.

  • File ownership considerations with Nginx and php-fpm

    I recently switched my CentOS 7 web server over to Nginx and php-fpm.

    From my experience with Apache I assumed that PHP scripts would be executed by the same user the web server is running as — ‘nginx’ in this case. But this could no longer be taken for granted since php-fpm is a separate process from the web server.

    In my configuration php-fpm was actually running as the ‘apache’ user. This meant any files that need to be writable by PHP scripts should still be owned by that user or group rather than ‘nginx’.

    A common scenario where this matters is if your users need to be able to install WordPress updates, Plugins, or Themes via the browser without entering additional credentials. In order for this to work, the web server (or in this case, php-fpm) must be able to write to the files in question.

    If you are wrestling with file permissions, or are unsure of the correct permissions to set in this scenario, be sure to confirm which user and group are specified in /etc/php-fpm.d/www.conf

    # grep "^user\|^group" /etc/php-fpm.d/www.conf 
user = apache
group = apache

    Or you can check the actual running process with pstree:

    $ pstree -ua | grep "nginx\|php"
  |-nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   |-nginx,nginx
  |   `-nginx,nginx
  |-php-fpm
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   |-php-fpm,apache              
  |   `-php-fpm,apache