From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: IPFire 2.29 - Core Update 185 is available for testing Date: Wed, 27 Mar 2024 12:25:25 +0100 Message-ID: <41ff5f74-2790-42c2-b892-4a6287b6ee60@ipfire.org> In-Reply-To: <2D5054B3-B378-42BB-B65E-A9AF7160B312@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8642989387225728511==" List-Id: --===============8642989387225728511== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 27/03/2024 11:14, Michael Tremer wrote: > I ran this multiple times on my machine and it worked. Okay, then let's leave it as it is. I clearly have some sort of corner=20 situation. The code is nicer now anyway. Having two entries does not cause any problems. I have checked in the=20 iptables and the LOGDROPHOSTILEIN and LOGDROPHOSTILEOUT only have one=20 entry each in the iptables so the logging will occur correctly. If I press the Save button on the FW Options page then the settings file=20 is updated correctly anyway. So even if some other people end up with two entries everything will=20 still work correctly anyway. So considering this issue fixed now. Regards, Adolf. >=20 >> On 27 Mar 2024, at 10:05, Adolf Belka wrote: >> >> Hi Michael, >> >> On 26/03/2024 15:44, Michael Tremer wrote: >>> Does this work? >> Progress has been made but not fixed. >> >> Now there were only one additional entry added to the end of the file for = LOGDROPHOSTILEIN & LOGDROPHOSTILEOUT but the entries were in the file already. >> >> SHOWTABLES=3Don >> SHOWCOLORS=3Don >> DROPNEWNOTSYN=3Doff >> DROPSPOOFEDMARTIAN=3Don >> DROPWIRELESSINPUT=3Doff >> SHOWDROPDOWN=3Don >> DROPOUTGOING=3Don >> DROPWIRELESSFORWARD=3Don >> DROPPORTSCAN=3Don >> DROPFORWARD=3Don >> DROPINPUT=3Don >> DROPHOSTILE=3Don >> FWPOLICY=3DDROP >> LOGDROPHOSTILEIN=3Don >> LOGDROPCTINVALID=3Don >> FWPOLICY2=3DDROP >> DROPSAMBA=3Don >> MASQUERADE_BLUE=3Don >> MASQUERADE_GREEN=3Don >> FWPOLICY1=3DDROP >> SHOWREMARK=3Don >> LOGDROPHOSTILEOUT=3Don >> MASQUERADE_ORANGE=3Don >> DROPPROXY=3Doff >> LOGDROPHOSTILEIN=3Don >> LOGDROPHOSTILEOUT=3Don >> >> It acts like the code is not seeing the entries earlier in the file. Howev= er if I run the code directly on the file from the command line it does find = the earlier lines and doesn't add anything. >> >> The permissions and ownership of the optionsfw/settings file is the same a= s all the other files in that area so nothing abnormal there that I can find. >> >> This time there were no error messages in the update-core-upgrade-185.log >> >> Real puzzler. >> >> Do you or anyone else find the same thing or is it only my system? >> >> Regards, >> Adolf. >> >>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3Dc2df627c8c2= 9d43d1acfbdf60878f6a3339151e1 >>>> On 26 Mar 2024, at 12:35, Adolf Belka wrote: >>>> >>>> Hi Michael, >>>> >>>> On 26/03/2024 12:45, Michael Tremer wrote: >>>>> Hello, >>>>>> On 26 Mar 2024, at 11:37, Adolf Belka wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 26/03/2024 11:55, Michael Tremer wrote: >>>>>>> Hello everyone, >>>>>>> I am not entirely sure what corner-case we are talking about here, bu= t I ran the code twice on a test system to see if it actually does what it is= supposed to do. I felt it did. >>>>>> If I ran the code myself on my vm system, it did the right things. It = was when I ran the CU185 update that it went wrong but I couldn't come up wit= h any idea for why. >>>>>> >>>>>>> But is it pretty? Not quite, so let=E2=80=99s dive into a little bit = of shell :) >>>>>> Well I am definitely not an expert at bash. Whenever I want to do some= thing I always have to search on the internet so that might cause me to have = ugly code. I try and learn as I go along, if I can remember. >>>>> That is why I thought I would give a little bit of feedback. I think so= metimes a problem is easier than it feels. >>>> :+1: >>>>> And after all, the code that you proposed does work. There is nothing w= rong with that in that regard. >>>>>>>> On 25 Mar 2024, at 16:29, Adolf Belka wro= te: >>>>>>>> >>>>>>>> Hi Nick, >>>>>>>> >>>>>>>> On 25/03/2024 16:49, Nick Howitt wrote: >>>>>>>>> I don't have the answer to why it is adding the lines, but can I as= k if this scriptlet is safe? >>>>>>>>> >>>>>>>>> If you have one line and not the other in the file you will end up = with three lines, the original plus two new. Also, if someone has preffed the= lines off, they will gain two lines preffed on. >>>>>>>>> >>>>>>>> Good point. If the lines are present with =3Don or =3Doff then the o= ptions have been saved and the update code would not be needed. >>>>>>>>> Perhaps it is safer to run the tests independently, just checking f= or ^LOGDROPHOSTILEIN=3D and ^LOGDROPHOSTILEOUT=3D >>>>>>>>> >>>>>>>>> if ! grep "^LOGDROPHOSTILEIN=3D" /var/ipfire/optionsfw/settings; th= en >>>>>>>>> sed -i '$ a\LOGDROPHOSTILEIN=3Don' /var/ipfire/optionsfw/setti= ngs >>>>>>>>> /usr/local/bin/firewallctrl >>>>>>>>> fi >>>>>>>>> if ! grep "^LOGDROPHOSTILEOUT=3D" /var/ipfire/optionsfw/settings; t= hen >>>>>>>>> sed -i '$ a\LOGDROPHOSTILEOUT=3Don' /var/ipfire/optionsfw/sett= ings >>>>>>>>> /usr/local/bin/firewallctrl >>>>>>>>> fi >>>>>>>>> >>>>>>> This is probably the cleanest version that we have seen here. >>>>>>> Formerly the if statement looked like this: >>>>>>>>>> if ! [ $(grep "LOGDROPHOSTILEIN=3Don" /var/ipfire/optionsfw/settin= gs) ] >>>>>>> This will run a sub shell $(=E2=80=A6) with grep in it which is not n= ecessary since if alone can determine the exit code of a command. >>>>>>>>> if ! grep "^LOGDROPHOSTILEIN=3D" /var/ipfire/optionsfw/settings; th= en >>>>>>> So this eliminates the sub shell, a couple of brackets and dollar sig= ns and is a lot easier to read. >>>>>> The [] brackets were something I read some time ago that I should have= in place when I did my original internet searching so have always used them = in other places in IPFire. >>>>>> Happy to be corrected and change to this approach. >>>>> [ is actually a command. It is somewhere in /usr/bin or /bin and a shor= tcut to =E2=80=9Ctest=E2=80=9D: >>>> Ah, I have heard of that. Thanks. >>>>> https://www.man7.org/linux/man-pages/man1/test.1.html >>>>>>>>> sed -i '$ a\LOGDROPHOSTILEOUT=3Don' /var/ipfire/optionsfw/settings >>>>>>> This could have simply been an echo: >>>>>>> echo "LOGDROPHOSTILEOUT=3Don=E2=80=9D >> /var/ipfire/optionsfw/set= tings >>>>>>> That would even be executed by the shell without forking any subproce= sses and therefore be the fastest option. Not very important if there is only= two strings to write, but sometimes there are loops that are being called th= ousands of times=E2=80=A6 You are going to save a lot of time and will also h= ave easier code to read. >>>>>> >>>>>> The search I did gave examples of sed, grep, awk but not echo. >>>>>> It does seem easier when you point it out. >>>>>> Will also change to that. >>>>> No need this time. >>>>>>> Reloading the firewall once would have been fine for me, even if ther= e have been no changes whatsoever. >>>>>>>> I will look at making that update. >>>>>>>> The only problem is I can't easily test that it solves the problem I= have found from the update as the original script does not cause the same re= sult when I manually run it. >>>>>>>> >>>>>>>> However, definitely want to change the script anyway to make sure th= at I don't end up with both =3Don and =3Doff fore the same setting which migh= t occur if someone has already adjusted their preferences. >>>>>>>> >>>>>>>> I will probably have to submit a patch for the modification and then= test it in the CU185 Testing release when it is updated. >>>>>>> Thank you. I will merge it shortly. >>>>>> You have merged my v2 example but it still had the square brackets and= the subshell and the sed etc. >>>>>> >>>>>> Should I do an update to the v2 version to get rid of the square brack= ets etc as discussed above. >>>>> I think we can leave it. This will waste 10ms of time when running the = update which really isn=E2=80=99t an issue whatsoever :) >>>> >>>> Interestingly enough it is still giving me the same problem of an additi= onal two entries for LOGDROPHOSTILEIN=3Don if the entry was already present i= n the file and the same for the OUT version. >>>> >>>> If the file started with no LOGDROPHOSTILEIN or LOGDROPHOSTILEOUT entry = then the update givers me the correct result of one entry for each. >>>> >>>> I just looked at the update-core-upgrade-185.log and it has the followin= g two lines. >>>> >>>> ./update.sh: line 120: [: LOGDROPHOSTILEIN=3Don: unary operator expected >>>> ./update.sh: line 121: [: LOGDROPHOSTILEOUT=3Don: unary operator expected >>>> >>>> Maybe that is what is causing me the problem. Any suggestions of what wo= uld be causing those errors. The quoted line numbers don't show the text that= is shown in the error. >>>> >>>> Regards, >>>> >>>> Adolf. >>>>> >>>>> -Michael >>>>>> >>>>>> Adolf. >>>>>>> -Michael >>>>>>>> >>>>>>>> Regards, >>>>>>>> Adolf. >>>>>>>>> It does, however, cost another firewall restart, which could be eva= ded with a few more lines of script. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Nick >>>>>>>>> >>>>>>>>> On 25/03/2024 15:02, Adolf Belka wrote: >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I am having difficulty understanding something that is happening w= ith the Core Update to 185. >>>>>>>>>> >>>>>>>>>> I added the following code into the update.sh script >>>>>>>>>> >>>>>>>>>> # Check if the drop hostile in and out logging options need to be = added >>>>>>>>>> # into the optionsfw settings file and apply to firewall >>>>>>>>>> if ! [ $(grep "LOGDROPHOSTILEIN=3Don" /var/ipfire/optionsfw/settin= gs) ] && \ >>>>>>>>>> ! [ $(grep "LOGDROPHOSTILEOUT=3Don" /var/ipfire/optionsfw/set= tings) ]; then >>>>>>>>>> sed -i '$ a\LOGDROPHOSTILEIN=3Don' /var/ipfire/optionsfw= /settings >>>>>>>>>> sed -i '$ a\LOGDROPHOSTILEOUT=3Don' /var/ipfire/optionsf= w/settings >>>>>>>>>> /usr/local/bin/firewallctrl >>>>>>>>>> fi >>>>>>>>>> >>>>>>>>>> If I do an update with a Core Update 183 version that has the LOGD= ROPHOSTILEIN and LOGDROPHOSTILEOUT entries in optionsfw/settings missing then= the update adds in the two lines shown. So working correctly. >>>>>>>>>> >>>>>>>>>> However if the Core Update 183 has the two entries already in the = optionsfw/settings file then the above code ends up with two more copies of e= ach put into the file as following. >>>>>>>>>> >>>>>>>>>> FWPOLICY=3DDROP >>>>>>>>>> SHOWTABLES=3Don >>>>>>>>>> DROPPROXY=3Doff >>>>>>>>>> LOGDROPHOSTILEIN=3Don >>>>>>>>>> LOGDROPHOSTILEOUT=3Don >>>>>>>>>> LOGDROPHOSTILEIN=3Don >>>>>>>>>> LOGDROPHOSTILEOUT=3Don >>>>>>>>>> >>>>>>>>>> However if I take a vm with optionsfw/settings containing the two = entries already and run the update code shown above manually via a script on = the vm then it does not add any extra lines in. If the vm has the two entries= missing and I run the script manually then it adds in one entry for each. >>>>>>>>>> >>>>>>>>>> So I do not understand at all why the code I put into the update.s= h file >>>>>>>>>> >>>>>>>>>> 1) Does not recognise that the entries already exist in the settin= gs file. >>>>>>>>>> 2) Then prints the entries twice. >>>>>>>>>> >>>>>>>>>> when it is run in the update.sh via an upgrade. >>>>>>>>>> >>>>>>>>>> Any help with understanding what is going wrong with the code I wr= ote would be very much appreciated. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Adolf. >>>>>>>>>> >>>>>>>>>> On 25/03/2024 10:15, IPFire Project wrote: >>>>>>>>>>> This update is another testing version for IPFire: It comes with = the brand release of the IPFire IPS, a number of bug fixes across the entire = system and a good amount of package updates. Test it while it's still hot! >>>>>>>>>>> =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2= =80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C = =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> IPFire_ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> IPFire 2.29 - Core Update 185 is available for testing >>>>>>>>>>> >>>>>>>>>>> This update is another testing version for IPFire: It comes with = the brand release of the IPFire IPS, a number of bug fixes across the entire = system and a good amount of package updates. Test it while it's still hot! >>>>>>>>>>> >>>>>>>>>>> Read The Full Post On Our Blog >>>>>>>>>>> >>>>>>>>>>> The IPFire Project, c/o Lightning Wire Labs GmbH, Gerhardstra=C3= =9Fe 8, 45711 Datteln, Germany >>>>>>>>>>> >>>>>>>>>>> Unsubscribe >>>>>>>>>>> >>>>>>>> >>>>>>>> --=20 >>>>>>>> Sent from my laptop >=20 --=20 Sent from my laptop --===============8642989387225728511==--