Sorry, this might be a bug. I'll try to reproduce it and come up with a workaround.

We'd really like to try to get to the bottom of this.

So was the domain or IP address that you used to use the appliance (ie in your web browser) the same as what you set in the firstboot scripts?

Always happy to hear from upstream devs! :)

I won't go into the in-and-outs of TKL appliances, but the basic idea is that they are fully pre-installed and configured ready to go. What little config info required is provided with an interactive firstboot setup console script. In the OpenPhoto appliance, these include OpenPhoto admin ('owner') email address, password and domain. As the name suggests, the firstboot scripts (aka turnkey-init scripts) run at firstboot after installation reboot (with the exception of some image types eg OVZ, OpenStack, etc - which either require values preseeded or manual initialisation by running 'turnkey-init'). So in the case of OpenPhoto, I would imagine that the appliance should not need to access /setup (as any required config has been done already from the console on firstboot). Ie the behaviour I experienced trying to reproduce this bug is what we would be hoping for.

So thanks again for your input Jaisen!

Resolving 'Issue #254' will eliminate the need to access /setup at all (in the context of TKL anyway) I would think. I would doubt that there would be any need to adjust DB/FS info in a dedicated appliance like TKL (although there may be edge cases, so great to have that info for reference).

Furthermore, the original post points to the configuration file not existing at `src/userdata/configs/{hostname}.ini`. The site redirects the user to /setup if it doesn't find that file. Is it possible that the cause is a hostname mismatch between what's int he browser and what TKL thought and used for the {hostname.ini} file?

Ahhh... I have a hunch that you have it in one! The info that you have provided and the fact that I used the IP address of my test appliance and didn't have the issue suggests that these others may not have done it that way thus causing this behaviour. I didn't write the firstboot/init script for the OpenPhoto appliance but I strongly suspect that the TKL script writes to that file, so if there is a mismatch between what the user inputs on firstboot and the hostname (/IP) used to access OpenPhoto it tries to run setup. Perhaps TKL needs to reword the firstboot script so this requirement is a little more explicit.

I'd be really interested to hear from the others who are experiencing this issue to confirm that this may be the issue/solution.

Other than #4 your experience is nothing to do with the OpenPhoto appliance (and I can't comment on #4 but I assume that you are right).

You would/will have a similar experience with any of the TKL appliances when using OVZ templates (PVE or any other implementation of OVZ) - if you don't initialise the system when you create it. It is a shortcoming of the usuage of TKL as an OVZ template. But there is a solution - you just need to RTFM! :)

As documented quite extensively (on the OVZ template release announcement blog post, in the Wiki in relation to both OVZ templates and PVE usage and as comments on numerous threads), OpenVZ does not have a true console. Therefore, it is impossible to have interactive firstboot scripts run automatically (as they do in most other appliance builds). Or more correctly, it is possible, it's just not possible for you to interact with them (which causes services such as Webmin to hang and other anomolies).

Ideally, it would be nice if we had a way of preseeding the required values from the PVE UI (similar to what you do when launching via the Hub) so this isn't such an issue. But until that happens, running OVZ templates requires running of the whole firstboot sequence manually. To make this easier for users the devs have included a nice little generic wrapper script to do this (it's actually available in all appliances, not just OVZ ones).

Run it like this:

turnkey-init

And it will run all the firstboot scripts (as happens automatically with an ISO install or a VM import). This will address your points as follows:

1. Runs openphoto.py - allowing you to enter details from the start
2. Runs mysql.py - allowing you to enter a password for the MySQL root account.
3. As you suspect this is a part of 1, but it also re-runs mysql.py non-interactively (using openphoto as the user name) and sets a random string password for the account (which it also adds to the OpenPhoto config file so that OpenPhoto can interact with the DB).

Hope that clears it up for you.

Sorry I left the 'bin' off. Fixing now... 

So no it hasn't and I doubt it will. It is a limitation of the OpenPhoto software itself. It can only be hosted on one domain name. So what you are trying to acheive is not possible OOTB. I can't speak for the OpenPhoto devs but i assume that it is to make the server more secure and reduce chances of things like cross-site scripting attacks. That's usually why it is done AFAIK. It is possible that there is a way you can hack it to make it host from multiple domains (or even be completely domain agnostic) but you'd need to contact the OpenPhoto community to see if that is possible and/or how you do it.

Having said that it is possible without hacking the software... But what you'll need to do is either 1) setup a reverse proxy (non-trival and probably not recommended unless you have other content you wish to serve). Or 2) set it up to serve on the external domain name (assuming you have a domain name linked to your external IP, either via some dynamic DNS provider or something else...) and reroute your internal network connection to the domain name.

If you want to go with 1) then I suggest that you check out google. I'm sure you'll find plenty of tutorials on how to do that.

If you want to go with 2) then rerun the config (as posted by me above) to resest your server to the external domain name you wish to use. You'll then need to add an entry to your hosts file (on every PC in your LAN that you wish to use the server from) that points to the local IP. The only issue with that is that if you do this with a portable device (laptop/tablet/phone/etc) you will only be able to view your photos within the LAN (it won't be able to find the IP when you are out and about).

Even without adding an entry to your hosts file you should still be able to connect to your server from within your LAN (using the external domain name) but that is dependant on your router/modem - it works with mine, but I have read others will not work). But be aware that if you do it this way then your connection is actually looping out to the internet and then back into your server. This will slow down the connection...

The other alternative (ie 2b) is to set up a local DNS server (on your home network). That is not too hard and is something I have done and am willing to share the info with you if you are interested. That will give you the best of both worlds (internal connection within your LAN and external everywhere else) without having to configure it on each machine.

To try to recreate your experience (with an aim to fixing it) can you please give me a couple more details please? Namely:

• Were you using the latest version? (v13.0 currently)
• What architecture are you using? (32 or 64 bit)
• Where/how is the appliance installed? [Bare-Metal/Local Hyperviser (Proxmox, VMware vSphere or similar)/Local Desktop VM (VirtualBox, VMware Player, KVM or similar)/TKL Hub (or AWS)/another VPS/Cloud provider (please give details)]
• If installed locally - what format/build type did you use/download? (e.g. ISO, OVF, VMDK file, OVZ, etc)

Thanks! :)

Is that what you mean when you say "I edited the openphoto file as described earler in this thread"?

Bottom line is that I can't reproduce this issue. I just downloaded and installed a fresh version of this appliance. I ran the firstboot scripts (from the console), set up a domain (I just used the hosts file on my laptop) and it all just worked OOTB.

Can you walk me through the exact steps you took, one by one and maybe we can work out what is going on...