Easiest way of upgrading or updating Mediawiki version on Debian/Ubuntu/etc.

So far this is the easiest way I have found to update Mediawiki. This presumes SSH access.   Back up your database and files first!  
cd
wget https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.1.tar.gz
(if going for another version, replace with the appropriate link)
tar -xvzf mediawiki-1.31.1.tar.gz
cp -rf mediawiki-1.31.1/* /var/www/YOURSITE
If your sites are stored elsewhere, replaces /var/www/YOURSITE with whatever the path name is. Copy with the rf flags forces over-write and copies recursively.
Visit https://yoursitename/mw-config/ in your browser
Follow the instructions from there – you will need the upgrade key from your existing LocalSettings.php file, which should be found in your existing Wiki directory via:

cat LocalSettings.php | grep -A 2 key

 

Owncloud Nine: How to reset the admin password

Well, about ten minutes after installing the new Owncloud Nine we found out that we had typo’d the admin password. Fortunately, it’s an easy fix. Run the following (this worked on Debian with a fresh Owncloud 9 install):  
cd /path/to/owncloud sudo -u webserveruser php occ user:resetpassword adminaccountname
  In our case the command was:  
cd /var/www/cloud sudo -u www-data php occ user:resetpassword admin
  It should prompt you for your password twice:  
Owncloud Nine - How to reset the admin password
Owncloud Nine – How to reset the admin password
  Assuming there are no more typos, that’s all done!

OpenSMTPD and Thunderbird: smtp-in: Bad input on session 5.5.1 Invalid command: Pipelining not supported

While trying to connect to OpenSMTPD running on Debian Stretch Thunderbird couldn’t auto-configure the account and provided the following error in the logs:  
email smtpd[566]: smtp-in: Bad input on session 6567905e3020707c: 500 5.5.1 Invalid command: Pipelining not supported
  This is a Thunderbird config issue, not a server side issue. Change the settings from SSL/TLS to STARTTLS and that should sort it.

How to protect Debian from the Shellshock exploit

Shellshock is quite a serious security hole found a couple of days ago in Bash; to check whether your Debian server is vulnerable run the following in a terminal:
env VAR='() { :;}; echo Shellshock vulnerable!‘ bash -c “echo Bash Testing”
If your system is vulnerable, you will see:
Shellshock vulnerable! Bash testing
If it is not vulnerable, you will see:
bash: warning: VAR: ignoring function definition attempt bash: error importing function definition for `VAR’ Bash testing
If you are vulnerable, you can update bash by running the following:
sudo apt-get update && sudo apt-get install --only-upgrade bash
Once the update has finished, run the code to check your vulnerability again and it should be sorted.



Debian: How to see what has recently been upgraded or updated through apt-get

Forgotten what it was you last updated, or want to check what someone else has been updating? There’s a log file for that, and it’s located at:  
/var/log/apt/history.log
  To view it, run:  
less /var/log/apt/history.log
  Looking for an older logfile? They’re kept, too. To see the other log files available, view the directory using ls:  
ls /var/log/apt/
  It should look something like:  
history.log  history.log.1.gz  history.log.2.gz  history.log.3.gz  history.log.4.gz  term.log  term.log.1.gz  term.log.2.gz  term.log.3.gz  term.log.4.gz
  One further note – This will show the most recent things done with apt, not just upgrades.

How to cache yum repositories on CentOS using apt-cacher-ng on Debian or Ubuntu

  If you have a lot of virtual (or real) machines running Debian or Ubuntu and a limited internet connection, it can make a lot of sense to use apt-cacher-ng to create a local cache of the packages you use so that they are only downloaded once. The current version of apt-cacher-ng can also help out with yum repositories!   On CentOS, edit /etc/yum.conf and add:  
proxy=http://[ip-of-your-local-apt-cacher-ng-server]:3142
  If you have changed the default port of apt-cacher-ng from 3142, you will need to modify that. Our example file:  
[main] cachedir=/var/cache/yum/$basearch/$releasever keepcache=0 debuglevel=2 logfile=/var/log/yum.log exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 installonly_limit=5 bugtracker_url=http://bugs.centos.org/set_project.php?project_id=16&ref=http://bugs.centos.org/bug_report_page.php?category=yum distroverpkg=centos-release proxy=http://10.1.1.12:3142 #  This is the default, if you make this bigger yum won’t see if the metadata # is newer on the remote and so you’ll “gain” the bandwidth of not having to # download the new metadata and “pay” for it by yum not having correct # information. #  It is esp. important, to have correct metadata, for distributions like # Fedora which don’t keep old packages around. If you don’t like this checking # interupting your command line usage, it’s much better to have something # manually check the metadata once an hour (yum-updatesd will do this). # metadata_expire=90m # PUT YOUR REPOS HERE OR IN separate files named file.repo # in /etc/yum.repos.d
  As you can see, our local apt-cacher-ng VM is 10.1.1.12.   Run yum update and check your apt-cacher-ng’s cache – you should now see some CentOS respositories cached there.

Debian Wheezy: /etc/sudoers missing

  If you’re looking to add something to the /etc/sudoers file in a Debian Wheezy install, you may find that the file isn’t there! To create the file while logged in as the root user you need to install the sudo package:  
apt-get install sudo
  Once that install completes the file will appear:  
# # This file MUST be edited with the ‘visudo’ command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults        env_reset Defaults        mail_badpass Defaults        secure_path=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin” # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root    ALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command %sudo   ALL=(ALL:ALL) ALL # See sudoers(5) for more information on “#include” directives: #includedir /etc/sudoers.d