Emanuel Pina

Debian 11 Released

Sat, 14 Aug 2021 16:41:27 +0100

The most recent version of Debian, with the code name “Bullseye”, was released today!

Debian is one of oldest Linux distributions, notorious for been stable and reliable. Used as base for many other distributions. And a popular choice to run on servers.

Debian sees a new release each two years (more or less) and in conjunction with their Long Term Support team, they promise at least 5 years of extended support for the each stable release.

I was waiting with special anticipation for this release, after recently decided to stop relying on enterprise developed distributions.

I’ll now migrate my server from Ubuntu 20.04 to Debian 11 and, therefore, it was only logic that my first step should be update the tutorials on this blog. From the initial server setup, to install Nginx, PostgreSQL and PHP, and finally installing Nextcloud, all were updated to reflect the use of Debian 11.

My First Year With Linux on Desktop

Fri, 11 Jun 2021 15:49:08 +0100

A year ago, after a couple months of head scratching and intense distro hopping, I settled with Manjaro with Gnome. But it didn’t take long for another Arch based project get my attention!

With their motto “a terminal-centric distro with a vibrant and friendly community at its core”, EndeavourOS sounded perfect.

First, as I began my journey with Linux on the server side, terminal is my natural choice to manage things. And more, EndeavourOS promised: a lean installation, close to a vanilla Arch experience; a user-friendly installer, with a dozen options between desktop environments and windows managers; and a great community.

I took my time with Manjaro, but a couple of months later I moved to EndeavourOS, and it didn’t disappoint! It was my home for months. First with Gnome, but mostly with KDE Plasma.

After my initial choice of Gnome, I got bored and decided to give Plasma another shot. At first it felt bloated with its large array of settings and customisation options. I had to fight that initial overwhelm feeling and increase my understanding of those settings to get my way with it.

KDE Plasma is powerful, pleasant and fulfilled my needs. But with the changes and hype around the release of Gnome 40, I couldn’t resist getting back to it.

At the end, I think the look and feel of Gnome is more at my taste. Although, to be honest I cannot point a distinct favourite. They’re both capable desktop environments that I can adapt to my workflow.

By the time I made plans to get back to Gnome, with the knowledge I acquired over the year, I felt that moving to Arch Linux would be a natural step. And so I did!

Meanwhile, I looked for a distro that I could install on my parents laptop. Something with a fixed release model, that I could forget for a few months. I tested Fedora, Elementary and Zorin, but my favourite keeps being Linux Mint. One can agree or not with their view about Snaps and its implementation on Ubuntu (I do!). But is indisputable the great work they keep doing, putting together a stable, predictable and user-friendly distro.

From the events of last year, there was one that made me think the most. The refocus of CentOS. I didn’t use CentOS or any distro from Red Hat, but was alarming seeing how much people/business relied on a project that an enterprise could change/end with the snap-of-a-finger.

I recognise the importance of those enterprises on the development and adoption of Linux, and I’m not against the use of their products. But keep in mind that enterprises will always behave according to its interests. So, if you rely on an enterprise developed product, have a backup plan.

Personally, I plan to migrate my server to Debian 11 once it’s released.

Furthermore, I hope Linux Mint keeps developing a version based on Debian instead of Ubuntu. And would like to see other projects, such as Zorin and Elementary, replicate that same strategy.

Using Hetzner to Self Host Nextcloud

Tue, 22 Sep 2020 20:10:39 +0100

This is a brief, but long owed post.

Last year, I decided that the best path to claim ownership of my data was self-hosting Nextcloud.¹ I faced some issues using Hetzner’s 1 vCPU plan and I convinced myself that the culprit was their vCPU not being powerful enough.²

If it’s true that their vCPU wasn’t as powerful as Vultr’s one. It’s also true that with the right know-how I would be able to debug the issue and make things work. The culprit was in fact my lack of knowledge.

So, what changed? I just learned how to tune PHP³ and PostgreSQL⁴ according to the server resources. That’s it!

That settled, I end up moving to Hetzner at the beginning of this year. Currently, on a 1 vCPU VPS (that costs €2.49/month), I’m hosting Nextcloud, Drone CI, Miniflux, MailyGo and this blog without issues. In the future, if I see myself in need of more CPU power, I can easy rescale the VPS to an optimized for CPU plan (based on AMD EPYC 2nd Gen processors) with 2 vCPU for €3.49/month. Which is still cheaper than the Vultr’s 1 vCPU plan.

If you’re looking for a VPS in Europe, give Hetzner a try. They have datacenters in Germany (Nuremberg and Falkenstein) and Finland (Helsinki). You can use my referral link to get €20 in credits. For full disclosure, if you choose to stick with them and after you spend €10, I receive €10 in credits.⁵

Handle HTML Forms Through Email With MailyGo

Thu, 30 Jul 2020 22:28:28 +0100

You may have already notice the contact form on this blog. Until recently, it was handled by Netlify and used a serverless function to send an email both to me and the submitter. This worked fine, but was far from ideal because I had to trust the data to a third party (Netlify).

As I was already running a server (with Nextcloud and Mastodon), I looked for a self-hosted solution and found MailyGo from Jan-Lukas Else. A small tool written in Go that allows send HTML forms through email. Exactly what I was looking for!

I just needed to tailor it a little bit to my use case. A good challenge as this was my first time working with Go. Keep that in mind and be kind when you review my code, please!

So, there’s the list of changes I made:

Fighting Spam

When a form is placed online it’s a matter of time until it get some bots’ attention and being targeted with spam. To fight it, the original version of MailyGo already used an honeypot field, a spamlist and integrated Google Safe Browsing to check URLs. And that seemed enough.

But I didn’t want to use any third party, even less Google! And unfortunately the honeypot field and spamlist alone shown insufficient.

I got some bots sending a particular field (submit) that wasn’t part of the form. And so, I created a denylist, a list of fields names that MailyGo will look for and, if present, mark the submission as spam.

I too got bots that grabbed the URL of MailyGo and posted a submission directly to it, bypassing the form. To prevent this, I created the ability to use a token to assure only the submissions that come from the form are handle by MailyGo. This token can be any combination of letters and numbers. If a TOKEN is defined on configuration, MailyGo will look for a field named _token. If this field doesn’t exist or its value doesn’t match the one defined on configuration the submission will be marked as spam.

I’m using this set of solutions for more than a week now with zero spam. Seems enough. At least for now!

An that’s it, my fork of MailyGo!

A big thanks to Jan-Lukas Else. Follow his blog and know more of his projects.

Getting Started With Linux on Desktop

Wed, 24 Jun 2020 19:46:29 +0100

At the beginning of March, I bought a laptop and decided to finally embrace Linux as my daily drive desktop. Till that day I had only used Linux, more precisely Ubuntu, on servers. So, obviously it was my first choice, but I faced a lot of issues, just to find out that the 3rd generation AMD Ryzen CPU on my laptop wasn’t yet supported by the kernel version (5.3) used on Ubuntu 19.10. I wasn’t able to use any Ubuntu based distro. At first it sucked, but now I’m glad that happen!

I then saw myself digging the Linux world to find a solution for me. I met and tried different distros and desktop environments. I saw dozens of videos, heard hours of podcasts, read a bunch of wikis, learned a lot and found a supportive community. There were moments of frustration, where I get paralyzed by indecision in the middle of so many choices. But that’s one of the beauties of Linux, right! You always have multiple choices and paths you can follow to tailor made your experience.

After almost two months of distro hopping, I finally settled with Manjaro. A rolling release, based on Arch Linux and so more up-to-date and compatible with the AUR (Arch Linux User Repository). From the ones I tried, I kept others distros in a shortlist of favorites, like Solus and Fedora, but at the end of the day I always started missing AUR!

Talking about desktop environments, I’m using Gnome. It’s not perfect and I spent some time exploring XFCE and KDE too, but I still prefer the look and feel of Gnome. Well, to be honest, so far my favorite DE is Budgie, but feels like its development is somehow on idle, limited to bugfixes. Which is understanding because the Solus’ team (who too develop Budgie) is small and have already a lot on their plate maintaining Solus.

I have yet to explore window managers like i3 and so many other things that I don’t know exists yet!

Any suggestion?

GoatCounter

Wed, 08 Apr 2020 10:35:32 +0100

Although page views aren’t my immediate concern when I write on this blog, is good to know if someone is reading what I share! But when doing it I wanted to assure that I wasn’t tracking you. In others words, that the data gathered couldn’t identify or being associated to you. To do so I started by using the self-hosted version of Fathom.

Unfortunately, some time ago the developers of Fathom decided change their business model. They developed a new version of Fathom, closed source, only for paid customers, named Fathom PRO and renamed the original Fathom as Fathom Lite. Since then the development of this first version seems to had come to an end, as its latest release is from November 2018.

I then started looking for alternatives and that’s when I found this discussion on Lobsters and met GoatCounter. A recent project of an open source and privacy-aware web statistics platform.

As its developer states:

No personal information (such as IP address) is collected; a hash of the IP address, User-Agent, and a daily changing random number (“salt”) is stored for 24 hours at the most to identify unique visitors.

There is no information stored in the browser with e.g. cookies. ¹

So what data does GoatCounter collect?

URL of the visited page;
Referer header;
User-Agent header;
Screen size;
Country name based on IP address;
A hash of the IP address, User-Agent, and random number.

The script that by default you need to add to your site so GoatCounter can do its job is lightweight (~1.5kB), and there’s a no-JavaScript image-based tracker option, or you can use it from your application’s middleware.

There’s an hosted version of GoatCounter that includes a free plan for non-commercial use or you can host it yourself. In either case, if you’re going to use it for free, don’t forget to, as you can, donate to the developer so he can pay his bills and continue support this project.

The issues tracking is done on GitHub and you can join the project’s Telegram group.

GoatCounter privacy policy ↩︎

Nextcloud 27 Installation on Debian

Sun, 23 Jul 2023 17:34:51 +0100

Finally, I’ll now cover the installation of Nextcloud on Debian!

At this point, is expected that you already had:

Choose a VPS provider and concluded the initial setup of your Debian server;
Installed Nginx;
Installed PostgreSQL;
Installed PHP 8.2.

I’m currently using Debian 12, but these instructions may be equally valid for other versions of Debian and Ubuntu.

Download Nextcloud 27

To download Nextcloud 27, change into the /tmp folder, to keep things clean, and use wget to download the archive:

# cd /tmp
# wget https://download.nextcloud.com/server/releases/latest.zip

With the archive downloaded, now unzip it. We’ll also attempt to install unzip, in case we don’t have it installed already. The -d switch specifies the target directory, so the archive will be extracted to /var/www/nextcloud:

# sudo apt install unzip
# sudo unzip latest.zip -d /var/www

Now we’ll have to change the owner of /var/www/nextcloud so Nginx can write to it:

# sudo chown www-data:www-data /var/www/nextcloud -R

Install PHP Required Modules

Beyond the ones we installed previously, Nextcloud requires some additional PHP modules. To install them, run the following command:

# sudo apt install php8.2-curl php8.2-gd php8.2-mbstring php8.2-xml php8.2-zip php8.2-bz2 php8.2-intl php8.2-ldap php8.2-imap php8.2-bcmath php8.2-gmp php8.2-imagick

Configure PHP

To meet the requirements of Nextcloud we need to make some changes in PHP configuration. The first one is changing the memory_limit. This setting is in php.ini, we can edit it running:

# sudo nano /etc/php/8.2/fpm/php.ini

Search for memory_limit and change it to 512M.

Once we’re editing php.ini you can take the opportunity to set upload_max_filesize and post_max_size according to your preferences.

Another thing is that as we’re using php-fpm, system environment variables like PATH, TMP or others are not automatically populated. A PHP call like getenv('PATH'); can therefore return an empty result. So we need to manually configure the environment variables in www.conf. To edit this file run:

# sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Usually, near the bottom of the file, we will find some or all of the environment variables already, but commented out like this:

;env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
;env[TMP] = /tmp
;env[TMPDIR] = /tmp
;env[TEMP] = /tmp

Just uncomment the ones that refer to PATH and TMP, like this:

...
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
...

With this changes done, restart the PHP service:

# sudo systemctl restart php8.2-fpm

Create PostgreSQL User and Database

To create a user and database for Nextcloud we first need to login to PostgreSQL prompt:

# sudo -i -u postgres psql

Then create a username (choose a username and password according to your preferences):

CREATE USER username WITH PASSWORD 'password' CREATEDB;

Create a database:

CREATE DATABASE nextcloud TEMPLATE template0 ENCODING 'UTF8';

Set the user you created as the owner of the database:

ALTER DATABASE nextcloud OWNER TO username;

Grant the user all the privileges over the database:

GRANT ALL PRIVILEGES ON DATABASE nextcloud TO username;
GRANT ALL PRIVILEGES ON SCHEMA public TO username;

To quit the PostgreSQL prompt, run:

\q

Configure Nginx

We’ll now create a Nginx server block to nextcloud. I’m naming it nextcloud but you can name it whatever you like:

# sudo nano /etc/nginx/sites-available/nextcloud

Copy the following content to the file and change the server_name from box.emanuelpina.pt to the domain address you want use:

server {
 listen 80;
 listen [::]:80;
 server_name box.emanuelpina.pt;
}

Save and close the file when you’re done.

