© Copyright Robert Vasvari, 1993-2003.
Since RBrowser does not use any custom software on the remote
end, it has to rely on various implementations of UNIX utilities
and FTP servers. Some remote systems you connect to might no
have correct implementations of all the software RBrowser
relies on. This can cause errors in some operations. This
document is my attempt to record all the various problems,
weirdnesses etc.
1. Connecting:
You are trying to connect to a remote host as UNIX, you have
an account, and the login still fails. You try login with FTP and
it succeeds. This is most likely caused by the fact that some
administrators disable the inetd service
"rexec" by commenting out the appropriate line in
/etc/inetd.conf. Failing that, you may be able to
use the SSH protocol to log in. If you are connecting to LINUX,
please make sure you read the Linux section in this document.
2. .cshrc:
Even though RBrowser does not use a C shell, the rexec server
does read it during login. The one thing that can really screw up
a remote site is if there are any 'stty xxx' commands in your
.cshrc. These commands do not belong in
.cshrc, so make sure to remove them. (If necessary,
you'd place them in .login instead.)
3. SCP problems:
Many UNIX systems use OpenSSH today, which works quite well in
most cases. Unfortunately, there is a problem with scp, where
upon copying something to the remote system it fails with a
message like:
bash: scp: command not found
lost connection
This problem has nothing to do with RBrowser, as if you
attempt to run scp on the command line, you will get
the same result. It is caused by the fact that the ssh server has
to invoke scp on the remote server during file transfer and it
has to find it there. It does not use the PATH to find scp;
rather it is compiled in during build/install time. The scp
client *cannot* be moved after that! If is is moved, it will
produce the the error above.
4. Error reporting:
Some of the operations fail silently. Deleting files is most
prone to this. This is true in all of the protocols. For that
reason, folders that are potentially changed with the operation
are always reloaded after the operation. One common inducement
for a silent failure is replacing a folder by dropping into its
parent another folder with the same name. If some of the contents
of the original folder are not writable, the whole operation will
(silently on some systems) fail. In this case, always check
permissions!
5. Remote-to-Remote Transfer Gotchas:
Direct Remote-to-Remote File Transfers work very nicely in
RBrowser, as long as you observe some very simple rules:
1. The source machine must be able to resolve the target
machine's name. If you are transferring from HOST1 to HOST2,
HOST1 must be able to resolve the name HOST2. For this reason,
always login using fully qualified hostnames, such as
HOST2.MYDOMAIN.COM that can always be resolved. If the source
host cannot resolve the target host, the transfer will just hang,
and eventually time out.
2. As described above the username/password supplied at login
time will be used to initiate an scp connection from user1@HOST1
to user2@HOST2. If you use special RSA keys while logging on to
user2@HOST2, it is possible that those RSA keys do not work
coming from user1@HOST1. More potential problems described in the
SSH Issues Page.
6. Available space:
There are certain situations where RBrowser will report the
incorrect amount of available space on the remote host. This has
to do with the fact that, on UNIX, due to the use of symbolic
links there are many ways to reference the same directory. For
instance, your home directory path may be /u/myhome.
There is a link from /nfs/home to the same
directory. RBrowser knows that /u is a mount point,
but the shell thinks your home directory is
/nfs/home/u/myhome. RBrowser has no way to know that
/u/myhome = /nfs/home/u/myhome.
Therefore, RBrowser goes back to /nfs to find out
the available space. The number it gets will be different from
/u where the real mount point is. Unfortunately,
there is no workaround for this, except... If you really want to
know the avail space, you can follow the alternative path
(/u/myhome) in the viewer, in which case the
correct available space will be shown.
7. Files are lost during copying:
On the unix server, I have: 3flags.JPG and 3FLAGS.JPG in the same directory. When
I copy them back to my OSX client, only one of the files shows up. What can it be?
Well, RBrowser works as expected in this case. If you copy those files from a unix server
which presumably has a ufs (case sensitive) filesystem and copy them back
to an hfs filesystem on OSX, one file will overwrite the other, since hfs is not case
sensitive, only case preserving. You need to keep that in mind when naming your
files! Also, it is possible to keep a partition in your OSX box with a ufs filesystem
so that you can have the same behaviour as the server.
8. LINUX issues:
Some Linux distributions (most notably RedHat 7.2) do not
include uuencode/decode in their base install. RBrowser requires
these standard utilities in order to be able to list directories
correctly. If they are missing from the host you are trying to
connect to, complain loudly to your system administrator to
install the uuencode package. If, however, for any reason you are
unable to get it installed, here is how you can help yourself
WITHOUT having root access:
- Log on to the remote system using your Terminal app.
- In your home directory create /UNIX/bin (the name is
arbitrary, of course.):
>cd
>mkdir UNIX UNIX/bin
- cd in there and download the uuencode tarball from
RBrowser.com:
>cd UNIX/bin
>curl -O
ftp://ftp.rbrowser.com/downloads/uu.tar.gz
- Unpack it:
>tar xvzpBf uu.tar.gz
- Verify they are both there and executable:
>ls -la
-rwxr-xr-x 1 user group 8068 Jul 12 2000 uudecode
-rwxr-xr-x 1 user group 6636 Jul 12 2000 uuencode
- Delete the archive:
>rm uu.tar.gz
- You are done, log out!
- Back in RBrowser, bring up this site in the Login Panel.
Before logging in, Hit the "Edit xxx" button. In the
Preferences Panel, hit the Helpers tab. Insert
~/UNIX/bin: into the beginning of the Shell Search
Path field. Hit Save. Hit login and things should just work
normally.
In the SSH/UNIX protocols, RBrowser runs a Bourne (or
compatible) shell on the remote system. This shell must be really
consistent across multiple platforms, otherwise RBrowser cannot
work with it. RBrowser loves the Korn shell
(ksh), but /bin/sh works fine too. RBrowser
looks for ksh and if is not there, it uses
ash or zsh in that order. Here is the
problem: all distributions of Linux come with
bash instead of
sh (/bin/sh is usually a link to
/bin/bash). RBrowser has a really tough time with
bash because it is inconsistent. The only good
solution to this problem is to install ksh on the
Linux system. After installing ksh, blow away the
connection default file in ~/Library/Application
Support/RBrowser (if exists) and reconnect. Most Linux
systems today have ash at least, and at the time of
this writing we have seen no problem with it.
More issues for RedHat Linux users: besides the
inetd.conf file mentioned above, there is a bug in
RedHat 5.2: the PAM module, which is used for authentication, is
misconfigured by default. The way it ships, the rexec service is
completely disabled. Workaround: after backing up the
/etc/pam.d/rexec file as rexec.orig,
remove the line:
auth required /lib/security/pam_securetty.so
from the rexec file. Warning: it is conceivable that this fix
might expose you to possible security risks (extent unknown). It
is not known whether other versions of Linux, such as Debian or
SUSE have this problem.
A bit about shells: most of the shells that ship with Linux
are broken, most notably bash. RBrowser defaults to
use /bin/ash when you connect to Linux systems, and
you probably want to leave that alone, as it is the most
consistent one that ships with RedHat Linux.
9. Changing Group on a file:
RBrowser uses chgrp to change groups of files on
the remote system. Please note that currently, if the file is a
symbolic link, chgrp will set the group on the
target of the link, not the link itself.
SaveBack does not work:
There could be great differences between the local and remote
box that could cause a failure in the modification checking
mechanism. Plase make sure that the clocks on your and the remote
box are not too far apart (unless they are in a different
timezone). Use ntp (network time) wherever possible.
What to do if you are trying to do something and get
the beach ball?
Maybe the remote host you are connected to is not responding.
Try logging in using telnet or ssh from the
Terminal. If the host is not responding correctly, RBrowser may
get stuck trying to talk to it. These connection attempts will
time out usually after 60 seconds. After that, everything
will operate normally. If the attempt does not time out, you may
have to kill RBrowser using the Processes menu from the
Workspace, and restart it.
I tried to kill a background process, but it would not
go away...
Depending on the reliability of your network connection, some
background processes can hang. If this happens, the only thing
you can do is to restart RBrowser.