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