Lin Pro's picture
Lin Pro - Fri, 2015/11/06 - 22:22

Hello,

the documentation of inithooks makes mention that /etc/inithooks.conf can be populated with values that when present will cause the installator to not ask the user for input.

Can that be done for generation of an ISO build from within tkldev?

If so, where the snippet belongs?

cat>/etc/inithooks.conf<<EOF
export ROOT_PASS=supersecretrootpass
export DB_PASS=supersecretmysqlpass
export APP_EMAIL=admin@example.com
export APP_PASS=webappadminpassword
export SEC_ALERTS=admin@example.com
export SEC_UPDATES=FORCE
export HUB_APIKEY=SKIP
EOF

 

Say the appliance is a wordpress, should the above go to:

/turnkey/fab/products/wordpress/overlay/etc/inithooks.conf

OR perhaps here

/turnkey/fab/products/core/overlay/etc/inithooks.conf

In any case, what file should the above be specified in? conf.d/main of the appliance or the core appliance? or maybe elswhere?

After reading this in the documentation:


It is possible to bypass this interactive configuration process by creating 
/etc/inithooks.conf in the appliance filesystem and writing inithooks 
configuration variables into it before the first system boot.

I would like to assume that cat < /etc/inithooks.conf<<EOF ... EOF shoud go into wordpress/conf.d/main.

Do you guys have any hints for me here?

Please help

 

Lin Pro

Forum: 
Support
Tags: 
bare metal
inithooks
preseed
Jeremy Davis's picture

Jeremy Davis - Sat, 2015/11/07 - 05:08
There are a few options but before I go into details I'd like to point something out that I think you may not realise (which will indirectly answer one of your questions).

So whilst all appliances are essentially based on Core, when you build them, they do not actually use the code contained within /turnkey/fab/products/core/. The shared code actually exists somewhere else altogether; in common (locally in TKLDev it is in /turnkey/fab/common/).

Armed with that knowledge, if you intend to (re)build multiple appliances it may actually make sense to put generic pre-seeding (for any/all) appliances in common. E.g. you could put a copy of your desired inithooks.conf in common/overlays/turnkey.d/pre-seed/etc/inithooks.conf (the contents of all directories in common/overlays/turnkey.d/ are overlayed for all appliances at build time). Alternatively if you prefer to do it via conf script (rather than an overlay file) that could go in a file in common/conf/turnkey.d/ e.g. common/conf/turnkey.d/pre-seed. There is no hard and fast rule regarding whether to use an overlay or conf script.

Alternatively if you only intend to (re)build one appliance then additions to common are overkill. Instead I would either add it as /turnkey/fab/products/wordpress/overlay/etc/inithooks.conf or via wordpress/conf.d/main (or a separate script in wordpress/conf.d/). Obviously if you go the common route; any appliance specific modifications must be done via an appliance specific conf script; otherwise the appliance overlay file will overwrite the one from common...

Lin Pro's picture

Lin Pro - Sat, 2015/11/07 - 21:07

Well, Thank you for the explanation.

Are changes done to common/overlays or common/conf.d safe even if "git pull" is exercised for some reason in the "common" directory as is recommended at some point to stay current?

 

regards

Lin Pro

best regards,

Lin Pro

Jeremy Davis's picture

Jeremy Davis - Sun, 2015/11/08 - 00:39
So long as it is a separate file there should be no issue. It is not likely that we would add a preseeding file to common anyway. FWIW even if we did, any files that would be overwritten in your local common with a git pull will cause git to complain. (you'd need to use the -f switch to force overwrite).

However, the "proper" way to do it would be to create your own branch. Then you can commit your changes locally. Keep in mind though that pushing this branch back to github would be a bad idea (as then everybody would see your pre-seeds). In the future if you do tweaks or fixes in common that you want to share with us then you would do that in another (new) branch and push just that branch back to GitHub. This is how I would do it: 

cd common
git remote rename origin upstream #change TurnKey's remote name to 'upstream'
git checkout -b preseed-inithooks
<set your inithooks>
git add .
git commit -m "created common preseed file"

Then if there are changes to TurnKey common master that you want to include you would do this: 

cd common
git checkout master
git pull upstream master #assuming Turnkey's remote is 'upstream'
git checkout preseed-inithooks
git merge master
Then if in the future you want to help out by providing a fix or a tweak, make a new branch and push those changes. So something like this: 
git checkout -b tweak-branch master
<tweak common>
git add .
git commit -m "fixed something"
git push origin tweak-branch #assuming that your GH repo is set as origin
git checkout preseed-inithooks
git merge tweak-branch
Alternatively if you wanted to share changes you had already committed to your local preseed-inithooks branch then checkout a new branch and git cherry-pick <commit hash> to add individual commits to your new branch. Then you can safely push back to GH (and make a pull request to us) without revealing your inithook preseeds to the world.

If you want to be really sure that you can't accidentally push your preseeds then you could add the filename to the .gitignore file (in the branch where you create the pre-seeds).

Add new comment