new argus-clients beta.38 on server
Carter Bullard
carter at qosient.com
Fri Jan 10 01:49:30 EST 2003
I've uploaded beta.38 to ftp://qosient.com/dev/argus-2.0.
It's not a big deal at all to generate a distribution tar,
I was just trying to be lazy ;o)
Carter
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> Andrew Pollock
> Sent: Friday, January 10, 2003 12:04 AM
> To: Carter Bullard
> Cc: 'Argus'
> Subject: Re: new argus-clients beta.37 on server
>
>
> On Thu, Jan 09, 2003 at 11:23:41PM -0500, Carter Bullard wrote:
> > Hey Andrew,
> > It should be 38, but I messed up. Since I hadn't actually
> > announced 37, can we just leave the new one as 37? Sure makes it
> > easier.
>
> It buggers me up, because I have released a Debian package of
> 37 to the
> world, and so all I can do is release another revision of
> that, but it's
> really a new upstream release, not a Debian revision of
> existing upstream
> release.
>
> I'd like to package up the fixed version ASAP so I can use
> it, so if you
> can make it 38, that would make everything okay.
>
> > Indeed, it is just a client problem. All the argus data
> is fine,
> > just clients selecting records based on time have problems,
> and only
> > since the New Year, and it should be pretty rare. Let me give you
> > some background so you can evaluate the impact.
> >
> > The -t option allows you to specify a complete time or a partial
> > time range. The time range 01/03.12:00:00-12:01:00 which you were
> > using, is a partial time range, since the year is not
> specified. The
> > filter can match Jan 03, 12pm for any year that is presented to the
> > filter. This is a good thing if you want to compare a time range
> > between days, months, etc...
> >
> > The bug was such that we would update the year field in the
> > comparison buffer only if the day of the month in the
> current record
> > was different from the day of the month in the previous record (it
> > should have been day of the year). Because the first record in an
> > argus stream is a management record, and the startime in a
> management
> > record is the time when the probe was started, when we went
> from 2002
> > to 2003, the management record and the data records would have
> > different years. We would have a real problem if the probe
> > was started on the same day of the month as the timestamp
> > in the first data record in the file, but occurred in
> > different years. As soon as a record arrived that was on
> > a different day of the month, things would clear up.
> >
> > So the answer is, this bug should have been an issue
> > only since the New Year.
>
> Excellent, I'm not impacted terribly badly at all then.
>
> > Carter
> >
> >
> >
> > > -----Original Message-----
> > > From: Andrew Pollock [mailto:andrew-argus at andrew.net.au]
> > > Sent: Thursday, January 09, 2003 5:24 PM
> > > To: Carter Bullard
> > > Cc: 'Argus'
> > > Subject: Re: new argus-clients beta.37 on server
> > >
> > >
> > > On Thu, Jan 09, 2003 at 03:48:09PM -0500, Carter Bullard wrote:
> > > > Gentle people,
> > > > In the spirit of all new year's resolutions, a new beta
> > > release of
> > > > argus-clients is available as
> > > >
> ftp://qosient.com/dev/argus-2.0/argus-clients-2.0.6.beta.37.ta
r.gz
> >
> > Umm, should that be beta.38, since there's already been a
> > (different) beta.37?
> >
> > > This version fixes some major problems with time argument
> > parsing that
> > > occur, interestingly enough, when the year number changes.
> > Please give
> > > this version a whirl, and if it works out, I'll incorporate
> > the mods
> > > into the argus-2.0.6 release that I'm putting out next week.
> >
> > So what's the extent of the impact of that bug? Just data
> > collected in
> > 2003?
> >
> > > Hope all is well!
> > >
> > > Carter
> > >
> >
>
More information about the argus
mailing list