Late news for SCO OpenServer Release 5.0.6

This document contains information that was obtained too late for inclusion in the documentation shipped with SCO OpenServer^(TM) Release 5.0.6. See also Release Notes and SCO OpenServer Features and Limitations for a complete list of known limitations and workarounds. You should also regularly check the SCO Support web site for new information on updates, patches, and other support issues.

Revision history

• Published on 1 September 2000

Check back here periodically. New limitations and workarounds will be published as they become available.

Table of contents

Topics described in this document are:

• ``Non-primary hard disk divisions not available''
• ``Video adapter might require accelerated video driver''
• ``wd.debug=udma bootstring''
• ``Remove SCODB before upgrading''
• ``Upgrading to the Enterprise configuration from Host or Desktop''
• ``/etc/default/lang errors''
• ``Configuration and startup changes for TCP/IP''
• ``Changes to the contents of /etc/resolv.conf''
• ``ipftest, tcpdump, and etherfind not shipped''
• ``Restarting the calendar server with IQM_LANGUAGE''
• ``getvar, setvar in tape(C)''
• ``DOS session requires ansi terminal type''
• ``Access to the Apache web server manual pages''
• ``Netscape Communicator 4.70e and Macromedia Flash plug-in''
• ``Netscape Communicator 4.70e and RealNetworks products''

Non-primary hard disk divisions not available

Some divisions configured during installation on a second SCSI hard disk might not be available after installation and are displayed by divvy(ADM) as not named.

To make those divisions available, use divvy after installation to name the divisions, but do not make any other changes with divvy. Then, install the updated division table to make all divisions available as configured.

Video adapter might require accelerated video driver

Most video adapters can be operated with the generic VESA video driver. A more limited range of video adapters can be operated with accelerated, hardware-specific drivers. When a hardware-specific driver exists, the SCOadmin Video Configuration Manager will identify it. Accelerated drivers usually perform much faster than the VESA driver.

If you experience problems with the operation of a video adapter, try switching between its accelerated and VESA drivers. An adapter not behaving correctly with one driver might operate correctly with the other. Specifically, if you experience system hangs with the Number Nine SR9 AGP video adapter using the VESA driver, you should configure and use the accelerated video driver to avoid this problem.

wd.debug=udma bootstring

The wd(HW) manual page gives incorrect syntax for the UDMA debug bootstring. The correct syntax is wd.debug=udma.

Remove SCODB before upgrading

If SCODB, the kernel debugger, is linked into the kernel prior to an in-place upgrade, the upgrade fails with an error message similar to:

   undefined symbol - scodbinit
 

To avoid this problem, before trying to upgrade to SCO OpenServer Release 5.0.6, deactivate SCODB in the link kit by changing Y to N in the file /etc/conf/sdevice.d/scodb.

If the system has already been upgraded, you can correct the problem by editing the file /etc/conf/cf.d/mdevice, but be careful not to damage the format of this file because you cannot reconstruct it without reinstalling the system. On the line for ``scodb'', change the second field from ``P'' to ``PI''. (Because of the risk involved in editing /etc/conf/cf.d/mdevice, it is safer to deactivate SCODB, as described above, before upgrading.)

Upgrading to the Enterprise configuration from Host or Desktop

During an upgrade installation of a SCO OpenServer Release 5.0.6 Host or Desktop System to Release 5.0.6 Enterprise System, you are prompted to enter your Enterprise license. Supply the license information from your Release 5.0.6 Enterprise System Certificate of License and Authenticity (COLA); do not choose to install the 60-day evaluation license because there is no built-in evaluation license for SCO OpenServer.

If you select the 60-day evaluation license, after installation the Enterprise system is in an unlicensed state, the License Manager shows the Host or Desktop license, and the Software Manager shows the Host or Desktop software as installed. To clear these unnecessary entries from the License Manager and Software Manager and to ensure that your system is licensed correctly, performing the following steps after installation:

1. Remove the Host or Desktop license from the License Manager.
2. Remove the product database for the Host or Desktop software:
   
   rm -r /opt/P/SCO/product

   Replace product, with unixos for the Host software or with odtps for the Desktop software.

3. Change directory to /etc/conf/pack.d/kernel.
4. Run the brand(ADM) command using the Enterprise license from your Release 5.0.6 COLA to make sure all the appropriate files are updated on the system.

   If your COLA has a license data string, enter:
   
   brand -g -a "license_data" license_number license_code os.a

   For example:
   
   brand -g -a "k1;q1;m9zyxwv" NUM123ENT xexfmyub os.a

   If your COLA does not have a license data string, enter:
   
   brand -g license_number license_code os.a

Then, relink the kernel and reboot the system.

For more information, see ``Upgrading to the Enterprise configuration from Host or Desktop'' in the SCO OpenServer Handbook.

/etc/default/lang errors

On a system installed in French or German, after reboot, you will see a series of errors similar to this:

   iserrno = 117
 

