(RADIATOR) Rodopi & Radiator
Mike McCauley
mikem at open.com.au
Thu Feb 6 18:49:05 CST 2003
Hello Tim,
Thanks for the summary.
On Fri, 7 Feb 2003 11:08 am, Tim Jung wrote:
> Ok I called a buddy of mine who is more of an Microsoft dude that I am. He
> is an MSCE and MSCD. We confirmed that SQL is getting the command but it
> appears that either MS-SQL is waiting for some additional command or
> something before it starts the actual query, since it shows the query in
> lists of tasks but it never ends or starts or whatever.
OK, so the acess and permissions issue seems to be solved?
>
> Also I found out that Radiator does one of the strangest/poorest things I
> have ever seen in working with databases. Radiator depends on the default
> database that the login/account happens to be set to use. So when I kept
> getting unknown or missing stored procedure for the new "linux" account and
> the "sa" and all the other non-"rodopi" accounts it because those accounts
> didn't have their default database set to "AbacBill". When I set the
> default database on the "linux" account to "AbacBill" it too then started
> to hang and cause Radiator to appear to lock up.
>
> Also all users who have any "public" access to the "AbacBill" database have
> permissions to execute the stored procedures of "Interface_VircomUsers" and
> "Interface_VircomDetails" which are the only 2 procedures that Radiator
> uses in Rodopi. Also by default any owner of a database automatically has
> FULL access to the database the account owns. There would never be a
> permissions/security issue with a database and that database owner.
>
> I have confirmed that it appears that the DBD::Sybase stuff and FreeTDS
> stuff is working. It does send the login and password to the MS-SQL server
> correctly. It does send the request for the stored procedure to the MS-SQL
> server, but nothing appears to be happening after that for whatever reason.
> I show that MS-SQL does lock the database "AbacBill" and shows it got the
> command, but nothing happens. It also appears that Radiator doesn't
> time-out or detect a problem thus appears to hang forever.
Radiator should detect such a hung server.
The default timeout is 60 seconds, but you can change this with the Timeout
parameter in your AuthBy RODOPI clause.
>
> If someone wants to look at either the Windows 2000 server or the Linux box
> let me know. I have terminal services setup on Windows 2000 and SSH on the
> Linux box.
I think I would like to at least check the linux box, and use dbish to test
the behaviour of the SQL connection.
I dont understand why the stored procedure would hang forever unless it was
trying to gain access to some resource that never became available. Are you
able to see the code of the Rodopi stored procedure?
Cheers.
>
> So at this point I have no clue what to do to make this work. All I can say
> is that at this point it doesn't work for me basically.
>
> Tim Jung
> System Admin
> Internet Gateway
> tjung at igateway.net
>
>
> ----- Original Message -----
> From: "Mike McCauley" <mikem at open.com.au>
> To: "Tim Jung" <tjung at igateway.net>; <radiator at open.com.au>
> Cc: <hugh at open.com.au>; <dbirkbeck at ikano.com>
> Sent: Thursday, February 06, 2003 4:15 PM
> Subject: Re: (RADIATOR) Rodopi & Radiator
>
> > Hello Tim,
> >
> > On Fri, 7 Feb 2003 08:54 am, Tim Jung wrote:
> > > Ok I changed mt freetds.conf file to read:
> > > [rodopi]
> > > host = 206.142.60.100
> > > port = 1433
> > > tds version = 7.0
> > >
> > > Which makes it the exact same format as your listed freetds.conf file
>
> and
>
> > > it is still no go.
> > >
> > > Ok I removed the NT "rodopi" account so now there is only the "rodopi"
> > > account in SQL. The really interesting thing is that if I login as
>
> "rodopi"
>
> > > via SQL it causes Radiator to lock up. I get the trace below for the
>
> first
>
> > > test request and then nothing when I try to do a second request. So
>
> there
>
> > > is certainly something hosed on the Radiator/Linux side of things. Why
> > > would it let me login and then "lock up" when it tries to do the stored
> > > procedure?
> >
> > I dont understand that. It looks like the SQL server has locked or
>
> blocked
>
> > access to the stored procedure or the tables it accesses.
> >
> > Im pretty sure this is not due to a problem in Radiator or freetds, but
> > something about the SQL server configuration. Im not sure how to proceed
>
> from
>
> > here.
> >
> > Is it possible to get remote access to your Radiator host by ssh and/or
>
> your
>
> > SQL server by pcanywhere or whatever?
> >
> > Cheers.
> >
> > > Tim Jung
> > > System Admin
> > > Internet Gateway
> > > tjung at igateway.net
--
Mike McCauley mikem at open.com.au
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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list