https://ikb.lux-ear.com/api.php?action=feedcontributions&feedformat=atom&user=104.56.117.26 2026-04-08T21:27:18Z User contributions MediaWiki 1.41.1 https://ikb.lux-ear.com/index.php?title=Lux-Ear_Internal_Incidents_%26_Operations_Log&diff=145 2026-01-08T05:33:01Z

<p>104.56.117.26: Add incident entries for Jan 6 operational failures</p> <hr /> <div>{{DISPLAYTITLE:Lux-Ear Internal Incidents &amp; Operations Log}}<br /> <br /> == Purpose ==<br /> This page serves as the authoritative chronological record of operational incidents, infrastructure failures, recovery efforts, and follow-up actions related to Lux-Ear systems and workflows.<br /> <br /> It is intended to:<br /> * Preserve institutional memory<br /> * Reduce repeated troubleshooting<br /> * Support accountability and learning<br /> * Provide a foundation for future automation and reporting<br /> <br /> ---<br /> <br /> == How to Use This Log ==<br /> * Each incident should have its own dedicated page using the [[Template:Incident|Incident Template]]<br /> * Incidents should be listed below in reverse chronological order (newest first)<br /> * This log summarizes incidents; detailed analysis belongs on individual incident pages<br /> <br /> ---<br /> <br /> == Incident Index ==<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> ! Date<br /> ! Incident Title<br /> ! Status<br /> ! Systems Affected<br /> ! Primary Owner<br /> |-<br /> | &lt;!-- YYYY-MM-DD --&gt;<br /> | [[Incident YYYY-MM-DD – Title]]<br /> | Open / Mitigated / Resolved<br /> | <br /> | <br /> |-<br /> | 2025-12-18<br /> | [[Incident 2025-12-18 – MediaWiki BotPassword Authentication Failure]]<br /> | Open<br /> | MediaWiki / API Automation<br /> | Scott<br /> |-<br /> | 2026-01-06<br /> | [[Incident 2026-01-06 – iCloud Sync &amp; Local Visibility Failure]]<br /> | iCloud files were present but not visible in Finder, causing confusion and delays locating critical incident archives.<br /> | Medium<br /> | Resolved / Documented<br /> |}<br /> <br /> ---<br /> <br /> == Ongoing / Open Incidents ==<br /> &lt;!-- Move unresolved incidents here for visibility --&gt;<br /> <br /> ---<br /> <br /> == Recently Resolved Incidents ==<br /> &lt;!-- Optional curated list --&gt;<br /> <br /> ---<br /> <br /> == Related Pages ==<br /> * [[Template:Incident]]<br /> * [[Lux-Ear Infrastructure]]<br /> * [[Lux-Ear Operations]]<br /> * [[Lux-Ear Automation Roadmap]]<br /> <br /> ---<br /> <br /> [[Category:Incidents]]<br /> [[Category:Operations]]<br /> [[Category:Infrastructure]]</div>

104.56.117.26 https://ikb.lux-ear.com/index.php?title=Incident_2026-01-06_%E2%80%93_BotPassword_Authentication_Failure_(MediaWiki_API)&diff=144 2026-01-08T05:28:56Z

<p>104.56.117.26: Create incident page</p> <hr /> <div>= Incident 2026-01-06 – BotPassword Authentication Failure (MediaWiki API) =<br /> <br /> == Summary ==<br /> Attempts to authenticate to the MediaWiki API using BotPasswords repeatedly failed, despite bot accounts and credentials being present in the database and visible via maintenance scripts. This prevented automation of wiki publishing and required extended debugging of MediaWiki authentication configuration.<br /> <br /> The failure was ultimately traced to missing or inactive BotPassword authentication providers in the MediaWiki AuthManager configuration.<br /> <br /> ----<br /> <br /> == Impact ==<br /> * Automation for wiki publishing blocked<br /> * Incident documentation and operational recovery delayed<br /> * Significant engineering time spent debugging authentication paths<br /> * Increased cognitive load during already degraded operational state<br /> <br /> ----<br /> <br /> == Timeline (condensed) ==<br /> * 2026-01-06 – Bot user accounts and BotPasswords verified in database<br /> * Multiple API login attempts failed using both `login` and `clientlogin`<br /> * MediaWiki version and configuration inspected<br /> * AuthManager providers dumped via maintenance scripts<br /> * BotPasswordAuthenticationProvider found to be absent from active auth stack<br /> <br /> ----<br /> <br /> == Root Cause ==<br /> * BotPassword authentication provider not registered in MediaWiki AuthManager<br /> * MediaWiki allowed creation and storage of BotPasswords but could not authenticate them<br /> * Configuration mismatch between enabled features and active auth providers<br /> <br /> ----<br /> <br /> == Resolution ==<br /> * Identified missing BotPassword authentication provider<br /> * Determined required configuration changes for full API-based bot login<br /> * Deferred final fix pending restoration of operational baseline and documentation completion<br /> <br /> ----<br /> <br /> == Preventive Actions ==<br /> * Explicitly verify AuthManager providers after MediaWiki upgrades<br /> * Add automated test for bot API login during deployment<br /> * Document required bot authentication configuration in operations wiki<br /> <br /> ----<br /> <br /> == Related Pages ==<br /> * [[Lux-Ear Internal Incidents &amp; Operations Log]]<br /> * [[MediaWiki Configuration]]<br /> * [[Automation &amp; Deployment]]</div>

104.56.117.26 https://ikb.lux-ear.com/index.php?title=Incident_2026-01-06_%E2%80%93_iCloud_Sync_%26_Local_Visibility_Failure&diff=143 2026-01-08T05:26:41Z

<p>104.56.117.26: Create incident page</p> <hr /> <div>= Incident 2026-01-06 – iCloud Sync &amp; Local Visibility Failure =<br /> <br /> == Summary ==<br /> During recovery and documentation work following multiple infrastructure incidents, iCloud Drive appeared enabled but files were not clearly visible or discoverable in Finder. This caused uncertainty about the location of critical artifacts (including incident ZIP files) and delayed documentation, publishing, and re-orientation work.<br /> <br /> The issue contributed to cognitive overload by obscuring whether data was missing, unsynced, or simply not presented clearly by the OS.<br /> <br /> ----<br /> <br /> == Impact ==<br /> * Incident documentation artifacts were temporarily inaccessible or difficult to locate<br /> * Delayed publication of operational and incident records<br /> * Increased time spent validating data safety rather than progressing with recovery tasks<br /> * Added to cumulative operational and psychological load<br /> <br /> ----<br /> <br /> == Timeline (condensed) ==<br /> * 2026-01-06 – Attempted to locate incident ZIP file believed to be stored in iCloud<br /> * iCloud Drive shown as enabled, but Finder visibility and status unclear<br /> * System Settings reviewed to confirm iCloud Drive, Desktop &amp; Documents sync, and optimization settings<br /> * Files eventually located after clarifying Finder iCloud location and sync state<br /> <br /> ----<br /> <br /> == Root Cause ==<br /> * iCloud Drive UX ambiguity regarding sync status and file locality<br /> * Finder did not clearly indicate whether files were local, cloud-only, or pending sync<br /> * High storage usage and optimization settings reduced immediate clarity<br /> <br /> ----<br /> <br /> == Resolution ==<br /> * Verified iCloud Drive settings and sync configuration<br /> * Located correct iCloud Drive folder in Finder<br /> * Confirmed presence of incident artifacts<br /> <br /> ----<br /> <br /> == Preventive Actions ==<br /> * Document iCloud Drive visibility and Finder behavior in operations wiki<br /> * Prefer explicit local working directories for critical incident artifacts<br /> * Add checklist for verifying cloud vs local file state during incidents<br /> <br /> ----<br /> <br /> == Related Pages ==<br /> * [[Lux-Ear Internal Incidents &amp; Operations Log]]<br /> * [[Lux-Ear Infrastructure]]</div>

104.56.117.26 https://ikb.lux-ear.com/index.php?title=Incident_2025-12-22_%E2%80%93_DreamHost_SSH_%26_Session_Instability&diff=142 2026-01-08T05:17:52Z

<p>104.56.117.26: Create incident page</p> <hr /> <div>= Incident 2025-12-22 – DreamHost SSH &amp; Session Instability =<br /> <br /> == Summary ==<br /> Intermittent SSH session instability and unexpected disconnections occurred when accessing DreamHost-hosted servers. Sessions dropped without clear error signaling, complicating diagnosis and prolonging active maintenance windows.<br /> <br /> == Impact ==<br /> * Unreliable SSH access to production and documentation servers<br /> * Increased troubleshooting time and repeated reconnections<br /> * Delayed automation and administrative tasks<br /> <br /> == Timeline (condensed) ==<br /> * 2025-12-22 – Repeated SSH session drops observed<br /> * Attempts made to stabilize sessions using keepalive and timeout settings<br /> * Partial mitigation achieved; underlying cause unresolved at the time<br /> <br /> == Status ==<br /> Mitigated<br /> <br /> == Systems Affected ==<br /> DreamHost / SSH / Server Access<br /> <br /> == Primary Owner ==<br /> Scott<br /> <br /> == Notes ==<br /> This incident contributed to cumulative operational fatigue during an already degraded infrastructure period.</div>

104.56.117.26 https://ikb.lux-ear.com/index.php?title=Incident_%E2%80%93_Screen_Sharing_Auto-Reconnect_(Draft)&diff=136 2026-01-06T08:05:00Z

<p>104.56.117.26: client continuously tries to log in to invalid IP address</p> <hr /> <div>= Incident – Screen Sharing Auto-Reconnect (Draft) =<br /> <br /> == Status ==<br /> Draft – created on Jan 5, 2026<br /> <br /> == Purpose ==<br /> Capture learnings from the macOS Screen Sharing auto-reconnect incident.<br /> <br /> == Summary ==<br /> To be completed.<br /> <br /> == Timeline ==<br /> To be completed.<br /> <br /> == Root Cause ==<br /> To be completed.<br /> <br /> == Resolution ==<br /> To be completed.<br /> <br /> == Preventive Actions ==<br /> To be completed.<br /> <br /> [[Category:Incidents]]<br /> [[Category:macOS]]<br /> [[Category:IT Operations]]</div>

104.56.117.26