linux-ext4 - Re: How to package e2scrub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190529182111.GA5220@magnolia>
Date:   Wed, 29 May 2019 11:21:11 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Lukas Czerner <lczerner@...hat.com>
Cc:     linux-ext4@...r.kernel.org, Jan Kara <jack@...e.com>,
        "Theodore Ts'o" <tytso@....edu>, xfs <linux-xfs@...r.kernel.org>,
        Eric Sandeen <sandeen@...hat.com>
Subject: Re: How to package e2scrub

On Wed, May 29, 2019 at 02:06:03PM +0200, Lukas Czerner wrote:
> Hi guys,
> 
> I am about to release 1.45.2 for Fedora rawhide, but I was thinking
> about how to package the e2scrub cron job/systemd service.

Funny, xfs has the same conundrum.  Adding Eric & xfs list to cc...

> I really do not like the idea of installing cron job and/or the service as
> a part of regular e2fsprogs package. This can potentially really surprise
> people in a bad way.
>
> Note that I've already heard some complaints from debian users about the
> systemd service being installed on their system after the e2fsprogs
> update.

Yeah, e2scrub is bitrotting rather faster than I had thought it
would... but it's only available in Debian unstable.

> What I am going to do is to split the systemd service into a separate
> package and I'd like to come to some agreement about the name of the
> package so that we can have the same name across distributions (at least
> Fedora/Debian/Suse).

Indeed.  Eric picked "xfsprogs-xfs_scrub" for Rawhide, though I find
that name to be very clunky and would have preferred "xfs_scrub".

> I was thinking about e2scrub-service for systemd service or e2scrub-cron
> for the cron job. What do you think ?

In /theory/ the cronjob support in e2scrub (and xfs_scrub) were designed
to step out of the way if systemd is running, so at least in theory (on
Debian anyway) the two can be in the same package with the end result
being that e2scrub runs weekly in the background.  I've not tried in
rhel/suse environments, however.

I also don't see the point of supporting cron *while* systemd is active.
That increases the amount of corner-case testing we have to do, for
little gain.  It's enough work to maintain the systemd-with-timers and
sysvinit-with-cron scenarios.

If you're worried about the stability of systemd timer code, systemd's
timer support has been stable enough to run e2scrub_all/xfs_scrub_all on
my systems since late 2015, and I have no interest in supporting either
on a pre-2016 distro.  Practically speaking, I guess that RHEL8, SLES16,
and Ubuntu 20.04 will be the first LTS distros to support e2scrub at
all.

(As for xfs_scrub, it'll barely achieve alpha status in Linux 5.2...)

> Also I decided not to package the cron job for now. But if I decide to
> package it in the future I'd like to change the e2scrub cron
> configuration so that it can run on the systems with systemd but make
> the package conflict with the e2scrub-service so that users are free to
> decide how they want to use it.

If you do end up creating two packages I'd name the systemd one
e2scrub-systemd over e2scrub-service.

--D

> Thoughts ?
> 
> Thanks!
> -Lukas