Re: Homedir backup (was Re: "Stateless Linux" project)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux