Bug 974544 - externalize database config; back-up database on every update
Summary: externalize database config; back-up database on every update
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: owncloud
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: DO NOT USE account not monitored (old adamwill)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-14 11:51 UTC by David Jaša
Modified: 2014-08-09 08:45 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-09 08:45:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Jaša 2013-06-14 11:51:48 UTC
Description of problem:
Every owncloud document states that first step of even update is to back-up the existing installation:
http://doc.owncloud.org/server/4.5/admin_manual/update.html

AFAIU, current fedora package doesn't include database connection configuration, that is left to owncloud runtime. It would be great if the database connection could be externalized to package-able configuration file, the package would then keep the file on upgrades (thanks to standard rpm facilities) and the database could be easily backed up during upgrades using tools called from rpm scriptlets.

There could be also cron job template for regular database backups.

Version-Release number of selected component (if applicable):
owncloud-4.5.12-1.fc19

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Gregor Tätzner 2013-06-14 20:14:30 UTC
Not sure if I'm following. The db config gets inserted into the main config i.e.:
  ...
  'dbtype' => 'mysql',
  'dbname' => 'xxx',
  'dbuser' => 'xxx',
  'dbpassword' => 'xxx',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_'
  ...

Why would you want to externalize that? Of course one could write a little tool to extract those options and dump that database to a preset location.

Another thing you need to keep in mind is that the upgrade process of oC doesn't start strictly at the point when you upgrade the package. You have to actually visit the oC web page of your installation and give it a good kickin', at least for major upgrades. Don't know how minors are handled, but it would be nice to have a backup of /etc/owncloud/config.php anyway.

Comment 2 Fedora End Of Life 2013-09-16 14:11:27 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Comment 3 Fedora Admin XMLRPC Client 2014-08-08 17:02:54 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Fedora Admin XMLRPC Client 2014-08-08 19:28:40 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 Adam Williamson 2014-08-09 08:45:34 UTC
New maintainer here (well, one of my identities)...I'm kinda with Gregor on this one, it seems like a slightly confusing mix of non-issue and upstream enhancement request. Doing database backups on webapp updates seems somewhat out of scope for webapp packaging - it'd be a nice trick but it's really something upstream ought to be doing, I'd say (it'd make a good upstream feature request but I wouldn't be surprised if it was there already). I don't see why you think it would require the database configuration to be separated from the main config - as long as the key names don't change it would be trivial to isolate them, and if they *do* change, having them in a separate file doesn't help you. It just seems like needless divergence from upstream.

With current OwnCloud versions, OC writes the database config you supply out to /etc/owncloud/config.php , which is tracked by the package management system of course. (In practice the file is modified on every OC deployment by the first run wizard thingy, so it will never be updated by the package after initial install - I have a feature request in upstream for a change that would allow us to ship our Fedora config as a subsidiary config file, but it's not practically possible right now). I think this was also the case back when you wrote the bug, but it's certainly the case now.

For now I'm going to close this, please re-open if you think I'm missing something.


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