Working from a clean Debian6 install, I wasn't able to get koha-common's script to work (probably my fault, more on that later after some more noodling around if I can't get it to work), so I aptitude purge'd it and then aptitude install'd the plain koha package. That worked fine, so I thought I'd go back and try again with the koha-common script, but this time I noticed there was all kind of kruft left over after the purge. I'll probably start over again with a fresh OS install, but I thought I'd put it out here - my understanding is that an aptitude PURGE is supposed to get rid of all data, config files, logs etc, basically a best effort to return the system to the way it was, especially if nothing else was added between the install, attempted configure and then the purge. As opposed to REMOVE which is supposed to delete all the binaries but leave the config files. I imagine this is an issue for the person responsible for the packaging, if s/he doesn't hang out here, could someone please forward this? I don't feel I've tested it thoroughly enough to file a bug. . .
hansbkk@gmail.com schreef op di 15-02-2011 om 00:03 [+0700]:
I'll probably start over again with a fresh OS install, but I thought I'd put it out here - my understanding is that an aptitude PURGE is supposed to get rid of all data, config files, logs etc, basically a best effort to return the system to the way it was, especially if nothing else was added between the install, attempted configure and then the purge.
I'll check the Debian specs, but purge should at least remove the config files. It's possible it's not supposed to remove the stuff in /var/lib/koha, but I'm not sure. Either way, I'll check and see if I can convince it to do what's right. To clean it out manually, all you should need to remove is /etc/koha, /var/lib/koha, and /var/log/koha - everything else (/usr/share/koha IIRC) should be taken care of by the remove (although check the cronjobs too, there's a bug open about them not getting removed.) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On Tue, Feb 15, 2011 at 4:16 AM, Robin Sheat <robin@catalyst.net.nz> wrote:
hansbkk@gmail.com schreef op di 15-02-2011 om 00:03 [+0700]:
I'll probably start over again with a fresh OS install, but I thought I'd put it out here - my understanding is that an aptitude PURGE is supposed to get rid of all data, config files, logs etc, basically a
<snip>
To clean it out manually, all you should need to remove is /etc/koha, /var/lib/koha, and /var/log/koha - everything else (/usr/share/koha IIRC) should be taken care of by the remove (although check the cronjobs too, there's a bug open about them not getting removed.)
Thanks for the manual remove details, but I figured the koha-create script (and/or stuff I did manually to get the plain koha package installed) probably did some Apache foo as well that I'm a bit rusty on troubleshooting, so best to start clean and this time write down every keystroke FFR, especially if I need to come back here for help. While I'm at it, thanks so much (to all) for your FOSS contributions, I'm coming back to Koha after a few years away and the install part of it seems to have made leaps-and-bounds progress.
OK, I got koha-common to work - great job and thanks! A couple of suggested adds to the README.Debian (and other doc locations, wiki etc?) a2dissite 000-default is definitely necessary if you're using the usual http port, otherwise you still get the default Apache "It works" page. And a reminder would be helpful about setting up DNS (or hosts file for testing/dev purposes) if you're going to use prefix-suffix rather than a different port for the admin interface - ipaddress-suffix doesn't seem to work. For those searching the archive later, here's my koha-sites.conf DOMAIN=".hh.net" INTRAPORT="80" INTRAPREFIX="" INTRASUFFIX="-admin" DEFAULTSQL=""
hansbkk@gmail.com schreef op di 15-02-2011 om 15:37 [+0700]:
is definitely necessary if you're using the usual http port, otherwise you still get the default Apache "It works" page.
I don't think that it is necessary to do this, as it's all virtual hosting anyway. One of our Koha servers has a 000-default site on it still.
And a reminder would be helpful about setting up DNS (or hosts file for testing/dev purposes) if you're going to use prefix-suffix rather than a different port for the admin interface -
Hmm yeah, I can see the benefit of that.
ipaddress-suffix doesn't seem to work.
It won't, your browser won't understand it at all. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On Wed, Feb 16, 2011 at 4:38 AM, Robin Sheat <robin@catalyst.net.nz> wrote:
hansbkk@gmail.com schreef op di 15-02-2011 om 15:37 [+0700]:
a2dissite 000-default
is definitely necessary if you're using the usual http port, otherwise you still get the default Apache "It works" page.
I don't think that it is necessary to do this, as it's all virtual hosting anyway. One of our Koha servers has a 000-default site on it still.
My setup (virgin Debian6 install from LiveCD + aptitude install koha-common, no fiddling other than the conf file I posted and ran the koha-create script) Without the -admin suffix my browser definitely brought up the "It's working" page from Apache. Running the " a2dissite 000-default" command - and not doing anything else then resulted in the koha maintenance notice showing up. If anyone truly doubts this isn't the way it goes I'd be willing to run through it again in a VM. . . I did qualify that (I assume) if you're using a different OPAC-port this wouldn't be an issue, but I imagine most people want that at the default. In my case I didn't want to mess with ports at all, as I prefer just using a different hostname for the OPAC, I would think most noobs would prefer the same. It is possible this all happened before I did the DNS/host file configuration, and was using localhost, but IMO it should work that way for someone doing a virgin setup, as far as they're concerned it's the only website on their installation. ----------- Another couple of points, admittedly minor - it isn't 100% clear that the .conf file needs to be created and then the koha-create script run, getting it's variable values from that file. I did figure it out of course but the "get the values needed from the create script" comment did throw me for a little while, as that's not commented either and there are a bunch of other variables at the top that *don't* get set by the conf. Also, populating the default SQL script probably shouldn't be there for a first-run example, or at least some information on what it's for and the fact that it should be empty for a fresh virgin install would be useful. All just IMO of course, whoever developed this functionality is to be commended and I'm very grateful. Just suggesting a couple of minor tweaks to make the process a little more noob-friendly. . .
hansbkk@gmail.com schreef op wo 16-02-2011 om 12:32 [+0700]:
Without the -admin suffix my browser definitely brought up the "It's working" page from Apache. Running the " a2dissite 000-default" command - and not doing anything else then resulted in the koha maintenance notice showing up.
OK, curious. It definitely shouldn't, perhaps there's an issue in the apache templates that makes it happen. I'll have a look when I get the chance.
Another couple of points, admittedly minor - it isn't 100% clear that the .conf file needs to be created and then the koha-create script run, getting it's variable values from that file. I did figure it out of course but the "get the values needed from the create script" comment did throw me for a little while, as that's not commented either and there are a bunch of other variables at the top that *don't* get set by the conf.
Ideally I'd probably like this to be a series of debconf questions, or at least pop a default file in there. It something that I do need to work on.
Also, populating the default SQL script probably shouldn't be there for a first-run example, or at least some information on what it's for and the fact that it should be empty for a fresh virgin install would be useful.
I'm not entirely sure what you mean by this.
All just IMO of course, whoever developed this functionality is to be commended and I'm very grateful. Just suggesting a couple of minor tweaks to make the process a little more noob-friendly. . .
Sure, it's appreciated :) there's a lot of fine-tuning that I hope to do to this, it's just a matter of finding time. Feel free to file bugs for any of these things that you think warrant it, it makes it less likely that I'll forget about them. For reference, the way we run it here on our hosted system is that we have another package that supplies default SQL for new instances and another SQL file for the demo instance, and it also provides cron jobs for backups, and a standard configuration. This isn't really necessary for smaller instances, and we mostly do it because it lets us have our configuration in one version-controlled, packaged place. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On Thu, Feb 17, 2011 at 3:52 AM, Robin Sheat <robin@catalyst.net.nz> wrote:
Also, populating the default SQL script probably shouldn't be there for a first-run example, or at least some information on what it's for and the fact that it should be empty for a fresh virgin install would be useful.
I'm not entirely sure what you mean by this.
I just meant that the wiki, README etc should be IMO primarily targeted to relatively non-technical people new to Koha - reliable "cookbook" style directions "step 1" "step 2" etc. So the initial example .conf file in the installation instructions should have the minimum needed to get Koha installed, and more advanced stuff like custom SQL files to pre-populate the DB left to later-stage explanations.
participants (2)
-
hansbkk＠gmail.com -
Robin Sheat