Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #222750 > unrolled thread

Return a Debian system to a pristine state

Back to article view | Back to linux.debian.user

Contents

  Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-27 10:50 +0200
    Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-05-27 15:50 +0200
      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:20 +0200
        Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 13:50 +0200
          Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-05-28 14:10 +0200
            Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 15:00 +0200
              Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-05-28 15:10 +0200
            Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:20 +0200
          Re: Return a Debian system to a pristine state Kenneth Parker <sea7kenp@gmail.com> - 2020-05-28 14:50 +0200
          Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:00 +0200
            Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 16:10 +0200
              Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:40 +0200
                Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-28 16:50 +0200
                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 17:20 +0200
                Re: Return a Debian system to a pristine state John Hasler <jhasler@newsguy.com> - 2020-05-28 18:00 +0200
                  Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-29 09:50 +0200
                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 16:40 +0200
                    Re: Return a Debian system to a pristine state Miles Fidelman <mfidelman@meetinghouse.net> - 2020-05-29 16:50 +0200
                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 17:20 +0200
                    Re: Return a Debian system to a pristine state John Hasler <jhasler@newsguy.com> - 2020-05-29 17:40 +0200
                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-30 06:00 +0200
                        Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-30 07:10 +0200
                          Re: Return a Debian system to a pristine state Tixy <tixy@yxit.co.uk> - 2020-05-30 11:30 +0200
                            Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-30 14:40 +0200
                              Re: Return a Debian system to a pristine state Tixy <tixy@yxit.co.uk> - 2020-05-30 19:40 +0200
                Re: Return a Debian system to a pristine state Miles Fidelman <mfidelman@meetinghouse.net> - 2020-05-28 18:00 +0200
            Re: Return a Debian system to a pristine state <tomas@tuxteam.de> - 2020-05-28 16:40 +0200
            Re: Return a Debian system to a pristine state Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2020-05-28 17:10 +0200
            Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-05-28 17:10 +0200
              Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-29 17:00 +0200
                Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-05-29 21:50 +0200
                  Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-05-29 22:30 +0200
                    Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-05-30 05:10 +0200
                      Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-05-30 20:00 +0200
                        Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-01 08:10 +0200
                          Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-01 12:30 +0200
                            Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-01 20:00 +0200
                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-31 11:30 +0200
                    Re: Return a Debian system to a pristine state Joe <joe@jretrading.com> - 2020-05-31 13:40 +0200
                      Re: Return a Debian system to a pristine state rhkramer@gmail.com - 2020-05-31 14:40 +0200
                        Re: Return a Debian system to a pristine state l0f4r0@tuta.io - 2020-05-31 15:00 +0200
                        Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-05-31 15:00 +0200
                        Re: Return a Debian system to a pristine state Michael Howard <mike@dewberryfields.co.uk> - 2020-05-31 15:10 +0200
                          Re: Return a Debian system to a pristine state "Thomas Schmitt" <scdbackup@gmx.net> - 2020-05-31 17:00 +0200
                            Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-05-31 17:40 +0200
                              Re: Return a Debian system to a pristine state "Thomas Schmitt" <scdbackup@gmx.net> - 2020-05-31 21:00 +0200
                            Re: Return a Debian system to a pristine state Michael Howard <mike@dewberryfields.co.uk> - 2020-05-31 19:50 +0200
                              Re: Return a Debian system to a pristine state rhkramer@gmail.com - 2020-05-31 22:00 +0200
                                Re: Return a Debian system to a pristine state Michael Howard <mike@dewberryfields.co.uk> - 2020-05-31 23:40 +0200
                              Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-04 16:40 +0200
                                Re: Return a Debian system to a pristine state John Hasler <jhasler@newsguy.com> - 2020-06-04 22:50 +0200
                                  Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-06-05 17:40 +0200
                                    Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-06-05 18:10 +0200
                                      Re: Return a Debian system to a pristine state Brian <ad44@cityscape.co.uk> - 2020-06-06 12:30 +0200
                                        Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-06-06 13:00 +0200
                                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-06-07 14:00 +0200
                                Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-06 11:30 +0200
                                  Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-08 21:40 +0200
                                    Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-09 08:10 +0200
                                      Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-07-02 03:10 +0200
                    Re: Return a Debian system to a pristine state Tom Dial <tddial@comcast.net> - 2020-06-01 05:10 +0200
                      Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-01 08:30 +0200
                        Re: Return a Debian system to a pristine state Tom Dial <tddial@comcast.net> - 2020-06-02 00:40 +0200
                      Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-01 11:50 +0200
                        Re: Return a Debian system to a pristine state "Sijmen J. Mulder" <ik@sjmulder.nl> - 2020-06-04 10:50 +0200
                          Re: Return a Debian system to a pristine state Tom Dial <tddial@comcast.net> - 2020-06-04 21:20 +0200
                      Re: Return a Debian system to a pristine state songbird <songbird@anthive.com> - 2020-06-01 13:30 +0200
                    Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-01 20:30 +0200
                      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-06-02 06:10 +0200
                        Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-02 07:30 +0200
                        Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-06-02 14:40 +0200
                        Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-02 17:10 +0200
                      Re: Override default post-install starting of services [was Return  a Debian system to a pristine state] davidson <davidson@freevolt.org> - 2020-07-05 22:20 +0200
                        Re: Override default post-install starting of services [was Return a  Debian system to a pristine state] David Wright <deblis@lionunicorn.co.uk> - 2020-07-05 23:40 +0200
        Re: Return a Debian system to a pristine state Dan Ritter <dsr@randomstring.org> - 2020-05-28 14:10 +0200
        Re: Return a Debian system to a pristine state Miles Fidelman <mfidelman@meetinghouse.net> - 2020-05-28 16:40 +0200
          Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 16:50 +0200
    Re: Return a Debian system to a pristine state songbird <songbird@anthive.com> - 2020-05-27 16:10 +0200
      Re: Return a Debian system to a pristine state Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-27 16:30 +0200
        Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:40 +0200
          Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-28 08:10 +0200
      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:30 +0200
    Re: Return a Debian system to a pristine state Charles Curley <charlescurley@charlescurley.com> - 2020-05-27 20:10 +0200
      Re: Return a Debian system to a pristine state Victor Sudakov <vas@sibptus.ru> - 2020-05-28 07:40 +0200
    Re: Return a Debian system to a pristine state "Sijmen J. Mulder" <ik@sjmulder.nl> - 2020-05-28 11:20 +0200
      Re: Return a Debian system to a pristine state <tomas@tuxteam.de> - 2020-05-28 11:30 +0200
    Re: Return a Debian system to a pristine state emetib <chadbrabec@gmail.com> - 2020-06-01 05:10 +0200
      Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-01 12:20 +0200
        Re: Return a Debian system to a pristine state songbird <songbird@anthive.com> - 2020-06-01 13:30 +0200
        Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-04 16:40 +0200
          Re: Return a Debian system to a pristine state The Wanderer <wanderer@fastmail.fm> - 2020-06-04 21:50 +0200
            Re: Return a Debian system to a pristine state Marco Möller <talby@debianlists.mobilxpress.net> - 2020-06-05 13:10 +0200
              Re: Return a Debian system to a pristine state Andrei POPESCU <andreimpopescu@gmail.com> - 2020-06-06 11:40 +0200
                Re: Return a Debian system to a pristine state David Wright <deblis@lionunicorn.co.uk> - 2020-06-08 21:40 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#222955

