From AI monorepos to OSINT reconnaissance: real troubleshooting in a Linux lab

Setting up local development environments and security labs on Linux is one of those tasks where initial theory rarely survives the first round of terminal commands. Recently, I completed two extensive debugging sessions on my CachyOS workstation and inside Docker lab containers.

The first objective was standing up the models and UI of a complex local AI monorepo (the AIRI project); the second was configuring an automated OSINT reconnaissance pipeline powered by programmatic Google Dorking.

Below is the technical log covering the errors encountered, log analyses, and practical workarounds that stabilized both stacks.

Part 1: Taming Node.js monorepos and runtime conflicts on CachyOS#

The initial goal was running the AIRI project locally, an AI avatar framework with voice and vision pipelines. The repository depends on an extensive monorepo managed through pnpm workspaces.

1. PNPM version conflicts and FNM multishells#

Attempting an installation via npx pnpm install triggered Corepack to fetch pnpm-10.33.0. Inspecting binary locations with which -a pnpm revealed multiple active paths:

/run/user/1000/fnm_multishells/44696_1784149451542/bin/pnpm
/usr/bin/pnpm
/bin/pnpm

On CachyOS / Arch, package-managed binaries in /usr/bin bind execution to the system Node runtime. Running pnpm install or pnpm dev immediately hung silently in the terminal.

2. The EUNSUPPORTEDPROTOCOL error with pnpm catalogs#

Attempting a fallback with standard npm install aborted instantly:

npm error code EUNSUPPORTEDPROTOCOL
npm error Unsupported URL Type "catalog:": catalog:

Root cause: The monorepo relies on pnpm Catalogs (catalog:), a feature designed to centralize dependency versions across monorepo packages. Traditional npm does not support this protocol, making pnpm mandatory.

3. Resolving with npx pnpm@latest and the onnxruntime-node build crash#

To bypass local symlink inconsistencies, I executed the latest clean binary through NPX:

npx pnpm@latest install

Package downloads for machine learning stacks proceeded normally, fetching over 2,700 dependencies. However, post-install scripts crashed with ELIFECYCLE:

node_modules/.pnpm/onnxruntime-node@1.21.0/node_modules/onnxruntime-node: Running postinstall script, failed in 183ms
.../node_modules/onnxruntime-node postinstall$ node ./script/install
│ Failed to detect CUDA version from `nvcc --version`: Unsupported CUDA version: 13
│ AggregateError [ECONNREFUSED]:
│     Error: connect ECONNREFUSED ::1:443
│     Error: connect ECONNREFUSED 127.0.0.1:443

Root cause: The onnxruntime-node build script attempted to compile GPU binaries, failed to recognize CUDA version 13, and attempted local network downloads that were refused.

4. Bypassing scripts and compiling internal workspaces#

To skip broken native build scripts and resolve dependencies cleanly:

npx pnpm@latest install --ignore-scripts

Installation finished in seconds. Running npx pnpm@latest dev launched Vite but threw unresolved module warnings:

(!) Failed to run dependency scan. Skipping dependency pre-bundling. Error: The following dependencies are imported but could not be resolved:
  @proj-airi/font-cjkfonts-allseto/index.css
  @proj-airi/core-agent
  @proj-airi/stream-kit
  @proj-airi/server-shared/types

Root cause: Skipping post-install scripts meant internal workspace packages had not yet generated their /dist bundles.

The complete working sequence was:

# 1. Compile internal monorepo packages and typings
npx pnpm@latest build

# 2. Start the Vite development server
npx pnpm@latest dev

Part 2: Trufflehog and Docker volume scope resolution#

In parallel, I set up a credential audit workflow using TruffleHog inside a Kali Linux Docker container to scan local repositories.

Running a filesystem scan:

trufflehog filesystem /root/shared/airi

Returned a missing path error:

error   trufflehog   encountered errors during scan   {"job": 1, "source_name": "trufflehog - filesystem", "errors": ["lstat /root/shared/airi: no such file or directory"]}

Root cause: The container alias mounted the current working directory (red-lab/kalilinux) into /root/shared. Because the target repo lived in another folder (ia-lab/airi), the container had no visibility into it.

Fix:

1. Navigate directly to the target project directory on the host before launching the container.
2. Or create a host symlink bridging the shared paths:

ln -s /home/user/labs/ia-lab/airi /home/user/labs/red-lab/kalilinux/airi

Part 3: OSINT automation with googledorker and Google custom search API#

For passive reconnaissance, I integrated GoogleDorker into a Python virtual environment inside Kali.

1. Installation and package structure#

Cloning the repository does not provide a standalone python3 googledorker.py executable; it is packaged via setup.py. Installation within the virtualenv requires:

# Inside the active venv
pip install .

This registers the global dorker CLI tool.

2. Missing API credentials error#

Running an initial query with dorker -q "site:domain.com filetype:sql" failed:

[version]: dorker current version v1.0.1 (latest)
[ERR]: Exception occured in the Keyreader module due to: Cannot choose from an empty sequence,
[ERR]: Exception occured in the google search request module due to: cannot unpack non-iterable NoneType object

Root cause: GoogleDorker queries the official Google Programmable Search API to avoid CAPTCHA blocks, requiring valid credentials in ~/.config/dorker/provider-config.yaml.

3. Programmable search engine configuration (CX ID)#

In the Google Programmable Search Engine console, "Search the entire web" is no longer available by default on free engines, and wildcards like :///* are rejected.

The verified workaround to enable wide search scopes is configuring structured patterns:

• www.google.com/*
• .google.com/

This successfully generated the Search engine ID (CX ID).

4. Provisioning the API key in Google cloud console#

To generate access credentials:

1. Open your project in the Google Cloud Console.
2. Explicitly enable the Custom Search API (otherwise credential restriction dropdowns will show "No items to display").
3. Navigate to APIs & Services > Credentials, create a new API Key, and restrict its scope strictly to the Custom Search API.
4. Populate the configuration file inside the Kali container:

# File: ~/.config/dorker/provider-config.yaml
google:
  - api_key: "AIzaSy..."
    cx: "1074f00b491db440b"

Once configured, dorker executed programmatic queries without network blocks or runtime exceptions.

Conclusion: practical takeaways for lab environments#

Whether handling AI monorepos on Arch Linux or configuring offensive security tools in containers, understanding the underlying mechanisms is key: package manager protocols (like pnpm's catalog:), proper Docker volume mappings, and Google Cloud API authorization scopes.

See also

Cybersecurity Troubleshooting Fail2ban status 255 exception: migrating to systemd backend and Nginx modular includes

Cybersecurity Incident anatomy: mitigating simultaneous L7 attacks, Dovecot DoS, and CPU bottlenecks

Cybersecurity Forensic analysis of a CloudLinux and cPanel compromise: from the sshd_config trap to PAM and IPMI persistence

This post is licensed under CC BY-NC.