1

I have a MediaWiki 1.32.0 website which I want to upgrade, hosted on a CentOS "Shared Server" environment.
It is an all-core website with no added extensions, skins and images (besides logo)

To upgrade I need to change generally all files in the website's directory to those inside a directory of a newer version's MediaWiki installment (available inside a tartball) by a general overriding operation.

To download a latest MediaWiki tarball containing such directory (as of 13/08/19) one could execute:

wget https://releases.wikimedia.org/mediawiki/1.33/mediawiki-1.33.0.tar.gz

In my existing website directory, there are these files I already edited and shouldn't override:

  1. LocalSettings.php
  2. robots.txt
  3. .htaccess
  4. example.com.png (logo image)
  5. googlec69e044fede13fdc.html (Google search console verification file)

How could I download, and extract all files from directory in tarball to override a my current MediaWiki directory to override all files besides listed exceptions (such as the files listed above)?
I do plan to backup the old directory before changes manually as priming part of the script; adding a condition to continue only of the backup was done might be a nice idea; all of this, aside from having automatic daily backups).

  • terdon, isn't `lang=bash` not working here? isn't stepped instructions be formatted by means of accessibility, splitting a passage into two sub-passages with `
    ` is wrong to you and I don't know why. I don't understand at least the formatting aspect of the rejection.     –  Aug 15 '19 at 16:42
  • [Your edit](https://unix.stackexchange.com/review/suggested-edits/305277) was making the answer into a list (why?) and using the wrong format for lists (you want `1.` not `1)`); it added a grammatically incorrect phrase (_In suggestion\* see:_) and then just changed the formatting commands that were fine already. Finally, you added a linebreak for no apparent reason. None of these changes were improving the post. But if you disagree with an edit rejection, please take it to meta. The comments are not the right place to discuss it. – terdon Aug 15 '19 at 16:44
  • IMO, steps should generally be in lists but never mind here; I was wrong about `1)` as in this particular case `1.` was fine indeed. I I don't know why you say this on "in suggestion" to me it's fine. I tried to explain why I think the `
    ` is good... Thanks anyway for taking my inquiry seriously --- I will not go to meta. I still ask about `lang=bash` though. Is it "valid" in SE?     –  Aug 15 '19 at 16:53
  • See [Implement \`\`\`-style (fenced) Markdown code blocks](//meta.stackexchange.com/a/322000). The right format is `lang-bash` not `lang=bash` but the principle is sound, yes. – terdon Aug 15 '19 at 16:58

2 Answers2

3

Extracting the tarball you have in your question will create the directory mediawiki-1.33.0 which contains the following sub-directories:

$ tree -dL 1 mediawiki-1.33.0
mediawiki-1.33.0
├── cache
├── docs
├── extensions
├── images
├── includes
├── languages
├── maintenance
├── mw-config
├── resources
├── skins
├── tests
└── vendor

12 directories

Assuming these are also the directories you need in a proper mediawiki installation, all you need to do is:

  1. Backup the files you want to keep, using -p to keep the permissions, ownership and timestamps unchanged.

    cp -p LocalSettings.php robots.txt .htaccess example.com.png googlec69e044fede13fdc.html /some/other/path

  2. Extract the tarball

    tar xvzf mediawiki-1.33.0.tar.gz

  3. Copy the files to wherever they should be

    cp -a mediawiki-1.33.0/* /path/to/mediawiki/instrallation

    This will overwrite any existing files.

  4. Copy the backups back to their original locations

    cp -p /some/other/path/LocalSettings.php /original/path
terdon
  • 234,489
  • 66
  • 447
  • 667
  • @JohnDoea I don't understand what you mean. Isn't this exactly what you want to do? – terdon Aug 14 '19 at 10:21
  • Sadly it isn't - I desire not to backup and copy anything, just download and extract the new MediaWiki installment content directly into the existing website directory to override everything besides noted exceptions. And after that, delete the installment tarball. –  Aug 14 '19 at 10:22
  • Edited again to try to better explain my intention. Sorry for doing it lousy... –  Aug 14 '19 at 10:27
  • 2
    @JohnDoea yes, I understand that's what you wanted, but that's not a good approach. So I posted an answer explaining how simple it is to just copy the few files you need and then overwrite everything and copy them back. I don't know if it will be possible to tell tar to not overwrite specific files only, but if it is, it will be more complicated than this extremely simple approach. Maybe you could change the permissions on the files so you don't have write access to them but, again, that's more complicated. So this is the answer I would recommend. – terdon Aug 14 '19 at 10:30
  • I understand what I can call here "conservatism" but for me what I seek might be good. –  Aug 15 '19 at 15:53
  • @JohnDoea sure, and you're very free to unaccept this answer (as you did, good for you) and wait for another one. I just gave you the solution _I_ would choose. Nobody is forcing you to use it. – terdon Aug 15 '19 at 15:55
  • After I used the method I desired, 1.32.0 files remaining undeleted in merge, created some conflicts and I had to restore the entire 1.32.0 directory from a backup I made just before everything. Seems I have to work with your way or a derivation/similar based on the same contours. –  Aug 17 '19 at 11:41
  • terdon, isn't `cp -ra` should be only `cp -a` because from `cp man` it seems to me `a` encapsulates `r`; https://unix.stackexchange.com/questions/536118/what-is-a-argument-for-cp/536121#536121 –  Aug 18 '19 at 10:33
2

1) Create a file exclude.me with:

LocalSettings.php
robots.txt
.htaccess
example.com.png
googlec69e044fede13fdc.htm

2) Extract the archive

tar xvzf mediawiki-1.33.0.tar.gz --exclude-from=exclude.me --strip-components 1 -C /path/to/your/wiki

In suggestion see:

But if this is a production server with important data, I'd still suggest going the way terdon described.
And maybe just symlink the extracted archive to where your mediawiki is --the old-fashioned unix-way.

markgraf
  • 2,849
  • 1
  • 8
  • 20
  • Ah, nice! But does the `--exclude-from` expect a file with just file names or actual paths? And relative or absolute paths? What if there are multiple `example.com.png` files, for instance, and only one should be kept? – terdon Aug 15 '19 at 16:35
  • To be fair, only `example.com.png` was listed, without any wildcards or indication of multiple various names. – Jeff Schaller Aug 15 '19 at 16:45
  • @JeffSchaller oh yes, absolutely. I'm just thinking about a case where one of the file names to be kept exists in multiple places in the target directory structure and maybe only one needs to be kept. I'm not saying there's anything wrong with this answer, on the contrary, I've already upvoted it! – terdon Aug 15 '19 at 17:03
  • markgraf, why did you use `--strip-components 1`? Thanks anyway, –  Aug 15 '19 at 20:23
  • @JohnDoea To get rid of the directory named `mediawiki-1.33.0` and just extract its contents into your mediawiki-path. – markgraf Aug 16 '19 at 06:53
  • @terdon You're right, that should probably be full paths in the `exclude.me`-file. Regexes are possible too, I think. – markgraf Aug 16 '19 at 06:58