Android app policy violation triggered by old testing tracks - Blank release fix

We have multiple tracks in google play console for one of our Android apps. Currently we don't need all of them, we need only the production track. But unfortunately, google does not provide a way to delete unwanted tracks. Also, even releases in paused tracks can trigger "policy violation" of having app releases targeting older target SDK values - we need to update every year to the latest target SDK.

Asking Gemini via aistudio.google.com about this, it suggested a "Blank Release" method - create a new release, but don't upload any aab/apk file. We can do this for each of the testing tracks which we don't need. That would make the older releases "Inactive" and prevent the "policy violation" for old releases.

I've done this yesterday for one of our apps, and it seems to be working. The changes were approved after review in just an hour or less. The policy violation popup did not go away yesterday even after the changes were approved, but today I see that the policy violation popup is replaced with "Policy status - No policy issues found" in the "Monitor and improve" tab.

While we can upload the latest release to all of the tracks, and use the "Add from library" method for each track instead of uploading, the "Blank release" strategy above avoids that busy-work, hopefully permanently.

slightly more user-friendly mass mailing script

Prompted Gemini via aistudio.google.com to make the mass-mailer using Google Apps Scripts a bit more user-friendly - displaying a checklist of actions to be performed for sending the emails, and picking up the rich-text html from a draft email instead of needing to write out the html by hand. Creating a custom menu and displaying a sidebar UI are done by these functions, using this html.

The Draft email with subject MassMailTemplate must not be deleted, it must remain available throughout the run of the script. The body of the email is taken from this Draft.

Inline images inside the draft will be sent as attachments, and it is better to avoid attachments to prevent our mails from being marked as spam. Formatted text is fine.

The Checklist in the Mass Mailer menu item is just for display, unchecking all the items can be done manually before the next send.

disk space alert and cleanup of MySQL databases with Moodle logs

We got an alert from our script that one of our servers had 95% utilization of the root disk. Asked Gemini via aistudio.google.com and carried out the following.

Find the Top 20 largest directories on the root partition:

sudo du -ahx / | sort -rh | head -20

Note: The `-x` flag ensures it only searches the root partition and doesn't scan external mounts or network drives.

Found that 29 GB was being used by MySQL databases.

Find individual files larger than 100MB:

sudo find / -xdev -type f -size +100M -exec ls -lh {} \;

Found that there were some .ibd files, with the names of Moodle table  like logstore_standard_log.ibd which were very large. Gemini suggested retaining only 180 or 365 days of logs instead of "Never delete logs" in Site administration > Plugins > Logging > Standard log.

Then, to get back space ...

First, logged on as the administrator of a particular database which we do not need, and dropped that database.

mysql -u thatusername -p

drop database unuseddbname

(sudo mysql does not work on this server, a root password is set, but I did not need the root password.)

That gave us 3-5 GB. Then, there were two options for Moodle logstore_standard_log - either just truncate the table - very quick, get back disk space instantly - or copy over the last 180 days' logs to a new table and then delete the old table.

(Other methods suggested by Gemini were very slow, mentioning only the good options below. Just deleting entries from a table would require an OPTIMIZE TABLE step afterwards, which would need enough disk space to create a full copy of the table.)

CREATE TABLE prefix_logstore_standard_log_new LIKE prefix_logstore_standard_log;

# find starting id to reduce copy time, since id is an indexed field

SELECT id FROM prefix_logstore_standard_log 

WHERE timecreated >= UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 180 DAY)) 

LIMIT 1;

INSERT INTO prefix_logstore_standard_log_new 

SELECT * FROM prefix_logstore_standard_log 

WHERE id >= YOUR_NUMBER_FROM_ABOVE_STEP;

The copying of log entries into the new table took 51 seconds using this method for our smallest db.

The quick and dirty way, of deleting all the logstore standard log entries (this is only the "what has the user clicked" data - grades etc are not deleted) -

TRUNCATE TABLE prefix_logstore_standard_log; 

This completes in less than a second, and makes disk space available immediately.

Azure portal - Review Azure Copilot agent access settings before 1 August

There was an email from Microsoft, letting us know that if we don't take action, we will be opted in for enabling Azure Copilot agents. In general, my instinct is to disable every new "feature' which Microsoft introduces, because sooner or later, that will be involved in some security incident. After consulting the other admins, I disabled "Azure Copilot" on both Azure tenants I have admin access to, with the result that these agents

