Re: New IDS won't unlink "/tmp/ids_page_locked"

[Matthias Fischer <matthias.fischer@ipfire.org>]

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

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=ipfire-2.x.git;a=tree;f=config/rootfiles/core/164/filelists;h=c81a06294cd3527b9b68d1352d487bf1c8f95c9e;hb=refs/heads/core164

> The IDS page locking issue should be fixed and shipped with the final
> C164 release.
> 
> See:
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=85b1d83b2a6fe2beb8169f3e810e915c4ad54036
> 
> 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".
> 
> Best regards,
> 
> -Stefan
>> Hi,
>> 
>> ..I'd like to have *two* problems with the IDS/IPS... ;-)
>> 
>> 
>> 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..."
>> 
>> Despite this message IPS seemed to work.
>> 
>> 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.
>> 
>> Three activated rulesets were running, see attachment "01".
>> 
>> But the Web GUI stopped because of lines 234ff in 'ids.cgi':
>> 
>> ...
>> # Check if the page is locked, in this case, the ids_page_lock_file
>> exists.
>> if (-e $IDS::ids_page_lock_file) {
>>         # Lock the webpage and print notice about autoupgrade of the
>> ruleset
>>         # is in progess.
>>         &working_notice("$Lang::tr{'ids ruleset autoupdate in
>> progress'}");
>> 
>>         # Loop and check if the file still exists.
>>         while(-e $IDS::ids_page_lock_file) {
>>                 # Sleep for a second and re-check.
>>                 sleep 1;
>>         }
>> ...
>> 
>> 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:
>> 
>> ...
>> ## Function to write the lock file for locking the WUI, while
>> ## the autoupdate script runs.
>> #
>> sub lock_ids_page() {
>>         # Call subfunction to create the file.
>>         &create_empty_file($ids_page_lock_file);
>> }
>> 
>> #
>> ## Function to release the lock of the WUI, again.
>> #
>> sub unlock_ids_page() {
>>         # Delete lock file.
>>         unlink($ids_page_lock_file);
>> }
>> ...
>> 
>> Somehow lines 103ff in "/usr/local/bin/update-ids-ruleset" didn't
>> work/weren't executed(?):
>> 
>> ...
>> # Lock the IDS page.
>> &IDS::lock_ids_page();
>> 
>> # The script has requested a lock, so set locket to "1".
>> $locked = "1";
>> 
>> # Grab the configured providers.
>> &General::readhasharray("$IDS::providers_settings_file",
>> \%providers);
>> 
>> # Loop through the array of available providers.
>> foreach my $id (keys %providers) {
>>    # Assign some nice variabled.
>>    my $provider = $providers{$id}[0];
>>    my $autoupdate_status = $providers{$id}[3];
>> 
>>    # Skip the provider if autoupdate is not enabled.
>>    next unless($autoupdate_status eq "enabled");
>> 
>>    # Call the download function and gather the new ruleset for the
>> current processed provider.
>>    if(&IDS::downloadruleset($provider)) {
>>       # Store error message for displaying in the WUI.
>>       &IDS::_store_error_message("$provider: $Lang::tr{'could not
>> download latest updates'}");
>> 
>>       # Unlock the IDS page.
>>       &IDS::unlock_ids_page();
>> 
>>       # Exit.
>>       exit 0;
>>    }
>> ...
>> 
>> Manual updates - yesterday - were ok, but the automatic updates
>> tonight
>> didn't unlink the lock file: IDS GUI stopped at the next call today.
>> 
>> ##########
>> 
>> 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?
>> 
>> And: can anyone confirm these two problems - or reproduce?
>> 
>> Best,
>> Matthias
> 
>