PreviousTips and Troubleshooting Regular ExpressionsNext

Appendix A: Installing SCP and Samba

SCP and Samba are provided for various versions of the UNIX operating system on different platforms. The programs are provided on the NetExpress 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 NetExpress CD for full details of which versions of SCP and Samba are supplied with NetExpress.


Note: There are two recommended methods of copying the SCP and Samba files from the NetExpress CD to your UNIX system:

  1. You can mount the NetExpress CD directly on your UNIX system and copy the files using standard UNIX commands. The NetExpress CD is supplied in a format which is supported by all UNIX systems. Typically, the command to mount the CD is:
    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.

  2. You can use the 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.

A.1 Installing SCP

The SCP program provides a standardized interface between the NetExpress 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:

  1. Choose the version of the SCP program - the program is called scp - relevant to your operating system from the NetExpress CD and copy it to a temporary area on your UNIX system; for example, /tmp

  2. Log in as root on the UNIX system

  3. Make sure the directory /usr/local/bin exists. You will need to create this directory if it does not already exist:
    mkdir /usr/local/bin

    and ensure that it is readable by everyone:

    chmod 755 /usr/local/bin 
  4. Copy 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

A.2 Configuring SCP

The SCP program is executed by the NetExpress 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.

Quickstart:

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.

A.2.1 The RSH Security Mechanism

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:

  1. It checks for the presence of /etc/hosts.equiv. If the file exists, it is a text file in the following format:
    Machine-Name [User-ID] [#Comments]
  2. If no user ID is specified next to the machine name, then all users are considered valid, and access is granted

  3. If your PC machine name and user ID matches any of the lines in the hosts.equiv file, then access is granted.

  4. If no machine name and user ID in /etc/hosts.equiv matches your PC machine name or user ID, the server checks for the presence of a file called .rhosts in the HOME directory of the user ID specified in the request. The .rhosts file has the same format as the hosts.equiv file.

    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.


  5. If the PC machine name matches any of the lines in the .rhosts file, then access is granted.

  6. If access was not granted by any of the above steps, access is denied at this point.

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:

A.2.2 Determining the Official Machine Name For the .rhosts File

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.


  1. Click Start, then select Settings.

  2. Click Control Panel, then click Network

    Note: The Computer Name field on the Identification tab is a NetBIOS name that has no relevance to your TCP/IP name.


  3. On Windows NT, click the Protocols tab, click TCP/IP Protocol, then click the Properties button.

    On Windows 95, in the list box showing installed network components, select the TCP/IP protocol and click the Properties button

  4. If the Obtain IP address from DHCP server button is checked, then you have a dynamically assigned IP address and should skip to the section Dynamically Assigned IP Addresses.

  5. If the Specify IP address button is checked, note the value shown in the IP Address entry field and proceed.

Now log in to your UNIX machine. There are three primary methods used by UNIX systems to cross-reference IP addresses to machine names:

  1. Hosts files. These are simple text files containing IP addresses and machine names (one per line). They are usually located at /etc/hosts

  2. DNS (Domain Name System). This is the system used by the Internet. It consists of special servers located all around the world that communicate with each other to resolve names and addresses. This is growing to be the most popular current method.

  3. NIS (Network Information System). NIS (previously called Yellow Pages) is a distributed database of host files, passwords, groups, aliases, services, and so on.

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.

How to Check if NIS is Configured:

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.

How to Check if DNS is Configured:

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.

A.2.2.1 Determining the Official Name Using NIS

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.

A.2.2.2 Determining the Official Name Using DNS

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.

A.2.2.3 Determining the Offical Name Using /etc/hosts

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.

A.2.3 Dynamically Assigned IP Addresses

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:

A.3 Installing Samba

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 NetExpress 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:

  1. Copy the version of Samba for your operating system from the NetExpress CD into a temporary directory on the UNIX system.

  2. If you don't already have Samba configuration file, copy the tar file that contains the sample configuration files from \unix\samba\smbconf.tar to a temporary area on UNIX system.

  3. Ensure that you have root privileges.

  4. Make sure there are no copies of Samba already running. Use the 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.

  5. Extract the Samba files from the tar archive using the command: tar xvf samba.tar

  6. Execute installsmb.sh to install the binaries into /usr/local/samba and manual pages into /usr/local/man.

  7. If you do not have a valid Samba configuration file, extract the sample configuration files from the tar file:
    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.

  8. Start the Name Daemon: /usr/local/samba/bin/nmbd -D.

  9. Start the Session Daemon: /usr/local/samba/bin/smbd -D.

  10. Check the log files log.smb and log.nmb in /usr/local/samba/var for any error messages.

  11. Check that the shares you have defined are working using the smbclient command. If your machine name is unixserv, then type:
    /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.

  12. Once you have confirmed that Samba has started and is running, you should add the commands to start Samba to your system start-up files. Please check with either or both your system administrator and UNIX system documentation for details of how to do this for your system. One common location for system start-up files is /etc/rc2.d

A.4 Configuring Samba

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:

In 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 NetExpress 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.

A.4.1 The Guest Account

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.


A.4.2 User Authentication

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.

A.4.2.1 Re-enable Windows Clients to Use Unencrypted Passwords

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.

Advantages:
Disadvantages:
Samba settings:
[global]
  security=user
  encrypt passwords = no

A.4.2.2 Configure the smbpasswd File on UNIX

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.

Advantages:
Disadvantages:
Samba Settings:
[global]
  security=user
  encrypt passwords = yes
How To:

A.4.2.3 Authenticate Using Windows NT Domain Server

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.

Advantages:
Disavantages:
Samba Settings:
[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.


A.4.3 Multiple IP subnets

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)

Client Configuration:

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.

Samba Configuration:

The Samba configuration depends on whether Samba or Windows NT (or Samba on a remote machine) is running the WINS server:

where wins-server-name is the name of the WINS server machine.

A.4.4 Changing the Install Location of Samba

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 © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
PreviousTips and Troubleshooting Regular ExpressionsNext