On 5/31/20 03:28, Victor Sudakov wrote:
> David Wright wrote:
>> On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
>>> David Wright wrote:
>>>> Finally,   pkg delete -a   sounds like something from the abattoir,
>>>> rather than anything you'd do to a pet (to use your analogy).
>>>
>>> It's not as terrible as it sounds ;-) It's more from a vet clinic than
>>> from a slaughterhouse. You don't lose configs, you don't lose network
>>> connectivity or remote access during this procedure. You can save a list
>>> of installed packages before deleting them, and reinstall only those you
>>> know you need.
>>>
>>> Unfortunately, the FreeBSD package system is not as mature as DEB or
>>> RPM, therefore until very recently the "pkg delete -a" procedure has
>>> been required to get rid of the dependencey hell.
>>
>> OK, that sounds more like what people do on Windows systems, where
>> there's a reset option, except that on Windows you can, ISTR, lose
>> all your own files if they're under C:.
> 
> Since what version does Windows have a reset option? For dozens of
> years, literally, Windows has been notorious for leftovers of removed
> programs remaining in the "base system" and causing unexpected effects.
> There were even commercial products on the market to purge those leftovers.
> 
> FreeBSD is different in this respect. No part of third-party software
> ever gets into the base system (unless you install something manually
> and incorrectly). And of course you don't lose any user data if you run 
> "pkg delete -a"
> 
>>
>> Debian doesn't work that way: you can remove packages from the system
>> at will in a controlled manner. Isn't that what sysadmins do?
> 
> Well, I was not feeling particulary sysadmin-ish about the desktop
> system I wanted to cleanup.
> 
>>
>>>> "apt has a bug, cannot believe it!"
>>>> https://lists.debian.org/debian-user/2020/05/msg00567.html
>>>
>>> Well, I must admit, I can sympathize with this person's frustration. He
>>> just got confused among those AutoRemove* advanced options. 
>>
>> I think it's much more than that. The OP appeared to regard the
>> --no-install-recommends option as a *property* that is applied to each
>> package installed under that recommendation regime, and that
>> that property would be preserved for all time. But as the "-install-"
>> in --no-install-recommends shows, it's just an option for the install
>> command itself.
> 
> Dare I say that one needs knowledge beyond a regular user to understand
> these subtleties? 
> 
>>
>>> I, too, was surprised by some Debian features like its tendency to start
>>> daemons with a vanilla configuration right after installation. Still
>>> can't say I like this decision.
>>
>> This has been discussed in the past. Using the term "vanilla" suggests
>> that an ordinary upstream configuration is applied to the daemon,
>> which is not true: the Debian developers apply what they consider are
>> sensible secure defaults, designed to integrate with the distribution.
>> This work is usually documented in changelog.Debian.gz or various
>> READMEs.
> 
> Is the /usr/sbin/policy-rc.d method still the official supported one of
> disabling this behavior when it is not desirable?
> 

In the fairly large number of posts in this thread I don't recall seeing
file system snapshots suggested. My current preference is ZFS, which I
know from experience to be up to what I understand to be the goal here.

However, root on ZFS is a distinctly non-standard and hands on install
that is fairly straightforward and decently documented, but not for
everyone. Moreover, ZFS is not DFSG and GPL compliant, and quite a few
users would avoid it because of that.

Alternatives include LVM and btrfs, and possibly others. I have used LVM
snapshots a little, but not for this use case. It appears to have the
capability to accomplish the objective, as described in

https://linuxconfig.org/create-and-restore-manual-logical-volume-snapshots

for instance.

I have not used btrfs and therefore have no opinion about its fitness
for the case at hand.

Regards,
Tom Dial

[toc] | [prev] | [next] | [standalone]

#222958

[Multipart message — attachments visible in raw view] — view raw

On Du, 31 mai 20, 20:52:06, Tom Dial wrote:
> 
> Moreover, ZFS is not DFSG and GPL compliant, and quite a few
> users would avoid it because of that.

ZFS is licensed under the CDDL[1], which is both free (as in freedom) 
and DFGS *compliant*.

It is also *incompatible* with the GPL, which means distributing a Linux 
kernel (GPL) including the ZFS modules is possibly illegal[2].

End users however are well within their rights (freedom 0 and 1)[3] to 
use this combination, as long as they don't share it with anyone else 
(freedoms 3 and 4)[3].

[1] https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License
[2] As far as I know this was never tested in court
[3] https://en.wikipedia.org/wiki/The_Free_Software_Definition

Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#222989

On 6/1/20 00:28, Andrei POPESCU wrote:
>On Du, 31 mai 20, 20:52:06, Tom Dial wrote:
>>
>> Moreover, ZFS is not DFSG and GPL compliant, and quite a few
>> users would avoid it because of that.
>
>ZFS is licensed under the CDDL[1], which is both free (as in freedom)
>and DFGS *compliant*.
>
>It is also *incompatible* with the GPL, which means distributing a Linux
>kernel (GPL) including the ZFS modules is possibly illegal[2].

I knew this, but overlooked that the relevant packages are in contrib,
presumably indicating their DFSG compliance.

Thank you for the correction.

TDD

