Opened 14 years ago
Closed 14 years ago
#122 closed defect (fixed)
"make install" overwrites existing smartd.conf without warning or backup
Reported by: | kaluscha | Owned by: | Christian Franke |
---|---|---|---|
Priority: | minor | Milestone: | Release 5.41 |
Component: | all | Version: | 5.40 |
Keywords: | Cc: |
Description
When installing from source tarball, "make install" overwrites an existing smartd.conf file without warning or creating a backup.
If such a config file already exists, it should at least be renamed to something like smartd.conf.backup so the existing configuration doesn't get completely lost.
Change History (6)
comment:1 by , 14 years ago
Keywords: | linux make install added |
---|
comment:2 by , 14 years ago
Keywords: | linux make install removed |
---|
follow-up: 4 comment:3 by , 14 years ago
It would, of course, have been possible to copy the smartd.conf file beforehand - if I had known about smartmontools behaviour. But I was completely surprised to learn that smartmontools' "make install" simply destroys an existing config.
I've installed many other packages using the classic "configure; make; make install" approach. Almost all of them preserve existing configurations or warn about installing a new config after renaming the old.
comment:4 by , 14 years ago
Milestone: | → Release 5.41 |
---|---|
Owner: | changed from | to
Status: | new → accepted |
Replying to kaluscha:
I've installed many other packages using the classic "configure; make; make install" approach. Almost all of them preserve existing configurations or warn about installing a new config after renaming the old.
Could you please provide some example package names?
comment:5 by , 14 years ago
E.g. Apache2, OpenSSH, Samba, ...
I don't expect a fancy algorithm of merging new and existing config files. In my opionion there are two options which are simple to implement:
- install new config file after renaming the old one and give a warning about that (especially useful when there are major changes)
- preserve an existing config file and create the new one with a different name (and give a warning about that, too)
BTW: OpenSuSE uses the second option pretty much; e.g. creating .rpmnew-files when a new or updated rpm-packages encounters an existing configuration. Then it is quite easy to do a diff on both config files to see what options are new.
In many cases your default config with DEVICESCAN will work fine, but I have some machines with a more sophisticated setup (monitor almost everything, but don't complain about small changes in temperature, send an e-mail if something is fishy, leave disk X alone as it contains very old data which is rarely accessed so the disk goes to standby mode etc.)
Thnx for dealing with the issue anyway,
Rainer
Possible workaround:
./configure --enable-sample