[jira] [Commented] (MESOS-9768) Allow operators to mount the container rootfs with the `nosuid` flag
[
https://issues.apache.org/jira/browse/MESOS-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844438#comment-16844438
]
James Peach commented on MESOS-9768:
{quote}
What we are primarily interested in is to set it for for the overlay backend
but there are multiple backend options. Seems like a common flag
--image_mount_options could be applicable to bind backend as well (maybe aufs
too? Gilbert Song). It doesn't apply to the copy backend of course.
{quote}
I think that the main mount options that applies to non-overlayfs backends is
{{MS_RDONLY}}. Since you only get one image provisioner backend, I think that a
single global option is OK. Each backend can error out it there are any mount
options provided that it can't support.
Making this a per-container option is more complex. We can table the issue of
mount flags for non-image volumes here, since I expect that the configuration
for that will be different.
> Allow operators to mount the container rootfs with the `nosuid` flag
>
>
> Key: MESOS-9768
> URL: https://issues.apache.org/jira/browse/MESOS-9768
> Project: Mesos
> Issue Type: Improvement
> Components: containerization
>Reporter: James Peach
>Priority: Major
>
> If cluster users are allowed to launch containers with arbitrary images,
> those images may container setuid programs. For security reasons (auditing,
> privilege escalation), operators may wish to ensure that setuid programs
> cannot be used within a container.
>
> We should provide a way for operators to be able to specify that container
> volumes (including `/`0 should be mounted with the `nosuid` flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9509) Benchmark command health checks in default executor
[ https://issues.apache.org/jira/browse/MESOS-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Mann reassigned MESOS-9509: Assignee: Joseph Wu (was: Gastón Kleiman) > Benchmark command health checks in default executor > --- > > Key: MESOS-9509 > URL: https://issues.apache.org/jira/browse/MESOS-9509 > Project: Mesos > Issue Type: Task > Components: executor >Reporter: Vinod Kone >Assignee: Joseph Wu >Priority: Major > Labels: default-executor, foundations, mesosphere, perfomance > Attachments: check-rate.png, check-responsiveness.png, > mesos-mwstpublicagent1-soak113s.testing.mesosphe.re-22-37.stacks.gz, > multi-healthcheck-large-pod-executor-logs.tar.gz, > mwstpublicagent1-soak113s.testing.mesosphe.re.mesos-agent.log.gz > > > TCP/HTTP health checks were extensively scale tested as part of > https://mesosphere.com/blog/introducing-mesos-native-health-checks-apache-mesos-part-2/. > > We should do the same for command checks by default executor because it uses > a very different mechanism (agent fork/execs the check command as a nested > container) and will have very different scalability characteristics. > We should also use these benchmarks as an opportunity to produce perf traces > of the Mesos agent (both with and without process inheritance) so that a > thorough analysis of the performance can be done as part of MESOS-9513. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-7908) Mesos UI Keeps refreshing
[ https://issues.apache.org/jira/browse/MESOS-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844224#comment-16844224 ] Michael Doyle commented on MESOS-7908: -- We see this issue in 1.7.1. I think perhaps the code moved here: [https://github.com/apache/mesos/blob/master/src/webui/app/controllers.js#L66-L69] > Mesos UI Keeps refreshing > - > > Key: MESOS-7908 > URL: https://issues.apache.org/jira/browse/MESOS-7908 > Project: Mesos > Issue Type: Bug >Affects Versions: 1.2.0, 1.3.0, 1.3.1 >Reporter: Lax >Priority: Major > Attachments: mesos_ui_refresh.png > > > I tried to upgrade mesos from 1.0.1 to latest and suddenly I see Mesos UI > keeps refreshing every few seconds. I can say the issue remains at least from > version 1.1.x onwards. > The UI refresh will be seen only when you access Mesos thru proxy ports > (other than 5050) or custom DNS. > Root cause for this appears to be to be how mesos ui is constructing the end > point in here: > https://github.com/apache/mesos/blob/master/src/webui/master/static/js/controllers.js#L362-L365. > It basically learning mesos host and port from mesos state API response and > using that to load in the UI. But what you learn will be the internal host > name(pretty much node name) and port (5050) and it wont work in cases where > user proxy's the mesos port eg: 9443 in my case and also have custom DNS > format eg: *mesos-laxmesos4.dev.io* > So basically when I load mesos ui with URI: > https://mesos-laxmesos4.dev.io:9443, above pointed API is returning > https://[my node name]:5050/metrics/... while expected path is > https://mesos-laxmesos4.dev.io:9443/metrics/... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MESOS-9329) CMake build on Fedora 28 fails due to libevent error
[
https://issues.apache.org/jira/browse/MESOS-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839483#comment-16839483
]
Benno Evers edited comment on MESOS-9329 at 5/20/19 11:53 AM:
--
Indeed, the autotools build uses a older version of libevent,
[2.0.22|https://github.com/apache/mesos/blob/a9a2acabd03181865055b77cf81e7bb310b236d6/3rdparty/libevent-2.0.22-stable.tar.gz].
We can't easily use it in the cmake build because newer versions do not
support cmake, see MESOS-3529. Bottom line is: a cmake build on Linux with ssl
and libevent enabled is currently not supported.
was (Author: alexr):
Indeed, the autotools build uses a newer version of libevent,
[2.0.22|https://github.com/apache/mesos/blob/a9a2acabd03181865055b77cf81e7bb310b236d6/3rdparty/libevent-2.0.22-stable.tar.gz].
We can't easily use it in the cmake build because newer versions do not
support cmake, see MESOS-3529. Bottom line is: a cmake build on Linux with ssl
and libevent enabled is currently not supported.
> CMake build on Fedora 28 fails due to libevent error
>
>
> Key: MESOS-9329
> URL: https://issues.apache.org/jira/browse/MESOS-9329
> Project: Mesos
> Issue Type: Bug
>Reporter: Benno Evers
>Priority: Major
>
> Trying to build Mesos using cmake with the options
> {noformat}
> cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_SSL=1 -DENABLE_LIBEVENT=1
> {noformat}
> fails due to the following:
> {noformat}
> [ 1%] Building C object CMakeFiles/event_extra.dir/bufferevent_openssl.c.o
> /home/bevers/mesos/worktrees/master/build-cmake/3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta/bufferevent_openssl.c:
> In function ‘bio_bufferevent_new’:
> /home/bevers/mesos/worktrees/master/build-cmake/3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta/bufferevent_openssl.c:112:3:
> error: dereferencing pointer to incomplete type ‘BIO’ {aka ‘struct bio_st’}
> b->init = 0;
>^~
> /home/bevers/mesos/worktrees/master/build-cmake/3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta/bufferevent_openssl.c:
> At top level:
> /home/bevers/mesos/worktrees/master/build-cmake/3rdparty/libevent-2.1.5-beta/src/libevent-2.1.5-beta/bufferevent_openssl.c:234:1:
> error: variable ‘methods_bufferevent’ has initializer but incomplete type
> static BIO_METHOD methods_bufferevent = {
> [...]
> {noformat}
> Since the autotools build does not have issues when enabling libevent and
> ssl, it seems most likely that the `libevent-2.1.5-beta` version used by
> default in the cmake build is somehow connected to the error message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