Once created, to enable the server block we need to create a symbolic link of it into /etc/nginx/sites-enabled/ using the following command:

# sudo ln -s /etc/nginx/sites-available/nextcloud /etc/nginx/sites-enabled/

Make sure that there are no syntax errors in the Nginx files:

# sudo nginx -t

If there aren’t any issues, restart Nginx to enable the changes:

# sudo systemctl reload nginx

Enable SSL

We can use certbot to obtain a Let’s Encrypt SSL certificate to our Nextcloud. If you didn’t already, install it as its Nginx package running the following command:

# sudo apt install certbot python3-certbot-nginx

Then to use Certbot, run:

# sudo certbot --nginx

At our first time running Certbot, we’ll be prompted to enter an email address, agree to the terms of service and authorise or not EEF (the entity that mantains Certbot) to send emails to us.

We’ll then be presented with a list of all domains enabled on our server:

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: box.emanuelpina.pt
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

Select the appropriate number for the domain you want to obtain a certificate (for our example type 1) and press ENTER. After doing so, Certbot will communicate with the Let’s Encrypt server, then run a challenge to verify that we control the domain we’re requesting a certificate for.

If that’s successful, Certbot will finish with a message like below. Look at IMPORTANT NOTES and save the locations of both the certificate and key.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://box.emanuelpina.pt
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
 /etc/letsencrypt/live/box.emanuelpina.pt/fullchain.pem
 Your key file has been saved at:
 /etc/letsencrypt/live/box.emanuelpina.pt/privkey.pem
...

Now, edit the Nextcloud’s server block:

# sudo nano /etc/nginx/sites-available/nextcloud

And replace its content with the following code. Don’t forget to change the server_name from box.emanuelpina.ml to the domain address you want and update the locations to the SSL certificate and key:

upstream php-handler {
 #server 127.0.0.1:9000;
 server unix:/var/run/php/php8.2-fpm.sock;
}

# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
 "" "";
 default "immutable";
}

server {
 listen 80;
 listen [::]:80;
 server_name box.emanuelpina.ml;

 # Prevent nginx HTTP Server Detection
 server_tokens off;

 # Enforce HTTPS
 return 301 https://$server_name$request_uri;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name box.emanuelpina.ml;

 # Path to the root of your installation
 root /var/www/nextcloud;

 ssl_certificate /etc/letsencrypt/live/box.emanuelpina.ml/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/box.emanuelpina.ml/privkey.pem;

 # Prevent nginx HTTP Server Detection
 server_tokens off;

 # HSTS settings
 # WARNING: Only add the preload option once you read about
 # the consequences in https://hstspreload.org/. This option
 # will add the domain to a hardcoded list that is shipped
 # in all major browsers and getting removed from this list
 # could take several months.
 add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;

 # set max upload size and increase upload timeout:
 client_max_body_size 512M;
 client_body_timeout 300s;
 fastcgi_buffers 64 4K;

 # Enable gzip but do not remove ETag headers
 gzip on;
 gzip_vary on;
 gzip_comp_level 4;
 gzip_min_length 256;
 gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
 gzip_types application/atom+xml text/javascript application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/wasm application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

 # Pagespeed is not supported by Nextcloud, so if your server is built
 # with the `ngx_pagespeed` module, uncomment this line to disable it.
 #pagespeed off;

 # The settings allows you to optimize the HTTP2 bandwitdth.
 # See https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/
 # for tunning hints
 client_body_buffer_size 512k;

 # HTTP response headers borrowed from Nextcloud `.htaccess`
 add_header Referrer-Policy "no-referrer" always;
 add_header X-Content-Type-Options "nosniff" always;
 add_header X-Download-Options "noopen" always;
 add_header X-Frame-Options "SAMEORIGIN" always;
 add_header X-Permitted-Cross-Domain-Policies "none" always;
 add_header X-Robots-Tag "noindex, nofollow" always;
 add_header X-XSS-Protection "1; mode=block" always;

 # Opt out of Google Chrome tracking everything you do.
 # Note: if you’re reading this, stop using Google Chrome.
 # It is ridiculous for web servers to essentially have to ask
 # “please do not violate the privacy of the people who are viewing
 # this site” with every request.
 # For more info, see: https://plausible.io/blog/google-floc
 add_header Permissions-Policy "interest-cohort=()" always;

 # Remove X-Powered-By, which is an information leak
 fastcgi_hide_header X-Powered-By;

 # Add .mjs as a file extension for javascript
 # Either include it in the default mime.types list
 # or include you can include that list explicitly and add the file extension
 # only for Nextcloud like below:
 include mime.types;
 types {
 text/javascript js mjs;
 }

 # Specify how to handle directories -- specifying `/index.php$request_uri`
 # here as the fallback means that Nginx always exhibits the desired behaviour
 # when a client requests a path that corresponds to a directory that exists
 # on the server. In particular, if that directory contains an index.php file,
 # that file is correctly served; if it doesn't, then the request is passed to
 # the front-end controller. This consistent behaviour means that we don't need
 # to specify custom rules for certain paths (e.g. images and other assets,
 # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
 # `try_files $uri $uri/ /index.php$request_uri`
 # always provides the desired behaviour.
 index index.php index.html /index.php$request_uri;

 # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
 location = / {
 if ( $http_user_agent ~ ^DavClnt ) {
 return 302 /remote.php/webdav/$is_args$args;
 }
 }

 location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

 # Make a regex exception for `/.well-known` so that clients can still
 # access it despite the existence of the regex rule
 # `location ~ /(\.|autotest|...)` which would otherwise handle requests
 # for `/.well-known`.
 location ^~ /.well-known {
 # The rules in this block are an adaptation of the rules
 # in `.htaccess` that concern `/.well-known`.

 location = /.well-known/carddav { return 301 /remote.php/dav/; }
 location = /.well-known/caldav { return 301 /remote.php/dav/; }

 location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
 location /.well-known/pki-validation { try_files $uri $uri/ =404; }

 # Let Nextcloud's API for `/.well-known` URIs handle all other
 # requests by passing them to the front-end controller.
 return 301 /index.php$request_uri;
 }

 # Rules borrowed from `.htaccess` to hide certain paths from clients
 location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
 location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }

 # Ensure this block, which passes PHP files to the PHP process, is above the blocks
 # which handle static assets (as seen below). If this block is not declared first,
 # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
 # to the URI, resulting in a HTTP 500 error response.
 location ~ \.php(?:$|/) {
 # Required for legacy support
 rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$request_uri;

 fastcgi_split_path_info ^(.+?\.php)(/.*)$;
 set $path_info $fastcgi_path_info;

 try_files $fastcgi_script_name =404;

 include fastcgi_params;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_param PATH_INFO $path_info;
 fastcgi_param HTTPS on;

 fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
 fastcgi_param front_controller_active true; # Enable pretty urls
 fastcgi_pass php-handler;

 fastcgi_intercept_errors on;
 fastcgi_request_buffering off;

 fastcgi_max_temp_file_size 0;
 }

 location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
 try_files $uri /index.php$request_uri;
 add_header Cache-Control "public, max-age=15778463, $asset_immutable";
 access_log off; # Optional: Don't log access to assets

 location ~ \.wasm$ {
 default_type application/wasm;
 }
 }

 location ~ \.woff2?$ {
 try_files $uri /index.php$request_uri;
 expires 7d; # Cache-Control policy borrowed from `.htaccess`
 access_log off; # Optional: Don't log access to assets
 }

 # Rule borrowed from `.htaccess`
 location /remote {
 return 301 /remote.php$request_uri;
 }

 location / {
 try_files $uri $uri/ /index.php$request_uri;
 }
}

