Menu
▾
▴
#8 LinuxCOE should provide a conformance mecanism
LinuxCOE should provide a conformance mecanism:
We would like to check our running system versus a baseline and ask LinuxCOE to fix the configuration
(Quoting Bryan: a tripwire on packages)
We would likre that LinuxCOE provides a cron job that would allow to reinstall what is missing on the system vs the baseline and remove what is extra.
Logged In: YES
user_id=87947
Originator: NO
My initial reaction was that the solution is far beyond the domain of SystemDesigner (since it is really a stateless web server with no notion of clients). However, we can certainly help the situation by leaving important breadcrumbs on the target host and possibly some more tools. For instance:
After installation, we already have the following "records":
1) a design session description in /etc/opt/LinuxCOE/replay
2) a list of packages in /var/log/LinuxCOE-base.log (albeit not in a very parser friendly format)
3) a retrofit session in /etc/opt/LinuxCOE/sw/BundleName (albeit removed if successful)
4) an updated snapshot of 2) during retrofits in /var/log/LinuxCOE-retrofit.log, and the packages installed denoted in /var/log/LinuxCOE-retrofit.log.rpm (again, not very parser friendly)
So, here is my thinking of how to assist in this matter (at least from the SysDes perspective)
a) we can't maintain state, the "golden" list, so this portion must be externally managed
in a CMDB offering. This is due to a huge number of reasons, with a short list below
- at some point a human has to decide when good is "good"
- most installations will have packages added (or substracted) during it's lifetime by someone with root level access, and with the LinuxCOE tools provided (apt/yum/... all preconfigured to point at any number of repositories), makes that even easier ;)
- hopefully the system is being patched, which may use the LinuxCOE provided mechanisms, and thus continually changes the "current" state
- ...
- as such, the complete solution would likely incldue tools like cfg2html and/or OCSInventory to maintain the state information and act as the CMDB
b) We could potentially add some tools, though:
- "replay" the installation, based on 1) 3) above. Certainly this would only address those components managed via SysDes assisted installations.
- "coe_remove" (basically the evil twin of coe_bootimage/coe_profile) to have a WebUI to assist in removing distro and value-add bundles
- "coe_retrorm" (the other coe_retrofit) and "uninstall_bundles" to deselect and remove bundles easily
d) ensure that our log files (or a representation of them) could be easily parsed
e) perhaps the patch script (which is now optional, and has a selectable frequency) could get deployed automatically (even if not specifically setup with a frequency), but would only provide a preview mode (apt-get update / apt-get --dry-run upgrade or yum list updates). This would at least show updates to the current installed base (and which doesn't address removals, of course).
Logged In: YES
user_id=87947
Originator: NO
My initial reaction was that the solution is far beyond the domain of SystemDesigner (since it is really a stateless web server with no notion of clients). However, we can certainly help the situation by leaving important breadcrumbs on the target host and possibly some more tools. For instance:
After installation, we already have the following "records":
1) a design session description in /etc/opt/LinuxCOE/replay
2) a list of packages in /var/log/LinuxCOE-base.log (albeit not in a very parser friendly format)
3) a retrofit session in /etc/opt/LinuxCOE/sw/BundleName (albeit removed if successful)
4) an updated snapshot of 2) during retrofits in /var/log/LinuxCOE-retrofit.log, and the packages installed denoted in /var/log/LinuxCOE-retrofit.log.rpm (again, not very parser friendly)
So, here is my thinking of how to assist in this matter (at least from the SysDes perspective)
a) we can't maintain state, the "golden" list, so this portion must be externally managed
in a CMDB offering. This is due to a huge number of reasons, with a short list below
- at some point a human has to decide when good is "good"
- most installations will have packages added (or substracted) during it's lifetime by someone with root level access, and with the LinuxCOE tools provided (apt/yum/... all preconfigured to point at any number of repositories), makes that even easier ;)
- hopefully the system is being patched, which may use the LinuxCOE provided mechanisms, and thus continually changes the "current" state
- ...
- as such, the complete solution would likely incldue tools like cfg2html and/or OCSInventory to maintain the state information and act as the CMDB
b) We could potentially add some tools, though:
- "replay" the installation, based on 1) 3) above. Certainly this would only address those components managed via SysDes assisted installations.
- "coe_remove" (basically the evil twin of coe_bootimage/coe_profile) to have a WebUI to assist in removing distro and value-add bundles
- "coe_retrorm" (the other coe_retrofit) and "uninstall_bundles" to deselect and remove bundles easily
d) ensure that our log files (or a representation of them) could be easily parsed
e) perhaps the patch script (which is now optional, and has a selectable frequency) could get deployed automatically (even if not specifically setup with a frequency), but would only provide a preview mode (apt-get update / apt-get --dry-run upgrade or yum list updates). This would at least show updates to the current installed base (and which doesn't address removals, of course).
Logged In: YES
user_id=87947
Originator: NO
My initial reaction was that the solution is far beyond the domain of SystemDesigner (since it is really a stateless web server with no notion of clients). However, we can certainly help the situation by leaving important breadcrumbs on the target host and possibly some more tools. For instance:
After installation, we already have the following "records":
1) a design session description in /etc/opt/LinuxCOE/replay
2) a list of packages in /var/log/LinuxCOE-base.log (albeit not in a very parser friendly format)
3) a retrofit session in /etc/opt/LinuxCOE/sw/BundleName (albeit removed if successful)
4) an updated snapshot of 2) during retrofits in /var/log/LinuxCOE-retrofit.log, and the packages installed denoted in /var/log/LinuxCOE-retrofit.log.rpm (again, not very parser friendly)
So, here is my thinking of how to assist in this matter (at least from the SysDes perspective)
a) we can't maintain state, the "golden" list, so this portion must be externally managed
in a CMDB offering. This is due to a huge number of reasons, with a short list below
- at some point a human has to decide when good is "good"
- most installations will have packages added (or substracted) during it's lifetime by someone with root level access, and with the LinuxCOE tools provided (apt/yum/... all preconfigured to point at any number of repositories), makes that even easier ;)
- hopefully the system is being patched, which may use the LinuxCOE provided mechanisms, and thus continually changes the "current" state
- ...
- as such, the complete solution would likely incldue tools like cfg2html and/or OCSInventory to maintain the state information and act as the CMDB
b) We could potentially add some tools, though:
- "replay" the installation, based on 1) 3) above. Certainly this would only address those components managed via SysDes assisted installations.
- "coe_remove" (basically the evil twin of coe_bootimage/coe_profile) to have a WebUI to assist in removing distro and value-add bundles
- "coe_retrorm" (the other coe_retrofit) and "uninstall_bundles" to deselect and remove bundles easily
d) ensure that our log files (or a representation of them) could be easily parsed
e) perhaps the patch script (which is now optional, and has a selectable frequency) could get deployed automatically (even if not specifically setup with a frequency), but would only provide a preview mode (apt-get update / apt-get --dry-run upgrade or yum list updates). This would at least show updates to the current installed base (and which doesn't address removals, of course).