On Jan 23, 2008 2:25 AM, Beni Cherniavsky <[EMAIL PROTECTED]> wrote: > On Jan 23, 2008 1:49 AM, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > One way to get what you want is to simply use the same fishd socket on > > all machines. Can UNIX sockets be shared through e.g. NFS file shares? > > If so, your problem is already solved, just set the FISHD_SOCKET_DIR > > variable to point to the same place everywhere and it's rock and roll. > > > No. "Another peculiarity is that you cannot connect to such a socket from > another machine-not even if the other machine shares the file system > which contains the name of the socket. You can see the socket in a > directory listing, but connecting to it never succeeds." -- info libc >
Ok. > > If Unix sockets can't be shared, it would be possible to instead use a > > tcp socket. The additional code should be fairly minimal, I guess. > > > Well, yes, looks not as hard as I thought: No, should be doable. All the concerns below need to be addressed, of course. > > * tcp to which host? The default, in my opinion, should be to use a regular Unix socket. If you want a tcp socket, I think it's fair to require you to set it up yourself, e.g. _you_ decide this by setting FISHD_SOCKET_DIR to e.g. sparks.localdoman:1234 The variable should probably be renamed FISHD_SOCKET or something like that, as well. > * when fishd starts, it writes its host & port to > ~/.config/fish/fishd_address > * this must be done under NFS-proof locking to prevent race condition > * we assume here that there are no firewall issues With the above approach, none if this is an issue. Or at least, it is someone elses problem, which is the same thing. ;-) > * we should keep the unix socket for local connections, use tcp > for remote access only. I doubt that the performance difference between using 10 tcp sockets or using 9 tcp sockets and one unix socket is noticable. > * what if the One and Single fishd Instance dies? To make fishd more safe, we should probably fork off a watchdog process that can respawn fishd if this happens. This should be done regardless of whether fishd over tcp happens. > * like now: if fishd is dead at any stage, launch new one (using > aforementioned locking) We can only launch a new fishd _if_ we are the specified host. If the remote socket is dead for any reason, we're out of luck. > * small danger: fishd is not dead, but can't connect for some > network reason, so starting a new fishd. > this is a bit dirty, because we step over ~/.config/fish/fishd_address. > but if we always check for local socket before global, this > won't cause additional damage. With the process outlined above, changing things so variables are shared between two machines called sparks and jakita, with fishd running on sparks, would be done using: sparks$ set -Ux FISHD_SOCKET localhost:12345 jakita$ set -Ux FISHD_SOCKET sparks:12345 In theory, that should mean that on startup, fish connects to a local fishd instance using the default location. That fishd instance initializes and sends over all universal variable values, including the new value for FISHD_SOCKET, which fish then uses to connect to the _real_ fishd, wherever that is. So everything should work both at once and later on, for all fish instances. I see a few major unsolved problems with this approach: * User needs to pick a port number themselves. We can't standardize on one since we'll use one socket per user. * As Martin pointed out, the security implications are major. We _definitely_ need authentication of some sort. By assuming a shared home directory, one has effectively created what can be regarded as a secure and authenticated sidechannel for this purpose, which is all fine and useful, but I would definitely like to avoid writing my own authantication mechanism if at all possible - that kind of code is error prone. Axel > > -- > > Beni Cherniavsky <[EMAIL PROTECTED]> (I read email only on weekends) > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
