feat(ulogd): enabling ulogd #121

Merged
rlahfa merged 1 commit from lbailly/infrastructure:ulogd into main 2024-09-08 12:21:08 +02:00
Member

ulogd indique qu'il n'arrive pas à parse le fichier de config, mais je ne trouve pas le problème

ulogd indique qu'il n'arrive pas à parse le fichier de config, mais je ne trouve pas le problème
rlahfa reviewed 2024-08-28 19:13:20 +02:00
@ -0,0 +28,4 @@
postgresql = {
enable = true;
ensureUsers = [
{
Owner

The root user is unnecessary

The `root` user is unnecessary
Author
Member

I removed the root user in the database.

I removed the root user in the database.
lbailly marked this conversation as resolved
rlahfa reviewed 2024-08-28 19:13:37 +02:00
@ -0,0 +32,4 @@
name = "root";
ensureClauses.superuser = true;
}
{
Owner

ulogd user is unnecessary as ulogd may require root privileges for now

`ulogd` user is unnecessary as ulogd may require `root` privileges for now
Author
Member

we need a user to access the database, and I'm not willing to use the 'postgres' user for such operations

we need a user to access the database, and I'm not willing to use the 'postgres' user for such operations
rlahfa marked this conversation as resolved
rlahfa reviewed 2024-08-28 19:14:24 +02:00
@ -0,0 +21,4 @@
user = "\"root\"";
table = "\"ulog2_ct\"";
procedure = "\"INSERT_CT\"";
pass = "\"changeme\"";
Owner

connstring = "postgresql:///ulogd?host=/run/postgresql"; should work in principle

`connstring = "postgresql:///ulogd?host=/run/postgresql";` should work in principle
Author
Member

it doesn't want a connection URI, but really a connection string, as in section 31.1.1.1. of the postgres doc. In the end, I just don't give network connection information and it behave as expected.

it doesn't want a connection URI, but really a connection string, as in section 31.1.1.1. of the [postgres doc](https://www.postgresql.org/docs/9.2/libpq-connect.html#LIBPQ-CONNSTRING). In the end, I just don't give network connection information and it behave as expected.
rlahfa marked this conversation as resolved
lbailly force-pushed ulogd from a3c2d3ad10 to 6c77e84cc2 2024-08-28 19:29:31 +02:00 Compare
lbailly force-pushed ulogd from 6c77e84cc2 to 460584e4a1 2024-08-28 19:29:41 +02:00 Compare
lbailly force-pushed ulogd from 460584e4a1 to a301fe0fd1 2024-08-28 20:34:30 +02:00 Compare
Author
Member

Normalement tout est bon dans la config now, il reste éventuellement à ajouter des stacks si les logs sont insufisant.

Normalement tout est bon dans la config now, il reste éventuellement à ajouter des stacks si les logs sont insufisant.
lbailly changed title from WIP: feat(ulogd): enabling ulogd to feat(ulogd): enabling ulogd 2024-08-28 20:41:47 +02:00
thubrecht reviewed 2024-08-28 20:46:13 +02:00
@ -0,0 +44,4 @@
};
systemd.services.postgresql = {
preStart = lib.mkAfter ''
if test -e "${config.services.postgresql.dataDir}/.first_startup"; then
Owner

Je ne pense pas que ça fasse ce que tu veux

Je ne pense pas que ça fasse ce que tu veux
Author
Member

Le but c'est que le script ne soit exec que quand le serveur s'initialise, il suppr toute les données.
Je peux pas utiliser .first_statup car il est suppr au tout début de postStart, ducoup je recréer le flag.

Le but c'est que le script ne soit exec que quand le serveur s'initialise, il suppr toute les données. Je peux pas utiliser .first_statup car il est suppr au tout début de postStart, ducoup je recréer le flag.
Owner

Mais en pratique ça ne tourne jamais donc je vois pas trop l'intérêt de le mettre

Mais en pratique ça ne tourne jamais donc je vois pas trop l'intérêt de le mettre
Author
Member

si on doit redéployer un routeur avec log, on aura le nécessaire dans le module sans avoir à recheck comment deploy ulogd, sinon le ensureUsers et ensureDatabases ne servent pas non plus...

si on doit redéployer un routeur avec log, on aura le nécessaire dans le module sans avoir à recheck comment deploy ulogd, sinon le `ensureUsers` et `ensureDatabases` ne servent pas non plus...
Author
Member

En vérité, il faudrait plutôt check l'existence des tables pour le cas où le module est déployé sur une machine qui a déjà un pgsql, mais bon...

En vérité, il faudrait plutôt check l'existence des tables pour le cas où le module est déployé sur une machine qui a déjà un pgsql, mais bon...
Owner

Oui, ou alors faire un preStart dans l'unit de ulogd en sauvegardant le state dans var/lib/ulogd, dans ce cas on pourra charger les tables lors de la première activation du module

Oui, ou alors faire un preStart dans l'unit de ulogd en sauvegardant le state dans `var/lib/ulogd`, dans ce cas on pourra charger les tables lors de la première activation du module
thubrecht reviewed 2024-08-29 13:26:59 +02:00
@ -0,0 +8,4 @@
services = {
ulogd = {
enable = true;
logLevel = 5;
Owner

Si ça fonctionne désormais ce n'est pas la peine d'activer les logs de debug, à part spammer journald

Si ça fonctionne désormais ce n'est pas la peine d'activer les logs de debug, à part spammer journald
Author
Member

D'après la doc, 5 correspond au niveau notice de log, 1 serai debug. Si tu veux on peut monter à 7 pour avoir que les erreurs.

D'après [la doc](https://search.nixos.org/options?channel=unstable&show=services.ulogd.logLevel), 5 correspond au niveau notice de log, 1 serai debug. Si tu veux on peut monter à 7 pour avoir que les erreurs.
lbailly force-pushed ulogd from a301fe0fd1 to f356f9fa4e 2024-09-07 13:30:21 +02:00 Compare
rlahfa merged commit 3b766e6a2b into main 2024-09-08 12:21:08 +02:00
Sign in to join this conversation.
No description provided.