Observability Agent

Deployment Agent

Troubleshooting Agent

Optimization Agent

Resiliency Agent

Migration Agent

will not be available.

When we navigate to Azure Copilot Admin Center (which we can access via the search at the top of portal.azure.com after logging in) to disable Azure Copilot, there is a link to toggle the control for <User> can manage access to all Azure subscriptions and management groups in this tenant. Since they recommend turning this off, I turned it on, disabled Copilot and turned it back on. The link to this control is https://portal.azure.com/#view/Microsoft_AAD_IAM/TenantProperties.ReactView

The documentation referencing this is at

https://learn.microsoft.com/en-gb/azure/copilot/manage-access

https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin

Google apps script issue - script.google.com refused to connect - google glitch

One of our servers which had a google apps script embedded in a php page started showing "script.google.com refused to connect" - the issue was noticed last afternoon. We checked that no changes had been made to the script, we did have

.setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL);

as mentioned in

https://stackoverflow.com/questions/57138352/apps-script-refused-to-connect

The only other change was to install and set up fail2ban on the server, that was unlikely to be the cause. 

"If no changes have been made to the script, then perhaps it is a transient google problem, and might be resolved in a few hours.

If not, we would need to check if google apps scripts have any recent policy changes."

It might have been a google glitch, since last night the issue was resolved by itself. Looked like the outage was for around 8-10 hours.

reminder to take a break - Mac version

I wanted to recreate the earlier "reminder to take a break" cron job script on MacOS. Asked Claude about it, and it suggested using launchd instead of cron, since cron jobs run without access to the display by default. After several rounds of trial and error, here is the method that worked.

nano ~/Library/LaunchAgents/com.yourname.walkreminder.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>Label</key>

    <string>com.yourname.walkreminder</string>

    <key>ProgramArguments</key>

    <array>

        <string>/bin/bash</string>

        <string>-c</string>

        <string>osascript -e 'display notification "Time to take a walk" with title "Reminder" sound name "Ping"'; afplay /Users/yourusername/Sounds/Walk.mp3</string>

    </array>

    <key>StartCalendarInterval</key>

    <array>

        <dict>

            <key>Hour</key>

            <integer>14</integer>

            <key>Minute</key>

            <integer>0</integer>

        </dict>

    </array>

    <key>StandardOutPath</key>

    <string>/tmp/walkreminder.log</string>

    <key>StandardErrorPath</key>

    <string>/tmp/walkreminder.err</string>

</dict>

</plist>

In the above, the schedule is to run once a day at 14:00 hours. For running every half an hour from the time the user was logged on, we can use 

<key>StartInterval</key>

  <integer>1800</integer>

instead of <key>StartCalendarInterval</key>

Or, in my case, since I wanted every half an hour aligned to 0:00 and 0:30 exactly, 

 <key>StartCalendarInterval</key>

    <array>

        <dict>

            <key>Minute</key>

            <integer>0</integer>

        </dict> 

        <dict>

            <key>Minute</key>

            <integer>30</integer>

        </dict>

    </array>

We had to use a Sounds directory which we had created, since afplay could not access the Downloads directory when run from launchd.

launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.yourname.walkreminder.plist

and test with

launchctl kickstart -k gui/$(id -u)/com.yourname.walkreminder

Troubleshooting can be done with

plutil -lint ~/Library/LaunchAgents/com.yourname.walkreminder.plist

launchctl list | grep walkreminder

cat /tmp/walkreminder.err

incident and response - malicious bots

One of our servers, which hosted a dot net backend as well as some wordpress sites, showed some outages two days in a row, restored by restarting. Feeding the apache access logs to Gemini via aistudio.google.com, Gemini said,

The logs clearly show an Apache HTTP

Server running PHP and hosting a WordPress application.

The logs indicate that your server was hit by an aggressive automated attack

(likely a botnet) starting around 07:33:35, which appears to have either

succeeded in exploiting a vulnerability or overloaded the server, causing it to

crash shortly after.

(Server had run out of memory). 

Gemini suggested the following - 

