I would like to humbly suggest that Epylog be included into Fedora Core
-- not in the current test, of course, but some time in the future.
What it is:
Epylog is a syslog parser which runs periodically, looks at your logs,
processes some of the entries in order to present them in a more
comprehensible format, and then mails you the output. It is written
specifically for large network clusters where a lot of machines (around
50 and upwards) log to the same loghost using syslog or syslog-ng. It is
an alternative to a similar package called LogWatch.
See more: http://linux.duke.edu/projects/epylog/
1. Written in Python (2.2 and above)
2. Written specifically for Red Hat Linux 7.x and above.
4. Actively maintained
5. Sends log reports in both HTML and plaintext.
6. Can publish reports to a location instead of mailing them, with
optional notification via email about new reports available.
7. Memory footprint is kept small at all times, despite the size of logs
(which may be hundreds of megabytes in size)
8. Robust and easily extensible using pluggable parsing modules.
9. Parsing modules can be written in Python, or in fact any other
language, using the external module API.
10. Been used extensively to do log reporting for large cluster
installations at Duke and several other EDUs.
11. Graphical front-ends to it do not exist at the moment, but should be
simple to write. Theoretically, it could be a replacement/extension for
1. It's a relatively obscure application largely not known outside Duke
2. Though it's been in use for over a year at Duke, it's not well tested
in a large variety of situations.
3. Parsing modules do not exist for other platforms where syslog strings
may differ from the ones in Linux/Fedora.
4. Due to threading and speed optimizations, Python parsing module API
is not very easy to grok. :/
Please see the website for more information. I would be willing to be
the Fedora package maintainer for it.
Konstantin ("Icon") Riabitsev
Duke Physics Sysadmin, RHCE
>From: Nils Philippsen <nphilipp(a)redhat.com>
>Subject: Re: fedora only for US users ?
>Date: Sat, 27 Sep 2003 11:47:00 +0200
>On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote:
> > this message is a little hard but :
>I wouldn't say it's hard, I would say these are bug reports. Consider
>checking the various Bugzillas for these and submitting reports if
>they're not in there already.
> > - at first time wizard, keyboard configuration is US, not the selected
> > language at install.
>Bug. --> bugzilla.redhat.com
> > - mozilla is only configured for US (language for web page, interface),
> > selected language at install have no importance.
>Upstream bug I guess (is Mozilla multi-language aware? I don't see any
>message catalogs...). --> bugzilla.mozilla.org
Here the .xpi for Mozilla 1.4 french language :
Here the line for "language for web page" in
user_pref("intl.accept_languages", "fr, en-us, en");
Can't prefs.js with the good language value be added in /etc/skel ?
> > - evolution's meteo is Boston US, I have selected an other city in
bug reported too in bugzilla.
MSN Messenger 6 http://g.msn.fr/FR1001/866 : dialoguez en son et en image
avec vos amis.
Would it make sense to add the rpm version-release strings in the OpenSSH,
Apache, etc. banners, e.g. like..:
instead of just:
.. this should be rather straightforward for the build process.
The gain would be that if you e.g. perform security scans in your network
you could identify whether a patched version has been installed in the
systems in question..
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
I see that Severn 2 still has OO 1.0.2 in it. Any chance we'll
see a OO 1.1rcX rpm for testing soon?
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
On Fri, 2003-09-26 at 11:30, Pekka Savola wrote:
> Would it make sense to add the rpm version-release strings in the OpenSSH,
> Apache, etc. banners, e.g. like..:
> SSH-1.99-OpenSSH_3.5p1 3.5p1-11
> instead of just:
> .. this should be rather straightforward for the build process.
> The gain would be that if you e.g. perform security scans in your network
> you could identify whether a patched version has been installed in the
> systems in question..
And so could an attacker.
Making sure your network is up2date is probably best resolved at some higher
Assursys are evaluating the viability of providing back-ported errata
packages for Red Hat Linux releases that have reached their official
End-of-Life, such as the 7.3 and 7.2 releases.
If this service is of interest to your organisation, please get in touch
(either privately, or on this list); we're particularly interested in
hearing which releases we should prioritise on (our hunch is 7.3, 7.2, 8,
7.0, in that order), and how much such a service is worth to your
At present, for insurance reasons, we can only offer such a service to EU