Create a local directory for EOS \texttt{mgm}. It seems this is not actually used for anything, but creating it
suppresses a spurious error in the EOS logs.
\begin{lstlisting}
# mkdir -p /mgm
# chown daemon:daemon /mgm/
\end{lstlisting}
\section{Set up the XRoot \texttt{fst} configuration file}
\section{Configure XRoot \texttt{fst}}
Replace references to \texttt{localhost} with the FQDN of the local development box:
In \texttt{/etc/xrd.cf.fst}, replace references to \texttt{localhost} with the FQDN of the local development box:
\begin{lstlisting}
all.manager devbox.cern.ch 2131
fstofs.broker root://devbox.cern.ch:1097//eos/
\end{lstlisting}
Create a local directory to be used to store files by the EOS \texttt{fst}:
\begin{lstlisting}
# mkdir -p /fst
# chown daemon:daemon /fst/
\end{lstlisting}
\section{Start the XRoot daemons that will run the EOS \texttt{mgm}, \texttt{mq} and \texttt{fst} plugins}
\section{Start XRoot daemons}
Start the XRoot daemons that will run the EOS \texttt{mgm}, \texttt{mq} and \texttt{fst} plugins:
\begin{lstlisting}
# systemctl start eos
\end{lstlisting}
%\section{Set both the EOS \texttt{mgm} and the EOS \texttt{mq} to be masters}
%\begin{lstlisting}
%# service eos master mgm
%# service eos master mq
%\end{lstlisting}
%As agreed I've installed a very simple EOS instance on eosctatape (p06253947b39467).
%
%The FST storage directory is:
%
% /srv/castor/01/fst
%
% [Ticket] Remove dependency on /usr/sbin/eosfsregister
%
% The /usr/sbin/eosfsregister command-line tool is a convenience script for registering an EOS fst node with its an EOS mgm node. This script is not directly maintained by the EOS developers.
%
% eosfsregister currently determines the location of the EOS mgm node by parsing the contents of the /etc/sysconfig/eos file. This file is part of the initd configuration files for EOS. This file does not exist in the set of configuration files for systemd. The CTA project is using a version of EOS based on systemd and therefore we currently have the work around of creating the /ets/sysconfig/eos file on our systemd based setups.
%
% The work carried out by the /usr/sbin/eosfsregister command-line tool can be done by using "standard" EOS commands directly maintained by the EOS developers. We should modify our CTA install/configure/setup scripts to use these "standard" EOS commands and therefore remove our dependency on the /usr/sbin/eosfsregister command-line tool.
\section{Create a local directory to be used to store files by the EOS \texttt{fst}}
The logs for the XRoot daemons will be created under \texttt{/var/log/eos/fst}, \texttt{/var/log/eos/mgm} and \texttt{/var/log/eos/mq}.
\begin{alertbox}
The EOS \texttt{mgm} startup script checks if we are running under \texttt{systemd}, but the test it performs does not work inside a
Docker container, as (a) pidof is part of \texttt{sysvtools-init}, which is not installed and (b) the \texttt{systemd} process is
started as \texttt{init}(a symbolic link to \texttt{systemd}):
\begin{lstlisting}
# mkdir -p /fst
# chown daemon:daemon /fst/
/usr/sbin/pidof systemd
\end{lstlisting}
This has been reported to the EOS team to fix. In the meantime, here is a hack to work around the problem:
\begin{lstlisting}
# yum install -y sysvinit-tools
# ln -s /usr/bin/sleep /tmp/systemd
# /tmp/systemd 1000&
# systemctl start eos
\end{lstlisting}
\end{alertbox}
\section{Enable the kerberos and simple shared secret authentication mechanisms within EOS as opposed to xroot}
\section{Enable EOS authentication mechanisms}
Enable the Kerberos and Simple Shared Secret authentication mechanisms within EOS (as opposed to XRoot):
\begin{lstlisting}
# eos vid enable sss
# eos vid enable krb5
\end{lstlisting}
\section{Register the local /fst directory with the default EOS space}
