Re: [stellation-res] Command line configuration specification

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
Sent: Monday, January 13, 2003 2:04 PM
Subject: Re: [stellation-res] Command line configuration specification


> On Thu, 2003-01-09 at 17:55, Jonathan Gossage wrote:
> > I have just checked in a specification document for the command line
> > configuration stuff I proposed. It is misc/doc/specs/configuration.txt.
Your
> > comments will be most welcome before I proceed to implementation.
>
> I've got a couple of comments. It mostly seems good, but there are
> a few points where I found things either confusing, or where there are
> some details that I think were off.
>
> - There are a bunch of places where you say something along the
>   lines of "this value is required", and "this defaults to X". (For
>   example, the port that the client will use to connect to a server.)
>
>   I understand what you mean, but I find the wording very confusing.
>   When you say the value is required, it sounds like it's something
>   that the user/administrator is required to explicitly specify; saying
>   it has a default sounds like the system sets it automatically if it
>   isn't explicitly specified.

You interpreted it correctly. I will change the wording.

>
> - In the client connection information, you say that the port that the
>   Stellation server listens on is   database specific. It isn't: it's
>   server specific - but not database specific. What database you use
>   shouldn't have any effect on what port the Stellation server listens
>   on.

Cut and paste bit me.

>
> - You ask if we should merge the suffix and filetype stuff. I think
>   so. It's easier to specify a suffix than a regexp, which is, I think,
>   why the suffix stuff originally went in separate from the regex. But
>   once there's a decent config tool, there's no reason to not unify it,
>   and let the tool gloss over - that is, provide an option in the tool
>   for saying "any .foo file is binary", and have the tool expand that to
>   the regex ".*\.foo".
>
> - I don't think that the Eclipse team plugin should read the command
>   line config file. There's too much overlap between what we put in
>   those files, and stuff that Eclipse does itself. I think it's going to
>   get too complicated. Instead, I think we should let the Eclipse plugin
>   get its config from the Eclipse prefs, and store it in the Eclipse
>   metadata location.

You're right here.

>
> - I'm pretty sure that MySQL has a notion of a database name, and so
>   there should be an option to specify that.

If I remember correctly, this is managed within the Mysql configuration
files and is not exposed to the JDBC driver, but I will double check this.
>
> - In the Server-connect element of the config file: the intention is
>   to have a server listen on a single port: the login and subscription
>   process is how we distinguish a child server from a client. So there
>   shouldn't be a distinct port for accepting connections from children.

Is there any specs on this yet?

>
> - I'm a bit skeptical about encrypting the database admin password. The
>   question is, how do we encrypt it? I can't think of a way that won't
>   be easy to reverse engineer and determine the password. (For example,
>   we could hardcode a password when we compile the server, but then that
>   password can be found by looking at the .class file. We could encrypt
>   that, but then it's still not too hard to find a way to figure out how
>   we did that, and get *that* password. It seems to me that ultimately,
>   unless we require the administrator to specify a password when they
>   start the server (which precludes automatically starting servers),
>   then we are ultimately relying on the fact that the config file is
>   secured. Putting the encryption in is giving people a false sense of
>   security that they don't really need to be so careful of protecting
>   their server config file.

It only provides light security. All it can do is prevent browsing
plain-text files to prevent casual snooping. In general it is not possible
to provide any serious security in environments where debuggers or other
observational tools can be run. That being said, 90% of attempts to crack
security can be stopped by simple measures such as not leaving plain-text
passwords lying around.
>
> -Mark
>

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx