https://community.splunk.com/t5/Splunk-Enterprise/How-to-deal-with-unattended-universal-forwarder-upgrade/m-p/656274#M17250 <P>Hi, I'm in the middle of testing deployment of the UF for a new setup and I started with 9.0.1, deploying it with ansible from a local yum repository as the initial push. (that' s the gist of it, bit more complex infrastructure behind it but not really relevant)</P><P>But now 9.1.1 came out which was pointed out to me due to a security alert so I updated the package on our repository, hit 'yum update'&nbsp; on one of my test servers, and this broke the UF.</P><P>Apparently it needs to be started manually once with '<SPAN>--accept-license --answer-yes --no-prompt</SPAN>'&nbsp; to complete the upgrade and accept the license .. again .. ?</P><P>Is there a clever way of dealing with this so it just works after upgrading the rpm ? Short of modifying the rpm's spec file so it does some starting and stopping while the rpm is being upgraded.</P><P>Manually doing this in case there happens to be an update is just not an option due to the number of hosts, our regular updates run unattended with basically just a 'yum/dnf update -y'</P><P>Modifying the systemd file so it just starts with the required parameters does not appear be working with the '<SPAN>_internal_launch_under_systemd' , replacing that with the old 'start etc' makes the UF not work with systemd anymore.<BR /></SPAN><SPAN>RHEL9 is going to forego the init.d folder I think so using older more flexible sysV scripts is not an option either.</SPAN></P><P><SPAN>Any sort of manual intervention when there happens to be a new version is highly undesirable.</SPAN></P> Thu, 31 Aug 2023 14:01:26 GMT Arjan1 2023-08-31T14:01:26Z https://community.splunk.com/t5/Splunk-Enterprise/How-to-deal-with-unattended-universal-forwarder-upgrade/m-p/656274#M17250 <P>Hi, I'm in the middle of testing deployment of the UF for a new setup and I started with 9.0.1, deploying it with ansible from a local yum repository as the initial push. (that' s the gist of it, bit more complex infrastructure behind it but not really relevant)</P><P>But now 9.1.1 came out which was pointed out to me due to a security alert so I updated the package on our repository, hit 'yum update'&nbsp; on one of my test servers, and this broke the UF.</P><P>Apparently it needs to be started manually once with '<SPAN>--accept-license --answer-yes --no-prompt</SPAN>'&nbsp; to complete the upgrade and accept the license .. again .. ?</P><P>Is there a clever way of dealing with this so it just works after upgrading the rpm ? Short of modifying the rpm's spec file so it does some starting and stopping while the rpm is being upgraded.</P><P>Manually doing this in case there happens to be an update is just not an option due to the number of hosts, our regular updates run unattended with basically just a 'yum/dnf update -y'</P><P>Modifying the systemd file so it just starts with the required parameters does not appear be working with the '<SPAN>_internal_launch_under_systemd' , replacing that with the old 'start etc' makes the UF not work with systemd anymore.<BR /></SPAN><SPAN>RHEL9 is going to forego the init.d folder I think so using older more flexible sysV scripts is not an option either.</SPAN></P><P><SPAN>Any sort of manual intervention when there happens to be a new version is highly undesirable.</SPAN></P> Thu, 31 Aug 2023 14:01:26 GMT https://community.splunk.com/t5/Splunk-Enterprise/How-to-deal-with-unattended-universal-forwarder-upgrade/m-p/656274#M17250 Arjan1 2023-08-31T14:01:26Z