# [Ach] (continuation) summary of yesterdays' meeting (what did we do, where are we heading?)

L. Aaron Kaplan kaplan at cert.at
Tue Nov 19 20:53:21 CET 2013

Hi,

As already mentioned in the previous mail, we created a timeline.

Did we miss anything? Scope
===========================
Next, we spend some time checking all kinds of sources if we missed important services. We came up with a few, which are documented in the TODO.txt
Note that there are quite a few services which we intentionally *do not* want to document. First of all, that would blow up the document and make it quite bloated (it is already quite lengthy!)
And secondly, many of these services are either internal, not commonly in use or there is some other reason why we decided that it is not in scope.
You can take a look at scope.tex for a feeling of what the team discussed yesterday. I tried to capture that in a few words.
Nevertheless, we went through a good part of the /etc/services table and did find a few services which we had missed before.

Which brings me to the next point: should we include DBs?

Berg San submitted a nice copy& paste setting for Mysql. However, so far we thought DBs are out of scope. We mostly believe that DBs should be an internal service and not facing the public Internet.
However, when you look at reality, there are many webhosters which actually have Mysql or similar running on public IP addresses. If you buy a normal LAMP setup with webmin, that often entails an Internet-facing DB.
Question to the group: what do you think? Are settings for DBs in scope or out of scope for the first release of the paper?
I'd like to hear your feedback on this question.

Structure
=========
After that, we found a new structure for every subsection in section 6 "practical settings".

We agreed that every described service should be documented like this:

--- snip ---
\begin{description}
\item[Tested with Version:]

\item[Settings:] \mbox{}

\begin{lstlisting}[breaklines]
\end{lstlisting}

\begin{lstlisting}[breaklines]
\end{lstlisting}

\item[Justification for special settings (if needed):]

% in case you have the need for further justifications why you chose this and that setting or if the settings do not fit into the standard Variant A or Variant B schema, please document this here

\item[References:]

% add any further references or best practice documents here

\item[How to test:]

% describe here or point the admin to tools (can be a simple footnote or \ref{} to  the tools section) which help the admin to test his settings.

\end{description}
--- snip ---

I will be updating the existing sections accordingly.
If you write a new one, please stick to this structure. It will help to create a uniform document.

Next meeting
=============

I'd like to propose the next working meeting for next Monday, 25th of Nov, 18:30 at the CERT.at offices.
Any objections?

Aaron.

---
// L. Aaron Kaplan <kaplan at cert.at> - T: +43 1 5056416 78
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131119/edbf1c0e/attachment.sig>