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 11:05:49 +0100 Message-ID: In-Reply-To: <3B903CAE-8F97-43E9-A0E1-D9E556F61501@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5348433402149975307==" List-Id: --===============5348433402149975307== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 LOG= DROPHOSTILEIN & 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. However = 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 as a= ll 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. >=20 > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3Dc2df627c8c29d= 43d1acfbdf60878f6a3339151e1 >=20 >> 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, but = I ran the code twice on a test system to see if it actually does what it is s= upposed to do. I felt it did. >>>> If I ran the code myself on my vm system, it did the right things. It wa= s when I ran the CU185 update that it went wrong but I couldn't come up with = 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 someth= ing I always have to search on the internet so that might cause me to have ug= ly 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 some= times a problem is easier than it feels. >> :+1: >>> And after all, the code that you proposed does work. There is nothing wro= ng with that in that regard. >>>>>> On 25 Mar 2024, at 16:29, Adolf Belka wrote: >>>>>> >>>>>> 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 ask = if this scriptlet is safe? >>>>>>> >>>>>>> If you have one line and not the other in the file you will end up wi= th three lines, the original plus two new. Also, if someone has preffed the l= ines off, they will gain two lines preffed on. >>>>>>> >>>>>> Good point. If the lines are present with =3Don or =3Doff then the opt= ions have been saved and the update code would not be needed. >>>>>>> Perhaps it is safer to run the tests independently, just checking for= ^LOGDROPHOSTILEIN=3D and ^LOGDROPHOSTILEOUT=3D >>>>>>> >>>>>>> if ! grep "^LOGDROPHOSTILEIN=3D" /var/ipfire/optionsfw/settings; then >>>>>>> sed -i '$ a\LOGDROPHOSTILEIN=3Don' /var/ipfire/optionsfw/settings >>>>>>> /usr/local/bin/firewallctrl >>>>>>> fi >>>>>>> if ! grep "^LOGDROPHOSTILEOUT=3D" /var/ipfire/optionsfw/settings; then >>>>>>> sed -i '$ a\LOGDROPHOSTILEOUT=3Don' /var/ipfire/optionsfw/settin= gs >>>>>>> /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/settings= ) ] >>>>> This will run a sub shell $(=E2=80=A6) with grep in it which is not nec= essary since if alone can determine the exit code of a command. >>>>>>> if ! grep "^LOGDROPHOSTILEIN=3D" /var/ipfire/optionsfw/settings; then >>>>> So this eliminates the sub shell, a couple of brackets and dollar signs= and is a lot easier to read. >>>> The [] brackets were something I read some time ago that I should have i= n 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 shortc= ut 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/setti= ngs >>>>> That would even be executed by the shell without forking any subprocess= es and therefore be the fastest option. Not very important if there is only t= wo strings to write, but sometimes there are loops that are being called thou= sands of times=E2=80=A6 You are going to save a lot of time and will also hav= e 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 there = 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 h= ave found from the update as the original script does not cause the same resu= lt when I manually run it. >>>>>> >>>>>> However, definitely want to change the script anyway to make sure that= I don't end up with both =3Don and =3Doff fore the same setting which might = occur if someone has already adjusted their preferences. >>>>>> >>>>>> I will probably have to submit a patch for the modification and then t= est 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 t= he subshell and the sed etc. >>>> >>>> Should I do an update to the v2 version to get rid of the square bracket= s etc as discussed above. >>> I think we can leave it. This will waste 10ms of time when running the up= date which really isn=E2=80=99t an issue whatsoever :) >> >> Interestingly enough it is still giving me the same problem of an addition= al two entries for LOGDROPHOSTILEIN=3Don if the entry was already present in = the file and the same for the OUT version. >> >> If the file started with no LOGDROPHOSTILEIN or LOGDROPHOSTILEOUT entry th= en 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 following = 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 woul= d be causing those errors. The quoted line numbers don't show the text that i= s shown in the error. >> >> Regards, >> >> Adolf. >>> >>> -Michael >>>> >>>> Adolf. >>>>> -Michael >>>>>> >>>>>> Regards, >>>>>> Adolf. >>>>>>> It does, however, cost another firewall restart, which could be evade= d 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 wit= h 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 ad= ded >>>>>>>> # into the optionsfw settings file and apply to firewall >>>>>>>> if ! [ $(grep "LOGDROPHOSTILEIN=3Don" /var/ipfire/optionsfw/settings= ) ] && \ >>>>>>>> ! [ $(grep "LOGDROPHOSTILEOUT=3Don" /var/ipfire/optionsfw/setti= ngs) ]; then >>>>>>>> sed -i '$ a\LOGDROPHOSTILEIN=3Don' /var/ipfire/optionsfw/s= ettings >>>>>>>> sed -i '$ a\LOGDROPHOSTILEOUT=3Don' /var/ipfire/optionsfw/= settings >>>>>>>> /usr/local/bin/firewallctrl >>>>>>>> fi >>>>>>>> >>>>>>>> If I do an update with a Core Update 183 version that has the LOGDRO= PHOSTILEIN and LOGDROPHOSTILEOUT entries in optionsfw/settings missing then t= he update adds in the two lines shown. So working correctly. >>>>>>>> >>>>>>>> However if the Core Update 183 has the two entries already in the op= tionsfw/settings file then the above code ends up with two more copies of eac= h 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 en= tries already and run the update code shown above manually via a script on th= e vm then it does not add any extra lines in. If the vm has the two entries m= issing 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.sh = file >>>>>>>> >>>>>>>> 1) Does not recognise that the entries already exist in the settings= 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 wrot= e 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 th= e brand release of the IPFire IPS, a number of bug fixes across the entire sy= stem 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 th= e brand release of the IPFire IPS, a number of bug fixes across the entire sy= stem 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=9F= e 8, 45711 Datteln, Germany >>>>>>>>> >>>>>>>>> Unsubscribe >>>>>>>>> >>>>>> >>>>>> --=20 >>>>>> Sent from my laptop >=20 >=20 --===============5348433402149975307==--