Continue writing thesis

content/a_tour_of_tfw.tex

@@ -1,4 +1,17 @@
-\chapter{A Tour of TFW}
+\chapter{A Tour of TFW}\label{atouroftfw}
+
+The bulk of the functionality provided by the Tutorial Framework
+is implemented in pre-made components that are built upon the architecture
+described in Chapter~\ref{architecture}.
+To create tutorials, developers generally rely on and use TFW provided components to
+implement most of the common functionality and then build more exercise-specific logic
+based on the TFW architecture themselves.
+A \emph{very important} point to keep in mind is that most of this
+exercise-specific logic will be implemented in \textbf{FSM callbacks} and
+custom \textbf{event handlers}.
+The whole framework is built in a way to faciliate this process and developers
+who understand this mindset are almost always guaranteed to create great
+content using TFW.
 
 The purpose of this chapter is to further detail the built-in components
 provided by the framework.
@@ -191,6 +204,28 @@ certain command are executed by the user.
 
 \pic{figures/terminal.png}{The Frontend Terminal of TFW Running top}
 
+The implementation of reading command history is quite an exotic one.
+The framework need to be able to detect if the user has executed any command in the
+container.
+This is not an easy thing to accomplish without relying some sort of heavyweight
+monitoring solution such as Sysdig%
+\footnote{\href{https://sysdig.comq}{https://sysdig.com}}.
+I deemed most simiar systems a huge overkill to implement this functionality, and their
+memory footprints are not something we can really afford here.
+Another way would be to use \texttt{pam_tty_audit.so} in the PAM%
+\footnote{Linux Pluggable Authentication Modules:
+\href{http://man7.org/linux/man-pages/man3/pam.3.html}
+{http://man7.org/linux/man-pages/man3/pam.3.html}}
+configurations responsible for logins, as this allows various TTY auditing, but
+I have found an ever simpler approach to the problem in the end.
+By using the inotify system built into TFW, I can set up the user's environment in
+such a way, that I can enforce or determine the location of the bash \texttt{HISTFILE}%
+\footnote{This environment variable contains the path to the file bash writes command
+history to}
+of the user.
+This way I can monitor changes made to this file and read the commands executed
+by the user from it.
+
 \section{Console Component}
 
 This component is a simple textbox that can be used to display anything to the user,
@@ -253,3 +288,25 @@ in a spectacular fashion until the whole thing managed to crash.
 It was an event of such chaotic beauty, that I often fondly recall it to this day.
 Of course it would take me several hours to identify the exact causes behind this
 fascinating phenomenon, but those were \emph{very} fun hours.
+
+\section{FSM Management}
+
+I have already mentioned the event handler called \texttt{FSMManagingEventHandler},
+which is responsible for managing the framework FSM.
+For completeness I chose to include it on this chapter as well.
+The API it exposes through TFW messages allows client code to attempt stepping the
+state machine.
+As previously explained this is something that is considered to be a \emph{privileged}
+operation in case authentication is enabled, causing the event handler to accept
+digitally signed messages only.
+In the event of a successful FSM step, this component is going to broadcast
+a message showcased as an example in the beginning of Chapter~\ref{atouroftfw}.
+
+\section{Additional Frontend Features}
+
+The frontend of the framework exposes some additional APIs through
+TFW messages.
+These include the changing of layouts, selecting the terminal or console
+component to be displayed, the possibility of dynamically modifying other
+frontend configuration (such as the frequency of autosaving the files in the editor)
+and more.