In article <1993Aug10.084403.16432@iti.gov.sg> jameslow@iti.gov.sg (James Low (RC)) writes:
[deleted]
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>From john@cs.wmich.edu Wed Aug 4 03:53:02 1993
>
>Assuming by "hard disk" you mean SCSI disks, you can run the following script
>as root:
>
>---------------- cut here -----------------
>#!/bin/sh
>#
># add-disk
>#
># Runs the commands to make Solaris locate a new disk that
># has been plugged in after the system was booted.
>#
>
>_DVFS_RECONFIG=YES; export _DVFS_RECONFIG
>
>/etc/init.d/drvconfig
>/etc/init.d/devlinks
>
>exit 0
>---------------- cut here -----------------
>
>This will only work if you already have at least one SCSI disk loaded in,
>because the SCSI parts of the kernel have to be loaded. I use this on a
>semi-regular basis, and it's worked for me. If you look at the stuff in
>/etc/init.d, that's all the "/reconfigure" does anyway.
>
>--Dave
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
[deleted]
>--
> James Low Teck Koon
> Information Technology Institute, National Computer Board, S'pore
> Email: jameslow@iti.gov.sg jameslow@itivax.bitnet
> Phone: (65) 7720438 Fax: (65) 7795966
Running
modinfo
will tell you what loadable modules are currently loaded. If the
'sd' driver is not loaded, running
modload -p drv/sd
will load that driver into the kernel.
Tom.
-- --- Tom Kimpton tom@dtint.dtint.com Digital Technology Int. (801)226-2984 500 W. 1200 South, Orem UT, 84057 FAX (801) 226-8438From matt@jarthur.Claremont.EDU Ukn Aug 11 16:55:46 1993 Received: from cns8.cns.ucalgary.ca (cns-gate.hsc.ucalgary.ca) by ume.med.ucalgary.ca (4.1/CPSC-BACS4.1) id AA19078; Wed, 11 Aug 93 16:55:46 MDT Received: by cns8.cns.ucalgary.ca (4.1/CPSC-CNS4.1) id AA03245; Wed, 11 Aug 93 16:54:26 MDT Return-Path: <sun-managers-relay@ra.mcs.anl.gov> Received: from ra.mcs.anl.gov by cns8.cns.ucalgary.ca (4.1/CPSC-CNS4.1) id AA03241; Wed, 11 Aug 93 16:54:17 MDT Received: by ra.mcs.anl.gov id AA07235 (5.65c/IDA-1.4.4 for sun-managers-outbound); Wed, 11 Aug 1993 12:36:50 -0500 Sender: sun-managers-relay@ra.mcs.anl.gov Received: from delta.eecs.nwu.edu by ra.mcs.anl.gov with SMTP id AA07229 (5.65c/IDA-1.4.4 for <sun-managers@ra.mcs.anl.gov>); Wed, 11 Aug 1993 12:36:46 -0500 Precedence: bulk Received: from JARTHUR.CLAREMONT.EDU by delta.eecs.nwu.edu with SMTP id AA08278 (5.65c/IDA-1.4.4 for <sun-managers@eecs.nwu.edu>); Wed, 11 Aug 1993 12:36:34 -0500 Message-Id: <199308111736.AA08278@delta.eecs.nwu.edu> Subject: How to create pts devs.(answer) To: sun-managers@eecs.nwu.edu Date: Wed, 11 Aug 93 10:36:31 PDT From: Matthew Hughes <matt@jarthur.Claremont.EDU> Reply-To: Matthew Hughes <matt@jarthur.Claremont.EDU> Followup-To: junk X-Mailer: ELM [version 2.3 PL11] Status: RO X-Status: X-Keywords: X-UID: 87
I asked how to create more pts devices on a Solaris 2.2 machine, and I was kindly informed that the correct kernel variable to change is pt_cnt. In other words, add the line set pt_cnt=number to /etc/system and reboot with a -r flag. Matt
From gb@cadalyst.com Ukn Aug 11 22:05:03 1993 Received: from cns8.cns.ucalgary.ca (cns-gate.hsc.ucalgary.ca) by ume.med.ucalgary.ca (4.1/CPSC-BACS4.1) id AA19243; Wed, 11 Aug 93 22:05:03 MDT Received: by cns8.cns.ucalgary.ca (4.1/CPSC-CNS4.1) id AA03477; Wed, 11 Aug 93 22:03:44 MDT Return-Path: <sun-managers-relay@ra.mcs.anl.gov> Received: from ra.mcs.anl.gov by cns8.cns.ucalgary.ca (4.1/CPSC-CNS4.1) id AA03473; Wed, 11 Aug 93 22:01:41 MDT Received: by ra.mcs.anl.gov id AA07384 (5.65c/IDA-1.4.4 for sun-managers-outbound); Wed, 11 Aug 1993 15:08:29 -0500 Sender: sun-managers-relay@ra.mcs.anl.gov Received: from delta.eecs.nwu.edu by ra.mcs.anl.gov with SMTP id AA07378 (5.65c/IDA-1.4.4 for <sun-managers@ra.mcs.anl.gov>); Wed, 11 Aug 1993 15:08:24 -0500 Precedence: bulk Received: from uu2.psi.com by delta.eecs.nwu.edu with SMTP id AA29098 (5.65c/IDA-1.4.4 for <sun-managers@eecs.nwu.edu>); Wed, 11 Aug 1993 15:08:08 -0500 Received: from cadalyst.UUCP by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA21147 for ; Wed, 11 Aug 93 15:50:55 -0400 Received: by cadalyst (4.1/SMI-4.1) id AA08009; Wed, 11 Aug 93 14:01:03 CDT Date: Wed, 11 Aug 93 14:01:03 CDT From: gb@cadalyst.com (George Beougher) Reply-To: gb@cadalyst.com (George Beougher) Followup-To: junk Message-Id: <9308111901.AA08009@cadalyst> To: sun-managers@eecs.nwu.edu Subject: SUMMARY Re: Solaris 2.2 floppy access Status: RO X-Status: X-Keywords: X-UID: 88
Original: | | Good morning Sun Managers. | | I have just loaded Solaris 2.2 on an LX and a Classic and everything was | going great untill I tried to tar a file from another SPARC. | | The tar command responds with a 'cannot open' message and when trying to | mount the a pcfs floppy the system says that the device is already mounted | but I can't seem to find what is tieing it up. | | Does anyone have any ideas? |
Thanks for all your help Sunmanagers.
Here is a summary of responses. They all refference the same new Solaris feature. I found that leaving "vold" alone and creating a new device that points to the /dev/rfd0a device worked best for me. "vold" ties up the /dev/rfd0c mount point. I just use my new device for "tar" because "vold" works really well for 'automounting' the DOS floppies.
1)
The pcfs file sytsem will be mounted in /floppy/floppy0 with "vold" opperating.
2)
A swell new macintosh feature that mounts your cd and floppy for you (even when you aren't root!). It's called "vold". you can edit /etc/vold.conf or just kill vold. Then all will be normal again (to a certain extent).
3)
Check out the section in the one of the release documents regarding "volume management".
4)
/etc/init.d/volmgt stop then you can use the floopy with tar... to enable vold: /etc/init.d/volmgt start
5)
It's because you have the volume manager running. Check out the man page for vold(1M). Basically, the volume manager detects when you insert a floppy, and automagically mounts it as PCFS, if formatted MS-DOS, under /floppy (the same things happens when a cdrom is inserted, and it is mounted under /cdrom).
6) from Access Graphics (thanks bill)
SRDB ID : 5624
SYNOPSIS : Unable to mount/use floppies with Solaris 2.2
DETAIL DESCRIPTION :
When running Solaris 2.2 on a Desktop system with 3-1/2" floppy drive a problem may arise when trying to mount a diskette:
# mount -F ufs /dev/diskette /mnt mount: /dev/diskette is busy or number of allowable mount points exceeded
OR possibly:
# tar tvf /dev/diskette tar: cannot open /dev/diskette
SOLUTION SUMMARY : This condition is a side-effect of the Volume Management software introduced with Solaris 2.2. There are two possible workarounds to this condition:
- disable Volume Management altogether # /etc/init.d/volmgt stop
- Remove the floppy drive from Volume Management's repertoire: # vi /etc/vold.conf ( comment out the following lines ) use floppy drive /dev/diskette dev_floppy.so floppy0 insert /vol*/dev/fd[0-9]/* user=root /usr/sbin/rmmount eject /vol*/dev/fd[0-9]/* user=root /usr/sbin/rmmount
Find the PID for vold, kill and restart it # ps -ef | grep vold # kill <pid> # /usr/sbin/vold
Diskette operations should then operate as expected.
KEYWORDS : mount, diskette, floppy, busy, exceeded PRODUCT : disk_admin
SUNOS RELEASE : Solaris 2.X UNBUNDLED RELEASE : n/a HARDWARE RELEASE : Sun4c, Sun4m ISO-9001 STATUS : Controlled
|=========================================================| | George Beougher Title: System Engineer | | Cadalyst Resources ARPA: georgeb@cadalyst.com| | 11122 Aurora Avenue UUCP: cadalyst\!georgeb | | Des Moines, IA 50322 | |=========================================================|
From jgraves@eng.auburn.edu Ukn Aug 11 23:30:16 1993 Received: from cns8.cns.ucalgary.ca (cns-gate.hsc.ucalgary.ca) by ume.med.ucalgary.ca (4.1/CPSC-BACS4.1) id AA19276; Wed, 11 Aug 93 23:30:16 MDT Received: by cns8.cns.ucalgary.ca (4.1/CPSC-CNS4.1) id AA03557; Wed, 11 Aug 93 23:28:57 MDT Return-Path: <sun-managers-relay@ra.mcs.anl.gov> Received: from ra.mcs.anl.gov by cns8.cns.ucalgary.ca (4.1/CPSC-CNS4.1) id AA03553; Wed, 11 Aug 93 23:28:18 MDT Received: by ra.mcs.anl.gov id AA07412 (5.65c/IDA-1.4.4 for sun-managers-outbound); Wed, 11 Aug 1993 15:30:45 -0500 Sender: sun-managers-relay@ra.mcs.anl.gov Received: from delta.eecs.nwu.edu by ra.mcs.anl.gov with SMTP id AA07406 (5.65c/IDA-1.4.4 for <sun-managers@ra.mcs.anl.gov>); Wed, 11 Aug 1993 15:30:37 -0500 Precedence: bulk Received: from eng.auburn.edu (edison.eng.auburn.edu) by delta.eecs.nwu.edu with SMTP id AA20009 (5.65c/IDA-1.4.4 for <sun-managers@eecs.nwu.edu>); Wed, 11 Aug 1993 15:30:22 -0500 Received: from yellin.eng.auburn.edu by eng.auburn.edu (4.1/SMI-4.0 edison 1.21) id AA25555; Wed, 11 Aug 93 15:30:18 CDT Date: Wed, 11 Aug 93 15:30:18 CDT From: Jeff Graves <jgraves@eng.auburn.edu> Reply-To: Jeff Graves <jgraves@eng.auburn.edu> Followup-To: junk Message-Id: <9308112030.AA25555@eng.auburn.edu> To: sun-managers@eecs.nwu.edu Subject: SUMMARY: Problem with Solaris 2 backup to a remote tape unit. Status: RO X-Status: X-Keywords: X-UID: 89
Sun Managers:
ORIGINAL QUESTION:
A few days ago we changed one of our servers from an ELC running SunOS 4.1.3 to a Classic running Solaris 2.2 . This machine is also the tape host for an Exabyte used primarily for backups. Since the change, I have not been able to run rdump/ufsdump specifying this machine as the remote tape host, except when running rdump/ufsdump from root which we don't want to do. If I run rdump/ufsdump specifying the backup file as local rather than remote, then this problem does not occur. If I run dump to a disk file instead of the tape drive, I get the same results. The following output listing illustrates the problem:
armstrong.eng.auburn.edu{jgraves}1: /usr/sbin/ufsdump 5ucsf 23000 /dev/rmt/0cn / . . DUMP: Dumping /dev/rdsk/c0t3d0s0 (/) to /dev/rmt/0cn . . . DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: level 5 dump on Fri Aug 6 15:46:43 1993 DUMP: 19518 blocks (9.53MB) on 1 volume DUMP: DUMP IS DONE armstrong.eng.auburn.edu{jgraves}2: /usr/sbin/ufsdump 5ucsf 23000 armstrong:/dev/rmt/0cn / . . DUMP: Dumping /dev/rdsk/c0t3d0s0 (/) to /dev/rmt/0cn on host armstrong . . . DUMP: Protocol to remote tape server botched (in rmtgets). rdump: Lost connection to remote host. DUMP: Bad return code from dump: 1 armstrong.eng.auburn.edu{jgraves}3: /bin/su Password: # /usr/sbin/ufsdump 5ucsf 23000 armstrong:/dev/rmt/0cn / . . DUMP: Dumping /dev/rdsk/c0t3d0s0 (/) to /dev/rmt/0cn on host armstrong . . . DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: level 5 dump on Fri Aug 6 17:41:25 1993 DUMP: 19524 blocks (9.53MB) on 1 volume DUMP: DUMP IS DONE #
[the remaining part of the listing deleted]
Any ideas, hints, RTFM pointers, etc, will be greatly appreciated.
Jeff Graves jgraves@eng.auburn.edu
THANKS TO:
From: trinkle@cs.purdue.edu (Daniel Trinkle) From: "Richard J. Niziak" <rickn@copley.com> From: jandoo@thijssen.nl (Jan van Doorn) From: Kelly G. Price <Kelly.Price> From: poffen@sj.ate.slb.com (Russ Poffenberger) From: Ian_MacPhedran@engr.usask.ca (Ian MacPhedran) From: sdo@phoebus.larc.nasa.gov (Sharon O. Beskenis) From: vasey@issi.com From: hoogs@alc.com From: hkatz@nucmed.NYU.EDU (Henry Katz) From: Tom Conroy <trc@NSD.3Com.COM> From: Ron Russell <rrussell@ag.auburn.edu>
SOLUTION:
The problem was in my .cshrc file, as almost everyone pointed out. We use the Modules package to manage applications in a user's environment, and we have separate sets of modules for Solaris 1 and Solaris 2. A few modules have not yet been defined for Solaris 2, one of which was in my module load list. When I would log into or use a remote command to a Solaris 2 machine, Modules would give an error message for the missing module, and this error message would cause the remote dump (probably rmt) to choke. Removing the offending module from my module list fixed the problem. I did not have this problem when armstrong, the tape host, was running Solaris 1, however. I do have the line if ($?USER == 0 || $?prompt == 0) exit in my .cshrc but it is after the module load command. My thanks to everyone who responded, and yes, next time I will read the FAQ first.
Jeff Graves jgraves@eng.auburn.edu
RESPONSES:
From: trinkle@cs.purdue.edu (Daniel Trinkle)
My guess is that you have something in the remote user's .cshrc file that generates output that ufsdump sees and assumes is coming from the remote rmt process. I will assume you are doing the backup as jgraves. I would suggest trying
armstrong.eng.auburn.edu{jgraves}1: rsh armstrong echo yes
If you see anything other than "yes", you know something is wrong. You probably don't see this for root because root's login shell is /bin/sh, and .profile does not get sourced except for login shells (rsh is not a login shell).
To solve this, put the following close to the beginning of jgraves' .cshrc, possibly after setting PATH and umask. You must have it before any stty commands, or anything else that might generate output.
if ( ! $?prompt ) exit
Daniel Trinkle trinkle@cs.purdue.edu Dept. of Computer Sciences {backbone}!purdue!trinkle Purdue University 317-494-7844 West Lafayette, IN 47907-1398
From: "Richard J. Niziak" <rickn@copley.com>
Got this from the SUN-FAQ:
29) My rdump is failing with a "Protocol botched" message. What do I do?
The problem produces output like the following:
DUMP: Date of this level 0 dump: Wed Jan 6 08:50:01 1993 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0a (/) to /dev/nrst8 on host foo DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 8232 blocks (4.02MB) on 0.00 tape(s). DUMP: Protocol to remote tape server botched (in rmtgets). rdump: Lost connection to remote host. DUMP: Bad return code from dump: 1
This occurs when something in .cshrc on the remote machine prints something to stdout or stderr (eg. stty, echo). The rdump command doesn't expect this, and chokes. Other commands which use the rsh protocol (eg. rdist, rtar) may also be affected.
The way to get around this is to add the following line near the beginning of .cshrc, before any command that might send something to stdout or stderr:
if ( ! $?prompt ) exit
This causes .cshrc to exit when prompt isn't set, which distinguishes between remote commands (eg. rdump, rsh) where these variables are not set, and interactive sessions (eg. rlogin) where they are.
########################################################################## + Richard J. Niziak + Systems Engineer + e:mail -> rickn@copley.com Copley Systems + land mail -> Copley Systems, Inc + 165 University Ave + Westwood, MA 02090 + voice mail -> (617)320-8300 x305 + ##########################################################################
From: jandoo@thijssen.nl (Jan van Doorn)
Hi,
Did you check the FAQ:
29) My rdump is failing with a "Protocol botched" message. What do I do?
The problem produces output like the following:
DUMP: Date of this level 0 dump: Wed Jan 6 08:50:01 1993 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0a (/) to /dev/nrst8 on host foo DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 8232 blocks (4.02MB) on 0.00 tape(s). DUMP: Protocol to remote tape server botched (in rmtgets). rdump: Lost connection to remote host. DUMP: Bad return code from dump: 1
This occurs when something in .cshrc on the remote machine prints something to stdout or stderr (eg. stty, echo). The rdump command doesn't expect this, and chokes. Other commands which use the rsh protocol (eg. rdist, rtar) may also be affected.
The way to get around this is to add the following line near the beginning of .cshrc, before any command that might send something to stdout or stderr:
if ( ! $?prompt ) exit
This causes .cshrc to exit when prompt isn't set, which distinguishes between remote commands (eg. rdump, rsh) where these variables are not set, and interactive sessions (eg. rlogin) where they are.
Looks awfully similar to me! Good luck! -- Jan van Doorn, Thijssen BV, Veenendaal, Holland. +31 8385 35111, jandoo@thijssen.nl.
From: Kelly G. Price <Kelly.Price>
Hi Could this problem be caused by your .cshrc? Specifically, do you have anything in your .cshrc that does output to stdout before the "if ($?USER == 0 || $?prompt == 0) exit" line is executed?
Kelly
From: poffen@sj.ate.slb.com (Russ Poffenberger)
The errors tyou listed are usually caused by performing operations in the login's .cshrc. An example would be 'biff y', that tries to grab or modify the terminal characteristics. This confuses the remote dump protocol.
Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies ATE UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 Voice: (408)437-5254 FAX: (408)437-5246
From: Ian_MacPhedran@engr.usask.ca (Ian MacPhedran)
>From the FAQ for this list: 29) My rdump is failing with a "Protocol botched" message. What do I do?
The problem produces output like the following:
DUMP: Date of this level 0 dump: Wed Jan 6 08:50:01 1993 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0a (/) to /dev/nrst8 on host foo DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 8232 blocks (4.02MB) on 0.00 tape(s). DUMP: Protocol to remote tape server botched (in rmtgets). rdump: Lost connection to remote host. DUMP: Bad return code from dump: 1
This occurs when something in .cshrc on the remote machine prints something to stdout or stderr (eg. stty, echo). The rdump command doesn't expect this, and chokes. Other commands which use the rsh protocol (eg. rdist, rtar) may also be affected.
The way to get around this is to add the following line to the beginning of .cshrc, before any command that might send something to stdout or stderr:
if ( ! $?USERS || ! $?PROMPT ) exit
This causes .cshrc to exit when USERS or PROMPT isn't set, which distinguishes between remote commands (eg. rdump, rsh) where these variables are not set, and interactive sessions (eg. rlogin) where they are.
From: sdo@phoebus.larc.nasa.gov (Sharon O. Beskenis)
Hi Jeff! I have seen this before. This occurs when you have commannds executed that require an interactive shell and one does not exist such as rsh, rdump, ufsdump to a remote host, etc. We do the following in our .cshrc files
if ($?prompt) then set prompt="`hostname`> " set notify stty dec stty erase ^H /usr/games/fortune date endif
The ($?prompt) construct is used to test for an interactive shell so that rlogin works as expected whereas rdump will not try to set terminal characteristics that are non-existent or send date output to your process on the host invoking the remote dump. I hope this helps.
Sharon Beskenis Systems Manager Lockheed Engineering & Sciences Co. NASA Langley Research Center MS 478 Hampton, VA 23681-0001 (804)864-1703
From: vasey@issi.com
> Since the change, I have not been able to run rdump/ufsdump specifying > this machine as the remote tape host, except when running rdump/ufsdump > from root which we don't want to do.
Under 4.1.2 cannot dump regular filesystems or directories except as a member of the "operator" group, since rdump needs read access to the inode list, and this was granted via the /dev device entries. Although, the 4.1.2 dump fails earlier in the process with a different message when this happens, it could be a related problem for your version. (Sorry, no 2.2 here until late this year.) (Who said Unix error messages needed to be meaningful, anyway? ;^)
++ Ron vasey@issi.com International Software Systems Peace! ++ 1+512+338-5724 9430 Research, Austin TX 78759 <><
From: hoogs@alc.com
longshot:
check your dump user's group. this really shouldn't cause the problem, though, since dump is starting up. i have not been able to get our solaris box working within our backup scheme since svr4 and bsd don't use the same gid for 'operator'/'sys'.
-Tim
From: hkatz@nucmed.NYU.EDU (Henry Katz)
Jeff,
You've already checked the .rhosts, /etc/hosts and /etc/hosts.equiv for correctness. Also check the .cshrc on the remote host to see if it has any interactive portion with the console.
Henry Katz hkatz@nucmed.med.nyu.edu
From: Tom Conroy <trc@NSD.3Com.COM>
Hi Jeff:
Let me sumarize your testing:
1 - dump from Solaris machine to local tape - successful 2 - remote dump of Solaris machine to local tape - unsuccessful 3 - remote dump of Solaris machine to local tape *from sh* - successful 4 - dump from Solaris machine to local file - successful 5 - remote dump of Solaris machine to local file - unsuccessful 6 - remote dump of Solaris machine to local file (w/FQDN) - unsuccessful
Observations:
Using local dump rather than remote dump works (hostname:filename forces remote dump).
Using remote dump always fails *except* with bourne shell. Weird. The remote dump will use the shell initialization files (.cshrc or .profile) appropriate to the shell used on the remote machine. The shell that you are running 'ufsdump' from should be irrelevant unless you changed the default shell for root ...
Anyway, the problem is somewhere in your root .cshrc or .login file. If there is anything sent to standard output by these files, remote dumps will fail. To fix, remove whatever is in the file that is echoing something.
Good Luck,
trc
Tom Conroy trc@NSD.3Com.COM NSD Engineering SysAdm Group 3Com Corporation Santa Clara, CA
From: Ron Russell <rrussell@ag.auburn.edu>
I would suggest that you look in the newsgroup:comp.unix.solaris for the FAQ. In this FAQ is a listing of commonly experienced problems.
The protocol botched is an FAQ. I was out most of the day and thus did not see your message till late. There are hints as to why this happens and it does not seem to be SOL related.
What I think would work as a front-line test ist to try this as another user that does not have the same startup files.
In otherwords, RTFFAQ ala sun-mgrs.... :-{
I am head-deep in awk-scripts so I cannot test this and I would not dare from home. Please send me a summary as I am curious to hear if this differs in SOL2 from SOL1.
Regards,, Ron
Ronald C. Russell ronald.c.russell@ag.auburn.edu Network Mangler Voice: (205) 844-3213 College of Ag. FAX: (205) 844-4814 Auburn University Auburn AL, 36849 ##################################################
From: Cron report <news@ms.uky.edu>
This site has received a news article entitled
Problem with Solaris 2 backup to a remote tape unit.
apparently posted by you to a questionable group or groups:
comp.sys.sun.managers is not a real USENET group. If your site treats it as valid, this is most likely due to an old accident, prank, or software bug. Though some other sites may also recognize the name, the group is not official and doesn't have a large audience. You may want to look at comp.sys.sun.admin instead.
An official list of USENET groups, as well as a partial list of bogus groups, is regularly posted to news.announce.newgroups and news.groups. You may wish to take a look at them.
This is an automatic letter; no reply is necessary. If you wish to discuss this message, please contact kherron@ms.uky.edu, Kenneth Herron.
This archive was generated by hypermail 2.1.3 : Wed Feb 22 2006 - 04:45:08 MST