1. Hide and Protect Your Origin IP - which we may not do
2. Patch and Update the Server Software - which we're doing
3. Implement a Web Application Firewall (WAF) - which is in place
4. Clean Up WordPress Configuration - "Open your wp-config.php file, locate line 63, and remove the    duplicate definition of WP_AUTO_UPDATE_CORE. While this didn't cause the crash, it eats up server I/O and makes reading logs difficult."
5. Restrict PHP Execution in Uploads Directories
6. Implement Intrusion Prevention (Fail2Ban)

Then, feeding the access logs of the dot net api to Gemini 

and as suggested by Gemini,

journalctl -u ourapi.service --since "2026-06-28 07:15:00" --until "2026-06-28 07:45:00"

Gemini gave some recommendations like returning 0 instead of a 500 error for no data found -

"As we saw in the access logs, when the mobile app sees

    this 500 error, its poorly designed error-handling logic says: "Something

    went wrong! Retry the entire sync process!" It then proceeds to download 4MB

    of lesson data, hits the notification endpoint again, gets another 500

    error, and repeats the cycle every 15 seconds until your server runs out of

    memory and crashes."

- this may or may not be actually what is happening here, since Gemini just saw the logs and does not have access to the code.

In any case, I've enabled bot protection on Cloudflare for this domain, and also installed and configured Fail2ban.

On Cloudflare, 

ourdomain.org > Security > Security rules > Custom rules

Block .env scans

URI Path equals .env

Block

 also added Cloudflare's default rate limiting rule,

Leaked credential check [Template]

Password Leaked equals true

Block

also enabled Cloudflare's AI blocking tools - AI Labyrinth enabled, and Block AI training bots on all pages.

Then, installed and set up Fail2ban on the server, monitoring the apache web server and sshd logs. It will temporarily block ip addresses which fail authentication repeatedly, or which repeatedly request non-existent files like malicious bots.

Gemini via aistudio.google.com gave step-by-step instructions for installation and setup of Fail2ban. 

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
(we can optionally edit these,

bantime  = 1h

findtime = 10m

maxretry = 5

)

Enable the Apache jails with

sudo nano /etc/fail2ban/jail.local

[apache-auth]

enabled  = true

port     = http,https

logpath  = %(apache_error_log)s

In case the logpath is custom - fail2ban looks by default for

Error logs: /var/log/apache2/*error.log

Access logs: /var/log/apache2/*access.log

In the case of one of our servers, we needed to change this to

logpath  = %(apache_error_log)s

           /var/www/mysite/logs/custom-error*.log

More Apache jails to enable - basically need to add the enabled = true line - 

[apache-badbots]

enabled  = true

port     = http,https

logpath  = %(apache_access_log)s

bantime  = 48h

maxretry = 1

[apache-noscript]

enabled  = true

port     = http,https

logpath  = %(apache_error_log)s

[apache-overflows]

enabled  = true

port     = http,https

logpath  = %(apache_error_log)s

[apache-nohome]

enabled  = true

port     = http,https

logpath  = %(apache_error_log)s

[apache-botsearch]

enabled  = true

port     = http,https

logpath  = %(apache_error_log)s

Then we can test

sudo systemctl start fail2ban

sudo systemctl enable fail2ban
sudo systemctl status fail2ban

and check the enabled jails with

sudo fail2ban-client status

On one server, we had to resolve

ERROR   Failed during configuration: Have not found any log file

for sshd jail

For that, we had to change the block to

[sshd]

enabled = true

port    = ssh

backend = systemd

since that server was using systemd, and traditional text log files like /var/log/auth.log (which Fail2Ban looks for by default for SSH) are no longer created. After the change, after restarting the service, we can check that jail alone with

sudo fail2ban-client status sshd

Then, for using a different port rather than port 22 for sshd - 

[sshd]

enabled = true

port    = 2022

backend = systemd

(if port 2022 is being used) 

and so on, because that is the port which fail2ban would ban using the machine's firewall, iptables or nftables as the case may be.

To see the rules, we can use

sudo nft list ruleset # for nftables, Ubuntu 24.04

sudo iptables -nL # for iptables, earlier Ubuntu etc

page listing many "Cloud Native" apps and projects

 The Cloud Native Landscape via this blog post looking back at the past (from the author of digitalbadger.net)