BACKRUSH  À¯´Ð½º¸í·É  ´ÙÀ½  ÀÚ·á½Ç  Ascii Table   ¿ø°ÝÁ¢¼Ó  ´Þ·Â,½Ã°£   ÇÁ·Î¼¼½º   ½©
ÁöÇÏö³ë¼±   RFC¹®¼­   SUN FAQ   SUN FAQ1   C¸Þ´º¾ó   PHP¸Þ´º¾ó   ³Ê±¸¸®   ¾Æ½ºÅ°¿ùµå ¾ÆÀÌÇǼ­Ä¡

±Û¾´ÀÌ: ¿ø°Ý ¿ø°Ý¹é¾÷ ufsdump Á¶È¸¼ö: 8243


.rhosts¿î¿µÀ» ÇؾßÇϸç 514¹øÆ÷Æ®¸¦ ¿­¾î¾ß ÇÕ´Ï´Ù.(inetd.conf)

#ufsdump 0uf host:/dev/rmt/0 /

¿¡·¯½Ã
´ë»ó ¼­¹öÀÇ .cshrc¸¦ Àá½Ã mv .cshrc cshrcÇسõÀºÈÄ Á¶Ä¡Çϱâ¹Ù¶÷

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.

°ü·Ã±Û : ¾øÀ½ ±Û¾´½Ã°£ : 2005/06/16 13:29 from 211.37.6.252

  ¹é¾÷µå¶óÀÌºê ¸®¼ÂÇÏ´Â ¹ýÁ» ¾Ë·ÁÁÖ¼¼¿ä ¸ñ·Ïº¸±â »õ±Û ¾²±â Áö¿ì±â ÀÀ´ä±Û ¾²±â ±Û ¼öÁ¤ sendmail relay ¼³Á¤  
BACKRUSH  À¯´Ð½º¸í·É  ´ÙÀ½  ÀÚ·á½Ç  Ascii Table   ¿ø°ÝÁ¢¼Ó  ´Þ·Â,½Ã°£   ÇÁ·Î¼¼½º   ½©
ÁöÇÏö³ë¼±   RFC¹®¼­   SUN FAQ   SUN FAQ1   C¸Þ´º¾ó   PHP¸Þ´º¾ó   ³Ê±¸¸®   ¾Æ½ºÅ°¿ùµå ¾ÆÀÌÇǼ­Ä¡