[Samba] How to get netbios aliases not show up in browse list?

[Trash]

What the...?!

----- Original Message ----- 
From: "Francesco De Rose" <fdr at nic-nac-project.de>
To: <samba at lists.samba.org>
Sent: Tuesday, May 31, 2005 12:36 PM
Subject: Re: [Samba] How to get netbios aliases not show up in browse list?


> John H Terpstra:
>
> > The whole purpose of the 'netbios aliases' is so that they WILL show up
in the
> > browse list. I am stunned by your question. Why would you use an option
that
> > is designed to cause the names to show up and not want it to do what it
is
> > designed to do? Perplexed!
> >
> > - John T.
>
> Heck yeah, you're perfectly right, it's quite an unusual thing. Let's
> see if I manage to explain it. :-)
>
> I have two machines, namely federica and giulia, that manage two drbd
> resources, namely ra and rb. federica is the primary for ra; likewise
> giulia is the primary for rb: then those resources (partitions) are
> respectively mounted on those machines during normal operation. In the
> event of a failure (machine death), heartbeat will act and mount both
> resources on the surviving machine.
>
Why not just have your heartbeat activate a script that writes (or moves) a
new smb.conf on the surviving machine and restart samba to give it access to
those shares?

> Now, here comes samba. :-)
> I want to set up on both machines a share containing two links towards
> the two resources. The interesting thing is that there is no immediate
> way to know on which machine they are mounted, if you don't examine the
> output of mount, that is.
>
> I thought that dfs with multiple targets could come into help and set it
> up this way:
>
>         ln -s msdfs:federica/ra,giulia/ra linkra
>         ln -s msdfs:giulia/rb,federica/rb linkrb
>
> This works on the hypothesis that the client first contacts the leftmost
> target, and goes on to the right in case of a timeout (i.e., if the
> machine is dead).
>
> Of course (as Murphy's law says) such hypothesis seems to be false, at
> least according with my tests with a windows 2000 client.
>
> It would seem that when my client connects to federica and I click on
> linkrb, the client skips to the rightmost target and tries to get
> federica/rb. But, since we're in regular operation, resource rb is
> actually only mounted on giulia, and the access fails. Probably the
> client behaves this way in order not to have to resolve one more netbios
> name, since it already knows of federica.
>
This is because your client has access to the link file on federica. Whether
what it points to actually exists or not is beside the point

> Now, my quick & dirty fix. Let's give federica a netbios alias, for
> instance 'haprimary'. (Likewise should be done on giulia)
> The client connects to haprimary, then I click on linkrb. Since it
> doesn't know about either federica or giulia, it follows the right order
> and is redirected to giulia, which is the Right Thing. And this seems to
> work on both machines. :-)
Actually, you're still connecting to federica, the only way I could see that
a setup like this could be usable would be to have a script to change the
netbios alias of giulia to haprimary should something happen. If you were
going to do all that, you'd be far better off (and spend less time) just
making a copy of your smb.conf and writing the script to move it to the
proper location and restart samba

>
> But at this point my browse list is filled up with four names: two
> netbios names and two aliases. I'd like to shorten it up, by hiding some
> of them. (if you hide the names, the links should work fine, if you hide
> the aliases, you should change the msdfs links a little...).
>
> So, here is why I need to hide them from the browse list. I fully
> understand your perplexity, it's kind of an unusual setup, I guess. I'm
> quite perplexed myself in the first place. :-)
>
> Any suggestion, *please*, *please*, *please*? (Or any advice about
> making my design a little less clumsy, please?)
>
> Thanks and have a nice day,
>
> Francesco
> -- 

To sum up, it sure seems like you're going through a lot of trouble just to
get some redundancy. Take 5 minutes and whip up 2 little shell scripts (one
for each machine). Heck, do it in Perl and you can daemonize it and make it
check the state of the other machine by itself.


Trash