>
>End users however are well within their rights (freedom 0 and 1)[3] to
>use this combination, as long as they don't share it with anyone else
>(freedoms 3 and 4)[3].
>
>[1]
https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License
>[2] As far as I know this was never tested in court
>[3] https://en.wikipedia.org/wiki/The_Free_Software_Definition
>
>Hope this explains,
>Andrei
>--
>http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#222963

On 01.06.20 04:52, Tom Dial wrote:
> 
> 
> On 5/31/20 03:28, Victor Sudakov wrote:
>> David Wright wrote:
>>> On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
>>>> David Wright wrote:
>>>>> Finally,   pkg delete -a   sounds like something from the abattoir,
>>>>> rather than anything you'd do to a pet (to use your analogy).
>>>>
>>>> It's not as terrible as it sounds ;-) It's more from a vet clinic than
>>>> from a slaughterhouse. You don't lose configs, you don't lose network
>>>> connectivity or remote access during this procedure. You can save a list
>>>> of installed packages before deleting them, and reinstall only those you
>>>> know you need.
>>>>
>>>> Unfortunately, the FreeBSD package system is not as mature as DEB or
>>>> RPM, therefore until very recently the "pkg delete -a" procedure has
>>>> been required to get rid of the dependencey hell.
>>>
>>> OK, that sounds more like what people do on Windows systems, where
>>> there's a reset option, except that on Windows you can, ISTR, lose
>>> all your own files if they're under C:.
>>
>> Since what version does Windows have a reset option? For dozens of
>> years, literally, Windows has been notorious for leftovers of removed
>> programs remaining in the "base system" and causing unexpected effects.
>> There were even commercial products on the market to purge those leftovers.
>>
>> FreeBSD is different in this respect. No part of third-party software
>> ever gets into the base system (unless you install something manually
>> and incorrectly). And of course you don't lose any user data if you run
>> "pkg delete -a"
>>
>>>
>>> Debian doesn't work that way: you can remove packages from the system
>>> at will in a controlled manner. Isn't that what sysadmins do?
>>
>> Well, I was not feeling particulary sysadmin-ish about the desktop
>> system I wanted to cleanup.
>>
>>>
>>>>> "apt has a bug, cannot believe it!"
>>>>> https://lists.debian.org/debian-user/2020/05/msg00567.html
>>>>
>>>> Well, I must admit, I can sympathize with this person's frustration. He
>>>> just got confused among those AutoRemove* advanced options.
>>>
>>> I think it's much more than that. The OP appeared to regard the
>>> --no-install-recommends option as a *property* that is applied to each
>>> package installed under that recommendation regime, and that
>>> that property would be preserved for all time. But as the "-install-"
>>> in --no-install-recommends shows, it's just an option for the install
>>> command itself.
>>
>> Dare I say that one needs knowledge beyond a regular user to understand
>> these subtleties?
>>
>>>
>>>> I, too, was surprised by some Debian features like its tendency to start
>>>> daemons with a vanilla configuration right after installation. Still
>>>> can't say I like this decision.
>>>
>>> This has been discussed in the past. Using the term "vanilla" suggests
>>> that an ordinary upstream configuration is applied to the daemon,
>>> which is not true: the Debian developers apply what they consider are
>>> sensible secure defaults, designed to integrate with the distribution.
>>> This work is usually documented in changelog.Debian.gz or various
>>> READMEs.
>>
>> Is the /usr/sbin/policy-rc.d method still the official supported one of
>> disabling this behavior when it is not desirable?
>>
> 
> In the fairly large number of posts in this thread I don't recall seeing
> file system snapshots suggested. My current preference is ZFS, which I
> know from experience to be up to what I understand to be the goal here.

(...)
I understand the OP to be in search for the uncomplicated removal of 
installed packages considering package installation dates.
A fs snaphot tool is likely to return to a general system state which 
would include also the return of the user data and system configurations 
to a point of time in the past, instead of only treating package 
installs. And if having to prepare sophisticated steps like requiring 
special partitioning schemes, then this wouldn't be uncomplicated anymore.

[toc] | [prev] | [next] | [standalone]

#223046

Marco Möller wrote:
> > In the fairly large number of posts in this thread I don't recall seeing
> > file system snapshots suggested. My current preference is ZFS, which I
> > know from experience to be up to what I understand to be the goal here.
> 
> (...)
> I understand the OP to be in search for the uncomplicated removal of 
> installed packages considering package installation dates.
> A fs snaphot tool is likely to return to a general system state which 
> would include also the return of the user data and system configurations 
> to a point of time in the past, instead of only treating package 
> installs. And if having to prepare sophisticated steps like requiring 
> special partitioning schemes, then this wouldn't be uncomplicated anymore.

Agreed, but at risk of going a bit off track, I didn't find this to be
a problem in practice on ZFS native systems like SmartOS. Separate
volume on /usr/pkg, snapshot, done. Of course the situation in Debian
is a bit different.

Sijmen

[toc] | [prev] | [next] | [standalone]

#223055

On 6/4/20 02:45, Sijmen J. Mulder wrote:
> Marco Möller wrote:
>>> In the fairly large number of posts in this thread I don't recall seeing
>>> file system snapshots suggested. My current preference is ZFS, which I
>>> know from experience to be up to what I understand to be the goal here.
>>
>> (...)
>> I understand the OP to be in search for the uncomplicated removal of 
>> installed packages considering package installation dates.
>> A fs snaphot tool is likely to return to a general system state which 
>> would include also the return of the user data and system configurations 
>> to a point of time in the past, instead of only treating package 
>> installs. And if having to prepare sophisticated steps like requiring 
>> special partitioning schemes, then this wouldn't be uncomplicated anymore.

Debian root on ZFS installation is non-standard (where the standard is
the Debian installer). It is more complicated than the standard install,
but instructions at

https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html

describe adequately how to do it using a Debian Live CD. I used an
earlier, slightly less polished, version for five or six installs and
found it satisfactory. It is a hands-on command line install using the
shell in a terminal, but most of the commands can be copied and pasted
from the documentation with only minor changes.

>> Agreed, but at risk of going a bit off track, I didn't find this to be
> a problem in practice on ZFS native systems like SmartOS. Separate
> volume on /usr/pkg, snapshot, done. Of course the situation in Debian
> is a bit different.
> 
> Sijmen
> 

[toc] | [prev] | [next] | [standalone]

