There was sombody here who mentioned taking advantage of the auth mecanism in SSH to decide which network we are on Another who mentioned that backupserver.location.organisation.com did not have to be the same machine - what if i was normaly resided in Oslo, (domain oslo.organisation.com - my computer gets this from dhcp - and sice this is my "main" location - my main backupserver is backupserver.oslo.organisation.com) Then i travel to the Sidney office - and the dhcp happily tells me that my domain is "sidney.organisation.com" - which means that the backupserver is backupserver.sidney.organisation.com. Both these backupservers has an alias - "backupserver". And my laptop happily connects to that through the internal LAN (fat pipe). But the best thing is: "something" in my profile tells the server that my main site is oslo - so while i am in flight home - the sidney server slowly sends the backup "back home" throug a small pipe. But what if am in Bangkok - and there are no office there (no backupserver)? Well, then i could tell the machine (manually) to backup anyway - using ssh (it should anyway use ssh in order to establish that it is really on a thrusted network) back to my "home" backupserver. And all this could be managed by the user from a small taskbar applet (se my former mail) Kyrre ons, 15.09.2004 kl. 21.20 skrev Michael Favia: > David Hollis wrote: > > >I think trying to determine location via Layer 2 means is going to be a > >big mistake. > > > Perhaps you are correct. > > >Networks tend to be very amorphous these days and node > >location is very non-physical. > > > Very valid point. Floating between wireless access point on same network > and all included. > > >The workstation should not care at all > >WHERE it is, it's more of a question of "can I get to where I need to?" > >If contact can be made to the "home directory backup server", it is able > >to sync. > > > Yes but the reason someone raised the MAC address issue was a bandwidth > concern. For instance you can reach my server from the internet via > cellphone infrared internet access (or dialup, public coffeshop) but i > wouldnt want to sync from there most of the time. Especially if my work > was more sensitive (financial, etc). > > >MAC address should play no part in this. Do you really want all of the > >client systems to stop backing up because you had to change an interface > >card in the router? Do you want to have to keep the same MAC address on > >that route forever so that you don't have to change every client in the > >org that may connect on that subnet? > > > > > I dont really have a problem with eternally spoofing the router address > but you convinced me that it isnt necessary or a good reference point to > judge ability/willingness to sync. Perhaps what we really want is this: > > 1. Assume can reach sync server > 2. If we are on a acknowledged MAC sync up without asking. > 3. If we aren't test bandwidth and assess amount to transfer then > present user with a nice throbber (with size of transfer, avg speed and > time expected) that allows him/her to decide or perhaps set a rule to > decide (e.g. under 5 mins sync auto). > > Regardless you have raised a good point that MAC addresses are NOT the > determining factor in our willingness/desire to sync. Instead bandwidth, > expected time on connection and perhaps the security of the connection > really determine it. In either case administrators could write rule that > prohibit outside syncing if desired (via MAC rules) and normal users > could benefit from increased portability. Sound better? > > -- > Michael Favia michael at insitesinc dot com > Insites Incorporated http://michael.insitesinc.com >
