Because turnkey is such an awesome Idea/System, I want to see if there is a way to take it one step further.
the Idea seems simple on the surface, but I know that it would be more than a little complex. In a nutshell, the idea is, when generating the ISO file for a particular appliance, it would also create some or all of the other containers inside the ISO with it. eg. the file turnkey-lxc-13.0-wheezy-amd64.iso would also have all the files for the supported formats
vmdk, OVF, OpenStack, OpenVZ, OpenNode, and Xen.
Hi everyone? Just want to ask why my emails from sogo mail are not being received by yahoo accounts. Undelivered message comes a few days later saying the following error:
Action: failed
Status: 4.4.1
Diagnostic-Code: X-Postfix; delivery temporarily suspended: connect to mta6.am0.yahoodns.net[98.136.216.25]:25: Connection timed out
Sometimes error will state that my IP is in the spamhaus list but whenever I checked it, it's is not there in the list.
After lots of research, I thought that Odoo ERP would be a perfect fit for my needs. However, figuring out how to install it on TKL was a real pain. So, I'm hoping to save someone else the same pain.
Disclaimer: I am NOT a Linux Guru. This might not be perfect, or even right, but I found it works for me.
With Debian 8 at RC2 and a full release coming in the next month presumbly, what's the roadmap for turnkey regarding rebasing? Are we waiting for 14.0 or will it come with 13.1?
Or another idea/question. Turnkey isn't going to have a Snappy or CoreOS version is it?
Are there any plans to port tkdev to Raspbian so certain appliances could be created for deployment on Rasberry Pi 2?
Since the latest edition of this SoC is rather powerfull for the price, I see a lot of linux services benefitting from running on Pi 2 from a cost/performance standpoint.
I've seen some past discussions on this in the blog (or the forum)...
I would like to "vote" against this deprecation. Or better, argument against it.
In summary, I've read that dev team does not really see a good reason for mantaining the 32 bit options given today's professional hardware... And they are taking lots of hosting room (lots of appliances and flavors for each of them).
Sorry for the long post... I've summarized the proposals at the end (see SUMMARY OF PROPOSALS below), but I previously explain/analyze of the issues, and propose detailed fixes (so that they are easier to implement if "accepted").
I'm opening this new thread with different (and I think better) suggestions that the one I recently made in: