These are just small little descriptions of strange or interesting problems I've run across here and there. There's no order to them; they just get put in as they happen.
A SCO Release 5 system suddenly began spewing error messages and the only solution was to power off. On reboot, everything seemed to be fine. Customer called me; I had them go to single user mode and run badtrk. That ran fine until it reached 30%, and then the error messages began again, and did not stop. After several minutes, I had them power off again.
I packed up a spare hard drive and drove to the site. I found a fairly new system with an UltraWide SCSI controller, 68 pin cable properly terminated with an LVD molded terminator. Looked fine, but when I reached in and pushed on the drive cable connector, the left hand side moved in- it had not been properly seated by the installer or perhaps someone in the machine at a later date had knocked it loose.
That was all that it was. After seating the connector (and checking all other connectors), I re-ran badtrk and all was fine. Unfortunately, the crash had caused problems for their RealWorld accounting system, so we had to restore the prior day's backup for parts of that, but the hardware at least was now OK.
A customer had added a third SCSI drive to an older DEC system. This is a machine with pluggable hard drives where the backplane assigns the SCSI ID. The new drive was automatically assigned SCSI ID 2, and "mkdev hd" worked correctly. However, after ftp'ing files to this drive from Windows, the entire machine would lock up and have to be rebooted. The fsck always fixed the drive, but any use of it from Windows would lock it up again.
My first thought was termination, but this seemed unlikely on this machine because the backplane takes care of that automatically. The customer questioned that on the basis that he could ftp from another Unix machine without incident, but I felt that was not significant- he wasn't transferring the same amount of data or at the same speed- nor was he sure he had ftp'ed to the same drive!
I suggested switching the 2d drive with the third. This of course made what was /dev/u3 be /dev/u2 and vice versa, but we found that the problem remained with the drive in slot 3. I therefore felt the backplane had to be at fault, so we moved the new drive to slot 4, and that was when the reboot suddenly showed a forgotten tape drive at ID 2- this had been hidden by the backplane assignment of the drive to ID 2, but became visible when the drive became ID 3 by moving it.
Normally such a conflict would prevent the drive from working at all; it wouldn't even be seen, but here the ID conflict only caused it to malfunction under load.
With no ID conflict, the machine now worked properly.
The RedHat Linux 7.0 has a graphical sendmail administration in Linuxconf (it's not there by default, but you can configure Linuxconf to use it). By default, it configures for no relaying, but I needed to add an internal host on another subnet. Although the graphical tool has a section for doing that, it doesn't work.
The tool adds the domains to /etc/mail/ip_allow, but it never generates a .db file. The sendmail start/stop script regenerates .db files, but it doesn't reference ip_allow. As I couldn't find documentation for ip_allow at www.sendmail.org, I instead added the host to /etc/mail/access, restarted sendmail (which recreates access.db) and everything now worked.
Digiboard uses its "ditty" command to set the transparent print sequences that allow the /dev/pr* devices to work. On a recent install, I noticed that setting a port with "ditty term wy60" worked (that is, output directed to the corresponding /dev/pra02 or whatver port printed), but it also printed on the screen. This was because "ditty" didn't use ESC-d-# to turn on transparent print as it should have. Fortunately, the solution is simple:
ditty onstr "\033d#" offstr "\024"forces the correct sequences.
A newly installed Windows machine had ip connectivity, and could telnet to the SCO server, but could not browse network neighborhood even by using Start->Run->\\scobox
The problem was that it had the same name as another PC on the network. This gets reported at startup, but the user ignored it because they didn't understand what it meant.
I had added an HP 4050N printer and used the HP Network Printer Configuration tool in scoadmin to configure it with bootp. However, the printer initialized with an entirely different address. The problem was simply that the SCO server was also providing DHCP services, and by default, bootp is not enabled when DHCP is (bootp and dhcp are very similar protocols and actually use the same tcp/ip port unless configured specially- see /etc/inetd.conf). The hpnpcfg doesn't know that; it will happily add the information to /etc/bootptab, but it will not work.
There are two ways to fix this: you can telnet to the HP using the DHCP assigned address (available by printing the HPconfiguration shet) and change the address manually, or it can also be entered on the front panel through the menu functions.
An upgrade from an older 3.2 release to 5.0.6: I had restored the old system to /u/oldstuff, and wanted to recreate the printers that had existed there. No HP network printers were present. The following script was used after flattening symbolic links:
cd /u/oldstuff/usr/spool/lp/admins/lp/interfaces for i in * do cp $i /usr/spool/lp/model/$i done cd ../printers for i in * do dev=`grep Device: $i/configuration | sed 's/Device: //'` /usr/lib/lpadmin -p $i -v $dev -m $i enable $i /usr/lib/accept $i done
Two Okidata 590 printers connected to Windows PC's running Procomm required local printing capability through serial connections. Fortunately, a Digiboard was the access method, and Digi supports transparent print very nicely through the /dev/pr??? devices; if the terminal is connected on ttya04 and is doing a Wyse60 emulation all that is necessary is
ditty term wy60 ttya04in a startup file, and any output directed to /dev/pra04 will trigger a local print in the emulator.
The PC's seemed to be set up identically, but one printed oddly- the printhead would "chatter", seemingly acting as though it were double or triple striking every character, and yet the final result was normal, although it did take a long time to run. I couldn't discern any difference in the Procomm or Windows setup, and switching the printers showed that the problem was not there.
As Windows printing worked quite normally, I was sure the problem was within Procomm, but in fact the two machines were identical in that set up. As a test, I installed a Generic/Text only printer. That printed correctly, but I had to change the Procomm Print Setup to tell it that it was using 14.5 inch wide paper or it would cut text off after 80 characters (because it was no longer using the Oki driver, it didn't know that the text could be compressed by the printer using a 17.1 pitch setting). With that setup, I couldn't have RealWorld (the application software) control changing the character pitch, so that would have to be done manually as required. Not a great solution.
I felt there must be something wrong with the Oki driver or the general OS on that machine. I checked on the web for newer drivers, but Okidata doesn't have anything for that printer and just says that Windows supports it directly. I reinstalled the drivers from the Win95 CD, but nothing changed, so I left it with Procomm using the Generic driver and Windows using the original Oki590 driver; this at least works in both places, though not very well.
The final solution was to install Omnicom Technologies, Inc terminal emulator. This immediately fixed all problems, and has the advantage of being much simpler: this user doesn't need the mind numbing complexity of Procomm.
A client called with these observations: nobody but root could print, and many commands seemed to not work or worked incorrectly: "w", for example, would only show his login (like "who am i") but "who" worked correctly. I had him check permissions and ownership on /usr/bin/lp; the permissions were correct but the group ownership was wrong. He had already run the "Verify Software" in Scoadmin, and it reported 607 (!) errors. I asked him to review the errors and tell me what kind of problems were present, and all 607 were problems of ownership or permissions, and mostly ownership. Given this much to deal with, I suggested that he let the Software Manager fix these files, and I'd deal with any residual problems after that.
Unfortunately, the Software Manager failed to fix anything, and the first reason it gave was that there was no group "auth". I was startled by that, so asked him to look at /etc/group. There were only six entries in it; it stopped at uucp. Interestingly, there were signs of a botched vi session- he said that the first and last lines were blank.
Solution: recreate /etc/group from information in /etc/passwd, run the Software Manager and it now fixed all permissions and ownerships.
I was called in to see a client who complained that after an upgrade, they could no longer access shares from the old Unix server on the Windows network.
A little investigation revealed this: A new server and all new PC's had been installed in preparation for changing the primary application. In the process of doing this, a separate and all-new 192.168.2.0 sub-net was installed, because the plan was to immediately scrap the "old" server which was running on an unfortunate 22.214.171.124 subnet.
As it turned out, though, the old application could not be immediately scrapped because the new application vendor wasn't quite ready on time. So, to give the new PC's access to the old server, the primary consultant had added an 192.1.2.x port to his internet access router/firewall and changed the default route on the "old" server to point to that. Since the PC's already had their default route running through that router, this gave them access to the old server and its application.
Unfortunately, part of that application also relied on the PC's accessing Samba shares that the old server provided. Those shares were now not visible to the PC's because they were now on a different sub-net.
As Visionfs was installed and running on the new server, we could have just moved everything there, but the client did not want to move the old application due to fears that the installation of the new application software might involve disruptions in service. Therefore, they needed to access the shares from the old server.
I showed them that there are two ways to do that. One requires adding the server IP address and name to LMHOSTS
For Windows 95/98 thats C:\WINDOWS\LMHOSTS file, and all it needs in it is something like this:
10.1.36.5 mysmbserver #PRE
For NT and Windows 2000, it's "\WINNT\SYSTEM32\DRIVERS\ETC\LMHOSTS" (assuming your system is in \WINNT)
The "#PRE" is not a comment, it needs to be there. With this in place (and you need to reboot), you can do Start->Run, type \\mysmbserver and, all other things being equal, it will pop up.
If you do that, you can now map a network drive by name, but if you don't want to bother, you can also just map it by ip address: \\126.96.36.199\sharename
I showed them how to do it both ways and the PC's could now access the shares. Note that the shares will still NOT show up in the browse window, but you can access them with a mapped drive or with Start->Run->\\share-name-or-ip-address
Visionfs error logs can fill up if a virus on a PC is trying to attack what it thinks is another Windows server. The virus is unlikely to harm anything, but it can fill up logs.
Realworld "> REGCNT" to fix "number of allowable users exceeded", "Maximum Number of Users Exceeded"
"Initialize Medium" Microlite is /usr/lib/edge/bin/edge.segadm -b
Sendmail complaining about world-writable permissions - check parent directories - I had a customer chmod 777 /usr
Got something to add? Send me email.
More Articles by Tony Lawrence © 2009-12-11 Tony Lawrence