F20 System Wide Change: No Default Syslog

["Jóhann B. Guðmundsson"]

On 07/17/2013 10:16 PM, Matthew Miller wrote:
> On Wed, Jul 17, 2013 at 09:12:46PM +0000, "Jóhann B. Guðmundsson" wrote:
>> You do realize I filed for the exact same thing for F18 as is being
>> proposed here.
> I know, at least. And, as I said earlier in a different subthread (I don't
> think you replied), the rejection didn't seem to me (I wasn't involved at
> the time) to be very harsh -- just that it wasn't ready yet. So, things have
> changed, because a year is a long time in the development of an early-stages
> software project like this. And, there's the impact on the cloud images,
> which wasn't a consideration before. So, it seemed worth proposing again. I
> don't think that _either_ invalidates your earlier proposal or makes the
> previous FESCO decision wrong.

My proposal was meant as an proposal to start identifying and shake out 
any deficiencies in the journal and identify which tools relied on the 
traditional log files in as least intrusive manner as possible which was 
to just disable even just up to beta which would expose it to the entire 
QA community during that time with the benefit of identifying which 
tools and which deficiency needed to be fixed to be performed before the 
inevitable moment came when the actual removal of rsyslog would be 
requested ( which Lennart is doing now and why fesco at that time denied 
that request even today makes absolutely no sense to me ).

>
> All of that said, I think many of are still very confused about the
> relevance your count of packages which have non-syslog log files. Can you
> help explain the relevance?

Let me paint the picture as I saw it what those two yeas ago, the 
question that haunted me then and I do believe still are relevant today 
and is not entirely related to the removal rsyslog but rather the act of 
switching to alternative logger .

Now that we as an community are considering switching from traditional 
login in text to a binary logger we as as community should step back 
look at the entire logging infrastructure and solutions their packaging 
and implementation thereof in the project and be asking ourselves the 
bigger questions instead of focusing on the usability of journalctl 
command with a very limited administrative perspective.

First and foremost we as a community need decide which standard we as a 
distribution have for our "default" syslogger, which IETF and other 
compliance standards it must pass.

Once that has been establish we can apply that to our "default" 
syslogger regardless if that's traditional logger or a binary one.

The next step is to ensure that we have procedures,policy,guidelines in 
place to ensure that all log related components are correctly packaged 
and have the correct dependency against each other, which is  not the 
case for around 550 - 600 components that ship services/daemons, the 
logrotion and logwatch etc and ( and whatever else I looked at at that 
time ) is and what I was trying to start addressing with my FPC proposal

Currently we are shipping around 550 - 600 components that ship 
services/daemons most but probably not all can use syslog but may not be 
configured to do so which may or may not be affect by the act of 
changing to binary logger I guess depending on which IETF syslog 
standards that binary logger supports?

And as we all know log files are used for audits, for evidence in legal 
actions, for incident response, to reduce liability, and for various 
legal and regulatory compliance reasons so so we need to look into  log 
alerting and parsing tools like but not limited to...||
logwatch
logcheck
swatch
sec
gui notifications/tools
etc..

Along with looking into and identify which one of those are they 
packaging in the distribution,how are they packaged in the distribution, 
are they affected by this change if so how are they affected by this 
change?

In addition to the data retention tools I mentioned there above we need 
to also look into which HIDS,NIDS and Common IDSs like but not limited 
to...|
|IPQ DBD
Fail2ban
Denyhosts
OSSEC
OpenVas
Tiger
Chrootkit
rkhunter
tripwire
osiris
samhain
etc

All of which might be depended on traditional log files

In addition to that we might also need to also check various monitoring 
tools like but not limited to
munin
nagios
zabbix
ximon
etc...

Then there are probably few applications out there we ship which do not 
fall into the above category but are crawling into those traditional log 
files.

Now the main argument of removing rsyslog all that I mentioned above 
that depends on traditional requires administrative installation and 
configuration thus it should not be a problem for administrator to 
install a tradition logger be rsyslog or syslog-ng at the same time they 
install and configure any of the previously mentioned stuff.

And that argument stands by itself but from my pov we should not only be 
focusing on that but rather be addressing the whole bigger picture.

That's the relevance

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130718/96bca0ce/attachment.html>