On Fri, Jul 13, 2012 at 06:43:36PM -0700, Maciej Żenczykowski wrote: > On Fri, Jul 13, 2012 at 2:16 AM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Thu, Jul 12, 2012 at 06:25:13PM +0200, Jan Engelhardt wrote: > >> > >> On Thursday 2012-07-12 17:49, Pablo Neira Ayuso wrote: > >> >> +config NETFILTER_XT_TARGET_SYSRQ > >> >> + tristate '"SYSRQ" - remote sysrq invocation' > >> > > >> >I guess this is useful for user, eg. you can reboot your crashed > >> >system from your office in case that cheap comodity hardware without > >> >remote management tools (eg. HP's ILO or Dell's iDRAC). > >> > > >> >Still, I think that including this in Netfilter is a bit of abuse > >> >since this is out of the scope of providing some firewalling feature. > >> > >> David Miller has stated his opinion already last year, and he's > >> for the Netfilter variant: > >> http://markmail.org/message/d7kpczdbtpcxwli6 > > > > I think that affirmation is true in the context of: > > > > [PATCH]: Add Network Sysrq Support > > > > but not sure it's out of it. > > > > He probably prefered the Netfilter option because, comparing it to the > > Netfilter approach, it looks nicer. Well, just look at all those sysfs > > and proc interfaces he was proposing for that approach (it seems quite > > ugly to me). > > > > You can use the udp_encap hook (that Florian mentioned) plus some > > genetlink interface and little user-space tool to make it out of > > netfilter. Most of the xt_SYSRQ code can be reused and the genetlink > > interface plus one library can be added with little extra work. > > > > @David: just to put you into context. Jan is proposing to merge > > xt_SYSRQ into mainstream, we are discussing if it would be better to > > make it out of it (so people do not depend on the firewalling > > utilities to get it working) based on a different proposal described > > above. > > -- > > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > For this to be truly useful, it has to work when all of userspace is > dead and unresponsive (oom hell, swap hell, hdd disconnected, etc), > and as such from the moment the magic packet gets received, to the > command (reboot/etc) being executed it has to be a fully kernel based > solution - preferably within the network softirq. > > Anything relying on userspace (outside of initial configuration) is > not acceptable. So far, nobody mentioned the possibility any sort of user-space daemon ;-). That user-space tool would be used to configure it through genetlink outside of netfilter. That's all. And I think everybody here still think this is useful, what we're discussing is the nicer approach. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
