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