---- Reported by email@example.com 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 firstname.lastname@example.org 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 email@example.com 2007-10-04 13:26:31 ----
MJ, is there an uninstall script now?
---- Additional Comments From firstname.lastname@example.org 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 email@example.com 2008-03-17 16:42:47 ----
Re-assigning to Galen ... low priority, but on the list somewhere :-)
---- Additional Comments From firstname.lastname@example.org 2009-07-01 09:26:14 ----
(In reply to comment #0)
> A companion to installer.pl should be written to uninstall a koha instance.
> 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 email@example.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 firstname.lastname@example.org 2009-12-10 09:41:11 ----
Can you post your thoughts here?
--- Bug imported by email@example.com 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: firstname.lastname@example.org.
Previous reporter was email@example.com.
The original assignee of this bug does not have
an account here. Reassigning to the default assignee
for the component, firstname.lastname@example.org.
Previous assignee was email@example.com.
CC member firstname.lastname@example.org does not have an account here
Restoring where "Previous assignee was email@example.com"
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?