Tim,
Contact Legato about this "feature". They claim it is by design, and
for "security". All clients after 7.1.1 (7.1.2+) do their own hostname
mangling after a gethostname() call is returned. They take the short
name of the machine, and attempt to use that as the authentication name
for finding which client the server is associated with.
As we have many clients (2000+ per networker environment) we ran into
this issue as soon as we started trying to use anything above 7.1.1 on
the clients, since many of our customers like to name their servers
based on role (like one client naming their server db.example.com and
another db.example.org).
When we contacted Legato about this, they were less than responsive, and
it took weeks and one of their consultants to come out and "by chance"
overhear that we were investigating jumping ship to another vendor, to
convince them that it was an issue and needed a workaround.
I had proposed our own workaround wich will work 100% of the time and
with any version of the client. It would use a custom library to
override the gethostname() function to return a custom value when
starting NetWorker with the library in the LD_PRELOAD environmental
variable. This allowed us to create a file in /etc and change the name
that NetWorker sees on the fly.
Legato however was unreceptive to this workaround and refused to support
our environments if this was used, and is now coding modified versions
of save and probly savefs for us to revert back to the old
authentication ritual.
Have fun banging your head against the wall while communicating the
problem to them, it took us about 2 weeks for them to figure out the
workaround I proposed, and I still don't think they fully get it.
Having to code custom client binaries for every version we want to run,
and then to have to test/qa/and support them just doesn't make sense to
me.
My reccomendation would be to run 7.1.1 on your clients, if you can, and
pray to the gods of backup that they get everything fixed by the time
8.x comes out and the 7.x series gets EOL'd.
Have fun!
Jason
PS. Let me know if you want the code to override the gethostname()
function anyway. Its extrealy simple, and probly ridden with bugs, but
it gets the job done.
On Sat, 2005-08-20 at 20:26 -0500, Tim Mooney wrote:
> All-
>
> Because of the recent security vulnerability and because there are not
> patched clients (and apparently won't be) for 6.1.x, I've updated a large
> number of our backup clients to the 7.1.3 Build 421 client this weekend.
> In doing so, I've encountered a problem with the DNS checks in the 7.1.3
> client, and I'm not sure how to mollify the new client. I'm hoping
> someone on the list has some suggestions.
>
> There are a few bits of important background information:
>
> - we use mixed case in our DNS domain name.
>
> - our backup server and our largest backup clients are on two networks:
> our primary network and a backup-only network. If a hostname on the
> primary network is foo.NoDak.edu, then its interface on our backup
> network is foo-2.NoDak.edu.
>
> - The clients are created within NetWorker using the fully qualified
> domain name of the interface on the backup network, e.g. foo-2.nodak.edu.
> In all cases, I've also added an alias in the client definition for
> the fully qualified domain name of the public interface, e.g.
> foo.nodak.edu.
>
> Note, though, that the clients were all created and the aliases were all
> added without using mixed case in the name.
>
> - The `hostname' command on each of the clients returns the fully
> qualified domain name (with mixed case) of the primary interface. In
> all cases, the /etc/hosts file has the correct entry for the primary
> interface:
>
> XXX.YYY.ZZZ.AAA foo.NoDak.edu foo
>
>
> Many of our clients don't have an /etc/hosts entry for their secondary
> (backup) interface's hostname.
>
> - Lastly, we have a few clients with the same "short name" in different
> subdomains, e.g. foo.subnet1.NoDak.edu (which is created within
> NetWorker as foo-2.subnet1.nodak.edu), foo.subnet2.NoDak.edu (in
> NetWorker it's foo-2.subnet2.nodak.edu), etc. In all cases, those
> clients are using their fully qualified domain name of their
> primary/public interface as their hostname.
>
>
>
> DNS resolution is set up, and is working correctly. Everything worked
> perfectly with the 6.1.x client.
>
> After upgrading the clients to the 7.1.3.421 backup client, though, backups
> now fail with the "...is not properly configured" error message. Here's
> an example for one of our IMAP servers:
>
> * imap1-2.ndsu.nodak.edu:/ save: SYSTEM error: client `imap1' is not properly
> configured on the NetWorker Server
> * imap1-2.ndsu.nodak.edu:/ or `imap1' is not in the aliases list for
> * client `imap1-2.ndsu.nodak.edu'
>
>
>
> The crux of the problem seems to be that NetWorker is for some reason
> wanting the short name `imap1' to be in the aliases list for this client.
> I don't see why; the client machine is using its fully qualified domain
> name:
>
> $hostname
> imap1.ndsu.NoDak.edu
>
>
> I can't add just `imap1' to the aliases list for this client, because then
> NetWorker gets this client confused with other clients in other subdomains
> that also have short names of `imap1' (even though all of those clients
> are also using their fully qualified domain name). For example, we also
> have backup clients name
>
> imap1-2.nodak.edu
> imap1-2.sendit.nodak.edu
>
> Those clients are also both correctly using their fully qualified domain
> names as their hostname, e.g. imap1.NoDak.edu and imap1.sendit.NoDak.edu.
>
> I'm not sure how to proceed. It looks to me like NetWorker is doing
> the wrong thing (truncating what the client returns as its hostname) and
> requiring that short name to be on the aliases list. That makes it
> impossible to have two clients with the same short name (even if they're
> not using the short name as their hostname) in different subdomains.
>
> Anyone have any suggestions or ideas for how to work around this?
>
> Tim
> --
> Tim Mooney mooney AT dogbert.cc.ndsu.NoDak DOT
> edu
> Information Technology Services (701) 231-1076 (Voice)
> Room 242-J6, IACC Building (701) 231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the
> body of the email. Please write to networker-request AT listserv.temple DOT
> edu if you have any problems
> wit this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
