completes the sftp solutions

modules/resources/solution_raspberrypi.md

@@ -252,20 +252,112 @@ done
 
 ## Setting up the fileserver
 
+The concept of a fileserver is about as old as the the world wide web, email, newsgroups etc.
+It's main purpose in life is to offer a place to store and retrieve large files.
+The Debian repositories where you download all your packages from is contactable over the FTP protocol.
+There are multiple implementations available, some plain, some secure, some less secure.
+We'll have a look at the two most common solutions to host and transfer files.
+
+To use the FTP protocol we can install any FTP tool we find.
+A good candidate is `filezilla` which you can find in the Debian repositories, or online if you want to use it on Windows.
+
 ### FTP
 
 A quick [google](https://likegeeks.com/ftp-server-linux/) tells us `vsftpd` is a popular *FileTransferProtocol* server.
 As expected you can find it in the main Debian repositories.
-You know how to install it by now!
 
 ```bash 
 sudo apt search vsftpd
 ```
 
+You know how to install it by now!
 To know *where* to configure the server we can look at the `man vsftpd` pages.
 Scroll all the way to the bottom to see which files it uses to configure itself.
 The configuration file itself is very *verbose* and should explain itself.
 
 ### SFTP
 
-TODO
+Even without installing any additional server, we can offer our users a way to download, and upload, files to our server.
+When you install `openssh-server`, and pay attention to the installation dialog, you'll see it will also install an additional package called `openssh-sftp-server`
+This in itself is enough to have an SFTP server up and running.
+Done!
+
+It does raise the question of security.
+When installing the `vsftpd` package your users can *only* upload and download files but when you install an ssh server they can also get shell access!
+This might not be the desired behaviour for all your users.
+Luckily we can change the server configuration to modify it to our requirements.
+
+How will we find *which* configuration file we need to change *where*?
+`man sshd` should do the trick.
+Navigate to to end of the manual and you'll see a huge list of files the server uses to configure itself.
+Why `sshd` and not `ssh` you ask?
+Well, `ssh` is the **client** you use to connect to the `sshd` **server** and thet are to different *programs*.
+Remember that `ssh` was installed on your Linux machine even before installing `openssh-server`!
+
+I can think of two ways to limit the shell access for specific users.
+The first one should ring a bell.
+As we define our default shell in the `/etc/passwd` file to be `/bin/bash`, we can also change this for specific users to `/usr/sbin/nologin`.
+This will block those users from getting an actual shell when sshing into the machine but SFTP should still work.
+There are multiple downsides to this solution, some of which we'll investigate further later one, but the main one I see from a beginner point of view is that it requires a customisation for each account we want to block.
+As all users we want to block are part of a group, either *red* or *blue* there should be a way to restrict access on a group based level no?
+
+It's the last lines of the configuration file that point out some interesting features.
+
+```bash
+# override default of no subsystems
+Subsystem	sftp	/usr/lib/openssh/sftp-server
+
+# Example of overriding settings on a per-user basis
+#Match User anoncvs
+#	X11Forwarding no
+#	AllowTcpForwarding no
+#	PermitTTY no
+#	ForceCommand cvs server
+```
+
+Remember that the `#` are comments.
+These settings point out that we can add different rules for different users, and probably groups as well.
+So, if you trust all people in the *blue* group, you can add a rule to match all users in the *red* group and restrict them to only sftp login and no shell access.
+With this in mind, what would adding the following to the configuration file do?
+
+```bash
+Match Group blue
+    ForceCommand internal-sftp
+```
+
+But the users can still walk around the entire file system, which is not always a good idea.
+Using the keywords **sftp**, **chroot**, **group** in [google](https://googlethatforyou.com?q=sftp%20chroot%20group) lists us the [arch](https://wiki.archlinux.org/index.php/SFTP_chroot) wiki which is *always* a solid place to inform ourselves.
+Try to have get this set up as an additional exersise!
+
+### Taking changes to configuration files into account
+
+When make these changes to the configuration files you probably noticed they are not applied immidiatly.
+So when are they taken into account then?
+Most servers we'll install onto our various machines run as [daemons](https://en.wikipedia.org/wiki/Daemon_(computing)) in the background.
+They listen on for an incoming client connection on a port, do whatever the client requests of them and go back to sleep when there are no tasks for them to perform.
+They might have internal tasks scheduled but we'll set this aside for the moment.
+As with most things Linux, configuration is done by a text file and *most* daemons will read their corresponding configuration files upon startup.
+Think of the .bashrc file, which is read every time a new shell is started.
+Once they know how to behave, from reading their configuration file, they will act accordingly.
+This raises the question, how do you *restart* a running server?
+
+The system responsible for launching most daemons on our Debian installions, and also our Raspberry PI's, is called **systemd**.
+The thee most used commands you need to know are as follows.
+How do to *start* a service, how to *stop* one and how to *check* if one is running properly.
+For system daemons, such as `sshd` or most webservers, you need administrator powers to interact with them.
+
+```bash
+sudo systemctl start sshd.service
+sudo systemctl stop sshd.service
+sudo systemctl status sshd.service
+```
+
+These three commands will go a long way but there are other handy ones you can try out.
+I advise you to use *tab-completion* as much as possible as it will help you to construct the proper commands.
+Especially at the beginning of your Linux journey because it takes some time to rememeber specific service names.
+Have a look at all the base commands of `systemctl` and you'll notice quite a few interesting things.
+For example, it can be used to reboot or shutdown your computer as well!
+
+For those who want to digg deeper into systemd itself I advise you to have a browse in it's configuration directory.
+You'll find it at `/etc/systemd` and the manpages `man systemd` are also very helpfull, but a bit verbose.
+We will have a deeper look at the internals of systemd later throughout the course.