Michael, I'd recommend in the beginning presenting a 50,000 foot overview, end to end, covering the build/cobbler server, and (presumably) bare metal installation to final login-screen(s). Present the big picture in layman's terms of what all is going to be accomplished with a generalization of the pros and cons. Then drop to the 10,000 foot level, provide some additional technical in-depth details that bridge the gap for those who are brand spanking new to provisioning Linux over the network in bulk and those to whom it is old hat. Then wade into all the material as you know it.
I agree with Ole Esroy's suggestion of validation. I'd add that it would be a really good topic to define what your starting point is (virgin HW, "everything" install or explicitly define what is and is not installed) as this gives your audience a credible, known and repeatable starting point. Present the steps of installation with rationale for the choices made along the way. I'm still quite new to cobbler, having pretty much 'gotten' how to PXE kickstart systems. I've not done cobbler yet and haven't understood the 50,000' view yet. I see comments about turning off DHCP, but still don't know why and I'm sure I'll learn as I wade into it. But, my point here is to recommend you consider a variety of 'typical' (pre-cobbler) kickstart process(s) and when laying out cobbler's how's and whys (i.e. the new way to do business), present clear and compelling rationale for why things are done (and not done, i.e. no DHCP) the cobbler-way. This gives die-hard old-style kickstarters a bridging roadmap to the future. One other area of deep concern (for me anyway, as I've probably got a lot to learn to get this) is the arbitrary installation of an operating system not previously installed in any given environment, without having to manually install it once first. A typical example is having two machines bare metal. On one, a Linux OS (pick one: FC5/32, RHEL ES4.2/32, RHEL5.1/64) is installed and configured to be a kickstart server (today, though eventually we'll all learn how to make it a cobbler server). Then set up another OS (pick multiple different ones that don't match that of the kickstart/cobbler server, in this case, settle on F9/32, RHEL AS4.7/64, RHEL ES4.1/32 and RHEL5.2/64) for a kickstarted implementation destined for the other bare metal server. What's the cobbler process to get a tailored installation of the destination bare metal server with the intended OS(s) that is repeatable and consistent without having to manually build on that server first??? And, maybe having asked all that in the previous para is not the problem set (or one of them) that cobbler is intended to solve. I don't know enough yet, but that area does seem pretty relevant to me. Not trying to get a reply back on the solution (though a private one back is welcome, too), as that wasn't my point, just trying to offer recommendations for exploration and documentating. Thank you for the opportunity to contribute. R, -Joe Wulf, CISSP, USN(RET) Senior IA Engineer ProSync Technology Group, LLC www.prosync.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael DeHaan Sent: Monday, July 28, 2008 14:09 To: all things Cobbler Subject: Thoughts on the free Cobbler deployment guide "book". What do youwant to see? One of the things I've talked about previously is writing a much involved "Best Practices" deployment guide for Cobbler. I think Cobbler's far enough now that it would be a good time to do this, as the core of things should not be changing so significantly that it will not rapidly become out of date. The focus would be on large scale and complex deployments, and would roll up and incorporate all the content on the Wiki with various things I hear from users about how they manage their deployments. This is very much going to be a "book" in terms of length. How short or long I'm not sure, but it will exceed the manpage and Wiki in scope. I'm going to start working on that soon, so I am wondering if there is anything specific you folks would like to see covered or included? As with Cobbler, this is intended to be collaboratively developed, so the document sources will be kept in git. My main concern at this point is if the deployment guide would become out of sync with the Wiki and/or manpage, so I'm tempted to just write the deployment guide on the Wiki. However this is less than ideal for printing reasons. Alternatively, we can look to hosting all documentation in DocBook, though this makes the Wiki less Wiki like. Publican seems to be a popular option for document publishing. (https://fedorahosted.org/publican/wiki/UsersGuide). It has the disadvantage of being XML, though I think this still may be a bit better for getting contributions than something like LaTEX. --Michael _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
