Re: SCO 5.0.7 MP5 network hung up

Brian K. White wrote:
Nico Kadel-Garcia wrote:
On 23 Feb, 17:35, "Steve M. Fabac, Jr." <smfa...@xxxxxxx> wrote:
mbennett wrote:
Steve,
The last time I had a problem with streams on 5.0.7 it was caused by
Samba. Is Samba in the mix?
Mark,

Samba is installed but not configured and is not running?

Slow up there. Which Samba? The last one published by SCO for 5.0.7,
which is Samba 3.0.14 I believe, and is pretty stable if somewhat out
of date?

Second. Given that you're using Samba, why can't your accounts
automatically mount a drive and transfer directly, rather than using
ftp? ftp is a very, very poor tool for modern file system transfer for
numerous reasons, including its extremely poor security model, the
confusion of firewall configuration with one port for data and one for
commands, the various binary versus text versus end-of-line settings,
etc.

Third. Why are you using /tmp for this? File ownership in /tmp is....
well an interesting problem. All it takes is mishandling one set of
files with the wrong permissions to completely muck up a scripted FTP
operation, and there are a lot of different processes that dump things
in /tmp/. If you can, consider using a designated /var/ directory,
such as '/var/ftp/transfer' for this sort of thing. In fact, your
"fetch" account should most certainly *not* use "/" as its home
directory!!!! No user account should, it causes potential conflicts
with user's /.[bashrc,.profile,etc.] files. 'vetch' should have its
own directory, such as '/var/fetch', so it can be left out of backup
systems easily and not reside in somewhere destinded to have other
debris.

That approach could operate well for both Samba access and this kind
of ftp access.

I have seen enough posts by Steve, heck even this one post proves it, to safely say the he has been doing this plenty long enough to know all of that and more. He didn't design or implement the scheme currently in place, he didn't write the software being used, he wasn't there when the current scheme was settled on, and doesn't know the various problemss the original people ran into. He inherited this box and can't make major changes to the way things work even if they only barely work, until _after_ he knows as much about the software and the job as the original authors and could for example, adjust the software itself to deal with any problems that his change created, or at least adjust it to sensibly debug whats wrong. He may not have any access to the code or happen to be fluent in that language. And even if he just happened to know all of that, you and I don't know what kind of mess it causes for the customer if he makes a change and it doesn't work perfect the first time. Whatever problem they're having now, they've at least already had it for a while and have been forced to be able to deal with it, and equally importantly, he didn't cause it.

Brian,

You've hit the nail on the head with the above comments. I've worked with
the client since July 2001 when I was contacted to resolve a problem
with the existing system configuration running SCO 5.0.5 on two servers with
1776 Software's Fault Freedom II product intended to mirror the application
programs and data between the live and backup servers in real time so that
if the live server dropped dead, the users would be able to reconnect to the
"floating" IP address and be served by the backup server. 1776 was installed
by the organization that set up the original servers and the client even
had Jack Willis from 1776 come in and work on the 1776 configuration.

When I first reviewed the "system," 1776 had been disabled from running as it
was proving to be a problem such that shutting down the backup server caused
the live server to shutdown and manually "failing" the live server to
bring the backup server on-line resulted in both servers going down.

I set up a script to mirror the application directory and user's home
directories from the live server to the backup server at 03:00 every day
using "find ./dir1 ./dir2 ./dir3 -mtime -1 -depth -print | cpio -oca | rcmd
target_host cpio -icvmdu." The script runs on both serves and is configured to
test to see if it is running on the server hosting the "floating" IP address
and if so, execute the cpio copy to the appropriate target.

The "system" ran with on-going problems on the original hardware as I worked
on the hardware issues I found until I replaced the two servers with two new
1.4GHZ PIII Supermicro based boxes in October 2002.

The PIII systems ran more reliably then the Pentium Pro boxes had and experienced
few hardware problems. The move to the new boxes was simply to move the DPT RAID
controllers from the old box to the new box and connect the external SCSI drive
cage (two DPT controllers, two separate external SCSI disk cages one for the
primary and one for the backup server). Other changes were to the backup system
to move the SCSI drivers for the tape from the old Adaptec 1520 and LSI controller
to the on-board Adaptec 3940 BLAD and reconfigure the network to load the drivers
for the on-board NIC.

The 1776 daemons were disabled in the rc2 scripts and /etc/inittab and we
continued to use the 3:00 cpio mirror from the live to the backup server.
One reason is that the backup server is unusable while 1776 is running as it
prevents access to the application and users home directories: You can't
use the backup system to test program modifications as you can't run the
application without having a second application directory and one or more
users with home directories located outside the 1776 mirrored directories.

