Rich Remer's questions

Previously, I was able to find the auto-assigned IPv6 address of an Amazon EC2 instance with something like the following:

aws ec2 describe-instances --region us-west-2 --instance-id i-09eca7af84e1ef806 \
  | jq .Reservations[].Instances[].NetworkInterfaces[].Ipv6Addresses[]

(if you're unfamiliar, jq is a tool to process JSON data; in this case I'm using it to extract the value described in https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html)

I can see the corresponding IPv6 address in the AWS console, so I know an address has been assigned to the instance. But I can't find a way to get that information using the AWS command-line tool.

The documentation at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#view-ipv6-addresses seems to be the most pointed place describing how to get IPv6 addresses, but the documentation no longer seems to be correct.

This worked up until about a month ago. Now I can't find any way to get the address for an instance.

I'm trying to launch a container with systemd-nspawn (from the systemd-container package, version 241), but the container is not able to resolve host names. The host environment is PureOS 9.0, which is Debian-like and based on Ubuntu.

The container image was created using debootstrap and has systemd-container installed:

debootstrap \
    --components main,restricted,universe \
    --include systemd-container \
    bionic /var/lib/machines/bionic http://archive.ubuntu.com/ubuntu/
echo bionic > /var/lib/machines/bionic/etc/hostname

I'm launching the container from the image directory:

systemd-nspawn -qbD /var/lib/machines/bionic

From inside the container, I can access the host network:

root@bionic:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=130 ms

But DNS resolution is failing:

root@bionic:~# ping google.com
ping: google.com: Temporary failure in name resolution

The container resolv.conf is what I would expect; it looks like a pretty standard local DNS resolver, which should be provided by the host systemd-resolved.

nameserver 127.0.0.53

I see the DNS resolver listening on the host:

root@host:~$ lsof -i -Pn | grep LISTEN | grep 53
systemd-r  6957 systemd-network   13u  IPv4 5300137      0t0  TCP 127.0.0.53:53 (LISTEN)
systemd-r  7252 systemd-resolve   12u  IPv4 5313025      0t0  TCP *:5355 (LISTEN)
systemd-r  7252 systemd-resolve   14u  IPv6 5313028      0t0  TCP *:5355 (LISTEN)

This is similar to a setup I was using before on Ubuntu without problem. I don't have any reason to believe this shouldn't work on PureOS or on my version of systemd. I'm guessing something is different in the host networking configuration, but I'm not sure what to check.

I found that my host was not running systemd-resolved or systemd-networkd by default. I started those services manually with no change in behavior. I also stopped NetworkManager, thinking it might be interfering, but no luck there either.

I cannot get mysqldump to generate a dump that will properly restore. The dump is being generated to setup a new slave, but whenever the slave starts up, it gets foreign key constraint failures.

I'm generating the dump with slave positions and as a single transaction so that the dump is (allegedly) atomic, but when I essentially execute the following:

mysqldump \
    -h master
    --flush-logs --single-transaction --master-data \
    --apply-slave-statements \
    --databases my-db \
    | mysql -h slave

I get the following error when I "SHOW SLAVE STATUS":

Last_Errno: 1452
Last_Error: Error 'Cannot add or update a child row: a foreign key constraint fails ...

All of the tables use the InnoDB engine, and the foreign key is an integer.

Using MariaDB 10.3.

I'm trying to configure nginx so it will load PHP files without an extension, but still pass along requests for missing files to a front controller.

I started out with a mostly working config like the following that properly loads URLs like "about.php" from webroot/about.php and properly sends all requests for missing files to webroot/index.php:

server {
    listen 80;
    listen 443 ssl http2;
    server_name *.example.com;
    root /srv/example/$host;

    client_max_body_size    8M;
    fastcgi_buffers         16 16k;
    fastcgi_buffer_size     32k;
    large_client_header_buffers 8 32k;

    ssl_certificate         /etc/ssl/certs/example+ca.pem;
    ssl_certificate_key     /etc/ssl/private/example.key;
    ssl_ciphers             '...';

    location / {
        try_files           $uri
                            /index.php$is_args$args;
    }

    location /blog {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://127.0.0.1:2368;
    }

    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+\.php\b)(.*)$;
        fastcgi_param       SERVER_NAME $host;
        fastcgi_param       PATH_INFO $fastcgi_path_info;
        fastcgi_param       SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param       SCRIPT_NAME /index.php;
        fastcgi_index       index.php;
        include             fastcgi.conf;
        fcgi_pass php-fpm;
    }
}

I attempt to add a .php arg to the try_files like the following so I can load URLs like /about from webroot/about.php:

location / {
    try_files           $uri
                        $uri.php
                        /index.php$is_args$args;
}

Now, /about.php loads as expected, but /about downloads the file. I can't figure out how to force an internal redirect while maintaining the catch-all for the front controller. I've seen several people suggest removing =404, but that's not the issue here.

error log (/about): https://pastebin.com/XbdjLri4

173.196.243.178 - - [16/May/2017:21:35:03 +0000] "GET /about HTTP/1.1" 200 6176 "-" "Wget/1.18 (linux-gnu)"

error log (/about.php): https://pastebin.com/ay32GZ0m

