tests of mid-tones brightness reduction on planetarium dome

Tried out reduction of mid-tones using Blender, for reducing the washed-out over-exposed look due to dome reflections. 

For individual textures in a 3D scene, add a RGB Curves node after the texture in Shader Editor. In Blender VSE (Video Sequence Editor), we can add via "Add" menu, choose "Effect Strip," and select "Color" followed by "RGB Curves."

On the M4 Mac Mini, 3840x2160 renders were proceeding at nearly 10 fps from Blender VSE. The output of that was probably not playable smoothly on Raspberry Pi, so ran it through Avidemux with Videotoolbox (GPU assisted) HEVC codec, the default bitrates of 2000 kbps avg and 4000 kbps max are quite low, but quality is fine for simple scenes.

NAVK preferred the previous version of "Unseen Earth" in which I probably either put a mask over the bright parts or left as is - when I reduce mid-tones again, the scene becomes too dark for him. Probably I can redo the overexposed parts of "The Search" with this technique.

Cloudflare Origin Server Certificate for Wordpress instance on Hostinger

After chatting with Hostinger support, the following is the reply.
"Yes. Your WordPress instances on Premium Web Hosting support custom SSL certificates on their virtual hosts"

(Copy-pasting from an email exchange).

So, we could install the cloudflare origin server certificate as per the procedure at https://www.hostinger.com/support/1583785-how-to-install-a-custom-ssl-in-hostinger/ 

Doing this has both Pros and Cons. 

 The pro is that then we can be sure of the certificate being valid for Cloudflare - unlike the letsencrypt certificate currently present, which would need updating every three months. 

 The con is that once the cloudflare origin server certificate is installed, you can only access the wordpress site through cloudflare (or you would get a scary "certificate not trusted" message) and you would be limited by cloudflare's file upload and timeout limits.

(The team opted to not use Cloudflare Origin Certificates.)

removed defunct DNS records

After an email the previous day to verify that none of these services need to be kept, deleted a handful of defunct DNS records from a couple of our domains. One was an MX record which was not active since the migration to Google Workspace in 2019.  

setting up passkeys with keepassxc on linux

Since Microsoft was making passkeys the default for authenticating on Azure as mentioned in a previous post, I wanted to understand more about passkeys and how to use them on Linux. This video was helpful - Convenient and secure: Manage passkeys with KeePassXC - Tutorial

So, with keepassxc, the steps were, for me on Linux Mint,

sudo add-apt-repository ppa:phoerious/keepassxc

sudo apt update
sudo apt install keepassxc

Then,

1. Need to enable browser integration

2. Need to connect browser plugin to keepassxc

3. Need to enable passkeys in the browser extension

4. Test with webauthn.io

5. https://passkeys.directory/ shows which services support

For Google account, passkey creation is via my account - myaccount.google.com/security

Under Security, Passkeys and security button at the bottom.

For Microsoft, currently passkey creation is at

https://mysignins.microsoft.com/security-info

Multiple google accounts are supported by keepassxc. Also, Android 16 phone supports passkeys out of the box. 

For Google Workspace logins, the admin must enable passkeys for users - Choose whether to let users skip their password if they can authenticate their Google Account securely with just a passkey. -  the only downside seems to be for people using security keys - "Users won't have the option to add a security key. They can still create passkeys on security keys, but security keys that support passwordless sign-in can't be added for 2-Step Verification only." 

bundling dependencies in MacOS app

Over several trial-and-error attempts with the help of Claude.ai, these two scripts bundled the dependencies needed to run the OpenSpace app without homebrew - tested by renaming /opt/homebrew to something else. 

https://github.com/hn-88/OpenSpace-AppImage/wiki/OpenSpace-on-Mac

The bundling of dependencies was done using these two scripts, bundle-macos-local.sh and bundle-python.sh.

Passkeys by default and retirement of Microsoft-provided SMS and voice authentication

Microsoft sent us an email and has a blog post where they say

To address these evolving threats, Microsoft Entra ID is updating its authentication experience by making passkeys the default phishing-resistant authentication method, helping customers reduce reliance on phishable methods such as SMS and voice.

I asked Gemini at aistudio.google.com, "How do I Identify users who still use SMS or voice in portal.azure.com?"

Gemini suggested

1. Method 1 - The Authentication Methods Activity Dashboard in Azure portal -  portal.azure.com > Microsoft Entra ID > Security > Authentication methods > Monitoring > Activity, "Click the Usage tab to see a high-level visual chart of which authentication methods are actually being used to sign in across your tenant"
2. Method 2 - Export a Report using Microsoft Graph PowerShell
3. Method 3: Check Actual Usage via Sign-in Logs - portal.azure.com > Microsoft Entra ID > Sign in logs, look at the Authentication Details tab

