Parse files in http_directory as templates

[pmenglund]

The files in http_directory is served straight up, which forces you to make modifications out of band to e.g. a kickstart file.

Adding a Handler that applies the same templating as in the config json will eliminate that.

[sethvargo]

This is interesting. I think we would only want to apply the templating if a certain file extension were used. Otherwise, a normal template that contained {{}} could present a problem. But in general 👍 on this idea.

[supersteves]

+1

Needed to allow account password to be parameterised for linux OS installs.

Suggest "http_variables": ["*.cfg"] e.g. for preseed.cfg

[willpriceb]

+1

This would be really handy, the main use case is for setting passwords, locales and keyboard layouts in preseed.cfg.

@rasa has a workaround for specifying passwords in the builder config JSON:

{
  "builders": [
    {
      "boot_command": [
        " passwd/user-fullname={{user `ssh_username`}}",
        " passwd/username={{user `ssh_username`}}",
        " passwd/user-password={{user `ssh_password`}}",
        " passwd/user-password-again={{user `ssh_password`}}",
      ], ...
      "ssh_password": "{{user `ssh_password`}}",
      "ssh_username": "{{user `ssh_username`}}",
   }, ...
}

If one were to look at adding this functionality where would they start? I see the virtualbox-iso plugin instantiates a server from which to serve the files in the http directory, I guess a step before this to template those files into a temporary build dir which is then served would work?

[rickard-von-essen]

I think this don't add any value. Credentials should be set with a provisioner.

I'm voting for closing as "won't fix". Unless someone comes up with a scenario where it's valuable.

[pmenglund]

@rickard-von-essen a provisioner can't modify the kickstart file, as the provisioners run at a later stage.

What I'm trying to avoid is hardcoding credentials used in preseed.cfg, e.g. passwd/username and passwd/user-password

[rickard-von-essen]

I think they can be hardcoded since they are just temporary and local or?

[pmenglund]

Now they have to be temporary as they are stored in cleartext, which is bad, being able to pass it in through an environment variable would make it possible to make safe.

[rickard-von-essen]

they have to be temporary as they are stored in cleartext

They can be stored in preseed.cfg encrypted with crypt(3) and you can pass it in as variable to ssh_password with the cleartext password. (This is probably not good enough security if you publish your preseed.cfg on internet and don't change your password.)

[pmenglund]

Right, I don't want any confidential (even if encrypted) information in preseed.cfg as I put it in a public github repo, and since you can brute-force crypt(3) in days now with a couple of GPUs...

[willprice]

How about those of us behind a corporate proxy, we have to duplicate preseed.cfg and then add in a new line to set the proxy, if the file was templated then one could share preseed.cfg across environments.

[rickard-von-essen]

My point is that there is nearly always another way to solve these things without preprocessing or parsing http_directory files as templates.

@willprice see https://github.com/boxcutter/ubuntu/blob/master/ubuntu.json

[tylert]

@rickard-von-essen nice alternative solution. However, it seems that the boxcutter Debian example lacks the extra "d-i passwd" preseed values that you were proposing to use here and it would seem (from some rushed tests I ran) that these variables may not be properly exposed in the current stable/testing debian-installers. Kali and other Debian variants may also suffer from this limitation.

I do think that @pmenglund 's original enhancement proposal is still a valid use case and one that I would gladly use.

[mwhooker]

Similar to #3961

This sounds like a reasonable idea, but right now we're focused on 1.0. This has very low chance of ever being a priority for us, so we'd rather close this issue than have it stagnate for years to come. The best way to get this implemented would be to submit a PR. Please see the mailing list for more details on 1.0.