From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: New IDS won't unlink "/tmp/ids_page_locked"
Date: Mon, 14 Mar 2022 18:04:56 +0100
Message-ID: <dbee97c6-baa1-199b-7729-34cd49836785@ipfire.org>
In-Reply-To: <be91bc79988e0bda2328d19f7d93148eb5fb42aa.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5515359637576516445=="
List-Id: <development.lists.ipfire.org>

--===============5515359637576516445==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 14.03.2022 06:08, Stefan Schantl wrote:
> Hello Mathias,

Hi Stefan,

> thanks for reporting your issue here.

No problem - I should have taken a closer look: 'update-ids-ruleset'
seems to be missing in the Core update for Core164, I was still using
the old version from Core163. ;-)

See:
https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dtree;f=3Dconfig/rootfiles/core=
/164/filelists;h=3Dc81a06294cd3527b9b68d1352d487bf1c8f95c9e;hb=3Drefs/heads/c=
ore164

> The IDS page locking issue should be fixed and shipped with the final
> C164 release.
>=20
> See:
> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D85b1d83b2a6fe2beb=
8169f3e810e915c4ad54036
>=20
> Please report if you are affected again by this issue.

I'll test and report.

Best,
Matthias

> You safely can drop those folder and files from "/tmp".
>=20
> Best regards,
>=20
> -Stefan
>> Hi,
>>=20
>> ..I'd like to have *two* problems with the IDS/IPS... ;-)
>>=20
>>=20
>> 1. After upgrading to Core164 yesterday I took a look at the IDS GUI
>> today and found it locked with a spinning wheel at "Ruleset update in
>> progress. Please wait until all operations have completed
>> successfully..."
>>=20
>> Despite this message IPS seemed to work.
>>=20
>> So I searched and found that the file "/tmp/ids_page_locked" still
>> existed. After deleting this file manually the web GUI opened,
>> everything seems normal.
>>=20
>> Three activated rulesets were running, see attachment "01".
>>=20
>> But the Web GUI stopped because of lines 234ff in 'ids.cgi':
>>=20
>> ...
>> # Check if the page is locked, in this case, the ids_page_lock_file
>> exists.
>> if (-e $IDS::ids_page_lock_file) {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# Lock the webpage and pri=
nt notice about autoupgrade of the
>> ruleset
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# is in progess.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&working_notice("$Lang::tr=
{'ids ruleset autoupdate in
>> progress'}");
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# Loop and check if the fi=
le still exists.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0while(-e $IDS::ids_page_lo=
ck_file) {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0# Sleep for a second and re-check.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0sleep 1;
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
>> ...
>>=20
>> I searched again and found that there are two subroutines in
>> '/var/ipfire/ids-functions.pl', lines 1920ff, which are responsible
>> for
>> locking and unlocking this file:
>>=20
>> ...
>> ## Function to write the lock file for locking the WUI, while
>> ## the autoupdate script runs.
>> #
>> sub lock_ids_page() {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# Call subfunction to crea=
te the file.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&create_empty_file($ids_pa=
ge_lock_file);
>> }
>>=20
>> #
>> ## Function to release the lock of the WUI, again.
>> #
>> sub unlock_ids_page() {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# Delete lock file.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0unlink($ids_page_lock_file=
);
>> }
>> ...
>>=20
>> Somehow lines 103ff in "/usr/local/bin/update-ids-ruleset" didn't
>> work/weren't executed(?):
>>=20
>> ...
>> # Lock the IDS page.
>> &IDS::lock_ids_page();
>>=20
>> # The script has requested a lock, so set locket to "1".
>> $locked =3D "1";
>>=20
>> # Grab the configured providers.
>> &General::readhasharray("$IDS::providers_settings_file",
>> \%providers);
>>=20
>> # Loop through the array of available providers.
>> foreach my $id (keys %providers) {
>> =C2=A0=C2=A0 # Assign some nice variabled.
>> =C2=A0=C2=A0 my $provider =3D $providers{$id}[0];
>> =C2=A0=C2=A0 my $autoupdate_status =3D $providers{$id}[3];
>>=20
>> =C2=A0=C2=A0 # Skip the provider if autoupdate is not enabled.
>> =C2=A0=C2=A0 next unless($autoupdate_status eq "enabled");
>>=20
>> =C2=A0=C2=A0 # Call the download function and gather the new ruleset for t=
he
>> current processed provider.
>> =C2=A0=C2=A0 if(&IDS::downloadruleset($provider)) {
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Store error message for displaying in the=
 WUI.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &IDS::_store_error_message("$provider: $Lan=
g::tr{'could not
>> download latest updates'}");
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Unlock the IDS page.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &IDS::unlock_ids_page();
>>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # Exit.
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exit 0;
>> =C2=A0=C2=A0 }
>> ...
>>=20
>> Manual updates - yesterday - were ok, but the automatic updates
>> tonight
>> didn't unlink the lock file: IDS GUI stopped at the next call today.
>>=20
>> ##########
>>=20
>> 2. There still exist a directory '/tmp/isd_tmp' containing 'conf'
>> ('config' and 'map' files from emerging-threats) and a 'rules'-dir
>> containing all '*.rules'-files. Leftovers!? Can I safely delete these
>> dirs?
>>=20
>> And: can anyone confirm these two problems - or reproduce?
>>=20
>> Best,
>> Matthias
>=20
>=20


--===============5515359637576516445==--