Davrom Consulting Pty Ltd

Established Since 2001
PO Box 1644, Sunnybank Hills, Qld, 4109
ABN: 81 096 990 804


Site Time: 19 November 2017 - 13:12




Back to Newsletters

KEYWORDS=htpdate, branch, head, office, tunnel, vpn, DAVROM CONSULTING Newsletter - Issue # 29 - Dated: Sat Oct 15 08:47:02 EST 2005


From the desk of David Clark

Our first week of big storms here in this part of the world has seen some
sites find that the UPS is the ultimate way to shutdown gracefully -
computers and tempest do not mix too well.

I finally installed SCO OpenServer 6 (full version - non-beta) on a decent
box and have written a review on my findings - and Progress now endorses
OpenServer 6 so no more changing from the base OS!!!

Some fun with setting up new remote customer branches with Internet links to
their head office has prompted me to cover an IP issue with the 192.168
addressing.

Support continues on in the Linux/SCO/Cyberguard world....

I would like to thank the reader for their time in reading this newsletter.

David.M.Clark


UNIX Quote

OpenOffice - freedom from the perpetual upgrade path.

Setting your branch/head-office IP addresses

As organisations grow and new offices are setup around the state, country
or world, there is often a need to setup secure tunnels between branches
for access to servers and remote branch resources via the Internet.

One interesting situation I often find when setting up remote branches
is the use of the 192.168.0.0 IP address scheme and how people often just
grab the first numbers for their network setup: 192.168.0.1, 192.168.0.2,
up to 192.168.0.254.

The network continues along merrily until David Clark turns up to put a
remote branch on-line, only to find that the remote branch is also using
the same "out of the box" IP network scheme (192.168.0.1-254), the same
as the head office IP network. What this means is the remote network PCs,
servers and printers at either end will not be able to communicate over
the Internet tunnel as each end believes that the network traffic stays
local - it is expecting that any IP in the 192.168.0.x range is at the
local branch itself and not at the other end of a tunnel. Basically your
remote PCs, servers and printers remain that - remote - non-contactable.

So what do we fix? One of the branch ends, preferably the one with the
least amount of PCs etc to configure, has to change. If you change one of
the remote ends to have the network IP address of 192.168.1.1-254 (that's
using number 192.168.1.1 to 192.168.1.254), both ends (192.168.1.x and
192.168.0.x) can then communicate via the tunnel as they will pass the
network traffic (packets) to the default router/gateway at each end which is
in turn able to communicate with the corresponding router/gateway at the
remote end.

If you have read this far, the moral of my story, my point is, be creative
with the IP addressing and have foresight when setting up your private
network. Make your head office have 192.168.4.0 for Queensland,
192.168.2.0 for NSW, 192.168.3.0 for Victoria and so on for an example
here in Australia. If your street number is 33, then use 192.168.33.0 as
your network address - there is no law on the setting of the IPs except
they must be within 1-254.

Even if you don't plan on having remote branches for the foreseeable future,
be aware that other organisations such as software support houses and
consulting companies such as DAVROM, may need to connect via the Internet
into your network and may also have grabbed the first address off the mark.

Some quick background - The 192.168.0.0 IP network address is a reserved
"C" class network address that is not used on the Internet hence can be
used by private companies and organisations for their internal network
addressing (there is also 10.0.0.0 for an "A" class and 172.16.0.0 for a
"B" class for larger organisations but most commonly you will deal with the
192.168.0.0 range) - I won't kill you with the backgrounds here but if you
want to read about the IP network standards set in place you can Google or
go to:

http://www.faqs.org/rfcs/rfc1918.html


OpenServer 6 Installation

As promised in a previous newsletter, as soon as I had a chance to do
some installing of SCO's new OpenServer 6 on a descent box I would write
a review. For a "First look" at OpenServer 6 I have made the following
points on what to expect - it's a nice and easy installation.

First there is a new fancy OpenServer 6 logo on booting the
installation CD and in fact if you have installed Unixware 7 before both
the logo and the boot options are like those of Unixware 7.

It now has the Unixware HBA (host bus adapter) approach to installing
additional boot drivers (normally hard disk adapter drivers) and you now
use the Unixware drivers rather than the OpenServer 5 traditional BTLD
(Boot Time Loadable Driver) approach.

The filesystem setup of disks is from the Unixware disk manager and the
default filesystem is vxfs rather than OpenServer HTFS - you can change
filesystem types but I can recommend the vxfs.

It does the Unixware mouse test and detected the ethernet card
automatically. I installed OpenServer 6 on a Compaq so the fact that it
found the network card without needing me to install the traditional
Compaq EFS (Extended Features Supplement) for OpenServer is a miracle
in itself.

