You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Jie Yu <yu...@gmail.com> on 2016/06/21 06:25:29 UTC
Persistent volume ownership issue
Hi folks,
Currently, the ownership of the persistent volumes are set to be the same
as the sandbox. In the implementation, we call `chown -R` on the persistent
volume to match that of the sandbox each time before we mount it into the
container.
Recently, we realized that this behavior is not ideal. Especially, if a
task created some files in the persistent volume, and the owner of those
file might be different than the task's user. For instance, a task is
running under root and it creates some database files under user 'database'
and launch the database process under user 'database'. When the database
process is restarted by the scheduler, the current behavior is that the
we'll do a 'chown -R root.root' on the persistent volume, causes database
files to be chown to 'root'.
The true fix of this problem is to allow frameworks to explicit specify
owner of persistent volumes during creation. THis is captured in this
ticket:
https://issues.apache.org/jira/browse/MESOS-4893
In the short-term (for 1.0), I propose that, instead of doing a recursive
chown, we do a non-recursive chown. That'll allow the new task to at least
create new files under the persistent volume, but do not change ownership
of files created by previous tasks. It should be a very simple fix which we
can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
Thanks,
- Jie
Re: Persistent volume ownership issue
Posted by Yan Xu <xu...@apple.com>.
+1 if no one is relying on the old behavior.
Jiang Yan Xu
On Mon, Jun 20, 2016 at 11:25 PM, Jie Yu <yu...@gmail.com> wrote:
> Hi folks,
>
> Currently, the ownership of the persistent volumes are set to be the same
> as the sandbox. In the implementation, we call `chown -R` on the persistent
> volume to match that of the sandbox each time before we mount it into the
> container.
>
> Recently, we realized that this behavior is not ideal. Especially, if a
> task created some files in the persistent volume, and the owner of those
> file might be different than the task's user. For instance, a task is
> running under root and it creates some database files under user 'database'
> and launch the database process under user 'database'. When the database
> process is restarted by the scheduler, the current behavior is that the
> we'll do a 'chown -R root.root' on the persistent volume, causes database
> files to be chown to 'root'.
>
> The true fix of this problem is to allow frameworks to explicit specify
> owner of persistent volumes during creation. THis is captured in this
> ticket:
> https://issues.apache.org/jira/browse/MESOS-4893
>
> In the short-term (for 1.0), I propose that, instead of doing a recursive
> chown, we do a non-recursive chown. That'll allow the new task to at least
> create new files under the persistent volume, but do not change ownership
> of files created by previous tasks. It should be a very simple fix which we
> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>
> Thanks,
> - Jie
>
Re: Persistent volume ownership issue
Posted by Yan Xu <xu...@apple.com>.
+1 if no one is relying on the old behavior.
Jiang Yan Xu
On Mon, Jun 20, 2016 at 11:25 PM, Jie Yu <yu...@gmail.com> wrote:
> Hi folks,
>
> Currently, the ownership of the persistent volumes are set to be the same
> as the sandbox. In the implementation, we call `chown -R` on the persistent
> volume to match that of the sandbox each time before we mount it into the
> container.
>
> Recently, we realized that this behavior is not ideal. Especially, if a
> task created some files in the persistent volume, and the owner of those
> file might be different than the task's user. For instance, a task is
> running under root and it creates some database files under user 'database'
> and launch the database process under user 'database'. When the database
> process is restarted by the scheduler, the current behavior is that the
> we'll do a 'chown -R root.root' on the persistent volume, causes database
> files to be chown to 'root'.
>
> The true fix of this problem is to allow frameworks to explicit specify
> owner of persistent volumes during creation. THis is captured in this
> ticket:
> https://issues.apache.org/jira/browse/MESOS-4893
>
> In the short-term (for 1.0), I propose that, instead of doing a recursive
> chown, we do a non-recursive chown. That'll allow the new task to at least
> create new files under the persistent volume, but do not change ownership
> of files created by previous tasks. It should be a very simple fix which we
> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>
> Thanks,
> - Jie
>
Re: Persistent volume ownership issue
Posted by Anindya Sinha <an...@gmail.com>.
Currently the volume is owned by say framework user A when a CREATE is done. When a task is launched, the ownership of the volume is changed recursively to say user B, which means the root directory and all of its content has now ownership of user B. This enables user B to write into this persistent volume but as a result it changes ownership of all existing contents of persistent volume to user B as well.
I think change just changes ownership of the root directory to user B but keeps the ownership of the existing content of persistent volume to user A. This would still allow the task to write onto the persistent volume as user B (at least at root level) but not allow existing content to be deleted or overwritten that is owned by a lower privileged user.
I think this would work and would restrict lower privileged user to not modify contents of higher privileged users.
Thanks
Anindya
> On Jun 21, 2016, at 5:07 AM, Joris Van Remoortere <jo...@mesosphere.io> wrote:
>
> For the case where a container drops down in privileges and still wants to
> create a new file, this will result in an error if it is at the root of the
> persistent volume right?
>
> Is the recommended pattern then to always create a stub directory at the
> root of the persistent volume, and then launch any lower privileged apps
> underneath that? For example:
>
> / <- Root of persistent volume (Owned by framework user / root)
> /Database/ <- Stub directory (Owned by lower privileged user)
>
> All new files by the lower privileged app must be created under /Database/*
> ?
> It would result in an error if the App tried to create /Database-backups/ ?
> Only the framework as its original user would be able to do that?
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
>> On Tue, Jun 21, 2016 at 8:25 AM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Hi folks,
>>
>> Currently, the ownership of the persistent volumes are set to be the same
>> as the sandbox. In the implementation, we call `chown -R` on the persistent
>> volume to match that of the sandbox each time before we mount it into the
>> container.
>>
>> Recently, we realized that this behavior is not ideal. Especially, if a
>> task created some files in the persistent volume, and the owner of those
>> file might be different than the task's user. For instance, a task is
>> running under root and it creates some database files under user 'database'
>> and launch the database process under user 'database'. When the database
>> process is restarted by the scheduler, the current behavior is that the
>> we'll do a 'chown -R root.root' on the persistent volume, causes database
>> files to be chown to 'root'.
>>
>> The true fix of this problem is to allow frameworks to explicit specify
>> owner of persistent volumes during creation. THis is captured in this
>> ticket:
>> https://issues.apache.org/jira/browse/MESOS-4893
>>
>> In the short-term (for 1.0), I propose that, instead of doing a recursive
>> chown, we do a non-recursive chown. That'll allow the new task to at least
>> create new files under the persistent volume, but do not change ownership
>> of files created by previous tasks. It should be a very simple fix which we
>> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>>
>> Thanks,
>> - Jie
>>
Re: source code compile failure mesos-0.28.0
Posted by Neil Conway <ne...@gmail.com>.
Can you post the content of "config.log"?
Thanks,
Neil
On Tue, Jun 21, 2016 at 3:17 PM, Ali Aktar <al...@icloudinnovate.com> wrote:
> Hi;
>
> All dependencies as per doc were installed. I’m using Centos 7:
> Linux ip-172-31-46-249.eu-west-1.compute.internal 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> CentOS Linux release 7.2.1511 (Core)
>
>
> Thanks
> Ali.
>
> On 21 Jun 2016, at 13:55, José Guilherme Vanz <gu...@gmail.com> wrote:
>
>> Do you ensure that all dependencies described here:
>> http://mesos.apache.org/documentation/latest/getting-started/ are
>> installed? Furthermore, which Linux flavour are you using?
>>
>> Thanks
>>
>> On Tue, 21 Jun 2016 at 09:22 Ali Aktar <al...@icloudinnovate.com> wrote:
>>
>>> Hi;
>>>
>>> Can someone please help, I’m getting the following errors while running
>>> ./configure:
>>>
>>> [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos
>>> --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
>>> checking build system type... x86_64-unknown-linux-gnu
>>> checking host system type... x86_64-unknown-linux-gnu
>>> checking target system type... x86_64-unknown-linux-gnu
>>> checking for a BSD-compatible install... /bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking whether make supports nested variables... yes
>>> checking whether to enable maintainer-specific portions of Makefiles... yes
>>> checking for style of include used by make... GNU
>>> checking for gcc... gcc
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... no
>>> checking for suffix of object files... o
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether gcc accepts -g... yes
>>> checking for gcc option to accept ISO C89... none needed
>>> checking whether gcc understands -c and -o together... yes
>>> checking dependency style of gcc... gcc3
>>> checking for ar... ar
>>> checking the archiver (ar) interface... ar
>>> checking how to print strings... printf
>>> checking for a sed that does not truncate output... /bin/sed
>>> checking for grep that handles long lines and -e... /bin/grep
>>> checking for egrep... /bin/grep -E
>>> checking for fgrep... /bin/grep -F
>>> checking for ld used by gcc... /bin/ld
>>> checking if the linker (/bin/ld) is GNU ld... yes
>>> checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
>>> checking the name lister (/bin/nm -B) interface... BSD nm
>>> checking whether ln -s works... yes
>>> checking the maximum length of command line arguments... 1572864
>>> checking how to convert x86_64-unknown-linux-gnu file names to
>>> x86_64-unknown-linux-gnu format... func_convert_file_noop
>>> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
>>> format... func_convert_file_noop
>>> checking for /bin/ld option to reload object files... -r
>>> checking for objdump... objdump
>>> checking how to recognize dependent libraries... pass_all
>>> checking for dlltool... no
>>> checking how to associate runtime and link libraries... printf %s\n
>>> checking for g++... g++
>>> checking whether we are using the GNU C++ compiler... yes
>>> checking whether g++ accepts -g... yes
>>> checking dependency style of g++... gcc3
>>> checking for archiver @FILE support... @
>>> checking for strip... strip
>>> checking for ranlib... ranlib
>>> checking command to parse /bin/nm -B output from gcc object... ok
>>> checking for sysroot... no
>>> checking for a working dd... /bin/dd
>>> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
>>> checking for mt... no
>>> checking if : is a manifest tool... no
>>> checking how to run the C preprocessor... gcc -E
>>> checking for ANSI C header files... yes
>>> checking for sys/types.h... yes
>>> checking for sys/stat.h... yes
>>> checking for stdlib.h... yes
>>> checking for string.h... yes
>>> checking for memory.h... yes
>>> checking for strings.h... yes
>>> checking for inttypes.h... yes
>>> checking for stdint.h... yes
>>> checking for unistd.h... yes
>>> checking for dlfcn.h... yes
>>> checking for objdir... .libs
>>> checking if gcc supports -fno-rtti -fno-exceptions... no
>>> checking for gcc option to produce PIC... -fPIC -DPIC
>>> checking if gcc PIC flag -fPIC -DPIC works... yes
>>> checking if gcc static flag -static works... no
>>> checking if gcc supports -c -o file.o... yes
>>> checking if gcc supports -c -o file.o... (cached) yes
>>> checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared
>>> libraries... yes
>>> checking whether -lc should be explicitly linked in... no
>>> checking dynamic linker characteristics... GNU/Linux ld.so
>>> checking how to hardcode library paths into programs... immediate
>>> checking whether stripping libraries is possible... yes
>>> checking if libtool supports shared libraries... yes
>>> checking whether to build shared libraries... yes
>>> checking whether to build static libraries... no
>>> checking how to run the C++ preprocessor... g++ -E
>>> checking for ld used by g++... /bin/ld -m elf_x86_64
>>> checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
>>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>>> libraries... yes
>>> checking for g++ option to produce PIC... -fPIC -DPIC
>>> checking if g++ PIC flag -fPIC -DPIC works... yes
>>> checking if g++ static flag -static works... no
>>> checking if g++ supports -c -o file.o... yes
>>> checking if g++ supports -c -o file.o... (cached) yes
>>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>>> libraries... yes
>>> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>>> checking how to hardcode library paths into programs... immediate
>>> configure: creating ./config.lt
>>> config.lt: creating libtool
>>> configure: Setting up build environment for x86_64 linux-gnu
>>> checking whether we are using the GNU C++ compiler... (cached) yes
>>> checking whether g++ accepts -g... (cached) yes
>>> checking dependency style of g++... (cached) gcc3
>>> checking whether we are using the GNU C compiler... (cached) yes
>>> checking whether gcc accepts -g... (cached) yes
>>> checking for gcc option to accept ISO C89... (cached) none needed
>>> checking whether gcc understands -c and -o together... (cached) yes
>>> checking dependency style of gcc... (cached) gcc3
>>> checking whether ln -s works... yes
>>> checking for C++ compiler vendor... gnu
>>> checking for C++ compiler version... configure: error: in
>>> `/mnt/s3mnt/mesos/mesos-0.28.0/build':
>>> configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
>>> See `config.log' for more details
>
Re: source code compile failure mesos-0.28.0
Posted by Neil Conway <ne...@gmail.com>.
Can you post the content of "config.log"?
Thanks,
Neil
On Tue, Jun 21, 2016 at 3:17 PM, Ali Aktar <al...@icloudinnovate.com> wrote:
> Hi;
>
> All dependencies as per doc were installed. I’m using Centos 7:
> Linux ip-172-31-46-249.eu-west-1.compute.internal 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> CentOS Linux release 7.2.1511 (Core)
>
>
> Thanks
> Ali.
>
> On 21 Jun 2016, at 13:55, José Guilherme Vanz <gu...@gmail.com> wrote:
>
>> Do you ensure that all dependencies described here:
>> http://mesos.apache.org/documentation/latest/getting-started/ are
>> installed? Furthermore, which Linux flavour are you using?
>>
>> Thanks
>>
>> On Tue, 21 Jun 2016 at 09:22 Ali Aktar <al...@icloudinnovate.com> wrote:
>>
>>> Hi;
>>>
>>> Can someone please help, I’m getting the following errors while running
>>> ./configure:
>>>
>>> [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos
>>> --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
>>> checking build system type... x86_64-unknown-linux-gnu
>>> checking host system type... x86_64-unknown-linux-gnu
>>> checking target system type... x86_64-unknown-linux-gnu
>>> checking for a BSD-compatible install... /bin/install -c
>>> checking whether build environment is sane... yes
>>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>> checking for gawk... gawk
>>> checking whether make sets $(MAKE)... yes
>>> checking whether make supports nested variables... yes
>>> checking whether to enable maintainer-specific portions of Makefiles... yes
>>> checking for style of include used by make... GNU
>>> checking for gcc... gcc
>>> checking whether the C compiler works... yes
>>> checking for C compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... no
>>> checking for suffix of object files... o
>>> checking whether we are using the GNU C compiler... yes
>>> checking whether gcc accepts -g... yes
>>> checking for gcc option to accept ISO C89... none needed
>>> checking whether gcc understands -c and -o together... yes
>>> checking dependency style of gcc... gcc3
>>> checking for ar... ar
>>> checking the archiver (ar) interface... ar
>>> checking how to print strings... printf
>>> checking for a sed that does not truncate output... /bin/sed
>>> checking for grep that handles long lines and -e... /bin/grep
>>> checking for egrep... /bin/grep -E
>>> checking for fgrep... /bin/grep -F
>>> checking for ld used by gcc... /bin/ld
>>> checking if the linker (/bin/ld) is GNU ld... yes
>>> checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
>>> checking the name lister (/bin/nm -B) interface... BSD nm
>>> checking whether ln -s works... yes
>>> checking the maximum length of command line arguments... 1572864
>>> checking how to convert x86_64-unknown-linux-gnu file names to
>>> x86_64-unknown-linux-gnu format... func_convert_file_noop
>>> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
>>> format... func_convert_file_noop
>>> checking for /bin/ld option to reload object files... -r
>>> checking for objdump... objdump
>>> checking how to recognize dependent libraries... pass_all
>>> checking for dlltool... no
>>> checking how to associate runtime and link libraries... printf %s\n
>>> checking for g++... g++
>>> checking whether we are using the GNU C++ compiler... yes
>>> checking whether g++ accepts -g... yes
>>> checking dependency style of g++... gcc3
>>> checking for archiver @FILE support... @
>>> checking for strip... strip
>>> checking for ranlib... ranlib
>>> checking command to parse /bin/nm -B output from gcc object... ok
>>> checking for sysroot... no
>>> checking for a working dd... /bin/dd
>>> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
>>> checking for mt... no
>>> checking if : is a manifest tool... no
>>> checking how to run the C preprocessor... gcc -E
>>> checking for ANSI C header files... yes
>>> checking for sys/types.h... yes
>>> checking for sys/stat.h... yes
>>> checking for stdlib.h... yes
>>> checking for string.h... yes
>>> checking for memory.h... yes
>>> checking for strings.h... yes
>>> checking for inttypes.h... yes
>>> checking for stdint.h... yes
>>> checking for unistd.h... yes
>>> checking for dlfcn.h... yes
>>> checking for objdir... .libs
>>> checking if gcc supports -fno-rtti -fno-exceptions... no
>>> checking for gcc option to produce PIC... -fPIC -DPIC
>>> checking if gcc PIC flag -fPIC -DPIC works... yes
>>> checking if gcc static flag -static works... no
>>> checking if gcc supports -c -o file.o... yes
>>> checking if gcc supports -c -o file.o... (cached) yes
>>> checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared
>>> libraries... yes
>>> checking whether -lc should be explicitly linked in... no
>>> checking dynamic linker characteristics... GNU/Linux ld.so
>>> checking how to hardcode library paths into programs... immediate
>>> checking whether stripping libraries is possible... yes
>>> checking if libtool supports shared libraries... yes
>>> checking whether to build shared libraries... yes
>>> checking whether to build static libraries... no
>>> checking how to run the C++ preprocessor... g++ -E
>>> checking for ld used by g++... /bin/ld -m elf_x86_64
>>> checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
>>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>>> libraries... yes
>>> checking for g++ option to produce PIC... -fPIC -DPIC
>>> checking if g++ PIC flag -fPIC -DPIC works... yes
>>> checking if g++ static flag -static works... no
>>> checking if g++ supports -c -o file.o... yes
>>> checking if g++ supports -c -o file.o... (cached) yes
>>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>>> libraries... yes
>>> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>>> checking how to hardcode library paths into programs... immediate
>>> configure: creating ./config.lt
>>> config.lt: creating libtool
>>> configure: Setting up build environment for x86_64 linux-gnu
>>> checking whether we are using the GNU C++ compiler... (cached) yes
>>> checking whether g++ accepts -g... (cached) yes
>>> checking dependency style of g++... (cached) gcc3
>>> checking whether we are using the GNU C compiler... (cached) yes
>>> checking whether gcc accepts -g... (cached) yes
>>> checking for gcc option to accept ISO C89... (cached) none needed
>>> checking whether gcc understands -c and -o together... (cached) yes
>>> checking dependency style of gcc... (cached) gcc3
>>> checking whether ln -s works... yes
>>> checking for C++ compiler vendor... gnu
>>> checking for C++ compiler version... configure: error: in
>>> `/mnt/s3mnt/mesos/mesos-0.28.0/build':
>>> configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
>>> See `config.log' for more details
>
Re: source code compile failure mesos-0.28.0
Posted by Ali Aktar <al...@icloudinnovate.com>.
Hi;
All dependencies as per doc were installed. I’m using Centos 7:
Linux ip-172-31-46-249.eu-west-1.compute.internal 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
CentOS Linux release 7.2.1511 (Core)
Thanks
Ali.
On 21 Jun 2016, at 13:55, José Guilherme Vanz <gu...@gmail.com> wrote:
> Do you ensure that all dependencies described here:
> http://mesos.apache.org/documentation/latest/getting-started/ are
> installed? Furthermore, which Linux flavour are you using?
>
> Thanks
>
> On Tue, 21 Jun 2016 at 09:22 Ali Aktar <al...@icloudinnovate.com> wrote:
>
>> Hi;
>>
>> Can someone please help, I’m getting the following errors while running
>> ./configure:
>>
>> [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos
>> --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
>> checking build system type... x86_64-unknown-linux-gnu
>> checking host system type... x86_64-unknown-linux-gnu
>> checking target system type... x86_64-unknown-linux-gnu
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether make supports nested variables... yes
>> checking whether to enable maintainer-specific portions of Makefiles... yes
>> checking for style of include used by make... GNU
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking whether gcc understands -c and -o together... yes
>> checking dependency style of gcc... gcc3
>> checking for ar... ar
>> checking the archiver (ar) interface... ar
>> checking how to print strings... printf
>> checking for a sed that does not truncate output... /bin/sed
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking for fgrep... /bin/grep -F
>> checking for ld used by gcc... /bin/ld
>> checking if the linker (/bin/ld) is GNU ld... yes
>> checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
>> checking the name lister (/bin/nm -B) interface... BSD nm
>> checking whether ln -s works... yes
>> checking the maximum length of command line arguments... 1572864
>> checking how to convert x86_64-unknown-linux-gnu file names to
>> x86_64-unknown-linux-gnu format... func_convert_file_noop
>> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
>> format... func_convert_file_noop
>> checking for /bin/ld option to reload object files... -r
>> checking for objdump... objdump
>> checking how to recognize dependent libraries... pass_all
>> checking for dlltool... no
>> checking how to associate runtime and link libraries... printf %s\n
>> checking for g++... g++
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++ accepts -g... yes
>> checking dependency style of g++... gcc3
>> checking for archiver @FILE support... @
>> checking for strip... strip
>> checking for ranlib... ranlib
>> checking command to parse /bin/nm -B output from gcc object... ok
>> checking for sysroot... no
>> checking for a working dd... /bin/dd
>> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
>> checking for mt... no
>> checking if : is a manifest tool... no
>> checking how to run the C preprocessor... gcc -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking for dlfcn.h... yes
>> checking for objdir... .libs
>> checking if gcc supports -fno-rtti -fno-exceptions... no
>> checking for gcc option to produce PIC... -fPIC -DPIC
>> checking if gcc PIC flag -fPIC -DPIC works... yes
>> checking if gcc static flag -static works... no
>> checking if gcc supports -c -o file.o... yes
>> checking if gcc supports -c -o file.o... (cached) yes
>> checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared
>> libraries... yes
>> checking whether -lc should be explicitly linked in... no
>> checking dynamic linker characteristics... GNU/Linux ld.so
>> checking how to hardcode library paths into programs... immediate
>> checking whether stripping libraries is possible... yes
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... no
>> checking how to run the C++ preprocessor... g++ -E
>> checking for ld used by g++... /bin/ld -m elf_x86_64
>> checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>> libraries... yes
>> checking for g++ option to produce PIC... -fPIC -DPIC
>> checking if g++ PIC flag -fPIC -DPIC works... yes
>> checking if g++ static flag -static works... no
>> checking if g++ supports -c -o file.o... yes
>> checking if g++ supports -c -o file.o... (cached) yes
>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>> libraries... yes
>> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>> checking how to hardcode library paths into programs... immediate
>> configure: creating ./config.lt
>> config.lt: creating libtool
>> configure: Setting up build environment for x86_64 linux-gnu
>> checking whether we are using the GNU C++ compiler... (cached) yes
>> checking whether g++ accepts -g... (cached) yes
>> checking dependency style of g++... (cached) gcc3
>> checking whether we are using the GNU C compiler... (cached) yes
>> checking whether gcc accepts -g... (cached) yes
>> checking for gcc option to accept ISO C89... (cached) none needed
>> checking whether gcc understands -c and -o together... (cached) yes
>> checking dependency style of gcc... (cached) gcc3
>> checking whether ln -s works... yes
>> checking for C++ compiler vendor... gnu
>> checking for C++ compiler version... configure: error: in
>> `/mnt/s3mnt/mesos/mesos-0.28.0/build':
>> configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
>> See `config.log' for more details
Re: source code compile failure mesos-0.28.0
Posted by Ali Aktar <al...@icloudinnovate.com>.
Hi;
I’ve managed to solve it, the tar file for 0.28.0 is broken, incomplete, I hand’t noticed that, so I tried downloading 28.2. This has worked perfectly.
Many thanks
Ali.
On 21 Jun 2016, at 13:55, José Guilherme Vanz <gu...@gmail.com> wrote:
> Do you ensure that all dependencies described here:
> http://mesos.apache.org/documentation/latest/getting-started/ are
> installed? Furthermore, which Linux flavour are you using?
>
> Thanks
>
> On Tue, 21 Jun 2016 at 09:22 Ali Aktar <al...@icloudinnovate.com> wrote:
>
>> Hi;
>>
>> Can someone please help, I’m getting the following errors while running
>> ./configure:
>>
>> [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos
>> --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
>> checking build system type... x86_64-unknown-linux-gnu
>> checking host system type... x86_64-unknown-linux-gnu
>> checking target system type... x86_64-unknown-linux-gnu
>> checking for a BSD-compatible install... /bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether make supports nested variables... yes
>> checking whether to enable maintainer-specific portions of Makefiles... yes
>> checking for style of include used by make... GNU
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking whether gcc understands -c and -o together... yes
>> checking dependency style of gcc... gcc3
>> checking for ar... ar
>> checking the archiver (ar) interface... ar
>> checking how to print strings... printf
>> checking for a sed that does not truncate output... /bin/sed
>> checking for grep that handles long lines and -e... /bin/grep
>> checking for egrep... /bin/grep -E
>> checking for fgrep... /bin/grep -F
>> checking for ld used by gcc... /bin/ld
>> checking if the linker (/bin/ld) is GNU ld... yes
>> checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
>> checking the name lister (/bin/nm -B) interface... BSD nm
>> checking whether ln -s works... yes
>> checking the maximum length of command line arguments... 1572864
>> checking how to convert x86_64-unknown-linux-gnu file names to
>> x86_64-unknown-linux-gnu format... func_convert_file_noop
>> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
>> format... func_convert_file_noop
>> checking for /bin/ld option to reload object files... -r
>> checking for objdump... objdump
>> checking how to recognize dependent libraries... pass_all
>> checking for dlltool... no
>> checking how to associate runtime and link libraries... printf %s\n
>> checking for g++... g++
>> checking whether we are using the GNU C++ compiler... yes
>> checking whether g++ accepts -g... yes
>> checking dependency style of g++... gcc3
>> checking for archiver @FILE support... @
>> checking for strip... strip
>> checking for ranlib... ranlib
>> checking command to parse /bin/nm -B output from gcc object... ok
>> checking for sysroot... no
>> checking for a working dd... /bin/dd
>> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
>> checking for mt... no
>> checking if : is a manifest tool... no
>> checking how to run the C preprocessor... gcc -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking for dlfcn.h... yes
>> checking for objdir... .libs
>> checking if gcc supports -fno-rtti -fno-exceptions... no
>> checking for gcc option to produce PIC... -fPIC -DPIC
>> checking if gcc PIC flag -fPIC -DPIC works... yes
>> checking if gcc static flag -static works... no
>> checking if gcc supports -c -o file.o... yes
>> checking if gcc supports -c -o file.o... (cached) yes
>> checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared
>> libraries... yes
>> checking whether -lc should be explicitly linked in... no
>> checking dynamic linker characteristics... GNU/Linux ld.so
>> checking how to hardcode library paths into programs... immediate
>> checking whether stripping libraries is possible... yes
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... no
>> checking how to run the C++ preprocessor... g++ -E
>> checking for ld used by g++... /bin/ld -m elf_x86_64
>> checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>> libraries... yes
>> checking for g++ option to produce PIC... -fPIC -DPIC
>> checking if g++ PIC flag -fPIC -DPIC works... yes
>> checking if g++ static flag -static works... no
>> checking if g++ supports -c -o file.o... yes
>> checking if g++ supports -c -o file.o... (cached) yes
>> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>> libraries... yes
>> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>> checking how to hardcode library paths into programs... immediate
>> configure: creating ./config.lt
>> config.lt: creating libtool
>> configure: Setting up build environment for x86_64 linux-gnu
>> checking whether we are using the GNU C++ compiler... (cached) yes
>> checking whether g++ accepts -g... (cached) yes
>> checking dependency style of g++... (cached) gcc3
>> checking whether we are using the GNU C compiler... (cached) yes
>> checking whether gcc accepts -g... (cached) yes
>> checking for gcc option to accept ISO C89... (cached) none needed
>> checking whether gcc understands -c and -o together... (cached) yes
>> checking dependency style of gcc... (cached) gcc3
>> checking whether ln -s works... yes
>> checking for C++ compiler vendor... gnu
>> checking for C++ compiler version... configure: error: in
>> `/mnt/s3mnt/mesos/mesos-0.28.0/build':
>> configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
>> See `config.log' for more details
Re: source code compile failure mesos-0.28.0
Posted by José Guilherme Vanz <gu...@gmail.com>.
Do you ensure that all dependencies described here:
http://mesos.apache.org/documentation/latest/getting-started/ are
installed? Furthermore, which Linux flavour are you using?
Thanks
On Tue, 21 Jun 2016 at 09:22 Ali Aktar <al...@icloudinnovate.com> wrote:
> Hi;
>
> Can someone please help, I’m getting the following errors while running
> ./configure:
>
> [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos
> --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking for a BSD-compatible install... /bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... yes
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking for ar... ar
> checking the archiver (ar) interface... ar
> checking how to print strings... printf
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for ld used by gcc... /bin/ld
> checking if the linker (/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
> checking the name lister (/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 1572864
> checking how to convert x86_64-unknown-linux-gnu file names to
> x86_64-unknown-linux-gnu format... func_convert_file_noop
> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
> format... func_convert_file_noop
> checking for /bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for g++... g++
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking dependency style of g++... gcc3
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /bin/nm -B output from gcc object... ok
> checking for sysroot... no
> checking for a working dd... /bin/dd
> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
> checking for mt... no
> checking if : is a manifest tool... no
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -DPIC works... yes
> checking if gcc static flag -static works... no
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> checking how to run the C++ preprocessor... g++ -E
> checking for ld used by g++... /bin/ld -m elf_x86_64
> checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking for g++ option to produce PIC... -fPIC -DPIC
> checking if g++ PIC flag -fPIC -DPIC works... yes
> checking if g++ static flag -static works... no
> checking if g++ supports -c -o file.o... yes
> checking if g++ supports -c -o file.o... (cached) yes
> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> configure: creating ./config.lt
> config.lt: creating libtool
> configure: Setting up build environment for x86_64 linux-gnu
> checking whether we are using the GNU C++ compiler... (cached) yes
> checking whether g++ accepts -g... (cached) yes
> checking dependency style of g++... (cached) gcc3
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o together... (cached) yes
> checking dependency style of gcc... (cached) gcc3
> checking whether ln -s works... yes
> checking for C++ compiler vendor... gnu
> checking for C++ compiler version... configure: error: in
> `/mnt/s3mnt/mesos/mesos-0.28.0/build':
> configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
> See `config.log' for more details
Re: source code compile failure mesos-0.28.0
Posted by José Guilherme Vanz <gu...@gmail.com>.
Do you ensure that all dependencies described here:
http://mesos.apache.org/documentation/latest/getting-started/ are
installed? Furthermore, which Linux flavour are you using?
Thanks
On Tue, 21 Jun 2016 at 09:22 Ali Aktar <al...@icloudinnovate.com> wrote:
> Hi;
>
> Can someone please help, I’m getting the following errors while running
> ./configure:
>
> [root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos
> --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking for a BSD-compatible install... /bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... yes
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking for ar... ar
> checking the archiver (ar) interface... ar
> checking how to print strings... printf
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for ld used by gcc... /bin/ld
> checking if the linker (/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
> checking the name lister (/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 1572864
> checking how to convert x86_64-unknown-linux-gnu file names to
> x86_64-unknown-linux-gnu format... func_convert_file_noop
> checking how to convert x86_64-unknown-linux-gnu file names to toolchain
> format... func_convert_file_noop
> checking for /bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for g++... g++
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking dependency style of g++... gcc3
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /bin/nm -B output from gcc object... ok
> checking for sysroot... no
> checking for a working dd... /bin/dd
> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
> checking for mt... no
> checking if : is a manifest tool... no
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -DPIC works... yes
> checking if gcc static flag -static works... no
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> checking how to run the C++ preprocessor... g++ -E
> checking for ld used by g++... /bin/ld -m elf_x86_64
> checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking for g++ option to produce PIC... -fPIC -DPIC
> checking if g++ PIC flag -fPIC -DPIC works... yes
> checking if g++ static flag -static works... no
> checking if g++ supports -c -o file.o... yes
> checking if g++ supports -c -o file.o... (cached) yes
> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> configure: creating ./config.lt
> config.lt: creating libtool
> configure: Setting up build environment for x86_64 linux-gnu
> checking whether we are using the GNU C++ compiler... (cached) yes
> checking whether g++ accepts -g... (cached) yes
> checking dependency style of g++... (cached) gcc3
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o together... (cached) yes
> checking dependency style of gcc... (cached) gcc3
> checking whether ln -s works... yes
> checking for C++ compiler vendor... gnu
> checking for C++ compiler version... configure: error: in
> `/mnt/s3mnt/mesos/mesos-0.28.0/build':
> configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
> See `config.log' for more details
Re: source code compile failure mesos-0.28.0
Posted by Ali Aktar <al...@icloudinnovate.com>.
Hi;
Can someone please help, I’m getting the following errors while running ./configure:
[root@ip-172-31-46-249 build]# ../configure --prefix=/mnt/s3mnt/mesos --exec-prefix=/mnt/s3mnt/mesos --datadir=/mnt/s3mnt/mesos
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
checking the name lister (/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /bin/ld -m elf_x86_64
checking if the linker (/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
configure: creating ./config.lt
config.lt: creating libtool
configure: Setting up build environment for x86_64 linux-gnu
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking whether ln -s works... yes
checking for C++ compiler vendor... gnu
checking for C++ compiler version... configure: error: in `/mnt/s3mnt/mesos/mesos-0.28.0/build':
configure: error: _AX_COMPILER_VERSION_GNU unknown gcc major
See `config.log' for more details
Re: Persistent volume ownership issue
Posted by Anindya Sinha <an...@gmail.com>.
Currently the volume is owned by say framework user A when a CREATE is done. When a task is launched, the ownership of the volume is changed recursively to say user B, which means the root directory and all of its content has now ownership of user B. This enables user B to write into this persistent volume but as a result it changes ownership of all existing contents of persistent volume to user B as well.
I think change just changes ownership of the root directory to user B but keeps the ownership of the existing content of persistent volume to user A. This would still allow the task to write onto the persistent volume as user B (at least at root level) but not allow existing content to be deleted or overwritten that is owned by a lower privileged user.
I think this would work and would restrict lower privileged user to not modify contents of higher privileged users.
Thanks
Anindya
> On Jun 21, 2016, at 5:07 AM, Joris Van Remoortere <jo...@mesosphere.io> wrote:
>
> For the case where a container drops down in privileges and still wants to
> create a new file, this will result in an error if it is at the root of the
> persistent volume right?
>
> Is the recommended pattern then to always create a stub directory at the
> root of the persistent volume, and then launch any lower privileged apps
> underneath that? For example:
>
> / <- Root of persistent volume (Owned by framework user / root)
> /Database/ <- Stub directory (Owned by lower privileged user)
>
> All new files by the lower privileged app must be created under /Database/*
> ?
> It would result in an error if the App tried to create /Database-backups/ ?
> Only the framework as its original user would be able to do that?
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
>> On Tue, Jun 21, 2016 at 8:25 AM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Hi folks,
>>
>> Currently, the ownership of the persistent volumes are set to be the same
>> as the sandbox. In the implementation, we call `chown -R` on the persistent
>> volume to match that of the sandbox each time before we mount it into the
>> container.
>>
>> Recently, we realized that this behavior is not ideal. Especially, if a
>> task created some files in the persistent volume, and the owner of those
>> file might be different than the task's user. For instance, a task is
>> running under root and it creates some database files under user 'database'
>> and launch the database process under user 'database'. When the database
>> process is restarted by the scheduler, the current behavior is that the
>> we'll do a 'chown -R root.root' on the persistent volume, causes database
>> files to be chown to 'root'.
>>
>> The true fix of this problem is to allow frameworks to explicit specify
>> owner of persistent volumes during creation. THis is captured in this
>> ticket:
>> https://issues.apache.org/jira/browse/MESOS-4893
>>
>> In the short-term (for 1.0), I propose that, instead of doing a recursive
>> chown, we do a non-recursive chown. That'll allow the new task to at least
>> create new files under the persistent volume, but do not change ownership
>> of files created by previous tasks. It should be a very simple fix which we
>> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>>
>> Thanks,
>> - Jie
>>
Re: Persistent volume ownership issue
Posted by Joris Van Remoortere <jo...@mesosphere.io>.
For the case where a container drops down in privileges and still wants to
create a new file, this will result in an error if it is at the root of the
persistent volume right?
Is the recommended pattern then to always create a stub directory at the
root of the persistent volume, and then launch any lower privileged apps
underneath that? For example:
/ <- Root of persistent volume (Owned by framework user / root)
/Database/ <- Stub directory (Owned by lower privileged user)
All new files by the lower privileged app must be created under /Database/*
?
It would result in an error if the App tried to create /Database-backups/ ?
Only the framework as its original user would be able to do that?
—
*Joris Van Remoortere*
Mesosphere
On Tue, Jun 21, 2016 at 8:25 AM, Jie Yu <yu...@gmail.com> wrote:
> Hi folks,
>
> Currently, the ownership of the persistent volumes are set to be the same
> as the sandbox. In the implementation, we call `chown -R` on the persistent
> volume to match that of the sandbox each time before we mount it into the
> container.
>
> Recently, we realized that this behavior is not ideal. Especially, if a
> task created some files in the persistent volume, and the owner of those
> file might be different than the task's user. For instance, a task is
> running under root and it creates some database files under user 'database'
> and launch the database process under user 'database'. When the database
> process is restarted by the scheduler, the current behavior is that the
> we'll do a 'chown -R root.root' on the persistent volume, causes database
> files to be chown to 'root'.
>
> The true fix of this problem is to allow frameworks to explicit specify
> owner of persistent volumes during creation. THis is captured in this
> ticket:
> https://issues.apache.org/jira/browse/MESOS-4893
>
> In the short-term (for 1.0), I propose that, instead of doing a recursive
> chown, we do a non-recursive chown. That'll allow the new task to at least
> create new files under the persistent volume, but do not change ownership
> of files created by previous tasks. It should be a very simple fix which we
> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>
> Thanks,
> - Jie
>
Re: Persistent volume ownership issue
Posted by Joris Van Remoortere <jo...@mesosphere.io>.
For the case where a container drops down in privileges and still wants to
create a new file, this will result in an error if it is at the root of the
persistent volume right?
Is the recommended pattern then to always create a stub directory at the
root of the persistent volume, and then launch any lower privileged apps
underneath that? For example:
/ <- Root of persistent volume (Owned by framework user / root)
/Database/ <- Stub directory (Owned by lower privileged user)
All new files by the lower privileged app must be created under /Database/*
?
It would result in an error if the App tried to create /Database-backups/ ?
Only the framework as its original user would be able to do that?
—
*Joris Van Remoortere*
Mesosphere
On Tue, Jun 21, 2016 at 8:25 AM, Jie Yu <yu...@gmail.com> wrote:
> Hi folks,
>
> Currently, the ownership of the persistent volumes are set to be the same
> as the sandbox. In the implementation, we call `chown -R` on the persistent
> volume to match that of the sandbox each time before we mount it into the
> container.
>
> Recently, we realized that this behavior is not ideal. Especially, if a
> task created some files in the persistent volume, and the owner of those
> file might be different than the task's user. For instance, a task is
> running under root and it creates some database files under user 'database'
> and launch the database process under user 'database'. When the database
> process is restarted by the scheduler, the current behavior is that the
> we'll do a 'chown -R root.root' on the persistent volume, causes database
> files to be chown to 'root'.
>
> The true fix of this problem is to allow frameworks to explicit specify
> owner of persistent volumes during creation. THis is captured in this
> ticket:
> https://issues.apache.org/jira/browse/MESOS-4893
>
> In the short-term (for 1.0), I propose that, instead of doing a recursive
> chown, we do a non-recursive chown. That'll allow the new task to at least
> create new files under the persistent volume, but do not change ownership
> of files created by previous tasks. It should be a very simple fix which we
> can ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>
> Thanks,
> - Jie
>
Re: Persistent volume ownership issue
Posted by James Peach <jo...@gmail.com>.
On 21 June 2016 at 12:25, Jie Yu <yu...@gmail.com> wrote:
> James, sticky bit means that there will be no write sharing between two
> users even if the underlying permission allows it. I'd prefer not having
> this restriction:)
No, it just prevents users renaming or deleting each others files.
http://man7.org/linux/man-pages/man1/chmod.1.html
If you want multiple users to be able to write to the same files, they
need to create with the right ownership.
>> I wonder whether ACLs are the right solution to volume ownership?
>> Certainly I think inherited ACLs are a good solution for expressing a
>> consistent access control policy over a hierarchy (at least in the
>> Windows/Darwin/SMB/NFSv4/RichAcl ACL model).
>
>
> Are you suggesting that we don't expose the underlying unix user directly to
> frameworks. Instead, expressing permissions and ownerships using ACLs?
Well that could be an option, though I'm mainly thinking out loud.
With shared volumes, it seems like you really want an access control
policy that applies to the volume, rather than requiring processes to
collaborate at a file granularity. One way to do that would be to make
the owner the creator of the volume, then use ACL inheritance to grant
additional access to other users. You'd have to reflow the
inheritance, but it could probably done.
--
James Peach | jorgar@gmail.com
Re: Persistent volume ownership issue
Posted by Jie Yu <yu...@gmail.com>.
I created https://issues.apache.org/jira/browse/MESOS-5680 to track.
Since this is no objection, we'll make sure the fix go into 1.0.
- Jie
On Tue, Jun 21, 2016 at 12:25 PM, Jie Yu <yu...@gmail.com> wrote:
> James, sticky bit means that there will be no write sharing between two
> users even if the underlying permission allows it. I'd prefer not having
> this restriction:)
>
> I wonder whether ACLs are the right solution to volume ownership?
>> Certainly I think inherited ACLs are a good solution for expressing a
>> consistent access control policy over a hierarchy (at least in the
>> Windows/Darwin/SMB/NFSv4/RichAcl ACL model).
>
>
> Are you suggesting that we don't expose the underlying unix user directly
> to frameworks. Instead, expressing permissions and ownerships using ACLs?
>
> - Jie
>
> On Tue, Jun 21, 2016 at 9:00 AM, James Peach <jo...@gmail.com> wrote:
>
>> Non-recursive chown is an improvement over recursive chown which seems
>> fraught and should be avoided. For an interim fix, could you make the
>> volume root world writeable with the sticky bit set? Then you wouldn't
>> have to chown and volume users would still be able to create files.
>>
>> I wonder whether ACLs are the right solution to volume ownership?
>> Certainly I think inherited ACLs are a good solution for expressing a
>> consistent access control policy over a hierarchy (at least in the
>> Windows/Darwin/SMB/NFSv4/RichAcl ACL model).
>>
>> On 20 June 2016 at 23:25, Jie Yu <yu...@gmail.com> wrote:
>> > Hi folks,
>> >
>> > Currently, the ownership of the persistent volumes are set to be the
>> same as
>> > the sandbox. In the implementation, we call `chown -R` on the persistent
>> > volume to match that of the sandbox each time before we mount it into
>> the
>> > container.
>> >
>> > Recently, we realized that this behavior is not ideal. Especially, if a
>> task
>> > created some files in the persistent volume, and the owner of those file
>> > might be different than the task's user. For instance, a task is running
>> > under root and it creates some database files under user 'database' and
>> > launch the database process under user 'database'. When the database
>> process
>> > is restarted by the scheduler, the current behavior is that the we'll
>> do a
>> > 'chown -R root.root' on the persistent volume, causes database files to
>> be
>> > chown to 'root'.
>> >
>> > The true fix of this problem is to allow frameworks to explicit specify
>> > owner of persistent volumes during creation. THis is captured in this
>> > ticket:
>> > https://issues.apache.org/jira/browse/MESOS-4893
>> >
>> > In the short-term (for 1.0), I propose that, instead of doing a
>> recursive
>> > chown, we do a non-recursive chown. That'll allow the new task to at
>> least
>> > create new files under the persistent volume, but do not change
>> ownership of
>> > files created by previous tasks. It should be a very simple fix which
>> we can
>> > ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>> >
>> > Thanks,
>> > - Jie
>>
>>
>>
>> --
>> James Peach | jorgar@gmail.com
>>
>
>
Re: Persistent volume ownership issue
Posted by Jie Yu <yu...@gmail.com>.
James, sticky bit means that there will be no write sharing between two
users even if the underlying permission allows it. I'd prefer not having
this restriction:)
I wonder whether ACLs are the right solution to volume ownership?
> Certainly I think inherited ACLs are a good solution for expressing a
> consistent access control policy over a hierarchy (at least in the
> Windows/Darwin/SMB/NFSv4/RichAcl ACL model).
Are you suggesting that we don't expose the underlying unix user directly
to frameworks. Instead, expressing permissions and ownerships using ACLs?
- Jie
On Tue, Jun 21, 2016 at 9:00 AM, James Peach <jo...@gmail.com> wrote:
> Non-recursive chown is an improvement over recursive chown which seems
> fraught and should be avoided. For an interim fix, could you make the
> volume root world writeable with the sticky bit set? Then you wouldn't
> have to chown and volume users would still be able to create files.
>
> I wonder whether ACLs are the right solution to volume ownership?
> Certainly I think inherited ACLs are a good solution for expressing a
> consistent access control policy over a hierarchy (at least in the
> Windows/Darwin/SMB/NFSv4/RichAcl ACL model).
>
> On 20 June 2016 at 23:25, Jie Yu <yu...@gmail.com> wrote:
> > Hi folks,
> >
> > Currently, the ownership of the persistent volumes are set to be the
> same as
> > the sandbox. In the implementation, we call `chown -R` on the persistent
> > volume to match that of the sandbox each time before we mount it into the
> > container.
> >
> > Recently, we realized that this behavior is not ideal. Especially, if a
> task
> > created some files in the persistent volume, and the owner of those file
> > might be different than the task's user. For instance, a task is running
> > under root and it creates some database files under user 'database' and
> > launch the database process under user 'database'. When the database
> process
> > is restarted by the scheduler, the current behavior is that the we'll do
> a
> > 'chown -R root.root' on the persistent volume, causes database files to
> be
> > chown to 'root'.
> >
> > The true fix of this problem is to allow frameworks to explicit specify
> > owner of persistent volumes during creation. THis is captured in this
> > ticket:
> > https://issues.apache.org/jira/browse/MESOS-4893
> >
> > In the short-term (for 1.0), I propose that, instead of doing a recursive
> > chown, we do a non-recursive chown. That'll allow the new task to at
> least
> > create new files under the persistent volume, but do not change
> ownership of
> > files created by previous tasks. It should be a very simple fix which we
> can
> > ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
> >
> > Thanks,
> > - Jie
>
>
>
> --
> James Peach | jorgar@gmail.com
>
Re: Persistent volume ownership issue
Posted by James Peach <jo...@gmail.com>.
Non-recursive chown is an improvement over recursive chown which seems
fraught and should be avoided. For an interim fix, could you make the
volume root world writeable with the sticky bit set? Then you wouldn't
have to chown and volume users would still be able to create files.
I wonder whether ACLs are the right solution to volume ownership?
Certainly I think inherited ACLs are a good solution for expressing a
consistent access control policy over a hierarchy (at least in the
Windows/Darwin/SMB/NFSv4/RichAcl ACL model).
On 20 June 2016 at 23:25, Jie Yu <yu...@gmail.com> wrote:
> Hi folks,
>
> Currently, the ownership of the persistent volumes are set to be the same as
> the sandbox. In the implementation, we call `chown -R` on the persistent
> volume to match that of the sandbox each time before we mount it into the
> container.
>
> Recently, we realized that this behavior is not ideal. Especially, if a task
> created some files in the persistent volume, and the owner of those file
> might be different than the task's user. For instance, a task is running
> under root and it creates some database files under user 'database' and
> launch the database process under user 'database'. When the database process
> is restarted by the scheduler, the current behavior is that the we'll do a
> 'chown -R root.root' on the persistent volume, causes database files to be
> chown to 'root'.
>
> The true fix of this problem is to allow frameworks to explicit specify
> owner of persistent volumes during creation. THis is captured in this
> ticket:
> https://issues.apache.org/jira/browse/MESOS-4893
>
> In the short-term (for 1.0), I propose that, instead of doing a recursive
> chown, we do a non-recursive chown. That'll allow the new task to at least
> create new files under the persistent volume, but do not change ownership of
> files created by previous tasks. It should be a very simple fix which we can
> ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think?
>
> Thanks,
> - Jie
--
James Peach | jorgar@gmail.com