On 02/11/2010 05:12 PM, Bart Samwel wrote:
On Thu, Feb 11, 2010 at 23:01, Mark Mielke <m...@mark.mielke.cc
<mailto:m...@mark.mielke.cc>> wrote:
On 02/11/2010 04:54 PM, Bart Samwel wrote:
ISSUE #3: Multiple hostnames?
Currently, a pg_hba entry lists an IP / netmask combination.
I would suggest allowing lists of hostnames in the entries,
so that you can at least mimic the "match multiple hosts by
a single rule". Any reason not to do this?
I'm mixed. In some situations, I've wanted to put multiple
IP/netmask. I would say that if multiple names are supported,
then multiple IP/netmask should be supported. But, this does
make the lines unwieldy beyond two or three. This direction
leans towards the capability to define "host classes", where
the rules allows the host class, and the host class can have
a list of hostnames.
Yes, but before you know it people will ask for being able to
specify multiple host classes. :-) Quite simply put, with a
single subnet you can allow multiple hosts in. Allowing only a
single hostname is a step backward from that, so adding support
for multiple hostnames could be useful if somebody is replacing
subnets with hostname-based configuration.
This implies two aspects which may not be true:
1) All hosts that I want to allow belong to the same subnet.
2) If I trust one host on the subnet, then I trust all hosts
on the subnet.
While the above two points are often true, they are not
universally true.
I don't think we're talking about the same thing here. I wasn't
suggesting doing hostname-plus-netmask. NO! I was suggesting that
where a lazy sysadmin would previously configure by subnet, they might
switch to more fine-grained hostname-based configuration ONLY IF it
doesn't require duplicating every line in pg_hba.conf for every host
in the subnet.
Ah yes. You are focusing on allowing a netmask to expand to hostnames.
I'm focusing on how netmasks were never that great on their own.
You want to allow multiple hosts - I want you to allow multiple
netmasks. I think the requirement is the same. I also think that "same
line" has always been an annoying restriction. I have many duplicated
lines today just for:
host DATABASE USER 127.0.0.1/32 md5
host DATABASE USER ::1/128 md5
Isn't that a big silly? If you think it's acceptable to allow multiple
hostname, I'm pointing out that your requirement is not limited to
hostnames only. Why not?
host DATABASE USER 127.0.0.1/32,::1/128 md5
Same requirements, same syntax (assuming you were suggesting ','), same
documentation. Why not?
But once there, it seems clear that packing hostnames or netmasks onto
one line is just ugly and hard to manage. I'd like to see this extended
to any of the many ways to allow hostnames to be specified one per line.
For example:
set tool_servers {
127.0.0.1/32
::1/128
1.2.3.4/32
1.2.3.5/32
}
host DATABASE USER $tool_servers md5
The above features easy parsing capability.
Of course, then I'll ask for the ability to simplify specifying multiple
databases:
set databases {
db1
db2
}
set users {
user1
user2
}
host $databases $users $tool_servers md5
Sorry... :-)
2) What will you do if they specify a hostname and a netmask?
This seems like a convenient way of saying "everybody on the same
subnet as NAME."
Not supported. Either an IP address / netmask combo, or a hostname,
but not both. I wouldn't want to recommend hardcoding something such
as netmasks (which are definitely subnet dependent) in combination
with something as volatile as a host name -- move it to a different
subnet, and you might allow a whole bigger subnet than you intended.
If they want to specify a netmask, then they should just use
hardcoded IPs as well.
Ah yes, I recall this from a previous thread. I think I also
disagreed on the other thread. :-)
I thought of a use for reverse lookup - it would allow wild card
hostnames. Still, that's an advanced feature that might be for
later... :-)
I think wildcards are interesting, but I have yet to see an actual use
case other than "it's cool and very generalized". In my mind (tell me
if I'm wrong), the most common type of PostgreSQL authentication setup
is within a local network within an organization. There, you either
authorize an entire subnet ("the entire server park" or "all client
PCs") or you authorize specific hosts (single IP address). The
wildcard case is for replacing the first case, but for that case,
subnets are usually just fine. I'm trying to target the second case here.
The user case would be an organization with nodes all over the IP space,
that wants to manage configuration from a single place. DNS would be
that single place of choice. If moves trust from "trust the netmasks to
be kept up-to-date" to "trust that DNS will be kept up-to-date". Since
DNS has important reasons to be up-to-date, it's a pretty safe bet that
DNS is equal or more up-to-date than pg_hba.conf hard coded netmasks. It
makes sense, but it can be a later use case. It doesn't have to be in
version 1.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>