Looking for some guidance to help automate/modularize repeatable deployments ... 1) NIC setup scenario: - The target server systems have multiple NICs - The respective MAC addresses of each NIC can be found using BMC interface - User wishes to seed desired NIC usage by providing target MAC Address(es) (e.g. MACAddress1 - dhcp, MACAddress3 - IP/mask,gateway,...) After (re)reading the docs many times, seems like a possible approach might be (albeit have yet to succeed doing this) - generate an autoYaST pre-script with - desired MACAddress - desired "bootproto" - output = mapping to associated "device" name found during boot - leverage rules, classes, or even asks (to confirm) - pull in "interface" fragment, substituting "device" name and config specifics Bonus points / challenges - also seems doable to have "interface" fragments for more complicated setups: - bond these two devices - bond/bridge these N devices, etc. - managing firewall settings - perhaps using post-scripts (for anything beyond the one needed NIC for install) 2) Disk setup scenario - The target server systems have multiple drives - The respective drive (model, serial number, size, etc) of each drive can be found using BMC interface - User wishes to seed desired partitioning by providing a physical attribute (e.g. serial number - root, serial number - data) As above, after (re)reading the docs many times, seems like a possible approach might be (albeit have yet to succeed doing this) - generate an autoYaST pre-script with - desired serial number - desired partitioning type/label - output = mapping serial number to associated "device" name found during boot - leverage rules, classes, or even asks (to confirm) - pull in "drive" fragment targeting mapped "device" name and config specifics Bonus points / challenges - more difficult if storage controller has created LUNs of multiple drives - perhaps using post-scripts (for anything beyond the one needed drive for install) Thanks in advance for any guidance and suggestions on how to implement this, for a large set of systems that are to be (re)installed over time and may not be entirely homogeneous. The goal though is to only pre-seed those specifics (that can be found outside the installer) and generate/rely upon such mappings into for the fragments to provide a good level of consistency (vs. just using the interactive installer interface). Of course, either post-install or typical configuration management options could be layered on after the fact to complete the system configuration, beyond needing one (desired) NIC to access packages/repos and one (desired) drive to install upon. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org