#222967

Tom Dial wrote:
...
> In the fairly large number of posts in this thread I don't recall seeing
> file system snapshots suggested. My current preference is ZFS, which I
> know from experience to be up to what I understand to be the goal here.

  both timeshift and partclone have been mentioned.  both
can be used to do snapshots.  while i have not fully tested
either of them lately.

  i see now that there is clonezilla too.  again i've not
had cause to test any of these out, but i suspect they'd
work.


> However, root on ZFS is a distinctly non-standard and hands on install
> that is fairly straightforward and decently documented, but not for
> everyone. Moreover, ZFS is not DFSG and GPL compliant, and quite a few
> users would avoid it because of that.
>
> Alternatives include LVM and btrfs, and possibly others. I have used LVM
> snapshots a little, but not for this use case. It appears to have the
> capability to accomplish the objective, as described in
>
> https://linuxconfig.org/create-and-restore-manual-logical-volume-snapshots
>
> for instance.
>
> I have not used btrfs and therefore have no opinion about its fitness
> for the case at hand.


  songbird

[toc] | [prev] | [next] | [standalone]

#222981

On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote:
> David Wright wrote:
> > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
> > > David Wright wrote:
> > > > Finally,   pkg delete -a   sounds like something from the abattoir,
> > > > rather than anything you'd do to a pet (to use your analogy).
> > > 
> > > It's not as terrible as it sounds ;-) It's more from a vet clinic than
> > > from a slaughterhouse. You don't lose configs, you don't lose network
> > > connectivity or remote access during this procedure. You can save a list
> > > of installed packages before deleting them, and reinstall only those you
> > > know you need.
> > > 
> > > Unfortunately, the FreeBSD package system is not as mature as DEB or
> > > RPM, therefore until very recently the "pkg delete -a" procedure has
> > > been required to get rid of the dependencey hell.
> > 
> > OK, that sounds more like what people do on Windows systems, where
> > there's a reset option, except that on Windows you can, ISTR, lose
> > all your own files if they're under C:.
> 
> Since what version does Windows have a reset option?

No idea. The last version of Windows that I used was IIRC 3.11.
I parted company when W95 came with "DOS" 7 rather than a
successor to DOS 6.22.

> For dozens of
> years, literally, Windows has been notorious for leftovers of removed
> programs remaining in the "base system" and causing unexpected effects.
> There were even commercial products on the market to purge those leftovers.

You're way ahead of me on Windows, then. I just know what I've seen,
and what I saw was this:

Chapter 3. Lenovo OneKey Recovery system
  The Lenovo OneKey Recovery system is software designed to back up and
  restore your computer. You can use it to restore the system partition to its
  original status in case of a system failure. You can also create user backups
  for easy restoration as required.
   Note: To utilize the features of the OneKey Recovery system, your hard disk already
         includes a hidden partition by default to store the system image file and the OneKey
         Recovery system program files. This default partition is hidden for security reasons,
         which explains why the available disk space is less than the stated capacity.
· Backing up the system partition
  You can back up the system partition to an image file. To back up the system
  partition:
  1 Press the Novo button to start the Lenovo OneKey Recovery system.
  2 Click System Backup.
  3 Select a back-up location and click Next to start the backup.
   Notes:
   • You can choose a back-up location on the local hard disk drive or an external storage device.
   • The back-up process may take a while.
   • The back-up process is only available when Windows can be started normally.
· Restoring
  You can choose to restore the system partition to its original status or to a
  previously created back-up point. To restore the system partition:
  1 Press the Novo button to start the Lenovo OneKey Recovery system.
  2 Click System Recovery. The computer will restart to the recovery environment.
  3 Follow the on-screen instructions to restore the system partition to its
      original status or to a previously created back-up point.
   Notes:
   • The recovery process is irreversible. Make sure to back up any data you wish to save on
      the system partition before starting the recovery process.
   • The recovery process may take a while. So be sure to connect the AC power adapter to
      your computer during the recovery process.
   • The above instructions should be followed when Windows can be started normally.
  If Windows cannot be started, follow the steps below to start the Lenovo
  OneKey Recovery system:
1 Shut down the computer.
2 Press the Novo button. From Novo Button Menu, select System recovery
  and press Enter.

This laptop has three partitions coded 2700 which I presume are for
supporting this, plus a partition coded ed01 which I presume is the
code executed from the "Novo" button. I've only used this button to
switch to BIOS for linux, from EFI/Windows.

> FreeBSD is different in this respect. No part of third-party software
> ever gets into the base system (unless you install something manually
> and incorrectly).

This has already been pointed out, that Debian's installed system is
an individual outcome, not some sort of mandated selection.

> And of course you don't lose any user data if you run 
> "pkg delete -a"

I didn't know we were discussing user data at all.

> > Debian doesn't work that way: you can remove packages from the system
> > at will in a controlled manner. Isn't that what sysadmins do?
> 
> Well, I was not feeling particulary sysadmin-ish about the desktop
> system I wanted to cleanup.

How you feel about it can't alter the fact that reverting a system by
removing packages is a sysadmin-ish process: you administering the
system.

> > > > "apt has a bug, cannot believe it!"
> > > > https://lists.debian.org/debian-user/2020/05/msg00567.html
> > > 
> > > Well, I must admit, I can sympathize with this person's frustration. He
> > > just got confused among those AutoRemove* advanced options. 
> > 
> > I think it's much more than that. The OP appeared to regard the
> > --no-install-recommends option as a *property* that is applied to each
> > package installed under that recommendation regime, and that
> > that property would be preserved for all time. But as the "-install-"
> > in --no-install-recommends shows, it's just an option for the install
> > command itself.
> 
> Dare I say that one needs knowledge beyond a regular user to understand
> these subtleties? 

       --no-install-recommends
           Do not consider recommended packages as a dependency for installing.
           Configuration Item: APT::Install-Recommends.

       --install-suggests
           Consider suggested packages as a dependency for installing.
           Configuration Item: APT::Install-Suggests.

It's in the man page. Install is a verb, not an adjective being
applied to the installation. One cannot control what people will read
into it.

