Bug 22026 - Upgrade the nextcloud server in updates to prevent the mess we had in MGA5 with backports.
Summary: Upgrade the nextcloud server in updates to prevent the mess we had in MGA5 wi...
Status: ASSIGNED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-15 08:40 CET by José Jorge
Modified: 2018-03-16 08:14 CET (History)
6 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description José Jorge 2017-11-15 08:40:46 CET
I'd like to push an update upgrading the nextcloud server in Mageia.
- it will allow an easier upgrade to MGA7 without manual operations.
- it is better for security to have recent app in such a public server
- it allows to do a better packaging picking the problems in a slow pace, out of a whole system upgrade

The idea is to always have at least the version before the latest, which must be already in cauldron. So for now it is version 12.0.3 that is pushed to MGA6 updates testing.
José Jorge 2017-11-15 08:41:34 CET

CC: (none) => mageia
Assignee: bugsquad => lists.jjorge

Comment 1 José Jorge 2017-11-29 22:55:06 CET
First test on a production system :  unfortunately, we need some new lines in the config.php file, to manage better the apps directory. For now, they are in the rpmnew file. I think it will need an information.

I had to add the following lines manually :

  'integrity.check.disabled' => true,
  'log_type' => 'syslog',
  'updatechecker' => false,
  'check_for_working_htaccess' => false,
  'asset-pipeline.enabled' => false,
  'assetdirectory' => '/var/lib/nextcloud',
  'preview_libreoffice_path' => '/usr/bin/libreoffice',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/share/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/lib/nextcloud/apps',
      'url' => '/apps-appstore',
      'writable' => true,
    ),
  ),
Comment 2 José Jorge 2017-12-25 10:49:51 CET
A README.urpmi file was added to explain the changes in config.file.

Please QA, test this update and decide if such manual operations are acceptable with an update.

SRPM :

nextcloud-12.0.3-2.mga6.srpm

RPMS :

nextcloud-12.0.3-2.mga6.noarch.rpm
nextcloud-mysql-12.0.3-2.mga6.noarch.rpm
nextcloud-postgresql-12.0.3-2.mga6.noarch.rpm
nextcloud-sqlite-12.0.3-2.mga6.noarch.rpm

Assignee: lists.jjorge => qa-bugs
CC: (none) => lists.jjorge
Status: NEW => ASSIGNED

Comment 3 Brian Rockwell 2018-01-04 16:58:38 CET
do you need me to pull in an old version of nextcloud and then upgrade or is a fresh install acceptable?

Keywords: (none) => feedback
CC: (none) => brtians1

Comment 4 David Walser 2018-01-04 21:40:47 CET
Upgrades are actually the point of this update, and it's updating to a new stable branch, so testing updating from the release version is very important.

Keywords: feedback => (none)

Comment 5 Brian Rockwell 2018-01-05 17:26:11 CET
Installing Base

The following 43 packages are going to be installed:

