dalbert

We have lock accounts set to 4, but I believe that would just lock the account that was tried, not refuse the connection, so if trying different addresses, or just submitting junk it won't block. We have 2x Invision forums - currently this is only an issue at one. The sessions portion of the database becomes corrupted when this happens, and we have to rebuild it. Server load jumps upwards of 70. ISP is throwing the blame at the software, saying it should have a mechanism to deal with it..... and the lP info for the offending connections can only be noted once the traffic becomes heavy - at which point the IP/Subnet can put in the firewall database.

Recent issue is that we have remote servers initiating 10+ logins a second on a continuous basis.. This eventually corrupts the sessions portion of the database, and causes the forum to go down. I looked but don't see a way, to limit / block these in the config... Is there some way this can be configured, or added as a security fix? i.e. more than 1 login a second from any given IP, would get blocked by the IPS software / more than 100 per 30min timespan - ideally logged as an offending IP somewhere for reference. Thanks.

As a quick follow up, the ISP noted that the drive was passing a short test, but failing on the long test... Drive was replaced. They also noted a DOS login attack from another dedicated server provider, and blocked it. We will see how the forum behaves over the coming days.

I have submitted a case to the host to check the disk, however our other Invision site as well as our Xenforo site are both working normally.. So at present that makes me wonder about ddos/effort to remotely cause hiccups or some other internal file corruption, that is just becoming the gift that keeps on giving. Since clearing the whole core_logs a little bit ago, nothing has popped up into the logs... Lets see how we do over the next few hours / overnights. Thanks.

Correct, but it keeps on corrupting - I have gone from having to do it every 3-4mo, to every week, and now every 4 days. At this point I just emptied the core_log that was 2.31gig in hopes that would help the issue, or at least give me more leeway.

Server just came back up after reboot, and the following error is in the admin CP... typically a repair of the sql table will resolve this, and get things back on track SELECT * FROM `core_sessions` WHERE ( core_sessions.id IN('SELECT MAX(id) FROM `core_sessions` AS `s` WHERE s.running_time>'SELECT MAX(id) FROM `core_sessions` AS `s` WHERE s.running_time>? AND s.login_type!=? AND (s.login_type!=? OR s.member_id=?) AND s.member_id IS NULL GROUP BY `ip_address`' AND s.login_type!=? AND (s.login_type!=? OR s.member_id=?) AND s.member_id IS NOT NULL GROUP BY `member_id`') OR core_sessions.id IN(?) ) ORDER BY core_sessions.running_time desc IPS\Db\Exception: Table 'core_sessions' is marked as crashed and should be repaired (1194) #0 /usr/www/users/myuser/myboard/forums/system/Db/Select.php(286): IPS\Db\_Select->runQuery() #1 /usr/www/users/myuser/myboard/forums/system/Session/Store/Database.php(253): IPS\Db\_Select->setKeyField() #2 /usr/www/users/myuser/myboard/forums/applications/core/extensions/core/Dashboard/OnlineUsers.php(52): IPS\Session\Store\_Database->getOnlineUsers() #3 /usr/www/users/myuser/myboard/forums/applications/core/modules/admin/overview/dashboard.php(64): IPS\core\extensions\core\Dashboard\_OnlineUsers->getBlock() #4 /usr/www/users/myuser/myboard/forums/system/Dispatcher/Controller.php(118): IPS\core\modules\admin\overview\_dashboard->manage() #5 /usr/www/users/myuser/myboard/forums/system/Dispatcher/Dispatcher.php(153): IPS\Dispatcher\_Controller->execute() #6 /usr/www/users/myuser/myboard/forums/admin/index.php(13): IPS\_Dispatcher->run() #7 {main}

