1.5.3


Old Stuff

 www.your-freedom.net
 www.secure-tunnel.com

Ticket #105 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

AlmostVPN hides the start-up drive

Reported by: anonymous Assigned to: andrei
Priority: normal Milestone: AlmostVPN 0.9.9
Component: PreferencePanel Version: 0.9
Severity: normal Keywords: file sharing drive afp
Cc:

Description

Alice, a user on node alpha, projects an SSH tunnel to node beta where Bob is a user, and Alice knows Bob's password. In the epoch before AlmostVPN Alice could mount the volumes beta_startup, Bob, and beta_part_B through her tunnel, beta_startup is the start-up volume on beta, and Bob's home area is on beta_startup. After Bob installed and exercised AlmostVPN, Alice could no longer see the volumes beta_startup or Bob through her SSH tunnel. She could still mount beta_part_B.

Change History

01/04/06 08:27:02 changed by andrei

  • keywords set to file sharing drive afp.
  • status changed from new to assigned.
  • version set to 0.9.
  • milestone set to AlmostVPN 0.9.9.

In described scenario, are we talking about AFP (Personal File Sharing)? Does the problem exhibit itself when Bob is running AlmostVPN or all the time? Does problem persists after Bob and/or Alice reboot they boxes?

Just installing AlmostVPN on the box should not (and does not) change any kind of system configuration (the only thing installation process will do is to copy Almost VPN Preference Pane to ~/Library/PreferencePanes). While Almost VPN profile is running, host name to IP resolution for some of the hosts "involved" might be altered, but Almost VPN should restore it back to original state once it done.

01/05/06 02:31:01 changed by anonymous

I am the originator of this ticket. I have reproduced the circumstances described above repeatedly on two PowerMac? G4s running 10,4.3. We are indeed talking about AFP through Alice's tunnel. Correct behavior is restored when Bob reboots his node. Unfortunately "repeatedly" is not the same as "consistently." I am unable to reproduce the problem "on demand." All I am able to say at this point is that after Bob repeatedly starts and stops a profile that includes the mount of a disk volume (a volume on node "gamma"), the adverse circumstances do arise. He sees no symptoms of the problem locally. Using only local tools it's a challenge for him to detect that his node has been corrupted. Thus without consulting Alice Bob does not even know when a reboot is in order.

01/05/06 08:06:31 changed by andrei

Actually I observed similar behavior ( some of the volumes become "un-mountable" remotely ) on my boxes, but I never though that this has something to do with SSH tunnels. In my case, once volume become "un-mountable", you can not remotely mount it even if you are trying to do it "directly" (from the same sub-net) without use of SSH tunnels.

I can not promise that I will be able to fix this one (it does look like something for Apple to fix), but I will try to figure out what is going on.

01/05/06 08:18:28 changed by andrei

FYI: It looks like just stopping and then starting "Person File Sharing" ( Sharing Preference Pane ) restores "mount-ability" for all Volumes.

01/18/06 11:57:47 changed by andrei

  • status changed from assigned to closed.
  • resolution set to fixed.

I think I fixed it. It was Apple problem after all, but I found other way to mount remote volumes which does not produce any bad side effects. Fix will be part of 0.9.9 build.