Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux Support #71

Open
philipnewcomer opened this issue Jul 7, 2017 · 8 comments
Open

Linux Support #71

philipnewcomer opened this issue Jul 7, 2017 · 8 comments
Assignees
Milestone

Comments

@philipnewcomer
Copy link
Member

Need to test Pilothouse on Linux systems and resolve any incompatibilities, after converting PH to NodeJS (#68).

@philipnewcomer philipnewcomer added this to the 1.0 milestone Jul 7, 2017
@philipnewcomer philipnewcomer self-assigned this Jul 7, 2017
@Faison
Copy link
Contributor

Faison commented Dec 17, 2018

Hi @philipnewcomer ,

I'm working on setting this up on Linux Mint 18.1. I'll let you know how it goes and if I needed to do anything strange to get it to work.

@Faison
Copy link
Contributor

Faison commented Dec 18, 2018

Just documenting a couple of things I'm working on troubleshooting:


When running pilothouse up. I'm first asked to enter my password, then two weird messages show up before docker starts up the containers:

sudo: security: command not found
sudo: security: command not found
Starting f260904477a1_pilothouse_php71-xdebug_1_e6c6d68ed2ec ... done

I haven't determined what's causing this yet.


When running pilothouse create, choosing wordpress, php 7.2, object cache on, and no repo for the wp-content directory, I get a permissions error:

Error: '/var/www/html/sites/<site>/htdocs/' is not writable by current user.
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.
(node:17107) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/home/<user>/Sites/<site>/htdocs/wp-content/object-cache.php'
    at Object.openSync (fs.js:439:3)
    at Object.writeFileSync (fs.js:1190:35)
    at Object.createSite (/home/<user>/repos/Pilothouse/utils/sites.js:229:7)
    at /home/<user>/repos/Pilothouse/commands/create.js:168:14
(node:17107) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejec
tion id: 1)
(node:17107) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Something I read last night was saying that the docker user for the container isn't in the same group as the docker user that created the docker container, but I didn't have a lot of time to look into that yet.

@Faison
Copy link
Contributor

Faison commented Dec 18, 2018

Hi @philipnewcomer ,

Looks like the first issue I had (the sudo: security: command not found message) is caused in commands.regenerateHTTPSCertificate(). You're using the OSX command security, which linux doesn't have. Are you adding self-signed certs to the OSX keychain in order to make the SSL cert trusted by the computer?

@philipnewcomer
Copy link
Member Author

@Faison thanks for tackling this issue.

You are correct that the error about the security command is occurring because we're trying to add the certificate to the macOS keychain, which obviously doesn't exist on Linux. As part of Linux support, we'll need to determine whether there is some sort of an equivalent of the macOS keychain or a global certificate store which we can add the generated certificate to instead.

Regarding the file permissions error, only certain directories from the host can be bind mounted into the Docker containers. On macOS, /Users is one of those default whitelisted directories so Pilothouse works out-of-the-box when the sites directory is inside a user directory, which it generally is. I suspect there may be a similar setting on Linux, where only directories inside a user directory can be mounted. I noticed in your log that your sites directory is /var/www/html/sites/, and I suspect that it would work if either 1) the /var/www directory was whitelisted in the Docker settings, or 2) the sites directory was located somewhere inside your home directory. On macOS, you can whitelist additional directories on the File Sharing tab of the Docker settings panel; I don't know if you have those same settings on Linux or not.

@Faison
Copy link
Contributor

Faison commented Dec 19, 2018

@philipnewcomer Thank you for the direction on the file permissions error, I'll look to see if there's a directory that just works for Linux. As for the directory /var/www/html/sites/, that's the directory in the docker container. The docker-compose.yml file has this in its list of volumes:

- "/home/<user>/Sites:/var/www/html/sites/"

I also pointed pilothouse to another directory further in my home directory, but without any success.

Could you add a screenshot of what the directory whitelist in the Docker for Mac settings look like? Might give me a good idea of what I need to look for.

Related to this, I was setting up another project that uses docker with docker-machine. In that, I had to do some fancy stuff where I map a directory on my host machine to /Users on the VM that docker-machine uses. Then manually hop in and create a symlink between /Users and some other directory. (All detailed here, probably not too relevant for pilothouse though).

@philipnewcomer
Copy link
Member Author

@Faison here's the screenshot of the Docker sharing settings on macOS:
screen shot 2018-12-20 at 8 19 54 pm

@Faison
Copy link
Contributor

Faison commented Dec 21, 2018

@philipnewcomer So it looks like there's a fancy directory sharing feature specific for OSX, which is likely why this just works for Mac and not for Linux. I tried a bunch of stuff with no luck.

But I did another search and found that 10up dealt with the issue on Linux in a few months ago: 10up/wp-local-docker-images@d51e31d

I'm going to work on seeing if I can adapt those changes into pilothouse and get it working on my computer.

@Faison
Copy link
Contributor

Faison commented Jan 2, 2019

@philipnewcomer So I determined the issue. I was trying to run pilothouse in a directory that is a part of a mounted drive. Turns out docker on linux would do shared drives properly if the directory is in a mounted drive.

Unfortunately, pilothouse still failed in a normal directory, but the 10up docker thing worked. It might be related to using alpine as the base image.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants