IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
squashed from the respective commits of the stable-7 branch, which is
the canonical source for this specific script.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The whole thing is already prepared for this, the systemd timer was
just a fixed periodic timer with a frequency of one minute. And we
just introduced it as the assumption was made that less memory usage
would be generated with this approach, AFAIK.
But logging 4+ lines just about that the timer was started, even if
it does nothing, and that 24/7 is not to cheap and a bit annoying.
So in a first step add a simple daemon, which forks of a child for
running jobs once a minute.
This could be made still a bit more intelligent, i.e., look if we
have jobs tor run before forking - as forking is not the cheapest
syscall. Further, we could adapt the sleep interval to the next time
we actually need to run a job (and sending a SIGUSR to the daemon if
a job interval changes such, that this interval got narrower)
We try to sync running on minute-change boundaries at start, this
emulates systemd.timer behaviour, we had until now. Also user can
configure jobs on minute precision, so they probably expect that
those also start really close to a minute change event.
Could be adapted to resync during running, to factor in time drift.
But, as long as enough cpu cycles are available we run in correct
monotonic intervalls, so this isn't a must, IMO.
Another improvement could be locking a bit more fine grained, i.e.
not on a per-all-local-job-runs basis, but per-job (per-guest?)
basis, which would improve temporary starvement of small
high-periodic jobs through big, less peridoci jobs.
We argued that it's the user fault if such situations arise, but they
can evolve over time without noticing, especially in compolexer
setups.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
this call site was apparently missed when we refactored the node config
/ ACME interaction.
Suggested/Reported-by: Frédéric Bourqui
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
if our self-signed certificate expires in more than 825 days, but was
created after July 2019 it won't be accepted by modern Apple devices. we
fixed the issuance to generate shorter-lived certificates in November
2019, this cleans up the existing ones to fix this and similar future
issues.
two years / 730 days as cut-off was chosen since it's our new maximum
self-signed certificate lifetime, and should thus catch all old-style
certificates.
another positive side-effect is that we can now phase out support for
older certificates faster, e.g. if we want to move to bigger keys,
different signature algorithms, or anything else in that direction.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
but only if the cert is issued by the ca in /etc/pve/pve-root-ca.pem
(by checking the issuer and openssl verify)
this way we can reduce the lifetime of the certs without having
to worry that they ran out
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Add a simple ExecStartPre command which reads the local node config,
and if a delay is set the helper sleeps that long then exists.
The systemd-unit approach was chosen as this ensures that we really
only delay when doing the startall on node boot. The pve-guests
service does not allows manual stops, starts or restarts, it can only
be pulled in by the multi-user.target
Mark this command with "-" to tell systemd that errors of it should
not cause an abort, it's a best-effort approach.
The journal from a 2 second delay would look like:
> Nov 19 13:13:48 dev6 systemd[1]: Starting PVE guests...
> Nov 19 13:13:48 dev6 pve-startall-delay[2318]: Delaying on-boot 'startall' command for 2 second(s).
> ...
> Nov 19 13:13:50 dev6 pve-guests[2339]: <root@pam> starting task UPID:dev6:00000924:00000529:5DD3DC7E:startall::root@pam:
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch builds the zsh tab completion scripts for the cli tools of
pve-manager.
In order for it to work, the latest version of pve-common and pve-docs
including the corresponding patches have to be installed on the build
system.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
this allows correct builds without pve-manager installed, with a clean
fall-back to the old behaviour in case pve-doc-generator is too old.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
In pve-common the following changes happened:
0adee98 ("cli_handler: pass common output options as separate parameter")
352b7a1 ("PVE::CLIFormatter - implement new output options")
We now get the format passed via an options hash in the
output function instead of seeing it as an api call
parameter.
Similarly, --quiet is now already handled there.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We have good command line completion and history with 'bash', so there is
no real need to duplicate this functionality.
Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
