From: David K. <dab...@ex...> - 2004-03-29 16:25:56
Attachments:
smartmontools.config.patch
|
Please find attached a simple patch to the startup script for smartd that allows a configuration file in /etc/sysconfig to control the initial command line flags to smartd. This has proven very useful with our setup. Excellent software! David _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! |
From: Brett R. <ru...@em...> - 2004-03-30 13:51:27
|
David K. wrote: > Please find attached a simple patch to the startup script for smartd > that allows a configuration file in /etc/sysconfig to control the > initial command line flags to smartd. This has proven very useful > with our setup. This is an interesting way to solve the same problem I was trying to solve. My patch (not yet released) basically makes some of the options normally set through cmd line flags able to be set via the /etc/smartd.conf file. By doing that, I introduce the notion of "global" options into the smartd.conf file, whereas now only drives are dealt with. Your solution is simpler but it requires another config file. I wonder what is preferable to the maintainers? Brett |
From: Bruce A. <ba...@gr...> - 2004-03-30 16:26:26
|
> > Please find attached a simple patch to the startup script for smartd > > that allows a configuration file in /etc/sysconfig to control the > > initial command line flags to smartd. This has proven very useful > > with our setup. > > This is an interesting way to solve the same problem I was trying to > solve. My patch (not yet released) basically makes some of the > options normally set through cmd line flags able to be set via the > /etc/smartd.conf file. By doing that, I introduce the notion of > "global" options into the smartd.conf file, whereas now only drives > are dealt with. Your solution is simpler but it requires another > config file. > > I wonder what is preferable to the maintainers? I'm not sure -- with this email I'm asking. The original idea with smartd was to have options that apply to all drives be on the command line, and to have the options that apply 'drive by drive' live in smartd.conf. Normally the command-line is accessible in the init script that starts smartd, and (at least with Redhat/Fedora) the normal way to put these command-line options into a file is to use a file in /etc/sysconfig/ to set their values. So I personally like the idea of having: if [ -f /etc/sysconfig/smartd ]; then . /etc/sysconfig/smard fi in the smartd init script, mostly because it simplifies smartd and saves the burden of documenting/maintaining yet another file. But I'm open to other opinions about this. I'm curious what is done on Debian, for example. Cheers, Bruce |
From: Guido G. <ag...@si...> - 2004-04-01 20:27:39
|
On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote: > So I personally like the idea of having: > if [ -f /etc/sysconfig/smartd ]; then > . /etc/sysconfig/smard > fi Nice. We're using something like this in Debian for some time (it's called /etc/default/smartmontools (this is what debian uses for these kind of things, need to ckeck what FHS says about this). I'd be great if we could agree on the same option names. We currently have this default skript: # Defaults for smartmontools initscript (/etc/init.d/smartmontools) # This is a POSIX shell fragment # list of devices you want to explicitly enable S.M.A.R.T. for # not needed if the device is monitored by smartd #enable_smart="/dev/hda /dev/hdb" # uncomment to start smartd on system startup #start_smartd=yes # uncomment to pass additional options to smartd on startup #smartd_opts="--interval=3600" Does this look reasonable for other distributions too? Cheers, -- Guido |
From: <li...@pe...> - 2004-04-01 20:47:11
|
On Thu, 1 Apr 2004, Guido Guenther wrote: > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote: > > So I personally like the idea of having: > > if [ -f /etc/sysconfig/smartd ]; then > > . /etc/sysconfig/smard > > fi > Nice. We're using something like this in Debian for some time (it's > called /etc/default/smartmontools (this is what debian uses for these > kind of things, need to ckeck what FHS says about this). FHS says nothing about /etc/sysconfig. -- http://www.pervalidus.net/contact.html |
From: Bruce A. <ba...@gr...> - 2004-04-01 21:04:53
|
> On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote: > > So I personally like the idea of having: > > if [ -f /etc/sysconfig/smartd ]; then > > . /etc/sysconfig/smard > > fi > Nice. We're using something like this in Debian for some time (it's > called /etc/default/smartmontools (this is what debian uses for these > kind of things, need to ckeck what FHS says about this). I'd be great if > we could agree on the same option names. We currently have this default > skript: > # Defaults for smartmontools initscript (/etc/init.d/smartmontools) > # This is a POSIX shell fragment > > # list of devices you want to explicitly enable S.M.A.R.T. for > # not needed if the device is monitored by smartd > #enable_smart="/dev/hda /dev/hdb" > > # uncomment to start smartd on system startup > #start_smartd=yes > > # uncomment to pass additional options to smartd on startup > #smartd_opts="--interval=3600" > > Does this look reasonable for other distributions too? Yes. I think that the 'enable_smart' part might not be needed/used by other distributions (I'm not sure what it does) but probably no harm having it there. By the way, I'd suggest that for things like smartd_opts="--interval=3600" we make the commented default values agree with the package default values (in this case --interval=1800). Guido -- can you take responsibility for choosing option and file names in a way that's consistent with FHS and putting it into our 'unified' init script. I suspect that the biggest issue is the /etc/sysconfig file name. I'd be happy with any of: smart smartd smartmontools and since Redhat/Fedora don't have these files yet, we have freedom to change the name... Cheers, Bruce |
From: Guido G. <ag...@si...> - 2004-04-02 10:50:24
|
On Thu, Apr 01, 2004 at 03:04:47PM -0600, Bruce Allen wrote: > I think that the 'enable_smart' part might not be needed/used by other > distributions (I'm not sure what it does) but probably no harm having it > there. This is what enable_smart does: enable_smart() { echo -n "Enabling S.M.A.R.T. for:" for device in $enable_smart; do echo -n " $device" $SMARTCTL --quietmode=3Derrorsonly --smart=3Don $device || \ { echo -n "(failed)"; RET=3D2; } done echo "." } > By the way, I'd suggest that for things like smartd_opts=3D"--interval=3D= 3600" > we make the commented default values agree with the package default values > (in this case --interval=3D1800). O.k., fine I'll do that. > Guido -- can you take responsibility for choosing option and file names in > a way that's consistent with FHS and putting it into our 'unified' init > script. I suspect that the biggest issue is the /etc/sysconfig file name= =2E =20 > I'd be happy with any of: > smart > smartd > smartmontools > and since Redhat/Fedora don't have these files yet, we have freedom to > change the name... O.k., I'll have a look. -- Guido |
From: Bruce A. <ba...@gr...> - 2004-04-02 13:10:36
|
> This is what enable_smart does: > enable_smart() { > echo -n "Enabling S.M.A.R.T. for:" > for device in $enable_smart; do > echo -n " $device" > $SMARTCTL --quietmode=errorsonly --smart=on $device || \ > { echo -n "(failed)"; RET=2; } > done > echo "." > } OK, this might be necessary for SCSI devices (smartd automatically enable SMART on ATA devices). You might want to add a comment to that effect. [Doug is opposed to smartd automatically enabling SMART for SCSI devices.] > > By the way, I'd suggest that for things like smartd_opts="--interval=3600" > > we make the commented default values agree with the package default values > > (in this case --interval=1800). > O.k., fine I'll do that. > > > Guido -- can you take responsibility for choosing option and file names in > > a way that's consistent with FHS and putting it into our 'unified' init > > script. I suspect that the biggest issue is the /etc/sysconfig file name. > > I'd be happy with any of: > > smart > > smartd > > smartmontools > > and since Redhat/Fedora don't have these files yet, we have freedom to > > change the name... > O.k., I'll have a look. As you see from my last email, I'm backing away from this 'unified file location.' Right now I'd prefer to define these standard variables in smartd.initd.in and then have distribution specific file includes to over-ride them if desired by the distribution/user. Cheers, Bruce |
From: Guido G. <ag...@si...> - 2004-04-02 16:02:03
|
On Fri, Apr 02, 2004 at 07:10:33AM -0600, Bruce Allen wrote: > > This is what enable_smart does: > > enable_smart() { > > echo -n "Enabling S.M.A.R.T. for:" > > for device in $enable_smart; do > > echo -n " $device" > > $SMARTCTL --quietmode=3Derrorsonly --smart=3Don $device || \ > > { echo -n "(failed)"; RET=3D2; } > > done > > echo "." > > } >=20 > OK, this might be necessary for SCSI devices (smartd automatically enable > SMART on ATA devices). You might want to add a comment to that effect. > [Doug is opposed to smartd automatically enabling SMART for SCSI devices.] The current Debian configuration says: # list of devices you want to explicitly enable S.M.A.R.T. for # not needed if the device is monitored by smartd so you think: # List of devices you want to explicitly enable S.M.A.R.T. for # Not needed if the device is a ATA device and monitored by smartd # But note that smartd doesn't enable S.M.A.R.T on SCSI devices # automatically smart_enable=3D... would be better? > As you see from my last email, I'm backing away from this 'unified file > location.' Right now I'd prefer to define these standard variables in > smartd.initd.in and then have distribution specific file includes to > over-ride them if desired by the distribution/user. Fine. We could try to agree on a sensible naming though. -- Guido |
From: Bruce A. <ba...@gr...> - 2004-04-02 19:44:54
|
> so you think: > > # List of devices you want to explicitly enable S.M.A.R.T. for > # Not needed if the device is a ATA device and monitored by smartd > # But note that smartd doesn't enable S.M.A.R.T on SCSI devices > # automatically > smart_enable=... > > would be better? Yes > > As you see from my last email, I'm backing away from this 'unified file > > location.' Right now I'd prefer to define these standard variables in > > smartd.initd.in and then have distribution specific file includes to > > over-ride them if desired by the distribution/user. > Fine. We could try to agree on a sensible naming though. Absolutely! Guido, will you take charge of this? In other words, edit smartd.initd.in in a sensible way? I don't think you need to search for consensus first -- if people don't like your choices we can talk it through on the mailing list and then check modifications into CVS later. Cheers, Bruce |
From: Guido G. <ag...@si...> - 2004-04-03 13:04:55
Attachments:
smartd.init.in
|
On Fri, Apr 02, 2004 at 01:44:52PM -0600, Bruce Allen wrote: > Absolutely! > > Guido, will you take charge of this? In other words, edit smartd.initd.in > in a sensible way? O.k. what about the attached changes? Redhat is missing since I'm not sure about the "daemon" call. I assume I can just append the arguments? Cheers, -- Guido |
From: Bruce A. <ba...@gr...> - 2004-04-03 19:53:45
|
> > Absolutely! > > > > Guido, will you take charge of this? In other words, edit smartd.initd.in > > in a sensible way? > O.k. what about the attached changes? Redhat is missing since I'm not > sure about the "daemon" call. I assume I can just append the arguments? The changes look fine -- please go ahead and check them into CVS. I think you can just append the arguments to the daemon call -- in any case I'll take responsibility for testing it and fixing it if needed. Cheers, Bruce |
From: Brett R. <ru...@em...> - 2004-04-05 04:22:39
|
Guido Guenther wrote: > O.k. what about the attached changes? Redhat is missing since I'm not > sure about the "daemon" call. I assume I can just append the arguments? My only issue with the below is that 99.9% of the config files in SuSE are in /etc/sysconfig. There are ~69 conf. files there and 1 conf. file in /etc/default (on my SuSE 9.0 pro system). Why not stick to the distro's convention since you're doing distribution specific code anyway? BR > > @@ -128,6 +136,8 @@ elif [ -f /etc/SuSE-release ] ; then > # Existence of config file is optional > SMARTD_CONFIG=/etc/smartd.conf > > +# source configuration file > + [ -r /etc/default/smartmontools ] && . /etc/default/smartmontools |
From: Guido G. <ag...@si...> - 2004-04-05 10:18:17
|
On Mon, Apr 05, 2004 at 12:22:29AM -0400, Brett Russ wrote: > My only issue with the below is that 99.9% of the config files in SuSE=20 > are in /etc/sysconfig. There are ~69 conf. files there and 1 conf. file= =20 > in /etc/default (on my SuSE 9.0 pro system). Why not stick to the=20 > distro's convention since you're doing distribution specific code anyway? SuSE is well known for starting moves from one subdir to another with just some files. Are you sure /etc/sysconfig will stay the default? It looks to me that more and more files are moving to /etc/default, but this could be wrong since I didn't follow SuSE development closely recently. Cheers, -- Guido |
From: Bruce A. <ba...@gr...> - 2004-04-05 14:49:42
|
Stanislav, Can you please tell us what is prefered for SuSE? We want a file location where a user can have a file that defines 'setup' for smartmontools. At the moment it will just contain the command-line arguments passed to smartd in the init script. The choices are: /etc/sysconfig/smartmontools /etc/default/smartmontools Which location is prefered for SuSE? Cheers, Bruce On Mon, 5 Apr 2004, Guido Guenther wrote: > On Mon, Apr 05, 2004 at 12:22:29AM -0400, Brett Russ wrote: > > My only issue with the below is that 99.9% of the config files in SuSE > > are in /etc/sysconfig. There are ~69 conf. files there and 1 conf. file > > in /etc/default (on my SuSE 9.0 pro system). Why not stick to the > > distro's convention since you're doing distribution specific code anyway? > SuSE is well known for starting moves from one subdir to another with > just some files. Are you sure /etc/sysconfig will stay the default? It > looks to me that more and more files are moving to /etc/default, but > this could be wrong since I didn't follow SuSE development closely > recently. > Cheers, > -- Guido > |
From: <li...@pe...> - 2004-04-03 02:55:41
|
On Thu, 1 Apr 2004, Bruce Allen wrote: > > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote: > > Does this look reasonable for other distributions too? > > Yes. /etc/sysconfig doesn't. > I suspect that the biggest issue is the /etc/sysconfig file > name. No, the biggest is /etc/sysconfig. > I'd be happy with any of: > smart > smartd > smartmontools > and since Redhat/Fedora don't have these files yet, we have freedom to > change the name... If you want to add something for all distributions, use /usr/share/smartmontools (I don't see a better place) or something, but not /etc/sysconfig. Or if you insist, make it disabled by default. -- http://www.pervalidus.net/contact.html |
From: Bruce A. <ba...@gr...> - 2004-04-01 21:31:06
|
> > > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote: > > > Does this look reasonable for other distributions too? > > Yes. > > /etc/sysconfig doesn't. OK, let's make a list of where different distribution put these things. Please add on to this list and resend Redhat/Fedora: /etc/sysconfig/ Debian: Mandrake: Slackware: Gentoo: SuSE: Connectiva: FHS: Others? Bruce |
From: <li...@pe...> - 2004-04-01 21:42:46
|
On Thu, 1 Apr 2004, Bruce Allen wrote: > > > > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote: > > > > Does this look reasonable for other distributions too? > > > Yes. > > > > /etc/sysconfig doesn't. > > OK, let's make a list of where different distribution put these > things. Please add on to this list and resend > Slackware: Nothing. Adding various directories to /etc and not being compliant with the FHS was always a Red Hat thing, later mimiced by other distributions. > FHS: "/usr/share : Architecture-independent data" /usr/share : Architecture-independent data Purpose The /usr/share hierarchy is for all read-only architecture independent data files. [30] This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS. Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. Game data stored in /usr/share/games must be purely static data. Any modifiable files, such as score files, game play logs, and so forth, should be placed in / var/games. /usr/share/misc : Miscellaneous architecture-independent data This directory contains miscellaneous architecture-independent files which don't require a separate subdirectory under /usr/share. [22] Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share. [30] Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo). -- http://www.pervalidus.net/contact.html |
From: Bruce A. <ba...@gr...> - 2004-04-01 21:45:40
|
> Adding various directories to /etc and not being compliant with the > FHS was always a Red Hat thing, later mimiced by other distributions. Please, I'd like to know where the other distributions put these files. Bruce |
From: <li...@pe...> - 2004-04-01 22:01:07
|
On Thu, 1 Apr 2004, Bruce Allen wrote: > > Adding various directories to /etc and not being compliant with the > > FHS was always a Red Hat thing, later mimiced by other distributions. > > Please, I'd like to know where the other distributions put these files. I don't know, but it's the truth. And if all but one don't use /etc/sysconfig, it shouldn't be enabled by default. Not to mention not being FHS compliant. But if you want to create an /etc/smartd or /etc/smartmontools, I don't see it as a problem. -- http://www.pervalidus.net/contact.html |
From: Bruce A. <ba...@gr...> - 2004-04-01 22:11:41
|
> > > Adding various directories to /etc and not being compliant with the > > > FHS was always a Red Hat thing, later mimiced by other distributions. > > > > Please, I'd like to know where the other distributions put these files. > > I don't know, but it's the truth. And if all but one don't use > /etc/sysconfig, it shouldn't be enabled by default. Not to > mention not being FHS compliant. > > But if you want to create an /etc/smartd or /etc/smartmontools, > I don't see it as a problem. I'm waiting to hear what Guido says... Bruce |
From: <li...@pe...> - 2004-04-01 21:52:25
|
On Thu, 1 Apr 2004, Fr=E9d=E9ric L. W. Meunier wrote: > The /usr/share hierarchy is for all read-only architecture > independent data files. [30] > > Any program or package which contains or requires data that > doesn't need to be modified should store that data in > /usr/share (or /usr/local/share, if installed locally). It is > recommended that a subdirectory be used in /usr/share for this > purpose. > > Game data stored in /usr/share/games must be purely static > data. Any modifiable files, such as score files, game play > logs, and so forth, should be placed in / var/games. Modifiable. /var what then ? /var/lib ? --=20 http://www.pervalidus.net/contact.html |
From: Brett R. <ru...@em...> - 2004-04-02 00:16:27
|
Bruce Allen wrote: > OK, let's make a list of where different distribution put these > things. Please add on to this list and resend > > Redhat/Fedora: /etc/sysconfig/ > Debian: > Mandrake: > Slackware: > Gentoo: > SuSE: /etc/sysconfig/ > Connectiva: > FHS: > Others? |
From: Guido G. <ag...@si...> - 2004-04-02 10:54:12
|
On Thu, Apr 01, 2004 at 03:31:03PM -0600, Bruce Allen wrote: > Redhat/Fedora: /etc/sysconfig/ > Debian: /etc/default/ > Mandrake: > Slackware: > Gentoo: > SuSE: Seems to have both: /etc/default and /etc/sysconfig > Connectiva: > FHS: > Others? >=20 > Bruce |
From: Guido G. <ag...@si...> - 2004-04-02 10:52:12
|
On Thu, Apr 01, 2004 at 06:17:03PM -0300, Fr=E9d=E9ric L. W. Meunier wrote: > If you want to add something for all distributions, use > /usr/share/smartmontools (I don't see a better place) or > something, but not /etc/sysconfig. Or if you insist, make it > disabled by default. I'd prefer to have all configuration data in /etc. It would probably make sense to have the _format_ of the configuration file the same across all distributions but not the _location_. -- Guido |