> > > I, too, was surprised by some Debian features like its tendency to start
> > > daemons with a vanilla configuration right after installation. Still
> > > can't say I like this decision.
> > 
> > This has been discussed in the past. Using the term "vanilla" suggests
> > that an ordinary upstream configuration is applied to the daemon,
> > which is not true: the Debian developers apply what they consider are
> > sensible secure defaults, designed to integrate with the distribution.
> > This work is usually documented in changelog.Debian.gz or various
> > READMEs.
> 
> Is the /usr/sbin/policy-rc.d method still the official supported one of
> disabling this behavior when it is not desirable?

It's many years since I ran servers in what one might call "hostile"
environments, so the current situation suits me, and I don't keep up
with discussions like those in
https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html

So others would have to comment here, after the discussion of
resetting Windows has subsided.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#222992

[Multipart message — attachments visible in raw view] — view raw

David Wright wrote:
> On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote:
> > David Wright wrote:
> > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
> > > > David Wright wrote:
> > > > > Finally,   pkg delete -a   sounds like something from the abattoir,
> > > > > rather than anything you'd do to a pet (to use your analogy).
> > > > 
> > > > It's not as terrible as it sounds ;-) It's more from a vet clinic than
> > > > from a slaughterhouse. You don't lose configs, you don't lose network
> > > > connectivity or remote access during this procedure. You can save a list
> > > > of installed packages before deleting them, and reinstall only those you
> > > > know you need.
> > > > 
> > > > Unfortunately, the FreeBSD package system is not as mature as DEB or
> > > > RPM, therefore until very recently the "pkg delete -a" procedure has
> > > > been required to get rid of the dependencey hell.
> > > 
> > > OK, that sounds more like what people do on Windows systems, where
> > > there's a reset option, except that on Windows you can, ISTR, lose
> > > all your own files if they're under C:.
> > 
> > Since what version does Windows have a reset option?
> 
> No idea. The last version of Windows that I used was IIRC 3.11.
> I parted company when W95 came with "DOS" 7 rather than a
> successor to DOS 6.22.

Ah, I thought you knew something I did not. Then no, Windows still does
not have a reset option.

> > For dozens of
> > years, literally, Windows has been notorious for leftovers of removed
> > programs remaining in the "base system" and causing unexpected effects.
> > There were even commercial products on the market to purge those leftovers.
> 
> You're way ahead of me on Windows, then. I just know what I've seen,
> and what I saw was this:
> 
> Chapter 3. Lenovo OneKey Recovery system
>   The Lenovo OneKey Recovery system is software designed to back up and
>   restore your computer. You can use it to restore the system partition to its

Such things are present in some laptops, but they are not part of
Windows per se, they are developed by equipment manufacturers. Usually
they just extract an OEM image of Windows from some recovery partition
in case a user renders his/her system unbootable, as was verbosely
quoted below.

[dd]

> 
> > FreeBSD is different in this respect. No part of third-party software
> > ever gets into the base system (unless you install something manually
> > and incorrectly).
> 
> This has already been pointed out, that Debian's installed system is
> an individual outcome, not some sort of mandated selection.
> 
> > And of course you don't lose any user data if you run 
> > "pkg delete -a"
> 
> I didn't know we were discussing user data at all.

Apparently we were. Let me quote your own words among others: 
"... ISTR, lose all your own files if they're under C:"

> 
> > > Debian doesn't work that way: you can remove packages from the system
> > > at will in a controlled manner. Isn't that what sysadmins do?
> > 
> > Well, I was not feeling particulary sysadmin-ish about the desktop
> > system I wanted to cleanup.
> 
> How you feel about it can't alter the fact that reverting a system by
> removing packages is a sysadmin-ish process: you administering the
> system.

This is more of a terminological question. Is a user installing or
removing GIMP of FireFox really administering a system? Some
administrative tasks are easy enough to be performed by users, and maybe
(just maybe) the removal of extra software should be easy enough
to be user-serviceable (i.e. not carry the risk of killing the system
itself, or require sysadmin knowledge and reading of manual pages).

[dd]

> > 
> > Is the /usr/sbin/policy-rc.d method still the official supported one of
> > disabling this behavior when it is not desirable?
> 
> It's many years since I ran servers in what one might call "hostile"
> environments, so the current situation suits me, and I don't keep up
> with discussions like those in
> https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html

It's an interesting development, I'm positively interested. Do you know
if I can somehow subscribe to see what's happening in this direction?

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

[toc] | [prev] | [next] | [standalone]

#222995

[Multipart message — attachments visible in raw view] — view raw

On Ma, 02 iun 20, 11:03:48, Victor Sudakov wrote:
> David Wright wrote:
> > 
> > It's many years since I ran servers in what one might call "hostile"
> > environments, so the current situation suits me, and I don't keep up
> > with discussions like those in
> > https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html
> 
> It's an interesting development, I'm positively interested. Do you know
> if I can somehow subscribe to see what's happening in this direction?

The Debian Package Tracker[1] supports "subscribing" to source packages, 
to receive various updates about the package (bugs, uploads, testing 
migration, etc.).

Most Debian packages have their source code on Salsa[2], which is 
Debian's Gitlab instance. Since policy-rcd-declarative is a "native" 
package, that is also the upstream source.

[1] https://tracker.debian.org
[2] https://salsa.debian.org

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#223005

Victor Sudakov wrote: 
> David Wright wrote:
> > 
> > How you feel about it can't alter the fact that reverting a system by
> > removing packages is a sysadmin-ish process: you administering the
> > system.
> 
> This is more of a terminological question. Is a user installing or
> removing GIMP of FireFox really administering a system? Some
> administrative tasks are easy enough to be performed by users, and maybe
> (just maybe) the removal of extra software should be easy enough
> to be user-serviceable (i.e. not carry the risk of killing the system
> itself, or require sysadmin knowledge and reading of manual pages).


Quoting myself:

  The essence of the UNIX philosophy is not "make small
  utilities that can be fitted together with pipes" but to
  assume that at any moment, a user might decide to be a developer
  or a sysadmin and should have the tools to do that.

  The problems of UNIX generally come from assuming either that
  users are never devs and sysadmins, or that all users are devs
  and sysadmins.


-dsr-

[toc] | [prev] | [next] | [standalone]

#223021

