From: Bruce A. <ba...@di...> - 2003-01-14 20:32:30
|
Hi Phil, Thanks for the quick reply! > > As part of this, I'd propose changing the -M directive to have the > > following syntax. I'm hoping for Phil William's feedback on this, and > > perhaps a bit of his help in implementing it. > > > > The idea is to allow the use of multiple -M Directives for example: > > > > -M diminishing -M test -M runsmartctl > > > > and to eliminate the "comma separated" Directives to -M, eg, replace > > -M once,test > > with > > -M once -M test > > I like the sound of this. The proposed -M Directive syntax is an improvement > on what we've got because we don't actually parse the list of Directives so: > > -M once,test > > is OK, but > > -M test,once > > is not. We could of course write the code to do that and write it so that > using multiple -M Directives also works as you'd expect, but I don't know > whether it's worth the effort. I'd say we keep it simple: -- allow multiple -M Directives -- each -M Directive takes a single argument -- if conflicting Directives are given (-M once -M daily) then the last one is the one that actually applies We should probably simplify configfile_s by replacing: char emailopt; with: unsigned char emailfreq; unsigned char emailtest; unsigned char runsmartctl; This will simplify the logic and Directive parsing. > I'm happy to make the necessary changes to the Directive parsing code and to > make the documentation changes. I guess the rest of it wouldn't be too tricky > either. Let me know what you'd like me to do, Bruce. Thank you! Let's wait to hear back from Tim. Cheers, Bruce |
From: Bruce A. <ba...@gr...> - 2003-01-17 21:25:29
|
Hi Tim, Phil, [and Doug, see below] I'm copying this to the mailing list to keep a public record of the discussions. I'd suggest you also do this. > How about: user can request the output of an arbitrary program > to be appended in case of smartd generating an email? I think this is OK -- but dangerous. It means you need to handle arbitrary length output. And it means that you need to handle gracefully the case where the arbitrary program doesn't terminate, expects a terminal device as input or output, etc. And it's then very important to deal cleanly with both stdout and stderr from the arbitrary program. So it's fine -- just be careful to handle the error cases cleanly. > I won't debate the choice of option but effectively on a per device > basis the user could include an option (we'll call it "-O" here) thus: > > /dev/hda -blahoptions -O "/usr/sbin/smartctl -a %s" > where %s is substituted for the devicename that smartd is > complaining about. Phil, do you like this? If so, can you pick a good option name? If not, can you suggest something better? I was hoping to simply hand off the command line interface issues to you. > Now the user can do what they like by writing a custom wrapper - > perhaps running "sginfo -d -e" (gets errors+defects list) > (from sg_utils package) if the device is SCSI or running > smartctl -a if it's ATA. It should be a more flexible approach. Since Doug Gilbert (author of sg_utils) is one of the smartmontools developers, we could also ask him to copy the relevant "sginfo -d -e" code into smartctl (:-). > I defer to you on how the option should be styled. I'm most happy > to write the patch better once you can tell me how it should be > presented in smartd.conf Phil, you should reply to this I think. > OK - I guess we can't really solve this - it would need to be upto the > user to fixup their rpmrc/rpmmacros settings to build somewhere they do have > write access (we do that) or the sysadmin can make /usr/src/redhat or equiv > have suitable access. In fact there IS a standard way to have .spec files build the code in places like /tmp or /var/tmp that are world-writetable. It's just that I don't know how to do it. And when I've tried it's failed. > I will double check what I did before I try submitting any changes to CVS. I already put part of your Makefile change into CVS (by accident, but I'll leave it there.) If you could take a crack at getting the .spec file to include the right "general user" invokations I'd be grateful. (on the subject of DEVICESCAN taking options) > Guess it needs looking at in detail - I'm not very conversant with > most of the codebase, can't really comment yet. Would be nice to do > though :-) At least add it into the TODO file. > > > the power on time is actually in seconds, which trips a false alarm. > > > > What disks are these? Is it attribute #9? > > It was a: > > Device Model: FUJITSU MPE3204AT > Serial Number: 05040260 > Firmware Version: ED-03-04 > > and it was attr #9 > > > > Should we add a -v options of 9,seconds for these disks? It's > trival. > > Or maybe a map file included with smartmontools? Some simple > format that could apply correction scalings to certain attributes > on named models of disks? That way the smartd.conf could be generic across > many machines despite disk model variations... Any good? I suspect it's too much work. With a dozen active disk vendors releasing new disks models weekly, I think we could never keep up. [But of course if you volunteer to add the code and maintain the map file.... well in that case it's fine with me!] > > Very nice. I gather that your systems are not very homogeneous? > > Oooh nooo. We tend to buy in batches; then some of those go slightly > variant when broken bits are replaced. Even servers tend to get > bought in lots of 10-ish depending on the deal our boss can > torture the vendor for. OK, that's good. Our computing clusters (I've built three) have all been 100% homogeneous. It's the only way to go when the number of machines/person is of order 100 or more. Cheers, Bruce |
From: Phil W. <ph...@su...> - 2003-01-18 01:04:44
|
Hi Bruce, Tim, > > I won't debate the choice of option but effectively on a per device > > basis the user could include an option (we'll call it "-O" here) thus: > > > > /dev/hda -blahoptions -O "/usr/sbin/smartctl -a %s" > > where %s is substituted for the devicename that smartd is > > complaining about. > > Phil, do you like this? If so, can you pick a good option name? If not, > can you suggest something better? I was hoping to simply hand off the > command line interface issues to you. How about something like: /dev/hda -M exec "/usr/sbin/smartcl -a %s" If we're going to allow the user to modify the behaviour of -m with four arguments to -M ('once', 'daily', 'diminishing', and 'test') then I'd prefer we stick with that convention and add a fifth argument rather than a separate Directive. I wasn't sure about the usefulness of '%s', but I've just realised that it is necessary if we are to allow Directives to be used with DEVICESCAN as Tim suggested (I think that's a good idea, btw.). > > I defer to you on how the option should be styled. I'm most happy > > to write the patch better once you can tell me how it should be > > presented in smartd.conf > > Phil, you should reply to this I think. I'm not really sure what Bruce was expecting me to write here, but anyway... I worked on the new options and Directives processing code in 5.1, and since Bruce hasn't revoked my CVS privileges yet I guess I'm sorta responsible for that stuff ;-) Once we've agreed on the syntax let me know if you want me to make the necessary changes to the Directive parsing code. If you want to do it yourself that's fine as well. Phil |
From: Bruce A. <ba...@gr...> - 2003-01-18 17:14:17
|
Hi Phil, > How about something like: > > /dev/hda -M exec "/usr/sbin/smartcl -a %s" > It looks good to me. > If we're going to allow the user to modify the behaviour of -m with four > arguments to -M ('once', 'daily', 'diminishing', and 'test') then I'd prefer > we stick with that convention and add a fifth argument rather than a separate > Directive. > > I wasn't sure about the usefulness of '%s', but I've just realised that it > is necessary if we are to allow Directives to be used with DEVICESCAN as Tim > suggested (I think that's a good idea, btw.). Actually I agree that %s is needed, but don't agree with the reason why. It's only needed to indicate where in the command line argument for the program to be execed the device name should appear. Eg: /usr/sbin/smartctlreplacement %s -a takes -b arguments -c afterwards /usr/sbin/dougsscsiutility -a takes -b device -c name -d %s -e midway But the %s is NOT needed for DEVICESCAN, since internally we always know what device we are concerned with. > I worked on the new options and Directives processing code in 5.1, and since > Bruce hasn't revoked my CVS privileges yet I guess I'm sorta responsible for > that stuff ;-) Yup, you're stuck with it (:-). Phil, I'm happy with the syntax you suggested; if Tim likes it then the two of you can sort out who writes the code and who checks it. Cheers, Bruce |
From: Phil W. <ph...@su...> - 2003-01-18 18:50:24
|
Hi Bruce, > > I wasn't sure about the usefulness of '%s', but I've just realised that it > > is necessary if we are to allow Directives to be used with DEVICESCAN as Tim > > suggested (I think that's a good idea, btw.). > > Actually I agree that %s is needed, but don't agree with the reason why. > It's only needed to indicate where in the command line argument for the > program to be execed the device name should appear. Eg: > /usr/sbin/smartctlreplacement %s -a takes -b arguments -c afterwards > /usr/sbin/dougsscsiutility -a takes -b device -c name -d %s -e midway > > But the %s is NOT needed for DEVICESCAN, since internally we always know > what device we are concerned with. All I meant was is that if we are to allow Directives to be used with DEVICESCAN as they are with /dev/hda, say, then the user must be able to indicate to smartd that it should substitute 'the relevant device name' into the command line, which is why the %s is required. Of course the user also has to indicate the position(s) (if any) of the device name within the command line. I couldn't see the usefulness of %s until I remembered that we are thinking of extending DEVICESCAN in this way. In other words, I couldn't see any real advantage in using /dev/hda -M exec "foo %s" ... instead of /dev/hda -M exec "foo /dev/hda" ... in smartd.conf. But it is obviously necessary to be able to use: DEVICESCAN -M exec "foo %s" ... or something equivalent. Or am I still missing the point? Phil |
From: Bruce A. <ba...@gr...> - 2003-01-19 02:58:24
|
Hi Phil, > /dev/hda -M exec "foo %s" ... > > instead of > > /dev/hda -M exec "foo /dev/hda" ... > > in smartd.conf. But it is obviously necessary to be able to use: > > DEVICESCAN -M exec "foo %s" ... > > or something equivalent. > > Or am I still missing the point? I'm not sure. I think the point is that IF we knew that the function to be execed always took the device name as the final argument, THEN we could simply have the syntax: DEVICESCAN -M exec "foo -a -b -c" /dev/hda -M exec "hello -d -e -f" and the commands run might be: "foo -a -b -c /dev/hdi" "hello -d -e -f /dev/hda" respectively. BUT, since we can't expect that all user commands will take the device name as the final argument, we need a string to indicate the position of the name in the argument of foo. And, as Tim pointed out, if it were not for DEVICESCAN this would not be needed, but it's a bit ugly to have /dev/hda -M exec "hello -d /dev/hda -e -f" and prettier to have /dev/hda -M exec "hello -d %s -e -f" Cheers, Bruce |
From: Phil W. <ph...@su...> - 2003-01-19 12:23:02
|
Hi Bruce, > > in smartd.conf. But it is obviously necessary to be able to use: > > > > DEVICESCAN -M exec "foo %s" ... > > > > or something equivalent. > > > > Or am I still missing the point? > > I'm not sure. > > I think the point is that IF we knew that the function to be execed always > took the device name as the final argument, THEN we could simply have the > syntax: > > DEVICESCAN -M exec "foo -a -b -c" > > /dev/hda -M exec "hello -d -e -f" > > and the commands run might be: > "foo -a -b -c /dev/hdi" > "hello -d -e -f /dev/hda" > respectively. > > BUT, since we can't expect that all user commands will take the device > name as the final argument, we need a string to indicate the position of > the name in the argument of foo. I have been assuming all along that the command line will contain any number of instances of the device name (possibly none) in any position. > And, as Tim pointed out, if it were not for DEVICESCAN this would not > be needed, but it's a bit ugly to have > > /dev/hda -M exec "hello -d /dev/hda -e -f" > > and prettier to have > > /dev/hda -M exec "hello -d %s -e -f" What I said originally is: I wasn't sure about the usefulness of '%s', but I've just realised that it is necessary if we are to allow Directives to be used with DEVICESCAN as Tim suggested (I think that's a good idea, btw.). Which seems to be what you've just said, except that where I couldn't see the usefulness of %s if DEVICESCAN doesn't take directives, you think it is prettier to use %s than to hardwire the device name. Phil |
From: Bruce A. <ba...@gr...> - 2003-01-19 12:46:17
|
Hi Phil, > Which seems to be what you've just said, except that where I couldn't > see the usefulness of %s if DEVICESCAN doesn't take directives, you > think it is prettier to use %s than to hardwire the device name. OK, I apologize, I had misunderstood what you wrote earlier! [Also, it hadn't occured to me that there might be multiple instances of %s in one exec statement, which I certainly agree with!] Cheers, Bruce |
From: Phil W. <ph...@su...> - 2003-01-19 14:19:43
|
Hi Bruce, > > Which seems to be what you've just said, except that where I couldn't > > see the usefulness of %s if DEVICESCAN doesn't take directives, you > > think it is prettier to use %s than to hardwire the device name. > > OK, I apologize, I had misunderstood what you wrote earlier! No problem. And sorry for not being more explicit in the first place. Cheers, Phil |
From: Tim S. <ts...@di...> - 2003-01-19 00:18:25
|
Hello Chaps On Sat, 18 Jan 2003 11:13:43 -0600 (CST) Bruce Allen <ba...@gr...> wrote: > Hi Phil, > > > How about something like: > > > > /dev/hda -M exec "/usr/sbin/smartcl -a %s" > > > > It looks good to me. OK - I'll use this :-) > > If we're going to allow the user to modify the behaviour of -m with four > > arguments to -M ('once', 'daily', 'diminishing', and 'test') then I'd prefer > > we stick with that convention and add a fifth argument rather than a separate > > Directive. > > > > I wasn't sure about the usefulness of '%s', but I've just realised that it > > is necessary if we are to allow Directives to be used with DEVICESCAN as Tim > > suggested (I think that's a good idea, btw.). > > Actually I agree that %s is needed, but don't agree with the reason why. > It's only needed to indicate where in the command line argument for the > program to be execed the device name should appear. Eg: > /usr/sbin/smartctlreplacement %s -a takes -b arguments -c afterwards > /usr/sbin/dougsscsiutility -a takes -b device -c name -d %s -e midway That was my reasoning. <snip> > > I worked on the new options and Directives processing code in 5.1, and since > > Bruce hasn't revoked my CVS privileges yet I guess I'm sorta responsible for > > that stuff ;-) > > Yup, you're stuck with it (:-). > > Phil, I'm happy with the syntax you suggested; if Tim likes it then the > two of you can sort out who writes the code and who checks it. Of course I'm more than happy if Phil alters the options code, being more familiar with it, but if you're (Phil) too busy I'll give it a crack and follow the style. Please let me know what you prefer. Best, Tim -- Tim Southerwood Website: http://www.dionic.net/ email: ts@DIESPAMDIE.dionic.net (remove DIESPAMDIE. to get address) |
From: Phil W. <ph...@su...> - 2003-01-19 14:08:07
|
Hi Tim, > > Phil, I'm happy with the syntax you suggested; if Tim likes it then the > > two of you can sort out who writes the code and who checks it. > > Of course I'm more than happy if Phil alters the options code, being more familiar with it, > but if you're (Phil) too busy I'll give it a crack and follow the style. Please let me know > what you prefer. I'm sure I'm less busy than a sysadmin must be! I'll make the necessary changes to the Directive parsing code and let you know when I've finished so that you can write the rest. Phil |
From: Tim S. <ts...@di...> - 2003-01-19 00:24:24
|
Hi On Sat, 18 Jan 2003 11:13:43 -0600 (CST) Bruce Allen <ba...@gr...> wrote: > Hi Phil, > > > How about something like: > > > > /dev/hda -M exec "/usr/sbin/smartcl -a %s" > > > > It looks good to me. > > > If we're going to allow the user to modify the behaviour of -m with four > > arguments to -M ('once', 'daily', 'diminishing', and 'test') then I'd prefer > > we stick with that convention and add a fifth argument rather than a separate > > Directive. > > > > I wasn't sure about the usefulness of '%s', but I've just realised that it > > is necessary if we are to allow Directives to be used with DEVICESCAN as Tim > > suggested (I think that's a good idea, btw.). > > Actually I agree that %s is needed, but don't agree with the reason why. > It's only needed to indicate where in the command line argument for the > program to be execed the device name should appear. Eg: > /usr/sbin/smartctlreplacement %s -a takes -b arguments -c afterwards > /usr/sbin/dougsscsiutility -a takes -b device -c name -d %s -e midway > > But the %s is NOT needed for DEVICESCAN, since internally we always know > what device we are concerned with. But how does the user specify where they want the device name to be inserted into the exec string, without the %s? I agree that in the case of specific device lines in smartd.conf, the user could hard code the same device name into the exec string (bit yukky IMO), but in the case of DEVICESCAN neither the user nor the called script knows which device tripped the email unless it can be passed as a parameter... Best Tim -- Tim Southerwood Website: http://www.dionic.net/ email: ts@DIESPAMDIE.dionic.net (remove DIESPAMDIE. to get address) |
From: Bruce A. <ba...@gr...> - 2003-01-19 02:46:56
|
Hi Tim, > > > I wasn't sure about the usefulness of '%s', but I've just realised that it > > > is necessary if we are to allow Directives to be used with DEVICESCAN as Tim > > > suggested (I think that's a good idea, btw.). > > > > Actually I agree that %s is needed, but don't agree with the reason why. > > It's only needed to indicate where in the command line argument for the > > program to be execed the device name should appear. Eg: > > /usr/sbin/smartctlreplacement %s -a takes -b arguments -c afterwards > > /usr/sbin/dougsscsiutility -a takes -b device -c name -d %s -e midway > > > > But the %s is NOT needed for DEVICESCAN, since internally we always know > > what device we are concerned with. > > But how does the user specify where they want the device name to be > inserted into the exec string, without the %s? I completely agree with this justification for having %s. > I agree that in the case of specific device lines in smartd.conf, the > user could hard code the same device name into the exec string (bit > yukky IMO), but in the case of DEVICESCAN neither the user nor the > called script knows which device tripped the email unless it can be > passed as a parameter... I'm still confused by this latter remark. Since I agree that we need %s for the reason given previously, this is beating a dead horse. So here goes. Supppose that we didn't have the previous reason for including %s. Suppose that we always have (for instance) the convention that the device name was inserted at the end of the exec string. Then there would be no need for %s. Since, within the smartd code, each time that we detect a problem with a device, we ALREADY have the device name internally in cfg->name. So smartd would just do: sprintf(cmdline,"%s %s", users_argument_to_-M_exec, cfg->name); system(cmdline); Thus, the ONLY reason for having %s is the one given above -- that we need a way to indicate where in the command to be execed the device name should go. Cheers, Bruce |
From: Tim S. <ts...@di...> - 2003-01-19 00:11:05
|
Hi Bruce,Phil,Doug On Fri, 17 Jan 2003 15:23:24 -0600 (CST) Bruce Allen <ba...@gr...> wrote: > > How about: user can request the output of an arbitrary program > > to be appended in case of smartd generating an email? > > I think this is OK -- but dangerous. > > It means you need to handle arbitrary length output. And it means that > you need to handle gracefully the case where the arbitrary program doesn't > terminate, expects a terminal device as input or output, etc. And it's > then very important to deal cleanly with both stdout and stderr from the > arbitrary program. > > So it's fine -- just be careful to handle the error cases cleanly. This is true. Arbitrary length output should be handled upto a point (that is truncate output, not blow up, if the length goes too crazy), and perhaps a timeout on the command. Then again I don't feel *too* worried because in theory in this case, user=sysamin if they're setting up a smartd daemon. In other words, we should protect smartd against reasonable scenarios, but the sysadmin is expected to test their deployment if they chose to add random scripts to be invoked by smartd which is not going to be the default behaviour. I'll do my best to be solid... > > Now the user can do what they like by writing a custom wrapper - > > perhaps running "sginfo -d -e" (gets errors+defects list) > > (from sg_utils package) if the device is SCSI or running > > smartctl -a if it's ATA. It should be a more flexible approach. > > Since Doug Gilbert (author of sg_utils) is one of the smartmontools > developers, we could also ask him to copy the relevant "sginfo -d -e" code > into smartctl (:-). Really - small world. I was really impressed with sg_utils. I wait and see what happens :-) > In fact there IS a standard way to have .spec files build the code in > places like /tmp or /var/tmp that are world-writetable. It's just that I > don't know how to do it. And when I've tried it's failed. Do you mean the "BuildRoot" option? This is usually in the spec file (must test mine) but it only pertains to where "make install" dumps stuff. I think where the code is unpacked, make'd and the RPMs written in usually governed by the rpm environment supplied by the distribution vendor and optionally overidden by the user's own rpmrc and rpmmacro preferences. It is possible to specify these in the spec file, but not usually desireable as the user has the power to shape their rpm build environment to work for them anyway. Are we thinking about the same things here? > > I will double check what I did before I try submitting any changes to CVS. > > I already put part of your Makefile change into CVS (by accident, but I'll > leave it there.) OK - many thanks :-) > > If you could take a crack at getting the .spec file to include the right > "general user" invokations I'd be grateful. I will review it certainly - there may be a limit as to how far it is "correct" to go by convention. I usually aim to be as conventional as possible. > (on the subject of DEVICESCAN taking options) > > Guess it needs looking at in detail - I'm not very conversant with > > most of the codebase, can't really comment yet. Would be nice to do > > though :-) > > At least add it into the TODO file. OK. <snip> > > > > > > Should we add a -v options of 9,seconds for these disks? It's > > trival. > > > > Or maybe a map file included with smartmontools? Some simple > > format that could apply correction scalings to certain attributes > > on named models of disks? That way the smartd.conf could be generic across > > many machines despite disk model variations... Any good? > > I suspect it's too much work. With a dozen active disk vendors releasing > new disks models weekly, I think we could never keep up. [But of course if > you volunteer to add the code and maintain the map file.... well in that > case it's fine with me!] Most true. I wasn't sure that smartmontools should include a definitive map, but perhaps just the more common exceptions as people report them. I mainly intended it to be somewhere for the local site packager/admin to be able to put all of their bad cases in, thus not having to have exceptions in some of the smartd.conf files depending on the machine it's on. I'm willing to recieve reports and add odd scaling factors on a best efforts basis. Or perhaps the package should just include it as a attribute-map.local file and make it clear it's for local rescaling of errant attributes. It was an off the wall suggestion and I move to relegate it to the TODO as a "maybe - warrenting further discussion" - at least until I've had a chance to (re)implement some more directly useful patches as discussed. So far attr #9 is the only one to bite me - and I suspect that there will be less and less disks which exhibit weird behaviour here over time. > > > Very nice. I gather that your systems are not very homogeneous? > > > > Oooh nooo. We tend to buy in batches; then some of those go slightly > > variant when broken bits are replaced. Even servers tend to get > > bought in lots of 10-ish depending on the deal our boss can > > torture the vendor for. > > OK, that's good. Our computing clusters (I've built three) have all been > 100% homogeneous. It's the only way to go when the number of > machines/person is of order 100 or more. When fully deployed at my place, I hope to have it checking some several dozen different model/make combos. Our Student Lab PCs where I have it on test represent a fairly small set of differing hardware, but our staff machines and servers - oh boy... ;-0 -- Tim Southerwood Website: http://www.dionic.net/ email: ts@DIESPAMDIE.dionic.net (remove DIESPAMDIE. to get address) |
From: Douglas G. <do...@to...> - 2003-01-19 00:22:22
|
Tim Southerwood wrote: > Hi Bruce,Phil,Doug > > <snip/> > >>>Now the user can do what they like by writing a custom wrapper - >>>perhaps running "sginfo -d -e" (gets errors+defects list) >>>(from sg_utils package) if the device is SCSI or running >>>smartctl -a if it's ATA. It should be a more flexible approach. >> >>Since Doug Gilbert (author of sg_utils) is one of the smartmontools >>developers, we could also ask him to copy the relevant "sginfo -d -e" code >>into smartctl (:-). > > > Really - small world. I was really impressed with sg_utils. I wait and > see what happens :-) Tim, Glad you found sg_utils useful. Getting the defects list was one reason why I ported scsiinfo to sginfo. The SCSI_IOCTL_SEND_COMMAND used by scsiinfo (and smartctl) has a PAGE_SIZE (4 KB) limit which is too small for defect list in many cases. So to implement reading defect lists solidly in smartmontools an sg device needs to be used. That in turn means mapping a disk device (e.g. /dev/sdc) to the corresponding sg device. So a fare amount of fiddling will be involved. Doug Gilbert |
From: Bruce A. <ba...@gr...> - 2003-01-19 02:39:33
|
Hi Doug, > >>>Now the user can do what they like by writing a custom wrapper - > >>>perhaps running "sginfo -d -e" (gets errors+defects list) > >>>(from sg_utils package) if the device is SCSI or running > >>>smartctl -a if it's ATA. It should be a more flexible approach. > >> > >>Since Doug Gilbert (author of sg_utils) is one of the smartmontools > >>developers, we could also ask him to copy the relevant "sginfo -d -e" code > >>into smartctl (:-). > > > > > > Really - small world. I was really impressed with sg_utils. I wait and > > see what happens :-) > > Glad you found sg_utils useful. Getting the defects list was one > reason why I ported scsiinfo to sginfo. The SCSI_IOCTL_SEND_COMMAND > used by scsiinfo (and smartctl) has a PAGE_SIZE (4 KB) limit which is > too small for defect list in many cases. > > So to implement reading defect lists solidly in smartmontools an sg > device needs to be used. That in turn means mapping a disk device > (e.g. /dev/sdc) to the corresponding sg device. So a fare amount of > fiddling will be involved. I'm ignorant enough about scsi to not even know exactly what this means. So this may be a Really Dumb (TM) question. But could this be accomplished at fd=open(path, flags) time by using some "other" path than the normal /dev/sd[a-z] one? I think it would be really nice to have this functionality in smarctl. I guess that "-e" is something like the --log=error for ATA disks, and "-d" has no correspondent for ATA disks. Cheers, Bruce > |
From: Bruce A. <ba...@gr...> - 2003-01-19 02:30:16
|
Hi Tim, > > So it's fine -- just be careful to handle the error cases cleanly. > > This is true. Arbitrary length output should be handled upto a point > (that is truncate output, not blow up, if the length goes too crazy), > and perhaps a timeout on the command. Then again I don't feel *too* > worried because in theory in this case, user=sysamin if they're > setting up a smartd daemon. In other words, we should protect smartd > against reasonable scenarios, but the sysadmin is expected to test > their deployment if they chose to add random scripts to be invoked by > smartd which is not going to be the default behaviour. I'll do my best > to be solid... OK, that's the right approach. > > In fact there IS a standard way to have .spec files build the code in > > places like /tmp or /var/tmp that are world-writetable. It's just that I > > don't know how to do it. And when I've tried it's failed. > > Do you mean the "BuildRoot" option? I think that's what I tried -- and what failed. Perhaps for the reasons that you explained -- it only the target path for make install, not for unpacking and building. Anyway, if you can fix it to make rpm -ba runnable by a regular non-root user, that would be wonderful. This is usually in the spec file > (must test mine) but it only pertains to where "make install" dumps > stuff. I think where the code is unpacked, make'd and the RPMs written > in usually governed by the rpm environment supplied by the > distribution vendor and optionally overidden by the user's own rpmrc > and rpmmacro preferences. It is possible to specify these in the spec > file, but not usually desireable as the user has the power to shape > their rpm build environment to work for them anyway. > > Are we thinking about the same things here? Yup! If you can figure out how to specify the default rpm* macros in the spec file that build (say) under /tmp/smartmontools or under /var/tmp or some other world-writable place, that would be nice. > > If you could take a crack at getting the .spec file to include the right > > "general user" invokations I'd be grateful. > > I will review it certainly - there may be a limit as to how far it is > "correct" to go by convention. I usually aim to be as conventional as > possible. I agree with this. And I think there is a conventional way to make things buildable by normal users in a .spec file -- I just don't know what it is, and my BuildRoot experiments failed to accomplish this. [Regarding DEVICESCAN directives...] > > At least add it into the TODO file. > > OK. I think I can probably do the DEVICESCAN Directive scanning pretty easily, but need to really check the code before I commit to doing it myself. > Most true. I wasn't sure that smartmontools should include a > definitive map, but perhaps just the more common exceptions as people > report them. I mainly intended it to be somewhere for the local site > packager/admin to be able to put all of their bad cases in, thus not > having to have exceptions in some of the smartd.conf files depending > on the machine it's on. I'm willing to recieve reports and add odd > scaling factors on a best efforts basis. Or perhaps the package should > just include it as a attribute-map.local file and make it clear it's > for local rescaling of errant attributes. > > It was an off the wall suggestion and I move to relegate it to the > TODO as a "maybe - warrenting further discussion" - at least until > I've had a chance to (re)implement some more directly useful patches > as discussed. Fine -- I do like the idea -- I just shudder at the work involved in keeping it up-to-date. Perhaps an intermediate step might be to maintain a human-readable file of disk models and comments about the various smartd/smartctl options that they need. Cheers, Bruce |
From: Tim S. <ts...@di...> - 2003-01-19 12:30:02
|
Hi Bruce On Sat, 18 Jan 2003 20:29:56 -0600 (CST) Bruce Allen <ba...@gr...> wrote: > > Yup! If you can figure out how to specify the default rpm* macros in the > spec file that build (say) under /tmp/smartmontools or under /var/tmp or > some other world-writable place, that would be nice. > The BuildRoot is specified conventially, is usually of the form: Buildroot: %{_tmppath}/%{name}-build.root or something like that. I did mis-specify that so it will be corrected. As to where the build tree (/usr/src/<distro-dep>/BUILD) and the resultant RPMS, SRPMS go, we shouldn't try to override that. Most users building RPMS on their own systems, if they're not doing it as root, chown the entire /usr/src tree to them. In other cases, they set up their own rpm environment to place bits of the RPM tree where they want. If we try to override too much it can interfere with the latter case. I think you were just talking about teh BuildRoot bit which I did mess up in a moment of madness, just wanted to be clear :-) Best Tim -- Tim Southerwood Website: http://www.dionic.net/ email: ts@DIESPAMDIE.dionic.net (remove DIESPAMDIE. to get address) |
From: Bruce A. <ba...@gr...> - 2003-01-20 15:54:57
|
Hi Tim, > > Yup! If you can figure out how to specify the default rpm* macros in the > > spec file that build (say) under /tmp/smartmontools or under /var/tmp or > > some other world-writable place, that would be nice. I spent a little while fooling around with this yesterday, and unfortunately did not resolve it. The goal is twofold: (1) to have a very conventional .spec file that lets non-root users do rpm -ba on their systems. I agree with you that the .spec file should be as conventional as possible. (2) to allow me or other smartmontools developers to do "make release" when logged in as non-root users of their systems. This second goal would make my life easier and would probably help other developers to easily generate releases. My assumption is that the conventional RPM build area (/usr/src/redhat) is NOT writable by non-root users. So particulary to implement (2) above, I'd like the RPM-building process triggered by "make release" to happen, if possible, in a area that is writeable by a normal user, for example a temporary subdirectory of sm5/. Here's what I tried (it failed!); perhaps it's helpful: I started by looking at this documentation: http://www.rpm.org/max-rpm/s1-rpm-anywhere-different-build-area.html which unfortunately is not (I think) up-to-date anymore. > The BuildRoot is specified conventially, is usually of the form: > > Buildroot: %{_tmppath}/%{name}-build.root I did this in the .spec file, exactly as above. Then, based on the documentation above, I modified the "make release" target of the Makefile as follows: (a) defined smb=`pwd`/rpmbuildroot/ near the top of Makefile (b) for testing, commented out the two lines starting ". cvs-script" (c) replaced (this is diff output) < mv -f $(pkgname).tar.gz /usr/src/redhat/SOURCES/ < rpm -ba smartmontools.spec < mv /usr/src/redhat/RPMS/i386/$(pkgname)*.rpm . < mv /usr/src/redhat/SRPMS/$(pkgname)*rpm . < rm -f /usr/src/redhat/SOURCES/$(pkgname).tar.gz with > rm -rf $(smb) > mkdir -p $(smb)/BUILD $(smb)/RPMS/i386 $(smb)/SOURCES $(smb)/SPECS $(smb)/SRPMS > mv -f $(pkgname).tar.gz $(smb)/SOURCES/ > rpm --buildroot=$(smb) -ba smartmontools.spec > mv $(smb)/RPMS/i386/$(pkgname)*.rpm . > mv $(smb)/SRPMS/$(pkgname)*rpm . > rm -rf $(smb) [I also tried replacing "rpm" above by "rpmbuild" based on the results of some google searches.] This failed to work. The rpm build process still takes place in /usr/src/redhat, and fails because I am not running as root. The file /var/tmp/rpm-tmp.7200 shows that the --buildroot option has the following effects: [ballen@lap sm5]$ more /var/tmp/rpm-tmp.7200 #!/bin/sh RPM_SOURCE_DIR="/usr/src/redhat/SOURCES" RPM_BUILD_DIR="/usr/src/redhat/BUILD" RPM_OPT_FLAGS="-O2 -march=i386 -mcpu=i686" RPM_ARCH="i386" RPM_OS="linux" export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_DOC_DIR="/usr/share/doc" export RPM_DOC_DIR RPM_PACKAGE_NAME="smartmontools" RPM_PACKAGE_VERSION="5.1" RPM_PACKAGE_RELEASE="4" export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE RPM_BUILD_ROOT="/home/ballen/projects/SF/sm5/rpmbuildroot" export RPM_BUILD_ROOT So in spite of my efforts to use my own SOURCE/BUILD/... directories it appears that --buildroot is not having the desired effect. I hope you understand this better than I do. The documentation for RPM is hard for me to follow and the code itself doesn't seem to follow it as closely as one would hope. [Or I am just being dumb and not doing the right thing.] Cheers, Bruce |
From: Tim S. <ts...@do...> - 2003-01-20 17:58:19
|
Hi Bruce On Mon, 20 Jan 2003 09:54:42 -0600 (CST) Bruce Allen <ba...@gr...> jiggled the electrons to say: > So in spite of my efforts to use my own SOURCE/BUILD/... directories > it appears that --buildroot is not having the desired effect. > > I hope you understand this better than I do. The documentation for > RPM is hard for me to follow and the code itself doesn't seem to > follow it as closely as one would hope. [Or I am just being dumb and > not doing the right thing.] > > Cheers, > Bruce > No, that's not enough - now I understand what you're doing, you might try a modification of my setup: make 2 files in your homedir: ~/.rpmrc **********************************CUT macrofiles: /usr/lib/rpm/macros:/usr/lib/rpm/%{_target}/macros:/usr/lib/rpm/suse_macros:/etc/rpm/macros.specspo:/etc/rpm/macros:/etc/rpm/%{_target}/macros:~/.rpmmacros **********************************CUT Yep - that's all one line: actuall, you don't want exactly that - rather do a: rpm --showrc | grep macrofiles, shove the output in the ~/.rpmrc file and make sure you append a :~/.rpmmacros to the end as you see above. Then make a ~/.rpmmacros ***********CUT %_install_langs en_GB:en %_topdir /vol/source/%{name}/%{version}/linux %_rpmdir %{_topdir}/RPMS %_sourcedir %{_topdir}/SOURCES %_specdir %{_topdir}/SPECS %_srcrpmdir %{_topdir}/SRPMS %_buildir %{_topdir}/BUILD/ %_packager Tim Southerwood <ts...@do...> %_signature gpg %_gpg_name Tim J Southerwood <ts...@do...> %_gpg_path /homes/ts/.gnupg ************CUT And adjust as required - esp: topdir, point that somewhere writeable (homedir?) and lose the %{name} and %{version} bits - thats just our weird setup. If you do the gpg bits too, then you can sign the packages with rpm --resign for extra ponceyness(!). If you don't want that lot as your rpm default, it's possible to call .rpmrc something else and invoke it in the "make release" bit by rpm --rcfile <somercfile> --restofstuff Hope that helps. Cheers Tim -- Mr Tim J Southerwood CSG, Dept of Computing, Imperial College, London Email personal: ts...@di... work: ts...@do... Tel home: 020-866-17388 mobile: 07949-487179 work: 020-759-48392 |
From: Bruce A. <ba...@gr...> - 2003-01-21 14:51:00
|
Hi Tim, Thanks very much for your suggestions. Here is my latest attempt at a non-root make release target, based on what you said. > If you don't want that lot as your rpm default, it's possible to call > .rpmrc something else and invoke it in the "make release" bit by rpm > --rcfile <somercfile> --restofstuff As I said, the goal is to keep whatever RPM macros and rpmrc settings the user has, and to ONLY replace the working directories with ones below the current sm5/ directory. I'm still trying to implement this -- and still having trouble. Here's what I tried (and how it failed): In the Makefile, I have added: smb=`pwd`/rpmbuildroot and here is the relevant part of the make release target: mkdir -p $(smb)/BUILD $(smb)/RPMS/i386 $(smb)/SOURCES $(smb)/SPECS $(smb)/SRPMS mv -f $(pkgname).tar.gz $(smb)/SOURCES/ echo "macrofiles: temprpmmacros" > temprpmrc echo "%_topdir $(smb)" > temprpmmacros echo "%_rpmdir %{_topdir}/RPMS" >> temprpmmacros echo "%_sourcedir %{_topdir}/SOURCES" >> temprpmmacros echo "%_specdir %{_topdir}/SPECS" >> temprpmmacros echo "%_srcrpmdir %{_topdir}/SRPMS" >> temprpmmacros echo "%_buildir %{_topdir}/BUILD" >> temprpmmacros rpmbuild --rcfile temprpmrc:/usr/lib/rpm/rpmrc:/etc/rpmrc:~/.rpmrc -ba smartmontools.spec So when I run this, the contents of the two temprpm* files are: :::::::::::::: temprpmrc :::::::::::::: macrofiles: temprpmmacros :::::::::::::: temprpmmacros :::::::::::::: %_topdir /home/ballen/projects/SF/sm5/rpmbuildroot %_rpmdir %{_topdir}/RPMS %_sourcedir %{_topdir}/SOURCES %_specdir %{_topdir}/SPECS %_srcrpmdir %{_topdir}/SRPMS %_buildir %{_topdir}/BUILD The argument to --rcfile is based on the following from the rpm man page: --rcfile FILELIST Each of the files in the colon sepa- rated FILELIST is read sequentially by rpm for configuration informa- tion. Only the first file in the list must exist, and tildes will be expanded to the value of $HOME. The default FILELIST is /usr/lib/rpm/rpmrc:/etc/rpmrc:~/.rpmrc. The idea is to keep exactly whatever the user's default macros and rpmrc settings are, and to just tweak the working directory but nothing else. Here is how "make release" fails: <deleted output> rpmbuild --rcfile temprpmrc:/usr/lib/rpm/rpmrc:/etc/rpmrc:~/.rpmrc -ba smartmontools.spec error: Unable to open /etc/rpmrc for reading: No such file or directory. make: *** [release] Error 1 Note that this CONTRADICTS the man page which explicitly says that only the first file in the list must exist. Sigh. Any suggestions? Bruce |
From: Bruce A. <ba...@di...> - 2003-01-20 19:54:25
|
Hi Tim, Thanks very much for the helpful comments and guidance. > > So in spite of my efforts to use my own SOURCE/BUILD/... directories > > it appears that --buildroot is not having the desired effect. > No, that's not enough - now I understand what you're doing, you might try a > modification of my setup: > > make 2 files in your homedir: > > ~/.rpmrc > **********************************CUT > macrofiles: /usr/lib/rpm/macros:/usr/lib/rpm/%{_target}/macros:/usr/lib/rpm/suse_macros:/etc/rpm/macros.specspo:/ etc/rpm/macros:/etc/rpm/%{_target}/macros:~/.rpmmacros > **********************************CUT > > Yep - that's all one line: actuall, you don't want exactly that - rather do a: > > rpm --showrc | grep macrofiles, shove the output in the ~/.rpmrc file and make sure you append a :~/.rpmmacros to the end as you see > above. > > Then make a ~/.rpmmacros > ***********CUT > %_install_langs en_GB:en > %_topdir /vol/source/%{name}/%{version}/linux > %_rpmdir %{_topdir}/RPMS > %_sourcedir %{_topdir}/SOURCES > %_specdir %{_topdir}/SPECS > %_srcrpmdir %{_topdir}/SRPMS > %_buildir %{_topdir}/BUILD/ > %_packager Tim Southerwood <ts...@do...> > %_signature gpg > %_gpg_name Tim J Southerwood <ts...@do...> > %_gpg_path /homes/ts/.gnupg > ************CUT > > And adjust as required - esp: topdir, point that somewhere writeable (homedir?) and lose the %{name} and %{version} > bits - thats just our weird setup. > > If you do the gpg bits too, then you can sign the packages with rpm --resign for extra ponceyness(!). > > If you don't want that lot as your rpm default, it's possible to call .rpmrc something else and > invoke it in the "make release" bit by rpm --rcfile <somercfile> --restofstuff If possible, I would like a method that by default builds *everything* underneath the current working directory, which in virtually all cases will be /sm5, but ideally without creating any extra files or requiring that the developers have particular .rpmrc set-ups. So modifying .rpmrc for myself wouldn't be a good general solution. Do you know if there are command-line arguments to rpm that could be used for this (ie to set topdir, rpmdir, sourcedir, specdir, and so on)? It appears that --buildroot is not what's needed, or not enough. The second alternative that you suggest, using rpm --rcfile <somercfile> --restofstuff IS a way of doing this, provided that I actually create the <somercfile> within the Makefile, which I can do using a series of "echo stuff > somercfile" commands within the Makefile. But do you know if the contents of <somercfile> are used to *supplement* the contents of ~/.rpmrc or to *replace* them? In the latter case, it means that all the user-specific information in ~/.rpmrc is lost, which is probably Not Good. If you don't know the answer offhand, I'll do a few experiments to figure it out for myself. Thanks again. I am looking forward to running "make release" as an ordinary user... Cheers, Bruce |
From: Tim S. <ts...@do...> - 2003-01-17 18:33:35
|
On Tue, 14 Jan 2003 14:32:28 -0600 (CST) Bruce Allen <ba...@di...> jiggled the electrons to say: > > I'd say we keep it simple: > > -- allow multiple -M Directives > -- each -M Directive takes a single argument > -- if conflicting Directives are given (-M once -M daily) > then the last one is the one that actually applies Seems good. I'll mention a thought about the option to include the contents of smartctl in another mail. <snip> > unsigned char runsmartctl; Please refer to soon to follow email dealing with this in more detail. Cheers Tim -- Mr Tim J Southerwood CSG, Dept of Computing, Imperial College, London Email personal: ts...@di... work: ts...@do... Tel home: 020-866-17388 mobile: 07949-487179 work: 020-759-48392 |