Originally posted by: The_Doctor

Are there any plans to include an option to configure syslog from the Enhanced interface ?  And yes, I'm not seeing the function in the classic GUI version either.

If not...... then I guess we will continue to use the CLI........ e.g. chhmc -c syslog     etc........... although the syslog facility could use some improved filtering options.

Originally posted by: sashok

Correct, rsyslog configuration is via the *hmc CLI only.

Can you elaborate on your comment on filtering?  In the V8R8.2 release, we added support for --input "filter_msg_contains_discard_strings= <string>" | -f <file name> to chhmc, so are you saying this is inadequate?

Originally posted by: The_Doctor

I think I'm probably saying my understanding of "filter_msg_contains_discard_strings" is inadequate..... but I'm slowly educating myself.

In putting together a sample of what might be considered inadequate filtering, I think I'm starting to understand the magic.  I started with:

chhmc -c syslog -s add -a 172.25.9.104

This appears to cause EVERYTHING from the HMC to be logged at my syslog server.  No surprise.  For these tests, my AIX syslog server is purposely set at:

*.debug   /tmp/var/hmc.log     rotate size 1m files 7

A small example of just the HMC "info" records grep'd from my syslog server is next:

Jan 15 09:00:01 hmccr7 :info HMCCR7 CROND[17686]: (root) CMD (/opt/hsc/bin/utilcollect 1)
Jan 15 09:00:35 hmccr7 daemon:info HMCCR7 dhcpd: DHCPREQUEST for 10.0.0.2 from 40:f2:e9:a5:28:a0 via eth4
Jan 15 09:00:35 hmccr7 daemon:info HMCCR7 dhcpd: DHCPACK on 10.0.0.2 to 40:f2:e9:a5:28:a0 via eth4
Jan 15 09:01:01 hmccr7 :info HMCCR7 CROND[18683]: (root) CMD (run-parts /etc/cron.hourly)
Jan 15 09:01:42 hmccr7 daemon:info HMCCR7 dhclient[11370]: DHCPREQUEST on usb0 to 169.254.95.118 port 67 (xid=0x6a0acc4c)
Jan 15 09:01:42 hmccr7 daemon:info HMCCR7 dhclient[11370]: DHCPACK from 169.254.95.118 (xid=0x6a0acc4c)
Jan 15 09:01:44 hmccr7 daemon:info HMCCR7 dhclient[11370]: bound to 169.254.95.120 -- renewal in 256 seconds.
Jan 15 09:02:01 hmccr7 :info HMCCR7 CROND[19790]: (root) CMD (/opt/hsc/bin/backupLog)
Jan 15 09:04:49 hmccr7 daemon:info HMCCR7 dhcpd: DHCPREQUEST for 10.0.0.2 from 40:f2:e9:a5:28:a0 via eth4
Jan 15 09:04:49 hmccr7 daemon:info HMCCR7 dhcpd: DHCPACK on 10.0.0.2 to 40:f2:e9:a5:28:a0 via eth4
Jan 15 09:06:00 hmccr7 daemon:info HMCCR7 dhclient[11370]: DHCPREQUEST on usb0 to 169.254.95.118 port 67 (xid=0x6a0acc4c)
Jan 15 09:06:00 hmccr7 daemon:info HMCCR7 dhclient[11370]: DHCPACK from 169.254.95.118 (xid=0x6a0acc4c)
Jan 15 09:06:01 hmccr7 daemon:info HMCCR7 dhclient[11370]: bound to 169.254.95.120 -- renewal in 229 seconds.

I manually altered the above messages to show portions in RED which I assume matches the TEXT of the message coming from the HMC.  Regardless, now I want to eliminate / filter all the CRON & DAEMON INFO records originating at the HMC.  Tough (impossible?) to do:

chhmc -c syslog -s modify -a 172.25.9.104 --input \"\"filter_msg_contains_discard_strings=:info\"\"

does not cut the mustard.  All the INFO records still come over.  Nothing is filtered.  BUT as expected if I modify the "target" syslog server to say:

*.debug;daemon.none   /tmp/var/hmc.log     rotate size 1m files 7

then I can drop the DAEMON INFO records BUT remember, it's done at the target syslog server.

I then played with the "filter_msg_contains_discard_strings=" and found that I can filter specific messages based solely on message text.  So if I filter on anything marked in RED above, such as "filter_msg_contains_discard_strings=DHCP,bound", it seems I can drop any specific messages that match, at the source HMC.

Bottom line..... I was looking for a way to:

• MASS filter CRON & DAEMON INFO (and maybe some higher priority) records AT THE SOURCE without specifying 25, 50, maybe a 100 text filters..... when just 1 text filter might INADVERTENTLY drop key System Events that I need to see.  aka.... I can't afford to drop key System Events due to an unintended filter match.
• or said another way........ to also filter at the HMC with options like......  daemon.none  OR  daemon.error (to get error & above msgs) 

Anyway, I think I'm starting to understand the design intent...... if desired, permit some filtering at the HMC, but do the bulk of the filtering at the target syslog server.  Hope this long winded post is accurate & makes sense.