Menu
▾
▴
devil-linux-develop
|
From: Tim T. <t....@co...> - 2004-05-26 17:22:42
|
While making some fixes to mount_cdrom for live update (due to issues with read-only mounts of disk device) it occured to me there was another issue - after reboot to a new version, pre_init will invoke for the upgrade-config script where the user will be required to provide input on the console. If the user is in fact at a remote location, the box is now hung. Q: It looks like upgrade-config needs some post-processing to actually upgrade the real config? A few alternatives occurred to me - - Make the choice to run upgrade-config default to "no", and let user ssh in later to run it. Can we setup all interactive logins to check for mismatch and prompt/run the upgrade script there? In some situation, the boot might not be succesfull unless the config is upgraded. - Add another boot-line option like "DL_remote" that would indicate never to require console input. This could be used to skip the upgrade prompt entirely, or just change the default answer. - Add and option to upgrade-config that takes default choices if no answer in n seconds, and leave the pre_init stuff alone. pre_init could detect the new "DL_remote" flag and call upgrade-config with the right options. The user could ssh in to accept and save the new config, or reject it and run the upgrade script again. Comments? Tim |
|
From: Friedrich L. <fl...@fl...> - 2004-05-26 22:17:41
|
Tim Tait wrote on 26.05.2004 19:22 MET: > > While making some fixes to mount_cdrom for live update (due to issues > with read-only mounts of disk device) it occured to me there was another > issue - after reboot to a new version, pre_init will invoke for the > upgrade-config script where the user will be required to provide input > on the console. If the user is in fact at a remote location, the box is > now hung. It times out in 5 minutes in this case. See around line 87 in pre_init. In CVS this file is build/scripts/script/pre_init. When I look at this a second time I think we should change the if condition. In case of a timeout the returned character is the empty character so the upgrade is done. Then a confirmation asks to use this config and times out after 5 minutes and then the old configuration is restored and another confirmation times out in 5 minutes. So we are finally at 15 minutes till such system boots after remote upgrade without local input. Therefore I think in case of a timeout in the upgrade confirmation we should rather not upgrade at all but start the system after a shortend timeout of lets say 2 minutes. > Q: It looks like upgrade-config needs some post-processing to actually > upgrade the real config? > > A few alternatives occurred to me - > > - Make the choice to run upgrade-config default to "no", and let user > ssh in later to run it. Can we setup all interactive logins to check > for mismatch and prompt/run the upgrade script there? In some situation, > the boot might not be succesfull unless the config is upgraded. If you keep your update within the series, eg. update from 1.x.y to 1.x.z then the config files should not have changed. You might miss one or the other update to a start script but a boot should not fail. But this is only true if we can keep to ourselfs and only do bugfixes to stable releases. With a development version of DL I would not advice to do remote update - too much can happen here. > - Add another boot-line option like "DL_remote" that would indicate > never to require console input. This could be used to skip the upgrade > prompt entirely, or just change the default answer. Why not just create a special file on the configuration media to signal that we should boot without user interaction after the upgrade? > - Add and option to upgrade-config that takes default choices if no > answer in n seconds, and leave the pre_init stuff alone. See above. > pre_init could > detect the new "DL_remote" flag and call upgrade-config with the right > options. The user could ssh in to accept and save the new config, or > reject it and run the upgrade script again. Bruce, can one run upgrade-config in the running system or will this break horribly for sure. One problem would be that we should eg. stop all running services but not sshd automatically in this case, right? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Tim T. <t....@co...> - 2004-05-26 22:38:29
|
Friedrich Lobenstock wrote: > Tim Tait wrote on 26.05.2004 19:22 MET: > >> >> While making some fixes to mount_cdrom for live update (due to issues >> with read-only mounts of disk device) it occured to me there was >> another issue - after reboot to a new version, pre_init will invoke >> for the upgrade-config script where the user will be required to >> provide input on the console. If the user is in fact at a remote >> location, the box is now hung. > > > It times out in 5 minutes in this case. See around line 87 in > pre_init. In CVS this file is build/scripts/script/pre_init. > > When I look at this a second time I think we should change the if > condition. In case of a timeout the returned character is the empty > character so the upgrade is done. Then a confirmation asks to use this > config and times out after 5 minutes and then the old configuration is > restored and another confirmation times out in 5 minutes. So we are > finally at 15 minutes till such system boots after remote upgrade > without local input. > > Therefore I think in case of a timeout in the upgrade confirmation we > should rather not upgrade at all but start the system after a shortend > timeout of lets say 2 minutes. But I think within the upgrade-config script itself there are infinte waits for user input.... so that would need to be changed to allow the option of defaults with timeout so allow an unattended upgrade to happen. And if we fix the default to "no upgrade" then we may not boot at all... > >> Q: It looks like upgrade-config needs some post-processing to >> actually upgrade the real config? >> >> A few alternatives occurred to me - >> >> - Make the choice to run upgrade-config default to "no", and let user >> ssh in later to run it. Can we setup all interactive logins to check >> for mismatch and prompt/run the upgrade script there? In some >> situation, the boot might not be succesfull unless the config is >> upgraded. > > > If you keep your update within the series, eg. update from 1.x.y to > 1.x.z then the config files should not have changed. You might miss > one or the other update to a start script but a boot should not fail. > > But this is only true if we can keep to ourselfs and only do bugfixes > to stable releases. With a development version of DL I would not > advice to do remote update - too much can happen here. > > > >> - Add another boot-line option like "DL_remote" that would indicate >> never to require console input. This could be used to skip the >> upgrade prompt entirely, or just change the default answer. > > > Why not just create a special file on the configuration media to > signal that we should boot without user interaction after the upgrade? Yes that could work also. > > >> - Add and option to upgrade-config that takes default choices if no >> answer in n seconds, and leave the pre_init stuff alone. > > > See above. > >> pre_init could detect the new "DL_remote" flag and call >> upgrade-config with the right options. The user could ssh in to >> accept and save the new config, or reject it and run the upgrade >> script again. > > > Bruce, can one run upgrade-config in the running system or will this > break horribly for sure. One problem would be that we should eg. stop > all running services but not sshd automatically in this case, right? Well the upgrade-config script makes it's changes in a parallel directory, so that much is safe. So I was thinking let it auto-upgrade and take the defaults, switch configs, and finish the boot. We should be able to boot far enough to get ssh working at least. Since the new config has not been saved yet, no permanent harm done. Now the user can ssh in and review them. If they are not to their exact liking then they can run upgrade-config again with the right input, and make a new-etc tree. Save that as etc.tar.bz2 (do the paths need to be munged?) over the old one, and reboot. Voila! Trick is to try to garantee the 1st boot has a high likelyhood of success. Tim |
|
From: Friedrich L. <fl...@fl...> - 2004-05-26 23:11:14
|
Tim Tait wrote on 27.05.2004 00:38 MET:
> Friedrich Lobenstock wrote:
>
>> Tim Tait wrote on 26.05.2004 19:22 MET:
>>
>>>
>>> While making some fixes to mount_cdrom for live update (due to issues
>>> with read-only mounts of disk device) it occured to me there was
>>> another issue - after reboot to a new version, pre_init will invoke
>>> for the upgrade-config script where the user will be required to
>>> provide input on the console. If the user is in fact at a remote
>>> location, the box is now hung.
>>
>>
>>
>> It times out in 5 minutes in this case. See around line 87 in
>> pre_init. In CVS this file is build/scripts/script/pre_init.
>>
>> When I look at this a second time I think we should change the if
>> condition. In case of a timeout the returned character is the empty
>> character so the upgrade is done. Then a confirmation asks to use this
>> config and times out after 5 minutes and then the old configuration is
>> restored and another confirmation times out in 5 minutes. So we are
>> finally at 15 minutes till such system boots after remote upgrade
>> without local input.
>>
>> Therefore I think in case of a timeout in the upgrade confirmation we
>> should rather not upgrade at all but start the system after a shortend
>> timeout of lets say 2 minutes.
>
>
> But I think within the upgrade-config script itself there are infinte
> waits for user input....
Ok, but that would be "fixed" if the first timeout would not start
upgrade-config at all if a timeout happens.
> so that would need to be changed to allow the
> option of defaults with timeout so allow an unattended upgrade to
> happen. And if we fix the default to "no upgrade" then we may not boot
> at all...
With the stable series this should be no problem. But you might want to test in
a testsystem beforehand anyways ;-)
>>> Q: It looks like upgrade-config needs some post-processing to
>>> actually upgrade the real config?
>>>
>>> A few alternatives occurred to me -
>>>
>>> - Make the choice to run upgrade-config default to "no", and let user
>>> ssh in later to run it. Can we setup all interactive logins to check
>>> for mismatch and prompt/run the upgrade script there? In some
>>> situation, the boot might not be succesfull unless the config is
>>> upgraded.
>>
>>
>>
>> If you keep your update within the series, eg. update from 1.x.y to
>> 1.x.z then the config files should not have changed. You might miss
>> one or the other update to a start script but a boot should not fail.
>>
>> But this is only true if we can keep to ourselfs and only do bugfixes
>> to stable releases. With a development version of DL I would not
>> advice to do remote update - too much can happen here.
>>
>>
>>
>>> - Add another boot-line option like "DL_remote" that would indicate
>>> never to require console input. This could be used to skip the
>>> upgrade prompt entirely, or just change the default answer.
>>
>>
>>
>> Why not just create a special file on the configuration media to
>> signal that we should boot without user interaction after the upgrade?
>
>
> Yes that could work also.
>
>>
>>
>>> - Add and option to upgrade-config that takes default choices if no
>>> answer in n seconds, and leave the pre_init stuff alone.
>>
>>
>>
>> See above.
>>
>>> pre_init could detect the new "DL_remote" flag and call
>>> upgrade-config with the right options. The user could ssh in to
>>> accept and save the new config, or reject it and run the upgrade
>>> script again.
>>
>>
>>
>> Bruce, can one run upgrade-config in the running system or will this
>> break horribly for sure. One problem would be that we should eg. stop
>> all running services but not sshd automatically in this case, right?
>
>
> Well the upgrade-config script makes it's changes in a parallel
> directory, so that much is safe. So I was thinking let it auto-upgrade
> and take the defaults, switch configs, and finish the boot. We should be
> able to boot far enough to get ssh working at least.
IMO I think this is far more dangerous than booting with the old config.
> Since the new
> config has not been saved yet, no permanent harm done. Now the user can
> ssh in and review them. If they are not to their exact liking then they
> can run upgrade-config again with the right input, and make a new-etc
> tree. Save that as etc.tar.bz2 (do the paths need to be munged?) over
> the old one, and reboot. Voila! Trick is to try to garantee the 1st boot
> has a high likelyhood of success.
Hmmmm.....maybe in case of autoupdate we should start a process in the
background that does nothing than the following:
sleep 10min
<restore prev. version of DL and remove disable new one>
reboot -n -f
This way you'd at least end up with the not updated system back to live if
everything else fails. Of course we'd then need to add some kind of warning to
the admins login to not forget to kill this process ;-)
Anyway those files that could not be upgrade by an auto-upgrade, eg. because
they where changed manually, need to be updated manually anyway.
--
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock Linux Services Lobenstock
URL: http://www.lsl.at/ Email: fl...@fl...
____________________________________________________________________
|
|
From: Heiko Z. <he...@zu...> - 2004-05-26 23:31:29
|
Friedrich Lobenstock wrote: > Tim Tait wrote on 27.05.2004 00:38 MET: >> Since the new config has not been saved yet, no permanent harm done. >> Now the user can ssh in and review them. If they are not to their >> exact liking then they can run upgrade-config again with the right >> input, and make a new-etc tree. Save that as etc.tar.bz2 (do the >> paths need to be munged?) over the old one, and reboot. Voila! Trick >> is to try to garantee the 1st boot has a high likelyhood of success. > > > Hmmmm.....maybe in case of autoupdate we should start a process in the > background that does nothing than the following: > sleep 10min > <restore prev. version of DL and remove disable new one> > reboot -n -f > > This way you'd at least end up with the not updated system back to live > if everything else fails. Of course we'd then need to add some kind of > warning to the admins login to not forget to kill this process ;-) This is a very good idea ! > Anyway those files that could not be upgrade by an auto-upgrade, eg. > because they where changed manually, need to be updated manually anyway. > True Heiko |
|
From: Tim T. <t....@co...> - 2004-05-27 02:58:10
|
Heiko Zuerker wrote: > Friedrich Lobenstock wrote: > >> Tim Tait wrote on 27.05.2004 00:38 MET: >> >>> Since the new config has not been saved yet, no permanent harm done. >>> Now the user can ssh in and review them. If they are not to their >>> exact liking then they can run upgrade-config again with the right >>> input, and make a new-etc tree. Save that as etc.tar.bz2 (do the >>> paths need to be munged?) over the old one, and reboot. Voila! Trick >>> is to try to garantee the 1st boot has a high likelyhood of success. >> >> >> >> Hmmmm.....maybe in case of autoupdate we should start a process in >> the background that does nothing than the following: >> sleep 10min >> <restore prev. version of DL and remove disable new one> >> reboot -n -f >> >> This way you'd at least end up with the not updated system back to >> live if everything else fails. Of course we'd then need to add some >> kind of warning to the admins login to not forget to kill this >> process ;-) > > > This is a very good idea ! > I agree a fail-safe restore to old version mechanism would be nice... but I still say you have to force an auto-update or you run a high risk of not being to update remotely in the future, in which case why even bother supporting it. When major versions are released, just how far can one expect a boot to go on an old config? Did dl 1.0 work with an unmodified dl 0.5 config? Will 1.2 work woth an unmodified 1.06 config? Will we always require it to going forward? This fail-safe would also by default restore the old config, because nobody would have run a save-config yet. The watchdog script could wait for an event to terminate - like the etc.tar.bz2 file being updated or something. > >> Anyway those files that could not be upgrade by an auto-upgrade, eg. >> because they where changed manually, need to be updated manually anyway. >> > > True And they still can be, but only if the user can ssh in at which point he can check the upgrade results, which aren't saved yet so not harmful. Running the upgrade-config script itself later is harmless because all changes are made to a copy, you have to pu it into /etc to apply it. > > Heiko Tim |
|
From: Heiko Z. <he...@zu...> - 2004-05-26 23:16:22
|
Tim Tait wrote: > Friedrich Lobenstock wrote: > >> Tim Tait wrote on 26.05.2004 19:22 MET: >> >>> >>> While making some fixes to mount_cdrom for live update (due to issues >>> with read-only mounts of disk device) it occured to me there was >>> another issue - after reboot to a new version, pre_init will invoke >>> for the upgrade-config script where the user will be required to >>> provide input on the console. If the user is in fact at a remote >>> location, the box is now hung. >> >> >> >> It times out in 5 minutes in this case. See around line 87 in >> pre_init. In CVS this file is build/scripts/script/pre_init. >> >> When I look at this a second time I think we should change the if >> condition. In case of a timeout the returned character is the empty >> character so the upgrade is done. Then a confirmation asks to use this >> config and times out after 5 minutes and then the old configuration is >> restored and another confirmation times out in 5 minutes. So we are >> finally at 15 minutes till such system boots after remote upgrade >> without local input. >> >> Therefore I think in case of a timeout in the upgrade confirmation we >> should rather not upgrade at all but start the system after a shortend >> timeout of lets say 2 minutes. > > > But I think within the upgrade-config script itself there are infinte > waits for user input.... so that would need to be changed to allow the > option of defaults with timeout so allow an unattended upgrade to > happen. And if we fix the default to "no upgrade" then we may not boot > at all... > >> >>> Q: It looks like upgrade-config needs some post-processing to >>> actually upgrade the real config? >>> >>> A few alternatives occurred to me - >>> >>> - Make the choice to run upgrade-config default to "no", and let user >>> ssh in later to run it. Can we setup all interactive logins to check >>> for mismatch and prompt/run the upgrade script there? In some >>> situation, the boot might not be succesfull unless the config is >>> upgraded. >> >> >> >> If you keep your update within the series, eg. update from 1.x.y to >> 1.x.z then the config files should not have changed. You might miss >> one or the other update to a start script but a boot should not fail. >> >> But this is only true if we can keep to ourselfs and only do bugfixes >> to stable releases. With a development version of DL I would not >> advice to do remote update - too much can happen here. >> >> >> >>> - Add another boot-line option like "DL_remote" that would indicate >>> never to require console input. This could be used to skip the >>> upgrade prompt entirely, or just change the default answer. >> >> >> >> Why not just create a special file on the configuration media to >> signal that we should boot without user interaction after the upgrade? > > > Yes that could work also. > >> >> >>> - Add and option to upgrade-config that takes default choices if no >>> answer in n seconds, and leave the pre_init stuff alone. >> >> >> >> See above. >> >>> pre_init could detect the new "DL_remote" flag and call >>> upgrade-config with the right options. The user could ssh in to >>> accept and save the new config, or reject it and run the upgrade >>> script again. >> >> >> >> Bruce, can one run upgrade-config in the running system or will this >> break horribly for sure. One problem would be that we should eg. stop >> all running services but not sshd automatically in this case, right? > > > Well the upgrade-config script makes it's changes in a parallel > directory, so that much is safe. So I was thinking let it auto-upgrade > and take the defaults, switch configs, and finish the boot. We should be > able to boot far enough to get ssh working at least. Since the new > config has not been saved yet, no permanent harm done. Now the user can > ssh in and review them. If they are not to their exact liking then they > can run upgrade-config again with the right input, and make a new-etc > tree. Save that as etc.tar.bz2 (do the paths need to be munged?) over > the old one, and reboot. Voila! Trick is to try to garantee the 1st boot > has a high likelyhood of success. This was my thought too. Heiko |
