Similar to notes for nodes.
datacenter.cfg normally uses key-value pairs defined in the schema.
We bypass this to allow potentially long comments at the top.
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
We have some users running into issues in some cases, like syncing
huge user base through LDAP into users.cfg or having a few thousands+
of HA services, as then the per-file limit is exhausted.
Bumping that one provides only half of the solution as the total
limit of 30 MiB would only allow a few files getting that big, or
reduce the amount left over for actual guest configurations quite a
bit.
So also bump the total filesystem limit from 30 MiB to 128 MiB, so by
a factor of ~4 and in the same spirit bump the maximal numbers of
inodes (i.e., different files) from 10k to 256k, which pmxcfs can
handle still rather easily (tested with touch) and would allow to max
out the full FS limit with 512 byte files, which fits small guest
configs, so sounds like an OK proportioned limit.
That should give use quite some wiggle room again, and should be
relatively safe as most of our access is rather small and on a few
files only, only root has full access anyway and that user can break
everything already, so not much lost here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The ceph.service file has been removed in pve-manager commit be244f1.
Therefore, there is no need to reference it anymore. This also avoids
showing the `ceph.service` as a `not found` unit.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
This was always an "issue", but with Perl 5.28, from our Debian Buster
based release, decode_json just ignored the \0 NUL byte.
For example:
```
perl -w -MJSON -e 'my $raw = "[]\0"; print to_json(decode_json($raw), {pretty=>1});'
```
will get you the following error on perl 5.32
```
garbage after JSON object, at character offset 2 (before "\x{0}") at -e line 1.
```
Note, I did not find anything related in the perldelta aricles for
the 28 -> 30 or 30 -> 32 update, the first one made a bigger jump for
the JSON module version used, so possibly a change there.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
dh_systemd was enabled by default since level 10, with level 12 the
compat plugin does not exists anymore so enabling it manually results
in an error.
The dh_strip override is now obsolete too, as users need to go
through 5.4 AND 6.4 anyway on upgrade, and new installations do not
matter here.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we have lots of forum posts where users think that the locking was
the error, not the actual error message from the called code.
This has limited value as general-applied prefix, if a code requires
the lockid or whatever to be included in the error message they can
already do so, so just re-raise the error and be done, at least if it
is a error from the code and not from the lock setup,.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
SQLITE_PREPARE_PERSISTENT
The SQLITE_PREPARE_PERSISTENT flag is a hint to the query planner
that the prepared statement will be retained for a long time and
probably reused many times. Without this flag,
sqlite3_prepare_v3() and sqlite3_prepare16_v3() assume that the
prepared statement will be used just once or at most a few times
and then destroyed using sqlite3_finalize() relatively soon. The
current implementation acts on this hint by avoiding the use of
lookaside memory so as not to deplete the limited store of
lookaside memory. Future versions of SQLite may act on this hint
differently.
-- https://sqlite.org/c3ref/c_prepare_normalize.html#sqlitepreparepersistent
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we can trust that we own *value and *name until the sqlite statement
was executed, so use the STATIC bind flag to tell sqlite that it does
not need to make it's own copy in the bind statement.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was initially done because of some hook reading the config from
an unprivileged namespace when using unprivileged containers.
But, we nowadays do not do this anymore, either setup stuff before to
or use another source for getting required information (e.g., our
autodev hook uses "/var/lib/lxc/$vmid/devices").
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Removing them now could count as compat breakage, for users which
still depend on some of this weird behavior it's nicer if we do this
more explicitly with 7.0
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
cpg_mcast_joined (and transitively, cpg_join/leave) are not thread-safe.
pmxcfs triggers such operations via FUSE and CPG dispatch callbacks,
which are running in concurrent threads.
accordingly, we need to protect these operations with a mutex, otherwise
they might return CS_OK without actually doing what they were supposed
to do (which in turn can lead to the dfsm taking a wrong turn and
getting stuck in a supposedly short-lived state, blocking access via
FUSE and getting whole clusters fenced).
huge thanks to Alexandre Derumier for providing the initial bug report
and quite a lot of test runs while debugging this issue.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
dfsm_send_state_message_full always returns != 0, since it returns
cs_error_t which starts with CS_OK at 1, with values >1 representing
errors.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
replaces the random hacks where we do some hail-mary mkdir in a
writer or the like, to ensure that the directory structure exists and
we can write safely.
more central and safer would be pmxcfs itself, but to late in the
release cycle to do that now.
Chicken out if pmxcfs is not mounted, we don't want to trash it's
(future) mountpoint..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