This error can be ignored and should not cause any problems.

Configuration and startup changes for TCP/IP

Under certain conditions, it might appear that the network on your SCO OpenServer Release 5.0.6 system is not functioning properly. Upon closer inspection, you might discover that a default route has not been set or that a routing daemon did not start as expected. This might be due to changes in how configuration information is stored and changes in the TCP/IP startup script.

You might encounter these problems if you:

• performed a fresh installation of SCO OpenServer Release 5.0.6 and deferred networking configuration
• performed an upgrade installation where the original system contained modifications to the network configuration
• used netconfig(ADM) to set up your network, but could not find where to enter the desired configuration parameters

To get your network functioning properly:

1. Determine the current network configuration on your system.
2. Understand how the installation has changed and where these network configuration parameters are stored.
3. Understand how TCP/IP startup behavior has changed.
4. Restart the network or the system (if necessary) to fix the problems you have encountered due to these changes.

Determining the network status of your system

You can check if a default route exists by displaying the routing tables with:

netstat -r

This command produces output similar to:

  Routing tables
  Destination      Gateway            Flags    Refs      Use  Interface
  default          gateway1           UGS        38   355378  net0
  localhost        localhost          UH         37    52026  lo0
  198.0.0          system1            UC          1        0  net0
  system1          localhost          UGHS        2       30  lo0
  BASE-ADDRESS.MCA system1            UGS         0        0  net0

 

(If you have trouble with name resolution, you can display network addresses instead of system and network names by adding the -n option to the netstat(TC) command.)

If the destination column does not contain an entry for ``default'', then a default route has not been configured on your system.

You can check if a router daemon is running by entering:

ps -e | egrep "gated|routed"

If the command returns with no output, no router daemon is running, which is normal for many network configurations because it is usually sufficient to have a default route that redirects outbound network traffic to a specific network interface. A router daemon is only needed on certain complex network configurations. If a router daemon is needed, your network administrator should be able to identify the correct daemon for your network. In no case should more than one routing daemon be running.

To see if the resolver configuration file has been set up as you expect, take a quick look at it with:

cat /etc/resolv.conf

If the file does not exist or does not have the values you expect, you can edit this file manually -- see resolv.conf(SFF).

New network parameters during initial installation

The network configuration screen of the initial installation has some new fields for TCP/IP configuration, which affects how network configuration files are created and used.

Gateway address

You can configure a default route by supplying the IP address of the system to which network traffic should be directed if no other routes can resolve the destination. The value you place in this field is stored in the file /etc/default/tcp as the GATEWAY variable, which is used by the /etc/tcp startup script to determine if a default route should be established. If the variable is set, the startup script executes the following command:

route add default $GATEWAY $DFLT_METRIC

If you leave this field blank during initial installation, the ``GATEWAY='' line in /etc/default/tcp exists without a value assigned. Because the variable is not set, /etc/tcp does not establish a default route.

---

NOTE: DFLT_METRIC is also in /etc/default/tcp to specify a default metric for the route command, but is not set. You can edit the /etc/default/tcp file to place the desired value on the ``DFLT_METRIC='' line.

---

Nameserver addresses

You can configure a primary DNS nameserver and a secondary DNS nameserver by supplying the IP addresses, which are then stored in /etc/resolv.conf. If you leave both of these fields blank during initial installation, the file /etc/resolv.conf is not created.

---

NOTE: To supply a third nameserver address, you should edit the /etc/resolv.conf file manually after installation.

---

Startup behavioral changes

Two routing daemons (routed and gated) are available, but they are mutually exclusive. One (but not both) of these daemons can be configured to start by editing the configuration file /etc/default/tcp. The variables ROUTER_DAEMON and ROUTER_DAEMON_ARGS in that file should contain the absolute path to the daemon to be used and the arguments with which to start that daemon, respectively.

These variables are not set during installation, so routing daemons will not be started automatically for you. This is fine if you have specified a gateway address, or do not require routing tables, but if your system participates in a larger network where routing tables are updated through the routing daemon propagation protocols, you must specify which daemon to use and its arguments by editing the /etc/default/tcp file and filling in the fields. For example:

   ROUTER_DAEMON=/etc/routed
   ROUTER_DAEMON_ARGS=-q
 

or

   ROUTER_DAEMON=/etc/gated
   ROUTER_DAEMON_ARGS="-f /etc/gated.conf"
 

These variables might not exist in the /etc/default/tcp file if you have performed an upgrade from a pre-5.0.6 system. If automatic start up of one of these daemons is required, simply add the appropriate definitions to the /etc/default/tcp file.

Be sure to unset the GATEWAY variable, if its existence is inappropriate with the running of one of these daemons.

Read the manual pages for routed(ADMN), gated(ADMN), and gated.conf(SFF) for further information on setting up these daemons.

Restart procedures

