Change Details

This may or may not be much of a task, just making some notes about setup issues on my new less-explodey laptop. Most of these problems are of my own making because I didn't read the setup instructions I wrote. (I also got the old one fixed and it is no longer an explosion risk.) --- **Cache** I get this junk when trying to access an instance: > Unable to open lock '/Users/epriestley/dev/core/tmp/cache/cluster/locala._www.almanac.cache.lock' for writing! This is because of user account vs apache permission issues. I might get rid of this cache (at least partly?) as part of caching changes in T13076, if we're lucky. As a workaround, I created this file and `chmod 666`'d it. This isn't great. Another alternative is maybe letting a temporary directory be configured, and just using `<system temp dir>/phacility` on local installs. We use `/core/tmp` instead of `/tmp` in production to keep the data off the tiny `/` mount. I think "not reading" also comes into play here. The official instructions say to `chmod o+w` the `tmp` directory. It would be nice to find a cleaner fix for this but I'm punting until after cache changes in T13076. **Conduit Public Key** I skipped the actual setup instructions and hit this: ``` ERR-INVALID-AUTH: No user or device is associated with that public key. ``` This could be a little more helpful by showing the public key, which is public. I also think I don't have a public key configured? Let me see... Following the instructions (creating `@instance-client` and adding the right key) fixed this.

This may or may not be much of a task, just making some notes about setup issues on my new less-explodey laptop. Most of these problems are of my own making because I didn't read the setup instructions I wrote. (I also got the old one fixed and it is no longer an explosion risk.) --- **Cache** I get this junk when trying to access an instance: > Unable to open lock '/Users/epriestley/dev/core/tmp/cache/cluster/locala._www.almanac.cache.lock' for writing! This is because of user account vs apache permission issues. I might get rid of this cache (at least partly?) as part of caching changes in T13076, if we're lucky. As a workaround, I created this file and `chmod 666`'d it. This isn't great. Another alternative is maybe letting a temporary directory be configured, and just using `<system temp dir>/phacility` on local installs. We use `/core/tmp` instead of `/tmp` in production to keep the data off the tiny `/` mount. I think "not reading" also comes into play here. The official instructions say to `chmod o+w` the `tmp` directory. It would be nice to find a cleaner fix for this but I'm punting until after cache changes in T13076. **Conduit Public Key** I skipped the actual setup instructions and hit this: ``` ERR-INVALID-AUTH: No user or device is associated with that public key. ``` This could be a little more helpful by showing the public key, which is public. I also think I don't have a public key configured? Let me see... Following the instructions (creating `@instance-client` and adding the right key) fixed this. **pcntl** The default version of PHP on macOS doesn't have `pcntl` so you can't start the daemons. I don't think we can handle signals without this and we realistically need to handle signals. So we must choose among three great evils: # Put `brew` on the machine. # Build PHP from source with `--enable-pcntl` or whatever? # Build just the extension from source? I'll try (3) and then probably give up and install `brew` if that doesn't pan out since I haven't actually needed to build `php` recently and approaches (3) and (1) both fight with the macOS version of PHP.

This may or may not be much of a task, just making some notes about setup issues on my new less-explodey laptop. Most of these problems are of my own making because I didn't read the setup instructions I wrote. (I also got the old one fixed and it is no longer an explosion risk.) --- **Cache** I get this junk when trying to access an instance: > Unable to open lock '/Users/epriestley/dev/core/tmp/cache/cluster/locala._www.almanac.cache.lock' for writing! This is because of user account vs apache permission issues. I might get rid of this cache (at least partly?) as part of caching changes in T13076, if we're lucky. As a workaround, I created this file and `chmod 666`'d it. This isn't great. Another alternative is maybe letting a temporary directory be configured, and just using `<system temp dir>/phacility` on local installs. We use `/core/tmp` instead of `/tmp` in production to keep the data off the tiny `/` mount. I think "not reading" also comes into play here. The official instructions say to `chmod o+w` the `tmp` directory. It would be nice to find a cleaner fix for this but I'm punting until after cache changes in T13076. **Conduit Public Key** I skipped the actual setup instructions and hit this: ``` ERR-INVALID-AUTH: No user or device is associated with that public key. ``` This could be a little more helpful by showing the public key, which is public. I also think I don't have a public key configured? Let me see... Following the instructions (creating `@instance-client` and adding the right key) fixed this. **pcntl** The default version of PHP on macOS doesn't have `pcntl` so you can't start the daemons. I don't think we can handle signals without this and we realistically need to handle signals. So we must choose among three great evils: # Put `brew` on the machine. # Build PHP from source with `--enable-pcntl` or whatever? # Build just the extension from source? I'll try (3) and then probably give up and install `brew` if that doesn't pan out since I haven't actually needed to build `php` recently and approaches (3) and (1) both fight with the macOS version of PHP.