[jira] [Commented] (MESOS-7262) Symlink mesos-agent to mesos-slave on `make install` not idempotent
[
https://issues.apache.org/jira/browse/MESOS-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933133#comment-15933133
]
pawan commented on MESOS-7262:
--
[~bbannier] I followed the install instructions in this page:
https://mesos.apache.org/documentation/latest/getting-started/
{code}
# Install (Optional).
$ make install
{code}
> Symlink mesos-agent to mesos-slave on `make install` not idempotent
> ---
>
> Key: MESOS-7262
> URL: https://issues.apache.org/jira/browse/MESOS-7262
> Project: Mesos
> Issue Type: Bug
> Components: cmake
>Affects Versions: 1.2.0
>Reporter: pawan
>
> I issued a make install twice after building Mesos from source, but its
> failing with the following error:
> {code}
> ln -s mesos-agent mesos-slave
> ln: failed to create symbolic link ‘mesos-slave’: File exists
> {code}
> I believe `make install` has to be idempotent. It looks like LN_S in Makefile
> aliases to `ln -s` and not `ln -snf` which would do it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7262) Symlink mesos-agent to mesos-slave on `make install` not idempotent
[
https://issues.apache.org/jira/browse/MESOS-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932601#comment-15932601
]
pawan commented on MESOS-7262:
--
Even a if check to see if the link already exists before trying to (re)create
it would suffice.
> Symlink mesos-agent to mesos-slave on `make install` not idempotent
> ---
>
> Key: MESOS-7262
> URL: https://issues.apache.org/jira/browse/MESOS-7262
> Project: Mesos
> Issue Type: Bug
> Components: cmake
>Affects Versions: 1.2.0
>Reporter: pawan
>
> I issued a make install twice after building Mesos from source, but its
> failing with the following error:
> {code}
> ln -s mesos-agent mesos-slave
> ln: failed to create symbolic link ‘mesos-slave’: File exists
> {code}
> I believe `make install` has to be idempotent. It looks like LN_S in Makefile
> aliases to `ln -s` and not `ln -snf` which would do it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7262) Symlink mesos-agent to mesos-slave on `make install` not idempotent
[
https://issues.apache.org/jira/browse/MESOS-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932507#comment-15932507
]
pawan commented on MESOS-7262:
--
[~tillt] Agreed. Aleast a simple -f would work. Also, `make install` breaks not
just with mesos-agent/mesos-slave combo but also in other areas where LN_S is
used.
> Symlink mesos-agent to mesos-slave on `make install` not idempotent
> ---
>
> Key: MESOS-7262
> URL: https://issues.apache.org/jira/browse/MESOS-7262
> Project: Mesos
> Issue Type: Bug
> Components: cmake
>Affects Versions: 1.2.0
>Reporter: pawan
>
> I issued a make install twice after building Mesos from source, but its
> failing with the following error:
> {code}
> ln -s mesos-agent mesos-slave
> ln: failed to create symbolic link ‘mesos-slave’: File exists
> {code}
> I believe `make install` has to be idempotent. It looks like LN_S in Makefile
> aliases to `ln -s` and not `ln -snf` which would do it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7262) Symlink mesos-agent to mesos-slave on `make install` has to be idempotent
pawan created MESOS-7262:
Summary: Symlink mesos-agent to mesos-slave on `make install` has
to be idempotent
Key: MESOS-7262
URL: https://issues.apache.org/jira/browse/MESOS-7262
Project: Mesos
Issue Type: Bug
Components: cmake
Affects Versions: 1.2.0
Reporter: pawan
I issued a make install twice after building Mesos from source, but its failing
with the following error:
{code}
ln -s mesos-agent mesos-slave
ln: failed to create symbolic link ‘mesos-slave’: File exists
{code}
I believe `make install` has to be idempotent. It looks like LN_S in Makefile
aliases to `ln -s` and not `ln -snf` which would do it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7262) Symlink mesos-agent to mesos-slave on `make install` not idempotent
[
https://issues.apache.org/jira/browse/MESOS-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pawan updated MESOS-7262:
-
Summary: Symlink mesos-agent to mesos-slave on `make install` not
idempotent (was: Symlink mesos-agent to mesos-slave on `make install` has to
be idempotent)
> Symlink mesos-agent to mesos-slave on `make install` not idempotent
> ---
>
> Key: MESOS-7262
> URL: https://issues.apache.org/jira/browse/MESOS-7262
> Project: Mesos
> Issue Type: Bug
> Components: cmake
>Affects Versions: 1.2.0
>Reporter: pawan
>
> I issued a make install twice after building Mesos from source, but its
> failing with the following error:
> {code}
> ln -s mesos-agent mesos-slave
> ln: failed to create symbolic link ‘mesos-slave’: File exists
> {code}
> I believe `make install` has to be idempotent. It looks like LN_S in Makefile
> aliases to `ln -s` and not `ln -snf` which would do it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MESOS-6443) Display maintenance information in the webui.
[ https://issues.apache.org/jira/browse/MESOS-6443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930506#comment-15930506 ] pawan edited comment on MESOS-6443 at 3/17/17 7:03 PM: --- Thanks [~haosd...@gmail.com] . Glad that it's being cherry picked. Would appreciate it if you can leave the new ticket id in the comment section here :) was (Author: pawan.ufl): Thanks [~haosdent huang]. Glad that it's being cherry picked. Would appreciate it if you can leave the new ticket id in the comment section here :) > Display maintenance information in the webui. > - > > Key: MESOS-6443 > URL: https://issues.apache.org/jira/browse/MESOS-6443 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Tomasz Janiszewski >Assignee: Tomasz Janiszewski >Priority: Minor > Fix For: 1.2.0 > > Attachments: mesos_webui_maintenance_schedule.png > > > Add new tab with Maintenance schedule. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-6443) Display maintenance information in the webui.
[ https://issues.apache.org/jira/browse/MESOS-6443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930506#comment-15930506 ] pawan commented on MESOS-6443: -- Thanks [~haosdent huang]. Glad that it's being cherry picked. Would appreciate it if you can leave the new ticket id in the comment section here :) > Display maintenance information in the webui. > - > > Key: MESOS-6443 > URL: https://issues.apache.org/jira/browse/MESOS-6443 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Tomasz Janiszewski >Assignee: Tomasz Janiszewski >Priority: Minor > Fix For: 1.2.0 > > Attachments: mesos_webui_maintenance_schedule.png > > > Add new tab with Maintenance schedule. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-6443) Display maintenance information in the webui.
[ https://issues.apache.org/jira/browse/MESOS-6443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930059#comment-15930059 ] pawan commented on MESOS-6443: -- Has the maintenance.html made it into the mesos-1.2.0 tar ball ? I cant see it in the package, also it throws a 404 on the ui. Could someone please check and comment ? > Display maintenance information in the webui. > - > > Key: MESOS-6443 > URL: https://issues.apache.org/jira/browse/MESOS-6443 > Project: Mesos > Issue Type: Improvement > Components: webui >Reporter: Tomasz Janiszewski >Assignee: Tomasz Janiszewski >Priority: Minor > Fix For: 1.2.0 > > Attachments: mesos_webui_maintenance_schedule.png > > > Add new tab with Maintenance schedule. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MESOS-4750) Mesos Executor expects all SSL_* environment variables to be set
pawan created MESOS-4750: Summary: Mesos Executor expects all SSL_* environment variables to be set Key: MESOS-4750 URL: https://issues.apache.org/jira/browse/MESOS-4750 Project: Mesos Issue Type: Documentation Components: general, slave Affects Versions: 0.26.0 Reporter: pawan I was trying to run Docker containers in a fully SSL-ized Mesos cluster but ran into problems because the executor was failing with a "Failed to shutdown socket with fd 10: Transport endpoint is not connected". My understanding of why this is happening is because the executor was trying to report its status to Mesos slave over HTTPS, but doesnt have the appropriate certs/env setup inside the executor. (Thanks to mslackbot/joseph for helping me figure this out on #mesos) It turns out, the executor expects all SSL_* variables to be set inside `CommandInfo.environment` which gets picked up by the executor to successfully reports its status to the slave. This part of __executor needing all the SSL_* variables to be set in its environment__ is missing in the Mesos SSL transitioning guide. I request you to please add this vital information to the doc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4665) Reverse DNS for cert validation ?
[
https://issues.apache.org/jira/browse/MESOS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pawan updated MESOS-4665:
-
Description:
I have three mesos master nodes configured to use SSL and with cert validation
enabled. All the machines are failing cert-validation and hence the peering
with the following error:
I0212 14:02:22.019564 20544 network.hpp:463] ZooKeeper group PIDs: {
log-replica(1)@192.168.1.16:5050, log-replica(1)@192.168.1.27:5050,
log-replica(1)@192.168.1.30:5050 }
I0212 14:02:22.037328 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.041191 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.061522 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065572 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065839 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos01.p.qa.a.com does not match peer hostname
name: 192.168.1.16
E0212 14:02:22.065994 20545 process.cpp:1911] Failed to shutdown socket with fd
27: Transport endpoint is not connected
I0212 14:02:22.068665 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.068761 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos02.p.qa.a.com does not match peer hostname
name: 192.168.1.27
E0212 14:02:22.068830 20545 process.cpp:1911] Failed to shutdown socket with fd
28: Transport endpoint is not connected
--
>From my understanding and looking at the source, during cert validation, mesos
>uses getnameinfo call to get the hostname of the connecting peer using the IP
>address on the socket connection. Everything worked when I added host-ip
>mappings of all peers to /etc/hosts on each host.
Does mesos inherently expect reverse DNS (PTR records) to be provisioned ? If
so, this is very challenging and unrealistic expectation. Even worse if you are
deploying mesos in a firewalled/NAT-ed environment.
Is my understanding right ? Am I missing anything here ? How would you
recommend me to proceed ?
Also, I use --hostname to set hostname of all mesos nodes and see the right
[ip, hostname] info in zookeeper node. Looks like mesos is not using it during
cert validation.
was:
I have three mesos master nodes configured to use SSL and with cert validation
enabled. All the machines are failing cert-validation and hence the peering
with the following error:
I0212 14:02:22.019564 20544 network.hpp:463] ZooKeeper group PIDs: {
log-replica(1)@192.168.1.16:5050, log-replica(1)@192.168.1.27:5050,
log-replica(1)@192.168.1.30:5050 }
I0212 14:02:22.037328 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.041191 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.061522 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065572 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065839 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos01.p.qa.a.com does not match peer hostname
name: 192.168.1.16
E0212 14:02:22.065994 20545 process.cpp:1911] Failed to shutdown socket with fd
27: Transport endpoint is not connected
I0212 14:02:22.068665 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.068761 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos02.p.qa.a.com does not match peer hostname
name: 192.168.1.27
E0212 14:02:22.068830 20545 process.cpp:1911] Failed to shutdown socket with fd
28: Transport endpoint is not connected
>From my understanding and looking at the source, during cert validation, mesos
>uses getnameinfo call to get the hostname of the connecting peer using the IP
>address on the socket
[jira] [Updated] (MESOS-4665) Reverse DNS for cert validation ?
[
https://issues.apache.org/jira/browse/MESOS-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pawan updated MESOS-4665:
-
Description:
I have three mesos master nodes configured to use SSL and with cert validation
enabled. All the machines are failing cert-validation and hence the peering
with the following error:
I0212 14:02:22.019564 20544 network.hpp:463] ZooKeeper group PIDs: {
log-replica(1)@192.168.1.16:5050, log-replica(1)@192.168.1.27:5050,
log-replica(1)@192.168.1.30:5050 }
I0212 14:02:22.037328 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.041191 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.061522 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065572 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065839 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos01.p.qa.a.com does not match peer hostname
name: 192.168.1.16
E0212 14:02:22.065994 20545 process.cpp:1911] Failed to shutdown socket with fd
27: Transport endpoint is not connected
I0212 14:02:22.068665 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.068761 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos02.p.qa.a.com does not match peer hostname
name: 192.168.1.27
E0212 14:02:22.068830 20545 process.cpp:1911] Failed to shutdown socket with fd
28: Transport endpoint is not connected
--
>From my understanding and looking at the source, during cert validation, mesos
>uses getnameinfo call to get the hostname of the connecting peer using the IP
>address on the socket connection. And this call would return the IP as a
>string which is resulting in failures as our cert has a CN of only the peer
>hostname. But, everything worked when I added host-ip mappings of all peers to
>/etc/hosts on each host.
Does mesos inherently expect reverse DNS (PTR records) to be provisioned ? If
so, this is very challenging and unrealistic expectation. Even worse if you are
deploying mesos in a firewalled/NAT-ed environment.
Is my understanding right ? Am I missing anything here ? How would you
recommend me to proceed ?
Also, I use --hostname to set hostname of all mesos nodes and see the right
[ip, hostname] info in zookeeper node. Looks like mesos is not using it during
cert validation.
was:
I have three mesos master nodes configured to use SSL and with cert validation
enabled. All the machines are failing cert-validation and hence the peering
with the following error:
I0212 14:02:22.019564 20544 network.hpp:463] ZooKeeper group PIDs: {
log-replica(1)@192.168.1.16:5050, log-replica(1)@192.168.1.27:5050,
log-replica(1)@192.168.1.30:5050 }
I0212 14:02:22.037328 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.041191 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.061522 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065572 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065839 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos01.p.qa.a.com does not match peer hostname
name: 192.168.1.16
E0212 14:02:22.065994 20545 process.cpp:1911] Failed to shutdown socket with fd
27: Transport endpoint is not connected
I0212 14:02:22.068665 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.068761 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos02.p.qa.a.com does not match peer hostname
name: 192.168.1.27
E0212 14:02:22.068830 20545 process.cpp:1911] Failed to shutdown socket with fd
28: Transport endpoint is not connected
[jira] [Created] (MESOS-4665) Reverse DNS for cert validation ?
pawan created MESOS-4665:
Summary: Reverse DNS for cert validation ?
Key: MESOS-4665
URL: https://issues.apache.org/jira/browse/MESOS-4665
Project: Mesos
Issue Type: Bug
Affects Versions: 0.26.0
Reporter: pawan
I have three mesos master nodes configured to use SSL and with cert validation
enabled. All the machines are failing cert-validation and hence the peering
with the following error:
I0212 14:02:22.019564 20544 network.hpp:463] ZooKeeper group PIDs: {
log-replica(1)@192.168.1.16:5050, log-replica(1)@192.168.1.27:5050,
log-replica(1)@192.168.1.30:5050 }
I0212 14:02:22.037328 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.041191 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.061522 20545 libevent_ssl_socket.cpp:973] Failed accept,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065572 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos01.p.qa.a.com does not
match peer hostname name: 192.168.1.16
I0212 14:02:22.065839 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos01.p.qa.a.com does not match peer hostname
name: 192.168.1.16
E0212 14:02:22.065994 20545 process.cpp:1911] Failed to shutdown socket with fd
27: Transport endpoint is not connected
I0212 14:02:22.068665 20545 libevent_ssl_socket.cpp:373] Failed connect,
verification error: Presented Certificate Name: mesos02.p.qa.a.com does not
match peer hostname name: 192.168.1.27
I0212 14:02:22.068761 20545 process.cpp:1281] Failed to link, connect:
Presented Certificate Name: mesos02.p.qa.a.com does not match peer hostname
name: 192.168.1.27
E0212 14:02:22.068830 20545 process.cpp:1911] Failed to shutdown socket with fd
28: Transport endpoint is not connected
>From my understanding and looking at the source, during cert validation, mesos
>uses getnameinfo call to get the hostname of the connecting peer using the IP
>address on the socket connection. Everything worked when I added host-ip
>mappings of all peers to /etc/hosts on each host.
Does mesos inherently expect reverse DNS (PTR records) to be provisioned ? If
so, this is very challenging and unrealistic expectation. Even worse if you are
deploying mesos in a firewalled/NAT-ed environment.
Is my understanding right ? Am I missing anything here ? How would you
recommend me to proceed ?
Also, I use --hostname to set hostname of all mesos nodes and see the right
[ip, hostname] info in zookeeper node. Looks like mesos is not using it during
cert validation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
