A Flarum Installation Guide For Dummies And The Truly Clueless

ron_jeremy

Aesahaettr now that I've done it a couple times it's not so bad.

jordanjay29

It might be easier to read if you encapsulate the command strings inside [code][/code] tags. Nice work, though, this should be helpful for new folks.

Kulga

nice! step by step command involving all the components takes awhile

I didn't read through it completely but one thing
- To make it more readable you can use code tags for commands and output and such

CREATE DATABASE flarum;

If you list the databases again you will see your new database:

SHOW DATABASES;

information_schema
flarum
mysql
performance_schema

edit: oops, slow on the post

Kulga

Looking through - some thoughts

Creating a new user is done to separate privileges from admin level to normal level. A fail-safe if that user has software running (like flarum) that is exploited and gains shell access, cannot delete or modify critical system files. the separated user should not need root access. Root level commands should be done through root itself or a account that isn't serving stuff accessible by the web.
A separate user for network accessible files is a fundamental part of linux security so +1.

UPDATING UBUNTU
sudo apt-get update

This command only synces changes. It does not update programs. From man page of apt-get

update is used to resynchronize the package index files from their sources.

To both update and then upgrade a system you can use this common command which combines the syncing and actual upgrade. If curious, the && stands for "If the preceding command exited successfully, do this command":

sudo apt-get update && sudo apt-get upgrade

A big +1 for using appropriate permissions and usage of groups rather then saying "do chmod -R 777"

Another +1 for using terminal mysql commands to create the database. However, newbies may be more comfortable using phpmyadmin. It does however involve additional steps of setting that up.

I would suggest modifying the thread title to include digitalocean and apache as these seem to be integral to your guide.

I am a total newbie

I'd rank you higher then that. You clearly have spent time learning a lot about the terminal

webeindustry

Kulga Creating a new user is done to separate privileges from admin level to normal level. A fail-safe if that user has software running (like flarum) that is exploited and gains shell access, cannot delete or modify critical system files. the separated user should not need root access. Root level commands should be done through root itself or a account that isn't serving stuff accessible by the web.
A separate user for network accessible files is a fundamental part of linux security so +1.

Okay, so if this were the case it would make good sense to me, but how does that actually work? Also, isn't that what the www-data, and apache user are? When I think of an "admin user" I think of the root account. Perhaps I am a bit naive.

So I am a hacker and am looking through code inside of flarum, this code will in some way leak information which gives me shell access? I don't get this one. All of my servers disable root login by any means, and disable password login. You can only access the shell with an ssh key by my personal user which I then use inside to elevate to root access. Creating additional users and groups always seemed like a "best practice" that only applied to mission-critical, enterprise-level projects, but was more assumed to be best in every instance than truly necessary. If I had other people logging into my server it would make sense, as a semi-loner it seems to make little sense.

To reiterate, the default webserver user has no shell access, no acct login, and seems the best default for web apps. Assigning a unique group/user for a web app seems necessary only when there is other players logging into the webserver itself. I wonder why you think it's possible for someone to gain access to critical system files by way of the www-user acct? If this is the case, please explain and I'll update my security measures accordingly.

Thanks.

ron_jeremy

Thanks for the suggestions @jordanjay29 and @Kulga . I added the 'code' tags and it does look much more readable!

luceos

Adding a user to sudo can be done using:

sudo adduser flarum sudo

Which adds user flarum to the sudo group 🙂

ron_jeremy

luceos Does it do exactly the same thing? If so, I will amend my post with your suggestion.

Kulga

ron_jeremy

In visudo

 # Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

When you make a user part of the sudo group, you authorize that user for those privelges. So it does not do the same thing, but will give that user identical permissions as your guide illustrates above.
Different approach, same result.

Kulga

or for existing users to add on groups

gpasswd -a user group
usermod -aG group user

adding accounts with a "lower-level" tool

useradd -G group user

Cat skinning 😉

webeindustry

ron_jeremy sudo chgrp www-data /var/www/html
sudo chgrp -R www-data /var/www/html/assets
sudo chgrp -R www-data /var/www/html/extensions
sudo chgrp -R www-data /var/www/html/storage

This is redundant. You only need to

 chown www-data: /var/www/html -R

Another note, directories should be 755, weberver files should be 644 for better security.

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Franz

webeindustry This is redundant. You only need to

chown www-data: /var/www/html -R

Nope? When you do that, all Flarum subdirectories (including the source code) will be writable by the web server. Which we do not want, in case there is some kind of security issue.

Kulga

webeindustry Another note, directories should be 755, weberver files should be 644 ~~for better security.~~

You are generally correct, in most cases permissions of 755 and 644 (for directories and files) is a good security practice. It is also applicable in web servers which many guides frequently direct exactly what you wrote

chown www-data: /var/www/html -R

As the method of setting up permissions and ownership.

Let's cover better security - permissions are only half the battle. File ownership and what group it belongs to complement the permissions. In the guide above, you may notice that the commands given do not change the owner of the file, rather the group of the file. Then the subsequent command gives permissions of 775 to assets, extensions and storage.

This does two things and permits one

Causes the webserver user (www-data commonly) to have write access only to the directories it requires write access. If the entire directory belongs to the webserver user group, other directories can be *5* and files are *4* (the first and last are irrelevant in this case), and read access would be granted as well.
The files are completely owned by the system user (flarum)
If the user is part of the webusers users group, elevated privileges are not required - which permits this level of security in most hosting environments.

Technically, the directories permissions could exclude the world ones, leaving 750 (and 770) - which can be very useful.

Franz When you do that, all Flarum subdirectories (including the source code) will be writable by the web server.

By using groups and owners, you can more selectively fine grain write access. Less write access is always better, whether protecting against the program itself or hackers. ?

webeindustry

Kulga

www-data: changes both ownership and group. It's the same as www-data:www-data

Franz

webeindustry To reiterate, the default webserver user has no shell access, no acct login, and seems the best default for web apps. Assigning a unique group/user for a web app seems necessary only when there is other players logging into the webserver itself. I wonder why you think it's possible for someone to gain access to critical system files by way of the www-user acct? If this is the case, please explain and I'll update my security measures accordingly.

I think the issue is that - especially with your setup - the web application (i.e. Flarum) is still your server's biggest surface to the outside world, and therefore also the biggest attack surface. So, if through any security issue in Flarum's code, attackers are able to execute PHP code (or even shell commands) on the server, you want them to be limited in what they can do as much as possible.

Kulga

webeindustry To reiterate, the default webserver user has no shell access, no acct login

Franz So, if through any security issue in Flarum's code, attackers are able to execute PHP code (or even shell commands) on the server

Should through flarum (or any php software), they be able to execute a command like /bin/bash (or another shell), they would have shell access to your server.
However, this will be through the webserver user (www-data). More precisely, the user used for php execution. By default, these system users are unprivileged - intended to be a scapegoat during a compromise.
Franz put it much more concise then me ?

webeindustry

Franz

Fair enough. I'm beginning to see this like wearing a seatbelt. Very little resource investment for big safety gains. Will incorporate this into my security practices.

fox

Is there a guide similar to this one but for nginx instead of apache? Its been a long time since I went through the whole process of setting up a web server. Most of it seems like it would be the same, but I'm having some trouble with the nginx configuration.

0E800

fox

Check out @webeindustry 's install script. I use it for my installs. Works great.

https://raw.githubusercontent.com/webeindustry/flarumvpsinstallscript/patch-1/script

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get install wget
wget https://raw.githubusercontent.com/webeindustry/flarumvpsinstallscript/patch-1/script
sudo chmod +x script
sudo ./script