Make sure that there are no syntax errors in the Nginx files:

# sudo nginx -t

If there aren’t any issues, restart Nginx to enable the changes:

# sudo systemctl reload nginx

Complete Installation

Now, to complete Nextcloud installation, in a browser visit the domain address you chosed and you will be presented with a form to fill.

On this form on “Create an admin account” we should chose a username and password for our admin account. And on “Configure Database” we should fill it with the username, password and database name defined above.

After filling the form just click on Finish setup and wait for the installation to complete. At the end we’ll be redirected to our dashboard.

And that’s it! Our Nextcloud installation is ready for use.

Additional configurations

Following we’ll look at some additional configurations that despite being optional, are advisable.

Memory Caching

Enabling memory caching can significantly improve the perfomance of your Nextcloud. The recommend solutions to implement should be based on the size and propose of our Nextcloud. For a small instance with a single server the recommended configuration is APCu for local memcache and Redis for everything else:¹

APCu: an in-memory key-value store for PHP;
Redis: an excellent modern memcache to use for distributed caching, and as a key-value store for Transactional File Locking.

To install APCu, go back to your terminal and run the following commands:

# sudo apt install php8.2-apcu

APCu is disabled by default on CLI which could cause issues with Nextcloud’s cron jobs. Make sure to set apc.enable_cli to 1 on /etc/php/8.2/cli/php.ini or append --define apc.enable_cli=1 to the cron job command.

And to install Redis, run:

# sudo apt install redis-server php8.2-redis

Then restart Nginx:

# sudo systemctl reload nginx

Now we need to configure Nextcloud to use both APCu and Redis. To do so let’s edit the Nextcloud configuration file:

# sudo nano /var/www/nextcloud/config/config.php

And add the following lines just bellow 'installed' => true,:

'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'memcache.distributed' => '\OC\Memcache\Redis',
'redis' => [
 'host' => 'localhost',
 'port' => 6379,
],

Background jobs

A system like Nextcloud sometimes requires tasks to be done on a regular basis without the need for user interaction or hindering Nextcloud performance. For that purpose, we can define background jobs. These jobs are typically referred to as cron jobs.

Cron jobs are commands or shell-based scripts that are scheduled to run periodically at fixed times, dates, or intervals. cron.php is a Nextcloud internal process that runs such background jobs on demand.

We can schedule cron jobs in three ways – using AJAX, Webcron, or cron. The default method is to use AJAX. However, the recommended method is to use the operating system cron feature.²

To run a cron job on our system, every 5 minutes, under the default Web server user, we must set up the following cron job to call the cron.php script.

Edit the crontab of the default Web server user (www-data):

# sudo crontab -u www-data -e

And append the following line, replacing the path /var/www/nextcloud/cron.php with the path to your current Nextcloud installation:

*/5 * * * * php -f /var/www/nextcloud/cron.php

We can verify if the cron job has been added and scheduled running:

# sudo crontab -u www-data -l

Finally, choose Cron in the Background jobs section of the Admin settings page at Setting > Administration > Basic settings > Background jobs.

Previews generation

By default, Nextcloud thumbnail system generates previews of files for the following filetypes:

Images files;
Cover of MP3 files;
Text documents.

Additional, we can add support for SVG and video files, installing those packages:

# sudo apt install libmagickcore-6.q16-6-extra ffmpeg

To add support for PDF files, we must install ghostscript:

# sudo apt install ghostscript

And tweak ImageMagick’s security policy:

# sudo nano /etc/ImageMagick-6/policy.xml

Look for <policy domain="coder" rights="none" pattern="PDF" /> at the end of the file. And comment the line, so it look like:

...
<!-- <policy domain="coder" rights="none" pattern="PDF" /> -->
...

The generation of previews can use a fair amount of hardware resources and can degrade our experience when using Nextcloud. We can prevent that, using an app called Preview Generator and setting a cron job that runs periodically on the background and generates previews for new or recently changed files.

To do so, first run the following commands to install and enable the app, where /var/www/nextcloud/ is the path to our Nextcloud installation:

# sudo -u www-data php /var/www/nextcloud/occ app:install previewgenerator
# sudo -u www-data php /var/www/nextcloud/occ app:enable previewgenerator

To set for which filetypes Nextcloud should generate previews, edit the Nextcloud configuration file:

# sudo nano /var/www/nextcloud/config/config.php

And add the following lines just bellow 'installed' => true,:

'enable_previews' => true,
'enabledPreviewProviders' =>
array (
 0 => 'OC\\Preview\\PNG',
 1 => 'OC\\Preview\\JPEG',
 2 => 'OC\\Preview\\GIF',
 3 => 'OC\\Preview\\HEIC',
 4 => 'OC\\Preview\\BMP',
 5 => 'OC\\Preview\\XBitmap',
 6 => 'OC\\Preview\\MP3',
 7 => 'OC\\Preview\\TXT',
 8 => 'OC\\Preview\\MarkDown',
 9 => 'OC\\Preview\\Movie',
 10 => 'OC\\Preview\\MKV',
 11 => 'OC\\Preview\\MP4',
 12 => 'OC\\Preview\\AVI',
 13 => 'OC\\Preview\\PDF',
),

Then, before setting a cron job, we should generate all previews running:

# sudo -u www-data php /var/www/nextcloud/occ preview:generate-all -vvv

We can now edit the crontab of the default Web server user (www-data):

# sudo crontab -u www-data -e

And add a cron job that will run the application each 10 minutes:

*/10 * * * * php /var/www/nextcloud/occ preview:pre-generate

Email

Nextcloud is capable of sending password reset emails, notifying users of new file shares, changes in files, and activity notifications.

Nextcloud does not contain a full email server, but rather connects to your existing mail server, and supports three types of connections: SMTP, qmail, and Sendmail.

I recommend using a SMTP server, more precisely a SMTP relay, like Mailgun.

