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

[Stefan Schantl <stefan.schantl@ipfire.org>]

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

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=ipfire-2.x.git;a=commit;h=85b1d83b2a6fe2beb8169f3e810e915c4ad54036

Please report if you are affected again by this issue.

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