173.196.243.178 - - [16/May/2017:21:35:10 +0000] "GET /about.php HTTP/1.1" 200 25848 "-" "Wget/1.18 (linux-gnu)"

I can't figure out how to initialize a MariaDB Galera cluster on Ubuntu Zesty. I've followed the documentation, but something seems to be missing. I cannot get the first node to come up.

I installed using standard package:

apt install mariadb-server

I've configured the cluster in /etc/mysql/mariadb.conf.d/90-cluster.cnf

[mariadb]
bind-address = 0.0.0.0
binlog-format = ROW
innodb-autoinc-lock-mode = 2
innodb-flush-log-at-trx-commit = 0
wsrep-on = ON
wsrep-sst-method = rsync
wsrep-cluster-name = "example"
wsrep-cluster-address = "gcomm://maria01.example.com,maria02.example.com"
wsrep-node-address = "maria01"
wsrep-node-name = "maria01.example.com"

Note: I've also attempted setting the wsrep-cluster-address to "gcomm://"

I attempt to bootstrap by stopping the service and starting with the specialized script:

systemctl stop mariadb
galera_new_cluster

Then I connect to the instance and check the status:

show global variables like 'wsrep%';
+---------------------------------+-----------------------------------------+
| wsrep_osu_method                | TOI                                     |
| wsrep_auto_increment_control    | ON                                      |
| wsrep_causal_reads              | OFF                                     |
| wsrep_certify_nonpk             | ON                                      |
| wsrep_cluster_address           | gcomm://                                |
| wsrep_cluster_name              | example                                 |
| wsrep_convert_lock_to_trx       | OFF                                     |
| wsrep_data_home_dir             | /var/lib/mysql/                         |
| wsrep_dbug_option               |                                         |
| wsrep_debug                     | OFF                                     |
| wsrep_desync                    | OFF                                     |
| wsrep_dirty_reads               | OFF                                     |
| wsrep_drupal_282555_workaround  | OFF                                     |
| wsrep_forced_binlog_format      | NONE                                    |
| wsrep_gtid_domain_id            | 0                                       |
| wsrep_gtid_mode                 | OFF                                     |
| wsrep_load_data_splitting       | ON                                      |
| wsrep_log_conflicts             | OFF                                     |
| wsrep_max_ws_rows               | 0                                       |
| wsrep_max_ws_size               | 2147483647                              |
| wsrep_mysql_replication_bundle  | 0                                       |
| wsrep_node_address              | maria01                                 |
| wsrep_node_incoming_address     | AUTO                                    |
| wsrep_node_name                 | maria01.example.com                     |
| wsrep_notify_cmd                |                                         |
| wsrep_on                        | OFF                                     |
| wsrep_patch_version             | wsrep_25.16                             |
| wsrep_provider                  | none                                    |
| wsrep_provider_options          | pc.bootstrap=1                          |
| wsrep_recover                   | OFF                                     |
| wsrep_replicate_myisam          | OFF                                     |
| wsrep_restart_slave             | OFF                                     |
| wsrep_retry_autocommit          | 1                                       |
| wsrep_slave_fk_checks           | ON                                      |
| wsrep_slave_uk_checks           | OFF                                     |
| wsrep_slave_threads             | 1                                       |
| wsrep_sst_auth                  |                                         |
| wsrep_sst_donor                 |                                         |
| wsrep_sst_donor_rejects_queries | OFF                                     |
| wsrep_sst_method                | rsync                                   |
| wsrep_sst_receive_address       | AUTO                                    |
| wsrep_start_position            | 00000000-0000-0000-0000-000000000000:-1 |
| wsrep_sync_wait                 | 0                                       |
+---------------------------------+-----------------------------------------+

show status like 'wsrep%';
+--------------------------+----------------------+
| wsrep_cluster_conf_id    | 18446744073709551615 |
| wsrep_cluster_size       | 0                    |
| wsrep_cluster_state_uuid |                      |
| wsrep_cluster_status     | Disconnected         |
| wsrep_connected          | OFF                  |
| wsrep_local_bf_aborts    | 0                    |
| wsrep_local_index        | 18446744073709551615 |
| wsrep_provider_name      |                      |
| wsrep_provider_vendor    |                      |
| wsrep_provider_version   |                      |
| wsrep_ready              | ON                   |
| wsrep_thread_count       | 0                    |
+--------------------------+----------------------+

Note especially the wsrep_cluster_size, which is 0, but it should be 1 after running galera_new_cluster according to the documentation.

The Maria log doesn't have a whole lot, but it does seem like the cluster is initialized:

systemd[1]: Starting MariaDB database server...
sh[4083]: 2017-05-03 22:11:40 139734663651904 [Note] /usr/sbin/mysqld (mysqld 10.1.22-MariaDB-) starting as process 4203 ...
sh[4083]: WSREP: Recovered position 00000000-0000-0000-0000-000000000000:-1
mysqld[4238]: 2017-05-03 22:11:44 140634874606144 [Note] /usr/sbin/mysqld (mysqld 10.1.22-MariaDB-) starting as process 4238 ...
systemd[1]: Started MariaDB database server.