search

c0c0n3 / odoo.box

All of Martel's Odoo stack on just one NixOS machine.
MIT License
3 stars 0 forks source link

Odoo password refresh needs bouncing the service #10

Open c0c0n3 opened 5 months ago

c0c0n3 commented 5 months ago

After updating the Odoo admin password, you might have to restart the Odoo systemd service to regenerate the Odoo config file with the new password. Sometimes NixOS is smart enough to do that for you---not sure exactly how it figures out the service should be restarted because its config file depends on the Age password file just decrypted, but, heck, it does. Some other times NixOS won't restart the service---why? When that happens, you'll have to do that manually, running sudo systemctl restart odoo.

Here's how to reproduce.

  1. Start the dev VM.
  2. Generate new vault secrets with vaultgen---this will generate a new Odoo password too.
  3. Deploy the new secrets.
  4. If NixOS says, in the deployment output, that it restarted the Odoo service, go back to step 2.
  5. SSH into the dev VM.
  6. Run: sudo bat /run/agez/passwords/odoo-admin.txt
  7. You should see the new Odoo password you've chosen or generated.
  8. Run: sudo bat /var/lib/odoo/config.ini
  9. You should see the old password still in the config file.
  10. Run: sudo systemctl restart odoo
  11. Run: sudo bat /var/lib/odoo/config.ini
  12. Now you should see the new password in the config file.
c0c0n3 commented 5 months ago

Ideally we should set up things in a way that whenever the password changes, the Odoo service gets automatically restarted at deployment time.

c0c0n3 commented 5 months ago

Sometimes NixOS is smart enough to do that for you [...] Some other times NixOS won't restart the service---why?

I think NixOS only restarts the service when you change vault implementation in your config---e.g. switch from snake oil to Agez. In fact, in this case NixOS actually has to rebuild the service derivation as you can see in the example output below

[...]
building '/nix/store/a8vddya3zxjb4fv3ql08dn17ngr7kxs2-unit-odoo.service.drv'...
[...]
building '/nix/store/5i5yjhnms1j4i2jqfx2yc8ihi97y1mv7-system-units.drv'...
building '/nix/store/09cxyn7f8b4r389im65887g218c7nbzq-etc.drv'...
building '/nix/store/sjgixdj5c0j5p6w2f57brl7y0dmab44z-nixos-system-devm-23.11.20240301.79baff8.drv'...
[...]
stopping the following units: odoo.service
activating the configuration...
setting up /etc...
[...]
reloading user units for root...
reloading user units for admin...
[...]
starting the following units: odoo.service
c0c0n3 commented 4 months ago

We should probably add a restart trigger for the password file in the Odoo service's def

{
    restartTriggers = [ pwd-file ];

    # ... existing  settings
}
c0c0n3 commented 4 months ago

17 adds the trigger but the issue's still there. We could try looking into referencing the Agenix mount dir as that changes when you redeploy secrets. First run

activating the configuration...
[agenix] creating new generation in /run/agenix.d/1
...
[agenix] symlinking new secrets to /run/agenix (generation 1)...
...
the following new units were started: run-agenix.d.mount

Second run (without rebooting VM)

activating the configuration...
[agenix] creating new generation in /run/agenix.d/2
...
[agenix] symlinking new secrets to /run/agenix (generation 2)...
[agenix] removing old secrets (generation 1)...

Notice there's no mention of run-agenix.d.mount on the second run, but maybe it's something we could leverage.