> That way, the first screen can be a input screen for a user id / password to > identify the potential user. Then the next screen offers you what type of > setup you want - that's basically where you would then go ahead and determine > most of the setup parameters. If needed, it might then ask you some more > questions and so on. > > Of course that would require anaconda to have support to take a server > location on the boot line and load screen definitions from a remote server - > something I don't think it can do right now... > or, fairly simply: You setup a web app that takes the info on what the user wants on the box and stores it in a db. Then it returns a url encoded to retrieve a ks.cfg from a cgi based on the info in the db. Then for the ks you specify the location of the ks.cfg as the aforementioned url. That's it. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
