<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>server on {bjørn:johansen}</title>
    <link>https://bjornjohansen.com/category/server/</link>
    <description>Recent content in server on {bjørn:johansen}</description>
    <generator>Hugo -- 0.118.2</generator>
    <language>en-US</language>
    <lastBuildDate>Thu, 09 Aug 2018 18:12:42 +0000</lastBuildDate>
    <atom:link href="https://bjornjohansen.com/category/server/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Wildcard certificate from Let’s Encrypt with CloudFlare DNS</title>
      <link>https://bjornjohansen.com/wildcard-certificate-letsencrypt-cloudflare/</link>
      <pubDate>Thu, 09 Aug 2018 18:12:42 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:35613132-6563-5037-b565-393461623230</guid> 
      <description>If you’re using CloudFlare to host your DNS, there is a plugin for the official Let’s Encrypt client Certbot you can use to easily acquire and renew wildcard certificates from Let’s Encrypt.</description>
    </item>
    <item>
      <title>Automate the upgrade of your DigitalOcean droplets</title>
      <link>https://bjornjohansen.com/automate-the-upgrade-of-your-digitalocean-droplets/</link>
      <pubDate>Fri, 19 Jan 2018 01:27:59 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:39653564-3061-5663-b064-613763646366</guid> 
      <description>Recently DigitalOcean released &lt;a href=&#34;https://blog.digitalocean.com/new-droplet-plans/&#34;&gt;new pricing plans&lt;/a&gt; where they basically doubled the RAM for the same price of the old plans. But to get the benefits for your existing droplets, you have to upgrade all of your existing droplets in a process that involves shutting them down, selecting the new plan, waiting for the upgrade to happen and power on the droplets again. I have tens of droplets and had no intention of doing this manually, so I wrote a script to use the DigitalOcean API to automate a mass-upgrade of all droplets.</description>
    </item>
    <item>
      <title>How to do an Nginx redirect</title>
      <link>https://bjornjohansen.com/nginx-redirect/</link>
      <pubDate>Sat, 15 Oct 2016 13:45:01 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:61646133-3162-5634-a232-346265303235</guid> 
      <description>Nginx is an extremely efficient and quite flexible web server. When you want to do a redirect in Nginx, you have a few options to select from, so you can choose the one that suits you best to do an Nginx redirect.</description>
    </item>
    <item>
      <title>Restrict allowed HTTP methods in Nginx</title>
      <link>https://bjornjohansen.com/restrict-allowed-http-methods-in-nginx/</link>
      <pubDate>Wed, 21 Oct 2015 18:22:11 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:62313264-3030-5033-b530-326262653633</guid> 
      <description>&lt;p&gt;Security vulnerabilities are often exploits of software that fails when trying to deal with unexpected input. Other times they are exploits of a misconfiguration or a service that unintentionally was open to the public.&lt;/p&gt;
&lt;p&gt;For the above reasons, we should limit as much as possible what services are exposed to the public and limit as much as possible what they do and accept from the visitors. To follow those security principles, we should only allow the HTTP methods for which we, in fact, provide services. Under all normal circumstances, that would be the methods &lt;code&gt;GET&lt;/code&gt;, &lt;code&gt;POST&lt;/code&gt; and &lt;code&gt;HEAD&lt;/code&gt;.&lt;/p&gt;
</description>
    </item>
    <item>
      <title>Exclude certain requests from the Nginx access log</title>
      <link>https://bjornjohansen.com/exclude-requests-from-nginx-access-log/</link>
      <pubDate>Sun, 11 Oct 2015 14:33:03 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:32653466-6236-5261-b834-346164313439</guid> 
      <description>Logs are nice and all that, but sometimes certain entries are there just to fill up the logs or are cluttering them. Here’s a few ways to exclude requests – by URL or visitor IP – from the Nginx access log.</description>
    </item>
    <item>
      <title>Configure your local Postfix to relay through a transactional email service</title>
      <link>https://bjornjohansen.com/postfix-relay/</link>
      <pubDate>Fri, 09 Oct 2015 13:10:10 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:37343066-3030-5237-a131-646234366666</guid> 
      <description>Using Postfix with specialized, transactional email services like SendGrid or Mandrill is excellent for not only for optimizing email deliverability, but they usually also offer some nice features.</description>
    </item>
    <item>
      <title>Running PHP7-FPM Nightly Build on Ubuntu 14.04</title>
      <link>https://bjornjohansen.com/php7-fpm-nightly-build-on-ubuntu/</link>
      <pubDate>Tue, 14 Apr 2015 15:36:03 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:32623231-3337-5732-b734-663036336433</guid> 
      <description>As I’m writing this, the calendar shows April 14 2015. According to the &lt;a href=&#34;https://wiki.php.net/rfc/php7timeline&#34;&gt;PHP 7.0 timeline&lt;/a&gt;, it has a projected release date of November 2015. But if you want to try it out (to check out the speed), you can already do so.</description>
    </item>
    <item>
      <title>Running HHVM with fallback to PHP-FPM</title>
      <link>https://bjornjohansen.com/hhvm-with-fallback-to-php/</link>
      <pubDate>Wed, 03 Dec 2014 21:57:29 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:37333362-6639-5337-a638-343161393433</guid> 
      <description>HHVM can really speed up your PHP-based web site. Most reports are somewhere in the range of 2–4x faster. Unfortunately, HHVM isn’t very stable and will suddenly die, just of the blue, from time to another. Fortunately, if you’re running Nginx it’s really easy to set up PHP-FPM as a fallback.</description>
    </item>
    <item>
      <title>Using fail2ban from behind a Rackspace Cloud LoadBalancer</title>
      <link>https://bjornjohansen.com/fail2ban-rackspace-loadbalancer/</link>
      <pubDate>Fri, 07 Nov 2014 19:31:31 +0000</pubDate>
       <guid isPermaLink="false">urn:uuid:34343362-6565-5331-b461-373762623161</guid> 
      <description>If your fail2ban is on a host behind a Rackspace Cloud LoadBalancer, you’ll want to block the offending IP addresses directly in your LoadBalancer. If your LB is acting as a reverse proxy, you’ll HAVE to block in the LB, but it is also nice to protect all other nodes behind the LB and offload the lifting.</description>
    </item>
  </channel>
</rss>