To connect Nextcloud to a remote SMTP server, we need the following information:

Encryption type: None, SSL/TLS, or STARTTLS;
The From address we want our outgoing Nextcloud mails to use;
Whether authentication is required;
Authentication method: None, Login, Plain, or NT LAN Manager;
The server’s IP address or fully-qualified domain name and the SMTP port;
Login credentials (if required).

Having this information we can then fill the configuration wizzard in the Email Server section of the Admin settings page at Setting > Administration > Basic settings > Email server.

Default phone region

Since Nextcloud 21, is recommend setting a default region for phone numbers, using ISO 3166-1 country codes such as DE for Germany, FR for France, PT for Portugal… It is required to allow inserting phone numbers in the user profiles starting without the country code (e.g. +351 for Portugal).

We can do that by editing the Nextcloud configuration file:

# sudo nano /var/www/nextcloud/config/config.php

And adding the following line, just bellow 'installed' => true,, changing the value to correspond to your country:

'default_phone_region' => 'PT',

Congratulations 🎉

You now have your self-hosted cloud storage solution and are one step closer to be the owner of your data!

Do you want contribute and add something to this tutorial? Have you found a typo, grammar or formatting error? Please, feel free to contact me or edit this post and open a pull resquest.

PHP Installation on Debian

Thu, 23 Jan 2020 18:52:25 +0000

On the way to install Nextcloud we’ve already completed the initial setup of our VPS, the installation of Nginx and the installation of PostgreSQL.

I will now cover the installation of PHP 8.2, the recommended version to run Nextcloud 27.¹

I’m currently using Debian 12, but these instructions may be equally valid for other versions of Debian and Ubuntu.

Install PHP

PHP (recursive acronym for PHP: Hypertext Preprocessor) is an open source server side scripting language, widely used to create dynamic interactive web pages.

To install PHP 8.2 along with some of it most common extensions use the following commands:

# sudo apt update
# sudo apt install php8.2 php8.2-common php8.2-fpm php8.2-pgsql

And that’s it. At any moment you can check the PHP 8.2 service status running:

# systemctl status php8.2-fpm

Test PHP Processing

To test PHP Processing we first need to configure Nginx to use it for dynamic content.

This is done at the server block level. For this example edit the server block we’ve created earlier. To do so, run:

# sudo nano /etc/nginx/sites-available/emanuelpina.pt

And edit the server block to add the following code, just bellow the server_name. Like this:

server {
 ###

 server_name emanuelpina.pt www.emanuelpina.pt;

 location ~ \.php$ {
 include snippets/fastcgi-php.conf;
 fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
 }

 ###
}

Test to make sure that there are no syntax errors in our Nginx files:

# sudo nginx -t

If there aren’t any issues, restart Nginx to enable the changes:

# sudo systemctl reload nginx

Now let’s create a test PHP file in the website root folder:

# sudo nano /var/www/html/info.php

Add the following content to the file, which is a valid PHP code that generates a page containing information about the server:

<?php
phpinfo();

Now visiting the page https://emanuelpina.pt/info.php on a browser we should see a page generated by PHP containing structured information about our server.

If you see this page then Nginx is successfully communicating with PHP!

At the end of this test, don’t forget to remove the PHP file we created:

# sudo rm /var/www/html/info.php

This is imporant because it exposes important information about our server and can make it vulnerable.

Tune PHP

Similar to what we did with PostgreSQL, we can tune some PHP settings depending on the hardware at our disposale.²

To proceed with this we need to know three things: how many CPU cores our server have; how much memory (RAM) we can dedicate to PHP; and how much memory the average PHP process consume.

To find out how many CPU cores your server has, run the following command:

# echo Cores = $(( $(lscpu | awk '/^Socket/{ print $2 }') * $(lscpu | awk '/^Core/{ print $4 }') ))

When determining how much memory you can dedicate to PHP, keep in mind that the server is also running Nginx and PostgreSQL. How much memory are these other processes consuming? For example, if you have 4GB of RAM and the other processes are consuming 1GB, that leaves you with 3GB – or 2GB if you want to play safe.

Finally, to get a general idea on how much memory each PHP process is consuming, run:

# ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

The settigns you need to change are all in the www.conf file. To edit it, run:

# sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Search for each one of the following settings and change it accordingly.

To get a good value for pm.max_children, take the memory that you want to allocate to PHP and divide it by the average memory that is consumed by each PHP process. For example, if you want to allocate 2GB (2000MB) and each process consumes about 50MB. Dividing 2000 by 50 we get around 40.
So, set pm.max_children to 40.

For pm.start_servers, multiply the number of cores that you have by 4.
If you have 2 cores: 2 x 4 = 8
So, set pm.start_servers to 8.

For pm.min_spare_servers, multiply the number of cores that you have by 2.
If you have 2 cores: 2 x 2 = 4
So, set pm.min_spare_servers to 4.

For pm.max_spare_servers, multiply the number of cores on your server by 4.
If you have 2 cores: 2 x 4 = 8
So, set pm.max_spare_servers to 8. The same used before for pm.start_servers.

To finish, just restart the PHP-FPM service:

# sudo systemctl restart php8.2-fpm

And that’s all 😀

What’s next?

With Nginx, PostgreSQL and PHP up and running we’re now ready to install Nextcloud!

Do you want contribute and add something to this tutorial? Have you found a typo, grammar or formatting error? Please, feel free to contact me or edit this post and open a pull resquest.

PostgreSQL Installation on Debian

Sat, 21 Dec 2019 11:12:04 +0000

On the way to install Nextcloud we’ve already completed the initial setup of our VPS and the installation of a webserver (Nginx).

We’ll now proceed with the installation of PostgreSQL, a relational database management system.

I’m currently using Debian 12, but these instructions may be equally valid for other versions of Debian and Ubuntu.

Why PostgreSQL

PostgreSQL isn’t the obvious choice to use with Nextcloud. In fact, the officially recommended database management system by Nextcloud is MySQL or MariaDB.¹

I choosed PostgreSQL mainly because I planned to run other applications, in the same server, that are only compatible with it. My goal was to have a simple as possible setup, avoiding run multiple database systems simultaneously.

Either way, PostgreSQL has its advantages like an extensive SQL compliance, data integrity and being open source and community driven.

But maybe it isn’t the right choice for you and for a more informed decision you can, for example, read this comparison between SQLite vs MySQL vs PostgreSQL. I found it really usefull.

Install PostgreSQL

Debian’s default repositories contain PostgreSQL packages, so we can install these using the apt packaging system.

First, refresh the local package index:

# sudo apt update

Then, install the PostgreSQL package along with a -contrib package that adds some additional utilities and functionality:

# sudo apt install postgresql postgresql-contrib

