Open dragetd opened 5 years ago
@dragetd, yeah I also thought that reference to google was out-of-scope as well. Do you know of any other obvious things like that which are out-of-scope? In this particular situation, do you think it makes sense to empty out the default search engines without offending anybody? Heh. ;)
Do you have any other reasons why you're interested in having the Autounattend.xml files completely templatized? Like are you just interested in changing the default users/passwords, or is there something else?
In my own fork, I de-vagrantify the Autounattend.xml
files by changing the default usernames/passwords w/ an .xslt, and then used something pretty similar in order to inject a product key so I could avoid figuring out how to properly re-arm the license on the target platform..
However, one thing which i'm very hesitant to do is to remove those Autounattend.xml
files, or require users to go through a stage of building in order to use one. Right now the templates can be used out-of-the-box, and a user only needs Packer
to build them (and nothing else) which I think is a very important capability.
Also, prior to basing my tools on this project, I had previously toyed around with auto-generating those Autounattend.xml
files. But I couldn't (for the life of me) figure out a good way to make it maintainable without a lot of painful testing because there's so many little differences in the schema between the different windows versions.
In terms of what was mentioned in issue #49, I've never really been a fan of the bin/tweak-json.py
script that is bundled in this repo. In my own fork, I use jq
to heavily modify the templates. Mostly because it's just infinitely more awesome for interacting with .json. As you referenced #49, are you interested in auto-generating these as well? What would you desire to change in that case?
As this has been requested a couple of times, I'm just trying to get an idea of how far this would need to go if it does eventually get worked on. Especially because I might already have some work that does some of these things that I could consider integrating if the community desires it.
I am sifting through old issues and things I might have forgotten… and I seem to have forgotten about almost all issues and PRs in your project. I am really sorry!
Personally, I consider it good practice that files which can be auto-generated should not be part of a git repository. So if we use Makefiles (eh, Makefiles are no fun!) then we could include building the templates as part of the build process. Yes, this would add some dependencies other than packer. But personally I would prefer this to handling all the XMLs in the repository.
Some time long ago I had started thinking about what the actual goal of such a project could be (https://github.com/dragetd/packerwin/issues/1). IMHO the default images should be as close to a straight Windows installation as possible, including all drawbacks and issues. Only by configuration / optional flag, it would have more sane default configurations (chocolatey, cloud-scripts etc.).
The way things work in repository here is already very configurable. Maybe you can tell me a bit about the goals you have in mind (ignoring the implementation for now) or we can chat (Matrix: @draget:matrix.org / Telegram: @draget) if you want to. :)
The Autounattend.xml files contain various bits and pieces that are repeated all over again.
Also things that I would not really expect to be part of this repository: https://github.com/boxcutter/windows/blob/ee2222e4cfe15dcbca7c5cec25d13c760492271a/floppy/win81x64-pro/Autounattend.xml#L82
Maybe we could get rid of most files with a simple template and just the adjustments needed for each version.
Just opened this issue to hold this thougth. :)
Related to #49