On 08/30/2011 06:58 PM, Duncan Mac-Vicar P. wrote:
An alternative implementation we may consider for a second iteration is
to have Spacewalk send the messages via AMPQ to a broker (apache QPid
seems to have a reasonable footprint), and the current daemon could
fetch from there to the outputs, tur
On 08/29/2011 03:14 PM, Cliff Perry wrote:
In short, my personal preference is not to become a toaster if audit
logging has crashed (including out of space to write).
Cliff,
if Taskomatic has crashed, the Spacewalk will be a toaster as well.
I believe the reliability is a different topic.
--
B
On Tue, Aug 30, 2011 at 05:29:48PM +0200, Miroslav Suchý wrote:
> On 08/30/2011 12:06 PM, Jan Pazdziora wrote:
> > To achieve that, I'll gladly review a patch which will add logging
> > triggers to all tables that we have in the schema, together with
> > initial insert to a central log table with i
On 08/29/2011 03:14 PM, Cliff Perry wrote:
In short, my personal preference is not to become a toaster if audit
logging has crashed (including out of space to write).
An alternative implementation we may consider for a second iteration is
to have Spacewalk send the messages via AMPQ to a broke
On 08/30/2011 01:51 PM, Jan Pazdziora wrote:
Sure. I'm just pointing out that you might save yourself some
architecture and coding work if you consider the bigger picture and
goals of the project and not just blindly focus on the narrow goal you
have on your plate right now.
The narrow goal tha
On 08/30/2011 12:06 PM, Jan Pazdziora wrote:
> To achieve that, I'll gladly review a patch which will add logging
> triggers to all tables that we have in the schema, together with
> initial insert to a central log table with identity/timestamp/remote
> host/user agent/whatever information.
How wo
On 08/30/2011 02:14 PM, Jan Pazdziora wrote:
But Bo Maryniuk said in the initial post:
Q: Does it takes care of being tamper-proof?
A: No. The software component is responsible only to collect various
You cannot access it as a spacewalk admin.
--
Bo Maryniuk
SUSE LINUX Products GmbH, Maxfel
On Tue, Aug 30, 2011 at 01:51:49PM +0200, Klaus Kaempf wrote:
> * Jan Pazdziora [Aug 30. 2011 12:07]:
> >
> > Currently, every Spacewalk component talks to one datastore, the
> > underlying database. Why cannot that component log directly to the
> > database to which it already has open connectio
* Jan Pazdziora [Aug 30. 2011 12:07]:
>
> Currently, every Spacewalk component talks to one datastore, the
> underlying database. Why cannot that component log directly to the
> database to which it already has open connection, rather than trying
> to log to another daemon which might be down?
O
On Tue, Aug 30, 2011 at 01:31:49PM +0200, Bo Maryniuk wrote:
> On 08/30/2011 12:46 PM, Jan Pazdziora wrote:
> >I'd much rather see a patch which would [...] finish
> >the Perl-to-Java migration of the outstanding .pxt Web pages.
>
> The topic is about Audit logging right now and you have your own
On Fri, Aug 26, 2011 at 04:10:03PM -0400, Cliff Perry wrote:
>
> Do you do it within the schema (and loose the who from where did what -
> unless all app code passes it down to DB).
No. You do it once, at the start of the HTTP request handling, store
that to the database and use identifier throug
On 08/30/2011 12:46 PM, Jan Pazdziora wrote:
I'd much rather see a patch which would [...] finish
the Perl-to-Java migration of the outstanding .pxt Web pages.
The topic is about Audit logging right now and you have your own
personal opinion on this. There will be always various ideas, of
cour
On Thu, Aug 25, 2011 at 02:30:51PM +0200, Johannes Renner wrote:
>
> Well, the general 'problem' is that Spacewalk consists of a lot of
> different components and this audit log should gather log events coming
> from these sources (web ui, frontend api, backend api, taskomatic),
> while sending th
On Wed, Aug 24, 2011 at 01:49:27PM +0200, Bo Maryniuk wrote:
> On 08/24/2011 01:20 PM, Tomas Lestach wrote:
> >what was the original use/business case for the audit logging add-on?
> To know who did what, when and from where.
To achieve that, I'll gladly review a patch which will add logging
trigg
On Tue, Aug 23, 2011 at 06:26:18PM +0200, Bo Maryniuk wrote:
>
> The main core of the logger is a separate daemon that serves XML-RPC
> listener to a localhost only. Then each software component in the
> Spacewalk is going to send an logging event message through it.
Currently, every Spacewalk co
On 08/29/2011 04:32 PM, Ionuț Arțăriși wrote:
> So if the auditlogging server is down, then the XMLRPC API is down. The
whole point of audit logging is to not let anything "important" pass
through without having a record of it. You can of course turn the
logging off from the server.
And someho
On 08/29/2011 03:14 PM, Cliff Perry wrote:
One of the main design decisions I would consider for behaviour is...
If the logging daemon is down, do all actions fail - or do you still
allow successful actions, knowing that it cannot log the event.
- Or do you have a fall-back temporary on-disk c
On 08/29/2011 08:01 AM, Ionuț Arțăriși wrote:
> Just to add to the discussion, I'll tell you how I thought about logging
> the python backend XMLRPC API calls. This needs a lot less filtering
> than logging the WebUI though, since we're interested in most of the
> methods, so it's a lot easier.
>
Just to add to the discussion, I'll tell you how I thought about logging
the python backend XMLRPC API calls. This needs a lot less filtering
than logging the WebUI though, since we're interested in most of the
methods, so it's a lot easier.
We decided we only wanted to log successful API call
On 08/25/2011 11:43 AM, Miroslav Suchý wrote:
> On 08/25/2011 02:30 PM, Johannes Renner wrote:
>
>> - While most of the struts actions are RhnAction or RhnLookupDispatchAction,
>> there is still some that are not derived from these classes. Therefore it's
>> not enough to put a shortcut metho
On 08/26/2011 03:10 PM, Johannes Renner wrote:
> I got the idea and I was even researching such an approach already. For the
> webapp I started with a ServletFilter (see my attached patch as an example)
> that simply logs all POST requests to the backend using my helper classes
> from the patches I
On 08/26/2011 11:02 AM, Miroslav Suchý wrote:
> On 08/25/2011 06:55 PM, Johannes Renner wrote:
>> Well, I can count three, while only one (!) of them is public. But we
>> can still rename the other ones, no problem.
>
> I count:
> private static Logger log = Logger.getLogger(AuditLog.LOGGER_NAME
On 08/25/2011 07:10 PM, Bo Maryniuk wrote:
> I thought the patches reviews you, guys, doing are more than just
> works/not-works?
Well in general we reserve right to reject it, if we find some things,
which we dislike.
It is the same as in kernel. You did not get anything in kernel if it
just work
On 08/25/2011 07:10 PM, Bo Maryniuk wrote:
> I thought the patches reviews you, guys, doing are more than just
> works/not-works?
Not exactly. This is true for small bugs. E.g there is some bug in
Spacewalk. Somebody diagnose it, create patch and sent it here (unless
he is proved Spacewalk contrib
On 08/25/2011 06:55 PM, Johannes Renner wrote:
> Well, I can count three, while only one (!) of them is public. But we
> can still rename the other ones, no problem.
I count:
private static Logger log = Logger.getLogger(AuditLog.LOGGER_NAME);
as well.
> - How can you distinguish between intere
On 08/25/2011 05:43 PM, Miroslav Suchý wrote:
AuditLog.java has 4 (!) functions log() and all of them has different
semantics - if I ommit that they are utilized to logging. Please
consider different names.
Four? Functions?.. I see three and they are methods, where only one is
public. This is c
On 08/25/2011 05:43 PM, Miroslav Suchý wrote:
> On 08/25/2011 02:30 PM, Johannes Renner wrote:
>> So (1.) there are some helper classes that I put into a new separate
>> package, see 01-new-classes.patch:
>
> AuditLog.java has 4 (!) functions log() and all of them has different
> semantics - if I
On 08/25/2011 05:28 PM, Bo Maryniuk wrote:
>> I.e. if I do some changes through
>> backend it will not be logged?
> No, they will.
Well we have users with tens thousands or registered machines. And they
can easily create hundreds and even thousands request in the same time.
So human admin is not
On 08/25/2011 02:30 PM, Johannes Renner wrote:
> So (1.) there are some helper classes that I put into a new separate
> package, see 01-new-classes.patch:
AuditLog.java has 4 (!) functions log() and all of them has different
semantics - if I ommit that they are utilized to logging. Please
consider
On 08/25/2011 04:18 PM, Miroslav Suchý wrote:
You want to audit just frontend?
No, everything.
I.e. if I do some changes through
backend it will not be logged?
No, they will.
--
Bo Maryniuk
SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Fe
On 08/24/2011 01:57 PM, Bo Maryniuk wrote:
> Well, if your admin can do more than 2000 changes-per-second,
> then just let me know... :)
You want to audit just frontend? I.e. if I do some changes through
backend it will not be logged?
--
Miroslav Suchy
Red Hat Satellite Engineering
On 08/24/2011 01:41 PM, Miroslav Suchý wrote:
Q: Why not just another log appender?
A: We believe it should be generic, agnostic and reliable. Hence
the embedded database and thread black magic are involved among other
things. :)
This is where I disagree. But I would like to see your code and m
On 08/24/2011 01:20 PM, Tomas Lestach wrote:
what was the original use/business case for the audit logging add-on?
To know who did what, when and from where.
How do you plan to present the audit information?
I plan to send it where it is needed in the way the destination is
asking. So it depe
On 08/23/2011 06:26 PM, Bo Maryniuk wrote:
> Entire Spacewalk components are going to be altered, where each
> audit-able action will perform a call. We already developed an log4j
> appender and now processing all Java part and XML-RPC backend and a
> frontend. This will help community to reconnect
Hey Bo,
what was the original use/business case for the audit logging add-on?
How do you plan to present the audit information?
Regards,
Tomas
--
Tomas Lestach
RHN Satellite Engineering, Red Hat
On 08/23/2011 06:26 PM, Bo Maryniuk wrote:
Hi, all!
Here at SUSE we are working on an audit loggi
Hi, all!
Here at SUSE we are working on an audit logging. As we all perfectly
know, the Audit Logging is not just a logging in the sense as a syslog
for like debugging or alerting etc.
We developing an add-on for the Spacewalk. It should collect events from
various components and then bring the
36 matches
Mail list logo
