Scottish independence referendum, 2014

In August 2009 the SNP announced a Referendum Bill would be included in its package of bills to be debated before Parliament in 2009–10, with the intention of holding a referendum on the issues of Scottish independence in November 2010.

The bill did not pass due to the SNP’s status as a minority administration, and due to the initial opposition to the Bill from all other major parties in the Scottish Parliament.

Following the Scottish Parliament general election, 2011 the SNP had a majority in parliament and again brought forward an Independence Referendum Bill.

The Scottish Government also suggested that full fiscal autonomy for Scotland (known as “devo-max”) could be an alternative option in the vote.

The negotiation of the Edinburgh Agreement (2012) resulted in the UK government legislating to provide the Scottish Parliament with the powers to hold the referendum.

The “devo-max” option was not included, however, as the Edinburgh Agreement stipulated that the referendum had to be a clear binary choice between independence or the existing devolution arrangements.

The Scottish Independence Referendum (Franchise) Act 2013 was passed by the Scottish Parliament and campaigning commenced. Two days before the referendum was held, with polls very close, the leaders of the three main UK political parties made “The Vow”, a public pledge to devolve “extensive new powers” to the Scottish Parliament if independence was rejected. They also agreed to a devolution timetable proposed by Gordon Brown.

After heavy campaigning by both sides, voting took place on 18 September 2014. Independence was rejected by a margin of 45% in favour to 55% against.

Dans Nextcloud, la page Paramètres > Administration > Vue d’ensemble vous permet d’avoir un bon aperçu des tâches de maintenance à effectuer sur votre installation Nextcloud.

This version of Nextcloud is not compatible with > PHP 7.4

C’est une erreur – et non un avertissement – qui bloque toutes les commandes suivantes dans le terminal. Elle apparaît lorsqu’une version de PHP plus récente est installée sur votre serveur.

Chez moi, par exemple, j’ai PHP 7.4 pour les sites en production et pour Nextcloud mais aussi PHP 8 pour les plateformes de développement.

Voici le message d’erreur:

This version of Nextcloud is not compatible with > PHP 7.4.

You are currently running 8.0.0

Ce message apparaît parce que Nextcloud lance un rapide php -v pour déterminer la version de PHP installée. Cela ne reconnait par contre que la version la plus récente installée.

Voici ce que donne la commande:

PHP 8.0.0 (cli) (built: Nov 27 2020 12:26:22) ( NTS )
 Copyright (c) The PHP Group
 Zend Engine v4.0.0-dev, Copyright (c) Zend Technologies
     with Zend OPcache v8.0.0, Copyright (c), by Zend Technologies

La solution consiste à modifier manuellement la version retournée par php -v, à l’aide de la commande update-alternatives :

update-alternatives --set php /usr/bin/php7.4

Si on relance php -v, voici le résultat:

PHP 7.4.13 (cli) (built: Nov 28 2020 06:24:59) ( NTS )
 Copyright (c) The PHP Group
 Zend Engine v3.4.0, Copyright (c) Zend Technologies
     with Zend OPcache v7.4.13, Copyright (c), by Zend Technologies

Avec cela, vous êtes parés pour les commandes occ de Nextcloud.

Nextcloud reste bloqué en mode maintenance

Cela peut arriver lors d’une mise à jour, pour diverses raisons.

Solution 1: avec la commande occ

cd /home/www/nextcloud 
sudo -u www-data php ./occ maintenance:mode --off 

Solution 2: éditer le fichier config.php

1. Editez le fichier config.php:

nano /home/www/nextcloud/config/config.php

2. trouvez:

 'maintenance' => true, 

3. remplacez par:

 'maintenance' => false, 

Enregistrez le fichier, l’assistant de mise à jour est alors capable de reprendre là où il s’était arrêté, automatiquement.

Local possède une version d’Adminer dans les options de chaque site qui est très utile puisqu’elle permet d’accéder rapidement à la base de données, ou d’importer une petite base de données.

Par contre, s’il s’agit d’importer une base qui fait plus de 80 Mo, mieux vaut se tourner vers un outil un peu plus robuste: le shell.

Accéder au shell depuis Local

Et cela tombe bien : Local possède son propre shell, accessible sur simple clic-droit sur le nom du site sur lequel vous souhaitez ouvrir une fenêtre de terminal:

Voici la marche à suivre : Démarrez votre site > sélectionnez le nom du site > clic-droit > Open Site Shell

Importer une base de données dans un site Local

Lorsque j’ai besoin de répliquer un site rapidement, je copie la base données dans le répertoire app du site Local en question.

Pour mon site de test (skyminds-2020 ), le chemin sur ma machine est /Users/matt/Local Sites/skyminds2020/app . C’est dans ce dossier que je place le fichier SQL à importer.

Ensuite, dans le shell Local, il suffit de faire un simple import SQL dans la base qui, par défaut, s’appelle local (et ce, pour tous vos sites Local, bien qu’elles soient toutes indépendantes).

L’utilisateur est root et le mot de passe root également, ce qui est plutôt pratique.

Le shell est par défaut sous app/public donc on remonte d’un cran dans l’arborescence pour pointer vers notre fichier (qui se trouve dans /app ).

Voilà ce que cela nous donne:

mysql -u root -proot local < ../db.sql

Résultat:

mysql: [Warning] Using a password on the command line interface can be insecure.
bash-3.2$

L’importation de la base de données SQL ne prend que quelques secondes, alors que cela se plante allégrement lorsque l’on utilise Adminer.

A utiliser sans modération, cela ne vaut vraiment pas le coup de s’embêter avec une interface graphique (ou à placer le fichier dans le répertoire d’adminer comme il l’indique sur la page d’importation).