public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: IPFire 2.29 - Core Update 185 is available for testing
Date: Mon, 25 Mar 2024 17:29:11 +0100	[thread overview]
Message-ID: <01a9d3fb-91da-44a0-a322-b5be135ab797@ipfire.org> (raw)
In-Reply-To: <a4f74e7d-1c12-475c-825a-6bd47aecc190@howitts.co.uk>

[-- Attachment #1: Type: text/plain, Size: 4909 bytes --]

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 
> 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 =on or =off then the options 
have been saved and the update code would not be needed.
> Perhaps it is safer to run the tests independently, just checking for 
> ^LOGDROPHOSTILEIN= and ^LOGDROPHOSTILEOUT=
>
> if ! grep "^LOGDROPHOSTILEIN=" /var/ipfire/optionsfw/settings; then
>     sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings
>     /usr/local/bin/firewallctrl
> fi
> if ! grep "^LOGDROPHOSTILEOUT=" /var/ipfire/optionsfw/settings; then
>     sed -i '$ a\LOGDROPHOSTILEOUT=on' /var/ipfire/optionsfw/settings
>     /usr/local/bin/firewallctrl
> fi
>

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 result when I manually run it.

However, definitely want to change the script anyway to make sure that I 
don't end up with both =on and =off 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 
test it in the CU185 Testing release when it is updated.

Regards,
Adolf.
> It does, however, cost another firewall restart, which could be evaded 
> 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 with 
>> 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=on" /var/ipfire/optionsfw/settings) ] 
>> && \
>>     ! [ $(grep "LOGDROPHOSTILEOUT=on" /var/ipfire/optionsfw/settings) 
>> ]; then
>>          sed -i '$ a\LOGDROPHOSTILEIN=on' /var/ipfire/optionsfw/settings
>>          sed -i '$ a\LOGDROPHOSTILEOUT=on' 
>> /var/ipfire/optionsfw/settings
>>          /usr/local/bin/firewallctrl
>> fi
>>
>> If I do an update with a Core Update 183 version that has the 
>> LOGDROPHOSTILEIN 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 each put into the file as following.
>>
>> FWPOLICY=DROP
>> SHOWTABLES=on
>> DROPPROXY=off
>> LOGDROPHOSTILEIN=on
>> LOGDROPHOSTILEOUT=on
>> LOGDROPHOSTILEIN=on
>> LOGDROPHOSTILEOUT=on
>>
>> 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.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 wrote 
>> 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!
>>> ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌
>>>
>>>
>>>   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 
>>> <https://www.ipfire.org/blog/ipfire-2-29-core-update-185-is-available-for-testing?utm_medium=email&utm_source=blog-announcement>
>>>
>>> The IPFire Project, c/o Lightning Wire Labs GmbH, Gerhardstraße 8, 
>>> 45711 Datteln, Germany
>>>
>>> Unsubscribe <https://www.ipfire.org/unsubscribe>
>>>

-- 
Sent from my laptop


  reply	other threads:[~2024-03-25 16:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <171135811429.1850211.10643578824706352392.ipfire@ipfire.org>
2024-03-25 11:10 ` Adolf Belka
2024-03-25 11:12   ` Michael Tremer
2024-03-25 13:09     ` Adolf Belka
2024-03-25 15:02 ` Adolf Belka
2024-03-25 15:49   ` Nick Howitt
2024-03-25 16:29     ` Adolf Belka [this message]
2024-03-26 10:55       ` Michael Tremer
2024-03-26 11:37         ` Adolf Belka
2024-03-26 11:45           ` Michael Tremer
2024-03-26 12:35             ` Adolf Belka
2024-03-26 14:44               ` Michael Tremer
2024-03-27 10:05                 ` Adolf Belka
2024-03-27 10:14                   ` Michael Tremer
2024-03-27 11:25                     ` Adolf Belka
2024-03-26 12:36           ` Nick Howitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01a9d3fb-91da-44a0-a322-b5be135ab797@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox