Page MenuHomeFreeBSD

retire rmt(8), the remote magtape protocol module
Needs RevisionPublic

Authored by emaste on Jan 23 2020, 3:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 1:04 AM
Unknown Object (File)
Nov 30 2023, 12:15 AM
Unknown Object (File)
Nov 28 2023, 11:28 AM
Unknown Object (File)
Nov 22 2023, 4:17 PM
Unknown Object (File)
Nov 22 2023, 4:02 PM
Unknown Object (File)
Nov 13 2023, 5:20 PM
Unknown Object (File)
Nov 13 2023, 5:06 PM
Unknown Object (File)
Oct 1 2023, 1:26 AM
Subscribers

Details

Summary

rcmds like rsh and rcp were removed in rS324351 but rmt was not included.
TODO: add it to net/bsdrcmds

See also D12573

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

emaste added a subscriber: rgrimes.

(I missed including the usr.sbin/Makefile change to remove rmt from SUBDIRS, changed locally)

This revision is now accepted and ready to land.Jan 23 2020, 4:03 PM
rgrimes requested changes to this revision.Jan 23 2020, 7:09 PM

The TODO: must be done before rmt is removed. And I think further discussion on -arch about this should occur, rmt is kinda a common thing for people that run tapes, and tapes are still alive.

This revision now requires changes to proceed.Jan 23 2020, 7:09 PM

rmt, rdump, rrestore all support something other than rsh(1) as a transport mechanism, ie ssh. Also if rmt goes you need to kill rdump, rrestore and fix the man pages. MFC'able depreication notices should go in first too.

ObsoleteFiles.inc
41

need to remove /etc/rmt also

@rgrimes this change was prompted by me trying to figure out what to do with the /etc/rmt symlink while working on pkgbase issues. Do you have any objection to starting with just removing that? (It exists to support remote mode in ancient UNIX tar commands.)

@emaste Yes I object especially if that is the basis for this change. Why are we messing with other software to fix a defeciency in pkg base? symlinks in /etc/ should be supported. My fear is that though you say /etc/rmt "is to support ancient tar commands" the reality is everyone using rmt probably refers to it via /etc/rmt and this is going to break if you remove it. Using the word ancient is poor taste, all things "Unix" are ancient :-) I am ancient also by your standards :-(.

How are the symlinks /etc/termcap, /etc/unbound, and /etc/aliases handled by pkgbase? You certainly can't go removing those.

@rgrimes there is no pkgbase deficiency that I'm trying to work around, it's just hoping to retire what appears to be a historical accident and remove the only binary executable in /etc.

How are the symlinks /etc/termcap, /etc/unbound, and /etc/aliases handled by pkgbase? You certainly can't go removing those.

See e.g. share/termcap/Makefile

etc-termcap:
        ${INSTALL_SYMLINK} -T "package=runtime" \
            ${BINDIR}/misc/termcap ${DESTDIR}/etc/termcap

*sigh* usr.sbin/rmt/Makefile needs updated to do the proper packaging of rmt and your done?

rmt, rdump, rrestore all support something other than rsh(1) as a transport mechanism, ie ssh

We don't need rdump and rrestore for that though, it's true for plain dump/restore. It seems such usage should really be explained in the man page.

You need r{dump,restore} to talk rmt protocol to a remote tape drive, you can not just pipe over ssh to a remote tape drive.

You need r{dump,restore} to talk rmt protocol to a remote tape drive, you can not just pipe over ssh to a remote tape drive.

Not precisely true, given that rdump is just a link to dump, but I see your point. Still we should document such use in the man page.

when dump/restore are invoked with the leading r they change behavior and speak "rmt". Yes, there is probably much documentaiton missing.

when dump/restore are invoked with the leading r they change behavior and speak "rmt". Yes, there is probably much documentaiton missing.

They don't actually check argv[0], remote mode is switched on by looking for : in the file argument.