LSST Stack 'on Ubuntu Linux on Windows'

windows
symlink
stack-install
Tags: #<Tag:0x00007f7f728f5068> #<Tag:0x00007f7f728f4de8> #<Tag:0x00007f7f728f4820>

(frossie) #21

@mjuric Well, I am not immune to the coolness (craziness?) factor here, but I’m pretty swamped and would have to do redo some testing so… [now watch for this stunning punting manouver down the left flank in slow mo…] if @timj can manage to do the honours succesfully tomorrow while I’m LDM-151ing, why the heck not.

Erm, and nobody tell @jbecla.


(Tim Jenness) #22

I can definitely make it so that mariadb and mariadbclient always use bundled libz and libssl. Is @josh going to object? Regardless, I can make the ticket and send it for review quick enough so that people can decide.


Binary distribution of v12.0.rc1 available via CernVM FS but there are issues
(Tim Jenness) #23

I’ve adjusted DM-5802 to use bundled SSL and ZLIB in mariadbclient. I’ll now make the identical change to mariadb.


(Tim Jenness) #24

Whilst I’m confident this will work fine (I’ve done a Jenkins build and OS X build). Who is going to check that this fixes the problem described here?


(josh) #25

Yes. :slight_smile: libssl averages around two vulnerabilities per month. Has anyone confirmed that the mariadb ssl symbols are not exported?


(Joachim Moeyens) #26

Jupyter notebooks don’t work with the current WSL build. (See: WSL Issue 185 and Jupyter Notebook Issue 1331) There is a potential workaround but the fix would be better if implemented by Microsoft developers. Fear not however, I shall accept your challenge when the time is right.

If someone was willing to guide me through the process I could and would be happy to test any fixes.


(Tim Jenness) #27

It doesn’t seem like we can resolve the MariaDB SSL issue in a timely manner that would allow it to squeeze into the release of 12.0. No one solution is liked by everyone (bundled SSL, stripping $PATH, adding conda library location to LD_LIBRARY_PATH).


(Tim Jenness) #28

For the record so far our options for fixing have been:

  • Giving cmake an exclusion path.
    • We currently try to ignore the library directory relative to the bin directory containing the python we are using. I’m not entirely sure why this isn’t working on ubuntu.
    • This didn’t work when conda builds were done because there are two conda paths in the PATH with libssl. A patch to fix this and include both paths does exist but not pushed anywhere.
  • Limiting the PATH available to cmake so that it won’t find the wrong libssl.
    • This was thrown out as unreliable (and possibly wouldn’t even work on conda installs that have their own GCC in the conda path.
  • Giving up and using the bundled SSL (and ZLIB).
    • This will obviously fix everything with the caveat that you won’t get security patches without updating MariaDB.
    • Lack of security patches is fine if we don’t ever use SSL in MariaDB but I don’t know enough about Qserv to know if that is right. @fritzm?

Of course, a case could be made that we should absolutely be using the conda libssl as it’s updated far more often than the system one. In that case we are approaching this from the wrong direction and should be working out how to put the conda library paths into LD_LIBRARY_PATH and how to get the build to use it explicitly.


(Mario Juric) #29

For the adventurous: https://blogs.msdn.microsoft.com/commandline/2017/07/28/windows-subsystem-for-linux-out-of-beta/