Yes, I’ll do that
Mmm… Good question… I’ll check it out.
By the way, the extension is supposed to be installed and working. It is best that you perform the last two steps if necessary:
$wgUploadDirectory.(Oh, remember to re-enable the account creation first)
Here is the result with the -i flag:
Of course I tried also with c: instead of /c/, etc.
FileZila: it’s not using the same key because it had to be converted to ppk, but the path ‘/c/Users/Miguel/.ssh/id_rsa’ is where Ubuntu looks for it when I log in and evidently finds it. Look
And here it’s that directory:
(the ppk key is FileZila’s)
The problem is that you’re running this command once you’re already connected to the wiki.actualism.online server.
Since you’re copying the file from your local machine TO the server — you have to run the command from your local machine. That is to say from the same place you are running this ssh command:
Oh, you say BEFORE I ssh wiki.actualism.online… I’ll try, thanks
Just in case, did you see this?
Because I want you to try the extension and then I thought to restore just the users database (if that can be done… -if not, I’d restore the whole wiki and later reinstall the extension-)
I think we have to restore the entire wiki because if we just remove the user, it will be broken since there will be pages that are edited by non-existent user (e.g. the talk pages)
maybe better restore it first, and then mess with the extensions – making sure the restored version still doesn’t allow new users to be made 
The extension, is it something you can try also?
OK. I’ll do that.
Oh, yes; no problem. Only that until now I had not done anything with the wiki but read it, without creating a user or looking at the existing ones. I’ll try to test the extension as well
@claudiu: thinking about which file to restore, I realized that the last backups will have the users spamed included.
Can you access the database to see WHEN the spam started, in order to restore a file dated prior to that? Or, if you prefer, tell me how to access/see them by myself.
The user list is here, can sort in ascending order: User list - Actualism Wiki
Looks like Dec 3 it started!
Well, I just found out that in the bucket we have wiki backups since November 4th 
because for the second time the lifecycle rule I made then to keep only the last 7 didn’t work… 
Fortunately they are small files.
I will see again if I can find out what the problem is with that rule. Otherwise I will ask for help here.
You have to upload it to a directory that is accessible by the wiki user.
The default home directory is a good candidate:
wiki@wiki-actualism-online:~$ pwd
/home/wiki
Note the directory is /home/wiki. An example path for a file in this folder would be /home/wiki/filename.
Note however that you are attempting to upload to the /home folder with /home/wiki.2022_12....zip.
It has to be /home/wiki/filename... not /home/wiki.filename (the first . → must be a /)
Thanks. Done.
I was planning to rename (at first, later delete) home/wiki and then restore the BUP’s wiki into home but I suppose I’ll then face the same error given the permissions granted to the wiki user, right?
What should I do? Involve the root user somehow…?
I re-read the deploy spec here https://discuss.actualism.online/t/actualism-wiki-deploy/696
There’s only 3 pieces for the wiki: the db, images, and local settings.
So rather than replace the entire home folder I would just replace these 3 pieces — and if we want to keep the current local settings then we only need to replace the db and images folder. Of course renaming the current ones first 
So I’ve finally restored just the wiki_db and wiki_image from the 2022/12/02 BUP, but the spammed users do not seem to have disappeared…
Cache? Docker image?
Here’s the situation of the folders now:
See if you can find out what’s going on…
So I tried to restart apache2 from within the container like this:
wiki@wiki-actualism-online:~$ docker exec -it wiki-actualism-online-prod bash
root@bca122d283d9:/var/www/html# /etc/init.d/apache2 restart
However this ended up killing the docker container!
So then I re-started it like this, as described in /home/wiki/deploy/create_docker_container.sh:
wiki@wiki-actualism-online:~$ docker start wiki-actualism-online-prod
However now the site served with an error saying it couldn’t access the database.
Doing an ls -alh I saw that the owner & group of the new wiki_db and wiki_images didn’t match the old ones:
drwxrwxr-x 3 wiki wiki 4.0K Jan 7 13:06 wiki_db
drwxrwxr-x 3 www-data www-data 4.0K Jan 11 20:40 wiki_db_OLD
drwxrwxr-x 9 wiki wiki 4.0K Jan 7 13:07 wiki_images
drwxrwxr-x 9 www-data www-data 4.0K Oct 2 11:21 wiki_images_OLD
So I made them the same like this:
wiki@wiki-actualism-online:~$ sudo chown -R www-data:www-data wiki_db
wiki@wiki-actualism-online:~$ sudo chown -R www-data:www-data wiki_images
After this, it worked! Spam users gone.
@Srinath Not sure if this caused any loss of edits, do you remember if you edited anything after Dec 3rd on the wiki?
It’s good to keep all this documented
Hi @claudiu. No, I was overseas then and super busy. Haven’t worked on wiki probably since … early Nov?? Just guessing, but well before Dec 3rd
Btw what edits were lost and where? I did add a lot of material to the enlightenment piece around the early - mid Nov and might have deleted and changed some of what you wrote, but didn’t exactly go slash and burn. Was it there or somewhere else?
Cooool then nothing was lost. We just restored the entire db to the state it was in on December 3rd.
Finally I’ve tested the ConfirmAccount extension.
After requesting and account, this error appeared:
Possible causes and solutions seem to be diverse…
