On Tuesday, December 27, 2005, at 06:34:51, Daniel Hartmeier wrote: > I'm not sure why you seem to consider a solution unprofessional simply > because it is hand-made or involves shell scripts. Is that because you > consider yourself able to write shell scripts, but not expertly, while > you wouldn't even try to write in another programming language?
I wrote that I can try. I think I will have to if there are no such progs :-) > All good software is hand-made, if there are any automatically generated > programs at all, they are only as good as their generating program, > which was hand-made in the first place. Even the most shiny, expensive, > and shrink-wrapped software package you can buy consists of hand-written > code. gosh, Daniel, I know that every program is/was hand-made but plenty of shell scripts working with other external progs with possibility of not working as you expected is in my opinion 'hand-made'. I look for sth which is complex and has all options combined together. And such a prog is for me good and professional software. I don't want to argue with you. If you feel that pieces of shell scripts combined with other progs written in c/perl/tcl/python or any other programming language are professional, that's good. For me it's not. That's why I asked ;-) > There's a serious profession[1] of people writing shell scripts, and it > would be silly to assume that any program is less professional because > it is implemented in shell script instead of, say, C. no, no, no. I didn't meant to make it so. I tried to tell that good software should be written in one language and in our case (PF + monitoring software) it should be the best if such monitoring sofware was strictly connected with PF. Don't you think so ? > None of these definitions would exclude a shell script from being a > 'professional solution' to this particular problem. Or any other > problem, in general, assuming the script was expertly written and > performed conforming to the standards of the profession. I agree. > Now take a look at one example of a suggested solution, which I assume > you have already seen while searching: > http://marc.theaimsgroup.com/?l=openbsd-pf&m=106883416904625&w=2 > If you're going to hire (according to the second and third definition > above) a programmer to write a C daemon doing something similar, you'll > have to provide precise specs that define what the program is supposed > to do. So, what should it do compared to the example script above? How > is the script not perfect, what other properties should the C program > have? Besides hiding implementation details from the non-technical reader > (who might not understand C source code but can read a script), who > might (possibly falsely) assume it does more things in a more clever way. In further part of message you told about nagios. It has several things which can be used in my 'quickly called professional' software (like ie. min and max time intervals between checking, notifications about state changing, max check attempts before changing state of object in nagios and service dependencies on hosts). > If it is more complex monitoring code you need, it's probably simpler to > extend a monitoring tool (like, say, nagios[3]) to do pf table > modifications, than re-implementing monitoring rules in an additional > daemon. If the monitoring code only needs to be as simple as "fetch a > test file through HTTP", again, why (and how) is the example script above > not completely sufficient? Firstly: your script has to be run with root privilege. IMHO better idea should be checking the status which is given by some tools/plugins/whatever we call it and on the basis of it to change tables in PF. If I think bad tell me ;) Secondly: I use nagios for almost all services and thought about such thing. But I should have to use 2 or 3 nagios procs cause nagios with whole bunch of plugins is very cpu-aware which is not the best idea for balancer. That's why I monitor all services on different host and try not to give more job to balancers ;) Anyway, thanks for your reply, Daniel. -- Sylwester S. Biernacki <[EMAIL PROTECTED]> X-NET, http://www.xnet.com.pl/
