One of the things that my cloud infrastructure team does is publish a set of semi-hardened Amazon Machine Images (#AMIs) each month. Many of our customers use #AWS and use RPM-based distributions that have specific hardening-requirements that need to be in place "from birth". So, we publish images for Red Hat, @almalinux@fosstodon.org, @rockylinux@fosstodon.org 8 and 9 as well as a semi-hardened version of #AmazonLinux2023.
At any rate, something happened to the #AL2023 images we bootstrap from between AWS's August-published images and their September-published images that causes the (chroot'ed) installation of the grub2-common RPM to fail. That RPM attempts to do a boot-loader installation for a couple platform-types. However, since the September-published image, it fails when doing the i386pc part. The backrev version of the RPM in question is only available in the AL2023 images published before April 7th of this year.
…So, now I'm back and forth with AWS support on the problem. Had to explain to them how to reproduce the problem, because they couldn't figure out how to do so. Bonus points: the issue isn't easily reproducible with any of the AMIs that are available, as AWS deprecates any AL2023 images older than " minus 2".
#AmazonLinux2023
Installing PHP ImageMagick on Amazon Linux 2023
WordPress has been yelling at me for a while that I don’t have the PHP module imagick installed. When I moved to an updated server running AL2023 and PHP 8, I lost it. As it turns out the reason is that the package isn’t included, and that hasn’t changed since 2022. Mildly annoying!
I found a re:Post guide (thanks Mike Lim!) on setting up PHP modules and followed that with some slight modifications/reordering:
sudo dnf install -y ImageMagick ImageMagick-develsudo dnf install -y php-devel php-pear gccsudo pecl update-channelssudo pecl install imagickAt this point, in checking that the shared library was successfully installed to /usr/lib64/php8.2/modules/ I noticed that the new file wasn’t marked executable like all the others. Pretty sure that’s necessary?
sudo chmod +x /usr/lib64/php8.2/modules/imagick.soThen for enabling the module, since my php.d had numbered prefixes and comments, I tweaked the config a bit:
sudo tee /etc/php.d/30-imagick.ini > /dev/null << EOF; Enable the ImageMagick extension moduleextension=imagick.soEOFAfter restarting php-fm I confirmed on my Site Health report in the admin panel that ImageMagick is good to go.
sudo systemctl restart php-fpmphp -m | grep -i imagickI’m hoping this might resolve some of the performance issues I’ve had on image upload.
While ideally this is the sort of thing that should just be handled by the distribution/image, probably instead of poking at my live VPS I should follow all the best practices I use at work and set up some sort of containerized WordPress pipeline, huh?
I run this blog on a small Amazon Lightsail instance (1 GB RAM, 2 vCPU). Cheap!
Most of the time, it’s fine, but it has a bad habit of dying sometimes on a large image upload. The Jetpack app reports the upload as failing (offering to try again) but my site is completely unresponsive. I can resolve this in one of two ways: either I can still SSH into the box, and restarting PHP with sudo systemctl restart php-fpm recovers and I can try the upload again; or the instance isn’t responsive to SSH and I have to reboot it via the Lightsail console. The CPU utilization is elevated during this period, eating into the burstable zone.
I have seen generally better performance since I updated /etc/php-fpm.d/www.conf to override pm = static and pm.max_children = 2, but something was obviously still wrong. I installed atop since I often couldn’t get on the host to see what was happening right when it was stuck.
Last week, while working on a new post, my instance got wedged in the same way while trying to upload a short video. From the JetPack activity log I could see it became unresponsive at 11:42 PM Seattle time; the instance and atop use UTC so I’d need to look at the minutes leading up to to 0642 in the weekly atop log. That looks like this:
Well there’s my problem! php-fpm spikes in CPU, and then kswapd0 pegs the CPU while the instance’s local disk goes wild with reads trying to keep up. One odd thing is while the memory is low, it doesn’t seem to have changed much for the two php-fpm children. I guess I either need to tune the swappiness on my host or try to put a better clamp on PHP processing images? Need to investigate further.
I’m sure the real solution is to not host my own LAMP stack, but where’s the fun in that?
https://blog.ultranurd.net/2024/07/21/investigating-failed-wordpress-uploads/
#amazonLinux2023 #apache #aws #debugging #httpd #lightsail #linux #phpFpm #wordpress
AnsibleでAmazon Linux 2023 に Postfix をインストールする
https://qiita.com/mkin/items/76a6b483d333769eaadd?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
#qiita #AWS #postfix #Ansible #AmazonLinux2023