You might be able to do it in an unsupported way by modifying the supporting files within the application directory that govern how the processes work. If successful, your system could be subject to instability and likely be broken if when you ever upgrade it.
What's the rationale for wanting to change the standard syslog UDP port used by all Cisco devices?
The reason is quite simple - PI 2.0 doesn't have possibility to forward gathered syslog messages to a third party tool. Something that was available back in CiscoWorks LMS years ago. So we have to create a workaround for our customer. And our idea is to create a script which would run on PI server, listen for syslog messages on standard PI syslog port (UDP 514), and distribute collected syslog messages to PI (to a port different from the standard one) and to a third party tool. This way we would achieve our goal.
So this can't be done without jeopardizing PI stability?
It may be possible (as I mentioned) but it would not be supported.
It would seem to me to be easier to use PI to deploy a configuration change to all the managed devices to add a secondary syslog destination of your thrid party tool.
It is not what we want to get. Third party tool needs to collect network inventory logs from one central place - PI. The same as it was in LMS. And we need a workaround different than configuring all network devices to send logs to a different location.
It doesn't look to be configurable even from the OS level. Even if it were, changing it might break the function in PI itself.
I poked around and the syslog|config.properties file does not specify it. It appears that the process syslog_daemon is listening on UDP 514 and unless someone knows differently I'd guess that's built into it's binary image (or at least the way the server calls the daemon when starting).
ade # pwd
ade # cat syslog_config.properties
ade # pwd
ade # ls -al
drwxr-xr-x 2 root root 4096 Nov 21 11:01 .
drwxr-xr-x 8 root root 4096 Nov 21 11:21 ..
-rwxrwxrwx 1 501 named 237482 Aug 16 07:38 cdb_convert
-rwxrwxrwx 1 501 named 639405 Aug 16 07:38 cdbq
-rwxr-xr-x 1 501 named 554851 Aug 16 07:44 da_daemon
-rwxr-xr-x 1 501 named 21193 Dec 12 2012 savecapture
-rwxr-xr-x 1 501 named 311095 Aug 16 07:44 seed_cb
-rwxr-xr-x 1 501 named 446231 Apr 1 2013 syslog_daemon
We are very close to have a workaround for this syslog messages forwarding that Prime misses.
If Prime 2.0 receives syslog messages from all devices not directly forwarded from devices, but from some kind of syslog proxy (one ip address), can it recognize device ip address from syslog message payload and map it to appropriate device in Prime inventory?
We can see in file /opt/CSCOlumos/decap/data/SyslogRcv_Main_514 that syslog messages are coming (from that syslog proxy), but they are not visible in Prime GUI.