Thread: postmaster dead on startup from unportable SSL patch
Someone had the bright idea that the postmaster's -i switch could
be redefined as
-i same as it ever was
-is accept only SSL connections
Unfortunately, implementing that requires a getopt() that understands
the GNU double-colon extension ("i::"). HPUX's getopt, which claims
to be fully conformant to POSIX.2 and about six other standards,
doesn't grok it. Net result: postmaster is quitting on startup with
a "usage" message for me. Doubtless it will also fail on most other
non-GNU-libc platforms.
Unless we want to get into the business of supplying a substitute
optarg() library routine, we're going to have to pick a more portable
switch syntax for SSL. (I might also point out that "-is" used to
have a quite different interpretation, ie "-i -s", which could trip
up someone somewhere.)
I can see two reasonable choices: (a) pick a currently-unused
switch letter that you specify *in addition to* -i, if you want
only secure connections; (b) pick a currently-unused switch letter
that you specify *instead of* -i, if you want only secure connections.
I'd lean towards (a) except that both of the obvious choices, -s and -S,
are already taken. If we go with (b), -I is available and perhaps not
a totally off-the-wall choice, but I can't say I really like it.
Comments? Ideas? Is it time to give up on getopt and go to multiletter
switch names? (Of course that would break a lot of people's startup
scripts... but we may someday be forced into it... maybe it's better
to bite the bullet now.)
regards, tom lane
> Comments? Ideas? Is it time to give up on getopt and go to multiletter
> switch names? (Of course that would break a lot of people's startup
> scripts... but we may someday be forced into it... maybe it's better
> to bite the bullet now.)
Break it ;)
The single-character switches are definitely non-intuitive. Implement
-I for now if you want, but if/when we release v7.0 breakage should be
OK. And with Jan's and Vadim's projects (among others) it looks like
v7.0 is coming up soon :)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> Someone had the bright idea that the postmaster's -i switch could
> be redefined as
> -i same as it ever was
> -is accept only SSL connections
>
> Unfortunately, implementing that requires a getopt() that understands
> the GNU double-colon extension ("i::"). HPUX's getopt, which claims
> to be fully conformant to POSIX.2 and about six other standards,
> doesn't grok it. Net result: postmaster is quitting on startup with
> a "usage" message for me. Doubtless it will also fail on most other
> non-GNU-libc platforms.
>
> Unless we want to get into the business of supplying a substitute
> optarg() library routine, we're going to have to pick a more portable
> switch syntax for SSL. (I might also point out that "-is" used to
> have a quite different interpretation, ie "-i -s", which could trip
> up someone somewhere.)
-is is a totally broken option flag.
>
> I can see two reasonable choices: (a) pick a currently-unused
> switch letter that you specify *in addition to* -i, if you want
> only secure connections; (b) pick a currently-unused switch letter
> that you specify *instead of* -i, if you want only secure connections.
>
> I'd lean towards (a) except that both of the obvious choices, -s and -S,
> are already taken. If we go with (b), -I is available and perhaps not
> a totally off-the-wall choice, but I can't say I really like it.
I like option (a). Just pick any letter for the additional SSL flag
. It is SSL, you can use -L or -l. I would like to keep -i as
required, so when we tell people they have to use -i, they really have
to use -i for INET connection, not -i or -L.
>
> Comments? Ideas? Is it time to give up on getopt and go to multiletter
> switch names? (Of course that would break a lot of people's startup
> scripts... but we may someday be forced into it... maybe it's better
> to bite the bullet now.)
No, I don't think so. long opt names are more a headache than just
picking any new letter.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
On Sep 30, Thomas Lockhart mentioned: > > Comments? Ideas? Is it time to give up on getopt and go to multiletter > > switch names? (Of course that would break a lot of people's startup > > scripts... but we may someday be forced into it... maybe it's better > > to bite the bullet now.) > > Break it ;) > > The single-character switches are definitely non-intuitive. Implement It's a backend people! My man page shows 12 defined switches, so there are at least 44 character switches left. A little imagination please. I am implementing GNU style long options in psql but obviously that sort of thing won't help anybody that doesn't have a GNU'ish system, in particular the people affected by the -is thing in the first place. Or do you *really* want to get into the business of writing your own getopt replacement??? Then you are liable to end up with something even less intuitive. Meanwhile, how about something like -i for normal and -i SSL for what's desired. (That is, change the "i" to "i:"). Then, if someone comes up with something related (accept only ssh, ipv6, latest pgsql protocol, etc. connections), you save a switch. Peter -- Peter Eisentraut - peter_e@gmx.net http://yi.org/peter-e
Thus spake Peter Eisentraut > > The single-character switches are definitely non-intuitive. Implement > > It's a backend people! My man page shows 12 defined switches, so there are > at least 44 character switches left. A little imagination please. My take is that on the CL I want single character flags for speed of entry and in startup scripts I can comment if neccesary. > Or do you *really* want to get into the business of writing your own > getopt replacement??? Then you are liable to end up with something even > less intuitive. Well, in fact I do and have. :-) See http://www.druid.net/~darcy/files/getarg.c for a different type of getopt. It uses a different programmer API to add some functionality but looks the same to the user unless they know about the extras. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Peter Eisentraut <peter_e@gmx.net> writes:
>> The single-character switches are definitely non-intuitive. Implement
> It's a backend people! My man page shows 12 defined switches, so there are
> at least 44 character switches left. A little imagination please.
It's true that the postmaster isn't something you normally start by
hand, but the other side of that coin is that startup scripts are
usually made by people when they are new to Postgres, and it's not
hard to make a mistake...
> I am implementing GNU style long options in psql but obviously that sort
> of thing won't help anybody that doesn't have a GNU'ish system, in
> particular the people affected by the -is thing in the first place.
>
> Or do you *really* want to get into the business of writing your own
> getopt replacement???
Er, you had better be writing your own getopt replacement if you want
to provide GNU-style options in psql. Or have you forgotten that the
code must be portable to non-GNU platforms? I don't think it would be
a good idea to support long options only on boxes with a suitable
getopt, either. That would create a documentation, scripting, and
support nightmare (because the same psql command line would work for
some people and not others).
If it weren't for the license conflict between BSD and GPL, I'd suggest
just dropping GNU getopt into the Postgres distribution, but having
GPL'd code in the distribution is a can of worms we'd best not open.
> Meanwhile, how about something like -i for normal and -i SSL for what's
> desired. (That is, change the "i" to "i:").
I tried that before I realized what the i:: was all about, but it still
breaks existing startup scripts, because i: means that there *must* be
an argument to -i --- so if you write something like -i -o "backend switches"
the -o gets swallowed as the argument to -i, and chaos ensues.
I do like the notion of specifying SSL as the argument of some new
switch letter, so that we have a way to add more connection
methods without using up more switch letters...
regards, tom lane
On Oct 2, Tom Lane mentioned: > Er, you had better be writing your own getopt replacement if you want > to provide GNU-style options in psql. Or have you forgotten that the > code must be portable to non-GNU platforms? I don't think it would be > a good idea to support long options only on boxes with a suitable > getopt, either. That would create a documentation, scripting, and > support nightmare (because the same psql command line would work for > some people and not others). Naturally this whole thing will be #ifdef'ed out and depending on an autoconf test for getopt_long. Also there will be a short option for every long one and vice versa. I also gave the documentation issue some thought and I agree that this might not be fun to support. But then I don't really see too many support questions regarding psql _invocation_. At this point I'm just going to leave it undocumented, pending further complaints. I just like the self-documenting elegancy of $ psql --host=localhost --port=5432 --dbname=foo --username=joe --from-file=myfile.sql --out-file=result.txt But you can also get (actual output): $ ./psql --list This version of psql was compiled without support for long options. Use -? for help on invocation options. It's not too hard to check for that: just include "-" in your options list for the regular getopt. > If it weren't for the license conflict between BSD and GPL, I'd suggest Okay, while we're at it: Someone wrote me regarding readline (GPL) vs libedit (BSD). If you look at the code, readline is pretty deeply integrated. This is almost the same issue. But there has not been any support nightmare I was aware of. On the other hand there are even backslash commands (\s) that only work with readline. I even wrote an SQL-aware readline tab completion which I intend to incorporate in one form or another. This is true added functionality, while you might get away with saying that long options are just a toy. And of course we don't even want to talk about the requirements regarding GNU make, GNU flex, GNU tar, or this whole autoconf business. Of course, we could write ./configure -e locale -w perl, but that's no fun . . . -- Peter Eisentraut - peter_e@gmx.net http://yi.org/peter-e