It's under docker_images, so make sense only if we deploy Anubis as a Docker image.

(In that case, could be complicated to get the socket path)

If the goal is to give a new configuration for Anubis deployed outside Docker, this pillar is fine, but we need to put it at the same level than docker_images (so one less tab)

Format is:

docker_images:
  <service name>:
    <container name>:

The container name devcentral is already used, so I guess that would be something like anubis_devcentral

(but only if we use Docker)

Should be put in a roles/paas-docker/anubis/ directory.

We can use:

• one file, so this would be roles/paas-docker/anubis/init.sls
• different files living in roles/paas-docker/anubis (to split software/services/config)

I see we're at +- 40 lines so one file is good

That's the name of the pillar entry, so in that case, in pillar/paas/docker/docker-002/main.sls we should have something like:

anubis_instances:

devcentral:
  socket: /run/anubis/devcentral.sock
  policies_file: /usr/local/etc/anubis/devcentral.yaml

Ansible convention is to use .j2 extension for Jinja2 templates.

In our Salt repository, I see two conventions:

• to directly use the filename for config, text
• to append .jinja for scripts, to bypass linter (e.g. mw.sh.jinja to avoid shellcheck to lint mw.sh and reports {{ is an errror)

Here it would be safe to use something like "instance.env" as filename.

So we have a target key in the anubis_instances pillar.

At this stage I imagine something like:

anubis_instances:
  devcentral:
    socket: /run/anubis/devcentral.sock
    policies_file: /usr/local/etc/anubis/devcentral.yaml
    target: http://localhost:31080

Or:

anubis_instances:
  devcentral:
    socket: /run/anubis/devcentral.sock
    policies_file: /usr/local/etc/anubis/devcentral.yaml
    target:
      type: docker # we ignore it for now, but in the future if we've a no Docker we can add target logic
      service: phabricator
      container: devcentral

The target would then be http://localhost:{{ docker_containers[config[service]][config[container]]["app_port"] }}

And we automatically grab app_port from docker_containers pillar.

Same logic than app_port grabbing, but host instead

We need to provide logic to provision those two credentials into Vault.

Something like in fix_anubis_devcentral.sh, but with a write in Vault to run before provisioning this.

Can we try with a UNIX socket? Like in /run/anubis/metrics/?

(That's perhaps that one we didn't succeed to query)

If we can do that, that will avoid to maintain a new ports table for the Anubis metrics.

No, no, no, we're especially heavily attacked on the files :/

Same, they query A LOT the source code files in Diffusion.

I guess the intent of the LLM is to get "public access", but our software isn't intended to be downloaded from DevCentral directly so we're good there

We're in two scenarii:

• we want to allow static assets -> they are served from devcentral.nasqueron-user-content.org we could just not query Anubis from that nginx block
• we want to protect everything -> that block isn't needed - the attack bombs us to fetch source code, including source code to get .js files so those would also end by .js in the URL, for example https://devcentral.nasqueron.org/source/api-datasources/browse/master/tasks/fetchExternalPageAndParseDOMTask.js URL ends by .js

So that rule to allow all traffic isn't useful neither

Hmmmm, those aren't really annoying, the ones that are annoying are the stealth ones, the ones that masquerade themselves as legit browser traffic

Hmmm

Actually, that one conflicts with everything else.

For example lines 19 to 34 offers to do the job we already do with the env file above.

What we would need is perhaps to document or script the keys generation part, the two openssl rand -base64 32, and write it to Vault afterwards (vault kv write).

We noticed a lot of hallucinations in this template.

For reference, here what we used for deck.nasqueron.org -> Orbeon in Decemmber:

TARGET=http://127.0.0.1:16080
POLICY_FNAME=/etc/anubis/botPolicies.yaml
ED25519_PRIVATE_KEY_HEX_FILE=/etc/anubis/private.key

ANUBIS_TARGET_URL seems to match expected value for TARGET

ANUBIS_METRICS_ADDR seems to match expected value for METRICS_BIND

Should be re conciliated with content in P390 currently deployed on Dwellers.

Outside the for loop, as we can try a unique policies file to avoid repeat the same information

Can be removed, we noticed Anubis doesn't document format for the key or a way to provide one, so our best shot is to let Anubis generate one, then store it manually in Vault.

Automation can be investigated later, probably by filing a bug request on Anubis tracker to get an option to generate a key (or doc to do so ourselves).