Hey all, I've got a latest-ed Koha install on Debian Jessie on which the staff client is displaying properly in the web browser, but the OPAC address is displaying the Apache2 default web server page (It Works!). I followed (with some other help) these <http://wiki.koha-community.org/wiki/Debian_Jessie_development_setup> directions. This is all I want - a test server accessible from the local machine. Currently configured to accept http://127.0.1.1:8080 as staff and http://127.0.1.1:80 as OPAC. I'm sure I'm doing something stupid, but I don't know quite what it is. I don't have a web error log for OPAC, will post code and .conf files as needed. I've gone through staff config as far as setting a library. -- View this message in context: http://koha.1045719.n5.nabble.com/New-Debian-install-OPAC-invisible-tp585611... Sent from the Koha-general mailing list archive at Nabble.com.
Hi Apparrish, These commands should disable the default site, then restart apache. I believe your OPAC will show up after that: a2dissite default apache2ctl restart Best, Doug -----Original Message----- From: Koha [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Aparrish Sent: Wednesday, October 7, 2015 12:40 PM To: koha@lists.katipo.co.nz Subject: [Koha] New Debian install - OPAC invisible Hey all, I've got a latest-ed Koha install on Debian Jessie on which the staff client is displaying properly in the web browser, but the OPAC address is displaying the Apache2 default web server page (It Works!). I followed (with some other help) these <http://wiki.koha-community.org/wiki/Debian_Jessie_development_setup> directions. This is all I want - a test server accessible from the local machine. Currently configured to accept http://127.0.1.1:8080 as staff and http://127.0.1.1:80 as OPAC. I'm sure I'm doing something stupid, but I don't know quite what it is. I don't have a web error log for OPAC, will post code and .conf files as needed. I've gone through staff config as far as setting a library. -- View this message in context: http://koha.1045719.n5.nabble.com/New-Debian-install-OPAC-invisible-tp585611... Sent from the Koha-general mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
On 15-10-8 7:40 am, Aparrish wrote:
Hey all,
I've got a latest-ed Koha install on Debian Jessie on which the staff client is displaying properly in the web browser, but the OPAC address is displaying the Apache2 default web server page (It Works!).
I followed (with some other help) these <http://wiki.koha-community.org/wiki/Debian_Jessie_development_setup> directions. This is all I want - a test server accessible from the local machine.
Currently configured to accept http://127.0.1.1:8080 as staff and http://127.0.1.1:80 as OPAC. I'm sure I'm doing something stupid, but I don't know quite what it is. I don't have a web error log for OPAC, will post code and .conf files as needed. I've gone through staff config as far as setting a library.
you probably have another default apache rule overriding your OPAC rule try disabling your default rule... $*sudo a2dissite* *000-default*
On 15-10-8 10:36 am, Mason James wrote:
On 15-10-8 7:40 am, Aparrish wrote:
Hey all,
I've got a latest-ed Koha install on Debian Jessie on which the staff client is displaying properly in the web browser, but the OPAC address is displaying the Apache2 default web server page (It Works!).
I followed (with some other help) these <http://wiki.koha-community.org/wiki/Debian_Jessie_development_setup> directions. This is all I want - a test server accessible from the local machine.
Currently configured to accept http://127.0.1.1:8080 as staff and http://127.0.1.1:80 as OPAC. I'm sure I'm doing something stupid, but I don't know quite what it is. I don't have a web error log for OPAC, will post code and .conf files as needed. I've gone through staff config as far as setting a library.
you probably have another default apache rule overriding your OPAC rule
try disabling your default rule... $*sudo a2dissite* *000-default* ^ oops.. a goofy cut/paste in my email client
Greetings, Your apache settings have the default site first THEN the Koha site. Three solutions: 1) Pay a support company to set it up for you. Seriously, sometimes a bill for someone else's 30 minutes is cheaper than you spending an entire day trying to do it yourself. 2) Use name based access! You can do just a local machine access by name based access. This requires setting up a DNS entry OR the equivalent. -- As I posted in another post: "If you don’t know how to do that or the equivalent, I’ll call upon the ancient spirits of evil with the Windoze incantation of C:\windows\system32\drivers\etc\hosts. *casts the call a troll spell* *running away* THIS IS NOT HOW YOU SHOULD DO IT PERMANENTLYYYYYYYYYYYYY!" 3) Fixing the Apache order 3a) I don't know how off the top of my head, name based access is way easier! 3b) DON'T EVEN THINK ABOUT IT, BUT YOU ARE PROBABLY GOING TO DO IT. (ARG! Those were the first suggestions just posted) GPML, Mark Tompsett
I fail to understand the Apache default website fetish and the advantage of longish rage emails without real advice besides "pay someone to do it in the way I prefer" over a simple command that leads to the result people ask for. -- Mirko
Greetings, We owe them the best solution. The best solution doesn't break others, and disabling default has that capacity. That's why packages are name-based by default. If Koha is accessed by IP, that's not default and requires Apache and Networking configuration knowledge. Knowledge which is not easily condensed to "a simple command that leads to the result people ask for". Networking and Apache configuration is really running the boundary of Koha support. This is subtly demonstrated by the express lack of networking references on the Debian pages. Why should default not be disabled? Perhaps there are other sites on the machine, and disabling default isn't the only problem one, and disabling may affect other web applications which the user is unaware of. If there are others, one may find themselves at something other than "It Works!" but not the OPAC either. So the suggested quick solution may not solve the problem all the time. Most of time, it likely will work, but not in all cases. Is debugging all those cases part of Koha's scope? I don't believe so. This is why a support company would be recommended. They would be able to navigate any pitfalls provided by the users configuration which could vary wildly from user to user. As stated before, name-based access is the default. Name based installations are the simplest. All that is needed is the hosts file hack. But a DNS entry is the correct solution, because otherwise someone has to run around to every computer on the network editing their hosts file?! That's the wrong way to do networking, but best practices regarding networking is definitely beyond scope. Again, a support company would be able to help deal with that. The /etc/koha/koha-sites.conf file can help determine http://{OPACPREFIX}{InstanceName}{OPACSUFFIX}{DOMAIN}:{OPACPORT} and http://{INTRAPREFIX}{InstanceName}{INTRASUFFIX}{DOMAIN}:{INTRAPORT} Also, knowing where to put the hosts file hack ON THE CLIENT is hard. http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#Tweak_Hosts_Fi... if the CLIENT is a linux box: /etc/hosts if the CLIENT is a windows box: C:\windows\system32\drivers\etc\hosts -- even C: could be wrong. :( -- which is why networking advice is really hard to do! And even once tweaked, only that client will work for name-based access, because the DNS entry wasn't set up. This is why the Ubuntu instructions do it to the server's /etc/hosts file, and then proceed to use lynx on the server to set Koha up. Next, if someone decides to move their Koha on the internet, having already set up for name-based access makes the transition easier. Just think of an imaginary domain: forthepublic.com Locally, it is hacked to have library.forthepublic.com. Then one day forthepublic.com is set up with the appropriate DNS records as required (and remove any hacks), and magically library.forthepublic.com is hosted on the internet. Not to mention, bookmarks will break when they aren't changed, but the ip address has. No one likes reading documentation. People rarely do. http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#It_Works.21 (That points to the relevant Apache configuration documentation) And imagine they disable the default site, and then install some software that depends on and they can't get it working. So they ask that software group for help. And they re-enable it. And now Koha breaks again. The cleanest solution is to only touch what you need to touch. DNS entries and name-based access are really, really clean. If one insists on IP address access, I would avoid port 80 for the OPAC. This ensures the default site is untouched, and Koha will not break or be broken by another application which may or may not be installed in the future. I do apologize for the "longish rage emails" (frustration perhaps, not rage), but I strongly feel that disabling default is the wrong solution and should be avoided. So, this isn't an "Apache default website fetish". It is an aim to reduce the amount of support needed long term, because of potential horrible cross-interactions or server relocations. Less is more. Less change and more default (pun intended) is good. GPML, Mark Tompsett
Hi, Mark Tompsett schrieb am 08.10.2015
Greetings,
We owe them the best solution.
I don't think I owe anyone anything when it comes to free community support. But I'd rather not decide what is the best solution for everyone.
requires Apache and Networking configuration knowledge. Knowledge which is not easily condensed to "a simple command that leads to the result people ask for".
True, there is a second command (add Listen 8080 to ports.conf). All things Koha require a lot of special knowledge. We could close the list then and make it autoreply "get paid support" to all questions.
Why should default not be disabled? Perhaps […]
Perhaps not. Who knows. When someone asks about a Koha installation on a local IP address, I'd assume a test installation on a dedicated (virtual) machine, not a production system, unless they tell me otherwise.
Most of time, it likely will work, but not in all cases. Is debugging all those cases part of Koha's scope?I don't believe so. This is why a support company would be recommended. They would be able to navigate any pitfalls provided by the users configuration which could vary wildly from user to user.
So we close the list? I do not see why we should make any difference between the Apache setup (magic only a professional can do) and Koha (much more complex than doing some webserver config). Maybe we should go as far as labelling free community support dangerous, because we can never take into account all things that may or may not be, while suppport companies could get the whole picture before making recommendations?
As stated before, name-based access is the default. Name based installations are the simplest. All that is needed is the hosts file hack. But a DNS entry is the correct solution, because otherwise someone has to run around to every computer on the network editing their hosts file?!
A "hack" with a wrong DNS entry is the right solution? Sounds fishy to me. I do not assume any other computers needing to access it in this and many other cases. There must be thousands of local test installations out there. Many of which lead to getting a support company once people tested and decided they would actually like to migrate to Koha.
That's the wrong way to do networking, but best practices regarding networking is definitely beyond scope.
You can either let people do it in a way that works, or explain the way you think is better. "Don't do A, but B is too complicated, hire someone" is not a constructive answer.
Also, knowing where to put the hosts file hack ON THE CLIENT is hard. http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#Tweak_Hosts_Fi...
Oh, even more reading required for the easiest solution. :P
Next, if someone decides to move their Koha on the internet, having already set up for name-based access makes the transition easier.
Because they all run on myDNSname.org? That will be lot of fun once I spend the 12€ to buy that domain.
[lots of imagination stuff]
I imagine nothing of that. I see a question that from years of experience (I'm a support provider, we know a lot of stuff :P) I can me assume to be about a local installation and I give advice that is easy to follow. If that leads to a follow-up question, fine. In dozens of cases it lead to something like "great, it's working now, thanks a lot, koha is awesome". Cheers, Mirko
Hello all, Thank you all for the suggestions. I had already disabled 000-config and enabled koha, and actually deleted the default site on the recommendation of another set of instructions, which was why I was confused. However, upon opening the web browser again this morning the OPAC catalog is displaying properly. Guess it just needed a refresh. Thanks again! -- View this message in context: http://koha.1045719.n5.nabble.com/New-Debian-install-OPAC-invisible-tp585611... Sent from the Koha-general mailing list archive at Nabble.com.
participants (5)
-
Aparrish -
Doug Dearden -
Mark Tompsett -
Mason James -
Mirko Tietgen