(RADIATOR) ExpirationDate format crashes Util.pm

[Dave Kitabjian]

I have read all the release notes, but I'd like to ask just to be safe: there shouldn't be compatibility issues introduced by upgrading from 2.19 to 3.11, should there?

Dave

> -----Original Message-----
> From: Dave Kitabjian
> Sent: Wednesday, November 17, 2004 9:25 AM
> To: Hugh Irvine
> Cc: radiator at open.com.au
> Subject: RE: (RADIATOR) ExpirationDate format crashes Util.pm
> 
> Thanks, Hugh.
> 
> Let me see if we can schedule doing an upgrade across the board, and get
> back to you with the results...
> 
> Dave
> 
> > -----Original Message-----
> > From: Hugh Irvine [mailto:hugh at open.com.au]
> > Sent: Wednesday, November 17, 2004 12:56 AM
> > To: Dave Kitabjian
> > Cc: radiator at open.com.au
> > Subject: Re: (RADIATOR) ExpirationDate format crashes Util.pm
> >
> >
> > Hello Dave -
> >
> > Yes the new version should fix the problem.
> >
> > We would be grateful if you could do some testing for us and confirm.
> >
> > If there is still a problem we would be keen to fix it as always.
> >
> > The latest version is Radiator 3.11 (plus a few patches).
> >
> > regards
> >
> > Hugh
> >
> >
> > On 17 Nov 2004, at 07:07, Dave Kitabjian wrote:
> >
> > > Hey folks,
> > >
> > > We just had a problem yesterday that smoothly "failed over" from one
> > > Radiator box to another until they all "failed".
> > >
> > >  We introduced a software bug that started provisioning
> > > ExpirationDates in the following format:
> > >
> > > Mon Nov 15 14:30:33 2004: DEBUG: LDAP got nccheckitem:
> > > Expiration="12/18/2004"
> > >
> > > Rather than the "correct" format:
> > >
> > > Tue Nov 16 11:41:24 2004: DEBUG: LDAP got nccheckitem: Expiration="Nov
> > > 21 2005"
> > >
> > > The result was an error which I thought was in the logs, but must have
> > > been just to standard error, because today I can't find any record of
> > > it. It was from Util.pm and it was something about the "month" being
> > > out of the range "0..11". Sadly, it crashed Radiator completely L
> > >
> > > Now, we're running 2.19, and I found the below post in the archives.
> > > Does this mean that the new version of Util.pm on 3.6 fixes the
> > > behavior I'm describing?
> > >
> > > Thanks,
> > >
> > > Dave
> > >
> > > _________________
> > >
> > >
> > >
> > >  (RADIATOR) Re: check attribute expiration date
> > >
> > > ·       From: Mike McCauley
> > > ·       Subject: (RADIATOR) Re: check attribute expiration date
> > > ·       Date: Thu, 18 Sep 2003 00:18:41 -0700
> > >
> > >  Hello,
> > >
> > > WE have now added support for an optional time component in ValidFrom,
> > > ValidTo
> > >
> > >  and Expiration. Some valid examples are:
> > >
> > > Dec 30 1998
> > >
> > > Dec 30, 2000
> > >
> > > December 30, 2000
> > >
> > > Dec 30, 2000 11:30:00
> > >
> > > 2002-02-02 23:00:00
> > >
> > > 30/12/2002 01:00:00
> > >
> > > 30.12.2002
> > >
> > > There is a new version of Util.pm in the 3.6 patches area that
> > > supports all
> > >
> > >  these syntaxes.
> > >
> > > Please let me know how you go.
> > >
> > > Cheers.
> > >
> > > On Thu, 18 Sep 2003 04:18 pm, Bulent Gulcan wrote:
> > >
> > > > Hello again,
> > >
> > > >
> > >
> > > > Sorry, I could not find any date function for Microsoft SQL Server
> > > (our
> > >
> > > > database is MSSQL) to convert date to seconds.
> > >
> > > >
> > >
> > > > Is there a way to tell the radiator that the selected date is in
> > >
> > > > "dd.mm.yyyy hh:mm:ss" format and not ignore "hh:mm:ss" part. (Sorry
> > > I ask
> > >
> > > > this question again).
> > >
> > > >
> > >
> > > > I used in radius.cfg :
> > >
> > > > -------------------
> > >
> > > > <AuthBy SQL>
> > >
> > > > .......
> > >
> > > > DateFormat %d.%m.%Y %H:%M:%S
> > >
> > > > ........
> > >
> > > > AuthSelect
> > >
> > > > ..........
> > >
> > > > </AuthBy>
> > >
> > > > ------------------
> > >
> > > >
> > >
> > > > but this did not work.
> > >
> > > >
> > >
> > > > Thanks for your help, regards
> > >
> > > >
> > >
> > > > Bulent Gulcan
> > >
> > > > Is Net A.S.
> > >
> > > --
> > >
> > >  Mike McCauley                               [EMAIL PROTECTED]
> > >
> > > Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++,
> WWW
> > >
> > > 24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
> > >
> > > Phone +61 3 9598-0985                       Fax   +61 3 9598-0955
> > >
> > > Radiator: the most portable, flexible and configurable RADIUS server
> > >
> > >  anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > >
> > >  Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP,
> > > TLS,
> > >
> > >  TTLS, PEAP etc on Unix, Windows, MacOS etc.
> > >
> > > ===
> > >
> > > Archive at http://www.open.com.au/archives/radiator/
> > >
> > > Announcements on [EMAIL PROTECTED]
> > >
> > > To unsubscribe, email '[EMAIL PROTECTED]' with
> > >
> > > 'unsubscribe radiator' in the body of the message.
> > >
> > >
> >
> > NB:
> >
> > Have you read the reference manual ("doc/ref.html")?
> > Have you searched the mailing list archive
> > (www.open.com.au/archives/radiator)?
> > Have you had a quick look on Google (www.google.com)?
> > Have you included a copy of your configuration file (no secrets),
> > together with a trace 4 debug showing what is happening?
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> > -
> > Nets: internetwork inventory and management - graphical, extensible,
> > flexible with hardware, software, platform and database independence.
> > -
> > CATool: Private Certificate Authority for Unix and Unix-like systems.
> 
> 
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.