Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto-generate or use templates for Autounattend.xml files? #175

Open
dragetd opened this issue Feb 27, 2019 · 2 comments
Open

Auto-generate or use templates for Autounattend.xml files? #175

dragetd opened this issue Feb 27, 2019 · 2 comments
Labels
enhancement This will introduce or improve an already existing capability help wanted question

Comments

@dragetd
Copy link

dragetd commented Feb 27, 2019

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:

<ScopeUrl>http://www.google.com/search?q={searchTerms}</ScopeUrl>

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

@arizvisa arizvisa mentioned this issue Jan 10, 2020
Closed
@arizvisa arizvisa added enhancement This will introduce or improve an already existing capability help wanted labels Jan 10, 2020
@arizvisa
Copy link
Contributor

arizvisa commented Jan 10, 2020

@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.

@dragetd
Copy link
Author

dragetd commented Apr 19, 2020

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 (dragetd/packerwin#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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This will introduce or improve an already existing capability help wanted question
Projects
None yet
Development

No branches or pull requests

2 participants