To learn the basics about using PostgreSQL you can start by reading this tutorial on Digital Ocean.

Tune PostgreSQL

One of the downsides of PostgreSQL is its memory performance, so besides optional is highly recommended tune its settings depending on the hardware at your disposale.

To do so, we can visit PGTune, fill the form with our system informations and get a list of settings to add/modify in postgresql.conf. This file can be found in /etc/postgresql/<version_number>/main folder. In my case, as I’m using the version 13 of PostgreSQL, I use the following command to edit it:

# sudo nano /etc/postgresql/15/main/postgresql.conf

Then is a matter of search for each one of the parameters in the list and modify or add it to match the values generated by PGTune.

Save the changes and just restart the PostgreSQL service:

# sudo systemctl restart postgresql

What’s next?

Now that we’ve installed a webserver and a database management system, all that’s missing so we can install Nextcloud is PHP.

Do you want contribute and add something to this tutorial? Have you found a typo, grammar or formatting error? Please, feel free to contact me or edit this post and open a pull resquest.

Nextcloud system requirements ↩︎

Nginx Installation on Debian

Sat, 05 Oct 2019 03:45:57 +0100

This is the second post on the road to self-host Nextcloud. At this point we have already choosed a provider and deployed a VPS and completed its initial setup.

Now, we’re going to cover the installation of Nginx, the use of Let’s Encrypt SSL certificates and the configuration of the web server to use HTTP Strict Transport Security (HSTS).

I’m currently using Debian 12, but these instructions may be equally valid for other versions of Debian and Ubuntu.

Install Nginx

First, let’s update the package lists from the repositories:

# sudo apt update

Then, install Nginx:

# sudo apt install nginx

We can check if it’s working by running:

# sudo systemctl status nginx

If all went well, we should get something like this:

● nginx.service - A high performance web server and a reverse proxy server
 Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
 Active: active (running) since Sun 2023-07-23 16:43:52 UTC; 1min 17s ago
 Docs: man:nginx(8)
 Process: 2471 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Process: 2472 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 2495 (nginx)
 Tasks: 2 (limit: 2251)
 Memory: 1.8M
 CPU: 25ms
 CGroup: /system.slice/nginx.service
 ├─2495 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
 └─2496 "nginx: worker process"

Adjust the Firewall

Before using Nginx, the firewall needs to be adjusted to allow access to the service. Nginx registers itself as a service with UFW upon installation, making it straightforward to allow Nginx access.

List the application configurations that UFW knows how to work with by typing:

# sudo ufw app list

We get a listing of the application profiles, like this:

Available applications:
 ...
 Nginx Full
 Nginx HTTP
 Nginx HTTPS
 ...

There are three profiles available for Nginx:

Nginx Full: This profile opens both port 80 (normal, unencrypted web traffic) and port 443 (TLS/SSL encrypted traffic);
Nginx HTTP: This profile opens only port 80 (normal, unencrypted web traffic);
Nginx HTTPS: This profile opens only port 443 (TLS/SSL encrypted traffic).

We plan to use TLS/SSL so choose the profile Nginx Full to open both ports:

# sudo ufw allow 'Nginx Full'

Visiting our IP address on a browser will now show the Nginx’s default page, like bellow.

Set Up a Server Block

When using the Nginx web server, server blocks can be used to encapsulate configuration details and host more than one domain from a single server. We will set up a domain called emanuelpina.ml, but you should replace this with your own domain name.

On this example the content of our site will be stored in the folder /var/www/html, change this to match your preferences.

Let’s create a index.html file for our site using Nano or use your favorite editor:

# sudo nano /var/www/html/index.html

Add the following HTML to the file:

<html>
 <head>
 <title>Welcome to EmanuelPina.pt!</title>
 </head>
 <body>
 <h1>Hello World!</h1>
 <p><b>The emanuelpina.pt server block is working!</b></p>
 </body>
</html>

Save and close the file when you’re finished.

In order for Nginx to serve this content, we need to create a server block with the correct directives. Instead of modifying the default configuration file directly, let’s make a new one. We’ll name it emanuelpina.pt but you can name it whatever you like:

# sudo nano /etc/nginx/sites-available/emanuelpina.pt

Paste in the following configuration block, which is similar to the default, but updated for our new directory and domain name:

server {
 listen 80;
 listen [::]:80;

 root /var/www/html;
 index index.html index.htm index.nginx-debian.html;

 server_name emanuelpina.pt www.emanuelpina.pt;

 location / {
 try_files $uri $uri/ =404;
 }
}

Notice that we’ve updated the root configuration to our site directory, and the server_name to our domain name.

Next, let’s enable the site by creating a link from this file to the sites-enabled directory, which Nginx reads from during startup:

# sudo ln -s /etc/nginx/sites-available/emanuelpina.pt /etc/nginx/sites-enabled/

Then, test to make sure that there are no syntax errors in the Nginx files:

# sudo nginx -t

If there aren’t any problems, restart Nginx to enable the changes:

# sudo systemctl reload nginx

Visiting our domain address on a browser will now show the content of the index.html file we’ve created.

Enable SSL

At this point we have set Nginx to serve our site, but notice that the browser is connecting to the server through a unencrypted/non-secure connection.

To enable the browser to use a encrypted/secure connection we’ve to install an SSL certificate. We can obtain a free SSL certificate using Let’s Encrypt. To easily do this we can use a open source software called Certbot. To install Certbot and its Nginx package run the following command:

# sudo apt install certbot python3-certbot-nginx

We can now use Certbot to obtaining an SSL certificate typing:

# sudo certbot --nginx

At first time we run Certbot, we’ll be prompted to enter an email address, agree to the terms of service and authorise or not EEF (the entity that mantains Certbot) to send emails to us.

We’ll then be presented with a list of all domains enabled on our server:

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: emanuelpina.pt
2: www.emanuelpina.pt
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

Select the appropriate numbers for the domains you want to obtain a certificate separated with a , (for our example type 1,2) and press ENTER. After doing so, Certbot will communicate with the Let’s Encrypt server, then run a challenge to verify that we control the domain we’re requesting a certificate for.

If that’s successful, Certbot will update the server block and Nginx will reload to pick up the new settings.

Now, visiting our domain address on a browser we can notice that a encrypted/secure connection is being used.

Enable HSTS

Let’s run our domain on this SSL Server Test from SSL Labs. The test takes a couple of minutes…

We got an A. Not bad, but we can do better! To do so we’ll enable HSTS.

HSTS stands for HTTP Strict Transport Security and is a response header that informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access it to HTTPS requests instead.

Enabling HSTS is as easy as editting our server block:

# sudo nano /etc/nginx/sites-available/emanuelpina.pt

And adding add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; just bellow the server_name, like this:

