• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

SAMBA for eCS... Need method for complete removal from eCS PC.

Started by NNYITGuy, 2012.01.20, 14:18:03

Previous topic - Next topic

DougB

Well, I have tried some other combinations, and the only one that works anywhere near acceptably, with eCS, is to use broadcasts, and have "bcast" as the first option in the name resolve order. Putting "wins" second helps windows to work better. Having "wins" first really messes up eCS, for some reason.

Looking forward to your updates.

herwigb

First of all, in order to have WINS working, you need exactly one WINS-Server in a subnet. Samba acts as a WINS server if you add to the smb.conf of the server:
Quote
wins support = Yes

On eCS Samba Clients you have to add to smb.conf:
Quote
wins server = xxx.xxx.xxx.xxx
name resolve order = wins lmhosts host bcast

xxx.xxx.xxx.xxx = IP of WINS server

EVFSGUI 2.5 http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120414.zip has new config options to to all that from the GUI.
Please note, that EVFSGUI 2.5 is still incomplete - the browsing code has been enhanced and works better than ever, however there are at least 2 known bugs in it. The new layout and functions are by and large missing in the helpfile, printer support is incomplete, the option to store credentials in RAM across sessions works nicely.

On Windows you will have to add the IP of the WINS server to the appropriate fields in TCP/IP notebook.

Additional note: EVFSGUI 2.5 has an option to create and manage a LMHOSTS file like a cache (this file works much like the %ETC%\HOSTS file, but for SMB networks). This will usually give you the best performance in name resolution, especially if your WINS server is slow (for instance if it is located behind a WLAN bridge or similar).

So the recommended name resolve order with a running WINS server and EVFGUI 2.5 would be:
Quote
name resolve order = lmhosts wins host bcast

For you Doug, as long you don't have a WINS server, I'd recommend:
Quote
name resolve order = lmhosts bcast host wins

EVFSGUI 2.5 creates and manages the LMHOSTS file from the network neighbourhood

In case a DHCP server is used in a network, the WINS server is normally advertised by that (Windows clients make use of that), however most eCS DHCP clients are older than Samba and as there is no standardized place to set a WINS server in OS/2 TCP/IP (until  our current Samba Client there was no software to make use of it). In short: Currently the WINS server IP address has to be specified manually or via EVFSGUI 2.5. There is no way to obtain it on eCS from a DHCP server.
Kind regards,
HerwigB.

ALT

Quote from: herwigb on 2012.05.20, 11:45:36
In case a DHCP server is used in a network, the WINS server is normally advertised by that (Windows clients make use of that), however most eCS DHCP clients are older than Samba and as there is no standardized place to set a WINS server in OS/2 TCP/IP (until  our current Samba Client there was no software to make use of it). In short: Currently the WINS server IP address has to be specified manually or via EVFSGUI 2.5. There is no way to obtain it on eCS from a DHCP server.

Actually, there is.

Basically, you need to add these lines to \mptn\etc\dhcpcd.cfg:
option 44 exec "setnbns.cmd 44 %s"
option 45 exec "setnbns.cmd 45 %s"
option 46 exec "setnbns.cmd 46 %s"

And then provide a REXX script called SETNBNS.CMD which updates the Samba configuration as needed.  The sample script IBM provides is for updating the IBMLAN configuration file -- this is nasty and requires a reboot every time the address changes.  I've pasted it here anyway to show how it works.  For Samba it should be much simpler, since Samba doesn't need to read its configuration file during CONFIG.SYS processing. 


/****************************************************************************
* SETNBNS.CMD
* by Peter Degotardi
* Revised April 21, 1998
* SETNBNS
* Return values: 0=successful, 1=unsuccessfull
* Accept DHCP options 44, 45 and 46 and put them in a queue where
* GETNBNS.CMD can read them.
****************************************************************************/
return_code = 1

/* Assume everything will fail */

/*** add RexxUtil functions ***/
call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
call SysLoadFuncs

/* get option number and data from the command line */
parse arg option_tag option_data
if ((option_tag = '') | (option_data = '')) then
do
    return_code = 1
    /* wrong number of arguments */
    exit return_code
end

/*** strip leading and trailing spaces ***/
option_tag = strip(option_tag)
option_data = strip(option_data)

