From: "Steven Levine" <ecs-isp@2rosenthals.com>
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk12062016; d=earthlink.net;
  b=kO1oC3Sokpwj77jx9RyfoXyXtjvfPA2wQ8xTJXR7LZkcO+l0KkLzpOxlXYy0hnLMRF+2pXHwT+UljgZJnSPUA5YvHAXuPjrxmA67DGMxatl3ahu1AYWS4luxady/sZe8PdkKrY4Kpss0mOjD6mTjT+mOsgLcJM2hfrshnEubeEoh9muNA7BK1Q7YYTkpGE3uQmtnu8hPv70ZhCnjvGotl2DktSF2I59LU9aFssdag4KzOSx9dTxEmBNvM3/dWq43RKoFNCioMpv4UALII1c3JLDR3CPRGZ7ZXDuXol3u4imLMCC4H5ZMyX/kswpfuB4Ef9U3Gs1t3OCQvjU17G77pA==;
  h=Received:From:Date:To:In-Reply-To:Subject:X-Mailer:Message-ID:X-ELNK-Trace:X-Originating-IP;
Date: Mon, 29 Mar 2021 20:55:51 -0700
To: "eCS ISP Mailing List" <ecs-isp@2rosenthals.com>
In-Reply-To: <list-1770503@2rosenthals.com>
Subject: Re: [eCS-ISP] links in the ticket
Message-ID: <E1lR6i0-000BOj-Am@elasmtp-mealy.atl.sa.earthlink.net>

In <list-1770503@2rosenthals.com>, on 03/29/21
   at 11:33 PM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said:

Hi,

>Who is to say that the configuration files were not the cause of the 
>failure(s) in the first place?

If this is a possibility, the user should be told how to check if this is
the case, assuming we already know how to do this check.

Also, while any failure mode is possible, this is not one that I recall
seeing, probably because the configuration files are mostly static.  I
don't include the rpm database here because it is not static and there is
a small window of time where it is at risk when an update is being
applied.  Also, we already have tools that can attempt to repair the rpm
datebase when the symptoms point to it as a problem.

>Also, only deleting executable files not in the bootstrap could lead to 
>inconsistencies between the rpm db and the installed system. IOW, if we
>are  replacing the existing rpm db with the one from the bootstrap, then
>more  than executables should be removed;

I think if you testcase the process, you will find that the files that my
method would not delete are mostly application specific user files and are
not going to affect whether or not the Package Manager runs correctly.

The way I look at it is that these files are there for a reason.  While
reinstalling the bootstrap might not replace them immediately, they will
be replaced, often with he same identical file as the user installs the
packages the the bootstrap reinstall implicitly deleted.

To say it another way, my POV is that the goal of reinstalling the
bootstrap is to put the Package Manager back into a working state while
minimizing the number of files that get deleted which might contain user
specific data.  Any leftover cruft can and will be taken care of as the
packages "lost" by the bootstrap reinstall are reinstalled.

>however, if we are keeping the
>installed  db,

I never considered doing this.  It's a bad idea.  The bootstrap db will
become the working db.  There may be extra files left in the directories
managed by the Package Manager after the unzip, but the chances of these
files causing the Package Manager to fail is minimal  If it turns out
there are exceptions, then they can be added to a must delete list.

The question that needs to be answered is if I unzip the bootstrap onto an
arbitrary working or broken Package Manager setup and overwrite any
conflicting files with the files from the bootstrap zip, do I get a
working Package Manager.  If I do, then I have accomplished my goal.
Bringing everything else back to the state it was before the bootstrap
reinstall was required will be normal Package Manager operations.

>Well, of those, only yum.log is part of the bootstrap itself. The other 
>files are not touched.

Then they can stay as long as the prior troubleshooting steps have
verified that they are not the cause of the problem to be solved.

>See tickets 3112 and 1929.

:-)

>Thinking about this.

>The troubleshooting wiki essentially lists symptoms and solutions. 
>Re-bootstrapping isn't a symptom but an operation.

True.  The sypmtom is, as you say, every other recovery solution failed.

>There are numerous greps around, some pre-klibc (you may recall that our
>one  enterprise client had a really, really old one in use), and some
>more  functional than others.

Sure, it could be anything, but whatever grep he installed, he installed
only partially.  An normal install of the grep package will result in a
working grep because everything it needs will be installed.

>Good.

One of my goals in working the stunnel issue with Massimo was to make the
idebug-small package as user-proof as possible.  Roderick and I had
already used an early version of the package to track down a couple of
application failures, but Roderick does not need to be spoon-fed when
doing this kind of stuff.  He recognizes and error message when he sees
one.

>Done, for the page title, however, note that the breadcrumbs now read:
>Wikis > Package Manager > Package Manager Troubleshooting

I was wondering if you would be forced to do that way or there was way to
override the default bread crumb text.  I suspect most folks will not even
notice the somewhat redundant text.

Having thought about the bootstrap reinstall issue some more, the curent
processing sequence I envision is:

 - Verify that the user has shut down any non-essential
   applications.
 - Confirm that the user is really really sure he/she
   wants to do this.
 - Use psfiles to capture a list of open files in the directories
   managed by the Package Manager.
 - Unlock the files.
 - Alert the user if one or more files cannot be unlocked.
   These will be data files.
   Exactly how to handle them is TBD.
   It really depends on the specific locked file.
 - Save any files we decide need to be saved.
   yum.log -> yum.log-orig etc.
 - Download the bootstrap.
 - Unzip the bootstrap overwriting any existing files.
 - Reboot.

This should result in working Package Manager.

If we want to be really nice, we could offer to convert the saved yum.log
into a list of packages the need to be installed because they were
logically uninstalled during the bootstrap reinstall.  The normal ANPM
update process will take care of the packages known to the bootstrap.
 
Steven

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53@earthlink.net>  Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------