I asked Gemini,

I get the message "Migrate to the converged Authentication methods policy"

"Please migrate your authentication methods off the legacy MFA and SSPR policies by September 2025 to avoid any service impact."

What does that mean, and how do I do it?

Gemini replied, 

What does this mean?

Historically, Microsoft Entra ID (formerly Azure AD) had two separate, disconnected portals for managing how users prove their identity:

1.  The Legacy MFA Portal: Used to control methods for Multi-Factor

    Authentication (MFA).

2.  The SSPR Portal: Used to control methods for Self-Service Password Reset

    (SSPR).

Because managing these in two different places was confusing, Microsoft created a unified "Authentication methods policy." This new policy is a single, converged dashboard where you manage all authentication methods (Microsoft Authenticator, SMS, Voice, FIDO2, Passkeys, etc.) for both MFA and Password Resets.

Microsoft is retiring the old legacy portals by September 30, 2025. The message you are seeing is a warning that your tenant is still relying on the old legacy settings, and you need to manually flip a switch to tell Microsoft to use the new modern policy instead.

If you don't do this before the deadline, you risk service disruption (users

might not be able to register or use their MFA/SSPR methods properly) once

Microsoft turns off the old portals.

How do I do the migration?

Migrating doesn't mean your users have to set up their MFA again; it simply

means you, as the administrator, are changing where the rules are managed.

Here is the step-by-step process to migrate safely:

Step 1: Audit your existing legacy settings

Before you switch over, you need to see what methods you currently allow so you

can match them in the new portal.

1.  Sign in to the Microsoft Entra admin center as a Global Administrator or

    Authentication Policy Administrator.

2.  Check your Legacy SSPR Settings: Go to Protection > Password reset >

    Authentication methods. Note which boxes are checked (e.g., Mobile app code,

    Email, Mobile phone).

3.  Check your Legacy MFA Settings: Go to Users > All users > Click Per-user MFA

    at the top. On the new page, click service settings at the top. Note which

    verification options are checked (e.g., Text message, Call, Notification).

Step 2: Configure the new Converged Policy

Now, you must replicate those allowed settings in the new unified portal.

1.  In the Entra admin center, go to Protection > Authentication methods >

    Policies.

2.  You will see a list of methods (Microsoft Authenticator, SMS, Voice call,

    FIDO2 security key, etc.).

3.  Click into each method you want to allow (based on your notes from Step 1).

4.  Toggle the Enable switch to Yes, set the Target to All users (or specific

    groups), and hit Save. (Note: It is highly recommended to enable Microsoft

    Authenticator and Temporary Access Pass, as Microsoft is pushing toward

    modern/phishing-resistant methods).

Step 3: Change the Migration State

Once your new policy matches your old settings, you are ready to flip the

switch.

1.  Still in Protection > Authentication methods > Policies, look near the top

    of the page for a banner or a button labeled Manage migration.

2.  A flyout menu will appear on the right side of your screen with three

    options:

      - Pre-migration: (Where you are currently) - Only legacy policies are

        respected.

      - Migration in progress: - Both policies are respected, but the new

        converged policy is evaluated first.

      - Migration Complete: - The legacy policies are completely ignored, and

        only the new converged policy is used.

3.  Select Migration in progress and click Save.

4.  Take a few days to ensure your users can still sign in, use MFA, and reset

    their passwords without issue.

5.  Once you confirm everything works, go back to the Manage migration menu,

    select Migration Complete, and click Save.

That's it! Once you hit "Migration Complete," the warning message in your portal

will disappear, your tenant will be fully modernized, and you will be safe from

the September 2025 deprecation deadline.

It was in the Migration in progress state. And all the methods are shown as not enabled. I asked Gemini if I should enable them.

Gemini said, Yes, absolutely. Because you are in the Migration in progress state, Microsoft is currently looking at both your old legacy settings and the new portal. If a method is turned on in either place, your users can use it.

Here is a screenshot of the authentication methods page, after I enabled some of them. 

I'm detailing the creation and use of passkeys on Linux / Android in another post.

saga of decommissioned UPS

Dec 18, 2025 - email to the top executive officer of one of our institutions, saying that we could possibly make use of a decommissioned 10 kVA UPS

Feb 20, 2026 - email "received with thanks". It takes 20 65Ah lead acid batteries, trying to charge the batteries with 12V charger ordered on 25th Feb.

June 29, 2026 - requesting electrical people to wire up the batteries which were individually charged

July 23-26, 2026 - internal resistance testing shows 11 of the 20 batteries are bad, which makes the UPS trip when input power fails. So, decide to not use it.

July 31, 2026 - sent the good batteries to another institution. 

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.