On Tue 02 Jun 2020 at 11:03:48 (+0700), Victor Sudakov wrote:
> David Wright wrote:
> > On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote:
> > > David Wright wrote:
> > > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
> > > > > David Wright wrote:
> > > > > > Finally,   pkg delete -a   sounds like something from the abattoir,
> > > > > > rather than anything you'd do to a pet (to use your analogy).
> > > > > 
> > > > > It's not as terrible as it sounds ;-) It's more from a vet clinic than
> > > > > from a slaughterhouse. You don't lose configs, you don't lose network
> > > > > connectivity or remote access during this procedure. You can save a list
> > > > > of installed packages before deleting them, and reinstall only those you
> > > > > know you need.
> > > > > 
> > > > > Unfortunately, the FreeBSD package system is not as mature as DEB or
> > > > > RPM, therefore until very recently the "pkg delete -a" procedure has
> > > > > been required to get rid of the dependencey hell.
> > > > 
> > > > OK, that sounds more like what people do on Windows systems, where
> > > > there's a reset option, except that on Windows you can, ISTR, lose
> > > > all your own files if they're under C:.
> > > 
> > > Since what version does Windows have a reset option?
> > 
> > No idea. The last version of Windows that I used was IIRC 3.11.
> > I parted company when W95 came with "DOS" 7 rather than a
> > successor to DOS 6.22.
> 
> Ah, I thought you knew something I did not.

No chance of that.

> Then no, Windows still does
> not have a reset option.

I don't know how you define "reset option". I was just employing those
words with their generally accepted meanings: reset means "set again",
in the sense of "restore", and option means "through choice". You
obviously have a more technical meaning in mind.

> > > For dozens of
> > > years, literally, Windows has been notorious for leftovers of removed
> > > programs remaining in the "base system" and causing unexpected effects.
> > > There were even commercial products on the market to purge those leftovers.
> > 
> > You're way ahead of me on Windows, then. I just know what I've seen,
> > and what I saw was this:
> > 
> > Chapter 3. Lenovo OneKey Recovery system
> >   The Lenovo OneKey Recovery system is software designed to back up and
> >   restore your computer. You can use it to restore the system partition to its
> 
> Such things are present in some laptops, but they are not part of
> Windows per se, they are developed by equipment manufacturers. Usually
> they just extract an OEM image of Windows from some recovery partition
> in case a user renders his/her system unbootable, as was verbosely
> quoted below.

Well, what you are asking for in your subject line concerns Debian,
so I chose to make this analogy in quoting that source:
an OS is part of a computer system,
Windows is part of the Lenovo system purchased,
Linux is part of a Debian system.
What counts as a "reset option" for Linux, as opposed to Debian?

> [dd]
> > 
> > > FreeBSD is different in this respect. No part of third-party software
> > > ever gets into the base system (unless you install something manually
> > > and incorrectly).
> > 
> > This has already been pointed out, that Debian's installed system is
> > an individual outcome, not some sort of mandated selection.
> > 
> > > And of course you don't lose any user data if you run 
> > > "pkg delete -a"
> > 
> > I didn't know we were discussing user data at all.
> 
> Apparently we were. Let me quote your own words among others: 
> "... ISTR, lose all your own files if they're under C:"

That partial quotation omits the opening words. The paragraph was:

    OK, that sounds more like what people do on Windows systems, where
    there's a reset option, except that on Windows you can, ISTR, lose
    all your own files if they're under C:."

The example of Windows was brought up in response to your mentioning
"dependency hell", something I remember well when my institution
upgraded their Windows users to W95. And with Windows, you don't
"own" C:, even though many users leave their own files there. In
Debian, you "own" /home, which is why there's no need to discuss it
here. (Whether you decide to wipe the filesystem containing /home is
up to you, of course.)

> > > > Debian doesn't work that way: you can remove packages from the system
> > > > at will in a controlled manner. Isn't that what sysadmins do?
> > > 
> > > Well, I was not feeling particulary sysadmin-ish about the desktop
> > > system I wanted to cleanup.
> > 
> > How you feel about it can't alter the fact that reverting a system by
> > removing packages is a sysadmin-ish process: you administering the
> > system.
> 
> This is more of a terminological question.

As is the definition of "pristine state" for a Debian system.

> Is a user installing or
> removing GIMP of FireFox really administering a system? Some
> administrative tasks are easy enough to be performed by users, and maybe
> (just maybe) the removal of extra software should be easy enough
> to be user-serviceable (i.e. not carry the risk of killing the system
> itself, or require sysadmin knowledge and reading of manual pages).

If you don't want to overthink it, then you could treat the
root/user prompts as distinguishing sysadmin/users.

> [dd]
> 
> > > 
> > > Is the /usr/sbin/policy-rc.d method still the official supported one of
> > > disabling this behavior when it is not desirable?
> > 
> > It's many years since I ran servers in what one might call "hostile"
> > environments, so the current situation suits me, and I don't keep up
> > with discussions like those in
> > https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html
> 
> It's an interesting development, I'm positively interested. Do you know
> if I can somehow subscribe to see what's happening in this direction?

No. List?¹

¹ This far down the post, which mainly discusses my unfortunate aside
mentioning Windows, most sensible people have already pressed D[elete],
so there may be no replies to this appeal.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224412 — Re: Override default post-install starting of services [was Return a Debian system to a pristine state]

[Multipart message — attachments visible in raw view] — view raw

On Mon, 1 Jun 2020 David Wright wrote:
> On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote:
>> David Wright wrote:
>>> On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:

[big snip]

>>>> I, too, was surprised by some Debian features like its tendency
>>>> to start daemons with a vanilla configuration right after
>>>> installation. Still can't say I like this decision.
>>>
>>> This has been discussed in the past.

Idly curious for links, in case anyone has them at hand. (Not asking
anyone to search for me, but not curious enough to search for everyone
else.)

>> [David Wright continued:]
>>> Using the term "vanilla" suggests that an ordinary upstream
>>> configuration is applied to the daemon, which is not true: the
>>> Debian developers apply what they consider are sensible secure
>>> defaults, designed to integrate with the distribution.  This work
>>> is usually documented in changelog.Debian.gz or various READMEs.
>> [Victor Sudakov asked:]
>> Is the /usr/sbin/policy-rc.d method still the official supported
>> one of disabling this behavior when it is not desirable?

