Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Adam Borowski-3
Package: ddupdate
Version: 0.6.2-1
Severity: normal

Hi!
The auto-update functionality is for some reason systemd only, despite not
actually using any systemd features.  This makes it broken on any other
init/rc system for no gain.

Could you please convert the .service/.timer to a init script and/or cron
job?


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ddupdate depends on:
ii  iproute2  4.20.0-2
ii  python3   3.7.3-1

ddupdate recommends no packages.

ddupdate suggests no packages.

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Alec Leamas
Hi Adam,

On 14/04/2019 16:22, Adam Borowski wrote:

> Package: ddupdate
> Version: 0.6.2-1
> Severity: normal
>
> Hi!
> The auto-update functionality is for some reason systemd only, despite not
> actually using any systemd features.  This makes it broken on any other
> init/rc system for no gain.
>
> Could you please convert the .service/.timer to a init script and/or cron
> job?
>
Anything is possible but... in this case ddupdate installs as a user
program without anything running as root. Things like cron or init
scripts are requires root permissions, which IMHO is bad enough to not
convert current timer etc. And, cron jobs are nowhere as flexible as
systemd timers.

OTOH, it would of course be possible to add alternative solutions like
cron jobs to the package. This would requires patches to
ddupdate-config, but should otherwise be trivial. But to be honest, I'm
more in a "patches welcome" state on this -- I'm just not motivated to
make such fixes myself.

--alec

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Adam Borowski-3
On Sun, Apr 14, 2019 at 05:20:08PM +0200, Alec Leamas wrote:

> On 14/04/2019 16:22, Adam Borowski wrote:
> > Hi!
> > The auto-update functionality is for some reason systemd only, despite not
> > actually using any systemd features.  This makes it broken on any other
> > init/rc system for no gain.
> >
> > Could you please convert the .service/.timer to a init script and/or cron
> > job?
> >
> Anything is possible but... in this case ddupdate installs as a user program
> without anything running as root. Things like cron or init scripts are
> requires root permissions

It's same as for systemd, which also runs as root -- only the syntax is
different.  There's "runuser"; on a default install exim4 and popcon use it.

> And, cron jobs are nowhere as flexible as systemd timers.

You have two timers: one every 1h (the usual cron way), and another 2min
after boot.  What's the point of the second if you already have an oneshot
service?

> OTOH, it would of course be possible to add alternative solutions like cron
> jobs to the package. This would requires patches to ddupdate-config, but
> should otherwise be trivial. But to be honest, I'm more in a "patches
> welcome" state on this -- I'm just not motivated to make such fixes myself.

I don't use ddupdate myself anymore (I don't even remember if I used
ddupdate or one of the alternatives), thus it might be more for an actual
user.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Alec Leamas

Hi again,

On 14/04/2019 18:49, Adam Borowski wrote:

> On Sun, Apr 14, 2019 at 05:20:08PM +0200, Alec Leamas wrote:
>> On 14/04/2019 16:22, Adam Borowski wrote:
>>> Hi!
>>> The auto-update functionality is for some reason systemd only, despite not
>>> actually using any systemd features.  This makes it broken on any other
>>> init/rc system for no gain.
>>>
>>> Could you please convert the .service/.timer to a init script and/or cron
>>> job?
>>>
>> Anything is possible but... in this case ddupdate installs as a user program
>> without anything running as root. Things like cron or init scripts are
>> requires root permissions
>
> It's same as for systemd, which also runs as root -- only the syntax is
> different.  There's "runuser"; on a default install exim4 and popcon use it.


No. ddupdate uses systemd --user to setup and run  the service without
root permissions. So it's not comparable in this respect.

>> And, cron jobs are nowhere as flexible as systemd timers.
>
> You have two timers: one every 1h (the usual cron way), and another 2min
> after boot.  What's the point of the second if you already have an oneshot
> service?


It's about having a dynamic (e. g., dhcp) address which could change
anytime. That's why services like this kind periodically checks if the
address has changed and updates the involved DNS entry if so.


>> OTOH, it would of course be possible to add alternative solutions like cron
>> jobs to the package. This would requires patches to ddupdate-config, but
>> should otherwise be trivial. But to be honest, I'm more in a "patches
>> welcome" state on this -- I'm just not motivated to make such fixes myself.
>
> I don't use ddupdate myself anymore (I don't even remember if I used
> ddupdate or one of the alternatives), thus it might be more for an actual
> user.


You have probably never used it then, it's a pretty new tool. You might,
however, have used ddclient which is sort of similar (and widespread).

> thus it might be more for an actual user.

Agreed.

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Alec Leamas
Hi again, one more thing:

