Bug 436227
| Summary: | smartd-conf.py is missing | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jóhann B. Guðmundsson <johannbg> |
| Component: | smartmontools | Assignee: | Tomas Smetana <tsmetana> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-03-07 07:58:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jóhann B. Guðmundsson
2008-03-06 00:14:53 UTC
The script is in a separate package: smartmontools-config. It dragged in too many dependencies. You're right that it should be installed by default. Smartd-conf.py was apparently move to separate package smartmontools-config Cause it was causing so much dep hell... #241389 The proper solution to this would be to create a new smartd-conf script that does not have to pull inn so many "dependency". Either the smartmontools get install by default and works out of the box for the enduser or it does not get installed at all! The default config uses DEVICESCAN, which is supposed to work for majority of the users. The script may help the autodetection by using information from HAL and /proc (yes, that's why the dependecies on hal and dbus-python). The "proper solution" would be to improve the autodetection at smartd application level. But keep in mind that wrong autodetection may cause problems (some controllers go offline after receiving unknown command...) so it is safer for users whose hardware is not detected to read the manual page and configure smartmontools manually. Anyone turning the service on is supposed to know what he is doing. "The "proper solution" would be to improve the autodetection at smartd application level" True.. "But keep in mind that wrong autodetection may cause problems" As can be with all "autodetection" hence things are fixed/improved. "Safer for users whose hardware is not detected to read the manual page and configure smartmontools manually" You seem to forget to take into the equation that the A. user(s) understand man pages B. the man pages are on his language and C. The fact that if the user is expected to read man pages he can just as well be expected to install the application if he needs it, hence this should not be installed by default. Anyone turning the service on is supposed to know what he is doing. True as long as Fedora/system/package does not turn on the service for him. Given the fact that there is no whole structure/rule on which services are enabled by default ( Which by the way should just be those who are strictly necessery to make the system run the rest should be enabled by the user in first boot/first login or whenever he decides to do so instead of $random package maintainer and developer either have turned on or off for example Bluetooth Avahi SSHD <-- Security risk that is enabled by default leaves the box open for bruteforce attaces ( in case ipables fail ) hplip ??? i could go on..... ) have to make sure that those services that are shipped with the default installation are clean and work. ( /etc/init.d/smard the genconfig() code there should not exist there unless smartd-conf.py is installed with it ) .. smartmontools-config was added to F-9 comps file, so it should be installed by default. Users may optionally unselect it during the installation. |