Kickstart module Up to Date?

this is what i meant, an understood

much cleaner, thank. update the docs as well kindly

I briefly searched for runagent in the Dev’s manual Buti I didn’t find where to update it. Any idea?

1 Like

i am not sure they were documented, even in the dev manuals, i learnt about them from this community, but would be wise if they apear somehwere in the docs for better reference

So now we have the additional Services and containers added,

But still services wont start, what am i missing?

cat enviroment is saying no file or directory found yet when i run ls i see enviroment any hint why

refer to this Kickstart module Up to Date? - #39 by davidep

1 Like

do you have created some systemd service for container and the pod like https://github.com/NethServer/ns8-sogo/tree/goToBeta/imageroot/systemd/user

if Yes then start the pod

systemctl start --user sogo

the pod is named sogo

https://github.com/NethServer/ns8-sogo/blob/goToBeta/imageroot/systemd/user/sogo.service

the others are the service of the containers of mariadb and sogo: mariadb-app and sogo-app

https://github.com/NethServer/ns8-sogo/blob/goToBeta/imageroot/systemd/user/mariadb-app.service
https://github.com/NethServer/ns8-sogo/blob/goToBeta/imageroot/systemd/user/sogo-app.service

keep an eye on that PR because I just start from kickstart, so you could see all changes you need

sogo is quite complex because it needs a lot of understanding of new concepts

template with jinja
events from redis
call of actions from another module
scripts in ./bin that does stuff
script to discover LDAP or MAIL capacities among the cluster
UI (for now really basic but NsComboBox is pure fear :wink: )

1 Like

Can you help me debug and check why this services are not running

open a terminal in the server with

journalctl -f _UID=$(id -u MODULE_ID)

MODULE_ID is the the name of your container, incremented after each installation, sogo1,sogo2

Sorry but without Logs I am blind, moreover it could be really specific to your container, for example your container could expect to connect to a database or expecting environment variable

So first you need maybe to debug by starting the podman command manually that You find https://github.com/compgeniuses/ns8-paperless-ngx/blob/main/imageroot/systemd/user/ns8-paperless-ngx.service#L20

However for what I see

the service you pointed me is the pod, I am not sure you could add an image to a pod, so the pod starts, then it calls all other container

here Before=paperless-pgsql.service paperless-redis.service you miss the paperless container service

see https://github.com/NethServer/ns8-sogo/blob/goToBeta/imageroot/systemd/user/sogo.service

1 Like

there is no image in the sogo pod, and inside the pod I call the two services that will starts the containers

1 Like

well so you need a pod

and three containers

1 Like

be aware 20001 was for my need, you need probably another port for your needs (read documentation of your container)

this is only needed if you expect to allow login from LDAP

--network=slirp4netns:allow_host_loopback=true \
--add-host=accountprovider:10.0.2.2

here you should do

systemctl --user enable ns8-paperless-ngx.service
systemctl --user restart ns8-paperless-ngx.service

here rather to query redis you could/should read from environment vars

config["host"] = os.getenv("TRAEFIK_HOST","")
config["http2https"] = os.getenv("TRAEFIK_HTTP2HTTPS") == "True"
config["lets_encrypt"] = os.getenv("TRAEFIK_LETS_ENCRYPT") == "True"

Env vars or redis are just string so you need to test them

os.getenv("TRAEFIK_LETS_ENCRYPT") == "True" in python means if equal to the string True the in it is true (boolean)

like this you could do things faster, testing locally is always faster

when you try to debug, do not forget to become runagent, like this you see all environment vars

ssh sogo1@::1
runagent bash
1 Like

HEllo @stephdl and @davidep , now what seems to be the reason why the attached services are failing to start, because i think we should be having active

Normally no. Just the pod shoul be enabled because the attached service are binded to the service pod
A bind makes that when the pod start/stop the binded services do the same

so is it ok for the services to be in this state?

Services should be running at some point. For example in your configure-module action a step (usually I write a tiny shell script for it) executes:

if [[ -z $SOME_CHECK ]]; then
    # Enable and start the services the first time configure-module is executed
    systemctl --user enable --now first.service second.service third.service
else
    # Reload or Restart running services (containers)
    systemctl --user try-reload-or-restart first.service second.service third.service
fi
1 Like

Yes the pod once you have triggered the configure-module must be enabled, the environment variable written to ~/.config/state/environment