[Koha] New Debian install - OPAC invisible

[Mark Tompsett]

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_File
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