7,627
edits
Changes
Jump to navigation
Jump to search
no edit summary
==The Options==
The obvious approach is to Export export (with or without revision history) , using [[Special:Export]], and then import. As the page count is likely around 500-600 (see below) this should be feasible, though importing though [[Special:Import]] isn't recommended for page counts greater than 100, due to timeout issues. See https://www.mediawiki.org/wiki/Manual:Importing_XML_dumps. Instead, one should use importDump.php [https://www.mediawiki.org/wiki/Manual:ImportDump.php] for larger imports. Note that mwdumper apparently doesn't work for imports in to MW1.31+, presumably because of database structure changes. Another option is to use pagefromfile.py [https://www.mediawiki.org/wiki/Manual:Pywikibot/pagefromfile.py], which is a part of [https://www.mediawiki.org/wiki/Manual:Pywikibot Pywikibot].
Looking at [[Special:AllPages]], it does seem that some of the pages from the old wiki were previously 'imported' to the new wiki. I suspect that this was done page-by-page by the students, copying over the content. Nevertheless, there are pages with the same name but differing content, which is going to cause collisions. See https://meta.wikimedia.org/wiki/Help:Import#Merging_histories_and_other_complications. The script pagefromfile.py has the option of adding the old content to the bottom of the new page (or the top), which would be helpful in many cases. However, a careful approach might be best. I could build lists of pages that have distinct names, common names, and common names but different import criteria, etc. Using [[Special:Import]] should merge the revision histories, which will mean that no date will be lost, as all revisions on Astarte's wiki should be older than the content on Mother's wiki. The documentation for importDump.php[https://www.mediawiki.org/wiki/Manual:ImportDump.php] doesn't make it clear how it processes revisions and potential conflict. [[Manual:dumpBackup.php]] documents options for starting and ending at specific revisions, implying at least some support for revisions.
Trying to copy data out of the database and then bringing it back in, almost surely isn't an option as this installation using Postgres and the new one uses MySQL. Also the base structure has changed beyond all recognition in the last decade or so. Likewise, I likely can't install any new extensions on the old wiki -- she's just too old.
===The Choice===
Given the analysis, I think I'm going to pull both page sets everything for posterity, do a full backup and then only load the "Astarte Only" pages for now. A quick look suggests that the duplicate pages won't be adding a huge amount of content that I care about. I'll do try the load with importDump.php, which is the most standard method available. If/when my wiki gets bigger I'll install pywikibots, but for now they seem like another potential vulnerability.
I'll then move the repository and pdf directories over by hand, and put some access control on them, and use ImportImages.php to get the images into the wiki.
==Moving Dumping Data==
I dumped the following from Astarte:
*AstarteAndMother pages with full histories to Wikiedia-20200923190929.xml (22MB)
*AstarteAndMother pages without histories to Wikiedia-20200923192123.xml (705K)
I also created some trial exports to test how importDump.php handles revisions.
==An Unexpected Issue==
After a shutdown, Astarte wouldn't come back up. If I reset her power, she'd spin up for maybe 2 seconds -- just enough to give a single BIOS beep - and then lose power. There was a bit of an ozone smell coming from her, and she seemed loud compared with my more modern desktop (which has a way bigger PSU), ever since I pulled her out of storage. I popped the case and discovered some sunflower and other seeds on the inside. At some point in her transatlatic travels, it looks like a mouse or something used her for storage (insert RAID array pun here). Based on the symptoms, I figured the PSU was the likely culprit and swapped it out. She then booted again just fine...
==Transfering Data==
I tried to mount my local shares to transfer data but kept getting mount error(95): Operation not supported:
mount -o username=researcher,vers=3\.0 //192.168.2.201/bulk /mnt/mother
mount -o username=researcher,vers=3\.0 //192.168.2.201/bulk /mnt/mother
smbclient -m CORE -L 192.168.2.201
...also tried COREPLUS, NT1, SMB2 (unrecognized protocol layer), SMB3 (unrecognized protocol layer)
This seems to be an smb negotiation issue. See: https://unix.stackexchange.com/questions/144522/mounting-cifs-operation-not-supported
I also tried lowering the requirement on the other end (i.e., on Mother) by editing /etc/samba/smb.conf (setting client min protocol =...) and doing a service smbd restart, but to no avail.
