Skip to Content.
Sympa Menu

freetds - Re: Proposed new FreeTDS configuration format

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Proposed new FreeTDS configuration format
  • Date: Wed, 30 May 2001 09:07:08 -0500 (CDT)


On Wed, 30 May 2001, James K. Lowden wrote:

> > # The conf file format follows a modified Windows INI style (or Samba
> > style if
> > # you prefer to think of it that way). There is a [global] section which
> > will
> > # affect all dataservers or basic program behaviour, and a section headed
> > with
> > # the dataserver's name which will have settings which override the global
> > # ones.

> I vote for [global] cf. Samba if it's still up for debate. Since James's
> main concern was having a database by that name, and the more like Samba it
> is, the better. For instance, Samba uses the name "workgroup" where you've
> opted for "nt domain". I think the latter is clearer, but might Samba
> alignment pay off later?

The 'workgroup' keyword in Samba's config is in fact badly overloaded, and the
meaning has been hotly contested in the past. In the case of FreeTDS, this
keyword is being used /only/ to specify an NT domain: there's nothing
workgroupish about it, so I think calling it 'workgroup' is rather confusing
for anyone not coming at this with a background in Samba.

> 1. FreeTDS should mimic the behavior of the native client insofar as
> possible, and require as little of the user as possible. For instance, why
> should the library need a {try | don't try} option for domain/server
> authentication? Why not: Just Try? The MS client uses trusted logins for
> any connection for which the client doesn't explicitly set a username. And
> it definitely *should* be per-connection. The trusted login is a kind of
> default environment; overriding it with a username is useful to alter the
> privileges of a particular application or interactive session.

The only clients I've been able to test with so far were Win98 clients; there,
when you set up a DSN you are /asked/ whether to use domain login (if
available) or server login. This suggests me that authentication isn't truly
being negotiated automatically, although if you have a different experience
with different clients I'd be interested to hear of it. (I'm also curious to
know if, e.g., NT clients will negotiate NTLMv2 auth.)

The benefit to specifying auth type explicitly in the config file is that
you as the sysadmin may know things about site policy that FreeTDS can never
determine automatically, and you can make this information available to
FreeTDS. For instance, you may have a server that you know can't/shouldn't
negotiate NTLMSSP. Turning off domain auth for this server entry in the conf
file will speed up authentications a little bit, but more importantly it'll
make the SQL server's logs much less spammy with failed authentications,
making it a more useful audit tool. On the other hand, you may have a server
that you know supports NTLMSSP, and you never want your clients to fall back
on the less secure server auth. Or maybe you value flexibility over security,
and you do want a fallback mechanism -- it's your choice.

> 3. I suggest we dump interfaces completely. Sybase did, Microsoft did.
> It's a dodo. I'll send you some perl (or C++, if need be) to convert an
> interfaces file to a skeleton freetds.conf if you think it could be
> incorporated into the FreeTDS installation.

If you write the code to do this (perl, please), I'd gladly use it in the next
release of the Debian packages.

> 4. If we dump interfaces, we can do away with $SYBASE, too. Why not
> replace it with $FREETDS, pointing to freetds.conf? If ~/.freetds.conf is
> honored before $FREETDS/freetds.conf, we can dump all the environment
> variables.

I think backwards-compatibility is important here. We should prefer the use
of the new freetds.conf format, but if someone's still using
$SYBASE/interfaces, why drop support for it?

> In sum, freetds.conf is flexible enough to incorporate all the environment
> variables (including $SYBASE) and the interfaces file. It should contain
> what the user knows or can ascertain about his environment. Authentication
> should be per-connection, relying on trusted logins in the absence of a
> username.

Ah, 'trusted logins' are possible in Windows because the client OS caches your
network credentials for you. We don't have this on a Unix system, so unless
Brian's getting very ambitious here :), the client app will still always have
to supply the username & password, even in domain auth mode.

Steve Langasek
postmodern programmer





Archive powered by MHonArc 2.6.24.

Top of Page