On 30/09/06 11:54, Paul Abrahams wrote:
<snip>
That has to qualify as a "gotcha". I fixed it just as you suggested and Samba now works on my Windows machines.
An epistemological question: how might I have discovered that if you hadn't told me, other than plowing through all the FW parameters and just maybe realizing that this one needed to be changed -- and changed to 137? Even though the description of this variable in the config file mentions Samba, it doesn't indicate very clearly how essential it is.
The only way to know what a firewall must permit is to know the services that need the network. That is often a great deal more detail than the average user should be expected to know in depth. The solution to this is, of course, a clearly written FAQ or Wiki, in a place that people can easily find it. Unfortunately, the Linux documentation world is as badly fragmented, and much of the information is woefully outdated -- the list FAQ mentions a SuSE FAQ at sourceforge, but the most recent amendment to that collection is March, 2005. The firewall document is dated 2002, so I suspect it is ipchains-based, whereas the 2.6 kernel uses iptables. I do not see this situation getting any better in my lifetime.
Too bad all this necessary stuff isn't in the Firewall section of Yast (granted that you can get at it through sysconfig if you know to look there).
I am not sure this is necessarily a good idea. How many services would need to be discussed, and in what detail? It could very quickly get out of hand. Perhaps it would be sufficient if port 137 broadcast is automatically turned on whenever the user chooses Samba-server as an allowed service (a note to this effect would have to be placed in the broadcast section, of course). PS, if I know so much about this, why did it take so long to resolve your problem? ;-)