From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Schantl To: development@lists.ipfire.org Subject: Re: New IDS won't unlink "/tmp/ids_page_locked" Date: Mon, 14 Mar 2022 06:08:36 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4230273042717515598==" List-Id: --===============4230273042717515598== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Mathias, thanks for reporting your issue here. The IDS page locking issue should be fixed and shipped with the final C164 release. See: https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D85b1d83b2a6fe2beb81= 69f3e810e915c4ad54036 Please report if you are affected again by this issue. You safely can drop those folder and files from "/tmp". Best regards, -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 prin= t 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 fil= e still exists. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0while(-e $IDS::ids_page_loc= k_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 creat= e the file. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&create_empty_file($ids_pag= e_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 the > 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: $Lang= ::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 --===============4230273042717515598==--