From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: IPFire 2.27 - Core Update 165 is available for testing Date: Fri, 18 Mar 2022 13:58:01 +0100 Message-ID: In-Reply-To: <8776fffb-1491-3cac-4817-b7f3c3bae661@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1723282728161133687==" List-Id: --===============1723282728161133687== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, Ignore my comments in the thread below on the fcron.daily issue. This is noth= ing to do with the CU164 to CU165. It is a bug but related to the fact that a= backup does not restore the suricata link in either the fcron.daily or fcron= .weekly or not at all depending on the update frequency setting. So if the link is there then a CU maintains it where it is. I have confirmed this by installing a CU163 vm restoring a backup from that t= ime and then discovering that the link was not there. Updated the frequency s= etting to get the link created and confirmed its presence. Then I did a CU to 164 and after reboot the suricata link was still there. Th= en did the same from CU164 to CU165 Testing and also the suricata link stayed= there. What happened was that I had a vm install some time back and did a restore fr= om a backup I had and did not notice that the suricata link was not there. So= this vm has not been doing daily backups for a while. Not so easily noticeab= le as I don't leave the vm's running overnight unless I am doing a CU Testing= evaluation. I will raise a bug for the lack of storing the suricata link. Regards, Adolf. On 18/03/2022 12:37, Adolf Belka wrote: > Hi All, > > After changing from daily to weekly and back to daily to get the suricata l= ink in the fcron.daily I can confirm that the updates for the two providers I= have selected worked overnight. Also no spinning disk when I went to the IPS= page. so everything looks good. > > Regards, > > Adolf > > On 17/03/2022 10:50, Adolf Belka wrote: >> Hi All, >> >> Further update. >> >> I registered for the Talos VRT Registered rulesets. >> >> I then=C2=A0 added the set to my IPS and after a while the IPS page came b= ack now with Talos VRT added to the providers. I then pressed customise rules= et and got the rules. I selected some rulesets from Talos and then pressed ap= ply. I got the spinning symbol and the browser status bar showed activity ong= oing. After some time the browser pointer spinning disk disappeared and the s= tatus bar was empty but the IPFire IPS spinning symbol continued. I checked i= n /tmp and there was no lock file but there was an ids_tmp directory. >> >> >> I then selected another wui menu and then went back to the IPS menu and go= t the screen with three providers. Selected customise ruleset again and got t= he table headed ruleset with the buttons Back and Apply but absolutely no rul= esets. >> >> >> I then deleted the Talos VRT ruleset and after some time got back the main= page with only two providers now. >> >> I then pressed customise ruleset again and got all the rulesets for the tw= o remaining providers back again. >> >> So the Talos VRT Registered ruleset=C2=A0 still has some issues. >> >> >> Regards, >> >> Adolf. >> >> On 17/03/2022 10:29, Adolf Belka wrote: >>> Hi All, >>> >>> Running 165 Testing for a day now. Most things working well. >>> >>> One thing I found is that this morning the daily update of the IPS rulese= ts had not taken place although the updates were set to occur in 163 and also= showed on the WUI page as being set for daily. >>> >>> After some searching I found that the suricata rules update link was not = set in the /etc/fcron.daily directory. Pressing save on the IPS page made no = difference. >>> I then changed the setting to weekly and pressed save and the link was th= en created in the fcron.weekly directory. Then I changed it to daily and pres= sed save and now I have the link in my fcron.daily directory but it was not p= resent after the upgrade process. >>> >>> It is no running with updated rulesets and I will check tomorrow how the = update went. >>> >>> In terms of test results, everything was running after the upgrade (On my= testbed I have everything set up and running although I don't yet have a wor= king IPSec client but that should be available for the next testing. >>> >>> OpenVPN Roadwarrior connections successfully running. >>> Web Proxy is up and running and working. >>> Openssh is up and working. >>> OpenVPN Roadwarrior connections log working. >>> Domain Name System fully working with five DNS TLS servers. >>> DHCP server up and fully working. >>> Backup system working. >>> All graphs working as before. >>> All Firewall Log Charts working. >>> >>> Regards, >>> Adolf. >>> >>> On 15/03/2022 12:40, IPFire Project wrote: >>>> IPFire Logo >>>> >>>> there is a new post from Michael Tremer on the IPFire Blog: >>>> >>>> *IPFire 2.27 - Core Update 165 is available for testing* >>>> >>>> =C2=A0=C2=A0=C2=A0 Another update is ready for testing: IPFire 2.27 - Co= re Update 165. It comes with various updates for the firewall engine that imp= rove its performance and increase its flexibility, as well as with an updated= toolchain, Python 3.10 and various more bug and security fixes. >>>> >>>> Click Here To Read More >>>> >>>> The IPFire Project >>>> Don't like these emails? Unsubscribe . >>>> --===============1723282728161133687==--