acct-user/localai
User for the LocalAI inference server
ChangeLog
commit 7fd0cd3c5820c81352a5067b432b88cce460912a
Author: lucascouts <lucascs@protonmail.com>
Date: Sun Sep 6 09:20:25 2026 -0300
add(acct-{user,group}/localai-0), mod(sci-ml/localai-4.9.0-r1): OpenRC service
local-ai is a daemon that shipped with no way to run it as one. Upstream sends
neither a systemd unit nor an init script, so the project rule about mirroring
a unit with an OpenRC script of the same scope never fired -- there was no unit
to mirror. The result was a server whose only launch path was by hand, as root,
in whatever directory happened to be current.
That last part is not rhetorical. Every path local-ai takes defaults to $PWD:
--models-path, --backends-path, --data-path and three more resolve relative to
the working directory, so a hand-started daemon scatters multi-gigabyte model
downloads wherever it was launched. The init script passes all seven
explicitly, under /var/lib/localai.
It binds loopback, and that is a correctness fix rather than hardening taste:
local-ai's own default is the wildcard ":8080", and it REFUSES TO START on a
wildcard or public address unless --allow-insecure-public-bind is given. Left
at upstream's default the service would not come up at all. LOCALAI_ADDRESS in
/etc/conf.d/local-ai widens it for anyone who configures authentication first.
/etc/conf.d/local-ai is installed 0640, not the 0644 newconfd leaves behind: it
is where LOCALAI_API_KEY, the OIDC client secret and HF_TOKEN belong. root:root
rather than root:localai is deliberate and sufficient -- OpenRC sources conf.d
as root and only then drops to the localai user, so the daemon never reads the
file and the account need not exist on the build host. The confd also documents
that those variables need an explicit `export`; a bare assignment is only a
shell variable of the init script and the daemon never sees it.
The accounts take id 600 rather than the next free number. ::gentoo's highest
assigned account id is 563, so 600 cannot collide with an existing assignment.
acct-user/ntpd-rs and ntpd-rs-observe took 466 and 500, which are holes INSIDE
the range ::gentoo allocates from -- they become collisions the day ::gentoo
hands those out. Not repeated here, and worth revisiting for ntpd-rs.
Revbumped rather than edited in place because 4.9.0 is already on origin and
this changes the installed image.
Verified on the image rather than the ebuild text: /etc/conf.d/local-ai is
0640, /etc/init.d/local-ai is 0755, /var/lib/localai exists, and the init
script's multi-line command_args expands to 15 argv entries beginning
`run --address 127.0.0.1:8080` -- 17 with a confd override, which lands the new
address and appends LOCALAI_OPTS. shellcheck and `sh -n` clean. pkgcheck clean
on all three packages but for the x32 nodejs finding already documented in the
ebuild.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: lucascouts <lucascs@protonmail.com>
Date: Sun Sep 6 09:20:25 2026 -0300
add(acct-{user,group}/localai-0), mod(sci-ml/localai-4.9.0-r1): OpenRC service
local-ai is a daemon that shipped with no way to run it as one. Upstream sends
neither a systemd unit nor an init script, so the project rule about mirroring
a unit with an OpenRC script of the same scope never fired -- there was no unit
to mirror. The result was a server whose only launch path was by hand, as root,
in whatever directory happened to be current.
That last part is not rhetorical. Every path local-ai takes defaults to $PWD:
--models-path, --backends-path, --data-path and three more resolve relative to
the working directory, so a hand-started daemon scatters multi-gigabyte model
downloads wherever it was launched. The init script passes all seven
explicitly, under /var/lib/localai.
It binds loopback, and that is a correctness fix rather than hardening taste:
local-ai's own default is the wildcard ":8080", and it REFUSES TO START on a
wildcard or public address unless --allow-insecure-public-bind is given. Left
at upstream's default the service would not come up at all. LOCALAI_ADDRESS in
/etc/conf.d/local-ai widens it for anyone who configures authentication first.
/etc/conf.d/local-ai is installed 0640, not the 0644 newconfd leaves behind: it
is where LOCALAI_API_KEY, the OIDC client secret and HF_TOKEN belong. root:root
rather than root:localai is deliberate and sufficient -- OpenRC sources conf.d
as root and only then drops to the localai user, so the daemon never reads the
file and the account need not exist on the build host. The confd also documents
that those variables need an explicit `export`; a bare assignment is only a
shell variable of the init script and the daemon never sees it.
The accounts take id 600 rather than the next free number. ::gentoo's highest
assigned account id is 563, so 600 cannot collide with an existing assignment.
acct-user/ntpd-rs and ntpd-rs-observe took 466 and 500, which are holes INSIDE
the range ::gentoo allocates from -- they become collisions the day ::gentoo
hands those out. Not repeated here, and worth revisiting for ntpd-rs.
Revbumped rather than edited in place because 4.9.0 is already on origin and
this changes the installed image.
Verified on the image rather than the ebuild text: /etc/conf.d/local-ai is
0640, /etc/init.d/local-ai is 0755, /var/lib/localai exists, and the init
script's multi-line command_args expands to 15 argv entries beginning
`run --address 127.0.0.1:8080` -- 17 with a confd override, which lands the new
address and appends LOCALAI_OPTS. shellcheck and `sh -n` clean. pkgcheck clean
on all three packages but for the x32 nodejs finding already documented in the
ebuild.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>


View
Download
Browse