server {
 ###

 server_name emanuelpina.pt www.emanuelpina.pt;

 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

 ###
}

Test to make sure that there are no syntax errors in our Nginx files:

# sudo nginx -t

And if there aren’t any problems, restart Nginx to enable the changes:

# sudo systemctl reload nginx

Now let’s run again the SSL Server Test from SSL Labs.

And that’s it. HSTS is enabled and we got an A+!

What’s next?

Now that we’ve connected our server to the Internet, to run Nextcloud we still need PHP and PostgreSQL. That’s what I’ll cover in a following post.

Do you want contribute and add something to this tutorial? Have you found a typo, grammar or formatting error? Please, feel free to contact me or edit this post and open a pull resquest.

Global Climate Strike

Thu, 19 Sep 2019 22:47:51 +0100

Climate crisis is a fact. It’s not something you choose to believe in or to deny. It’s an emergency.

Because of human activity the world is changing at great pace and this time it’s not for the better. We are no longer in time to avoid many of the drastic consequences of our aggressions to the planet, but we are still in time and have the responsibility to restrain them as much as we can.

The Global Climate Strike initiative is another attempt to raise awareness to the consequences of our actions, the policies of our governments and the imperative and urgent need for change.

For this initiative, the proposal is for millions of people around the world leave their homes and workplaces, on September 20th, to join the young climate strikers on the streets and demand an end to the era of fossil fuels.

You can use this map to find a climate strike near you, and if you’re unable to strike on September 20th, here are some other ways you can join the movement.

Fight for our home 🌍 There’s no Planet B…

Debian Server Initial Setup

Wed, 18 Sep 2019 12:03:48 +0100

This is the first of a series of posts that will cover from the deployment of a VPS up to the installation of Nextcloud. These are the kind of posts I will write mostly for future memory, but if they will be useful to you, even better. I’m not reinventing the wheel here, these are just the result of the sum of tutorials and lessons I keep learning.

On this post I will cover the use of SSH to connect to a server, the creation of a new user with administrative privileges and the setup of a firewall.

I’m currently using Debian 12, but these instructions may be equally valid for other versions of Debian and Ubuntu.

Update the system

Keeping our system updated is important not only, but mostly for security reasons. To do so, let’s first update the package lists from the repositories:

# apt update

If an update is available a list is presented. To apply the update(s), run:

# apt upgrade -y

Don’t forget to periodically run those commands and keep the system up-to-date!

Use SSH

While managing our server, we’ll spend a lot of time working on a terminal session and the safest way to connect to it is through SSH, or secure shell.

To do that we’ve to make use of an SSH key, which is a pair of encryption keys mathematically linked to each other: a private key and a public key. The public key is used to encrypt a message whereas the private key is used to decrypt it. There are several ways to generate an SSH key. Usually the SSH client we’ll use is capable of doing it and that’s probably the easiest way. For Windows, the most popular SSH client is Putty, but I use Termius. To know more on how to connect to a server using SSH, see this tutorial from DigitalOcean.

So, we’ll keep our private key to ourself, to use with the SSH client, and install/copy the public key to our server. Almost any VPS provider nowadays have an option on their console that let’s add our public SSH keys so we can chose to automatically add them upon server deployment. That’s how I do it. But if you prefer to install/copy your SSH key only after the server deployment, see this tutorial.

Moving on, after creating a new Debian server there are a few configuration steps that we should take to increase security and usability.

Create a new user

To first access our server we need to login as root.

The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident. ¹

So, our first step is to set up an alternative user account with a reduced scope of influence for day-to-day work.

On this example we will create a new user called johndoe, but you should replace it with a username of your choice:

# adduser johndoe

We’ll be asked to set up a password and some information. Enter a strong one and, optionally, fill in any of the additional information if you would like. This is not required and you can just hit ENTER in any field you wish to skip.

Grant administrative privileges

To grant administrative privileges to the new user we need to add it to sudo group:

# usermod -aG sudo johndoe

Copy SSH key to a new user

Next you’ve to copy the public SSH key from root user to the new user. This way you can login as both using the same SSH key. The simplest way to copy the files with the correct ownership and permissions is with the rsync command. This will copy the root user’s .ssh directory, preserve the permissions, and modify the file owners, all in a single command:

# rsync --archive --chown=johndoe:johndoe ~/.ssh /home/johndoe

Now we can login with our new user account typping:

# sudo -i -u johndoe

We should be logged in to the new user account without using a password. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

# sudo command_to_run

You will be prompted for your regular user password when using sudo for the first time each session.

Setup a firewall

You can use UFW (Uncomplicated Firewall) to manage which connections are allowed to/from the server.

So, let’s update the package lists from the repositories and install UFW:

# sudo apt update
# sudo apt install ufw

Different applications can register their profiles with UFW upon installation. These profiles allow UFW to manage these applications by name. OpenSSH, the service allowing us to connect to our server now, has a profile registered with UFW.

You can see this by typing:

# sudo ufw app list

Available applications:
 OpenSSH

We need to make sure that the firewall allows SSH connections so that we can log back in next time. We can allow these connections by typing:

# sudo ufw allow OpenSSH

Afterwards, we can enable the firewall by typing:

# sudo ufw enable

Type y and press ENTER to proceed. We can see that SSH connections are still allowed by typing:

# sudo ufw status

Status: active

To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)

What’s next?

Now that we’ve completed the initial configuration of our server, we can proceed with the installation of a webserver to present it to the vast and incredible world wide web!

In a following post I will cover the installation of Nginx.

Do you want contribute and add something to this tutorial? Have you found a typo, grammar or formatting error? Please, feel free to contact me or edit this post and open a pull resquest.

Initial Server Setup with Debian 11 ↩︎

This Blog's Source Code Is Now Public

Sun, 15 Sep 2019 12:03:09 +0100

This blog was built following the JAMStack philosophy using Hugo, with its development being done at GitHub and now publicly available under the MIT license. It’s deployed and hosted on Netlify.

Keep in mind that the theme used was tailor-made, and if you decide to use it, you will probably have a lot of work to do to adjust it to your needs.

I am making the source code public so it can be useful to you, but also so it can be audited. So please, if you find any typos, grammar or formatting errors, or any other issue that needs to be addressed, feel free to open a Pull Resquest. On posts you can use the link Edit (below the title) to fix them directly on GitHub.

Enjoy and contribute 😄

How I Ended Up With Vultr to Self Host Nextcloud

Wed, 11 Sep 2019 19:50:36 +0100

In the process of self-hosting Nextcloud the first step was to choose a VPS provider. It wasn’t a straightforward choice and in the process I ended up experiencing, by this order, Hetzner, DigitalOcean and Vultr.