- apache-2.4.27-1.1.mga6.x86_64
- apache-mod_php-5.6.32-1.mga6.x86_64
- lib64apr-util1_0-1.5.4-8.mga6.x86_64
- lib64apr1_0-1.5.2-2.1.mga6.x86_64
- lib64json2-0.12.1-1.mga6.x86_64
- lib64mbfl1-1.3.2-1.mga6.x86_64
- lib64onig2-5.9.6-2.mga6.x86_64
- lib64php5_common5-5.6.32-1.mga6.x86_64
- lib64t1lib5-5.1.2-19.mga6.x86_64
- lib64zip4-1.1.3-1.1.mga6.x86_64
- nextcloud-11.0.3-1.mga6.noarch
- php-ctype-5.6.32-1.mga6.x86_64
- php-curl-5.6.32-1.mga6.x86_64
- php-dom-5.6.32-1.mga6.x86_64
- php-fileinfo-5.6.32-1.mga6.x86_64
- php-filter-5.6.32-1.mga6.x86_64
- php-ftp-5.6.32-1.mga6.x86_64
- php-gd-5.6.32-1.mga6.x86_64
- php-gettext-5.6.32-1.mga6.x86_64
- php-hash-5.6.32-1.mga6.x86_64
- php-iconv-5.6.32-1.mga6.x86_64
- php-ini-5.6.32-1.mga6.x86_64
- php-json-5.6.32-1.mga6.x86_64
- php-mbstring-5.6.32-1.mga6.x86_64
- php-opcache-5.6.32-1.mga6.x86_64
- php-openssl-5.6.32-1.mga6.x86_64
- php-pdo-5.6.32-1.mga6.x86_64
- php-pdo_sqlite-5.6.32-1.mga6.x86_64
- php-posix-5.6.32-1.mga6.x86_64
- php-session-5.6.32-1.mga6.x86_64
- php-sqlite3-5.6.32-1.mga6.x86_64
- php-suhosin-0.9.38-1.mga6.x86_64
- php-sysvsem-5.6.32-1.mga6.x86_64
- php-sysvshm-5.6.32-1.mga6.x86_64
- php-timezonedb-2017.2-1.mga6.x86_64
- php-tokenizer-5.6.32-1.mga6.x86_64
- php-xml-5.6.32-1.mga6.x86_64
- php-xmlreader-5.6.32-1.mga6.x86_64
- php-xmlwriter-5.6.32-1.mga6.x86_64
- php-zip-5.6.32-1.mga6.x86_64
- php-zlib-5.6.32-1.mga6.x86_64
- t1lib-config-5.1.2-19.mga6.x86_64
- webserver-base-2.0-10.mga6.noarch

144MB of additional disk space will be used.

38MB of packages will be retrieved.

Is it ok to continue?

I’ve configured it with a custom data folder /home/apache and using sqlite.

Created a new user, besides admin, and posted some new documents in the repo.

Seems to be working as designed.


Now for upgrade

Upgrading to 12.03

The following 9 packages are going to be installed:

- lib64php5_common5-5.6.33-1.mga6.x86_64
- nextcloud-12.0.3-2.mga6.noarch
- nextcloud-mysql-12.0.3-2.mga6.noarch
- php-exif-5.6.33-1.mga6.x86_64
- php-ldap-5.6.33-1.mga6.x86_64
- php-mbstring-5.6.33-1.mga6.x86_64
- php-mysqlnd-5.6.33-1.mga6.x86_64
- php-pdo-5.6.33-1.mga6.x86_64
- php-pdo_mysql-5.6.33-1.mga6.x86_64

8.2MB of additional disk space will be used.

37MB of packages will be retrieved.

Is it ok to continue?



The configuration changes – I didn’t find the README.urpmi.  I did click on update notes, but they just pointed to the /etc/nextcloud/config.php.rpmnew file.

I looked at it.  This isn’t clear what needs to be changed at all.

I’m lost.  

Did I miss the README file somewhere?

Keywords: (none) => feedback

