[ale] Outside Request for Linux Help (Samba issue?)

Matthew simontek at gmail.com
Fri Jun 1 22:52:13 EDT 2012


I am more on the vm thought, vm's are much newer than the 7.3 is. 7.3
came out may 6th, 2002. Kernel 2.4.18. When you were setting this up,
why didn't you use fedora or centos?

On 6/1/12, Michael H. Warfield <mhw at wittsend.com> wrote:
> On Fri, 2012-06-01 at 17:53 -0400, Aaron Ruscetta wrote:
>> Received a request from help from the wider community from a
>> Michael Pelaia.
>
>> If you can assist, please reply directly to Michael or CC him on
>> replies to the list.
>
>
>> ---------- Forwarded message ----------
>> From: Michael Pelaia <michael at hooks.com>
>> Date: Fri, Jun 1, 2012 at 5:27 PM
>> Subject: RE: Linux support contacts
>> To: Aaron Ruscetta <arxaaron at gmail.com>
>
>
>> Aaron - OK.  Here is some more related to the specific problem we are
>> having:
>
>> I have some Linux servers mixed with some Windows servers and my IT
>> person
>> (he's a windows guy) is having trouble with a permissions/security issue.
>> []
>> Every once in a while we get stuck because of the depth of our knowledge.
>
>> PROBLEM: We have a setting on the Linux server at Hooks that we'd like
>> changed. I think PIN (our internal Virtual Linux) (xx.xxx.xxx.xx) has a
>> setting
>> that blocks anything but the local network from accessing its samba
>> shares.
>>  I have a hosted server that wants to access those shares and can't.
>
>> http://www.linuxquestions.org/questions/red-hat-31/restrict-samba-access-to-only-certain-lan-ip-addresses-575345/
>
>> I found the above link while trying to check if such a thing exists.  I'm
>> not
>> sure it's how it was done on this server.  Can you look to see if that is
>> set
>> on the server?  Or do you know of somewhere else an IP based restriction
>> could be set in Linux?  I don't want it limited by Linux at all (based on
>> IP),
>> I want the external firewall to deal with that.
>
>> Hooks Unlimited does music production for radio stations worldwide and
>> have a virtual Linux server running Red Hat 7.3
>
> Seriously?  Red Hat 7.3?  That thing is at least a decade old, from
> before RedHat split Fedora and RHEL (RedHat Enterprise Linux).  IIRC,
> RedHat Linux made it up to 9 before that split and they reset the
> version counters.  I'm not even sure I want to think about the kernel
> rev or Samba version you are dealing with.  Even RHEL 5 is sporting a
> version of Samba that is no longer maintained by the team.  That thing
> is beyond ancient at this point.
>
> A couple of questions I am afraid to ask, but...  What, on that 7.3
> server, do you get for...
>
> rpm -qa | grep samba
>
> ... and ...
>
> rpm -qa | grep kernel
>
> I suspect the versions that you get back are going to be so old you're
> going to be severely limited.
>
> Next...  Locate your smb.conf file.  Should be in /etc/samba but that
> klunker is so old all bets are off.  I think it was there even back
> then.  Find it and then edit and and look for hosts allow.  If it has
> one, comment it out and restart nmbd and smbd using the service command.
> If it's a custom build of Samba running on that box and not installed
> from rpm, you can probably just hang it up right now.
>
> What are you using on the remote end (I'm presuming it's NOT on the same
> subnet as this server)?
>
> If it's Linux, what happens if you run the following commands from it:
>
> telnet {PIN IP} 139
>
> ... and ...
>
> telnet {PIN IP} 445
>
> I strongly suspect that, if that version of Samba is NEARLY as old as I
> suspect it is (2.x or even 1.x) the telnet to port 445 will most
> certainly fail.  If 139 fails, you're going to have to find out where,
> in the network path, it's failing.
>
> I can almost guarantee you are not going to get it to work through
> netbios name resolution, like you would on the local net.  That old
> netbios nameserver, nmbd, operated purely in "B" (Broadcast) mode which
> would not propagate beyond the local subnet.  That old version of Samba
> did not support WINS, AFAICR.
>
> How is your remote server trying to access that server (assuming it's
> Linux)?
>
> If it's smbclient, have you tried the -I option to specify the internet
> address, bypassing the name resolution procotol?
>
> If you are attempting to use smbmount / smbfs, all I can suggest is
> DON'T.  I was one of the maintainers of smbmount, smbmnt, and smbfs on
> the Samba team.  It was deprecated years and years ago for good reason
> and supplanted by cifsmount and cifs.  Good riddance.
>
> If you are attempting to use cifs, I'm not totally sure how well it's
> going to work with that ancient version of Samba, considering that you
> probably have no port 445 (SMB over TCP on 445/tcp as opposed to SMB
> over Netbios over TCP on 139/tcp) support.  I've had to bump some CentOS
> 5.x systems (RHEL 5.x clone) to Samba3 to get to a supported version
> that could even begin to support Windows 7.
>
> If you're trying to connect to it from a Windows system, you're probably
> going to be in the same boat as a CIFS mount, only worse.  You'll have
> to be running at least Samba 3.1 or higher...
>
> Last problem...  What's your service provider and do you know you can
> propagate the MS protocols over them?  Best common practice now days is
> the block 135-139 plus 445 on tcp and udp.  That comes down from MS
> itself.  If your ISP is blocking it, you may need to set up a VPN.  If
> you do that, you may need to set up OpenVPN in TAP (bridge) mode to work
> around the local subnet only limitations on the netbios name server
> cruft with that old version.
>
>> Contact Michael Pelaia
>> michael at hooks.com
>> 404-835-0205
>
>> Michael Pelaia
>> President
>> Hooks Unlimited
>> clear. consistent. quality.
>
> Regards,
> Mike
> --
> Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
>    /\/\|=mhw=|\/\/          | (678) 463-0932 |
> http://www.wittsend.com/mhw/
>    NIC whois: MHW9          | An optimist believes we live in the best of
> all
>  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
>

-- 
Sent from my mobile device

SimonTek
912-398-6704


More information about the Ale mailing list