| Tips and Troubleshooting | Regular Expressions | |
SCP and Samba are provided for various versions of the UNIX operating system
on different platforms. The programs are provided on the Net Express CD, in the
directory /unix/os_name, where os_name is a mnemonic for
the operating system. For example, for SCO OpenServer 5 and IBM AIX V4.1, the
programs are stored in the following directories:
| SCO OpenServer V5 | IBM AIX V4.1 | |
| SCP | /unix/sco5/scp |
/unix/aix413/scp |
| Samba | /unix/sco5/samba.tar |
/unix/aix413/samba.tar |
See the readme.txt file in the /unix directory on the Net Express CD for full details of which versions of SCP and Samba are supplied with Net Express.
Note: There are two recommended methods of copying the SCP and Samba files from the Net Express CD to your UNIX system:
mount /dev/cd0 /cdrom
Please refer to the Important CD-ROM information document supplied with COBOL Developer Suite for UNIX or Object COBOL Developer Suite for UNIX for the specific commands needed for your operating system.
ftp command supplied with Windows 95 and
Windows NT to copy the files across the network from your PC to UNIX. When you
copying the files, remember to set the binary flag before
transferring the files.The SCP program provides a standardized interface between the Net Express UNIX Option and the UNIX operating system and COBOL product. It is essential that SCP is installed for the Publisher to work.
To install the SCP:
scp
- relevant to your operating system from the Net Express CD and copy it to a
temporary area on your UNIX system; for example, /tmpmkdir /usr/local/bin
and ensure that it is readable by everyone:
chmod 755 /usr/local/bin
scp from the temporary area to /usr/local/bin
and ensure that it can be executed by all users; for example:
cp /tmp/scp /usr/local/bin/scp ; chmod 755 /usr/local/bin/scp
The SCP program is executed by the Net Express UNIX Option using the UNIX Remote Shell (RSH) protocol. Since nearly all UNIX systems have the RSH server program enabled by default, you do not need to install or configure any other special server software. However, to use the UNIX Option you must ensure that the RSH security configuration enables you to execute the SCP program from your PC.
You need to ensure that you have a file called .rhosts in the home directory of the user ID on the UNIX system to which you want to publish applications. This file must contain the official name of the PC from which you want to Publish.
The RSH security mechanism works by establishing "user equivalence" based on configuration files on the UNIX system. If users are equivalent, the UNIX system grants access to the requested program without requiring a password. The .rhosts and hosts.equiv files are used to control this equivalence; these two files are known as the rhosts files.
The rhosts files originated in the original Berkeley UNIX distribution but have since spread to all UNIX versions. In the process, several different versions have emerged -most notably SUN's extensions to support NIS (formerly Yellow Pages) - although these have also spread to different UNIX variants.
When the UNIX Option contacts the UNIX system, it supplies the user ID that you entered in the Server Settings dialog. The UNIX system determines the official name of your PC - based on its IP address - by using a technique called reverse lookup. It then uses your official machine name and user ID in the following way to determine whether you should be allowed access:
Machine-Name [User-ID] [#Comments]
Warning: The .rhosts file must be owned by the user ID that
owns the directory and must not be writable by either group or world ( that is,
it must have rw-r--r-- permissions). Also, it cannot be a symbolic
link.
The presence of a user name field in the .rhosts file is designed for UNIX users who might be logged in as one user on one system but want to use a remote shell on, or perform a remote copy to, another system as a different user. This is not needed for the UNIX Option as it will always supply the user ID of the HOME directory that it is trying to access.
The major SUN extension to the RSH security is the addition of the plus
symbol (+) to the list of valid machines in the rhosts files. This
is designed to be used in NIS setups with the meaning "all valid machines";
however, in non-NIS setups it means "all machines". Generally, you
should avoid using this symbol as it compomises system security.
In most cases, you should set up the rhosts files for the UNIX Option as follows:
If your server supports the SUN extensions, you might want to add a +
to the .rhosts file to disable machine name checking for that user ID.
(Check your UNIX man page for rhosts to see if it supports this)
The machine name of your PC that you enter into the .rhosts file must be your official machine name as determined by the UNIX server. It does not matter what the PC thinks it is called; the name is determined by the UNIX server based on the IP address of the connection. For most installations, the server determined name and the client name should be the same.
The first step in determining your system's official name is to determine the IP address of your PC.
Note: The configuration dialogs differ between Windows 95 and Windows NT; these dialogs have also been updated in various service packs; therefore, the dialogs you need to use might be slightly different. These instructions were created using Windows NT V4.0 with Service Pack 3, and Internet Explorer V4.01 installed.
Note: The Computer Name field on the Identification tab is a NetBIOS name that has no relevance to your TCP/IP name.
On Windows 95, in the list box showing installed network components, select the TCP/IP protocol and click the Properties button
Now log in to your UNIX machine. There are three primary methods used by UNIX systems to cross-reference IP addresses to machine names:
In order to determine your official host name you need to determine which name resolution method is being used on your UNIX system and then use that method to lookup the name based on your PC's IP address.
You might be able to ask your systems administrator, who will be able to tell you what to enter in your .rhosts file.
Check for the presence of a file called /etc/nsswitch.conf. If it
exists, look for a line starting with hosts: It will look
something like one of the following lines:
hosts: xfn nisplus dns [NOTFOUND=return] files
hosts: xfn nis [NOTFOUND=return] files
hosts: files
This statement determines the order in which hostnames are resolved using NIS, DNS and the files in /etc/hosts.
Follow the name resolution order defined in nsswitch.conf to determine your official name.
Check for the presence of a file called /etc/resolv.conf; if it exists, DNS is configured. The contents of this file are not important here.
You can determine the official name using NIS with the ypcat
command. For example, if your PC's IP address is 204.160.128.10,
type:
ypcat hosts | grep 204.160.128.10
If there are multiple names associated with the IP address, then the first one is the official name.
You can determine the official name using DNS with the nslookup
command. This command provides a standard way to interrogate DNS servers. For
example, if your PC's IP address is 204.160.128.10, type:
nslookup 204.160.128.10
This displays the name and IP address of the DNS server from which the information was obtained, followed by the name and address of the IP address you entered. The name returned is always the official name.
Since the hosts file is a simple text file, you can just examine it directly. For example:
grep 204.160.128.10 /etc/hosts
If there are multiple names associated with the IP address, the the first one is the official name.
If you cannot determine your official machine name, it is possible that your PC does not have an official name. If this is the case then you could try adding your IP addresses (in dotted decimal) directly into the .rhosts file; while this might it is highly machine specific. It would be better to have your systems administrator add an official name for you PC into your company's master machine name table.
The .rhosts access mechanism does not support dynamically assigned IP addresses. The entire security mechanism assumes - and has always done so - that machine names (and IP addresses) are constant and defined.
If your network uses DHCP (or any other dynamic IP scheme such as BOOTP), check with you network administrator whether you can be assigned a static IP address. If you can get a static IP address, do so, and configure your .rhosts in the normal way.
Note: If you're dialing up via a serial line, you are probably using PPP or SLIP, in which case you will almost certainly have a dynamically assigned IP address.
For the UNIX Option to work with a dynamic IP address, you need to have your current machine name listed in the rhosts files. You can do this in several ways, each of which have some trade-offs regarding convenience and security:
If you are not concerned about security and your server supports the SUN
+ extension to the rhosts files, then adding this to the .rhosts
file enables any host trying to Publish using that user ID to succeed. This is
the least secure method but requires the least effort.
You can add the machine names for all of the dynamically assigned IP
addresses that exist on your subnet to the .rhosts file. For example,
your network might have the IP addresses from x.x.x.100 to
x.x.x.120 assigned for dynamic IP mapping and have named
them dhcp100 through dhcp120.
If you add all the dhcp100 through dhcp120 names
to your .rhosts file, you can publish when you have any of these
addresses assigned to you. Anyone else with a dynamically assigned IP address on
the same subnet would have exactly the same permissions as you.
You will probably have to contact your local IT department to determine what the dynamically assigned addresses are
This is the most secure method; however, it is also the most inconvenient. Whenever you dial-up using PPP or reboot your PC (DHCP), it is possible that a new IP address will be assigned. You therefore edit the .rhosts file to remove the old machine name and replace it by your new one each time you reboot or dialup.
Note: DHCP can actually change your IP address without a reboot, but, in most circumstances it's highly unlikely that it would do so.
To use this option, perform the following steps:
nslookup followed by your current Windows IP address (in
dotted decimal), and the machine name corresponding to that IP address is
displayed.grep
to fnd your Windows IP address.Samba enables you to share UNIX files and printers with PCs using standard PC-style networking. Samba is required to import applications from the UNIX machine to the PC.
Note: Samba implements what is termed "NetBIOS over TCP/IP"; it is one of many implementations of NetBIOS support for UNIX. Some system vendors package other implementations with their systems. If you try to enable more than one implementation, the second one will fail to initialize as the network port for this service is busy. You must choose only one package to implement this service.
If you have an existing NetBIOS over TCP/IP package (including your own version of Samba), then the UNIX Option Import facility should function with it, as the UNIX Option only needs to copy the UNIX files via standard file access APIs.
Micro Focus cannot provide support if you encounter problems using a package other than the Samba product supplied on the Net Express CD.
If you are not familiar with Windows networking, please refer to your Windows documentation for details of how to map network drives using Windows Explorer and the net use command.
To install Samba on your UNIX system:
ps
command to find out what processes are running. For example, type the command
ps -eaf | grep mbd and check there are no processes called nmbd
or smbd executing. If either of these processes is returned from
the ps command, you must stop the installation as Samba is already
installed and running on your system.
If you want to update your current Samba installation, ensure that you will not disrupt any current users when you do so. Copy your existing Samba files to a safe location if you think you might need them again.
Use the kill command to terminate the the existing nmbd
and smbd processes and then proceed with the rest of the
installation instructions. You only need to kill the master daemon processes -
that is, those having a parent process ID (PPID) of 1 (the init process) - as
they will take care of shutting down all of the other Samba processes.
tar
xvf samba.tarinstallsmb.sh to install the binaries into /usr/local/samba
and manual pages into /usr/local/man.tar xvf smbconf.tar
This creates a series of smbconf.description files. There
are comments at the top of each configuration file regarding its purpose. If you
just want to get started as quickly as possible, select smbconf.basic
and copy it to /usr/local/samba/lib/smb.conf.
Please see the next section, Configuring Samba, for details of how to edit your smb.conf file.
/usr/local/samba/bin/nmbd -D./usr/local/samba/bin/smbd -D./usr/local/samba/bin/smbclient -L unixserv
If you are prompted for a password, just press the Enter key. If you get any errors, check the Samba log files.
Samba is a complex product and contains well over 100 different configuration options that can be modified by the Samba administrator. The purpose of this section is not to attempt to cover all of these different configurables, but to highlight some common issues involved in setting up a Samba server.
The Samba manpages, which are installed at the same time as the Samba
binaries, contain detailed reference information. To access the manpages, you
will probably have to add /usr/local/man to your MANPATH
environment variable so that the man command can find the pages. The
most important manpages are:
samba - General overview of the Samba suitesmbd - the Session Manager Daemonnmbd - the Name Manager Daemonsmb.conf - the Samba Configuration fileIn addition, Samba also has many How To documents and a FAQ as part of the Samba source code distribution. The Samba sources are provided on the Net Express CD in \unix\samba\sambasrc.tar. If you extract this source code distribution, the documents are in the docs subdirectory. The documents range from the very simple to the highly technical. If you are having problems with Samba, or just want to find out more about how to configure it, these documents are invaluable. If you have problems configuring Samba and making it work despite this documentation, there is a very helpful document called DIAGNOSIS.txt in the docs directory.
One common problem encountered when setting up Samba is the value for the guest account that is specified in the smb.conf file. This user ID is used by Samba for such things as providing a list of shares available to a client as well as the more obvious use as a real guest user (for publically accessible file shares).
It is very important that the value specified in the smb.conf file exists and has a valid UID. Most UNIX systems define by default an unprivileged network user; common examples include the nobody, nouser and network users provided on various UNIX systems. Check the /etc/passwd file on your system to see which one you have and make sure the smb.conf file has the correct value. If you do not have a suitable user name, you need to create one.
Note: On HP-UX, the UID (and sometimes the GID) of the nobody account has a negative value (which is illegal). If you wish to use this username as the guest account for Samba, you must change the UID and GID for the nobody account to an unused, non-negative number.
If your PC is using a version of Windows 95 earlier than OSR2, or Windows NT V4.0 SP3, then user authentication with Samba will cause no problems.
However, in the release of Windows 95 OSR2 and Windows NT V4.0 SP3, Microsoft changed the way that their client systems authenticated users with a NetBIOS server. The key change was that password information was sent to the server in an encrypted format instead of the previous unencrypted format. As the encrypted password format used by Microsoft is incompatible with that used by the UNIX passwd file, it is impossible to tell if the two encrypted password strings match.
Note: The use of unencypted passwords is no less secure than typing in your password to a UNIX telnet or ftp session.
There are three different ways in which you can configure Samba security for these releases of Windows 95 and Windows NT:
These are described in more detail in the following sections.
You can re-enable the old unencrypted password support in the Windows clients via a registry setting. Registry configuration files for Windows 95 and Windows NT are provided with the Samba source code distribution in the docs directory.
[global] security=user encrypt passwords = no
Samba now includes built in support for NetBIOS format encrypted passwords. The NetBIOS format passwords are stored in a special smbpasswd file which is manipulated by the smbpasswd command.
[global] security=user encrypt passwords = yes
/usr/local/samba/private. This directory must be owned by root
and only accessible by root; that is, it has rwx------
permissions.smbpasswd -a myuserid
Note: There are some helpful tips and programs documented in the Samba source code docs directory that can help migrate user IDs from the existing passwd database to smbpasswd. In addition, details are also provided for the user changing their password from the client.
Samba can authenticate users against a Windows NT domain server. Samba cannot actually particapate in a domain but it can forward encrypted passwords to a Windows NT server for validation.
[global] encrypt passwords = yes security = server password server = nt-server-name
If the Windows NT authentication fails for a particular user ID and
password, then the security mode reverts to security = user"
and Samba attempts to authenticate the user in the smbpasswd file, if it
exists.
Note: Regardless of the security authentication method used, a real UNIX user ID must exist in the /etc/passwd file for the username being authenticated. Samba requires this in order to set the appropriate permissions for the user, establish file ownership permissions, and so on.
The NetBIOS protocol was originally designed for small scale workgroups on a single isolated LAN using the NetBEUI transport. One consequence of this design was that NetBIOS makes the list of machine names and shares available by broadcasting the information to all machines in the LAN.
When NetBIOS over TCP/IP was introduced, the broadcast methodology broke down. TCP/IP is a protocol in which broadcasts only happen within a subnet. Another method was needed to distribute machine name and share information between different IP subnets. The solution was the Windows Internet Naming Service (WINS).
When you have multiple IP subnets, you need to have a WINS server to correlate information between the subnets. Both Windows NT Server and Samba include a WINS server. In general, if you have Windows NT server, use its WINS server in preference to that provided with Samba. There should be only one WINS server per network (although Windows NT allows backup WINS servers)
Every client system must have the WINS server configured in their TCP/IP properties. You might have to do this manually, or it might be set centrally via a DHCP server. The client systems will both register themselves with this server and interrogate it when looking for machine names and shares.
The Samba configuration depends on whether Samba or Windows NT (or Samba on a remote machine) is running the WINS server:
[global] wins support = yes
[global] wins support = no wins server = wins-server-name
where wins-server-name is the name of the WINS server machine.
The base install location of /usr/local/samba is actually compiled into the Samba binaries. If you want to change the install location of Samba, you can either recompile the supplied Samba source code, or you can change the locations of the files via command line and configuration file options.
In most cases, it is easier and more reliable to recompile the Samba source code with the new base directory; it is a one line change in the Samba Makefile.
Note: Some Samba features such as support for multiple code pages will not function unless you recompile Samba with the new base directory.
If recompiling Samba is not practical, then you need to make changes similar to those in the following example. For this example, assume that the new install location is /home/samba.
First, the nmbd and smbd commands need additional options to tell then where the new configuration file is located and where to log their output:
nmbd -s /home/samba/lib/smb.conf -l /home/samba/var/nmb.log -D
smbd -s /home/samba/lib/smb.conf -l /home/samba/var/smb.log -D
Secondly, in the Samba configuration file, you need to make the following
additions to the [global] section:
lock directory = /home/samba/var/locks smb passwd file = /home/samba/private/smbpasswd smbrun = /home/samba/bin/smbrun
Copyright © 2000 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Tips and Troubleshooting | Regular Expressions | |