It just installs sshguard and that’s it. No log integration, no firewall integration, no init script… :( I use Shorewall, and it seems there is no way for me to use this tool. I would have to write my own init script, and learn how to do that first. (I’m not willing to become a Gentoo maintainer/admin just yet. ;) I also would have to hack Shorewall in a way… No chance, I barely manage to configure it properly. Reproducible: Always Steps to Reproduce: 1. emerge sshguard # version doesn’t matter right now Actual Results: >> Installing (1 of 1) app-admin/sshguard-1.4 * checking 5 files for package collisions --- /usr/ --- /usr/sbin/ >>> /usr/sbin/sshguard --- /usr/share/ --- /usr/share/doc/ >>> /usr/share/doc/sshguard-1.4/ >>> /usr/share/doc/sshguard-1.4/whitelistfile.example.bz2 >>> /usr/share/doc/sshguard-1.4/README.bz2 >>> /usr/share/doc/sshguard-1.4/Changes.bz2 --- /usr/share/man/ --- /usr/share/man/man8/ >>> /usr/share/man/man8/sshguard.8.bz2 Expected Results: Depending on installed supported software, the ebuild should trigger integration. It should also install an init script. Configuration or hacking should only be necessary for setups which are not (yet) supported by upstream. Where sensible, it should show a message about remaining things that can only be configured manually. (E.g. checking and uncommenting the generated sshd part in metalog.conf, in case there already is a configured sshd logging.)
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.