In March 2008 we started to get "AllocB Fail: NSTRPAGES exceeded." I posted the
problem to c.u.s.m and implemented a cron script to log the "Streams memory in
use" output of netstat -m run every five minutes on both the live and the backup
servers. Nothing had changed on the servers but the client's network had been
modified by installing new wireless access points to blanket the warehouse and
support the fork truck wireless work stations. The client has been using wireless
stations in the warehouse since before July 2001. So wireless is not a new function.

Streams memory in use climbed on both the live and the backup sever and I increased
streams tunable parameters as suggested in TA 116684 (how to debug streams leak
failures).

This condition continued and we resorted to rebooting both servers once a week to
clear the streams memory in use and avoid the AllocB failure condition while I
worked to resolve the streams leak issue.

Bela pointed out that it is a questionable decision to stay with 5.0.5 and
try to resolve the streams leak when improved NIC drivers had been built
into 5.0.7, just because 1776 is installed on the 5.0.5 system and is not available
for 5.0.7 and "you are not even using the 1776 drivers anyway." He even suggested
that I could try installing the 5.0.7 NIC drivers on 5.0.5 "..and it might work."

I did install the 5.0.7 drivers on one of the 5.0.5 systems but that did not resolve
the streams leak condition.

In June 2008 we experienced the beginning of a two month period where 20+ SCSI disk
in both SCO 5.0.5 systems were destroyed by power problems (even though all the
servers are on APC smart ups units). In the end both the live and backup SCO 5.0.5
boxes were destroyed (mother boards won't boot and out of warranty), one IBM server
hosting MS Exchange, one Dell box hosting the company web site (all SCSI disks
damaged and the server hardware damaged), and a loaner PIII system I took to the client
to keep them in production (hard disks and motherboard fried). That turned out to
be caused by the electrical utility's substation feeding the building intermittently
dropping one phase of 440V 3-phase supply after hours. Oddly none of the Windows XP
computers on the users desks were affected, nor the HP Gigabit switches, system monitors,
firewall hardware, or Buffalo NAS units.

In August 2008 I installed two new Quad core Xeon severs and upgraded to SCO 5.0.7
with MP5 (after the utility replaced equipment in the substation and resolved the
power problem). Since then we have been running on the backup server (hosting the
floating IP) with the primary server acting as the backup server.

We are still seeing streams leak failures on both SCO 5.0.7 systems,
the active system (backup below) and the idle system (primary below)
only running Backup Edge jobs and receiving the 3:00 data copy:

streams memory in use:
App running on backup
Primary system as backup

Sun Aug 17 00:00:00 backup: 4892.77KB primary: 1721.72KB
Mon Aug 18 00:00:00 backup: 4916.15KB primary: 1686.99KB
Tue Aug 19 00:00:00 backup: 4990.44KB primary: 1826.50KB
Wed Aug 20 00:00:00 backup: 5060.12KB primary: 1731.08KB
Thu Aug 21 00:00:00 backup: 4845.19KB primary: 1798.98KB
Fri Aug 22 00:00:00 backup: 1726.99KB primary: 4902.79KB
Sat Aug 23 00:00:00 backup: 1790.89KB primary: 4917.39KB
Sun Aug 24 00:00:00 backup: 1879.66KB primary: 5006.53KB
Mon Aug 25 00:00:00 backup: 1738.70KB primary: 5074.10KB
Tue Aug 26 00:00:00 backup: 1773.36KB primary: 5140.23KB
Wed Aug 27 00:00:00 backup: 5157.67KB primary: 4974.42KB
Thu Aug 28 00:00:00 backup: 5234.51KB primary: 5042.23KB
Fri Aug 29 00:00:00 backup: 5301.64KB primary: 5096.07KB
Sat Aug 30 00:00:00 backup: 5348.25KB primary: 5138.01KB
Sun Aug 31 00:00:00 backup: 5351.77KB primary: 5142.53KB
Mon Sep 1 00:00:00 backup: 5362.11KB primary: 5150.92KB
Tue Sep 2 00:00:00 backup: 5450.20KB primary: 5163.15KB
Wed Sep 3 00:00:00 backup: 5402.03KB primary: 5191.70KB
Thu Sep 4 00:00:01 backup: 5425.90KB primary: 5210.98KB
Fri Sep 5 00:00:00 backup: 5484.59KB primary: 5222.46KB
Sat Sep 6 00:00:00 backup: 5551.04KB primary: 5340.85KB
Sun Sep 7 00:00:00 backup: 5564.16KB primary: 5354.97KB
Mon Sep 8 00:00:00 backup: 5580.32KB primary: 130.34KB
Tue Sep 9 00:00:00 backup: 5645.12KB primary: 161.25KB
Wed Sep 10 00:00:00 backup: 5709.29KB primary: 1739.61KB
Thu Sep 11 00:00:00 backup: 5784.94KB primary: 1869.80KB
Fri Sep 12 00:00:00 backup: 5868.10KB primary: 1955.73KB
Sat Sep 13 00:00:00 backup: 5952.58KB primary: 2071.43KB
Sun Sep 14 00:00:00 backup: 5981.32KB primary: 2097.17KB
Mon Sep 15 00:00:00 backup: 5991.00KB primary: 2103.84KB
Tue Sep 16 00:00:00 backup: 6047.72KB primary: 2166.89KB
Wed Sep 17 00:00:00 backup: 6088.63KB primary: 2205.81KB
Thu Sep 18 00:00:00 backup: 6121.55KB primary: 2239.08KB
Fri Sep 19 00:00:00 backup: 6162.16KB primary: 2282.69KB
Sat Sep 20 00:00:00 backup: 6203.71KB primary: 2383.82KB
Sun Sep 21 00:00:00 backup: 6216.90KB primary: 2439.45KB
Mon Sep 22 00:00:00 backup: 6230.07KB primary: 2452.62KB
Tue Sep 23 00:00:00 backup: 6297.55KB primary: 2551.02KB
Wed Sep 24 00:00:00 backup: 6419.91KB primary: 2671.37KB
Thu Sep 25 00:00:00 backup: 6757.41KB primary: 3014.58KB
Fri Sep 26 00:00:00 backup: 7132.56KB primary: 3470.25KB
Sat Sep 27 00:00:00 backup: 7904.34KB primary: 4209.89KB
Sun Sep 28 00:00:00 backup: 8151.75KB primary: 4457.66KB
Mon Sep 29 00:00:00 backup: 8179.38KB primary: 4468.77KB
Tue Sep 30 00:00:00 backup: 8380.23KB primary: 4696.45KB
Wed Oct 1 00:00:00 backup: 8561.24KB primary: 4950.81KB
Thu Oct 2 00:00:00 backup: 8625.29KB primary: 5040.68KB
Fri Oct 3 00:00:00 backup: 8775.09KB primary: 5252.62KB
Sat Oct 4 00:00:00 backup: 9019.84KB primary: 5576.55KB
Sun Oct 5 00:00:00 backup: 9191.54KB primary: 5714.86KB
Mon Oct 6 00:00:00 backup: 9203.78KB primary: 5760.34KB
Tue Oct 7 00:00:00 backup: 9332.88KB primary: 8521.60KB
Wed Oct 8 00:00:00 backup: 9570.55KB primary: 8756.63KB
Thu Oct 9 00:00:00 backup: 9708.25KB primary: 8850.79KB
Fri Oct 10 00:00:00 backup: 9747.88KB primary: 8890.75KB
Sat Oct 11 00:00:00 backup: 9730.73KB primary: 8923.17KB
Sun Oct 12 00:00:01 backup: 9792.87KB primary: 8938.75KB
Mon Oct 13 00:00:00 backup: 9804.90KB primary: 8949.17KB
Tue Oct 14 00:00:00 backup: 9818.10KB primary: 8960.96KB
Wed Oct 15 00:00:00 backup: 9839.28KB primary: 8982.79KB
Thu Oct 16 00:00:00 backup: 9869.25KB primary: 9015.11KB
Fri Oct 17 00:00:00 backup: 9904.91KB primary: 9049.42KB
Sat Oct 18 00:00:00 backup: 9930.51KB primary: 9074.73KB
Sun Oct 19 00:00:00 backup: 9942.63KB primary: 9089.85KB
Mon Oct 20 00:00:00 backup: 9942.97KB primary: 9090.19KB
Tue Oct 21 00:00:00 backup: 9968.32KB primary: 9106.46KB
Wed Oct 22 00:00:00 backup: 9986.00KB primary: 9128.85KB
Thu Oct 23 00:00:00 backup: 10010.19KB primary: 9156.39KB
Fri Oct 24 00:00:00 backup: 10035.27KB primary: 9180.76KB
Sat Oct 25 00:00:00 backup: 10067.83KB primary: 9214.04KB
Sun Oct 26 00:00:00 backup: 10071.85KB primary: 9216.70KB
Mon Oct 27 00:00:00 backup: 10074.86KB primary: 9220.71KB
Tue Oct 28 00:00:00 backup: 10124.95KB primary: 9255.61KB
Wed Oct 29 00:00:00 backup: 10200.77KB primary: 9346.61KB
Thu Oct 30 00:00:00 backup: 10398.23KB primary: 9543.07KB
Fri Oct 31 00:00:00 backup: 10445.52KB primary: 9591.72KB
Sat Nov 1 00:00:00 backup: 10481.71KB primary: 9622.89KB
Sun Nov 2 00:00:00 backup: 10496.14KB primary: 9587.71KB
Mon Nov 3 00:00:00 backup: 10498.88KB primary: 9643.72KB
Tue Nov 4 00:00:00 backup: 10539.64KB primary: 9679.49KB
Wed Nov 5 00:00:00 backup: 10560.25KB primary: 9704.46KB
Thu Nov 6 00:00:00 backup: 10582.54KB primary: 9728.74KB
Fri Nov 7 00:00:00 backup: 10620.43KB primary: 9766.28KB
Sat Nov 8 00:00:00 backup: 10668.43KB primary: 9812.64KB
Sun Nov 9 00:00:00 backup: 10673.76KB primary: 9818.96KB
Mon Nov 10 00:00:00 backup: 10675.31KB primary: 9820.51KB
Tue Nov 11 00:00:00 backup: 10706.47KB primary: 9848.32KB
Wed Nov 12 00:00:00 backup: 10731.33KB primary: 9876.18KB
Thu Nov 13 00:00:00 backup: 10770.02KB primary: 9915.86KB
Fri Nov 14 00:00:00 backup: 10802.43KB primary: 9948.28KB
Sat Nov 15 00:00:00 backup: 10827.28KB primary: 9972.42KB
Sun Nov 16 00:00:00 backup: 10827.96KB primary: 9974.11KB
Mon Nov 17 00:00:00 backup: 10829.31KB primary: 9974.45KB
Tue Nov 18 00:00:00 backup: 10856.98KB primary: 10002.77KB
Wed Nov 19 00:00:00 backup: 10899.66KB primary: 10042.80KB
Thu Nov 20 00:00:00 backup: 10935.68KB primary: 10079.82KB
Fri Nov 21 00:00:01 backup: 10909.33KB primary: 10120.89KB
Sat Nov 22 00:00:00 backup: 11009.67KB primary: 10153.39KB
Sun Nov 23 00:00:00 backup: 11024.39KB primary: 10170.82KB
Mon Nov 24 00:00:00 backup: 11031.01KB primary: 10178.44KB
Tue Nov 25 00:00:00 backup: 11080.49KB primary: 10224.63KB
Wed Nov 26 00:00:00 backup: 11169.64KB primary: 10313.74KB
Thu Nov 27 00:00:00 backup: 11225.30KB primary: 10369.09KB
Fri Nov 28 00:00:00 backup: 11256.48KB primary: 10403.62KB
Sat Nov 29 00:00:00 backup: 11319.93KB primary: 10463.07KB
Sun Nov 30 00:00:00 backup: 11274.87KB primary: 10476.67KB
Mon Dec 1 00:00:00 backup: 11331.79KB primary: 10476.93KB
Tue Dec 2 00:00:00 backup: 11391.63KB primary: 10535.77KB
Wed Dec 3 00:00:00 backup: 11464.43KB primary: 10608.21KB
Thu Dec 4 00:00:00 backup: 11559.54KB primary: 10702.96KB
Fri Dec 5 00:00:00 backup: 11653.95KB primary: 10799.09KB
Sat Dec 6 00:00:00 backup: 11729.86KB primary: 10873.00KB
Sun Dec 7 00:00:00 backup: 11738.29KB primary: 10882.07KB
Mon Dec 8 00:00:00 backup: 11739.22KB primary: 10884.36KB
Tue Dec 9 00:00:00 backup: 11775.61KB primary: 10918.75KB
Wed Dec 10 00:00:00 backup: 11831.48KB primary: 10975.62KB
Thu Dec 11 00:00:00 backup: 11893.30KB primary: 11036.44KB
Fri Dec 12 00:00:00 backup: 11956.67KB primary: 11099.81KB
Sat Dec 13 00:00:00 backup: 12010.68KB primary: 11154.82KB
Sun Dec 14 00:00:00 backup: 12015.32KB primary: 11160.46KB
Mon Dec 15 00:00:00 backup: 12018.84KB primary: 11164.98KB
Tue Dec 16 00:00:00 backup: 12066.74KB primary: 11209.88KB
Wed Dec 17 00:00:00 backup: 12105.59KB primary: 11249.14KB
Thu Dec 18 00:00:00 backup: 12152.96KB primary: 11296.10KB
Fri Dec 19 00:00:00 backup: 12198.85KB primary: 11336.99KB
Sat Dec 20 00:00:00 backup: 12237.19KB primary: 11381.97KB
Sun Dec 21 00:00:00 backup: 12248.27KB primary: 11344.47KB
Mon Dec 22 00:00:00 backup: 12256.37KB primary: 11391.06KB
Tue Dec 23 00:00:01 backup: 12306.66KB primary: 11449.43KB
Wed Dec 24 00:00:00 backup: 12352.48KB primary: 11481.46KB
Thu Dec 25 00:00:00 backup: 12364.68KB primary: 11428.89KB
Fri Dec 26 00:00:00 backup: 12367.00KB primary: 11512.14KB
Sat Dec 27 00:00:00 backup: 12416.34KB primary: 11561.48KB
Sun Dec 28 00:00:00 backup: 12462.81KB primary: 11612.36KB
Mon Dec 29 00:00:00 backup: 12461.51KB primary: 11661.90KB
Tue Dec 30 00:00:00 backup: 12562.48KB primary: 11705.25KB
Wed Dec 31 00:00:00 backup: 12612.07KB primary: 11758.20KB
Thu Jan 1 00:00:00 backup: 12647.98KB primary: 11793.85KB
Fri Jan 2 00:00:00 backup: 12658.51KB primary: 11804.39KB
Sat Jan 3 00:00:00 backup: 12703.82KB primary: 11848.34KB
Sun Jan 4 00:00:00 backup: 12705.01KB primary: 11849.89KB
Mon Jan 5 00:00:00 backup: 12710.88KB primary: 11856.04KB
Tue Jan 6 00:00:00 backup: 12739.79KB primary: 11880.67KB
Wed Jan 7 00:00:00 backup: 12769.59KB primary: 11914.11KB
Thu Jan 8 00:00:00 backup: 12805.75KB primary: 11950.62KB
Fri Jan 9 00:00:00 backup: 12849.28KB primary: 11992.80KB
Sat Jan 10 00:00:00 backup: 12886.69KB primary: 12029.57KB
Sun Jan 11 00:00:00 backup: 12894.52KB primary: 12038.04KB
Mon Jan 12 00:00:00 backup: 12907.49KB primary: 12050.01KB
Tue Jan 13 00:00:00 backup: 12962.23KB primary: 12106.11KB
Wed Jan 14 00:00:00 backup: 13172.01KB primary: 12317.89KB
Thu Jan 15 00:00:00 backup: 13232.46KB primary: 12377.33KB
Fri Jan 16 00:00:00 backup: 13269.88KB primary: 12413.75KB
Sat Jan 17 00:00:00 backup: 13298.77KB primary: 12441.64KB
Sun Jan 18 00:00:00 backup: 13228.16KB primary: 12448.57KB
Mon Jan 19 00:00:00 backup: 13316.70KB primary: 12461.57KB
Tue Jan 20 00:00:00 backup: 4945.23KB primary: 12542.81KB
Wed Jan 21 00:00:00 backup: 4918.67KB primary: 1742.80KB
Thu Jan 22 00:00:00 backup: 4955.01KB primary: 1774.10KB
Fri Jan 23 00:00:00 backup: 4896.75KB primary: 1816.76KB
Sat Jan 24 00:00:00 backup: 4927.20KB primary: 1907.07KB
Sun Jan 25 00:00:00 backup: 4958.70KB primary: 1985.17KB
Mon Jan 26 00:00:00 backup: 4967.61KB primary: 1987.49KB
Tue Jan 27 00:00:00 backup: 5074.34KB primary: 2096.10KB
Wed Jan 28 00:00:00 backup: 5189.31KB primary: 2213.44KB
Thu Jan 29 00:00:00 backup: 5358.14KB primary: 2376.11KB
Fri Jan 30 00:00:01 backup: 5407.54KB primary: 2427.34KB
Sat Jan 31 00:00:00 backup: 5505.57KB primary: 2537.47KB
Sun Feb 1 00:00:00 backup: 5559.06KB primary: 2591.96KB
Mon Feb 2 00:00:00 backup: 5576.44KB primary: 2608.97KB
Tue Feb 3 00:00:00 backup: 5685.08KB primary: 2713.92KB
Wed Feb 4 00:00:00 backup: 5724.22KB primary: 2812.64KB
Thu Feb 5 00:00:00 backup: 5757.01KB primary: 2846.43KB
Fri Feb 6 00:00:00 backup: 5815.11KB primary: 2848.88KB
Sat Feb 7 00:00:00 backup: 5876.65KB primary: 3025.62KB
Sun Feb 8 00:00:00 backup: 5920.27KB primary: 3173.21KB
Mon Feb 9 00:00:00 backup: 5940.70KB primary: 3291.63KB
Tue Feb 10 00:00:00 backup: 6030.04KB primary: 3460.18KB
Wed Feb 11 00:00:00 backup: 6086.47KB primary: 3617.93KB
Thu Feb 12 00:00:00 backup: 6145.70KB primary: 3753.72KB
Fri Feb 13 00:00:00 backup: 6192.02KB primary: 3901.20KB
Sat Feb 14 00:00:00 backup: 6237.37KB primary: 4001.10KB
Sun Feb 15 00:00:00 backup: 6247.51KB primary: 4017.28KB
Mon Feb 16 00:00:00 backup: 6258.77KB primary: 4026.18KB
Tue Feb 17 00:00:00 backup: 6338.25KB primary: 4144.11KB
Wed Feb 18 00:00:00 backup: 6383.74KB primary: 4217.89KB
Thu Feb 19 00:00:00 backup: 6416.00KB primary: 4248.79KB
Fri Feb 20 00:00:00 backup: 6464.23KB primary: 4296.66KB
Sat Feb 21 00:00:00 backup: 4911.78KB primary: 4432.82KB


Typical 03:00 transfer log shows:

Mirror backup started: Mon Feb 23 03:00:00 CST 2009
/usr1/tm/data/BARCDMST.DAT
/usr1/tm/data/PARTMST.DAT
/usr1/tm/data/PARTMISC.DAT
.....
/tmp/ICEXTEND.IMP
/tmp/coIKYWGEa0004k
/tmp/mirror.10079
4843492 blocks <-- 2.4G Typical
/tmp
Mirror backup complete: Mon Feb 23 03:02:11 CST 2009


grep blocks /usr/spool/mail/root | less

....
7168503 blocks
88552 blocks
1930326 blocks
7201899 blocks
7058509 blocks
7161228 blocks
7165861 blocks
7162960 blocks
135808 blocks
4439641 blocks
7083857 blocks
7083857 blocks
7195178 blocks
7181933 blocks
7180734 blocks
7186290 blocks
3571079 blocks
2903880 blocks
7212423 blocks
7202332 blocks
7208217 blocks
7186240 blocks
7203255 blocks
4819379 blocks
3237278 blocks
7170501 blocks
7146010 blocks
7269283 blocks
7243128 blocks
7252397 blocks
4802075 blocks
4773643 blocks
7267790 blocks
7237444 blocks
(END)


The latest precompiled samba that I know of is 3.0.20a on osr507suppcd5
Which Steve's post showed he has.
There used to be a kernel bug which his kernel does not have and which his samba does not tickle anyways.
However, the earliest Samba that works with Vista and all other clients is 3.0.22. I seem to remember some further fixes in 3.0.24 too
but obviously if you have to build at all, just build the latest.

One reason FOR using ftp right off the bat is, it's a lot easier to automate from a random windows pc. You could write a little batch file with the name & password in the batch file so that it always works, even if someone copies the .bat/.cmd to a new pc. Keeping windows usernames in sync with smbpasswd, or vice/versa is too much bs to ask a small shop to deal with. Otoh, creating a public access share that doesn't care about user names or passwrods but limits access by client pc IP, compined with /etc/ipf.conf to ensure no one from outside can spoof it might be ok, but why? There is really nothing wrong with ftp. It's been stock in the system for ages and is among the most thoroughly tested and debugged code anywhere and is dead simple to use and MS isn't free to keep changing the protocol so it doesn't work after a while. Non of which is true of samba. ftp is almost certainly not his streams leak and so should probably be among the last things he turns into a new variable by changing. As for /tmp, again, can he modify the application code?
Even if he could, using /tmp for temp files does not cause streams leaks and so should not be something he wastes time fiddling with right now.

I can't modify the code but the application maintainer can. It's just a
question of what battle to choose next. He has additional /XXTMP directories
that he populates with data based upon company's divisions. Moving the files
he now populates to /tmp to /some_new_tmp should not be that big a deal. As for
fetch's home directory in /: I tried setting the home directory to /tmp but that
was not successful as it was problematical then to access the alternate /XXTMP
directories by navigating within IE (click backup, up, etc...).

I would like to move away from ftp just because of the entries I see in
/usr/adm/syslog. They don't give me the warm fuzzies and seem to indicate
a configuration problem.

I still hesitate to try to switch to samba as the client has been purchasing
Dell laptops with MS Vista for the sales reps and when they are in-house,
are connecting to the internal LAN. The GM's reason for going to Vista on the
laptops is that "...can get them serviced when something fails when out of town
on sales calls."

Further complicating the mix is the plan to place a third SCO 5.0.7 box
off-site at a co-loc provider facility as a third fail-over server should
building power take out both on-site servers. This will likely use hardware
based VPN endpoints and SAMBA traffic may be problematical where FTP will not.


If it were me I'd probably start by commenting out all the unused services in /etc/inetd.conf
swat and cups (ipp) jump out at me as new and thus suspect.
cups came with mp5. I'm not 100% sure if he can disable that and still have a working traditional lpd spooler. I think so. He'll have to research that himself. In any event he could probably block port 631 in ipf.conf from anywhere but loopback to at least ensure that no pc or printer is hitting the service.

All good suggestions. I'll give them a try. I'll also replace the find...cpio
script to copy files at 03:00 with rsync and see what that does for streams
leaks (if anything).

Because of the problem in June-Aug with power destroying the hard disks and
and ultimately the systems, I had implemented rsync on each box to copy
the files in the application directories and the parent of the users home
directories to /util/backup/... at 10:00, 14:00, 17:00 and 22:00 and have
Backup Edge configured to backup /util/backup to a NAS server at 10:15, 14:15,
17:15, and 22:15 to capture the days business so that we did not have to
re-enter a full days production if (when) the hard disks failed and we have
to install new disks and restore from backup. The rsync copy to /util/back
only runs on the "live" server hosting the floating IP. Each system is
backed up to DVD-RAM each night as well as doing a master backup of the
"live" system's /util/backup to the NAS so that the 10:05, 14:15, etc..
backups are differential of only the changed files.



Also see this thread where there appeared to be a link between a particular nic and a drastic streams leak on 507.

http://groups.google.com/group/comp.unix.sco.misc/browse_thread/thread/972e47390a5096dc?hl=en&ie=UTF-8&q=osr507+streams+leak#2fc5fb360382ea52

I reviewed the thread but did not see that the OP posted the resolution to the
problem nor the result of changing the NIC.


Two different userland programs appeared to cause leaks, which generally isn't possible, but simply unplugging a nic and thus ensuring no traffic actually passes over that nic, but still using the apps, halted the leak. Implying it's not the userland apps themselves but the nic driver doing the leaking.

Can't do that on the live system as the only access is via the network and the
client runs two shifts. The fact that the idle backup system also has
streams leak recommends mis-behaving network hardware as the ultimate source
of the problem.


So I'd also try a different nic which uses a different driver, or try upgrading or downgrading the driver for the existing nic.


I'll have to give that some thought. The system board has two Gigabit NIC's

|| HW Broadcom NetXtreme Gigabit Ethernet BCM575X Compatible - PCI Bus# ||
|| SCO TCP/IP ||
|| - SCO NFS Runtime System

Index: 13
DeviceNum: 0
Function: 0
Bus: 3
VendorId: 0x14e4
DeviceId: 0x1659
RevId: 0x21
Command: 0x0006 Memory Enabled, I/O Disabled
Status: 0x0010
ClassCode: 0x020000 Ethernet controller
CacheLineSize: 8 32 bit words
HeaderType: 0x00 Single-function, Standard encoding
BaseAddr[0]: Memory 0xff7f0000, 64 bit space
CardbusCISPtr: 0x00000007
SubsysVendorID: Asustek Computer, Inc.
SubsystemID: 0x8149
InterruptLine: IRQ-10
InterruptPin: INTA
New Capabilities
CapID: 0x01 PCI Power Management (PM)
CapID: 0x03 Vital Product Data (VPD)
CapID: 0x05 Message Signaled Interrupts (MSI)
CapID: 0x10


Index: 14
DeviceNum: 0
Function: 0
Bus: 4
VendorId: 0x14e4
DeviceId: 0x1659
RevId: 0x21
Command: 0x0006 Memory Enabled, I/O Disabled
Status: 0x0010
ClassCode: 0x020000 Ethernet controller
CacheLineSize: 8 32 bit words
HeaderType: 0x00 Single-function, Standard encoding
BaseAddr[0]: Memory 0xff8f0000, 64 bit space
CardbusCISPtr: 0x00000007
SubsysVendorID: Asustek Computer, Inc.
SubsystemID: 0x8149
InterruptLine: IRQ-11
InterruptPin: INTA
New Capabilities
CapID: 0x01 PCI Power Management (PM)
CapID: 0x03 Vital Product Data (VPD)
CapID: 0x05 Message Signaled Interrupts (MSI)
CapID: 0x10


Odd: HW reports:


Report about cpu for failover.xxxxxx.com on Wed Feb 25 13:05:16 2009

There are 4 CPUs on this system.

CPU 1 performs like a 800Mhz Intel Pentium greater than III

Processor: 1 (0xffffe)
Physical CPU: 1
Logical CPU: 1
Vendor ID: GenuineIntel
cpu_family: 6
cpu_id: 0x000006fb
type: 0
family: 6
model: 15
stepping: 11
brandId: 0

I know that the system was built with a 2.1GHz Quad Core chip: hwconfig -h:

device address vec dma comment
======== ============= === === ================================================
kernel - - - rel=3.2v5.0.7 kid=2003-02-18
cpu - - - unit=1 family=6 type=gt PentIII
cpuid - - - unit=1 vend=GenuineIntel tfms=0:6:15:11(0)
fpu - 13 - unit=1 type=80387-compatible
pci 0xcf8-0xcff - - am=1 sc=0 buses=6
PnP - - - nodes=0
clock - - - type=TSC/2.133409588Ghz
serial 0x3f8-0x3ff 4 - unit=0 type=Standard nports=1 base=0 16550A/16
serial 0x2f8-0x2ff 3 - unit=1 type=Standard nports=1 base=8 16550A/16
console - - - unit=vga type=0 num=12 scoansi=1 scroll=50
floppy 0x3f2-0x3f7 6 2 unit=0 type=135ds18
kbmouse 0x60-0x64 12 - type=Keyboard|PS/2 mouse id=0xFF
udi - - - UDI environment
adapter - - - ha=0 type=usb_msto UDI SCSI HBA
adapter 0x1f0-0x1f7 14 - type=IDE ctlr=0 dvr=wd
adapter - 10 - type=aacraid ha=0 driver=B7348
bcme0 - 10 - chip=BCM5721 mem=FF7F0000 addr=00:1e:8c:d5:66:06
cd-rom - - - type=IDE ctlr=0 cfg=mst unit=0 dvr=Srom->wd
disk - - - type=S ha=0 id=0 lun=0 bus=0 ht=aacraid unit=0
Sdsk - - - cyls=8922 hds=255 secs=63 unit=0 fts=sdb
Sdsk-0 - - - Vnd=Adaptec Prd=ASR-2130S Mirro Rev=0001
usb_ehci - 17 - PCI bus=0 dev=29 func=7
usb_uhci - 17 - PCI bus=0 dev=29 func=0
usb_uhci - 18 - PCI bus=0 dev=29 func=1
cpu - 255 - unit=2 family=6 type=gt PentIII
cpuid - - - unit=2 vend=GenuineIntel tfms=0:6:15:11(0)
fpu - - - unit=2 type=80387-compatible
cpu - 255 - unit=3 family=6 type=gt PentIII
cpuid - - - unit=3 vend=GenuineIntel tfms=0:6:15:11(0)
fpu - - - unit=3 type=80387-compatible
cpu - 255 - unit=4 family=6 type=gt PentIII
cpuid - - - unit=4 vend=GenuineIntel tfms=0:6:15:11(0)
fpu - - - unit=4 type=80387-compatible

And I just noticed that the IRQ10 is being shared between the configured NIC
and the Adpatec 2130S RAID controller. I normally try to avoid sharing IRQ's
and just missed this when I set up the system. I'll see about moving one of
them to IRQ11 or run netconfig and disable the current NIC and select the
NIC shown as using IRQ11 above.
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
.

Relevant Pages

  • Re: Configuring Samba 3 on Openserver 6
    ... I'm trying to configure Samba 3.0.2 to run on SCO Openserver 6 ... I have no prior experience with Samba but I was able to get it running ... No matter what I try I can not connect to the Unix server from a ... install Microlite Backup Edge and a proper backup device ...
    (comp.unix.sco.misc)
  • Re: Error on network card
    ... underuns correlate to a backup that was being run (Files copied from ... server via samba). ... There was a reboot at 20:25:42 because the system ...
    (comp.os.linux.networking)
  • Re: Error on network card
    ... underuns correlate to a backup that was being run (Files copied from ... server via samba). ...
    (comp.os.linux.networking)
  • Samba - NTBackup Error: Access to this device or folder has been denied
    ... I have Samba 2.2.5 running on Red Hat and it serves as a file server for my ... Windows network. ... Samba Mapped Drive using NT Backup I get the following error: ...
    (linux.redhat)
  • RE: SBS Back up Failure
    ... attached the log and report from yesterday's backup also. ... One or more components of Small Business Server Backup failed. ... recommended that you review errors in the Event log related to the service. ... Notifications task in the Server Management Monitoring and Reporting taskpad. ...
    (microsoft.public.windows.server.sbs)