I have for a while assumed that this is what

  /etc/systemd/system-preset/*.preset

files are for (on systems with systemd).

Selective excerpts from systemd.preset(5):

   NAME
    systemd.preset - Service enablement presets

   SYNOPSIS
    /etc/systemd/system-preset/*.preset
    /run/systemd/system-preset/*.preset
    /lib/systemd/system-preset/*.preset
    /etc/systemd/user-preset/*.preset
    /run/systemd/user-preset/*.preset
    /usr/lib/systemd/user-preset/*.preset

   DESCRIPTION

    Preset files may be used to encode policy which units shall be
    enabled by default and which ones shall be disabled. They are read
    by "systemctl preset" (for more information see systemctl(1)) which
    uses this information to enable or disable a unit according to
    preset policy.  "systemctl preset" is used by the post install
    scriptlets of RPM packages (or other OS package formats), to
    enable/disable specific units by default on package installation,
    enforcing distribution, spin or administrator preset policy.

    [With respect to that last bit about the post install scriptlets of
    packages, see my note at bottom.]

    This allows choosing a certain set of units to be enabled/disabled
    even before installing the actual package.

    For more information on the preset logic please have a look at the
    Presets document [at
    https://www.freedesktop.org/wiki/Software/systemd/Preset/ ].

    [...]

   PRESET FILE FORMAT

    The preset files contain a list of directives consisting of either
    the word "enable" or "disable" followed by a space and a unit name
    (possibly with shell style wildcards), separated by newlines. [...]

    [...] Files in /etc/ override files with the same name in /usr/lib/
    and /run/.
    Files in /run/ override files with the same name in /lib/.
    Packages should install their preset files in /lib/. Files in /etc/
    are reserved for the local administrator, who may use this logic to
    override the preset files installed by vendor packages. [...]

   EXAMPLES

    Example 1. Default to off

      # /lib/systemd/system-preset/99-default.preset

      disable *

    This disables all units. Due to the filename prefix "99-", it will
    be read last and hence can easily be overridden by spin or
    administrator preset policy.

    [...]

    Example 3. Administrator policy

      # /etc/systemd/system-preset/00-lennart.preset

      enable httpd.service
      enable sshd.service
      enable postfix.service
      disable *

    This enables three specific services and disables all others. This
    is useful for administrators to specifically select the units to
    enable, and disable all others. Due to the filename prefix "00-" it
    will be read early and override all other preset policy files.

> It's many years since I ran servers in what one might call "hostile"
> environments,

(Myself I claim no experience whatsoever.)

> so the current situation suits me, and I don't keep up with
> discussions like those in
> https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html
>
> So others would have to comment here, after the discussion of
> resetting Windows has subsided.

NOTE

Regarding,

   "systemctl preset" is used by the post install scriptlets of RPM
   packages (or other OS package formats), to enable/disable specific
   units by default on package installation, enforcing distribution,
   spin or administrator preset policy.

it seems we are not supposed to take that (weirdly
distro-inappropriate) language too literally:

   $ for deb in /var/cache/apt/archives/*.deb ; \
   > do dpkg-deb -I $deb preinst postinst 2>/dev/null ; \
   > done |
   > grep -i 'preset' ; \
   > if [ $? == 1 ] ; then echo SORRY BOSS ; fi
   SORRY BOSS

Nonetheless, doing like so before issuing "apt-get install privoxy"

   # echo disable privoxy.service >> /etc/systemd/system-preset/05-privoxy-test.preset

yields this installation message

   [...]
   Creating config file /etc/privoxy/config with new version
   privoxy.service is a disabled or a static unit, not starting it.

instead of this one:

   [...]
   Creating config file /etc/privoxy/config with new version
   Created symlink /etc/systemd/system/multi-user.target.wants/privoxy.service → /lib/systemd/system/privoxy.service.

So it appears to work, though any understanding of the causal chain
eludes me.

-- 
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.

[toc] | [prev] | [next] | [standalone]

#224413 — Re: Override default post-install starting of services [was Return a Debian system to a pristine state]

On Sun 05 Jul 2020 at 20:12:36 (+0000), davidson wrote:
> On Mon, 1 Jun 2020 David Wright wrote:
> > On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote:
> > > David Wright wrote:
> > > > On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
> 
> [big snip]
> 
> > > > > I, too, was surprised by some Debian features like its tendency
> > > > > to start daemons with a vanilla configuration right after
> > > > > installation. Still can't say I like this decision.
> > > > 
> > > > This has been discussed in the past.
> 
> Idly curious for links, in case anyone has them at hand. (Not asking
> anyone to search for me, but not curious enough to search for everyone
> else.)

https://lists.debian.org/debian-user/2019/09/msg00895.html
for example. The policy hasn't troubled me in the past.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#222796

Victor Sudakov wrote: 
> Dan Ritter wrote:
> > Victor Sudakov wrote: 
> > > A production system, especially a desktop system, tends to accumulate
> > > unnecessary packages. Users install software for testing, then forget
> > > about it, or it falls into disuse...
> > > 
> > > In FreeBSD, you can always run "pkg delete -a" and return to the
> > > post-install state (well, almost). This command will remove all the
> > > third-party packages added to the base system after installation
> > > (modified files under /usr/local/ will remain).
> > > 
> > > What's the procedure for Debian? 
> > 
> > There is no pristine state for Debian. 
> 
> There should be, even if this "pristine state" is but a list of packages
> at the moment of the first boot.

> The first boot experience is what can be called a pristine state. If
> something or someone saved that initial list of packages, it could be
> called "the pristine state."

That won't be consistent against other installs of the same Debian
version.

The installer looks at the hardware it can find and asks you for
selections that influence what it will install. If you answer
the questions the same way every time on a particular machine,
it will produce a consistent result. If you answer the questions
differently, or the hardware is at all different, you will get a
different result.

Hardware manufacturers often substitute "equivalent" parts, so
two identical machines from the same vendor might not actually be
identical. For example, a laptop vendor might ship a mini-PCIe add-on
card for bluetooth 4 and wifi b/g/n, but when they run out, might ship a
slightly more expensive card that does bluetooth 5 and wifi b/g/n/ac --
with a different driver required.

You might be interested in:

- chef, puppet, ansible, salt: systems that enforce package
  installation and configuration across many machines

- etckeeper: a version control system that operates
  semi-automatically on /etc

- FAI, installer pre-seed, Debian Live: methods for producing as
  consistent an installation as possible across many machines

-dsr-

[toc] | [prev] | [next] | [standalone]

#222813

Of course, the real way to return ANY system to a pristine state is to 
do a re-install from scratch.

Which, one might add, is why we have things like Ansible.

Miles Fidelman

On 5/28/20 1:15 AM, Victor Sudakov wrote:
> Dan Ritter wrote:
>> Victor Sudakov wrote:
>>> A production system, especially a desktop system, tends to accumulate
>>> unnecessary packages. Users install software for testing, then forget
>>> about it, or it falls into disuse...
>>>
>>> In FreeBSD, you can always run "pkg delete -a" and return to the
>>> post-install state (well, almost). This command will remove all the
>>> third-party packages added to the base system after installation
>>> (modified files under /usr/local/ will remain).
>>>
>>> What's the procedure for Debian?
>> There is no pristine state for Debian.
> There should be, even if this "pristine state" is but a list of packages
> at the moment of the first boot.
>
>> Choices made during
>> installation affect what the first boot experience looks like.
> The first boot experience is what can be called a pristine state. If
> something or someone saved that initial list of packages, it could be
> called "the pristine state."
>
> For the future, I'll always save the output of "dpkg -l" after the first
> boot for later comparison, but I did not expect it was not being done
> somewhere automatically already.
>
> [dd]
>
>> /var/lib/apt/lists/* has package information; if you grep for
>> Priority: required  you will find packages that *must* be
>> installed. The ranking is:
>>
>>   required > important > standard > optional > extra
> This is interesting. This job of finding "extra" packages installed
> since the first boot can probably be done by the user, but I expected
> some ready solution to exist.
>
-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

[toc] | [prev] | [next] | [standalone]

#222817

Miles Fidelman wrote:
> Of course, the real way to return ANY system to a pristine state is to do a
> re-install from scratch.
> 
> Which, one might add, is why we have things like Ansible.

Yes, it's the well-known "pet vs cattle" dilemma. I still treat *some* of
my machines as pets, and still cannot get used to treating all machines
as cattle.


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

[toc] | [prev] | [next] | [standalone]

#222755

Victor Sudakov wrote:
> Dear Colleagues,
>
> A production system, especially a desktop system, tends to accumulate
> unnecessary packages. Users install software for testing, then forget
> about it, or it falls into disuse...
>
> In FreeBSD, you can always run "pkg delete -a" and return to the
> post-install state (well, almost). This command will remove all the
> third-party packages added to the base system after installation
> (modified files under /usr/local/ will remain).
>
> What's the procedure for Debian? 

  i don't think there is any one procedure as there are so
many different requirements that people can have and the
size of the installation may be quite different.

  when someone specifies a production system to me that means
they are likely running stable and not testing or unstable.

  you can find some information about what packages and 
versions in /var/log/install and /var/log/apt if you've kept
those files.

  if as time has been long enough there may be updates from
the initial installed versions so i don't think you can always
count on downgrading to work for those.

  if you desire a specific image of a system to always be able
to boot and work then there would have to be some other way
to do that IMO.  i have not yet used timeshift as my backup
and recovery needs are not that great (instead i keep other
bootable versions available including one on a USB stick).

  there are other partition copying utilties and schemes that
can be used, but i've not had to mess with them recently enough.
a long time ago i was using partclone which did what i needed 
it to do.


  songbird

[toc] | [prev] | [next] | [standalone]

#222757

> Victor Sudakov wrote:
> > In FreeBSD, you can always run "pkg delete -a" and return to the
> > post-install state (well, almost). This command will remove all the
> > third-party packages added to the base system after installation
> > (modified files under /usr/local/ will remain).

That's because (Free|Open)BSD has a completely different approach to
how they develop their operating system.  Under their model, there
are two completely *separate* parts of the operating system: the base
system, and packages.  Packages are add-ons that are maintained by a
separate group.  They're not part of the base system.  They're installed
in /usr/local, and they're tracked separately.

In Debian, there is no such separation.  There are only "packages", and
these packages can be essential (what you'd consider part of the base
system), or frivolous, or anywhere in between.  The packaging system
doesn't *know* which packages you would consider to be keep-worthy and
which ones you would consider to be fluff.  Only you would know that.

So, if you want to put the work in to achieve this goal, you can come
up with a set of packages that *you* consider important enough to keep,
and then simply purge everything else.

When you break the system, you will get to reinstall from scratch, which
is what you should have been doing in the first place, if you really want
to "clean up" a legacy installation.

[toc] | [prev] | [next] | [standalone]

#222781

Greg Wooledge wrote:
> > Victor Sudakov wrote:
> > > In FreeBSD, you can always run "pkg delete -a" and return to the
> > > post-install state (well, almost). This command will remove all the
> > > third-party packages added to the base system after installation
> > > (modified files under /usr/local/ will remain).
> 
> That's because (Free|Open)BSD has a completely different approach to
> how they develop their operating system.  Under their model, there
> are two completely *separate* parts of the operating system: the base
> system, and packages.  Packages are add-ons that are maintained by a
> separate group.  They're not part of the base system.  They're installed
> in /usr/local, and they're tracked separately.

I know. I've been using FreeBSD for 25 years, since 1.1.5.1 probably.

> 
> In Debian, there is no such separation.  There are only "packages", and
> these packages can be essential (what you'd consider part of the base
> system), or frivolous, or anywhere in between.  The packaging system
> doesn't *know* which packages you would consider to be keep-worthy and
> which ones you would consider to be fluff.  Only you would know that.

I probably know that the packages present at the moment of the first
boot after installation are essential and keep-worthy. Can I do
something useful having this knowledge now?

> 
> So, if you want to put the work in to achieve this goal, you can come
> up with a set of packages that *you* consider important enough to keep,
> and then simply purge everything else.

So there is no software product which would suggest to me packages for
purging? Maybe even interactively?

"Package XXX was installed YYY days after the system installation, would
you like to purge it and its dependencies? (y/n)" 

That would be kinda nice.

> 
> When you break the system, you will get to reinstall from scratch, which
> is what you should have been doing in the first place, if you really want
> to "clean up" a legacy installation.

No, a reinstall from scratch is some Microsoft Windows approach, I'd
refrain from if I possibly can.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | linux.debian.user

csiph-web