<--iNT13-->
Group: Members
Posts: 10
Joined: June 2004 |
|
Posted: June 15 2004,03:08 |
|
Quote (cbagger01 @ June 14 2004,12:39) | It sounds like a cool idea that could work for many poeple, but there is one "gotcha" that I can think of:
If you are a dialup/PPoE user, or someone with a static IP address, then you cannot connect to the Internet until your "saved" networking configuration is restored.
This leaves you in a "Catch-22" situation where you need an Internet Connection to restore your settings, but you need your settings in order to create an Internet connection.
However, this idea can work for users that have "hands-free" DHCP Internet access like Cable Modems, Home-routers, schools and businesses. |
I (kind of) thought of that (problem). From the luxury of ignorance I think there's a couple of ways around that:- Boot DSL from the CD and:- ;1. at the "stock" gui choose "reload config" from menu, enter details of "config" (ie. url, protocol, port, username, password, etc), and the appropriate services are "re-started", fstab re-written etc with the new values. So it should be possible to even mount NFS as /home, load "custom" desktop and menus, perhaps even .dsl extensions. ;2. before starting the Xserver - load custom settings from offsite, re-start services and re-write/read settings as necessary - then start the Xserver and Window Manager and other (now) customised settings.
Which ever method, or variation of, if taken it would require the ability to "re-start" services and "re-write/re-read" config settings after boot. My understanding (limited) is that this ability is the norm under Deb... It should also be possible, and certainly desirable, to set some configs at boot time (either at the command line or from a local device as specified via the restore option at boot time) - and retain those (sic) settings when "restoring" "offsite" settings... In short - "offsite" settings don't necessarily "over-write" boot time settings, unless implicit in the offsite settings.
One possible complication is the need to logon and authenticate remotely as one user, and run DSL as another - but that's probably another post
|