From: Ben H. <ga...@gr...> - 2014-02-24 16:59:10
|
Hi, There are several different methods of connecting nagios to ganglia in our github repo: * https://github.com/ganglia/ganglia-web/tree/master/nagios * https://github.com/ganglia/ganglia-nagios-bridge * https://github.com/ganglia/ganglia_contrib/tree/master/nagios and I'm about to add a fourth, moving https://bitbucket.org/maplebed/ganglios into github instead of bitbucket (it wants to join its brethren). What would you all think of reorganizing the repo a bit to concentrate these things? Understandably the ganglia-web one can't be moved if it is to remain part of the web installation, though a pointer to it could be included in a centralized nagios-ganglia integration area. Does this deserve a top level repo, or does it belong in the ganglia-contrib repo? I lean towards making a 'nagios-integration' repo since it is clearly something that is often done and has several different methods. The argument for including it in ganglia-contrib could be made pretty easily though. Cheers, -ben |
From: Daniel P. <da...@po...> - 2014-02-24 19:43:17
|
On 24/02/14 17:59, Ben Hartshorne wrote: > Hi, > > There are several different methods of connecting nagios to ganglia in our > github repo: > * https://github.com/ganglia/ganglia-web/tree/master/nagios > * https://github.com/ganglia/ganglia-nagios-bridge > * https://github.com/ganglia/ganglia_contrib/tree/master/nagios > and I'm about to add a fourth, moving > https://bitbucket.org/maplebed/ganglios into github instead of bitbucket > (it wants to join its brethren). > > What would you all think of reorganizing the repo a bit to concentrate > these things? Understandably the ganglia-web one can't be moved if it is to > remain part of the web installation, though a pointer to it could be > included in a centralized nagios-ganglia integration area. > > Does this deserve a top level repo, or does it belong in the > ganglia-contrib repo? I lean towards making a 'nagios-integration' repo > since it is clearly something that is often done and has several different > methods. The argument for including it in ganglia-contrib could be made > pretty easily though. Just some comments: - it would be good to create a wiki page comparing them all - people often ask about the the potential to use Nagios-related stuff with Icinga and other related projects |
From: Ben H. <ga...@gr...> - 2014-02-24 23:39:32
|
I was planning on writing a README comparing them (so it's visible at the directory / repo level that houses all the various incarnations) but a wiki page might be better. I like the README because it's right there when you're browsing for the code but a wiki provides more flexibility. Maybe the README can just link to the wiki. Either way, +1 documentation and so on. :D I think I can write up a (slightly biased) comparison of most of them, but I've never used the ganglia-web nagios php one. Maybe Vladimir can write up that section when the scaffold is in place. -ben On Mon, Feb 24, 2014 at 11:43 AM, Daniel Pocock <da...@po...>wrote: > > > On 24/02/14 17:59, Ben Hartshorne wrote: > > Hi, > > > > There are several different methods of connecting nagios to ganglia in > our > > github repo: > > * https://github.com/ganglia/ganglia-web/tree/master/nagios > > * https://github.com/ganglia/ganglia-nagios-bridge > > * https://github.com/ganglia/ganglia_contrib/tree/master/nagios > > and I'm about to add a fourth, moving > > https://bitbucket.org/maplebed/ganglios into github instead of bitbucket > > (it wants to join its brethren). > > > > What would you all think of reorganizing the repo a bit to concentrate > > these things? Understandably the ganglia-web one can't be moved if it is > to > > remain part of the web installation, though a pointer to it could be > > included in a centralized nagios-ganglia integration area. > > > > Does this deserve a top level repo, or does it belong in the > > ganglia-contrib repo? I lean towards making a 'nagios-integration' repo > > since it is clearly something that is often done and has several > different > > methods. The argument for including it in ganglia-contrib could be made > > pretty easily though. > > > Just some comments: > > - it would be good to create a wiki page comparing them all > > - people often ask about the the potential to use Nagios-related stuff > with Icinga and other related projects > > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Ganglia-developers mailing list > Gan...@li... > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > |
From: Daniel P. <da...@po...> - 2014-02-25 09:20:13
|
On 25/02/14 00:39, Ben Hartshorne wrote: > I was planning on writing a README comparing them (so it's visible at > the directory / repo level that houses all the various incarnations) > but a wiki page might be better. I like the README because it's right > there when you're browsing for the code but a wiki provides more > flexibility. Maybe the README can just link to the wiki. > > Either way, +1 documentation and so on. :D > > I think I can write up a (slightly biased) comparison of most of them, > but I've never used the ganglia-web nagios php one. Maybe Vladimir > can write up that section when the scaffold is in place. This page was duplicated and refers to the ganglia-web solution for Nagios: https://github.com/ganglia/monitor-core/wiki/Integrating-Ganglia-with-Nagios https://github.com/ganglia/ganglia-web/wiki/Nagios-Integration I've started changing the version on monitor-core to be a summary page, it links to the document in the ganglia-web wiki and the other related projects Please feel free to add your comments in the table |
From: Ben H. <ga...@gr...> - 2014-03-01 21:59:58
|
I've changed my mind about reorganizing the repo. The correct way to summarize different approaches to the same problem is through documentation (aka the wiki) not repository organization. It makes sense to keep self contained projects (like ganglia-nagios-bridge) as its own repo for ease of forks and PRs and so on. I've made changes to both wiki pages Daniel mentions in the hope of making it easier for folks that are looking to solve this problem. All they need now is a little google juice; these pages are impossible to find via google. There are many other pages talking about nagios and ganglia that rank higher. Any suggestions? -ben On Tue, Feb 25, 2014 at 1:20 AM, Daniel Pocock <da...@po...> wrote: > On 25/02/14 00:39, Ben Hartshorne wrote: > > I was planning on writing a README comparing them (so it's visible at the > directory / repo level that houses all the various incarnations) but a wiki > page might be better. I like the README because it's right there when > you're browsing for the code but a wiki provides more flexibility. Maybe > the README can just link to the wiki. > > Either way, +1 documentation and so on. :D > > I think I can write up a (slightly biased) comparison of most of them, > but I've never used the ganglia-web nagios php one. Maybe Vladimir can > write up that section when the scaffold is in place. > > > This page was duplicated and refers to the ganglia-web solution for Nagios: > > > https://github.com/ganglia/monitor-core/wiki/Integrating-Ganglia-with-Nagios > > https://github.com/ganglia/ganglia-web/wiki/Nagios-Integration > > I've started changing the version on monitor-core to be a summary page, it > links to the document in the ganglia-web wiki and the other related projects > > Please feel free to add your comments in the table > > > > |
From: Daniel P. <da...@po...> - 2014-03-02 09:01:26
|
On 01/03/14 22:54, Ben Hartshorne wrote: > I've changed my mind about reorganizing the repo. The correct way to > summarize different approaches to the same problem is through documentation > (aka the wiki) not repository organization. It makes sense to keep self > contained projects (like ganglia-nagios-bridge) as its own repo for ease of > forks and PRs and so on. > > I've made changes to both wiki pages Daniel mentions in the hope of making > it easier for folks that are looking to solve this problem. All they need > now is a little google juice; these pages are impossible to find via > google. There are many other pages talking about nagios and ganglia that > rank higher. > > Any suggestions? There are still trac wikis about too It is a real hassle In Github, we can actually disable the wiki feature and refer everybody back to track if that is easier to manage On the other hand, github wikis have the github ACLs If we are going to keep the github wikis, we need to modify the menu links on ganglia.info to link into the right places, etc |
From: Vladimir V. <vl...@ve...> - 2014-03-03 02:05:32
|
I like the fact that Github Wiki's are just another Git repo. Perhaps we ought to figure out if we can use github pages to serve Wiki's directly e.g. something like wiki.ganglia.info Anyone know ? Vladimir On 03/02/2014 04:01 AM, Daniel Pocock wrote: > > On 01/03/14 22:54, Ben Hartshorne wrote: >> I've changed my mind about reorganizing the repo. The correct way to >> summarize different approaches to the same problem is through documentation >> (aka the wiki) not repository organization. It makes sense to keep self >> contained projects (like ganglia-nagios-bridge) as its own repo for ease of >> forks and PRs and so on. >> >> I've made changes to both wiki pages Daniel mentions in the hope of making >> it easier for folks that are looking to solve this problem. All they need >> now is a little google juice; these pages are impossible to find via >> google. There are many other pages talking about nagios and ganglia that >> rank higher. >> >> Any suggestions? > There are still trac wikis about too > > It is a real hassle > > In Github, we can actually disable the wiki feature and refer everybody > back to track if that is easier to manage > > On the other hand, github wikis have the github ACLs > > If we are going to keep the github wikis, we need to modify the menu > links on ganglia.info to link into the right places, etc > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Ganglia-developers mailing list > Gan...@li... > https://lists.sourceforge.net/lists/listinfo/ganglia-developers |
From: Nick S. <nfs...@gm...> - 2014-03-03 21:23:56
|
Why don't we convert the sourceforge trac wiki in to Jekyll pages and serve them via Github? --Nick. On Mon, Mar 3, 2014 at 2:05 AM, Vladimir Vuksan <vl...@ve...> wrote: > I like the fact that Github Wiki's are just another Git repo. > > Perhaps we ought to figure out if we can use github pages to serve > Wiki's directly e.g. something like > > wiki.ganglia.info > > Anyone know ? > > Vladimir > > On 03/02/2014 04:01 AM, Daniel Pocock wrote: > > > > On 01/03/14 22:54, Ben Hartshorne wrote: > >> I've changed my mind about reorganizing the repo. The correct way to > >> summarize different approaches to the same problem is through > documentation > >> (aka the wiki) not repository organization. It makes sense to keep self > >> contained projects (like ganglia-nagios-bridge) as its own repo for > ease of > >> forks and PRs and so on. > >> > >> I've made changes to both wiki pages Daniel mentions in the hope of > making > >> it easier for folks that are looking to solve this problem. All they > need > >> now is a little google juice; these pages are impossible to find via > >> google. There are many other pages talking about nagios and ganglia that > >> rank higher. > >> > >> Any suggestions? > > There are still trac wikis about too > > > > It is a real hassle > > > > In Github, we can actually disable the wiki feature and refer everybody > > back to track if that is easier to manage > > > > On the other hand, github wikis have the github ACLs > > > > If we are going to keep the github wikis, we need to modify the menu > > links on ganglia.info to link into the right places, etc > > > > > > > ------------------------------------------------------------------------------ > > Flow-based real-time traffic analytics software. Cisco certified tool. > > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > > Customize your own dashboards, set traffic alerts and generate reports. > > Network behavioral analysis & security monitoring. All-in-one tool. > > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > _______________________________________________ > > Ganglia-developers mailing list > > Gan...@li... > > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Ganglia-developers mailing list > Gan...@li... > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > -- gpg: using PGP trust model pub 4096R/1EE38BD9 2013-01-06 [expires: 2018-01-06] Key fingerprint = 3EE9 550D D9D8 DB65 58C2 B58D CE78 EC6C 1EE3 8BD9 uid Nicholas Satterly (Debian Key) <nfs...@gm...> sub 4096R/23804EE9 2013-01-06 [expires: 2018-01-06] |
From: Vladimir V. <vl...@ve...> - 2014-03-03 21:32:00
|
<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Works for me. Now we just need a volunteer :-D<br> <br> On 03/03/2014 04:23 PM, Nick Satterly wrote:<br> </div> <blockquote cite="mid:CAL...@ma..." type="cite"> <div dir="ltr">Why don't we convert the sourceforge trac wiki in to Jekyll pages and serve them via Github?<br> <div><br> </div> <div>--Nick.</div> </div> <div class="gmail_extra"><br> <br> <div class="gmail_quote">On Mon, Mar 3, 2014 at 2:05 AM, Vladimir Vuksan <span dir="ltr"><<a moz-do-not-send="true" href="mailto:vl...@ve..." target="_blank">vl...@ve...</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the fact that Github Wiki's are just another Git repo.<br> <br> Perhaps we ought to figure out if we can use github pages to serve<br> Wiki's directly e.g. something like<br> <br> <a moz-do-not-send="true" href="http://wiki.ganglia.info" target="_blank">wiki.ganglia.info</a><br> <br> Anyone know ?<br> <br> Vladimir<br> <div> <div class="h5"><br> On 03/02/2014 04:01 AM, Daniel Pocock wrote:<br> ><br> > On 01/03/14 22:54, Ben Hartshorne wrote:<br> >> I've changed my mind about reorganizing the repo. The correct way to<br> >> summarize different approaches to the same problem is through documentation<br> >> (aka the wiki) not repository organization. It makes sense to keep self<br> >> contained projects (like ganglia-nagios-bridge) as its own repo for ease of<br> >> forks and PRs and so on.<br> >><br> >> I've made changes to both wiki pages Daniel mentions in the hope of making<br> >> it easier for folks that are looking to solve this problem. All they need<br> >> now is a little google juice; these pages are impossible to find via<br> >> google. There are many other pages talking about nagios and ganglia that<br> >> rank higher.<br> >><br> >> Any suggestions?<br> > There are still trac wikis about too<br> ><br> > It is a real hassle<br> ><br> > In Github, we can actually disable the wiki feature and refer everybody<br> > back to track if that is easier to manage<br> ><br> > On the other hand, github wikis have the github ACLs<br> ><br> > If we are going to keep the github wikis, we need to modify the menu<br> > links on <a moz-do-not-send="true" href="http://ganglia.info" target="_blank">ganglia.info</a> to link into the right places, etc<br> ><br> ><br> > ------------------------------------------------------------------------------<br> > Flow-based real-time traffic analytics software. Cisco certified tool.<br> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer<br> > Customize your own dashboards, set traffic alerts and generate reports.<br> > Network behavioral analysis & security monitoring. All-in-one tool.<br> > <a moz-do-not-send="true" href="http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk</a><br> > _______________________________________________<br> > Ganglia-developers mailing list<br> > <a moz-do-not-send="true" href="mailto:Gan...@li...">Gan...@li...</a><br> > <a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/ganglia-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/ganglia-developers</a><br> <br> <br> </div> </div> ------------------------------------------------------------------------------<br> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.<br> With Perforce, you get hassle-free workflows. Merge that actually works.<br> Faster operations. Version large binaries. Built-in WAN optimization and the<br> freedom to use Git, Perforce or both. Make the move to Perforce.<br> <a moz-do-not-send="true" href="http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk</a><br> <div class="HOEnZb"> <div class="h5">_______________________________________________<br> Ganglia-developers mailing list<br> <a moz-do-not-send="true" href="mailto:Gan...@li...">Gan...@li...</a><br> <a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/ganglia-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/ganglia-developers</a><br> </div> </div> </blockquote> </div> <br> <br clear="all"> <div><br> </div> -- <br> <span style="font-family:courier new,monospace">gpg: using PGP trust model<br> pub 4096R/1EE38BD9 2013-01-06 [expires: 2018-01-06]<br> Key fingerprint = 3EE9 550D D9D8 DB65 58C2 B58D CE78 EC6C 1EE3 8BD9<br> uid Nicholas Satterly (Debian Key) <<a moz-do-not-send="true" href="mailto:nfs...@gm..." target="_blank">nfs...@gm...</a>><br> sub 4096R/23804EE9 2013-01-06 [expires: 2018-01-06]<br> <br> </span> </div> </blockquote> <br> </body> </html> |
From: Chris B. <chr...@gm...> - 2014-03-04 20:36:57
|
On 03/02/2014 09:05 PM, Vladimir Vuksan wrote: > I like the fact that Github Wiki's are just another Git repo. > > Perhaps we ought to figure out if we can use github pages to serve > Wiki's directly e.g. something like > > wiki.ganglia.info > > Anyone know ? I like the idea of docs.ganglia.info or whatever just being a git repo that uses whatever markup github automatically builds a pretty page out of. Along a similar vein, sphinx and readthedocs.org is also very nice. For example: http://www.opsschool.org/en/latest/ |
From: Peter P. <pet...@in...> - 2014-03-01 22:30:16
|
Actually, looking at the code, it looks the the message type is explicit, so you wouldn’t need any configuration: msg->version != EBT_ULOG_VERSION On Mar 1, 2014, at 1:54 PM, Ben Hartshorne <ga...@gr...> wrote: > I've changed my mind about reorganizing the repo. The correct way to summarize different approaches to the same problem is through documentation (aka the wiki) not repository organization. It makes sense to keep self contained projects (like ganglia-nagios-bridge) as its own repo for ease of forks and PRs and so on. > > I've made changes to both wiki pages Daniel mentions in the hope of making it easier for folks that are looking to solve this problem. All they need now is a little google juice; these pages are impossible to find via google. There are many other pages talking about nagios and ganglia that rank higher. > > Any suggestions? > > -ben > > > > On Tue, Feb 25, 2014 at 1:20 AM, Daniel Pocock <da...@po...> wrote: > On 25/02/14 00:39, Ben Hartshorne wrote: >> I was planning on writing a README comparing them (so it's visible at the directory / repo level that houses all the various incarnations) but a wiki page might be better. I like the README because it's right there when you're browsing for the code but a wiki provides more flexibility. Maybe the README can just link to the wiki. >> >> Either way, +1 documentation and so on. :D >> >> I think I can write up a (slightly biased) comparison of most of them, but I've never used the ganglia-web nagios php one. Maybe Vladimir can write up that section when the scaffold is in place. > > This page was duplicated and refers to the ganglia-web solution for Nagios: > > https://github.com/ganglia/monitor-core/wiki/Integrating-Ganglia-with-Nagios > > https://github.com/ganglia/ganglia-web/wiki/Nagios-Integration > > I've started changing the version on monitor-core to be a summary page, it links to the document in the ganglia-web wiki and the other related projects > > Please feel free to add your comments in the table > > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ > Ganglia-developers mailing list > Gan...@li... > https://lists.sourceforge.net/lists/listinfo/ganglia-developers |
From: Peter P. <pet...@in...> - 2014-03-01 22:33:25
|
Please ignore the non sequitur - I accidentally sent this reply to the wrong email thread. On Mar 1, 2014, at 2:30 PM, Peter Phaal <pet...@in...> wrote: > Actually, looking at the code, it looks the the message type is explicit, so you wouldn’t need any configuration: > > msg->version != EBT_ULOG_VERSION > > On Mar 1, 2014, at 1:54 PM, Ben Hartshorne <ga...@gr...> wrote: > >> I've changed my mind about reorganizing the repo. The correct way to summarize different approaches to the same problem is through documentation (aka the wiki) not repository organization. It makes sense to keep self contained projects (like ganglia-nagios-bridge) as its own repo for ease of forks and PRs and so on. >> >> I've made changes to both wiki pages Daniel mentions in the hope of making it easier for folks that are looking to solve this problem. All they need now is a little google juice; these pages are impossible to find via google. There are many other pages talking about nagios and ganglia that rank higher. >> >> Any suggestions? >> >> -ben >> >> >> >> On Tue, Feb 25, 2014 at 1:20 AM, Daniel Pocock <da...@po...> wrote: >> On 25/02/14 00:39, Ben Hartshorne wrote: >>> I was planning on writing a README comparing them (so it's visible at the directory / repo level that houses all the various incarnations) but a wiki page might be better. I like the README because it's right there when you're browsing for the code but a wiki provides more flexibility. Maybe the README can just link to the wiki. >>> >>> Either way, +1 documentation and so on. :D >>> >>> I think I can write up a (slightly biased) comparison of most of them, but I've never used the ganglia-web nagios php one. Maybe Vladimir can write up that section when the scaffold is in place. >> >> This page was duplicated and refers to the ganglia-web solution for Nagios: >> >> https://github.com/ganglia/monitor-core/wiki/Integrating-Ganglia-with-Nagios >> >> https://github.com/ganglia/ganglia-web/wiki/Nagios-Integration >> >> I've started changing the version on monitor-core to be a summary page, it links to the document in the ganglia-web wiki and the other related projects >> >> Please feel free to add your comments in the table >> >> >> >> >> ------------------------------------------------------------------------------ >> Flow-based real-time traffic analytics software. Cisco certified tool. >> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> Customize your own dashboards, set traffic alerts and generate reports. >> Network behavioral analysis & security monitoring. All-in-one tool. >> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________ >> Ganglia-developers mailing list >> Gan...@li... >> https://lists.sourceforge.net/lists/listinfo/ganglia-developers > |
From: Daniel P. <da...@po...> - 2014-03-03 21:44:33
|
On 03/03/14 22:31, Vladimir Vuksan wrote: > Works for me. Now we just need a volunteer :-D This could be a fun exercise for testing one of the GSoC applicants, maybe they can write a small script to scrape and convert the content |
From: Nick S. <nfs...@gm...> - 2014-03-03 22:20:03
|
+1 On Mon, Mar 3, 2014 at 9:44 PM, Daniel Pocock <da...@po...> wrote: > > > On 03/03/14 22:31, Vladimir Vuksan wrote: > > Works for me. Now we just need a volunteer :-D > > This could be a fun exercise for testing one of the GSoC applicants, > maybe they can write a small script to scrape and convert the content > > -- gpg: using PGP trust model pub 4096R/1EE38BD9 2013-01-06 [expires: 2018-01-06] Key fingerprint = 3EE9 550D D9D8 DB65 58C2 B58D CE78 EC6C 1EE3 8BD9 uid Nicholas Satterly (Debian Key) <nfs...@gm...> sub 4096R/23804EE9 2013-01-06 [expires: 2018-01-06] |