content: setting-up-the-server-to-host-pelican
This data as json
| author | category | content | published_date | slug | summary | title | url |
|---|---|---|---|---|---|---|---|
| ryan | technology | # Creating the user on the server Each site on my server has it's own user. This is a security consideration, more than anything else. For this site, I used the steps from [some of my scripts for setting up a Django site](https://www.ryancheley.com/2021/02/21/automating-the-deployment/). In particular, I ran the following code from the shell on the server: adduser --disabled-password --gecos "" ryancheley adduser ryancheley www-data The first command above creates the user with no password so that they can't actually log in. It also creates the home directory `/home/ryancheley`. This is where the site will be server from. The second commands adds the user to the `www-data` group. I don't think that's strictly necessary here, but in order to keep this user consistent with the other web site users, I ran it to add it to the group. # Creating the nginx config file For the most part I cribbed the `nginx` config files from this [blog post](https://michael.lustfield.net/nginx/blog-with-pelican-and-nginx). There were some changes that were required though. As I indicated in part 1, I had several requirements I was trying to fulfill, most notably not breaking historic links. Here is the config file for my UAT site (the only difference between this and the prod site is the server name on line 3): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | server { server_name uat.ryancheley.com; root /home/ryancheley/output; location / { # Serve a .gz version if it exists gzip_static on; error_page 404 /404.html; rewrite ^/index.php/(.*) /$1 permanent; } location = /favicon.ico { # This never changes, so don't let it expire expires max; } location ^~ /theme { # This content should very rarely, if ever, change expires 1y; } listen [::]:443 ssl ipv6only=on; # managed by Certbot listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/uat.ryancheley.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/uat.ryancheley.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = uat.ryancheley.com) { return 301 https://$host$request_uri; } # managed by Certbot listen [::]:80; listen 80; server_name uat.ryancheley.com; return 404; # managed by Certbot } ---|--- The most interesting part of the code above is the `location` block from lines 6 - 11. location / { # Serve a .gz version if it exists gzip_static on; error_page 404 /404.html; rewrite ^/index.php/(.*) /$1 permanent; } ## Custom 404 Page error_page 404 /404.html; This line is what allows me to have a custom [404](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404) error page. If a page is not found `nginx` will serve up the html page `404.html` which is generated by a markdown file in my pages directory and looks like this: Title: Not Found Status: hidden Save_as: 404.html The requested item could not be located. I got this implementation idea from the [Pelican docs](https://docs.getpelican.com/en/4.6.0/tips.html?highlight=404#custom-404-pages). ## Rewrite rule for index.php in the URL rewrite ^/index.php/(.*) /$1 permanent; The rewrite line fixes the `index.php` challenge I mentioned in the [previous post](https://www.ryancheley.com/2021/07/02/migrating-to-pelican-from- wordpress/) It took me a _really_ long time to figure this out because the initial config file had a `location` block that looked like this: 1 2 3 4 5 | location = / { # Instead of handling the index, just # rewrite / to /index.html rewrite ^ /index.html; } ---|--- I didn't recognize the `location = / {` on line 1 as being different than the `location` block above starting at line 6. So I added rewrite ^/index.php/(.*) /$1 permanent; to that block and it NEVER worked because it never could. The `=` in the location block indicates a literal exact match, which the regular expression couldn't do because it's trying to be dynamic, but the `=` indicates static 🤦🏻♂️ OK, we've got a user, and we've got a configuration file, now all we need is a way to get the files to the server. I'll go over that in the next post. | 2021-07-05 | setting-up-the-server-to-host-pelican | # Creating the user on the server Each site on my server has it's own user. This is a security consideration, more than anything else. For this site, I used the steps from [some of my scripts for setting up a Django site](https://www.ryancheley.com/2021/02/21/automating-the-deployment/). In particular, I ran the following code from … | Setting up the Server to host my Pelican Site | https://www.ryancheley.com/2021/07/05/setting-up-the-server-to-host-pelican/ |