On Tue, Jun 29, 2010 at 11:01 AM, Dan Mahoney, System Admin
<danm@xxxxxxxxxxxxxxx> wrote:
> As I mentioned in my first request, this hash would have to be done after
> the client looked up the FQDN, and base it on that. Something resolvable
> would have to be specified on the command line.
>
> I admit that this would not work in cases where you're using both host and
> hostname for the same host in your options file. I've always been a fan of
> specifying the correct thing on the command line, though, and mainly use
> this config for tunnels and port forwards, not for hostname-aliasing, which
> would work perfectly fine with this.
At that point just nix the "Hostname" field.
Then you are just asking for hashing the "Host" field and matching the
host field after FQDN expansion.
of course all aliases must be implemented either in the host table or in DNS
via your search path.
so:
Host desktop
Hostname desk-HBMDT3J.site.domain.com
tunnel stuff...
cannot be done if Hostname was hashed.
or even:
Host desk-HBMDT3J-tun1
Hostname desk-HBMDT3J.site.domain.com
tunnel options 1
Host desk-HBMDT3J-tun2
Hostname desk-HBMDT3J.site.domain.com
tunnel options 2
Host desk-HBMDT3J
Hostname desk-HBMDT3J.site.domain.com
<no tunnel options>
Since the "Hostname" field is not a field the is used to match
against, it is used to store information that is used as is, you
cannot store it as a none reversible transform (a hash). You need to
be able to pull the original data out of it.
The ONLY field that can be hashed is the "Host" field, since it is not
used to retrieve settings.
If you require a FQDN expansion before matching the Host entry, you
then preclude having multiple entries for the same host, specifying
different options. (as shown in my second example)
--
And, did Galoka think the Ulus were too ugly to save?
-Centauri
