Gaia Embedded Syslog Severity

[lbcadenco10]

Anyone know how to change the syslog severity on Gaia Embedded appliances? I've seen sk92798 but this appears to only apply to Gaia appliances. I edited /etc/syslog.conf to only send warning and higher level logs to our remote syslog servers but "logger -p local4.info info2" and "tcpdump" shows informational level logs still being sent. I'm guessing syslogd needs to be restarted in order for the changes to go into effect, but "service syslog restart" is not a valid command in expert mode.

[PhoneBoy]

I believe if you kill the process it will restart on its own.
Or maybe do a kill -1 which may cause it to reread the config file.
Must caution you about editing config files directly as they can get overwritten on a reboot or upgrade.

[lbcadenco10]

Thanks, I'll give that a shot. Is there a better approach to modifying the syslog severity on SMB appliances?

[G_W_Albrecht]

There is no way - according to GAiA Embedded CLI, you can define external syslog servers by the command

# add syslog-server

and one parameter is

sent-logs Determine which logs types will be sent to the System Log Server

Options: system-logs, security-logs, system-and-security-logs

[John_Fleming]

### unsupported bla bla bla don't want to hear it ###

ok here is my advice on how to hack this to do what you want. No idea if this will work on all scenarios but there is a chance this will hold even during upgrades.

Come up with a custom rsyslog.conf file.

Store it in /pfrm2.0/etc

edit /pfrm2.0/etc/userScript (not created by default perms should be root:root 755)

have userScript file copy /pfrm2.0/etc/rsyslog.conf to /etc

#I'm saying do this because / (and thus /etc) is a rootfs which is basically a memory based filesystem.

have userScript restart rsyslogd. You'll have to find pid kill it and start it.

Now in theory it will get reinstalled on boot up.

Last step is edit /pfrm2.0/etc/additional_settings_file_list

and add /pfrm2.0/etc/rsyslog.conf. This *should* protect you from upgrades. 

edge cases this won't help with..

someone editing syslog settings via clish or webui. Most likely your settings will be lost until you rerun userScript commands or reboot. Possible other changes in clish/webui might trigger reloading build rsyslog.conf. 

[John_Fleming]

and if you want to get super hacky.. uh.

looks like /pfrm2.0/bin/logControlConfig is the script that generates the /etc/rsyslog.conf.

Would need to do the same thing i pointed out before.. edit userScript to do something with a master copy of this. This dir is mounted normally so should stick around unless an upgrade is done. Again adding ref to that additional file might address that but we're out in crazy town now.