ovf (Forum tag)https://www.turnkeylinux.org/forum/term/355/0/feed
en(concept Idea only) ISO file with other templates insidehttps://www.turnkeylinux.org/forum/general/20150421/concept-idea-only-iso-file-other-templates-inside
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>Because turnkey is such an awesome Idea/System, I want to see if there is a way to take it one step further. <br />
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<br />
vmdk, OVF, OpenStack, OpenVZ, OpenNode, and Xen.</p>
<p>now I know this sounds like a uber bloat idea, but hold on. here is the actual idea.<br />
because its happening at the time of generating the ISO we might be able to deduplicate the data.<br />
Please read the info that I gleaned from different sites (sorry no sources linked) that give additional information and concepts to explain it better.</p>
<p>*******************************************************<br />
Data deduplication (often called "intelligent compression" or "single-instance storage")<br />
is a method of reducing storage needs by eliminating redundant data. Only one unique instance<br />
of the data is actually retained on storage media, such as disk or tape. Redundant data is<br />
replaced with a pointer to the unique data copy. For example, a typical email system might<br />
contain 100 instances of the same one megabyte (MB) file attachment.</p>
<p>*******************************************************<br />
The optimize parameter in the CDImage can possibly compress the contents of the generated ISO file by recording the duplicate files one time only, this greatly reduce size the X-in-1 CDs and enables 4 GB of data to fit in one CD.</p>
<p>This functionality is not built-in in the MKISOFS (it doesn't analyze the files to check which files are the duplicate one) but it can accept the hardlinks that point to the files to be included in the ISO file as pointers to the actual files (with the parameters '-follow-links -cache-inodes').<br />
That means that a file and its hardlink will be encoded once in the ISO file (thus giving the same effect as the -o parameter in CDImage).</p>
<p>*******************************************************</p>
<p>so the question is..... because each container basically has all the same files, can we find a way to create them in a way that the container files are filled with hardlinks to the files in the ISO, so that when extracted it is a fully populated container? </p>
<p><br />
the benifits to this are two fold, <br />
1. this could reduce the bandwidth requirements by turnkey. (always good)<br />
2. this would be a universal image that can be deployed on Any of the environments. <br />
3. because its an all scripted build, this would lower human involvement in the process, and gaining a more consistent build.</p>
<p> </p>
<p>now that I've explaind my thought, I want to know if you think its possible.<br />
what information do we need?<br />
what roadblocks are there? etc.</p>
<p>thanks for your time reading this. I look forward to your comments.<br />
Peter.</p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/openvz">openvz</a></div><div class="field-item odd"><a href="/forum/tags/ovf">ovf</a></div><div class="field-item even"><a href="/forum/tags/xen">xen</a></div><div class="field-item odd"><a href="/forum/tags/openstack">openstack</a></div><div class="field-item even"><a href="/forum/tags/iso">iso</a></div><div class="field-item odd"><a href="/forum/tags/vmdk">vmdk</a></div><div class="field-item even"><a href="/forum/tags/opennode">opennode</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/general">General</a></div></div></div>Tue, 21 Apr 2015 19:19:15 +0000Peter C. (Benchwork)17496 at https://www.turnkeylinux.orgOVF import broken on Virtualbox 64bit. Fix and other suggestions for easier TKLX on Virtualbox.https://www.turnkeylinux.org/forum/general/20150208/ovf-import-broken-virtualbox-64bit-fix-and-other-suggestions-easier-tklx-virt
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>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").</p>
<p>I'm opening this new thread with different (and I think better) suggestions that the one I recently made in:</p>
<p><a href="http://www.turnkeylinux.org/forum/general/20150203/why-not-vbox-default-zip-build-appliance-addition-vmx" rel="nofollow">http://www.turnkeylinux.org/forum/general/20150203/why-not-vbox-default-...</a></p>
<p>There is a rationale there on the need of making the Virtualbox use case for novice users more "turnkey" (than it is now, apparently).</p>
<p> </p>
<p><strong>SUMMARY OF CURRENT ALTERNATIVES FOR TKLX ON VBOX:</strong></p>
<p>Current alternatives for running TKLX if one has VBOX installed:</p>
<p><strong>Alt. 0, ISO</strong>: Download the .ISO. Manually create a new VM following a tutorial, attach to it the .ISO, launch and install from .ISO (installing is an "extra step").</p>
<p><strong>Alt. 1, default ZIP</strong>: Download the default ZIP (containing .vmdk and .vmx) . Manually create a new VM following a tutorial, and attach to it the .vmdk extracted from the ZIP. This looks like the currently "recommended" for VBOX. Not "evident", and documentation al little bit outdated.</p>
<p><strong>Alt. 2, OVF:</strong> Download the "OVF" ZIP ("OVF" link). VBOX assotiates with .ovf, so this is straighforward: extract the ZIP and double click on the .OVF. VBOX opens a confirmation window with an "Import" button. This Window shows the characteristics of the VM that is going to be imported (name, OS type, RAM, etc), permitting adjusting if desired, prior to import. Import is in fact creating the VM folder and making a "clone" of the .vmdk (with a new and unique UUID, correctly reflected on the .vbox file that it creates). </p>
<p>This Alt. 2 is currently IMO by far the simpler for the user (specially a novice, but also handy for everyone): it does not require to create a VM and configure it (need to ensure that PAE/NX enabled, change network settings to bridge, decide a RAM size, decide/know OS type and 32/64bit, decide a name for the VM...). Alt. 2 is simply more "turnkey".</p>
<p>... But alt.2 has currently an issue on 64 bit TKLX (current default architecture).</p>
<p> </p>
<p><strong>CURRENT ISSUES WITH 64bit OVF IMPORT IN VBOX AND </strong><strong>"MANUAL" WORKAROUNDS</strong></p>
<div>My tests for alt. 2 of .ovf import have given the following results (tested with last VBOX branch, 4.3.x, on Mac OS X 64bit host, Win7 64bit host, and XP 32bit host):</div>
<p>- It works fine with the "to be deprecated" TKLX 32bit. Unzip, double click and go... Great!</p>
<p>- It is "broken" for "currently pushed option" TKLX 64bit (of course, this issue only applies on 64bit hosts). It imports apparently "fine", but when starting the imported machine, after Grub, it gets hanged on "Loading initial ramdisk" (without further error).</p>
<p>First solution/Workaround for 64bit: when importing from the OVF, the VM is "detected" as "Other/Unknown" (being in fact implicit that it is 32 bit). If one just changes the dropdown menu to "Other/Unkown (64-bit)" before importing (or after importing, in the VM configuration), things work fine.</p>
<p class="rteindent1"><strong>Note:</strong></p>
<p class="rteindent1">For sure, the imported VM's also works if setting the OS Type to "Linux/Debian (64-bit)". However, this is not strictly needed (both for 32 and 64 bit): no need to specify that it is a Debian, nor even Linux. Current VBOX "only" seems needing "a hint on 64bit" (whatever it is).</p>
<p>An additional "minor" issue when importing (both in 32bit and 64bit) is that the proposed name on the Wirzard for the VM is "vm" instead of a more descriptive one (like e.g. TURNKEY LAMP seen on the .ovf file)... So the user clicking "next, next" will create a VM named "vm" in the VBOX interface. Moreover, a futur import of a different TKLX appliance will "clash" by default (same name), confusing a novice user.</p>
<p>This 2 issues (change OS type when importing 64bit TKLX that is currently pushed, and change name to a more significative one) can be easily documented. This gives globally by far a more easy procedure that following current suggestions of "starting a new VBOX VM" (alt 0 and alt 1) seen on tutorial <a href="http://www.turnkeylinux.org/docs/installation-appliances-virtualbox" rel="nofollow">http://www.turnkeylinux.org/docs/installation-appliances-virtualbox</a>.</p>
<p>But it is still not as "turnkey" as it should (as it easily could).</p>
<p> </p>
<p><strong>FIXES FOR THE OVF ISSUES</strong></p>
<p>I've been looking on fixes on this: fixing the OVF file, so that it proposes the correct stuff in the Import Wizard, so that the user only has to click "Import" (not typing, not configuring... turnkey, in a word).</p>
<p>These are my findings.</p>
<p>Here is the relevant extract from the <strong>current</strong> .OVF file generated for Turnkey Lamp (as an example of appliance):</p>
<pre>
[...]
​&lt;VirtualSystem ovf:id="<strong>vm</strong>"&gt;
&lt;Info&gt;A virtual machine&lt;/Info&gt;
&lt;Name&gt;<strong>TURNKEY LAMP</strong>&lt;/Name&gt;
&lt;OperatingSystemSection ovf:id="<strong>1</strong>" vmw:osType="otherGuest"&gt;
[...]
</pre>
<p>Instead of:</p>
<pre class="rteindent1">
ovf:id="<strong>vm</strong>"</pre>
<p>it should better say something more explicit... For example, the same contents of the "Name" element below it. In this example, it could be:</p>
<pre class="rteindent1">
ovf:id="<strong>TURNKEY LAMP</strong>"</pre>
<p>so that a better name is detected and proposed by the Wizard.</p>
<p>And for 64 bit TKLX (currently default and pushed arch), instead of:</p>
<pre class="rteindent1">
ovf:id="1"</pre>
<p>it should say (for example):</p>
<pre class="rteindent1">
ovf:id="102"</pre>
<p>so that a correct (64 bit) OSType is detected and proposed.</p>
<p class="rteindent1"><strong>Note:</strong></p>
<p class="rteindent1">This number comes is from the (obscure) "OVF" standard specification:</p>
<p class="rteindent2"><a href="http://schemas.dmtf.org/wbem/cim-html/2/CIM_OperatingSystem.html" rel="nofollow">http://schemas.dmtf.org/wbem/cim-html/2/CIM_OperatingSystem.html</a></p>
<p class="rteindent1">Searching "OSType", one sees that the value is an integer, currently between 0 and 116, and it shows there the corresponding "readable values". For "1" it is effectively "Other", and for "102" it is "Other 64-Bit".</p>
<p class="rteindent1">BTW, "Debian" is 95, and "Debian 64-Bit" is 96. These could be a "better fit" for current 32bit and 64 bit TKLX, but are not strictly needed for what I see.</p>
<p>So the configuration could be for 64 bit something like (for 32 bit, the "102" should stay as "1"):</p>
<pre>
[...]
​&lt;VirtualSystem ovf:id="<strong>TURNKEY LAMP</strong>"&gt;
&lt;Info&gt;A virtual machine&lt;/Info&gt;
&lt;Name&gt;<strong>TURNKEY LAMP</strong>&lt;/Name&gt;
&lt;OperatingSystemSection ovf:id="<strong>102</strong>" vmw:osType="otherGuest"&gt;
[...]
</pre>
<p class="rteindent1"><strong>Note:</strong></p>
<p class="rteindent1">I suppose that this part besides the 102:</p>
<pre class="rteindent2">
vmw:osType="otherGuest"</pre>
<p class="rteindent1">is a "directive" for VMWare products.</p>
<p>With these changes, I've tested that the VBOX import on 64bit proposes the good stuff, then when pressing "Import" and then launching the VM, everything goes fine without needing any adjust. And is makes easy the import of other TKLX appliances (since no generic name "vm" is used).</p>
<p>For fixing this on dev-side:</p>
<p>I see now in the TKLX documentation that the OVF ZIP is created "with VMWare's <a href="http://communities.vmware.com/community/vmtn/vsphere/automationtools/ovf" rel="nofollow">OVFtool</a>.".</p>
<p>So I guess that it should be possible to fine tune this when generating the OVF... Sorry, but reading the OVFTool user guide, I don't see clearly how (maybe it is straighforward for the dev team). In this User guide, I see mentioned the "VM ID" stuff: "If you are creating a VM, you need to specify the id in the descriptor file.", but I don't unserstand how this is done (I don't see a command line option for specifying it, and I currently don't understand from where does it take it). They do not either provide hints on how the "OSType" is specified. But they mention this, so this is for sure "doable" in a straighforward way that I don't see now.</p>
<p>Surely, the best option is to find out it: so that the OVFtool just sets in source these values with a more correct value and then produces a more "correct" ovf output.</p>
<p>If the previous is not feasible/easy, a workaround could be to do an easy post-process (e.g. a simple sed command) of the output .ovf file, in order to adjust this stuff (also requires updating the sha1 in the .mf file)... Less elegant and more "risky"...</p>
<p>Only possible "problem" that I can foresee on "fixing" the .OVF for VBOX compatibility is if it may break other usages/users of the "OVF flavor". If I understand well, these usages are mainly the VMWare products (home and specially professional), but they should be compliant with OVF that follow the standard (and specially if generated by their own OVFTool). It should be possible to do this in a compatible way for "everyone".</p>
<p> </p>
<p><strong>SOME DOCUMENTATION ISSUES AND PROPOSED FIXES</strong></p>
<p>I've found some documentation issues for the "straightforward case", using the "lens" of a completely novice user (that may just know Virtualbox, or may not even know anything on virtualization, but lands to Turnkey Linux).</p>
<p>- The turnkey home page only clearly suggests "Try the live demo!". One could see it as the lighter and simpler way to try TKLX... But with the live demo, the user does not really see the VM itself, nor can "deploy one", nor can he configure and use it (as far as I've seen, sorry if I'm wrong). The demo is oriented to show how multiple VM's management and monitoring looks like in the Hub, but not for testing and playing with a particular VM and "seeing" what Turnkey linux is really like... If the user wants to "play" further and see a particular Turnkey machine that is not "fake", he has to contract Amazon cloud for going further (account and billing info needed, even if "in principle" it is 0 cost at the beginning). This is a giant step for casual users that just want to try TKLX. It will put away a lot of potential users (young students for sure, but also a lot of grown-up, and specially if they come from an FOSS tradition, where only the locally executed FOSS software can be trusted).</p>
<p>I really miss a link in the home page after the "Try the live demo!" link...</p>
<p>Something like: "Or try it on your computer in a few simple steps". This link will provide a guide for the current simpler, more universal, more "minimal assumptions", aka "more turnkey" way of testing it: install Virtualbox and download the OVF link of a given appliance.</p>
<p>A third sentence could be "Or use your current virtualization product" (being a link to the doc/builds page).</p>
<p> </p>
<p>- In the downloaded default .ZIP and the OVF .ZIP, the <strong>included README</strong> is only a link to:</p>
<p><a href="http://www.turnkeylinux.org/docs/virtualization" rel="nofollow">http://www.turnkeylinux.org/docs/virtualization</a></p>
<p>This document, recommends the "default VM build" for Virtualbox users. It summarizes that the OVF build is "recommended for users of high-end VMWare products (ESX, vSphere)", while it is also useful for Virtualbox...</p>
<p>This should be fixed on "docs/virtualization" document: describe the OVF also as good for VBOX, and even recommending it for novices (even with the current 64bit import issue that I've described before).</p>
<div>Or maybe the README should directly point to "docs/builds" (currently more accurate, see below) instead of "docs/virtualization".</div>
<p>Or maybe "docs/virtualization" should just be merged/redirected to "docs/builds".</p>
<p> </p>
<p>- On the Website, when going to a particular appliance page (from the turnkey home page, or landing from Google), the help for choosing a flavor is quite "hidden" IMO...</p>
<p>A little "?" after "Xen" (seems like a help only for the Xen option).</p>
<p>I think that the "?" link should be after the word "BUILDS", to indicate that it helps to decide what build one should download/use.</p>
<p>I would even change the "?" with the explicit word "help".</p>
<p>Or better, I would give in the same page of each appliance a little orientation for novice users (so they don't need to go through a further "?" link and they don't need to have read something that is in another place). A short, complet, explicit and straighforward guidance, like "For novice users: install Virtualbox and download from the OVF link".</p>
<p>- The "?" link goes to:</p>
<p><a href="http://www.turnkeylinux.org/docs/builds" rel="nofollow">http://www.turnkeylinux.org/docs/builds</a></p>
<p>This one is much more accurate than the "docs/virtualization": in the second paragraph, it corrently points to novice users to download and use Virtualbox.</p>
<p>But then, the (novice) user has to read quite all the document to find the places where Virtualbox is mentionned, with some quite technical jargon (very related to Virtualbox and virtualization).</p>
<p>The document shows the three options, but really does not give a recommendation, and it is difficult for a novice to decide.</p>
<p>The document explains correctly that importing the OVF is a "step further" (cloning the vmdk), so may take longer and take more space (but being 250MB VM's, I think that the simplicity of the procedure currently really pays off). This may discourage using it...</p>
<p>It encourages in fact the other approach, since it gives a link for further info (the tutorial for VBOX on docs/installation-appliances-virtualbox).</p>
<p>I think that this document should better suggest the OVF approach, and also right at the beginning of the document (where it mentions VBOX as the easy way for novice users).</p>
<p>- The tutorial for Virtualbox:</p>
<p><a href="http://www.turnkeylinux.org/docs/installation-appliances-virtualbox" rel="nofollow">http://www.turnkeylinux.org/docs/installation-appliances-virtualbox</a></p>
<p>At least the document "recognizes" that it is dated (I understand that there is no time to constantly fixing/updating it).</p>
<p>It is a pity that a newcomer currently tends to see this as the "suggested easiest way". It should at least include a mention to the "other possibility" of importing the OVF. And even recommend it.</p>
<p>While my previously proposed fix for the OVF generated file is implemented by a developper (or in case it is never implemented), I would just quickly document here the workaround: when importing, the user should choose as "OS Type" "Other/Unknown (64-Bit)" (if using the 64 bit OVF, that is currently the default architecture). And in the workaround, I would also recommend the user to change the VM name from "vm" to something more explicit (and to avoid future import clashes).</p>
<p> </p>
<p><strong>MAYBE MERGE "DEFAULT .ZIP" AND "OVF .ZIP"</strong></p>
<p>I assume that the .vmdk on these two downloads are in fact really the same, or at least perfecly compatible... And they are the bigger part of the ZIP... Quite redundant!</p>
<p>Doesn't it make sense to put both contents on the same .ZIP?</p>
<p>E.g. just adding the "little" .vmx to the current OVF zip contents. A single ZIP download (storage savings for Turnkey developpers, less confusion for the user).</p>
<p>The user just extracts. Then he double clicks on the .vmx if he has VMWare Player, or double clicks on the .ovf if he has Virtualbox. Or he can also import the .ovf with any VMWare product, since they support the OVF format (according to VWWare knowledge base).</p>
<p>I'm sorry that I don't have now at least a VMWare Player at hand to test that this works fine... But I think it should work...</p>
<p> </p>
<p><strong>MAYBE PROVIDE .OVA FORMAT DOWNLOAD (EVEN SUBSTITUTE THE ZIP ONES)</strong></p>
<p>In fact, .OVA may be a better alternative that providing current .OVF zip file.</p>
<p>.OVA is just a tar of the .ovf, the .vmdk and the .mf.</p>
<p>Also standarized like OVF, and it is precisely designed for VM's distribution/download.</p>
<p>It is supported by VBOX, and in facts avoids the extra step of unzipping, then importing: it directly imports from "inside" the OVA (less time, space and garbage than unzipping).</p>
<p>I see that the OVFTool generator also supports generating this format.</p>
<p>And this format is in principle also fully supported by VMWare products (<a href="http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;cmd=displayKC&amp;externalId=2053864" rel="nofollow">http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;cmd...</a>).</p>
<p>And surely there it also avoids there the extra step of unzipping.</p>
<p>I think that currently using zip for ovf distribution instead of this "tar" (.ova) makes little sense: the current .zip is not compressing further the .vmdk, and the TKLX .zip or .ova size is quite small (250MB... no need to split multi-giga file downloads).</p>
<p>Maybe I'm missing something, but in fact I would even merge current "default .ZIP" and "OVF .ZIP" in a single .OVA (tar of the contents of the current OVF zip, or directly generated by OVFTool). And forget the ".vmx" option.</p>
<p>Less storage, less (unneeded) choices.</p>
<p>If only an OVA is provided (instead of currently 2 separated zip), the only "minor issue" seems for "VMWare Player/Worksation" (desktop products): user needs to import the OVA instead of unzipping and then using directly the .vmx/.vmdk of the current "default ZIP"... But in fact, importing from the .OVA is quite equivalent to unzipping, in terms of time/space/garbage. And the usability of importing should be quite similar (if not better: maybe VMWare products also assotiate to .OVA in desktops, like VBOX does).</p>
<p>With the .OVA, the recommended approach for novices gets even more streamlined, quick and clean: install Virtualbox, download and open (double-click) the OVA file, then press the "Import" button.</p>
<p>No unzip step needed, no stuff left behind (except the downloaded .OVA, the same as the downloaded ZIP was).</p>
<p> </p>
<p><strong>SUMMARY OF PROPOSALS </strong></p>
<ol><li>Fix somehow the .OVF generation so that it works for 64bit on VBOX (OSType) and provides a more relevant name (instead of current "vm"). See before for technical details.</li>
<li>If this fix is not possible/recommended, or in any case while it gets "fixed": documment briefly the workaround (in docs/builds, and/or in docs/installation-appliances-virtualbox): "fix" these values when importing. See before for details.</li>
<li>For novices, on TKLX website, recommend this Virtualbox with OVF method: at the start of docs/builds and even at the home page.</li>
<li>On every appliance page on the website, put the "?" help link after "BUILDS" word. Maybe also do an explicit recommendation for novices there. Or at least a "Advice for novice users" link, linking to the relevant paragraph in a central document.</li>
<li>(Maybe) Merge the two ZIP currently made (default and OVF) into a single one. Or maybe even better substitute them by a single OVA.</li>
</ol><p>I understand that the TKLX core team has to prioritize the suggestions between multiple different issues to be fixed (both in code and documentation). But I think that I describe here are issues worth fixing them.</p>
<p>This is because they are addressing the use case of the less savvy user that lands to TKLX.</p>
<p>This user is special, since it can be more easily frightened or overwhelmed if things are not really "turnkey" for him... If the first thing he finds is a choice of downloads (besides the choice of appliances), but not a simple (and correct) hint on what is the simpler initial option he has... He may (silently) run away (maybe looking for alternative options, maybe in the Bitnami style). How many times may have this (silently) happenned?</p>
<p>I think that "ideollogically" it is good to defend this user, the weakest... In fact, I know that Turnkey core team completely agrees on this (this is in fact the main original point of the TKLX project).</p>
<p>But besides this, I think that it is wise to do it this way, since it may help to increase the adoption of Turnkey Linux (being easy for everyone is its main "selling point"). Increase the adoption both for novices, and not-so novice users. For example I do not consider me so "novice", but I really appreciate when things that can be made easy, are made easy (kudos to the TKLX project for this). I know that there are other users to atract (not Virtualbox ones), but these suggestions should not be at all imcopatible (with some "regression testing").</p>
<p>In any caso, I'm not talking about marketing, just talking about making it simpler (since it can be made, in this case, with very minor difficulty)...</p>
<p>Again, I'm sorry if there is something obvious that I'm missing.</p>
<p>PS: I see that the TKLX documentation Wiki is not open, so I cannot try to help and improve it myself concerning the issues that I see and describe here... Besides, even if it was open, I surely wouldn't dare without prior consent/agreement.</p>
<p> </p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/virtualbox">virtualbox</a></div><div class="field-item odd"><a href="/forum/tags/ovf">ovf</a></div><div class="field-item even"><a href="/forum/tags/documentation">documentation</a></div><div class="field-item odd"><a href="/forum/tags/general">general</a></div><div class="field-item even"><a href="/forum/tags/ova">ova</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/general">General</a></div></div></div>Sun, 08 Feb 2015 01:48:39 +0000Dani M.17023 at https://www.turnkeylinux.org Redmine - switch to SMTP for email with google business accounthttps://www.turnkeylinux.org/forum/support/20140826/redmine-switch-smtp-email-google-bussiness-account
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>I installed the Turnkey Redmine Streamable VMDK image with OVF, to my ESXi host, updated it and everything works just as i expected, however i would like to use this post to ask for support in changing: Postfix MTA (bound to localhost) to allow sending of email (e.g., password recovery) to using SMTP with a Google business email account i have so that mails send by this machine don't end up in the SPAM folder.</p>
<p>In this section i show what i did so far:</p>
<p>1. made a backup of file /var/www/redmine/config/configuration.yml that has following contents:</p>
<p>production:<br />
email_delivery:<br />
delivery_method: :sendmail<br />
smtp_settings:<br />
address: 127.0.0.1<br />
port: 25</p>
<p>and with this configuration emails are send OK but end up as spam on google</p>
<p>2. i then read up on and chose to use this piece of code:</p>
<p># ==== SMTP server at using TLS (GMail)<br />
#<br />
# This might require some additional configuration. See the guides at:<br />
# <a href="http://www.redmine.org/projects/redmine/wiki/EmailConfiguration" rel="nofollow">http://www.redmine.org/projects/redmine/wiki/EmailConfiguration</a><br />
#<br />
# production:<br />
# email_delivery:<br />
# delivery_method: :smtp<br />
# smtp_settings:<br />
# enable_starttls_auto: true<br />
# address: "smtp.gmail.com"<br />
# port: 587<br />
# domain: "smtp.gmail.com" # 'your.domain.com' for GoogleApps<br />
# authentication: :plain<br />
# user_name: "<a href="mailto:your_email@gmail.com" rel="nofollow">your_email@gmail.com</a>"<br />
# password: "your_password"</p>
<p><br />
from the configuration.yml.example</p>
<p>3 that i edited in to the configuration.yml as:</p>
<p>production:<br />
email_delivery:<br />
delivery_method: :smtp<br />
smtp_settings:<br />
enable_starttls_auto: true<br />
address: "smtp.googlemail.com"<br />
port: 465<br />
domain: "********.com"<br />
authentication: :plain<br />
user_name: "********@********.com"<br />
password: "********"</p>
<p>where ******** is personal information, and all configuration options mirror my Thunderbird configuration that works.</p>
<p>However this configuration doesn't do any email sending on Turnkey Redmine Streamable VMDK image with OVF that i have and i don't know what to do next. Here is where i need your help if possible. Thanks</p>
<p>PS: what i think i need to do is install a SMTP client, but not sure how and if it's compatible with what i have so far.</p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/redmine">redmine</a></div><div class="field-item odd"><a href="/forum/tags/turnkey">turnkey</a></div><div class="field-item even"><a href="/forum/tags/ovf">ovf</a></div><div class="field-item odd"><a href="/forum/tags/smtp">smtp</a></div><div class="field-item even"><a href="/forum/tags/business">business</a></div><div class="field-item odd"><a href="/forum/tags/google">google</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/support">Support</a></div></div></div>Tue, 26 Aug 2014 06:55:05 +0000Wien16040 at https://www.turnkeylinux.orgOVF ID:95 Not Supported on ESXi 5https://www.turnkeylinux.org/forum/support/20120912/ovf-id95-not-supported-esxi-5
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>I've just downloaded the LAMP OVF to play with it. When I try to deploy it through vSphere, I get an error message stating:</p>
<blockquote>
<p>The specified operating system identifier " (id: 95) is not supported on the selected host. It will be mapped to the following OS identifier: 'Other Linux (32-bit)'.</p>
</blockquote>
<p>I've tried setting up a blank VM, exporting an OVF to compare the two files. From what I can tell, the two OS identifier fields are identical.</p>
<p>Any thoughts? Everything seems to be working as epected: Should I not proceed until this is resolved? The OVF imports as VM Version 7, where most of my VMs that ESXi 5 creates are VM Version 8: Is that a problem?</p>
<p>Thanks!</p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/ovf">ovf</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/support">Support</a></div></div></div>Wed, 12 Sep 2012 17:01:17 +0000ElliotFriend4163 at https://www.turnkeylinux.orgpossible turnkey-core ovf assembly integrity problemhttps://www.turnkeylinux.org/forum/support/20111002/possible-turnkey-core-ovf-assembly-integrity-problem
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>
I have downloaded turnkey-core-11.2-lucid-x86-ovf.zip several times from<font class="Apple-style-span" color="#0077aa" size="2"><span class="Apple-style-span"> </span></font><a href="http://sourceforge.net/projects/turnkeylinux/files/turnkey-core/11.2-lucid-x86/" rel="nofollow">http://sourceforge.net/projects/turnkeylinux/files/turnkey-core/11.2-lucid-x86/</a> to make sure the file has not been corrupted on download.</p>
<p>
The zip file checks ok for integrity with the Ubuntu archive manager.</p>
<p>
When I try to import the Vm into VirtualBox 4.1.2 I get the following error:</p>
<p class="rteindent1">
Failed to import appliance &lt;...&gt;/turnkey-core11.2-lucid-x86.0vf</p>
<p class="rteindent1">
Could not create the clone medium '&lt;...&gt;/turnkey-core11.2-lucid-x86-disk1.vmdk'</p>
<p class="rteindent1">
Result Code: VBOX_E_FILE_ERROR (0x 80BB0004)</p>
<p class="rteindent1">
Component: Appliance</p>
<p class="rteindent1">
Interface IAppliance {&lt;some sort of hash key&gt;}</p>
<p>
I am running Ubuntu Lucid as a workstation and have about 400GB free on the host volume.</p>
<p>
<strong>Q</strong>: If the zip archive has no integrity problems, is there a possible problem with the original turnkey assembly that was zipped up?</p>
<p>
P.S. I checked the file signature with gpg and <a href="http://releases.turnkeylinux.org/turnkey-core/11.2-lucid-x86/turnkey-core-11.2-lucid-x86-ovf.zip.sig" rel="nofollow">http://releases.turnkeylinux.org/turnkey-core/11.2-lucid-x86/turnkey-core-11.2-lucid-x86-ovf.zip.sig</a> and it was fine...</p>
<p>
Cheers,</p>
<p>
--Peter G</p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/core">core</a></div><div class="field-item odd"><a href="/forum/tags/ovf">ovf</a></div><div class="field-item even"><a href="/forum/tags/integrity">integrity</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/support">Support</a></div></div></div>Sun, 02 Oct 2011 13:12:16 +0000Peter Goodall2686 at https://www.turnkeylinux.orgTurnkey Core hangs on boot - Virtualboxhttps://www.turnkeylinux.org/forum/support/20110211/turnkey-core-hangs-boot-virtualbox
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>
Hello everyone,</p>
<p>
Very nice community here. I really like the Turnkey concept and just discovered it in the last few days.</p>
<p>
</p>
<p>
I've tried downloading, both the zip and ISO of the OVF from multiple download location in case it was a corrupt download, but basically my VM hangs on boot.</p>
<p>
<br />
I've tried to change a number of settings such as PAE, Acceleration, chipset, just to see if it helps but to no avail. My host is running Windows 7 Home premium. and i'm using VirtualBox.</p>
<p>
</p>
<p>
Below is a screenshot. Any ideas?</p>
<p>
</p>
<p>
<a href="http://screencast.com/t/678dBmel" rel="nofollow">http://screencast.com/t/678dBmel</a></p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/core">core</a></div><div class="field-item odd"><a href="/forum/tags/virtualbox">virtualbox</a></div><div class="field-item even"><a href="/forum/tags/ovf">ovf</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/support">Support</a></div></div></div>Fri, 11 Feb 2011 10:08:42 +0000Khuram Malik2034 at https://www.turnkeylinux.orgESXi 4 will not deploy OVF Templatehttps://www.turnkeylinux.org/forum/support/20100722/esxi-4-will-not-deploy-ovf-template
<div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even"><p>
ESXi 4 server on an x86 machine.</p>
<p>
Downloaded turnkey-zimbra-2009.10-2-hardy-x86. From vSphere Client selected to "Deploy OVF Template" and navigated to turnkey-zimbra-2009.10-2-hardy-x86.ovf file using the deploy from file option. This error comes up immediately:</p>
<p class="rteindent1">
Line 9: Unsupported value "Http://<a href="http://www.vmware.com/interfaces/specifications/vmdk.html#sparse" rel="nofollow">www.vmware.com/interfaces/specifications/vmdk.html#sparse</a> 'for attribute 'format'' on element "Disk".</p>
<p>
Am I using correct file or is there another way to deploy the appliance on ESXi server?</p></div></div></div><div class="field field-name-taxonomy-vocabulary-9 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Tags:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/tags/esxi">esxi</a></div><div class="field-item odd"><a href="/forum/tags/bug">bug</a></div><div class="field-item even"><a href="/forum/tags/ovf">ovf</a></div><div class="field-item odd"><a href="/forum/tags/virtualization">virtualization</a></div><div class="field-item even"><a href="/forum/tags/vmware">vmware</a></div><div class="field-item odd"><a href="/forum/tags/vm-image">vm image</a></div><div class="field-item even"><a href="/forum/tags/vm-import">vm import</a></div></div></div><div class="field field-name-taxonomy-forums field-type-taxonomy-term-reference field-label-above"><div class="field-label">Forum:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/forum/support">Support</a></div></div></div>Wed, 21 Jul 2010 23:43:43 +0000Gordon1425 at https://www.turnkeylinux.org