A change made to /etc/resolv.conf is used by new processes requiring name resolution services. Some daemons, or long-running programs, might need to be restarted to reread /etc/resolv.conf. If you detect inconsistent name resolution behavior, you might need to either restart the services that are not working properly or reboot the system.

Changes to /etc/default/tcp require a restart of TCP/IP using one of these methods:

• In most situations, you can restart the TCP/IP network by simply running these commands:
  
  /etc/tcp stop
  /etc/tcp start

  The new network environment should reflect the changes you made.

  or

• In some situations, you might need to reboot the system (for example, if network does not start up properly or if some service that requires network connectivity became confused when the network was restarted).

Changes to the contents of /etc/resolv.conf

In this release of SCO OpenServer, the /etc/resolv.conf file might be created for you during a fresh installation; however, if you examine this file, you might notice that the domain line is missing, which is intentional because the domain line is redundant with the search line. While the domain keyword is still legal, if the domain line appears after the search line, the search line is ignored. To prevent confusion or misunderstanding, the /etc/resolv.conf file is now created without the domain line.

Other configuration information placed in the /etc/resolv.conf file during installation includes:

• primary nameserver
• secondary nameserver
• hostresorder (local first, BIND second)

The /etc/resolv.conf file is created only if nameserver addresses and the system domain name were entered during initial installation.

For more detailed instructions on resolver configuration, see the resolv.conf(SFF) manual page.

ipftest, tcpdump, and etherfind not shipped

The ipftest(ADMN) manual page mentions several tools that are not currently shipping with SCO OpenServer; therefore, please ignore any reference to ipftest, tcpdump, or etherfind.

Restarting the calendar server with IQM_LANGUAGE

The steps given in ``Calendars'' in the SCO OpenServer Handbook to restart the calendar server with the initial LANG setting are not correct.

Below are the correct steps:

1. Change directory to /usr/lib/sco/oadb and remove all the data files in the caldata directory with:
   
   cd /usr/lib/sco/oadb
   rm caldata/*
2. Enter:
   
   DBKEY=6373
   IQMFILE=/usr/adm/ISL/iqm_file
   . $IQMFILE
   LANG=$IQM_LANGUAGE
   export DBKEY IQMFILE LANG
3. Change directory to /usr/lib/scosh/utilbin and rebuild the database with:
   
   cd /usr/lib/scosh/utilbin
   ./calbuild

You should now be able to administer the calendar database.

To make this change permanent on your system, you must also:

1. Edit the file /etc/rc2.d/P95calserver and find the line:

   DBKEY=6373;     export DBKEY
    
   

2. Before that line, add:

   IQMFILE=/usr/adm/ISL/iqm_file
   . $IQMFILE
   LANG=$IQM_LANGUAGE
   export IQMFILE LANG
    
   

This will enable the calendar server to start using the locale that was set at installation time, regardless of the system locale setting.

getvar, setvar in tape(C)

Although the manual page has not yet been updated, the tape(C) command has been enhanced with new subcommands:

getvar (S)

Report the current setting of the Stp_read_variable_blocks switch in the device driver.

setvar (S)

Set the Stp_read_variable_blocks switch in the device driver. For example, turn the switch on by setting Stp_read_variable_blocks to 1 (one) with the -a option:

tape -a 1 setvar

To turn it off, use the -a option with an argument of 0 (zero).

When Stp_read_variable_blocks is set to 1, a read in variable mode (block size=0) returns the actual physical block read.

With Stp_read_variable_blocks set to 0, a read returns as much data as the buffer will hold.

DOS session requires ansi terminal type

If you start a DOS session from a tty running the ``scoansi'' terminal type, DOS does not work correctly. If you exit the DOS environment and set the terminal type to ``ansi'', then DOS works correctly.

Access to the Apache web server manual pages

In order to provide system-wide access to the Apache web server manual pages, modify /etc/default/man as follows:

MANPATH=scohelp:/usr/man:/usr/local/man:/usr/local/lib/apache/man
 

That is, add /usr/local/lib/apache/man to your MANPATH.

After setting up your MANPATH, follow the instructions in the Apache Release Notes on the SCO Skunkware CD-ROM.

Complete documentation on the Apache web server is available in the Apache manual. After installing the Apache web server , the Apache manual can be accessed via the URL:

file:/usr/local/lib/apache/htdocs/manual/index.html

Netscape Communicator 4.70e and Macromedia Flash plug-in

Release Notes for Netscape Communicator 4.70e say that a new feature of this release is built-in support for the Macromedia^(TM) Flash plug-in; however, at this time, no Macromedia Flash plug-in exists for SCO OpenServer.

Netscape Communicator 4.70e and RealNetworks products

Release Notes for Netscape Communicator 4.70e say that a new feature of this release is built-in support for RealNetworks® products; however, RealNetworks products are no longer part of the SCO OpenServer distribution and are no longer available from SCO.

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.