Select
    when (option_tag = 44) then      /* NBNS address */
    do
        if (check_IPaddr(option_data)) then
            return_code = queue_it(option_tag||','||option_data)
    end

    when (option_tag = 45) then
    do
        if (check_IPaddr(option_data)) then       /* NBDD address */
            return_code = queue_it(option_tag||','||option_data)
        end
    when (option_tag = 46) then
    do
        call lineout '\setnbns.log', 'option_data="'option_data'"'
        select
            when option_data = 8 then data = 'H-Node'
            when option_data = 4 then data = 'M-Node'
            when option_data = 2 then data = 'P-Node'
            otherwise data = 'B-Node'
        end
        return_code = queue_it(option_tag||','||data)
    end
    otherwise  nop     /* unsupported_option */
end
exit return_code


/****************************************************************************
* check_IPaddr
* Check a dotted decimal IP address for valid format.
*
* Return 0 if there are not 4 octets or the data is out of range or
* there are embedded blanks in the address, else return 1.
****************************************************************************/
check_IPaddr: Procedure
    parse arg addr
    addr = strip(addr)
    parse var addr octet.1 '.' octet.2 '.' octet.3 '.' octet.4
    do pos = 1 to 4
        if (verify(octet.pos, '0123456789', N) \= 0) then
        return 0
        /* not an unsigned number */
        if ((octet.pos < 0) | (octet.pos > 255)) then
        return 0
    end
return 1


/****************************************************************************
* hex2ascii_string (option_data)
*
* Take a hex string in the form 'hex"nn nn nn ... ", verify it's a valid
* hex string, and convert it to an ASCII character string.
*
* Returns the string if the data is valid, a null string if not.
****************************************************************************/
hex2ascii_string: Procedure
    parse arg 'hex' '"' data '"'
    if (\ DATATYPE(data, X)) then return ""
    data = strip(data, 'B', '09'x)
return X2C(data)


/****************************************************************************
* queue_it
* Put the data in a queue where it can be read by GETNBNS.
* Tries to create the queue. If a different name is returned, the queue
* must already exist, so delete the 'wrong' queue, set the queue to the
* 'correct' one, and put the data there.
****************************************************************************/
queue_it: Procedure
    parse arg data
    qname = 'NBNSINFO'
    /* The queue we're using */
    new_queue = rxqueue("create", qname)
    if new_queue \= qname then
        rc = rxqueue("delete", new_queue)
    rc = rxqueue("set", qname)
    queue data
return 0


DougB

WINS server would not seem to be suitable for my mode of operation, simply because I never know which machines might be turned on at any given time.

QuoteEVFSGUI 2.5 creates and manages the LMHOSTS file from the network neighbourhood

So it does, but trying to use EVFSGUI 2.5 seems to introduce a few problems. Never ending hangs, while trying to populate a drive directory, is one of them. Another is that there is an error popup when I attempt to mount a new share:

QuoteLine 40 of CB_MOUNT_Change in evfsgui.VRM:

There is a button (END?) that closes the program.

File-> Load seems to work, as long as the mount was saved earlier.

I don't have the time to try to sort it out now, so I have gone back to EVFSGUI 2.13, which works good, after adding the "magic line" to smb.conf.

ALT seems to have an interesting approach, that I will have to try out when I find more time, but it would seem to require a WINS server. I think that my own router might have WINS support, but I don't think my brother's router has it.

So many possibilities, and so little time.

herwigb

Doug,

QuoteWINS server would not seem to be suitable for my mode of operation, simply because I never know which machines might be turned on at any given time.
That's the purpose of a WINS server: Using broadcasts is like somebody entering a populated room shouting "I'm here" - everybody might hear that (or not), therefore it might take some time until everybody noticed someone new is here. Same for leaving. With a WINS server, somebody who enters registers at the WINS server and anybody who wants to know who is around, asks the WINS server and obtains a list.

QuoteLine 40 of CB_MOUNT_Change in evfsgui.VRM:
Please send me the evfsgui.err file found in the directory of evfsgui.exe

Alex,

good to know. I did some investigations on that and ended up in dhcpcd.cfg, but got distracted. So many things to implement, so little time.

Kind regards,
HerwigB.

DougB

QuotePlease send me the evfsgui.err file found in the directory of evfsgui.exe

I added it to the netlabs TRAC for SAMBA, in incident #194.

QuoteThat's the purpose of a WINS server: Using broadcasts is like somebody entering a populated room shouting "I'm here" -

If I put "wins" first in the list, I get hangs, and very slow network neighbourhood population. Using "bcast" first gives me pretty good response, but not what should be possible.

At the moment, I don't have the time, or the resources, to do any comprehensive testing.

herwigb

Doug,