But, first of all, let me advise you that this isn’t intended to be a factual analysis, supported by quantifiable and specific data. It is rather a subjective assessment based on my use case. Therefore, I believe that your experience with these providers could be completely different. If you are into more technical and detailed analyses you can go here and here, for example.

So my first choice was Hetzner. A company with a high reputation and a very inviting features/price ratio. A VPS with 1vCPU, 2GB RAM, 20GB Disk and 20TB Traffic for €2.49 ($2.75) looks great. It seemed a logical choice. So I proceeded with the installation and configuration of Nextcloud and uploaded my files to the server. Everything was going well, until I started to browse through Nextcloud and tried to open some of my videos. The server crashed. I thought it was a one-time event, but I repeated the process always with the same outcome. According to Hetzner’s console the culprit seemed to be the CPU. On idle it remained arround 30% and very often reached 100%. So I upgraded the VPS to 2vCPU, 4GB RAM and 40GB Disk for €4.90 ($5.41) and it all started to work like a charm.

But then I kept wondering, does it take 2vCPU to run a personal Nextcloud? So I decided to give a try with the only provider I had ever worked with, DigitalOcean (DO). Of course I chose a droplet with 1vCPU, 1GB RAM and 25GB Disk ($5, €4.54). The user experience was very similar to Hetzner’s 2vCPU plan. Of course, CPU utilization was higher in DO (1vCPU vs 2vCPU), but with rare peaks and generally never exceeding 60%. One noticeable difference was the higher download/load speed in DO. Something I expected, because by the reviews I read they have a better network performance with higher download and upload speeds.

The same reviews pointed out that Vultr has a network performance on par with DO and a better overall performance. Besides that they have a datacenter in Paris (500km closer to me than Amsterdam) and free snapshots. So I decided to give it a spin. As in DO I deployed a server with 1vCPU, 1GB RAM and 25GB Disk ($5, €4.54). The user experience was slightly better than with DO. The response time was shorter. As a result the pages opened more quickly and the download/load of files was also faster. A better overall experience. This, combined with the ability to create and store snapshots for free, made it easier for me to choose Vultr.

For now I see no advantage in using DO over Vultr. Hetzner can be back in play if I find myself in need of a little more disk space, or of the extra performance the 2vCPUs and 4GB RAM can offer.

Wrapping up

Hetzner 1vCPU, 2GB RAM, 20GB Disk at €2.49 ($2.75): High CPU utilization and server crashed when loading videos, aparently because of CPU limitations.
Hetzner 2vCPU, 4GB RAM, 40GB Disk at €4.90 ($5.41): Worked like a charm.
DigitalOcean 1vCPU, 1GB RAM, 25GB Disk at $5 (€4.54): Similar experience as with Hetzner 2vCPU plan. Download/load of files was faster than Hetzner.
Vultr 1vCPU, 1GB RAM, 25GB Disk at $5 (€4.54): Slightly better exeprience than DO. Faster response time and download/load of files. Free snapshots.

Be the Owner of Your Data With Nextcloud

Sun, 08 Sep 2019 19:36:09 +0100

Since a few years now I started to get concern with how much of my data was being gathered and how it was being used.

Nowadays we spend a big part of our lives online and over the years companies have grown basing their business on tracking our actions. The searches we made, the sites and pages we visit, the time you spent on them… and so on.

Let’s face it, Google Search was a revolution, and Gmail, OneDrive, iCloud, Facebook or Youtube are excellent products in terms of usability and features. And best of all they’re free, you would say. Are they?

So, how can this companies create and mantain such great products, give them free and be profitable? More than been profitable, all those are now in the top 10 list of the most values companies. How?

Because data is nowadays the most profitable resource. The metadata those companies gather of us can be used, for instance, to place ads or shape what we see when we do a search on Google or view our timeline on Facebook or Youtube. In the end, they can condition us to buy a product or to vote in a certain politic. Do you think I’m being dramatic? Take a look at Netflix documentary The Great Hack about Facebook and Cambridge Analytica actions during Trump and Brexit campaigns.

One question that came up in that documentary and made me think was “how much of Facebook’s profits come from the use of its users’ data?” The answer is all. All of the more than $400 billion dollars that Facebook worth are result of how much of our data they gather and own. That’s disturbing.

What can we do? Well, look for alternative products with privacy in mind. But the first step you need to take is acknowledge the importance of protect your data. Why? Because some of the alternatives to those big companies produtcs don’t offer the same features or don’t come free, or both. Yes, the truth is that presently privacy can be seen in some way as a “luxury” product.

So far, in pursuit for privacy, what changes did I make? A couple years ago I ditched Chrome for Firefox. Gradually stopped using Facebook or Messenger, and recently adopted Signal for messaging and Mastodon as social network. My email, contacts and calendars are now handled by Tutanota.

For now there was still one big piece missing, cloud storage. I was using OneDrive because of his deep integration with Windows and Office. Looking for alternatives I found good, open source, but expensive ones like Least Authority S4 ($25/month), and more affordable, but closed source ones like Sync and Tresorit. Then I decided to take what I already knew on SysAdmin, learn a couple of new things, and give a try on self-hosting Nextcloud. And two weeks later there’s no looking back!

Nextcloud is a community-driven, free and open source software with all is code published on GitHub. It offers server-side encryption and end-to-end encryption is under development. It’s mainly a cloud storage, but groupware capabilities could be easily added. It meets all my most urgent requirements and have room for grow and improvement.

So far, my roadmap on self-hosting Nextcloud:

Deploy a Ubuntu server with Nginx, PHP and PostgreSQL installed;
Install and tune Nextcloud;
Use Restic to automate backups of Nextcloud files and database to Backblaze B2;
Use Vultr’s API to automate snapshots management.

I’m no expert, but I will try detail each one of these steps on upcoming posts.

For now I’m using Nextcloud only to store files and notes. As next step I will probably work on the integration with OnlyOffice.

Hello World

Thu, 29 Aug 2019 12:43:44 +0100

Maybe the best way to begin is with a introduction…

I’m a pediatric nurse by ☀️ and 🌙, ☕ lover and a 🐶 owner for life!

In between I taught myself a couple of things on web development, currently focused on JAMstack and with more than 15 years of experience on trying to learn JavaScript!

I’m a motorsport fan (F1, WEC, IMSA…) and I do some sim racing on iRacing.

There’re days (less than it should) when I take some time to cycling.

What to expect from this blog? Well, the way I see it I will use it more like a journal. A place to log some thoughts, ideas, events and keep track of things, like tutorials, for future memory.

I hope, if you share my interests, you will find here something enjoyable or useful.

For sure, I have the expectation to ear things from you too. So fell free to reach me out commenting on posts or through this form.

I have accounts on Twitter and Instagram, but I don’t post much by there. I’m more active on Mastodon, so feel free to follow me there 😀