Sure!

– hl=en → force language of results to be in English, otherwise Google regularly prioritizes other languages.

– gl=us → force location to the US.

– nfpr=1 → stop autocorrecting “““typos”””. Google doesn't always respect quotation marks unfortunately.

– verbatim=1 → search as is, it complements nfpr=1.

– pws=0 → disable personalization.

– filter=0 → stop “filter[ing] out some of the results for a given search” in order to “enhance the user experience”[1][2].

– tbs=li:1 → stop including other forms. e.g. without it searching for “test” also returns results that contain “testing”.

– udm=14 → disable AI-augmented features.

– q=%s → the query itself!

————————

[1] http://www.google.com/apis/reference.html (dead)

[2] Mirror: https://web.archive.org/web/20021201103155/http://www.google... (section 2.3, “Automatic Filtering”)

Here you go. Write me at jk@datapult.dk, if you need more.

A.5.25 Security in development and support processes:

Safe rolling deploy, rollback mechanisms, NGINX health checks, code versioning, Prometheus alerting for deployment issues

A.6.1.2 Segregation of duties:

Separate roles for database, monitoring, web apps; distinct system users

A.8.1.1 Inventory of assets:

Inventory management through Ansible inventory.ini and groups

A.8.2.3 Handling of assets:

Backup management with OVH S3 storage; retention policy for backups

A.8.16 Monitoring activities (audit logging, monitoring):

auditd installed with specific rule sets; Prometheus + Grafana Agent + Loki for system/application/audit log monitoring

A.9.2.1 User registration and de-registration:

ansible_user, restricted SSH access (no root login, pubkey auth), AllowUsers, DenyUsers enforced

A.9.2.3 Management of privileged access rights:

Controlled sudo, audit rules track use of sudo/su; no direct root access

A.9.4.2 Secure log-on procedures:

SSH hardening (no password login, no root, key-based access)

A.9.4.3 Password management system:

Uses Ansible Vault and variables;

A.10.1.1 Cryptographic controls policy:

SSL/TLS certificate generation with Cloudflare DNS-01 challenge, enforced TLS on Loki, Prometheus

A.12.1.1 Security requirements analysis and specification:

Tasks assert required variables and configurations before proceeding

A.12.4.1 Event logging:

auditd, Prometheus metrics, Grafana Agent shipping logs to Loki

A.12.4.2 Protection of log information:

Logs shipped securely via TLS to Loki, audit logs with controlled permissions

A.12.4.3 Administrator and operator logs:

auditd rules monitor privileged command usage, config changes, login records

A.12.4.4 Clock synchronization:

chrony installed and enforced on all hosts

A.12.6.1 Technical vulnerability management:

Lynis, Wazuh, vulnerability scans for Prometheus metrics

A.13.1.1 Network controls:

UFW with strict defaults, Cloudflare whitelisting, inter-server TCP port controls

A.13.1.2 Security of network services:

SSH hardening, NGINX SSL, Prometheus/Alertmanager access control

A.13.2.1 Information transfer policies and procedures:

Secure database backups to OVH S3 (HTTPS/S3 API)

A.14.2.1 Secure development policy:

Playbooks enforce strict hardening as part of deploy processes

A.15.1.1 Information security policy for supplier relationships:

OVH S3, Cloudflare services usage with access key/secret controls; external endpoint defined

A.16.1.4 Assessment of and decision on information security events:

Prometheus alert rules (e.g., high CPU, low disk, instance down, SSL expiry, failed backups)

A.16.1.5 Response to information security incidents:

Alertmanager routes critical/security alerts to email/webhook; plans for security incident log webhook

A.17.1.2 Implementing information security continuity:

Automated DB backups, Prometheus backup job monitoring, retention enforcement

A.18.1.3 Protection of records:

Loki retention policy, S3 bucket storage with rotation; audit logs secured on disk

Nice article.

Reminded me my own experience of creating bank software system for a State Bank of one of republics that was in the middle of separating from former USSR. "Perestroika" they named that process.

No mainframes, where we would get those at that time? Only i386 as a server and PC XTs as terminals. Connected by ropes essentially, but NetBIOS was working over them. Plus 1200 bod or so modems to connect with other banks in the republic.

But we (team of two developers) did it in 9 months.

Excellent Zortech C++ by Walter Bright (creator of D language).

Editor - MultiEdit the Great. What we would do without it - I don't know.

Database - dbVista (later known as dbRaima).

Everything was working on PTDOS (Russian MSDOS alike thing)

Yet multitasking C library providing cooperative multitasking (same execution model Node.js is using).

And everything in 640k of RAM that "should be enough for anybody".

We were young and nobody hadn't even a chance to tell us that this is "too serious", "impossible" and the like.

A lot of manual input by operators, so usability requirements were surprisingly high: http://www.terrainformatica.com/2016/02/ui-usability-solutio...

:)