Summary: | app-admin/sshguard lacks sensible system integration | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Navid Zamani <navid.zamani> |
Component: | [OLD] Server | Assignee: | Gentoo Netmon project <netmon> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | CC: | bugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Navid Zamani
2010-12-18 11:07:03 UTC
I guess it would be a good idea to check how other distributions have solved this… An init script for 1.4 would be very inappropriate, since it expects you to hook it into your logger (syslog-ng on most gentoo installs). This is very well documented on their website. 1.5 will have a different approach (you define which logs it should keep track on) and would benefit from such a init script, but please let 1.5 come out first and see how maintainer handles it. I'll still keep it open so maintainer can decide what to do. (In reply to comment #2) > An init script for 1.4 would be very inappropriate, since it expects you to > hook it into your logger (syslog-ng on most gentoo installs). This is very well documented on their website. Have you checked that what you are saying has any relation to reality? The documentation on how to get it working at boot tells you *to use a init script*! How else would ho run it with metalog? Where would you start the “tail … | sshguard” pipe otherwise? 1. Metalog: Done. → http://www.sshguard.net/docs/setup/getlogs/metalog-multilog/ 2. What does start that tail at boot? → http://www.sshguard.net/docs/setup/getlogs/raw-file/ 3. The FAQ has the answer: http://www.sshguard.net/docs/faqs/#sshguard-start-at-boot Plus, even ignoring all of the above, it’s still a automatable process that does not contain big user decisions that would prevent anyone from automating it with one or two parameters. If you don’t wanna do it, and you’re not getting money for it, that’s OK, just admit it. But this is lame. > > 1.5 will have a different approach (you define which logs it should keep track > on) and would benefit from such a init script, but please let 1.5 come out > first and see how maintainer handles it. I'll still keep it open so maintainer > can decide what to do. > Sorry for the late response. I forgot to CC myself :-( (In reply to comment #3) > Have you checked that what you are saying has any relation to reality? > The documentation on how to get it working at boot tells you *to use a init > script*! How else would ho run it with metalog? Where would you start the > “tail … | sshguard” pipe otherwise? With the recommended logger in Gentoo it's probably easiest to follow this guide: http://www.sshguard.net/docs/setup/getlogs/syslog-ng/ An init script will not be needed for this (but for 1.5). Init scripts are for "lesser" loggers with the 1.4 approach. Let me know if you have any problems (In reply to comment #4) > An init script will not be needed for this (but for 1.5). Init scripts are for > "lesser" loggers with the 1.4 approach. Let me know if you have any problems I don’t quite like you saying metalog is a “lesser” logger… And well, if Gentoo offers freedom of choice, but things only actually work with the “recommended” choice, that’s not much freedom, is it? ;) Hmm, I think metalog is perfectly fine with calling applications on log events. But I fear it might start a new process on *every* event instead of piping to it… I would check this, but fact is, I lost interest after seeing I would have to practically write the thing myself to get it working. I just told my Internet router to map 2222 (Internet) to 22 (dmz). Which won’t solve someone really attempting to crack the thing, but apparently not a single one of the bots tried non-standard ports. So to me it’s rather… meh… right now. Should I close it as “I don’t care” or as “Maintainer doesn’t care”, as you obviously haven’t much interest in it either? (But unless I throw money at you and you accept, I am better OK with that anyway. ;) (In reply to comment #5) > (In reply to comment #4) > > An init script will not be needed for this (but for 1.5). Init scripts are for > > "lesser" loggers with the 1.4 approach. Let me know if you have any problems > > I don’t quite like you saying metalog is a “lesser” logger… > And well, if Gentoo offers freedom of choice, but things only actually work > with the “recommended” choice, that’s not much freedom, is it? ;) Sorry, I didn't mean to offend Metalog in any way. I was kind of referring to syslog and older versions of syslog-ng that aren't able to pipe to applications. I don't say that you should run metalog; but i didn't know that you did when i said that the suggested didn't make much sense with syslog-ng and a separate init script. > > Hmm, I think metalog is perfectly fine with calling applications on log events. > But I fear it might start a new process on *every* event instead of piping to > it… > I would check this, but fact is, I lost interest after seeing I would have to > practically write the thing myself to get it working. I just told my Internet > router to map 2222 (Internet) to 22 (dmz). Which won’t solve someone really > attempting to crack the thing, but apparently not a single one of the bots > tried non-standard ports. > > So to me it’s rather… meh… right now. Should I close it as “I don’t > care” or as “Maintainer doesn’t care”, as you obviously haven’t much > interest in it either? (But unless I throw money at you and you accept, I am > better OK with that anyway. ;) I'm not a maintainer, I'm just really fond of this application. You could always use the 1.5 rc's (they're stable, I'd say) and then use the init script for that. We'll end up there some day soon anyway. (read up on "log sucker" at the web site) Hope you find a solution that works for you! Cheers Navid: Please try the ebuild attached in bug 351665 and give feedback so I can improve it. (In reply to comment #6) > Sorry, I didn't mean to offend Metalog in any way. LOL, you don’t have to be sorry, man. We’re good. :) > You could > always use the 1.5 rc's (they're stable, I'd say) and then use the init script > for that. We'll end up there some day soon anyway. (read up on "log sucker" at > the web site) (In reply to comment #7) > Please try the ebuild attached in bug 351665 and give feedback so I can > improve it. Thanks. :) I didn’t know a 1.5 ebuild existed. Back then I saw that log sucker stuff and that’s what I wanted, since you can use it for non-logger things too. Unfortunately I really lost interest. I’m in way too much stress right now, and I’m still in a heavy cold. Also things run fine as they are now. So I don’t think I will test that ebuild. Sorry. I would revoke being the bug reporter, if I could. P.S.: If the 1.5 ebuild includes a init script for the log sucker, then for me, this bug is moot anyway. I could close it. You decide. :) Oh, and thanks man. :) There's an ebuild in #351665 which addresses this issue, which really isn't a bug, rather a missing feature (apparent in 1.5 branch). I disagree, since a non-integrating software package is not really working at all. I mean what’s the difference to just manually compiling it? If it’s an ebuild, it should be integrated in Gentoo. But whatever. I don’t have money to throw at it, and you clearly don’t want to do what is the whole point of maintaining a package. So fuck it, I’m out. This is to stupid for me. |