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 |
