Ghust

Hey Marc, Assuming I drop my new index and recreate it as post_date, I should be fine right? Unless something has to be changed on a specific index (such as implementing the topic_id 😄 ) I doubt an upgrade will drop and recreate all indexes, would take ages

If you're mostly remote, my go-to would be: Disable ssh access with password, only use public key authentication. Remove all unknown keys in /root/.ssh/authorized_keys file And for all other accounts . When adding public keys to authorized_keys, annotate whose key is whose, will greatly simplify this in the future. But for all intents and purposes you have to assume your server is compromised, especially if your ex employee had root access. This is something that your Legal department should know about. This is less of a technical issue imo.

Addendum: I dropped the post_date index for now, it seems to be running better. But I'm now a bit scared that future updates will break, so if I have to recreate post_date instead, let me know!

Hey, last weeks I've been having complaints from our users that our (self hosted) IP is slower than before. First I tried tweaking php-fpm settings, but I never really saw enough concurrent connections to really justify upping the max_clients to something absurd. Then I saw that the database seemed to be having difficulties. I enabled slow query logging and found the following query that was really slow (> 5seconds) for about every user. MariaDB [mysql]> select * from slow_log limit 10; +----------------------------+--------------------------------------+-----------------+-----------------+-----------+---------------+-------+----------------+-----------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+---------------+ | start_time | user_host | query_time | lock_time | rows_sent | rows_examined | db | last_insert_id | insert_id | server_id | sql_text | thread_id | rows_affected | +----------------------------+--------------------------------------+-----------------+-----------------+-----------+---------------+-------+----------------+-----------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+---------------+ | 2024-07-28 08:38:04.975686 | forumrsca[forumrsca] @ [172.19.0.8] | 00:00:07.687649 | 00:00:00.000022 | 1 | 2595147 | forum | 0 | 0 | 1 | /*forum::forumrsca::IPS\Content\_Item::_comments:2109*/ SELECT forums_posts.*, author.*, author_pfields.* FROM `forums_posts` LEFT JOIN `core_members` AS `author` ON author.member_id = forums_posts.author_id LEFT JOIN `core_pfields_content` AS `author_pfields` ON author_pfields.member_id=author.member_id WHERE forums_posts.topic_id=8215 AND forums_posts.queued!=-2 AND forums_posts.queued!=-3 ORDER BY post_date ASC LIMIT 0,1 | 3542766 | When running an EXPLAIN i see the following: MariaDB [forum]> EXPLAIN SELECT forums_posts.*, author.*, author_pfields.* FROM forums_posts LEFT JOIN core_members AS author ON author.member_id = forums_posts.author_id LEFT JOIN core_pfields_content AS author_pfields ON author_pfields.member_id = author.member_id WHERE forums_posts.topic_id = 8215 AND forums_posts.queued != -2 AND forums_posts.queued != -3 ORDER BY post_date ASC LIMIT 0, 1; +------+-------------+----------------+--------+-------------------------------------------------------+-----------+---------+------------------------------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------------+--------+-------------------------------------------------------+-----------+---------+------------------------------+------+-------------+ | 1 | SIMPLE | forums_posts | index | queued,topic_id,first_post,idx_topic_queued_post_date | post_date | 5 | NULL | 835 | Using where | | 1 | SIMPLE | author | eq_ref | PRIMARY,mgroup | PRIMARY | 8 | forum.forums_posts.author_id | 1 | Using where | | 1 | SIMPLE | author_pfields | eq_ref | PRIMARY | PRIMARY | 3 | forum.author.member_id | 1 | Using where | +------+-------------+----------------+--------+-------------------------------------------------------+-----------+---------+------------------------------+------+-------------+ 3 rows in set (0.51 sec) It's using post_date here, which isn't really ideal as there's no indexing on topic_id I then tried creating this index: CREATE INDEX idx_topic_id_queued_post_date ON forums_posts(topic_id, queued, post_date); But it's not being used in this query. And admin CP doesn't agree with my fix 😄 How could I fix this issue? Is this a known one? I guess I could drop the post_date index and recreate it with the topic_id and queued instead... But hey, I'd rather double check 🙂 Added info: Invision Community v4.7.17

Where is it hosted? You don't neccesarily need to delete the account, if you can ensure only internal network can reach your machine.

That's actually a fair point, I hadn't thought about that. Thanks @Jim M!

When upgrading I got an error saying a script "insert ignore select into gallery_images_uploads select * from gallery_images_uploads_new" This is because my database had more columns in the "new" table. This I worked around this by manually adding the columns in mysql: MariaDB [dbname]> alter table gallery_images_uploads add column upload_location text; Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [dbname]> alter table gallery_images_uploads add column upload_unique_id bigint(20) unsigned NOT NULL; Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [dbname]> alter table gallery_images_uploads add column upload_order int(10) unsigned; Query OK, 0 rows affected (0.02 sec) Records: 0 Duplicates: 0 Warnings: 0 This may be caused because I never upgraded anything else than Core and Forums. But I didn't have an option to deselect other features from this upgrade. But anyway... We survived!

Slightly related question: are your avatars generated with some sort of publicly available tool? 🙂

Yeah that should have been my first idea. Thanks @Marc Stridgen!

Hi guys, To test the PHP 8 upgrade I restored production db to a staging environment. Everything seems to work fine, however I have some issues with fonts being fetched from the production environment. And because it comes from another URL, a CORS error is thrown: Any idea where I can change this so it goes to the staging environment?

Thanks @Randy Calvert!

Hey guys, For our community we run a docker stack on an azure machine. It's comprised of: - Nginx - PHP-FPM (7.3) - Mariadb (10.2) - Certbot for https certs - Some helper containers Currently we run IPS 4.5.2. As PHP 8.0 will be recommended for new version I wanted to test if the upgrade procedure was working correctly. Therefore I took a backup of the database, spun up a new stack with the same settings and tried upgrading the php-fpm container to 8.0. Before the new container, I can access the staging environment just fine. After the new php-fpm container I notice that it just keeps loading until the max_execution_time is hit, and then it proceeds to dump some code in the browser, without any error messages. Any ideas? Should I try a more "baby steps" approach using a 7.4 container?