Skip to main content

SSH access

The nexgen_v3 tenant, since 2026-10-21

Since the cutover on 2026-10-21 the site runs on the instance nutritionistpro-web in the nexgen_v3 AWS tenant, the same account as the Nexgen apps (the default AWS CLI profile on the operator's machine). The old instance Npro2 in the old Axxya tenant is kept only for rollback; its Bitnami layout is summarized at the end of this page until it is deleted.

Connecting​

The instance was created with an imported key pair named cawood-mac, whose private key is ~/.ssh/lightsail-nexgen-v3 on the operator's machine (RSA; Lightsail's key import does not accept Ed25519 keys). The login user is admin, not bitnami, ubuntu, or ec2-user:

ssh -i ~/.ssh/lightsail-nexgen-v3 admin@35.174.58.107

The shell prompt shows the private hostname, admin@ip-172-26-14-0. The instance details, static IP, and firewall rules are on Hosting and deployment.

Port 22 admits only the operator's IPv4 address plus the four Lightsail aliases (lightsail-connect, lightsail-connect-ipv6, lightsail-setup-ipv4, lightsail-setup-ipv6), so the console's Connect using SSH browser client always works as a fallback, and anyone else needs their address added to the 22 rule. To give another person a key, append their public key to /home/admin/.ssh/authorized_keys (append, never replace). The browser client passes Mac keystrokes through correctly on this image, unlike the old Bitnami one, so nano works there.

File paths​

A standard Debian layout, with no symlinks:

  • WordPress root: /var/www/html, owned by admin:www-data; everything under wp-content is owned by www-data.
  • wp-config.php: /var/www/wp-config.php, one level above the web root (WordPress looks there when the file is absent from the root). Mode 440, readable only by root and www-data, so reading or editing it needs sudo. The database password is not in the file: it is read at runtime from /opt/aws/wordpress/credentials.log, which ~/application_credentials links to, so that file must stay in place.
  • .htaccess: /var/www/html/.htaccess, written by hand during the migration; WP Rocket adds its own block to it.
  • PHP configuration for the web server: /etc/php/8.2/apache2/php.ini (PHP runs as an Apache module, mod_php, so there is no PHP-FPM pool). The command-line PHP reads /etc/php/8.2/cli/php.ini instead, so php -i does not show the web server's values.
  • Apache virtual hosts: /etc/apache2/sites-enabled/000-default.conf (port 80, redirects to https) and default-ssl.conf (port 443, with the Origin CA certificate). ServerName is set in /etc/apache2/conf-enabled/servername.conf.
  • TLS certificate and key: /etc/ssl/certs/nutritionistpro-origin.pem and /etc/ssl/private/nutritionistpro-origin.key.
  • Apache logs: /var/log/apache2/error.log and access.log.

wp-config.php cannot be edited from wp-admin: the Appearance and Plugin file editors only reach files inside wp-content/.

Running WP-CLI​

WP-CLI is installed at /usr/local/bin/wp. Run it as the web server user so that any file it writes keeps the right owner, and pass the WordPress path since you will usually be in the home directory:

sudo -u www-data wp --path=/var/www/html --info
sudo -u www-data wp --path=/var/www/html option get siteurl
sudo -u www-data wp --path=/var/www/html option get home
sudo -u www-data wp --path=/var/www/html plugin list

To feed a file in the home directory to a command (for example a database import), use standard input (wp db import - < ~/file.sql), because www-data cannot read /home/admin.

Restarting services​

sudo apache2ctl configtest
sudo systemctl reload apache2
sudo systemctl restart apache2
sudo systemctl restart mariadb

A reload is enough after a virtual host or php.ini change; PHP runs inside Apache, so there is no separate PHP service to restart. A wp-config.php change needs no restart at all, since it is read on every request. Check the result in /var/log/apache2/error.log.

Editing configuration safely​

Always back up, validate, then reload. A syntax error in wp-config.php takes the whole site down, including wp-admin.

sudo cp /var/www/wp-config.php /var/www/wp-config.php.bak
sudo nano /var/www/wp-config.php
sudo php -l /var/www/wp-config.php

php -l must print No syntax errors detected. In nano, Ctrl+_ followed by a line number jumps straight to that line, and sudo nano -i disables auto-indent, which otherwise mangles pasted blocks.

To roll back:

sudo cp /var/www/wp-config.php.bak /var/www/wp-config.php

Keep the SSH session open until the change is verified. The backups from the migration are still on the box: wp-config.php.bak is the image's original file and wp-config.php.bak2 is the state before the salts were copied across.

Flushing caches​

Yoast caches generated sitemaps in WordPress transients. After any change that affects sitemap or URL output, clear them:

sudo -u www-data wp --path=/var/www/html transient delete --all

This clears every plugin's transients, including Yoast's. That is safe, because transients are caches that regenerate on demand, though the first few page loads afterwards are slightly slower. WP Rocket's page cache is separate: clear it from the WP Rocket menu in the wp-admin bar, or by deleting /var/www/html/wp-content/cache/wp-rocket/ as www-data.

The old instance​

Npro2 in the old Axxya tenant (account 898347667108, AWS CLI profile axxya-old) is the pre-migration Bitnami instance, static IP 54.162.107.22. It is reachable only through the console's browser SSH client as user bitnami, because its key pair nprowp1 was never found on the operator's machine; the browser client does not pass Mac Ctrl keystrokes to nano there, so use tee -a and sed -i for edits. Its layout: WordPress at /opt/bitnami/wordpress with wp-content and wp-config.php symlinked into /bitnami/wordpress/, PHP-FPM with php.ini at /opt/bitnami/php/etc/php.ini and the pool at /opt/bitnami/php/etc/php-fpm.d/www.conf, Apache logs under /opt/bitnami/apache/logs/, services restarted with /opt/bitnami/ctlscript.sh, and WP-CLI run as sudo wp --path=/opt/bitnami/wordpress. The stopgap settings applied to it on 2026-10-21 are on PHP security stopgap (October 2026). It is to be stopped once the new instance has had a few days of traffic, and deleted after a final snapshot; see Moving the site to the new AWS tenant.