On 14/04/2019 20:02, Alec Leamas wrote:
>
> Hi again,
>
[lot's of stuff]


BTW: Given that the systemd stuff is part of the upstream package, on
what grounds could you state that "autoupdate shouldn't be
systemd-only"? Is there a Debian policy or something similar I have missed?

TL;DR Isn't this a plain RFE?

--alec

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Adam Borowski-3
On Sun, Apr 14, 2019 at 08:12:30PM +0200, Alec Leamas wrote:
> BTW: Given that the systemd stuff is part of the upstream package

Ah right, I've confused this with another package I was reviewing at the
same time, where the .service file came from the debian/ dir.  My bad.

On the other hand, I see that your "ddupdate" is a clean reimplementation
with no relation to the ddupdate I had been using over a decade ago, thus
this is not a regression either.

> on what grounds could you state that "autoupdate shouldn't be
> systemd-only"?  Is there a Debian policy or something similar I have
> missed?
>
> TL;DR Isn't this a plain RFE?

A "must" requirement of the policy:

§9.11:
# [...] any package integrating with other init systems
# must also be backwards-compatible with sysvinit by providing a SysV-
# style init script with the same name as and equivalent functionality
# to any init-specific job, as this is the only start-up configuration
# method guaranteed to be supported by all init implementations.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Adam Borowski-3
In reply to this post by Alec Leamas
On Sun, Apr 14, 2019 at 08:02:45PM +0200, Alec Leamas wrote:
> No. ddupdate uses systemd --user to setup and run  the service without
> root permissions. So it's not comparable in this respect.

It is called by the main blob itself, which runs as root, and sheds
permissions only to execute user services.

But I'm definitely not an expert on systemd -- heck, I can't even run it on
the machine I'm sitting at right now as it won't complete boot...

> >> And, cron jobs are nowhere as flexible as systemd timers.
> >
> > You have two timers: one every 1h (the usual cron way), and another 2min
> > after boot.  What's the point of the second if you already have an oneshot
> > service?
>
>
> It's about having a dynamic (e. g., dhcp) address which could change
> anytime. That's why services like this kind periodically checks if the
> address has changed and updates the involved DNS entry if so.

Yeah, that's what the 1h cronjob is for.  You also have one at boot.  What
I'm pointing at is the second timer that runs 2min after boot -- it's
redundant with the service you already have.

> > I don't use ddupdate myself anymore (I don't even remember if I used
> > ddupdate or one of the alternatives), thus it might be more for an actual
> > user.
>
> You have probably never used it then, it's a pretty new tool. You might,
> however, have used ddclient which is sort of similar (and widespread).

There's a large number of such clients, yeah.

Heck, I once wrote such a script for an own DNS server myself, even...

But today, any consumer ISP at any of three places I have non-hosted
machines at doesn't even support inbound IPv4 anymore, making tunnels
the way to go for me.


Meow.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#927062: ddupdate: autoupdate shouldn't be systemd-only

Alec Leamas
On 14/04/2019 21:22, Adam Borowski wrote:
> On Sun, Apr 14, 2019 at 08:02:45PM +0200, Alec Leamas wrote:
>> No. ddupdate uses systemd --user to setup and run  the service without
>> root permissions. So it's not comparable in this respect.
>
> It is called by the main blob itself, which runs as root, and sheds
> permissions only to execute user services.

Indeed. Stili, ddupfdate users can setuo and run their service without
root permissions; IIRC cron et. el. does not offer this option.


>>> You have two timers: one every 1h (the usual cron way), and another 2min
>>> after boot.  What's the point of the second if you already have an oneshot
>>> service?

Because it's very likely you have a new address after boot which need to
be registered


> But today, any consumer ISP at any of three places I have non-hosted
> machines at doesn't even support inbound IPv4 anymore, making tunnels
> the way to go for me.

Well, that's you. Other users have inbound connections for various reasons.

> A "must" requirement of the policy:

> §9.11:
> # [...] any package integrating with other init systems
> # must also be backwards-compatible with sysvinit by providing a SysV-
> # style init script with the same name as and equivalent functionality
> # to any init-specific job, as this is the only start-up configuration
> # method guaranteed to be supported by all init implementations.

It's interesting -- but it does not take the fact that systemd is the
default init system into account (per TC decision etc, you know this
better than me I guess). The Debian wiki [1] tells us:

# Since jessie, only systemd is fully supported; sysvinit is mostly
# supported, but Debian packages are not required to provide sysvinit
# start scripts.

I will not take part in any systemd  war here. Given the complete
context,  I think this is an RFE.


--alec

[1] https://wiki.debian.org/Init