Skip WP installation about wordpress-nginx-nix

[3noch]

@niklaswallerstedt It would most certainly be possible. The only trouble is I'm not exactly sure how to do it. My assumption is that these fields are in the WP database. So we'd have to pre-configure the database without WordPress building it for us.

Perhaps some of these fields could be set in wp-config?

Let me know if you have ideas.

[3noch]

That's a pretty neat project for WordPress, BTW. I'd love to have at least some of those features here.

You can use this setup to pre-install plugins and themes. If the freeze* settings are all true, then you can actually use nix to control WordPress installation, plugins, and themes after the site is up and running. But in that case nix is in total control and you cannot install them via the admin panel. If freeze* is false then it can set them up on first install, but after that you must control things from the admin panel. The benefit of freezing things is that you can create VirtualBox deployments and staging sites very easily that have the exact same configuration as your production site.

Multilanguage support is also easily possible; I just didn't have a need for it.

[niklaswallerstedt]

@3noch I've been thinking about this and I discovered that wp-cli is available as a nix package. Works well! Given that wordpress has embraced it that might be a way to do it. I added it to environment.systemPackages.

And the freeze setting disallows wp-cli from installing anything, but activation works and I presume wp core setup as well (haven't tried that yet though). It complains running as root, so it has to be run with wp <command> --allow-root

[3noch]

@niklaswallerstedt Great find! I believe you can use something like this to run commands on startup:

{ # somewhere in logical.nix
  system.activationScripts.setupWp = ''
    ${wp-cli}/bin/wp-cli ...
  '';
}

You'd certainly want to have some sort of check to make sure you're not overwriting anything, but the approach is the point.

[3noch]

@niklaswallerstedt Just curious if you've had any success using wp-cli to get a fully automated setup?

[niklaswallerstedt]

@3noch Yes and no, I can get wp-cli to run on startup as you described. The installation works if the machine is already built, but if I destroy the deployment and run it again there's a problem connecting to the database. From the logs it seems that the mysql service gets started after wp-cli runs. I'll paste in some logs below.

Two things I've not been able to figure out.

1. How do I reference the path to wordpress in the nix store in a convenient way? I've been hardcoding it (--path="/nix/store/a44yx4vasgn48zbzgnd8fqh4nvnlc8y1-wordpress-app/") for these examples.
2. I get this during a successful install sh: -t: command not found. Sendmail_path is in your logical.nix, but maybe this is the same issue with the startup order like mysql. Reference.

I'll continue to tinker with it :)

{
system.activationScripts.setupWp = ''
    ${pkgs.wp-cli}/bin/wp cli version --debug --allow-root
    '';
}

wordpress-main> Debug (bootstrap): Running command: cli version (0.059s)
wordpress-main> WP-CLI 1.0.0

{
system.activationScripts.setupWp = ''
    ${pkgs.wp-cli}/bin/wp core install --url=testsite.dev --title=Testsite \
    --admin_user=superadmin --admin_password=strongpassword [email protected] \
    --path="/nix/store/a44yx4vasgn48zbzgnd8fqh4nvnlc8y1-wordpress-app/" \
    --debug --allow-root
    '';
}

deploy/manage vbox deploy

1st run

wordpress-main> Debug (bootstrap): ABSPATH defined: /nix/store/a44yx4vasgn48zbzgnd8fqh4nvnlc8y1-wordpress-app/ (0.051s)
wordpress-main> Debug (bootstrap): Set URL: testsite.dev (0.052s)
wordpress-main> Debug (bootstrap): Begin WordPress load (0.052s)
wordpress-main> Debug (bootstrap): wp-config.php path: /nix/store/760wjn88hmb9d7f0b60978g140rflk83-wp-config.php (0.052s)
wordpress-main> Debug (bootstrap): Loaded WordPress (0.213s)
wordpress-main> Debug (bootstrap): Running command: core install (0.213s)
wordpress-main> Success: WordPress installed successfully.
wordpress-main> sh: -t: command not found <-- Not sure where this is coming from

2nd run

wordpress-main> Debug (bootstrap): ABSPATH defined: /nix/store/a44yx4vasgn48zbzgnd8fqh4nvnlc8y1-wordpress-app/ (0.04s)
wordpress-main> Debug (bootstrap): Set URL: testsite.dev (0.041s)
wordpress-main> Debug (bootstrap): Begin WordPress load (0.041s)
wordpress-main> Debug (bootstrap): wp-config.php path: /nix/store/760wjn88hmb9d7f0b60978g140rflk83-wp-config.php (0.041s)
wordpress-main> Debug (bootstrap): Loaded WordPress (0.182s)
wordpress-main> Debug (bootstrap): Running command: core install (0.183s)
wordpress-main> WordPress is already installed.

deploy/manage vbox destroy --confirm
deploy/manage vbox deploy

wordpress-main> copying closure...
vbox> closures copied successfully
wordpress-main> updating GRUB 2 menu...
wordpress-main> stopping the following units: alsa-store.service, audit.service, kmod-static-nodes.service, network-local-commands.service, network-setup.service, nix-daemon.service, nix-daemon.socket, nscd.service, ntpd.service, systemd-modules-load.service, systemd-sysctl.service, systemd-tmpfiles-clean.timer, systemd-tmpfiles-setup-dev.service, systemd-udev-trigger.service, systemd-udevd-control.socket, systemd-udevd-kernel.socket, systemd-udevd.service, systemd-vconsole-setup.service, virtualbox.service
wordpress-main> NOT restarting the following changed units: dhcpcd.service, [email protected], systemd-journal-flush.service, systemd-random-seed.service, systemd-remount-fs.service, systemd-tmpfiles-setup.service, systemd-update-utmp.service, systemd-user-sessions.service, [email protected]
wordpress-main> activating the configuration...
wordpress-main> setting up /etc...
wordpress-main> removing user ‘ntp’
wordpress-main> Debug (bootstrap): No readable global config found (0.009s)
wordpress-main> Debug (bootstrap): No project config found (0.01s)
wordpress-main> Debug (bootstrap): No package autoload found to load. (0.04s)
wordpress-main> Debug (bootstrap): ABSPATH defined: /nix/store/a44yx4vasgn48zbzgnd8fqh4nvnlc8y1-wordpress-app/ (0.04s)
wordpress-main> Debug (bootstrap): Set URL: testsite.dev (0.04s)
wordpress-main> Debug (bootstrap): Begin WordPress load (0.047s)
wordpress-main> Debug (bootstrap): wp-config.php path: /nix/store/760wjn88hmb9d7f0b60978g140rflk83-wp-config.php (0.047s)
wordpress-main> Error: Error establishing a database connection. This either means that the username and password information in your `wp-config.php` file is incorrect or we can’t contact the database server at `localhost`. This could mean your host’s database server is down.
wordpress-main> restarting systemd...
wordpress-main> reloading the following units: dbus.service, dev-hugepages.mount, dev-mqueue.mount, firewall.service, sys-kernel-debug.mount
wordpress-main> restarting the following units: sshd.service, systemd-journald.service, systemd-logind.service
wordpress-main> starting the following units: alsa-store.service, audit.service, kmod-static-nodes.service, network-local-commands.service, network-setup.service, nix-daemon.socket, nscd.service, systemd-modules-load.service, systemd-sysctl.service, systemd-tmpfiles-clean.timer, systemd-tmpfiles-setup-dev.service, systemd-udev-trigger.service, systemd-udevd-control.socket, systemd-udevd-kernel.socket, systemd-vconsole-setup.service, virtualbox.service
wordpress-main> the following new units were started: mysql.service, nginx.service, phpfpm.service, postfix.service, sshd-keygen.service, systemd-timesyncd.service
wordpress-main> error: unable to activate new configuration

[3noch]

@niklaswallerstedt Thanks for all the detail!

So for 1, in logical.nix I define the app and then refer to it like this: https://github.com/grafted-in/wordpress-nginx-nix/blob/master/server/logical.nix#L37

That expands to the path of the package, which is all the WordPress files.

Regarding the wp-cli issue, your diagnosis is likely correct, that the script runs before mysql is set up. I hadn't thought of that. You probably want to set up a systemd service to run after mysql starts. I'll post an example in a bit when my internet is working. You can find an example systemd service in logical.nix that sets up writeable paths.

[niklaswallerstedt]

@3noch Thanks for helping out! I got it working! Never really configured systemd before, so if this is the correct way of doing it idk. I'll dive into it now though :)

{
    systemd.services.wp-cli = {
      description   = "WP-CLI for WordPress";
      wantedBy      = [ "multi-user.target" ];
      after         = [ "mysql.service" ];
      serviceConfig = {
        ExecStart = ''
          "${pkgs.wp-cli}"/bin/wp core install \
          --url=testsite.dev \
          --title=Testsite \
          --admin_user=superadmin \
          --admin_password=strongpassword \
          [email protected] \
          --path="${app.package}" \
          --debug \
          --allow-root
        '';
        };
      };
}

[3noch]

@niklaswallerstedt Awesome! Yes that looks like a perfect definition of the systemd service! The only thing you might add is Type = "oneshot"; in the same set (i.e. {} block) as ExecStart. (Systemd docs; NixOS module docs). That just means the service doesn't represent a long-running program.

[niklaswallerstedt]

@3noch Great, works really well!

About point 2 from above.

I get this during a successful install sh: -t: command not found. Sendmail_path is in your logical.nix, but maybe this is the same issue with the startup order like mysql.

WP-CLI kept printing this on every new deploy, but digging a bit deeper I think there's a problem with the sendmail_path. This is from master (without wp-cli), using the docker build slave. Tried this from easyengine

php -a

Interactive shell
mail ('[email protected]', "Test Postfix", "Test mail from postfix");
sh: -t: command not found

From phpfpm-log

wordpress-main php-fpm[1494]: [WARNING] [pool wordpress-pool] child 1659 said into stderr: "sh: /var/setuid-wrappers/sendmail: No such file or directory"

I can send mail using sendmail directly though. Any ideas?

[3noch]

Ah, yes I forgot to look into that. So systemd services are by default run with a very minimal environment, which means their PATH has almost nothing on it. You should be able to add path = [ postfix ]; to your systemd configuration to bring sendmail into the PATH environment for the service. Here's the docs for that attribute: https://nixos.org/nixos/options.html#systemd.services+path

[niklaswallerstedt]

@3noch I've been trying to get it to work, saw that you committed some changes, but I'm still stuck. Shouldn't the php.ini be updated through phpOptions? Sorry to keep bothering you! :)

# php --ini
Configuration File (php.ini) Path: /nix/store/5p060w5dr85cd8v2jz2w60bhgq9w98wg-php-7.1.2/etc
Loaded Configuration File:         /nix/store/5p060w5dr85cd8v2jz2w60bhgq9w98wg-php-7.1.2/etc/php.ini
Scan for additional .ini files in: /etc/php.d
Additional .ini files parsed:      (none)

# cat /nix/store/5p060w5dr85cd8v2jz2w60bhgq9w98wg-php-7.1.2/etc/php.ini | grep "sendmail_path"
;sendmail_path =

[3noch]

@niklaswallerstedt You're definitely not bothering me! I wanted to open source this project for this very reason and you're providing super valuable feedback.

Yes you're absolutely right. I forgot about that too. So yes, you shouldn't need to mess with the systemd PATH as long as php is configured properly. You have a few options:

1. Invoke php and specify the config setting from the CLI. For example, the systemd service could use this: ExecStart = '' php -d d sendmail_path="${pkgs.postfix}/bin/sendmail -t -i" ''.
2. Use this same approach, but specify a new php.ini file that has custom configuration (e.g. php -c some-file.ini). This has the downside that it will only use the specified INI file which means you can't piggyback on the defaults.
3. Most likely you'd want to piggyback on the defaults. Also, I suspect you aren't calling php directly, though, but actually wp-cli is doing that. To solve both of these cases, you could use the PHP_INI_SCAN_DIR environment variable to list paths to your INI files. In a systemd service, you could do it like this:

{

systemd.services.myservice = {
  # ...
  environment.PHP_INI_SCAN_DIR = let
      # `writeTextDir` generates a file with the given name in a new nix store directory.
      myCustomIni = pkgs.writeTextDir "my-php.ini" ''
        sendmail_path = ${pkgs.postfix}/bin/sendmail -t -i
      '';
    in "${pkgs.php}/etc:${myCustomIni}";  # we list both the default location and our new one
};
}

[3noch]

Please keep me in the loop on your progress since I think this is a really useful feature that would be great to add somehow.

[niklaswallerstedt]

@3noch Thanks! Just to make sure, anything that goes inside phpOptions should be appended to the .ini-file though, right? Because now nothing is appended. Similar to this issue.

Also, I'm currently not using wp-cli as I've trying to get php to send mail by invoking it from the cli first. I'll try your suggestions!

{
      phpOptions = mkOption {
        type = types.lines;
        default = "";
        example =
          ''
            date.timezone = "CET"
          '';
        description =
          "Options appended to the PHP configuration file <filename>php.ini</filename>.";
      };
}

[3noch]

@niklaswallerstedt The phpOptions attribute of the phpfpm module only affects the phpfpm service. Running PHP from some other source will not have that configuration. I do wonder if there's a way to refer to that config though and use it.

[3noch]

Good find on that bug, I don't know if this repo is using a version of nixpkgs with that bug, but upgrading can't hurt (much).

[3noch]

Also it appears that my setting for sendmail_path is not right. We need to use /run/wrappers/bin/sendmail.

[3noch]

Upgrading nixpkgs will have to wait a bit since the change was recent. But I'm not sure if we have the bug in our version so it's worth trying it as is.

[niklaswallerstedt]

@3noch Ah totally makes sense now about the different configurations for phpfpm and cli!