Log inRegister
You are here: Boossy » WikiFoswiki » FwIssues

FOSWIKI issues

Wrong translations

  • login page:
    • source: Having problems logging in?
    • translation: Probleemen bij het inloggen?
    • corrected translation: Problemen bij het inloggen?

Rename / Delete topic

  • Rename/delete a topic resulted in an error, although the rename/delete action succeeded.
    • Error in ~/working/logs/error.log: Compilation failed in require at /home/boossybe/domains/boossy.be/public_html/wiki/lib/Foswiki/Plugins/SolrPlugin.pm line 216.
    • solution: disabled the SolrPlugin...
  • Rename a topic that is referred to in a %TREEVIEW%: the topic name is renamed in the %TREEVIEW%, but is not surrounded by double quotes and so doesn't work!

Copy / View revision history / View last change (24/07/'19)

After I switched to the !NatSkin skin, the commands Copy / View revision history / View last change resulted in a 500 error.

Copying the attach command as copy and diff command solved this issue.

See FwCommands.

Encode object version 2.51 does not match bootstrap parameter 3.01 (21/06/'20)

Ik surf naar wiki.boossy.be en ik krijg meteen een vieze Software error in mijn gezicht gegooid:
Encode object version 2.51 does not match bootstrap parameter 3.01 at /usr/lib64/perl5/DynaLoader.pm line 213.
 at /usr/lib64/perl5/DynaLoader.pm line 213.
   DynaLoader::bootstrap('Encode', 3.01) called at /usr/lib64/perl5/DynaLoader.pm line 105
   DynaLoader::bootstrap_inherit('Encode', 3.01) called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 12
   Encode::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   require Encode.pm called at /home/web00929/domains/boossy.be/public_html/wiki/lib/Foswiki/Configure/Load.pm line 22
   Foswiki::Configure::Load::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   require Foswiki/Configure/Load.pm called at /home/web00929/domains/boossy.be/public_html/wiki/lib/Foswiki.pm line 53
   Foswiki::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   require Foswiki.pm called at view line 28
   main::BEGIN() called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13
   eval {...} called at /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm line 13

Tijdelijke oplossing

/home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/Encode.pm hernoemd naar _Encode.pm

MAAR: nu werkt de mail niet meer in de wiki…

Oorzaak & oplossing

  • DirectAdmin: Extra Features > !cPGuard Security
  • menu VIRUS SCANNER > SCANNER LOGS
    • FILENAME: Encode.so, STATUS: DELETED
      => restored from backup (~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Encode.so)
      hierna ging het mailen nog niet, XS.so vereist
    • FILENAME: XS.so, STATUS: DELETED
      => restored from backup (~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Email/Address/XS/XS.so)
      hierna ging het mailen wel opnieuw

Andere terug te plaatsen, verwijderde .so-bestanden

  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Byte/Byte.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/CN/CN.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/EBCDIC/EBCDIC.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/JP/JP.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/KR/KR.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Symbol/Symbol.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/TW/TW.so
  • ~/lib/CPAN/lib/perl5/x86_64-linux-thread-multi/auto/Encode/Unicode/Unicode.so

406 Not Acceptable / 403 Forbidden (21/06/'20)

today (21/06/'20) I wasn't able to login to one of the public webs on my foswiki site.

When I click the log in link, I get:

Forbidden
You don't have permission to access this resource.

Also other public webs (e.g. Main) are visible, but can't be logged in to.

One workaround to log in, is to go to a private web, where immediately the login form is shown, then log in, then go to the public web…

Another workaround is to delete the query string from the url:

FORBIDDEN: http://wiki.boossy.be/bin/login?foswiki_origin=GET%2cview%2c/bin/view/Boossy/WebHome

WORKAROUND 1 OK (private web): http://wiki.boossy.be/bin/view/Yssoob/WebHome

WORKAROUND 2 OK (no query string): http://wiki.boossy.be/bin/login

The link starts to show the logon screen if I shorten it upto: http://wiki.boossy.be/bin/login?foswiki_origin=GET%2cview%2c/bin Once I add another slash, I get the error!

In the meantime (23/06/'20), the message has changed, but the workaround still work:

Not Acceptable
An appropriate representation of the requested resource could not be found on this server.

According to the hosting company, a weekly update had been executed on the shared servers.

DirectAdmin (Apache) Error Log

It took me some time before I realised that the usage and error log I was looking at, was from the domain only, not of the subdomains:
  • in DirectAdmin, go to System Info & Files > Site Summary / Statistics / Logs
  • click on the name of the subdomain that is throwing the error (wiki.boossy.be) and choose Error Log
[:error] 
ModSecurity: Access denied with code 406 (phase 2). 
Match of "contains /wp-admin/admin-ajax.php?action=ime_test_im_path" against "REQUEST_URI" required. 
[file "remote server"] 
[line "-1"] 
[id "410009"] 
[msg "Malware.Expert - query_string: unwanted shell access"] 
[hostname "wiki.boossy.be"] 
[uri "/bin/login"] 
[unique_id "XvMGeb5Rwa83WZiDXjWScwAAAXk"], 
referer: http://wiki.boossy.be/bin/view/Boossy/WebHome

It's clearly meant to avoid access to WordPress admin pages, so it's a false positive in my case (my URL is e.g. http://wiki.boossy.be/app/login?foswiki_origin=GET%2cview%2c/app/view/Boossy/WebHome), but not wanting the hosting company to bother them with an exception only for me, I figured out a solution.

I tried three possibilities:

(0) disable mod_security for wiki.boossy.be
<IfModule mod_security2.c>
   SecFilterEngine Off
   SecFilterScanPOST Off
</IfModule>

or

  
    SecRuleRemoveById 410009
  

But this didn't work, I suppose the hosting company didn't allow my configs.

(1) use short URLs

Inspiration First, I added this to the root .htaccess:
# RewriteEngine On (is already on, so that's why I comment it here
RewriteRule ^([A-Z].*) /home/web00929/domains/boossy.be/public_html/wiki/bin/view/$1 [L]
DirectoryIndex /bin/view

Then I adapted the Foswiki Configuration accordingly:
  • General settings, Web URLs and Paths:
  • Script Url Path: /bin
  • Script Url Path for View:
So I emptied the Script Url Path for View

This effectively solved the problem, but I had no skin (no css)...

Navigating to a .css file also threw an error, e.g. http://wiki.boossy.be/pub/System/PatternSkinTheme/style.css
%ORANGE% _403 Forbidden - You don't have permission to access this resource._ %ENDCOLOR%

In the error log, you read:
%ORANGE%<i>[rewrite:error] </i>%ENDCOLOR%
%ORANGE%<i>AH00670: Options FollowSymLinks and SymLinksIfOwnerMatch are both off, </i>%ENDCOLOR%
%ORANGE%<i>so the RewriteRule directive is also forbidden due to its similar ability to circumvent directory restrictions : </i>%ENDCOLOR%
%ORANGE%<i>/~/pub/System/PatternSkinTheme/style.css</i>%ENDCOLOR%

Also, attachments weren't accessible and images weren't shown, indicating navigating to the pub directory content wasn't allowed.

Adding a .htaccess to the /~/pub folder with the following line solved the problem:
%ORANGE% _Options +SymLinksIfOwnerMatch_ %ENDCOLOR%

I hope this doesn't imply a security risk...

Strangely enough, one day later, the !+SymLinksIfOwnerMatch isn't necessary anymore...

Finally, in order to get the WebHome of my most used web, instead of using a Redirect in .htaccess (which didn't work anymore), I used the built-in !HomePagePlugin in the Foswiki Configuration:
  • navigate to ~/bin/configure (of ~/app/configure als het met 'bin' niet lukt…)
  • choose Extensions in the left bar
  • click on the !HomePagePlugin button/tab
  • fill in the needed value in {HomePagePlugin}{SiteDefaultTopic}: Boossy
Save the changes.

(2) symbolic link to bin
  • 1st link: app (16/04/2021)
  • 2nd link: web (15/11/2023)
Before I tried the short URLs solution, I had another solution/workaround, i.e. a symlink to the app directory:

ln -s bin app

Then I had to change the redirect in the .htaccess of wiki.boossy.be as well:

# Redirect /index.html /bin/view/Boossy/WebHome
Redirect /index.html /app/view/Boossy/WebHome

And finally I adapted the Foswiki Configuration accordingly:
  • General settings, Web URLs and Paths:
  • Script Url Path: /app
  • Script Url Path for View: /app/view
Save your changes.

This finally solved my problem.

403 when trying to edit the topic Win10AppShortcut

Again:
  • in DirectAdmin, go to System Info & Files > Site Summary / Statistics / Logs
  • click on the name of the subdomain that is throwing the error (wiki.boossy.be) and choose Error Log
[Tue Oct 13 21:49:05.796292 2020]
[:error]
[pid 350394:tid 140396248008448]
[client 78.22.157.55:61748]
[client 78.22.157.55] [[ModSecurity][ModSecurity]]: Access denied with code 403 (phase 2). Pattern match "(?:\\\\n|\\\\r)+(?:get|post|head|options|connect|put|delete|trace|propfind|propatch|mkcol|copy|move|lock|unlock)\\\\s+" at MATCHED_VAR. [file "/usr/local/cwaf/rules/12_HTTP_Protocol.conf"]
[line "137"]
[id "217280"]
[rev "6"]
[msg "COMODO WAF: HTTP Request Smuggling Attack||wiki.boossy.be|F|2"]
[data "Matched Data: get found within MATCHED_VAR"]
[severity "CRITICAL"]
[tag "CWAF"]
[tag "Protocol"]
[hostname "wiki.boossy.be"]
[uri "/bin/rest/WysiwygPlugin/tml2html"]
[unique_id "X4YEsbm@82iv9hHt0-6aVgAAGjg"], referer: https://wiki.boossy.be/bin/edit/Boossy/Win10AppShortcut?t=1602618538

A hint to the answer, I found here. Apparently, in the web hosting control panel Plesk, you can adjust settings in the Web Application Firewall.

I found out this can also be achieved in !DirectAdmin, the control panel used by my web hosting company:
  • Account Manager > Domain Setup
  • click on your domain name
  • in the top right corner, click on !ModSecurity
  • now scroll down to Disabled Rules
  • in the ID text box, fill in the id you found in the Error log and click on the DISABLE RULE button: the ID is added to the list with ModSecurity Disabled Rules
Afterwards, I was able to edit the topic.

Expires header in /pub directory (26/06/'20)

In the default .htaccess delivered in the /pub directory, the mod_expires lines are commented out, but it is mentioned that it reduces the load on the server significantly and that you should enable it if you can, to get an improved foswiki experience, so I did…
<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
    ExpiresActive on
    ExpiresDefault "access plus 11 days"
  </filesmatch>
</ifmodule>

Relocate local Perl lib & CPAN lib (26/06/'20)

These libraries were located in /home/web00929/domains/boossy.be/public_html/wiki/lib/CPAN/lib/perl5/x86_64-linux-thread-multi, so public.
  • I moved them to /home/web00929/perl5/x86_64-linux-thread-multi
  • and changed the variable accordingly in ~/bin/LocalLib.cfg:
@localPerlLibPath = ( '/home/web00929/perl5/x86_64-linux-thread-multi', '/home/web00929/perl5/x86_64-linux-thread-multi/CPAN/lib' );

Then I did a test to send a mail (which definitely makes use of such a lib), and this went fine!

Clean environment variables and $PATH variable

After that, I still wanted to clean the environment variables and get a clean$PATH variable.

Source: https://www.tecmint.com/set-unset-environment-variables-in-linux/

I always used set to see the variables, the site above mentions env.

The output is different, the difference between the two commands is explained here: https://www.linuxquestions.org/questions/linux-general-1/set-versus-env-265773/#:~:text=env%20is%20a%20program%20that,brace%20expansion%20within%20the%20shell.
set is a shell command to set the value of a shell attribute variable; these are internal variables used by the shell.

env is a program that runs another program with modified environment variables.

The major difference is that the env command will never modify the shell's own environment (only that of the child process), while set will. Set can also change settings like brace expansion within the shell.

You might also want to look at export, which changes the environment variables for all future commands.

All variables I wanted to modify, were user environment variables, defined in ~/.bashrc. (~ = user's home directory, I remember now, reading the site…) So I could easily correct them using vi.

For the changes to take effect, you have to either logout/login or issue the following command
source ~/.bashrc

User … has used up 0.0% of their bandwidth and 121% of their allocated disk space

(Toegeschreven) Schijf(ruimte) loopt dus vol - nochtans, som van mails, databases en files is nog geen 3GB, en ik heb in principe 5GB ter beschikking.

Root cause: quarantined cache file - and solution

  • DirectAdmin: Extra Features > !cPGuard Security
  • menu VIRUS SCANNER > SCANNER LOGS
    • FILENAME: !Boossy.DBCachePluginDB
    • CATEGORY: Virus File
    • VIRUS DESCRIPTION: {CPG}.php.onedrivephish.001.UNOFFICIAL
    • STATUS: QUARANTINED
dbcacheplugin-vir-odp.png

En dat zo meer dan 1000 keer. Dus 1000 keer 3MB is 3GB natuurlijk!

Eerst gerestored, maar uiteraard werd het bestand opnieuw in quarantaine geplaatst. Dus dan via het tandwieltje gewhitelist:
  • Whitelist Files: Boossy.DBCachePluginDB
Maar dat werkt niet. Reactie van Mirko:

Detecties van het type Virus File kunnen niet gewhitelist worden, alleen Suspicious Files kunnen gehitelist worden. Dit omdat Virus File’s (zeer) ernstige infecties bevatten, in dit geval een onedrive phish infectie. Ik raad dus aan om de hele website te scannen/na te lopen om te achterhalen waar dit probleem vandaan komt en zo het probleem met het schijfruimtegebruik ook op te lossen.

Een manuele scan van de wiki levert echter niets op:
  • SCAN TYPE: PATH
  • TARGET: /home/.../domains/.../public_html/wiki
  • TESTED FILES: 20238
  • INFECTED FILES: 0
  • STATUS: DONE Success
Ik ben dan overgeschakeld naar een ander type caching. In de configure van de wiki:
  • Extensions kiezen & DONE Show expert options inschakelen
  • !DBCacheContrib
  • {DBCacheContrib}{Archivist}:
    • oude waarde: Foswiki::Contrib::DBCacheContrib::Archivist::Storable
    • nieuwe waarde: Foswiki::Contrib::DBCacheContrib::Archivist::Segmentable (zoals bij eXplio)
Voorlopig ziet dat er goed uit - maar de gecachete databestanden bevatten natuurlijk ook wel het woord wandraaif, wat volgens mij de oorzaak was waarom het bestand abusievelijk werd beschouwd als virus.

User … has used up ...% of their bandwidth and >100% of their allocated disk space

  • leeg mailboxen
  • verwijder oudere files uit:
    • /home/web00929/public_html/wiki/working/cache (ouder dan 1 maand)
    • /home/web00929/public_html/wiki/working/tmp (ouder dan 1 week)
Geautomatiseerd kan dat als volgt:
  • find /home/web00929/public_html/wiki/working/cache -type f -mtime +30 -delete
  • find /home/web00929/public_html/wiki/working/tmp -type f -mtime +7 -delete
En volautomatisch, gescheduled in cron, middels het script del-cache-and-tmp.sh, geplaatst in .../wiki/tools, als volgt:
find /home/web00929/domains/boossy.be/public_html/wiki/working/cache -type f -mtime +30 -delete
find /home/web00929/domains/boossy.be/public_html/wiki/working/tmp -type f -mtime +7 -delete

Dit script wordt nu maandelijks uitgevoerd op de 8ste van de maand om 10h20.

Things to check after configuration changes

  • are images still visible?
  • can attachments be downloaded?
  • can attachments be uploaded?

Login always required instead of once a day/month

Settings identical to foswiki settings at the office…

Security and Authentication category
  • Sessions tab
    • Use Client Sessions
    • Session Expiry
    • Cookie Expiry*
  • Login tab
    • Authenticated Scripts


tick
2629746
2629746

niets toegevoegd, in tegenstelling tot wiki op kantoor
Tuning category
  • Cache tab
    • Enable Page-Cache
    • Cache Implementation
    • Cache Root Directory


tick
Foswiki::PageCache::DBI::SQLite
$Foswiki::cfg{WorkingDir}/cache
Extensions category
  • !AutoRedirectPlugin
[
{
'context' => 'view',
'target' => 'WebHome',
'topic' => 'WelcomeUser',
'web' => 'Boossy'
}
]
tick enable
Extensions category
  • !HomePagePlugin
    • !SiteDefaultTopic
    • !GotoHomePageOnLogin


!Boossy.WelcomeUser
tick
* enable Show expert options

Side effect was that I - again - got 406 errors:

https://wiki.boossy.be/ReadOnlyWeb/Topic
was redirected to:
https://wiki.boossy.be/ReadOnlyWeb/Topic?validation_key=...;remember=1;origurl=https://wiki.boossy.be/bin/login

So I returned to the symlink of the bin directory:
ln -s bin app

In combination with the corresponding path settings in Foswiki Configuration :
  • General settings, Web URLs and Paths:
    • Script Url Path: /app
    • Script Url Path for View: /app/view

… but still requiring to login after every browser session!

So I used the quick and dirty way and modified the browser cookie using the !EditThisCookie browser extension:
  • .wiki.boossy.be | SFOSWIKISID
  • check the !HostOnly checkbox
  • uncheck the Session checkbox
  • click on the check icon at the bottom (save cookie settings)

508 Resource Limit Is Reached ► Internal Server Error (16/4/'22-19/4/'22)

Op 22/3/'22 tussen 11 & 13u wordt boossy.be verhuisd. Ogenschijnlijk zonder gevolgen.

Op 29/3 krijg ik 508 Resource Limit Is Reached te zien bij het benaderen van wiki.boossy.be. Maar na de melding aan HostingSquad passeert het vanzelf.

Op zaterdagochtend 16/4 merk ik dezelfde fout 508 Resource Limit Is Reached. Mirko vermoedt een aanval op wiki.boossy.be, met een loop tot gevolg of een slechte beveiliging. Hij had de 'container' gereset, maar zag onmiddellijk weer overbelasting. Hij stelt voor dat ik zoek naar een betere beveiliging. Intussen was de melding veranderd in Internal Server Error.

Uit de events.log van foswiki maak ik op dat:
  • er twee topics zijn die voortdurend benaderd worden:
    • Boossy.FwEventsCalendar
    • Boossy.Test
  • die 'aanvallen' afkomstig zijn van twee ranges en één afzonderlijk IP-adres
De topics heb ik verplaatst naar het niet-publieke gedeelte van de wiki.

De IP-adressen vang ik af in de .htaccess onder de root van de wiki:

<RequireAll>
    Require all granted
    Require not ip 123.45.678.90
    Require not ip 234.567.890
    Require not ip 345.678
</RequireAll>

zie: https://htaccessbook.com/access-control-apache-2-4/

Ik vond het raar dat de statische pagina's nog steeds werkten, en alleen de dynamische van de wiki niet, dus ik vroeg om die laatste weer te activeren. Maar blijkbaar was de hele container actief, en was foutmelding puur afkomstig van wiki.boossy.be. Mirko vermoedt dat er nog PHP-modules ingeschakeld moeten worden (na de verhuizing…).

Nu, foswiki is geen PHP-applicatie. Toch even gekeken, en opcache en redis ingeschakeld, maar in 'DirectAdmin ook vastgesteld dat zowel CGI-Bin als Shell Access (SSH) op disabled stonden:
  • DirectAdmin
  • Your Account: View More
  • Account Configuration tab
Zo doorgegeven aan Mirko. Blijkbaar waren de waarden van CGI-Bin en SSH bij het resetten van de container verloren gegaan. Na het opnieuw inschakelen ging de wiki weer.

Vaststellingen achteraf

  • in de log van de wiki (.../working/logs/events.log) zie ik geen verzoeken meer van de vermelde IP-adressen en -ranges
  • wel komen er nog verzoeken door voor Boossy.FwEventsCalendar en Boossy.Test
Die laatste wil ik eigenlijk ook al op Apache-niveau tegenhouden (zodat die niet de wiki belasten, noch de wiki-log bevuilen). Eerst geprobeerd met een -directive in de .htaccess, maar dat bleek niet te lukken, dan maar met een rewrite:

RewriteEngine On
RewriteCond %{REQUEST_URI} (Boossy.FwEventsCalendar|Boossy.Test) [NC]
RewriteRule .* - [F,L]

Bron: https://techexpert.tips/apache/apache-blocking-access-urls/

uitleg van de vlaggen/flags:
  • [NC] staat voor nocase, dus hoofdletterongevoelig (wat eigenlijk niet moet hier)
  • [F] staat voor Forbidden
  • als je [F] gebruikt, gebruik je impliciet ook [L], hoewel ik ze nog afzonderlijk vermeld
  • [L] staat voor Last (als de rule matcht, zullen er geen verdere rules meer worden verwerkt)
Bron: https://httpd.apache.org/docs/current/rewrite/flags.html

Wistjedatje

Aangezien de wiki niet meer ging, maar al mijn kennis in de wiki zit, had ik een probleem. Nu heb ik vastgesteld dat ik de Boossy-boom van onder wiki/data zomaar kan kopiëren naar wiki/data van de wiki op kantoor om deze onmiddellijk weer beschikbaar te hebben. Klein, maar handig wistjedatje!

bin & app!

Na heel de speurtocht bleek of blijkt dat ook ~/bin/configure niet meer bereikbaar is (de browser wil 'configure' downloaden…).

Als je de configuratie van de wiki wil bereiken, kan dat wel nog via ~/app/configure

See FwTest

User … has used up 0.0% of their bandwidth and 142% of their allocated disk space (27/8/'23)

Op een goeie 12 uur tijd krijg ik 1917 request voor de pagina System/CommandAndCGIScripts, allemaal vanaf Singaporese IP-adressen beginnend met 47.128. Ik heb die nu ook toegevoegd aan de geblokkeerde ranges in de .htaccess van de wiki:

<RequireAll>
    Require all granted
    Require not ip 47.128
    # Require not ip 78.22.137.253
    Require not ip 85.208.96 # vanaf 12/11/2023
    Require not ip 114.119
    Require not ip 157.90.182.28
    Require not ip 185.191.171
</RequireAll>

Werkwijze

Je wil toegang blokkeren voor de request de wiki bereikt. Dus in de wiki log zelf vaststellen welke requests te vaak worden uitgevoerd en in de .htacces van de wiki ip's blokkeren
  • /domains/boossy.be/public_html/wiki/working/logs/events.log
  • deze in een Excel gieten (Data > Text to Columns)
  • dan pivottable en rows en values allebei zetten op topic, vervolgens allebei zetten op IP
  • zo wordt het meteen duidelijk welke requests malafide zijn

Een bijkomende actie die je kunt doen, is de sqlite-database compacteren (zie https://wiki.boossy.be/System.PageCaching#SQLite), en wel als volgt:
cd /home/web00929/public_html/wiki/working
sqlite3 sqlite.db "VACUUM;"

Dat leverde op 17/11/2023 toch een winst op van 185 MB (vooraf 290 MB ► achteraf 105 MB). Dat kan toch al tellen!

tags

modsecurity mod_security

maintenance - onderhoud
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
This page was cached on 08 Mar 2024 - 08:21.