I need to state here that given we are using a SVR5 kernel based on Unixware
the steps so far are governed by this native kernel - but don't worry, it is
easy and the actual installation is very fast.

It has the traditional OpenServer 5 package installing progress bar so here
it feels more like the older OpenServer.

I installed the default packages which requires about 1.3GB of root
filesystem space and I let it install GTK, Perl, PHP4, Cups and KDE to
name a few.

After the install it came up without a hitch - it is more like the
Unixware boot and the traditional "hwconfig" screen no longer exists. You
still go through the "Control-D" startup sequence though.

I added a printer but cups does not appear to be changed - it still updated
/usr/spool/lp/admins/lp/interfaces. This to me is a blessing as I have
really liked the interface approach that SCO and other UNIX systems have
given with regards to allowing you to modify a printer interface script
for a printer.

The "hwconfig" command is gone and you use the more extensive Unixware
"hw" utility to view system hardware settings - and it tells you
everything.

mkdev is still there but bear in mind you are now dealing with the Unixware
approach to setup - it also has the Unixware dcu hardware config utility.

The default console terminals are at386-ie but you can change these to
ansi.

At this point, the "scoadmin" utility looks and feels the same so
administrators won't feel lost.

You may need to change /etc/xorg.conf to get the graphical X window to
come up based on your monitor. Normally you need to mess around with
the Hz settings which was the issue with my Acer monitor.

I changed the /etc/default/X11 file to kde3 as I have always preferred
the KDE graphical desktop - impressive using KDE on a OpenServer box. KDE
has the same admin tools under X (scoadmin, printer manager etc).

Overall I was very impressed with the new version and how well it
installed and detected the hardware. It is very fast in performance and
now places OpenServer in a higher realm of the server market.

This version will now allow those companies that have been running
OpenServer for many years to move to this newer version to take advantage
of the new kernel where application houses have previously recommended
people move to other non-SCO platforms. Why change from the core
operating system that you know and have relied on for so many years?

For more information on OpenServer 6 please visit:

http://www.sco.com/products/openserver6

Newsworthy Items

An important milestone in the SCO/Progress relationship - OpenEdge 10
certification for OpenServer 6 is complete! Progress reported
to SCO today that OpenServer 6 passed their certification tests which
have been underway for several weeks. This is an important event for
SCO, Progress, and mutual customers. Prior to the announcement, OpenServer
5 customers running Progress Version 9 were faced with either running
outdated systems or changing either the database, the operating system,
or both. Now customers can stay with SCO OpenServer.

Red Hat Appoints ALSTOM IT its New Distributor in Australia ALSTOM, with
its solid understanding of the needs of the market and its technical
skills base of their sales team, is a natural fit with Red Hat's expansion
needs in Australia.

Sun Microsystems and Google announced a multiyear partnership to help
spread and develop each other's software, a deal that includes
OpenOffice.org, Java and OpenSolaris from Sun, and Google's Toolbar.
Google toolbar will become a standard part of the software people get when
they download Java from Sun's Web site. The Java Runtime Environment is
downloaded 20 million times per month, Sun chief executive Scott McNealy
said.

The second Release Candidate of OpenOffice.org 2.0 can now be downloaded
or obtained from most newsagent magazine CD/DVDs. Recent articles in
Brisbane newspapers comment on the massive in-roads OpenOffice is making
as an alternative to Microsoft Office products and the alliance of Google
and SUN Microsystems.


Tech Tip


An interesting utility I found in the Linux Magazine August 2005 issue. A
utility for keeping your server time correct via the Internet - htpdate.

htpdate can be downloaded from http://www.clevervest.com/htp/intro.html
as an rpm (this is what I used on RedHat 7.3 and Fedora Core 4) and their
is source so I may tackle compiling it for SCO at some point.

htpdate has a few options and you simply tell it a HTTP site to
synchronise your time with. The following command line sync-ed my local
server time with a Brisbane website (with Google as a fallback - it can
take up to 16 sites):

htpdate -d -s www.ourbrisbane.com.au www.google.com.au

If you want to run it as daemon your use the -D option instead

htpdate -D -s www.ourbrisbane.com.au www.google.com.au

You can us a -x to tell htpdate not to just change the clock in one go -
this would save you having potential problems if you had an application
that would fail if the server time was all of a sudden 1 or 2 hours
earlier/later.

The site recommends staying with ntpd (Network Time Protocol Daemon) for
the but I was impressed that I now have a simpler alternative.


Back to Newsletters




Website design by Davrom Consulting Pty Ltd
This site is fully tested with Google Chrome and Firefox web bowsers

Home Page | Support | Misc | David's Pages | Podcasts | Contact Us | Blog