also send us the smb.conf of your server and the .evp file that you are using to connect.

After investigating these, I will ask you for some logs from client and server. Details what to do will follow.
Kind regards,
HerwigB.

DougB

Quotealso send us the smb.conf of your server and the .evp file that you are using to connect.

I updated incident 194 in TRAC. The Mount problem occurs on every attempt to mount a share, no matter what OS, or server, I use. The updated files at TRAC are an attempt to Mount a share on a Win98 machine. There is no .evp file, and there is no smb.conf involved. Just select a share to mount, and click the Mount button, and the popup shows the error. If I do load a *.evp file, it will mount the drive, but that does me no good when i don't have a saved *.evp file to use.

herwigb

Try this one (updated evfsgui.exe only), it has the crash with saving fixed, nothing else changed (I think)
http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120529-update.zip
Kind regards,
HerwigB.

DougB

Quoteit has the crash with saving fixed

I got the update. I never get far enough to try saving anything. The crash occurs when I try to mount a share. I can't save the information until I get the share mounted.

herwigb

Doug,

did you try the update? When mounting, the save routine is used internally, the call to this routine was broken and I fixed that.
You tell me it still crashes? In that case I need the new evfsgui.err file
Kind regards,
HerwigB.

DougB

Quotedid you try the update?

The evfsgui.EXE file is dated May 28 2012.

QuoteYou tell me it still crashes? In that case I need the new evfsgui.err file

Yes, it still crashes. The evfsgui.err file looks the same to me (without verifying that). I will update the incident.

herwigb

Sorry, I overlooked the second .err file, only the first one was fixed in the 20120529 .exe.

The second (and third) one is strange and should not happen at all - try this one http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120603-update.zip
The error is not fixed, however it should not crash, but display an error message box, which should give us a hint, what's exactly happening. It might crash after the message box....

Anyway, I need to know what the message box says, and, in case it crashes afterwards, the new .err file.
Kind regards,
HerwigB.

DougB

QuoteThe error is not fixed, however it should not crash, but display an error message box, which should give us a hint, what's exactly happening

I think I may need to be very specific about how to make it fail. Yes, the crash is fixed. Now, I get a popup saying that whatever type of share I am trying to mount, is an "unknown mount type". I reply to that popup, and it proceeds to, happily, mount what I requested. There is no evfsgui.err file now. If I try the mount from the New resource tab, I don't get the popup.

To make it fail:
Open EVFSGUI.
Select the Network neighbourhood tab.
Wait for that to populate (often it takes more than one Refresh to get it to populate).
Select a share.
Click Mount. You will get the error message.

Other things that I have found, is that NMDB.EXE doesn't always stay running when it starts after a boot. I will need to capture a log file (they need to be rolled over, rather than just replaced), which shows that it is not happy with address 0.0.0.0. It seem that NMBD.EXE is starting before the DHCP stuff gets set up. I find that rather surprising since I start the samba server in the STARTUP folder, using REXX Autostart, and the SAMBA startup is close to last in the series (of about 20 items), so it takes more than 10 seconds to get to it.

I have also been playing with the sequence of the name resolve order. I changed my router (my own router, not my brother's which we started this thread with) to use "point to point, then bcast", rather than just bcast. I also turned off the Global settings "Use broadcasts instead of local master browser". Now, it seems that setting the order to "lmosts wins bcast host" is working more reliably, but I haven't tried adding more clients to the mix, and I haven't tried turning off the one that seems to think that it is the master. I also need to reset the default cache timeout, and the listings to cache, to the defaults. BIG numbers (600 and 80) seem to work much better.

This whole thing is way too complicated for the average user, and it seems that other things (like router settings) can affect the results. I still have many hours of testing, to see what does, and doesn't, work.

DougB

I have been doing more testing. I updated TRAC with the information, but it seems that SAMBA only works properly, when the machine that gets designated as the DMB (Domain Master Browser???) never gets turned off. It also seems that the machine that gets designated as DMB is a random thing, and a second machine can also get that designation, somehow.

It seems to me, that the user should not need to even think about such things, never mind have to go through the settings to see if they can find a combination that might work, only to find that it quits working just because they powered off the machine that happened to become the DMB. I never even heard about such problems with the old PEER networking. Of course, PEER has major problems with later versions of windows, and with files larger than 2 GB, so SAMBA is our only option. Also, I have not seen similar problems when using Windows as a client to the SAMBA server (I may not have run into the proper combination of circumstances, since I don't use windows much).