syspatch ideas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

syspatch ideas

Michal Bozon-2
Hi,
the syspatch utility for now knows only three options:

 -c(heck for available plugins and list them)
 -l(ist installed patches - "id"'s only)
 -r(evert most recent patch)
.. and recently apparently also
 -R(evert all patches)

Here are two additional features that would be very useful:

1)
 -L(ist files of the recent patch)

For now, i'm doing that with:
  tar tzf /var/syspatch/"$(ls -tr /var/syspatch/ | tail -n 1)"/*.tgz

2) Notion of transactions

Often, more patches are installed at once, with the single `syspatch`
command. One might want to be able to revert all those patches at once
as well. A notion of transactions could be made by adding a notion
of transactions, but that would add more unnecessary complexity.

It can be solved simpler way, by adding the line with the list of
patches applied, e.g.

  # syspatch
  Installing patch 005_pf_src_tracking
  Get/Verify syspatch61-006_libssl.tgz 100% |*************|  2276 KB    00:04
  Installing patch 006_libssl
  Get/Verify syspatch61-007_freetyp... 100% |*************|   732 KB    00:01
  Installing patch 007_freetype
  Missing set, skipping patch 007_freetype
  Patches applied: 5,6

and by adding support for -r optional argument, which could be comma separated
patch number list.

(And this optional argument support would be also nice for the proposed -L option)


thanks for very handy feature,
Michal Bozon

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Theo de Raadt-2
>2) Notion of transactions
>
>Often, more patches are installed at once, with the single `syspatch`
>command. One might want to be able to revert all those patches at once
>as well. A notion of transactions could be made by adding a notion
>of transactions, but that would add more unnecessary complexity.
>
>It can be solved simpler way, by adding the line with the list of
>patches applied, e.g.
>
>  # syspatch
>  Installing patch 005_pf_src_tracking
>  Get/Verify syspatch61-006_libssl.tgz 100% |*************|  2276 KB    00:04
>  Installing patch 006_libssl
>  Get/Verify syspatch61-007_freetyp... 100% |*************|   732 KB    00:01
>  Installing patch 007_freetype
>  Missing set, skipping patch 007_freetype
>  Patches applied: 5,6
>
>and by adding support for -r optional argument, which could be comma separated
>patch number list.

That is incorrect.

The usage situations are no patches, or all of the patches, or a
subset and you are about to install to get more /all of them.  You
don't get to choose which you want, unless all newer ones are ripped out also.

We don't manage dependencies.

This tooling is designed to make errata handling EASY FOR US.  Otherwise,
we would not bother building this service.


Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Michal Bozon-2
On 2017-05-15 Mon 01:31, Theo de Raadt wrote:

> >2) Notion of transactions
> >
> >Often, more patches are installed at once, with the single `syspatch`
> >command. One might want to be able to revert all those patches at once
> >as well. A notion of transactions could be made by adding a notion
> >of transactions, but that would add more unnecessary complexity.
> >
> >It can be solved simpler way, by adding the line with the list of
> >patches applied, e.g.
> >
> >  # syspatch
> >  Installing patch 005_pf_src_tracking
> >  Get/Verify syspatch61-006_libssl.tgz 100% |*************|  2276 KB    00:04
> >  Installing patch 006_libssl
> >  Get/Verify syspatch61-007_freetyp... 100% |*************|   732 KB    00:01
> >  Installing patch 007_freetype
> >  Missing set, skipping patch 007_freetype
> >  Patches applied: 5,6
> >
> >and by adding support for -r optional argument, which could be comma separated
> >patch number list.
>
> That is incorrect.
>
> The usage situations are no patches, or all of the patches, or a
> subset and you are about to install to get more /all of them.  You
> don't get to choose which you want, unless all newer ones are ripped out also.
>
> We don't manage dependencies.
>
> This tooling is designed to make errata handling EASY FOR US.  Otherwise,
> we would not bother building this service.
>

Here i agree.

If not providing easy ability to revert arbitrary list of patches, what about
handle "transactions" or "syspatch sessions" or "patchsets" internally:

After successful application of patch(es), create /var/syspatch/patchset.$TIMESTAMP
with list of applied patches (line by line).

Reverting the last patchset would be reverting the patches from the last
patchset file, and removing that file.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Theo de Raadt-2
In reply to this post by Michal Bozon-2
>On 2017-05-15 Mon 01:31, Theo de Raadt wrote:
>> >2) Notion of transactions
>> >
>> >Often, more patches are installed at once, with the single `syspatch`
>> >command. One might want to be able to revert all those patches at once
>> >as well. A notion of transactions could be made by adding a notion
>> >of transactions, but that would add more unnecessary complexity.
>> >
>> >It can be solved simpler way, by adding the line with the list of
>> >patches applied, e.g.
>> >
>> >  # syspatch
>> >  Installing patch 005_pf_src_tracking
>> >  Get/Verify syspatch61-006_libssl.tgz 100% |*************|  2276 KB    00:04
>> >  Installing patch 006_libssl
>> >  Get/Verify syspatch61-007_freetyp... 100% |*************|   732 KB    00:01
>> >  Installing patch 007_freetype
>> >  Missing set, skipping patch 007_freetype
>> >  Patches applied: 5,6
>> >
>> >and by adding support for -r optional argument, which could be comma separated
>> >patch number list.
>>
>> That is incorrect.
>>
>> The usage situations are no patches, or all of the patches, or a
>> subset and you are about to install to get more /all of them.  You
>> don't get to choose which you want, unless all newer ones are ripped out also.
>>
>> We don't manage dependencies.
>>
>> This tooling is designed to make errata handling EASY FOR US.  Otherwise,
>> we would not bother building this service.
>>
>
>Here i agree.
>
>If not providing easy ability to revert arbitrary list of patches, what about
>handle "transactions" or "syspatch sessions" or "patchsets" internally:
>
>After successful application of patch(es), create /var/syspatch/patchset.$TIMESTAMP
>with list of applied patches (line by line).
>
>Reverting the last patchset would be reverting the patches from the last
>patchset file, and removing that file.

You haven't justified need.

They are either installed, or not, and existence of files and directories
already indicates the patchlevel.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Michal Bozon-2
On 2017-05-15 Mon 02:23, Theo de Raadt wrote:

> >On 2017-05-15 Mon 01:31, Theo de Raadt wrote:
> >> >2) Notion of transactions
> >> >
> >> >Often, more patches are installed at once, with the single `syspatch`
> >> >command. One might want to be able to revert all those patches at once
> >> >as well. A notion of transactions could be made by adding a notion
> >> >of transactions, but that would add more unnecessary complexity.
> >> >
> >> >It can be solved simpler way, by adding the line with the list of
> >> >patches applied, e.g.
> >> >
> >> >  # syspatch
> >> >  Installing patch 005_pf_src_tracking
> >> >  Get/Verify syspatch61-006_libssl.tgz 100% |*************|  2276 KB    00:04
> >> >  Installing patch 006_libssl
> >> >  Get/Verify syspatch61-007_freetyp... 100% |*************|   732 KB    00:01
> >> >  Installing patch 007_freetype
> >> >  Missing set, skipping patch 007_freetype
> >> >  Patches applied: 5,6
> >> >
> >> >and by adding support for -r optional argument, which could be comma separated
> >> >patch number list.
> >>
> >> That is incorrect.
> >>
> >> The usage situations are no patches, or all of the patches, or a
> >> subset and you are about to install to get more /all of them.  You
> >> don't get to choose which you want, unless all newer ones are ripped out also.
> >>
> >> We don't manage dependencies.
> >>
> >> This tooling is designed to make errata handling EASY FOR US.  Otherwise,
> >> we would not bother building this service.
> >>
> >
> >Here i agree.
> >
> >If not providing easy ability to revert arbitrary list of patches, what about
> >handle "transactions" or "syspatch sessions" or "patchsets" internally:
> >
> >After successful application of patch(es), create /var/syspatch/patchset.$TIMESTAMP
> >with list of applied patches (line by line).
> >
> >Reverting the last patchset would be reverting the patches from the last
> >patchset file, and removing that file.
>
> You haven't justified need.
>
> They are either installed, or not, and existence of files and directories
> already indicates the patchlevel.
>

I think the justification is:

Why do i even need to revert a patch? Only because something got broken
by the last syspatch command, that may have applied multiple patches.
I might not now which patch caused the problem.

If the problematic patch was not the last one from the set,
reverting with -r does not help, because it reverts single last patch only.

Well, applying `syspatch -r` repeatedly is a sort of solution as well.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Marc Espie-2
On Mon, May 15, 2017 at 08:36:21AM +0000, Michal Bozon wrote:

> I think the justification is:
>
> Why do i even need to revert a patch? Only because something got broken
> by the last syspatch command, that may have applied multiple patches.
> I might not now which patch caused the problem.
>
> If the problematic patch was not the last one from the set,
> reverting with -r does not help, because it reverts single last patch only.
>
> Well, applying `syspatch -r` repeatedly is a sort of solution as well.

scratching head.

well, we're talking patches on top of *stable*.
The release is originally rather well tested.
patches on top of that are applied conservatively, only to fix actual
issues.

I would really start worrying about our process if you actually need
to 'revert patches until you find out which one causes the problem'.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Andreas Kusalananda Kähäri
In reply to this post by Michal Bozon-2
On Mon, May 15, 2017 at 08:36:21AM +0000, Michal Bozon wrote:

> On 2017-05-15 Mon 02:23, Theo de Raadt wrote:
> > >On 2017-05-15 Mon 01:31, Theo de Raadt wrote:
> > >> >2) Notion of transactions
> > >> >
> > >> >Often, more patches are installed at once, with the single `syspatch`
> > >> >command. One might want to be able to revert all those patches at once
> > >> >as well. A notion of transactions could be made by adding a notion
> > >> >of transactions, but that would add more unnecessary complexity.
> > >> >
> > >> >It can be solved simpler way, by adding the line with the list of
> > >> >patches applied, e.g.
> > >> >
> > >> >  # syspatch
> > >> >  Installing patch 005_pf_src_tracking
> > >> >  Get/Verify syspatch61-006_libssl.tgz 100% |*************|  2276 KB    00:04
> > >> >  Installing patch 006_libssl
> > >> >  Get/Verify syspatch61-007_freetyp... 100% |*************|   732 KB    00:01
> > >> >  Installing patch 007_freetype
> > >> >  Missing set, skipping patch 007_freetype
> > >> >  Patches applied: 5,6
> > >> >
> > >> >and by adding support for -r optional argument, which could be comma separated
> > >> >patch number list.
> > >>
> > >> That is incorrect.
> > >>
> > >> The usage situations are no patches, or all of the patches, or a
> > >> subset and you are about to install to get more /all of them.  You
> > >> don't get to choose which you want, unless all newer ones are ripped out also.
> > >>
> > >> We don't manage dependencies.
> > >>
> > >> This tooling is designed to make errata handling EASY FOR US.  Otherwise,
> > >> we would not bother building this service.
> > >>
> > >
> > >Here i agree.
> > >
> > >If not providing easy ability to revert arbitrary list of patches, what about
> > >handle "transactions" or "syspatch sessions" or "patchsets" internally:
> > >
> > >After successful application of patch(es), create /var/syspatch/patchset.$TIMESTAMP
> > >with list of applied patches (line by line).
> > >
> > >Reverting the last patchset would be reverting the patches from the last
> > >patchset file, and removing that file.
> >
> > You haven't justified need.
> >
> > They are either installed, or not, and existence of files and directories
> > already indicates the patchlevel.
> >
>
> I think the justification is:
>
> Why do i even need to revert a patch? Only because something got broken
> by the last syspatch command, that may have applied multiple patches.
> I might not now which patch caused the problem.
>
> If the problematic patch was not the last one from the set,
> reverting with -r does not help, because it reverts single last patch only.
>
> Well, applying `syspatch -r` repeatedly is a sort of solution as well.
>

That would probably be a better solution (repeatedly removing the latest
patch), since I assume a new patch may depend on an earlier patch
existing.

However, if a patch is broken, it should be reported and then fixed, and
then a new patch will be rolled (if deemed necessary).

Regards,
Kusalananda

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Theo de Raadt-2
In reply to this post by Michal Bozon-2
>On Mon, May 15, 2017 at 08:36:21AM +0000, Michal Bozon wrote:
>> I think the justification is:
>>
>> Why do i even need to revert a patch? Only because something got broken
>> by the last syspatch command, that may have applied multiple patches.
>> I might not now which patch caused the problem.
>>
>> If the problematic patch was not the last one from the set,
>> reverting with -r does not help, because it reverts single last patch only.
>>
>> Well, applying `syspatch -r` repeatedly is a sort of solution as well.
>
>scratching head.
>
>well, we're talking patches on top of *stable*.
>The release is originally rather well tested.
>patches on top of that are applied conservatively, only to fix actual
>issues.
>
>I would really start worrying about our process if you actually need
>to 'revert patches until you find out which one causes the problem'.

Exactly.

If a syspatch sequence doesn't apply to your virgin system, then your
system isn't virgin and all bets are off, sorry you screwed it up.

This system is intentionally simple, to create robustness via simplicity.

I think you are being critical because you think it is amusing.

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Michal Bozon-2
In reply to this post by Michal Bozon-2
On 2017-05-15 Mon 08:19, Michal Bozon wrote:
> > > ...
> > ...
> ...
> Reverting the last patchset would be reverting the patches from the last
> patchset file, and removing that file.
>

correction/addition: in the reverse order

Reply | Threaded
Open this post in threaded view
|

Re: syspatch ideas

Michal Bozon-2
In reply to this post by Theo de Raadt-2
On 2017-05-15 Mon 02:50, Theo de Raadt wrote:
> ...
> This system is intentionally simple, to create robustness via simplicity.
>
> I think you are being critical because you think it is amusing.
>

(please not that the subject is still "syspatch ideas")

Syspatch infrastructure itself is amusing, not necessarily it is so
for currently available syspatch(8) feature set.

Yet more than discussed patchset revert feature i do miss
-v(erbose) option and/or mentioned -L(ist patched files) option.

It reminds me the discomfort of absence of -v option to rm(1) -r $dir
(which is fakeable by doing `find $dir` beforehand; manual listing
of syspatch-patched files is much more complicated)