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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