System log in the database is approx 2.3gig, and core_sessions keeps on needing to be rebuilt every week or so (getting more frequent now -- maybe every 4 days). Appears that today alone there were 400k entries. We updated from approx 4.7.8 to 4.17.13, and the issue seems to have gotten worse. Issue began happening between Sept. 1st and 2nd, when the database grew 500 meg overnight.... We didn't do any board changes on that date, and the other IPS board on the same server seems to be running fine. Here is one example of a frequent error - I would post more, but I just had to reboot the server Error: Call to a member function language() on null (0) #0 /usr/www/users/myuser/ourboard/forums/system/Dispatcher/Front.php(719): IPS\Dispatcher\_Standard::baseJs() #1 /usr/www/users/myuser/ourboard/forums/init.php(936) : eval()'d code(45): IPS\Dispatcher\_Front::baseJs() #2 /usr/www/users/myuser/ourboard/forums/system/Dispatcher/Front.php(79): IPS\Dispatcher\agepopup_hook_dispatcherFront::baseJs() #3 /usr/www/users/myuser/ourboard/forums/init.php(936) : eval()'d code(98): IPS\Dispatcher\_Front->init() #4 /usr/www/users/myuser/ourboard/forums/system/Dispatcher/Dispatcher.php(110): IPS\Dispatcher\memberscountry_hook_dispatcherFront->init() #5 /usr/www/users/myuser/ourboard/forums/index.php(13): IPS\_Dispatcher::i() #6 {main}

We hae approx 100 users signed up to get notifications of new topics being posted in one of our forums (a for sale forum), who are not receiving any notifications... Our test forum however (which I have followed in the same way) does send out notifications of new topics. Issue was in 4.7.4 and I upgraded to 4.7.8, and still have the same issue. Caches cleared Any insight on how to remedy, would be appreciated.

Thank you... Will do.

In the event the info helps, here are the x_utf tables that were generated, in the event it gives a better explanation of where the process is stopping at.

As an update, I have also used MyPHPadmin to drop all of the x_utf_ entries, in the hope that it would get a fresh start from the CLI, but get the same message.

% php -v PHP 8.0.24 (cli) (built: Sep 29 2022 13:47:46) ( NTS ) Copyright (c) The PHP Group Zend Engine v4.0.24, Copyright (c) Zend Technologies %

Attempting to update UTF8, and we get an error as follows (full command line output below) with a PHP8 install Error: count(): Argument #1 ($value) must be of type Countable|array, null given File: /system/Convert/Convert.php Line: 552 Would appreciate guidance on how to proceed. Thanks. ------------- % php cli.php --info IP.Board Character Set: iso-8859-1 Database Character Set: latin1 Original table prefix: ibf_ Converted table prefix: x_utf_ibf_ 190 tables are latin1 190 tables have incorrect collations Can use 'dump' method: true % % php cli.php ---------------------------------------------------- Welcome to the IPS UTF8 Conversion utility (v1.1.20) ---------------------------------------------------- This utility will convert all the tables in this database to UTF-8. The converted data is inserted into new tables prefixed with x_utf_ and the original data kept. You have a conversion session unfinished. The session was last updated on Wed 19 October 2022 and has processed 43 tables (1%) so far. [c] Enter 'c' to continue [x] Enter 'x' to reset and start the conversion again. x Are you sure? This will re-start the conversion [y] Enter 'y' to re-start the conversion [c] Enter 'c' to continue the conversion. y ---------------------------------------------------- Welcome to the IPS UTF8 Conversion utility (v1.1.20) ---------------------------------------------------- 190 table(s) are not UTF-8 and need converting. This utility will convert all the tables in this database to UTF-8. The converted data is inserted into new tables prefixed with x_utf_ and the original data kept. Press enter to continue Processing: cache_store 1% Error: count(): Argument #1 ($value) must be of type Countable|array, null given File: /system/Convert/Convert.php Line: 552 %

Thank you ... It is throwing errors via the CLI at 1% of the process.. I will open a separate topic.

Yes, we have SSH access ... I see a cli.php in the UTF8 conversion directory, but a search here hasn't yielded me the proper usage of it... If there is a different utility, I should be using, please let me know, or direct me to the proper structure of using this php script (I really do not want to bugger up the data). Thanks.