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 |