Although they have been useful, their maintenance and fragility caused
more trouble than their benefits.
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
(cherry picked from commit 038de0031b)
And the mon_advanced_debug_mode option that is only used in the context
of osdmonitor_prepare_command.
http://tracker.ceph.com/issues/9245Fixes: #9245
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
(cherry picked from commit 2abc8f400f)
Normally we repeat a sync if the journal is full and asks for it or if we
have pending sync waiters. This isn't for correctness: it's to move things
along quickly.
If we are shutting down *and* the journal is full, however, we currently
can get stuck in a loop where we repeatedly sync. However, the journal
never gets unfull because we aren't expiring anything.
We tried to fix this in 682b9daacb but that
didn't work because we don't tell the journal to stop before we shut down
the filestore sync thread.
I'm pretty sure there is another issue in the journal code as
full_state == FULL_FULL
submit_manager.op_seq = 14761
apply_manager.committing_seq = 14761
apply_manager.committed_seq = 14761
which seems odd. But I have no longs. Meanwhile, this fixes the hang.
Fixes: #9545
Signed-off-by: Sage Weil <sage@redhat.com>
If a given client doesn't have the required caps when running a command,
it must receive an EACCES or EPERM reply. This is already handled by
Monitor::handle_command(), which does an exceptionally good job at it.
Therefore, and unlike other messages that do not expect return values,
we can't simply drop the message if the client doesn't have the
appropriate capabilities, or things can get very weird very fast from
the user's perspective. Dropping the message for a command without a
reply has roughly the same effect as loss of quorum (timeout, pipes
failing) and confusion may ensue from it.
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
test creating and entity with blank caps with and without '--force'
being specified. without '--force' they must fail with EINVAL as the
monitor will not be able to parse them.
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
Eye-candy. We changed indentation of a few other entries and this one
was just too darn obvious, itching all over, night terrors, the whole
nine yards.
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
We have variables with the same name that are being shared! We don't
hit any issues with it currently because the code just kind of works
even though that happens. Add a bit of new logic that relies on an
immutable return code (for instance) and we're in the woods.
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
Only dispatch messages that a client may send if said client has at
least MON_CAP_R, and only dispatch internal monitor messages if peer is
a monitor.
Backport: firefly
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Instead of a single switch(), have multiple switch() and order them by
increasing necessity of privileges.
This patch thus divides the big switch into:
- messages not requiring auth/caps checks at all
- messages which caps shall be checked somewhere else
- messages the Monitor class needs to deal with but only require a
client to have enough caps for the monitor to consider handling them
- messages that only a monitor is allowed to send.
Backport: firefly
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
Adds three new profiles:
read-only: able to issue all read-only (MON_CAP_R) commands. Any
command that may take additional caps (MON_CAP_W or MON_CAP_X) won't
be allowed.
read-write: able to issue all read-write (MON_CAP_R | MON_CAP_W)
commands. Commands that require MON_CAP_X will not be allowed.
role-definer: solely able to issue commands on the 'auth' subsystem,
to which all caps are given (MON_CAP_R | MON_CAP_W | MON_CAP_X).
Fixes: #8899
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
We were checking the command's permissions against what we perceived as
the 'module' from parsing the command's "prefix" (specified by the
client). This caused troubles with cap checks for commands without a
submodule clearly defined, such as 'status' or 'health' (vs 'mon dump'
or 'osd pool set', which are of submodule 'mon' and 'osd' respectively).
As such, we now grab the command's submodule (right now solely for caps
checks) from the monitor's internal representation of the commands
(defined in mon/MonCommands.h and built at compile time and stashed in
'mon_commands'). Given that commands such as 'health', 'fsid' or
'status' have properly defined modules in MonCommands.h, we simply rely
on that representation for all commands. Which is what we should have
been doing from the start anyway, because we shouldn't be relying on the
client to point us to what we want to authenticate against.
Backport: firefly
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
The monitor doesn't really know how to validate caps not meant for it.
The MDS or the OSD may very well allow blank caps for instance, while
the monitor categorically does not. We can't simply state a capability
is invalid because we wouldn't take it as such.
On the other hand, we must check monitor caps and make sure they are
correct, otherwise malformed caps can go unnoticed for a while,
sometimes even being hard to understand what may have gone wrong.
Backport: firefly
Signed-off-by: Joao Eduardo Luis <joao.luis@inktank.com>
The STATEDIR variable is used to initialize the bootstrap-osd keyring
before it gets a chance to be overriden by --statedir. Replace it with
{statedir} so that it can be substituted after all options have been
parsed.
http://tracker.ceph.com/issues/9653Fixes: #9653
Signed-off-by: Loic Dachary <loic-201408@dachary.org>
(cherry picked from commit fa0bd06b46)
The RWTimer event cancellation is racy. Instead, just make all of our
callbacks tolerate cancellation races. This is already true of most of
them (in fact, they are probably broken because they try to take a write
lock while holding a read lock). Fix C_CancelOp so that it calls the
other op_cancel (that takes a tid).
Then switch the RWTimer back to a SafeTimer. Put it in unsafe callbacks
mode because we don't want to introduce lock cycles with timer_lock.
Fixes: #9582
See also: #9650
Signed-off-by: Sage Weil <sage@redhat.com>
Previously, we continuously requeued the snap trimmer while in
TrimmingObjects. This is not a good idea now that we try to
limit the number of snap trimming repops in flight and requeue
the snap trimmer directly as those repops complete.
Fixes: #9113
Backport: giant, dumpling, firefly
Signed-off-by: Samuel Just <sam.just@inktank.com>
Also, explicitely maintain a max number of concurrently trimming
objects.
Fixes: 9113
Backport: dumpling, firefly, giant
Signed-off-by: Samuel Just <sam.just@inktank.com>
Fixes: #9013
Originally the configurable was empty, now setting explicitly both
fastcgi and civetweb (on port 7480).
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
This is done in fedora packaging. Do it here too so that you can move
between upstream packages (from ceph.com) and fedora and other derivatives
will builds.
Backport: firefly, dumpling
Signed-off-by: Sage Weil <sage@redhat.com>
Fix two other paths where may change the mon state so that we wait for the
pending write first. start_election() in particular can be triggered at
almost any time if we see an election message from another mon.
Signed-off-by: Sage Weil <sage@redhat.com>
Also, the full peer will wait until the rejection from the primary
to do a state transition.
Fixes: #9626
Backport: giant, firefly, dumpling
Signed-off-by: Samuel Just <sam.just@inktank.com>
We are hitting a strange issue with valgrind and pthread spinlocks. Avoid
the issue by using an atomic_t here (which is simpler anyway).
Avoids: #8822
Backport: firefly
Signed-off-by: Sage Weil <sage@redhat.com>
The ctime changes any time the inode does. That can happen even without
the file itself having changed, so we'd better accept the update whenever
the auth caps have dirtied, without worrying about the file caps!
Fixes: #9514
Backport: firefly
Signed-off-by: Greg Farnum <greg@inktank.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: John Spray <john.spray@redhat.com>
