On Mon, 2018-11-19 at 19:58 +0000, Jonathan Dieter wrote:
On Mon, 2018-11-19 at 20:16 +0100, Jan Pokorný wrote:
> On 19/11/18 13:13 +0100, Nicolas Mailhot wrote:
> > Le 2018-11-19 12:28, Martin Kolman a écrit :
> >
> > > Many people might think RAM would not be an issue in 2018, but in
> > > practice there are
> > > and likely always will be memory constrained installation targets,
> > > such as massive deployments
> > > of "small" VMs or the IoT use cases mentioned above.
> >
> > Sure, that’s the artificial small vm case
> >
> > The average old/limited hardware is limited in memory, cpu and storage.
> > Therefore if you have one factor to sacrifice it's cpu time because you
can
> > always let the CPU run a little longer, but a limited system won't
magically
> > grow more memory or more storage.
> >
> > Storage would not be such a problem is dnf was smart enough to auto
> > partition big upgrades in lots of small partial upgrades, before downloading
> > gigs of data that do not fit on disk.
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=1609824
>
> Also, not familiar with zchunk way of doing things, but couldn't
> rpm-integrity-verified installed files be mapped back to "chunks"
> to further aleviate space concerns for the machine receiving
> updates in some cases?
That's an interesting thought. I was picturing using the zchunk
library in the dnf download stage to build a local rpm from the
verified locally installed files and the downloaded changed chunks,
but, if I understand your suggestions correctly, you're saying we could
just download the changed chunks and have RPM automatically get the
rpm-integrity verified chunks during the *install* stage.
How do you know which chunks to download w/o having a stored (or
recomputed) list of existing chunks ?
The advantage of this method is that you don't need to store the
local
data twice, but the danger is that the local files get changed
elsewhere during the install process.
It's an interesting thought, though, and I wonder if there's a way we
could work around that danger?
I do not think you can just trust random metadata somewhere, one of the
points of a rpm reinstall is to fix damaged files for example. It does
no good if you skip those because some file somewhere says they are
"OK". (If I understood your comment about "just downloading changed
chunks).
A couple more questions.
I skimmed quickly at the format and I have two questions I did not
immediately see an answer for.
1) why are you still supporting SHA-1 in a new format ?
2) what are the chunks sizes ?
Sorry if this is already answered somewhere.
Finally what signature scheme where you planning to use ? And how do
you deal with the data you want to "exclude" from signing, omit it or
feed in blank "sectors" ?
Thanks for any answer.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc