---- Reported by mjr@ttllp.co.uk 2003-05-15 02:58:40 ---- A companion to installer.pl should be written to uninstall a koha instance. With multiple install support, this will only become more useful. ---- Additional Comments From mjr@ttllp.co.uk 2004-04-14 11:00:47 ---- Steps given on the list by Frank Weis: > *) Drop the Koha database > *) remove the web sites (rm -rf /usr/local/koha if you installed in the > standard location) > *) rm /etc/koha.conf > *) rm /etc/koha-httpd.conf > *) delete the koha related entries in the mysql users table ---- Additional Comments From jmf@liblime.com 2007-10-04 13:26:31 ---- MJ, is there an uninstall script now? ---- Additional Comments From mjr@ttllp.co.uk 2007-10-05 01:49:37 ---- There is a partial uninstall in 3.0, but the database drop still needs doing manually - that require permissions no longer given to koha. Steps 2-4 of the above list are given by make uninstall. ---- Additional Comments From jmf@liblime.com 2008-03-17 16:42:47 ---- Re-assigning to Galen ... low priority, but on the list somewhere :-) ---- Additional Comments From koha-devel@litarena.com 2009-07-01 09:26:14 ---- (In reply to comment #0) > A companion to installer.pl should be written to uninstall a koha instance. > With > multiple install support, this will only become more useful. > I've been giving this utility some consideration and I believe that there's a little more to it than at first meets the eye. ---- Additional Comments From koha-devel@litarena.com 2009-07-01 13:18:29 ---- I've been giving http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=459 (No unistall script) some thought. And I've come up with what might well be a solution. I'd be interested to hear thoughts on the matter. ---- Additional Comments From chris@bigballofwax.co.nz 2009-12-10 09:41:11 ---- Can you post your thoughts here? --- Bug imported by chris@bigballofwax.co.nz 2010-05-20 23:31 UTC --- This bug was previously known as _bug_ 459 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=459 Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was mjr@ttllp.co.uk. The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, gmcharlt@gmail.com. Previous assignee was koha-devel@litarena.com. CC member koha-devel@litarena.com does not have an account here
Restoring where "Previous assignee was mjr@ttllp.co.uk"
Created attachment 12435 [details] Untested uninstall script edited in Windows This bug caught my attention. Here is my initial, rough draft attempt. If anyone wishes to polish it up, test it, comment that it is missing something, that would be great. The measure of good software, in my books: installs easy, does what it says, and uninstalls easy. Hopefully, this script will work towards making the last point a reality.
Created attachment 12451 [details] Revised partially tested, but still a bit buggy non-patch file Fine, I'll take the bug. I haven't patch-i-fied this yet. I've only run this on a packages installation. The koha zebra daemon removal part still needs some work. But once I'm happy with my testing on packages, I'll work on testing it on a git install. Then I'll go old-school with a tarball install. I probably need to add logic to exclude the git clone directory from deletion. Any other ideas or feedback? Feel free to test tweak and post a patch if you want. :)
Created attachment 12606 [details] Revised untested non-patch file - Prevent package uninstalls now I was told that anything that even attempted a packages uninstall would not pass QA, so no packages processing (except detection) is done. MJ Ray's security rant made me revisit sections of this to remove as many sudo's as possible. Not all have been removed. The Ubuntu instructions create an /etc/cron.d/koha cronjob using sudo. Should all git and tarball installs use user crontab files and not /etc/cron.d /etc/cron.hourly or /etc/cron.daily? Feedback needed.
Why would we not use koha-remove <instance> and then apt uninstall koha-common then apt autoremove? I'm not sure this bug needs a fix anymore? A developer is going to be using either a devbox or a koha-testing-docker; an average user hopefully will be using Debian packages as advised in our documentation, and certainly, support vendors will be using the packages as well.
(In reply to Liz Rea from comment #5) > Why would we not use koha-remove <instance> and then apt uninstall > koha-common then apt autoremove? > > I'm not sure this bug needs a fix anymore? A developer is going to be using > either a devbox or a koha-testing-docker; an average user hopefully will be > using Debian packages as advised in our documentation, and certainly, > support vendors will be using the packages as well. I tend to agree, but isn't installation from tarball still supported?
(In reply to Kyle M Hall from comment #6) > (In reply to Liz Rea from comment #5) > > Why would we not use koha-remove <instance> and then apt uninstall > > koha-common then apt autoremove? > > > > I'm not sure this bug needs a fix anymore? A developer is going to be using > > either a devbox or a koha-testing-docker; an average user hopefully will be > > using Debian packages as advised in our documentation, and certainly, > > support vendors will be using the packages as well. > > I tend to agree, but isn't installation from tarball still supported? I'm with Liz on this one. While people can install Koha from a tarball, I can't think of any Linux software that has a uninstall script when installed from source tarball...