Well, here we are again. A new version of Unixware, Unixware 7.1. Three floppy disks, three CD's, a few sheets of paper marked "Installation Roadmap", a a new Release 7.1 System Handbook and a slim "Getting Started Guide". If you've done Unixware installs before, you might as well just get started- believe me, you'll have plenty of time to read the documentation.
That's probably my biggest gripe about the install. It's s-l-o-o-o-w. Even just booting the first floppy disk takes so long that I was certain something must be wrong: so certain I actually interrupted it the first time!
I started the install at just before 4:30 PM. The machine is a clone Pentium 266 with 64 meg of memory, an Adaptec 2940AU controller with a Quantum Fireball 4.3 gig drive and Toshiba SCSI CDROM.. admittedly not a powerhouse, but it ran both Linux and OSR5 very nicely.
I've covered the details of a Unixware 7 install elsewhere, and not a lot has changed. You still get asked for ipx and nis information (just "defer" those if you don't want them). Holding Ctrl_Alt and pressing ESC switches you to an install shell where you can watch what's happening behind the scenes. Interestingly, you are running a ksh there, and most of the commands that you would type (df, etc) are actually defined as ksh functions that do some pretty strange stuff. Take a peek at the file "funcrc" to see what those are (on an installed system you can find it at /usr/lib/drf/funcrc).
Just because I mention some feature here doesn't necessarily imply that it wasn't the same in previous Unixware releases. I may just not have noticed it, or may just not have commented on it in previous articles. There are new features in this release; most notably the Webtop, but some of the other features touched on below have been included previously.
CD # 2
An hour later (!) it was done with the first CD. As you would expect, it asks you to remove floppy disks and CD's. I had no real need to remove the CD (this machine is not bootable from CDROM), but it would not shutdown until I at least opened the CD drawer. It then reboots from the hard drive and (eventually) asks for CD number 2. It's during this second boot that you configure the mouse and test it. I checked CTRL-ALT-ESC: there are messages displayed on that screen, but there is no longer a shell running.
This CD has a bunch of optional stuff: the Webtop, Lxrun, JDK, and several sets of documentation packages in different languages. The interface to selecting or de-selecting packages is still that strange space bar toggling that redraws the screen as each selection is made. To proceed to actually installing your choices requires ENTER (up to this point the F10 key is the proceed key; that's traditional Unixware usage).
Because I chose to install Enhanced Logging, the install does stops to ask for the database location when it gets to that point. Other than that, the rest of the packages install without further involvement.
What seems to consume the most time on this CD is the documentation and manual pages that follow your optional software installations. These are obviously the entire Unixware docs; it's too much to be just the few packages installed here. During this portion of the install the network hardware has been initialized; you can verify that from another machine with ping (but telnet and other services are not yet available).
CD # 3
At 6:15 we reached CD # 3. This again offers a selection of software to install. For this installation, I deselected Arcserve, selected Merge, and left the others (Visionfs, the RealNetworks stuff) alone. Again, the proceed key is ENTER, not F10.
This part of the installation is really annoying. For each package, you have to confirm that you really do want to install it, and then after each install, press ENTER to move to the next. Why have the the initial screen at all if you have to confirm everything? Sure, this makes some sense for products where additional licensing or configuration information is required, but a lot of this doesn't need any further interaction, or the configuration could be delayed. Some further work is needed on the entire install process.
Fortunately, this last CD takes only 15 minutes or so, but the very end of it gave me a chuckle because the "proceed" prompt reverted back to Novell style F10 again- but - ENTER worked just as well!
The Visionfs install warned that it won't run at startup until the visionfs password wizard has been run (/usr/vision/bin/visionfs password --wizard). That warning is probably necessary; it is emitted again by the /etc/rc3.d/S90visionfs startup script (OSR5 users note: the default run state for Unixware is 3, and /etc/rc3.d is where Visionfs, NFS and the Webtop start), but you probably won't notice that during boot as your screen will have switched away to the graphical login. If Unixware collects the rc output (as Openserver does in /var/adm/messages), I can't find it. There are no sub-logs for individual scripts as there are on OSR5 (/etc/rc2.d/messages). It seems to be up to individual scripts to log their own startup- for example, rc2.d/S69inet logs to /var/adm/log/inet.start.
Up and Running
At 6:30 we rebooted for the final time. There were no warnings to remove the CD this time. There do seem to be some minor delays getting up and running though. Well after login prompts had appeared, I tried accessing this machine from another OSR5 box on the network. I couldn't, so I tried pinging it, but that didn't work either. I was perplexed, because I knew that the network had at least ping working during the install, so why would it be dead now? I switched back to the Unixware machine and tried pinging out from it, and that worked. Back to the OSR5 box, and now ping and telnet were fine. Obviously the network startup was more than a little delayed, but it was now up and working.
The first thing to do is to run /usr/man/bin/config_search -f. This builds the search indexes needed by the graphical search tool. This takes a fair amount of time, and on this hardware, it drastically affected performance- it was very difficult to use the graphical interface while config_search was running. Again, this is a 266 mhz scsi box with 64 meg of ram- until very recently, a fairly powerful box.
Speaking of performance, sar is enabled by default in this release. That's good; it has annoyed me for some time that sar has to be explicitly turned on in the OSR5 systems. There are minor differences in output, but one thing an OSR5 user will immediately notice is that the proc, inode, etc. tables are not dynamic. Unixware kernels use statically sized tables. I'm not sure if that's good or bad; you can make arguments either way on dynamic tables.
The System Handbook tells you that you can start the Webtop simply by accessing http://hostname/Webtop. That's not quite true: the Webtop can't run until the web server has been started, and that has not been started by default. You can run "nsfast start" or you can go into Scoadmin to Netscape Server Administration (which will ask for authentication: it wants "admin" and the password is whatever you used for "root" when you installed the system) and turn the server on port 80 on. Neither of those set it to run upon reboot, however. To get that, run "nsfast enable"
Once the server was running, I could access the Webtop from another machine. You need a Java capable browser, and in order to have complete functionality, you need to allow Java to have privileges it ordinarily would not have. You are told that you should turn on "Smart Updates" in your browser; for Netscape 4.0.8, that's actually called "Auto Install" (Preferences/Advanced/Enable Autoinstall). You also need proper host resolution: DNS or /etc/hosts. When I added the Unixware box to my hosts file, I accidentally mistyped its domain. This didn't matter for the initial access to the Webtop (because the hostname was correct), but when I started drilling down into administration tools, those failed to resolve. That got me into a little bit of a Catch-22: I couldn't close out of the remote session, and the local machine wouldn't let me in to the administration scripts while the remote was running. I finally had to use command line kills to close everything out, fix my naming problem, and restart.
The ability to run system administration tools over a browser is not without its headaches, of course. First, authentication is obviously a BIG issue (as it should be), so you get asked to authenticate over and over again. Secondly, Java is still painfully slow at times, and although the integration works very smoothly when everything is working well, the design doesn't catch problems very well. For example, several times I had problems accessing Network administration through the browser. It would just hang, displaying nothing. Eventually it would pop up, but during the wait you have no way to interrupt it or indeed any indication that something is wrong- it just hangs. Once it finally did come up, I tried configuring a ppp link- I couldn't do it: I got as far as "bundles" and it just died forever. I'm sure these are glitches that will go away in future releases/patches, and MOST of the interface was functional, so don't take this as being extremely negative.
As I couldn't configure ppp through the browser, I came back to Scoadmin and tried it there. It's not immediately obvious how to do this, because when you call up Network Configuration, it only shows NIC cards and doesn't offer any ppp choices on its menus. However, under "View", you can switch to a "Wan View", and there you can configure ppp links.
That configuration is pretty nicely done. I'd say it is almost as easy as Windows, and does offer more power and control. I found that it couldn't automatically detect my Courier V.Everything, but when I chose it manually it worked. The rest of the configuration was quick and simple (though the "bundles" terminology, which apparently refers to the bundling of a modem and a ppp link, is a little confusing at first). The setup asks the right questions, gives you a chance to enter a chat script, and in a very few minutes I had a working connection to my ISP.
But.. I immediately noticed that the connection was much slower than usual. Pages that normally load quickly dribbled in at sub 1k speeds. At first I thought that I'd just hit one of those Internet Interludes where everything gets slow, but when I switched the modem back to the OSR5 machine, everything was crisp again. As the OSR5 box is actually lower powered than the Unixware machine (and neither of them were loaded down with any other task anyway), I assumed that something must be set very differently in the link protocols. That leads me to my first grip about the ppp setup: I'm used to OSR5 where the files that control all this (/etc/ppphosts or the Morningstar equivalent) are simple text files that are easy to see, to understand, and to edit manually if you want to. This is not the case in Unixware. It's not even particularly easy to find the actual configuration file (/etc/ppp.d/.pppcfg) and you are repeatedly warned not to edit it manually- which is probably good advice, because its structure is fairly complex. But the graphical tools do not give you complete control, so you are offered the "ppptalk" program to use instead of hand editing.
This "pptalk" is a little confusing at first, and its built in help is less than illuminating. You need to read the manual pages, but once you understand how it works, it is not unpleasant: it lets you pipe output to external commands ("list bundle world | more") and if you "set vi" or "set emacs", you have command line recall and editing within it. However, I wasn't able to spot anything different from the OSR5 configuration that would cause the slowness- it just remained slow. I even turned off the Enhanced Logging feature, thinking that perhaps this was contributing to the lagging performance, but I just couldn't get it to move any faster.
Tim Mason had some trouble with ppp:
Tony, As is noted on your web pages, the ppp setup and configuration within UnixWare 7.1.1 is via the gui and not manual text manipulation as in OSR5. I have noticed what seems to be a bug and I just cannot seem to get around it. Currently I am trying to connect to Earthlink via a dialup. I have successfully done this on an OSR5 and a UnixWare 7.0.1 OS but I cannot get the gui within the ppp setup to take the correct login to the ISP because of the slash i.e., ELN/loginname. When I input the correct login and click on the next button in the wizard the "/" is removed by the system! I eventually got tired of re-doing this and edited outside of the wizard but the system (ISP) will not authenticate me (CHAP). The bug remains but I worked the problem out. It seems the wizard was NOT entering my CHAP information correctly. The solution was to use PPPTALK and remove the complete bundle, link, and IP information - reset and save the ppp configuration then re-do the information using ONLY PPPTALK. Even so, the .pppcfg file had the login name incorrect (without the slash) and I had to manually edit the file, reset and save the configuration via PPPTALK. Afterwards the CHAP authentication works quickly and efficiently. Maybe you could incorporate this info into your page so that others may use it (if they have special characters in their logins - that is...) Tim ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Business2Business Custom Programming and Web Development "Enabling network techology for the information age" Tim Mason - Owner Phone: (253) 219-5839 or E-mail: firstname.lastname@example.org
Emergency Boot Disks
Unixware has the WORST implementation of emergency recovery ever seen. It's awful, it's slow, it's ridiculous: don't bother with it at all, get one of the Supertar products. The recovery ability is a hundred times better, and you can dump that idiotic Arcserve product at the same time.
This releases bundles the "lxrun" compatibility by default (you get the chance to install it with CD #2). I haven't yet tried any particular Linux apps, but see Roberto Zini's article on running Star Office under the OSR5 lxrun.
Visionfs 3.0 is included with this release as noted above. Merge 4.1 is available (extra cost).
There's a lot new here. One of the more interesting capabilities is that Unixware now can be a DHCP client (previous releases only offered a DHCP server). There is support for 8 network cards, incredible storage support: 2^31 HBA's, each with 2^31 buses and each bus supporting 2^31 SCSI targets, each with 2^31 LUNS. Nobody is building adapators with anything like this capacity, but Unixware is ready if they ever do.
Unixware now supports 8GB of pageable memory, and up to 64GB of dedicated memory (pageable memory is available to any program, dedicated memory is handled by specific programming techniques).
Ready to Switch?
I'll get some disagreement on this, but I think this product has come along far enough that the average OSR5 user could now switch without excessive pain and trauma. Yes, there are some bugs and wrinkles, and yes there are major sections that work very differently than OSR5 (the use of sacadm rather than getty is probably the worst of it), but I really think that the product has enough friendliness in it that you should be able to survive switching. You'll get ticked off, you'll surely experience some frustration, but I truly don't think it will be any worse than the transition from Xenix to Unix that many of us went through years ago. It's close enough.
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic