Hi Hugh,
I think the cause of the problem is probably the existence of all
the rc scripts which are auto-configured when on uses an RPM install
for example coupled with the restartwrapper entry in rc.local
Though I haven't tried it but I would guess that one shouldn't (be able to)\
use a restartwr
Hello Tunde -
I always recommend using the source tarball for better control.
regards
Hugh
On Monday, Feb 3, 2003, at 19:56 Australia/Melbourne, Ayotunde Itayemi
wrote:
Hi Hugh,
I think the cause of the problem is probably the existence of all
the rc scripts which are auto-configured when
Title: RE: (RADIATOR) radiator stops ...
> Of course Easysoft OOB is even better as far as
> compatibility/reliability are concerned, albeit at a higher cost.
You're kidding, right?
In production use, Easysoft is absolutely lovely bar for one minor 'feature' (at least in the version I had)
Hello Claudio,
thanks for your contribution. Added to the goodies for the next release, also
in the 3.5 patches.
Thanks again to you and German.,
Cheers.
On Mon, 3 Feb 2003 02:47 pm, Claudio Lapidus wrote:
> Hello Toomas et al.
>
> Sorry for not answering your first post earlier, I unattended
Matthew Trout wrote:
> > Of course Easysoft OOB is even better as far as
> > compatibility/reliability are concerned, albeit at a higher cost.
>
> You're kidding, right?
>
> In production use, Easysoft is absolutely lovely bar for one minor 'feature'
> (at least in the version I had) - if the NT
Title: RE: (RADIATOR) radiator stops ...
> -Original Message-
> From: 'Dan Melomedman' [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 03, 2003 2:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) radiator stops ...
>
>
> Matthew Trout wrote:
> > > Of course Easysoft OOB is
>
> Hmm ... I guess the answer is YMMV, then.
>
> To anyone looking for solutions like this, I would say that Easysoft were
> very helpful getting their stuff up and running, and your best bet is
> probably to try both. It was certainly better than Openlink, and I believe
> their pricing is more
Hello Petri,
thanks for the patch. We have applied it for both the SQL and file cases.
We have rolled it in for the next release, and included it in the 3.5 patches
area.
Thanks again.
Cheers.
On Mon, 3 Feb 2003 07:44 pm, [EMAIL PROTECTED] wrote:
> From [EMAIL PROTECTED] Mon Feb 3 02:44:07 2
I'm fighting a problem where I get a stop record, but the session record (mysql) is
not getting deleted. This is happening very intermittently and only from my Qwest
users.
Has anyone seen this? I haven't done the trace yet, but there is no errors in my
logfile. Also, I'm still using the defaul
Hi
I have a number of 3com Hipers as well a a Cisco as5300 and an SQL-based
session database to check Max sessions. I am really being troubled by cases
of stale sessions, and someone mentioned that I can use SNMP to check
whether the sessions are indeed genuine (i.e by querying the Nas).
Can some
Hello Tom -
As you say, we will need to see a copy of the configuration file (no
secrets) together with a trace 4 debug from Radiator showing what is
happening. Many operators don't look at starts or alives, they just
keep stop records. As for the delete query, it really only should be
NAS-Id
Hello -
You should add a NasType parameter to your Client clauses and configure
the NAS's to accept the corresponding queries.
Have a look at section 6.5.5 in the Radiator 3.5 reference manual
("doc/ref.html").
This topic has also been discussed many times on the mailing list.
www.open.com.
12 matches
Mail list logo