Comment 6 José Jorge 2018-01-05 22:37:05 CET
(In reply to Brian Rockwell from comment #5)
 > The configuration changes – I didn’t find the README.urpmi.  I did click on
> update notes, but they just pointed to the /etc/nextcloud/config.php.rpmnew
> file.
> 
> I looked at it.  This isn’t clear what needs to be changed at all.
> 
> I’m lost.  
> 
> Did I miss the README file somewhere?

Thanks for testing. The README file is the updates notes. It is in /usr/share/doc/nextcloud. The problem is that configuration changes a lot. End users should probably just copy database and path from /etc/nextcloud/config.php to /etc/nextcloud/config.php.rpmnew and then replace the first with that last.

I don't see a clean way to do this automaticaly...
Comment 7 Brian Rockwell 2018-01-05 23:43:19 CET
ok - updated the config.php and was able to get it set up.

With sqllite is lost my users and required me to reset them up.  As long as I named them the same I got my document directories back.  that could be convenient or quite frightening pending how you think about it.

Jose did you run into the same thing?

Keywords: feedback => (none)

Comment 8 José Jorge 2018-01-06 09:18:36 CET
(In reply to Brian Rockwell from comment #7)
> ok - updated the config.php and was able to get it set up.
> 
> With sqllite is lost my users and required me to reset them up.  As long as
> I named them the same I got my document directories back.  that could be
> convenient or quite frightening pending how you think about it.
> 
> Jose did you run into the same thing?

No. You should not lose you sqlite database. I have just tested with MariaDB database, but it should be the same. Can you ensure you choosed the same path for sqlite database?
Comment 9 Brian Rockwell 2018-01-06 21:16:55 CET
When I started nextcloud, the application started as if new not upgraded, so it must of overlaid the database.   I didn't have an option for choosing the directory.

I suspect this is part of the "cost" of using sqlite.

The rest of the application has worked fine, but I do see that risk.
Comment 10 José Jorge 2018-01-06 23:16:53 CET
(In reply to Brian Rockwell from comment #9)
> When I started nextcloud, the application started as if new not upgraded, so
> it must of overlaid the database.   I didn't have an option for choosing the
> directory.
> 

Got it : as data has moved, you have to move your data directory when upgrading, or keep the old path in the config file :

BEFORE:
"datadirectory" => "/usr/share/nextcloud/data",

AFTER:
"datadirectory" => "/var/lib/nextcloud/data",

As /usr/share/nextcloud/data was a symlink to /var/lib/nextcloud, it means one has to move /var/lib/nextcloud/* to /var/lib/nextcloud/data except data and apps directories.

This upgrade is hard for those who have kept the default config!
Comment 11 Brian Rockwell 2018-01-06 23:43:16 CET
As mentioned earlier, I retained the data directory, the old data was there, but not the database of users.

So, there is something else in the database, I'll try another tomorrow and see if I emulate the same thing or can get it to work.  If I can and I suspect it has to do with the hashes, I suspect we need to document carefully the configuration updates.
Comment 12 José Jorge 2018-01-06 23:45:22 CET
(In reply to Brian Rockwell from comment #9)
> I suspect this is part of the "cost" of using sqlite.

Forget my comment 10. You are right, I could reproduce the problem : nextcloud replaces existing sqlite file if you remove the installed => true line in config file.

So this is a end user bug, where I can just say sys admin have to add this at the end of config file, just before closing) :

'log_type' => 'syslog',
  'datadirectory' => '/var/lib/nextcloud/data',
  'updatechecker' => false,
  'check_for_working_htaccess' => false,
  'asset-pipeline.enabled' => false,
  'assetdirectory' => '/var/lib/nextcloud',
  'preview_libreoffice_path' => '/usr/bin/libreoffice',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/usr/share/nextcloud/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/lib/nextcloud/apps',
      'url' => '/apps-appstore',
      'writable' => true,
    ),
  ),
Comment 13 Brian Rockwell 2018-01-07 21:35:17 CET
Hi - did a fresh build of 11.03.   Built it and a user.

Then installed 12.03, indicating as such as "installed" => true

the system then tried to do the upgrade then flagged back that it cannot do upgrades between major versions.

changed "installed" => false, this triggered a replace of the users, but data was retained.

-----

It works, but no luck with the upgrade.

Keywords: (none) => feedback

Comment 14 Brian Rockwell 2018-01-14 17:18:15 CET
fyi - on a straight install of Nextcloud 12.03 it ends up failing for me.  Apparently in that version SQLite is not a standard part of the install and thus the system is looking for mysql/mariadb.

While those are certainly more powerful, they also create a whole new set of configuration challenges.  In my case, mariadb was not installed yet NextCloud assumed it was.  I ended up in this broken situation with no path to install that was in anyway easy.

What did I do?

I went back to Nextcloud 11.03 and built that.

Is this upstream that they are dropping sqlite or is it our choice?  If it is ours, please add that as part of the build for 12.03.
Comment 15 Brian Rockwell 2018-01-19 16:39:21 CET
Okay  - tried another 12.03 rebuild.

included nextcloud-sqlite module

---

didn't work.

---

added

php-pdo_sqlite-3:5.6.33-1.mga6.x86_64

----

rebooted an it worked.
Comment 16 Brian Rockwell 2018-01-19 16:47:12 CET
(In reply to Brian Rockwell from comment #15)
> Okay  - tried another 12.03 rebuild.
> 
> included nextcloud-sqlite module
> 
> ---
> 
> didn't work.
> 
> ---
> 
> added
> 
> php-pdo_sqlite-3:5.6.33-1.mga6.x86_64
> 
> ----
> 
> rebooted an it worked.

we should probably makes the php-pdo-sqlite a dependency on nextcloud-sqlite (12.03) module

I'll move on to mariadb and upgrade testing later today.
Comment 17 Brian Rockwell 2018-01-19 22:09:07 CET
I installed Mariadb and restarted the system and confirmed mysqld is running.

Next I hardened Mariadb using the script:  mysql_secure_installation

go through the prompts and set up admin password and clean-up anonymous stuff.

Then log in as root using:  # mysql -u root -p


Once you’re in.  Then set up a database for nextcloud.   I’m very dynamic and original so I named my database next.

MariaDB [(none)]> create database next;


--- mariadb configured.

Now installed nextcloud 11.03


Note, 11.03 tries to use sqlite by default.  To correct this I had to add the php-pdo_mysql and restart everything to make it able to access mariadb.  Fyi – removed php-pdo-sqlite as well.

Also – all my work to create the nextcloud user was unnecessary for testing.  It wants root anyhow.


Added a user and tested the systems ability to save files.


Upgrading to 12.03

The following 4 packages are going to be installed:

- nextcloud-12.0.3-2.mga6.noarch
- nextcloud-mysql-12.0.3-2.mga6.noarch
- php-exif-5.6.33-1.mga6.x86_64
- php-ldap-5.6.33-1.mga6.x86_64


Working with the config.php was a lot of experimenting, but ultimately I was able to do an upgrade, using default data directory.

Whiteboard: (none) => mga6-64-ok
Keywords: feedback => (none)

Comment 18 Lewis Smith 2018-01-22 21:12:24 CET
This update worries me, which is why I hold the advisory.
Brian had a hell of a time testing it, trying one way then another. Several things strike me:

* The previous version presumed the use of SQlite, the new one MySQL. There must be no obstacle to carrying forward the existing database.

*
> we should probably makes the php-pdo-sqlite a dependency on nextcloud-sqlite
> (12.03) module
Yes.
And the same for the mariadb/MySQL? Or is 'php-pdo_mysql' already a dependancy of 'nextcloud-mysql'?

* That apart, there is a host of information related to the update.
> The README file is the updates notes. It is in /usr/share/doc/nextcloud
Is this the message posted to read during the update?
Are *all* the changes needing to be done by the user noted? Including config.php?
The note should include the fact that it can be found in /usr/.../nextcloud.
Is it worth posting it here to cross-check that everything that has been found along the way is covered?

* In C13 Brian found (I think) that doing the update was refused because it was a version change. He had to frig the update to 'install' for it to go ahead, when it lost the user database. Is this problem still with us? It is not mentioned in C17.

CC: (none) => lewyssmith

Comment 19 Brian Rockwell 2018-01-22 22:14:57 CET
(In reply to Lewis Smith from comment #18)

> 
> * In C13 Brian found (I think) that doing the update was refused because it
> was a version change. He had to frig the update to 'install' for it to go
> ahead, when it lost the user database. Is this problem still with us? It is
> not mentioned in C17.

Hi Lewis - C13 remains with sqlite.  Mariadb/mysql - nextcloud allows an upgrade.

Yes the steps need to be documented out, I hacked around until it worked, could take some hours to document carefully.  Do you need me to focus on the steps that worked for me?  

It will involve doing snapshots of the config files before and after the updates.  We should drop that in the /usr.../nextcloud directory.  Also, it may be wise to try a non-default directory for the data.

In the end, nextcloud and it's parent owncloud are challenging to do major upgrades.
Comment 20 Dave Hodgins 2018-01-23 02:31:38 CET
The procedure is documented. See
https://wiki.mageia.org/en/OwnCloud#Upgrading

I haven't checked to see if the instructions are current, or need changes.

CC: (none) => davidwhodgins

Comment 21 Lewis Smith 2018-01-23 17:25:07 CET
(In reply to Dave Hodgins from comment #20)
> The procedure is documented. See
>  https://wiki.mageia.org/en/OwnCloud#Upgrading
> I haven't checked to see if the instructions are current, or need changes.
Feel free!

@Brian : Since you have installed the update, it should have the README file in
/usr/share/doc/nextcloud/ ; is it short enough to post here? If not, please post it on the qa-discuss thread you raised in parallel. We can review it; and if it is insufficient, enhance it as necessary.
Comment 22 Brian Rockwell 2018-01-25 02:39:58 CET
You should choose to keep rpmnew, but keep the original config.php (if you haven't made a copy).

First thing you'll see after the rpmnew message:

Upgrade information

Starting with Nextcloud version 12, the config file changes a lot. When upgrading from a previous version, you will have to edit by yourself the config file using /etc/nextcloud/config.php.rpmnew as reference.

----

information in /usr/share/doc/nextcloud

-rw-r--r-- 1 root root 47329 Sep 19 16:12 config.sample.php
-rw-r--r-- 1 root root  8868 Sep 19 16:12 AUTHORS
-rw-r--r-- 1 root root   232 Dec 25 03:41 README.urpmi
[root@localhost nextcloud]# pwd
/usr/share/doc/nextcloud


[root@localhost nextcloud]# cat README.urpmi
Upgrade information

Starting with Nextcloud version 12, the config file changes a lot. 
When upgrading from a previous version, you will have to edit by yourself
the config file using /etc/nextcloud/config.php.rpmnew as reference.

I've backed up the old config.pho and made config.rpmnew the main file.  I'll work on what changes..
Comment 23 Brian Rockwell 2018-01-25 03:07:30 CET
<Users>
An important thing to know, the information in your old configuration file will be different in content from this example


# diff config.php config.1103
3,25c3,21
<     "log_type" => "syslog",
<     "datadirectory" => "/var/lib/nextcloud/data",
<     "updatechecker" => false,
<     "check_for_working_htaccess" => false,
<     "asset-pipeline.enabled" => false,
<     "assetdirectory" => '/var/lib/nextcloud',
<     "preview_libreoffice_path" => '/usr/bin/libreoffice',
< 
< 
<     "apps_paths" => array(
<         0 =>
<         array (
<             'path'=> '/usr/share/nextcloud/apps',
<             'url' => '/apps',
<             'writable' => false,
<         ),
<         1 =>
<         array (
<             'path' => '/var/lib/nextcloud/apps',
<             'url' => '/apps-appstore',
<             'writable' => true,
<         ),
<     ),
---
>   'instanceid' => 'ocmfkpxhsfta',
>   'passwordsalt' => 'faAL9AqvJF9G1KIKkX14LonwHbHNzy',
>   'secret' => 'mX15c1TjBZwWZf/th934RtuJQuF0L5hlnE2PMaZgS4B9PENi',
>   'trusted_domains' => 
>   array (
>     0 => '127.0.0.1',
>   ),
>   'datadirectory' => '/usr/share/nextcloud/data',
>   'overwrite.cli.url' => 'http://127.0.0.1/nextcloud',
>   'dbtype' => 'mysql',
>   'version' => '11.0.3.2',
>   'dbname' => 'next',
>   'dbhost' => 'localhost',
>   'dbport' => '',
>   'dbtableprefix' => 'oc_',
>   'dbuser' => '<dbuser>',
>   'dbpassword' => '<dbseed>',
>   'logtimezone' => 'UTC',
>   'installed' => true,


Reviewing this I will add below "preview_libreoffice_path" => '/usr/bin/libreoffice',:

    'instanceid' => 'ocmfkpxhsfta',
    'passwordsalt' => 'faAL9AqvJF9G1KIKkX14LonwHbHNzy',
    'secret' => 'mX15c1TjBZwWZf/th934RtuJQuF0L5hlnE2PMaZgS4B9PENi',

Then I will add the following after the

    "apps_paths" => array(
        0 =>
        array (
            'path'=> '/usr/share/nextcloud/apps',
            'url' => '/apps',
            'writable' => false,
        ),
        1 =>
        array (
            'path' => '/var/lib/nextcloud/apps',
            'url' => '/apps-appstore',
            'writable' => true,
        ),
    ),

This is pulled over from the old config file

  'dbtype' => 'mysql',
  'version' => '11.0.3.2',
  'dbname' => 'next',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => '<dbuserid>',  
  'dbpassword' => '<dbpasswordseed>',
  'logtimezone' => 'UTC',
  'installed' => true,


The config file is closed with:

);


Once I’ve saved the config.php file, I go ahead and reboot.  You can stop and start the instance if you’d like.

When you return to the Nextcloud url, you’ll see the upgrade page.

I run the upgrade page and it works.

If you look at the config.php file after the upgrade, you’ll see that nextcloud has revised it as needed.


<<<Hackers, be aware this is built on a VM I’m throwing away, so don’t get too excited>>>
Comment 24 Dave Hodgins 2018-02-06 06:37:32 CET
I really don't like the idea of an update that requires such extensive changes.
That said, as long as the readme.urpmi is clear on the needed changes, and given
that the package is likely only used by more experienced users, I think we should
allow this as an update.

While the list of srpms is available above, we still need the purpose of the
update, list of cve ids (if any), etc., for the advisory.
Comment 25 Dave Hodgins 2018-02-08 11:48:35 CET
Adding the feedback tag. Please remove it when the info for the advisory has
been added to this report.

Keywords: (none) => feedback

Comment 26 Morgan Leijström 2018-02-12 14:56:52 CET
Good work guys :)

It is very convenient Nextcloud is packaged - That way it can be used by many single person/small companies/organisations or even home use.

(In reply to Dave Hodgins from comment #24)
> I really don't like the idea of an update that requires such extensive
> changes.

I agree with that.  

Many are like me, or less, that find Nextcloud is useful for internal needs, and they do not know much about cleaning up a mess.  They cold probably read up on it, but do not want that surprise mess just suddenly landing on them when they just do not have the time but they need the server running.

Many small internal installations may not even need update, those fractional-time-admins may not want to throw time on clearing out mess with some old incompatible plugin, or whatever, when they want to just continue their normal completely different occupation... 


As we do not have any repo for "know problematic and potentially borking updates" i suggest to "mis"use backport like before, to avoid some users borking their installation by ignorance or mistake.



Still, for security updates some sites should be upgraded, si it is good if users be informed.

Idea:  What if we have a package that updates in normal updates repos, and the only thing that package do is trig that "This update comes with important information" dialog, and in that tell the user there is an update in backports, and also show a link to https://wiki.mageia.org/en/Nextcloud.

That package should be pulled in as dependency first time Nextcloud is installed.

User is then informed, and can read up and perform the update.

(And/or note in blog there is a new Nextcloud, but all do not read it.)


Note the difference from a message popping up *after* the update: "Please now check your server this update potentially borked...  You must now... etc, etc..."  ;)



Note I am very grateful for you packaging it, it is just the serving i wish there is some caution with  :)




> Starting with Nextcloud version 12, the config file changes a lot. 
> When upgrading from a previous version, you will have to edit by yourself
> the config file using /etc/nextcloud/config.php.rpmnew as reference.

Well put.  Maybe you can update 
https://wiki.mageia.org/en/OwnCloud#-.3E_Nextcloud_12
When the update is settled?  And may other info you see fit.

:)

CC: (none) => fri

Comment 27 José Jorge 2018-03-04 11:10:04 CET
(In reply to Morgan Leijström from comment #26)
> As we do not have any repo for "know problematic and potentially borking
> updates" i suggest to "mis"use backport like before, to avoid some users
> borking their installation by ignorance or mistake.
> 

The problem is that even with backports, people won't install it except they are advanced users, and read the Wiki etc. But Ok, I will submit this to backports, we'll see if it helps.

Sysadmins, please remove this update from updates_testing.

SRPM :

nextcloud-12.0.3-2.mga6.srpm

RPMS :

nextcloud-12.0.3-2.mga6.noarch.rpm
nextcloud-mysql-12.0.3-2.mga6.noarch.rpm
nextcloud-postgresql-12.0.3-2.mga6.noarch.rpm
nextcloud-sqlite-12.0.3-2.mga6.noarch.rpm
Comment 28 Morgan Leijström 2018-03-04 12:14:36 CET
Yes the idea is to avoid unexperienced users getting into trouble.

Thanks

/Morgan
José Jorge 2018-03-16 08:14:04 CET

Whiteboard: mga6-64-ok => (none)
Keywords: feedback => (none)


Note You need to log in before you can comment on or make changes to this bug.