mon-devel — Discussions related to mon development

[Mon-devel] mon.cgi v11 Released

[Nathan G. <na...@cm...>]

Finally, after 3 years+ !
Released a new version of our mon.cgi.
Should now run correctly under perl 5.16+ and CGI 4.04+

http://www.cmpublishers.com/oss/mon.shtml#moncgi

Enjoy.
:-)

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] Network I/O Error question.

[Nathan G. <na...@cm...>]

Hi all,

Does anyone have an idea of what a sane number would be for I/O errors
including discards, on a network interface in, say a five minute period.

One of our systems recently had a NIC failure.
I spent over an hour swapping cables, messing with switch & firewall
settings, etc.
Finally, I happened to try looking at the NICs on the failing system via
SNMP.
What I saw was a system with 2 NIC's functioning perfectly, and one NIC
with an error count of over 400,000.
Obviously, a hardware failure & something that mon could cover.
:-)

I'd like to be sure that the default value for acceptable error counts
is something sensible before releasing the monitor for this.

Currently I have a default of 1000.

There is also the idea of a baseline acceptable error count that could
scale based on the interface type detected, as a faster interface could
experience more errors in a shorter amount of time.

Any thoughts, ideas, or recommendations for a base acceptable error count?

Thanks
:-)

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] mon.cgi v10 Released

[Nathan G. <na...@cm...>]

Finally, after 2 years+ !
Released a new version of our mon.cgi

http://www.cmpublishers.com/oss/mon.shtml#moncgi

Enjoy.
:-)

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

Re: [Mon-devel] mon (wiki) website

[Jim T. <tr...@gm...>]

On Wed, 31 Jul 2013, Marco Bozzolan wrote:

>
> Hello,
>
> I have just noticed that the main website for mon:
>
> https://mon.wiki.kernel.org/
>
> is now redirecting to SourceForge, at
>
> https://sourceforge.net/projects/mon/
>
> so that all the wiki contents are not available anymore.
>
> Is there any chance those contents can be recovered and republished on
> the SourceForge wiki?

Yes, I have an XML dump of the contents of the wiki, and the intention
is to transplant it into the sf environment.

[Mon-devel] mon (wiki) website

[Marco B. <ma...@s1...>]

Hello,

 I have just noticed that the main website for mon:

https://mon.wiki.kernel.org/

is now redirecting to SourceForge, at

https://sourceforge.net/projects/mon/

so that all the wiki contents are not available anymore.

Is there any chance those contents can be recovered and republished on
the SourceForge wiki?

 If any conversion work has to be done, I wouldn't mind spending some
time for it.

Regards

-- 
http://s19n.net

[Mon-devel] cmpublishers.com Mon stuff moved

[Nathan G. <na...@cm...>]

Hi all,

We've moved all the mon stuff on our site from the general Open Source
Software page to its own Mon specific page.

http://www.cmpublishers.com/oss/mon.shtml

Thanks and enjoy,


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] Mon Wiki - Reference Section - Entry 15 bbmon.cgi doesn't work

[Nathan G. <na...@cm...>]

Hi all,

I was checking up on the status of the bbmon.cgi project at loplop.net
and discovered that it's not there anymore.

I've been siting on a rewrite since 2010, as Nicolas indicated that he
planned to publish our changes in an updated version.

I'd hate for the community to lose this software so I've put our version
up at:
http://www.cmpublishers.com/oss/#bbmoncgi

Thanks Nicolas for a cool Web interface to mon.


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] mail.alert v0.2 Released

[Nathan G. <na...@cm...>]

Just released a bug fix version of our replacement mail.alert script.

http://www.cmpublishers.com/oss/#mail.alert

The service name wasn't being put into the subject line of the email alerts.
OOPS :-(
Fixed Now :-)
Enjoy.
:-)

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

Re: [Mon-devel] mail.alert v0.1 Released

[Nathan G. <na...@cm...>]

On 2/22/2013 1:44 PM, Andrew Siegel wrote:
> Hi Nathan,
> 
> Thanks for making this available.  I don't know if anyone else mentioned
> it, but the mail.alert link on the page actually references the
> snmpinv.monitor modules mentioned on the lines above.
> 
> Andy
> 
> -- 
> Andrew Siegel

AAAH!
I can't believe I did that!
Its fixed now.
LOL!
:-)
:$

Thanks Andrew.
I appreciate it.
:$
:-)


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] mail.alert v0.1 Released

[Nathan G. <na...@cm...>]

Just released our version of the mail.alert script that ships with the
mon software.

http://www.cmpublishers.com/oss/#mail.alert

After seeing mon-Bugs-3605484 yesterday, I remembered that we have been
running a modified mail.alert for the last couple of years.
Yesterday, I reviewed & documented these changes in addition to fixing
bug 3605484.
Enjoy.
:-)

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] Website Download links broken

[Jonathan <jdc...@gm...>]

Hey all:

I just tried to download version 1.2 off the website, and the download 
links are broken. ftp.kernel.org doesn't have the latest files, I had to 
go to sourceforge to find them.

I'm not sure if the CVS version is better to install, but if it is that 
should probably mentioned on the download page somewhere.

Also, the last 2 edits on the main page of the wiki have been spam-edits 
for "essay services" and should probably be removed:
https://mon.wiki.kernel.org/index.php/Main_Page

Thanks for a great piece of software!

Jonathan

[Mon-devel] http.monitor

[Timothy Lu Hu B. <ti...@su...>]

the standard http.monitor wasn't cutting it so i modified it and have
been using it like this a while .

the major modifications are :
1) regex to match against for (did i do that ? don't remember , but i
might have .. the diff from cvs seems to not have it , but i don't
remember ... i'll bet trockij did it and i'm trying to steal it but
this would be better if mon was rehosted in github)
2) logging so that if there is a failure condition i have a log of
what mon saw to kick back to developers
3) HTTP BASIC AUTH support

for a bit i sat and tried to make a diff against what's in the cvs ...
and it's not very good . i think the regex stuff came into that file
1.1.1.1.4.1 but ... that's not what's in the cvs .

so find attached both the file itself and a patch .

--timball

-- 
"[]x[][][][][][][][]" || 202-250-0211 [fon] || timmyball [aim]
[sunlight foundation] [fb] [twtrr] [utube] [join] [rss]

[Mon-devel] snmpinv.monitor v0.1 Released

[Nathan G. <na...@cm...>]

Just released an SNMP Inventory monitor.

http://www.cmpublishers.com/oss/#snmpinv.monitor

Not really a monitor, just a quick way to do an SNMP inventory of
everything in a group.

Enjoy.

-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] snmpdiskspace.monitor v0.5 & snmpnetdisk.monitor 0.3 Released

[Nathan G. <na...@cm...>]

Just updated the snmpdiskspace & snmpnetdisk monitors.

http://www.cmpublishers.com/oss/#dns-gtld.monitor

snmpnetdisk
Fixed error on multiple network mounts when a specific mount point was.
specified.

All
Code & output cleanup.
More Debug info.


Enjoy.


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

[Mon-devel] dns-gtld.monitor v0.6

[Nathan G. <na...@cm...>]

Just updated the dns-gtld monitor.

http://www.cmpublishers.com/oss/#dns-gtld.monitor

Code & Output Polishing
Added an option to disable complete TLD NS checking
Reverse zone filtering.
Domain NS sanity checks.
Glue record consistency check.
Massive thanks to sourceforge user gulikoza for these great ideas and code.

Enjoy.


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

Re: [Mon-devel] mon "fork bomb"

[Jim T. <tr...@gm...>]

On Fri, 18 Nov 2011, Anders Synstad wrote:

>>> We had the problem some years ago. We fixed it and I sent a patch. It
>>> seems it was never integrated to the source.
>>
>> this fix has been in cvs under the mon-1-2-branch branch, along with
>> some other more recent fixes which affect the process handling. so, i'd
>> recommend that Anders check out that branch from cvs and give it a try.
>
> We're currently running the 1.2.0 release of mon, but if I understand you
> correctly, the fix didn't make the 1.2.0 release, but is available in the the
> cvs branch.

correct.

cvs -d:pserver:ano...@mo...:/cvsroot/mon login

(hit return for password)

cvs -z3 -d:pserver:ano...@mo...:/cvsroot/mon co -P -rmon-1-2-branch mon

> On a side note; the more I've been looking at other monitoring systems, the
> more I love mon.

that's good to hear. whatever works is best.

Re: [Mon-devel] mon "fork bomb"

[Anders S. <and...@ba...>]

>> We had the problem some years ago. We fixed it and I sent a patch. It 
>> seems it was never integrated to the source.
>
> this fix has been in cvs under the mon-1-2-branch branch, along with
> some other more recent fixes which affect the process handling. so, i'd
> recommend that Anders check out that branch from cvs and give it a try.

We're currently running the 1.2.0 release of mon, but if I understand you 
correctly, the fix didn't make the 1.2.0 release, but is available in the the 
cvs branch.

Will check it out.


On a side note; the more I've been looking at other monitoring systems, the 
more I love mon.


Regards
Anders Synstad
Basefarm AS

Re: [Mon-devel] mon "fork bomb"

[Jim T. <tr...@gm...>]

On Fri, 18 Nov 2011, den...@or... wrote:

> Hello,
>
> We had the problem some years ago. We fixed it and I sent a patch. It seems it was never integrated to the source.

this fix has been in cvs under the mon-1-2-branch branch, along with
some other more recent fixes which affect the process handling. so, i'd
recommend that Anders check out that branch from cvs and give it a try.

Re: [Mon-devel] mon "fork bomb"

[Anders S. <and...@ba...>]

Thank you Denis,

I'll look into this as soon as I can. I does seem very 
plausible that this is what could be happening.


Regards,
Anders Synstad
Basefarm AS
________________________________________
From: den...@or... [den...@or...]
Sent: Friday, November 18, 2011 11:49 AM
To: Anders Synstad; mon...@li...
Subject: RE: [Mon-devel] mon "fork bomb"

Hello,

We had the problem some years ago. We fixed it and I sent a patch. It seems it was never integrated to the source.

The problem is due to the fact that sometime the 'exec' function call used to run a monitor or an alert script *does* return.
It should not. It's written in the 'exec' documentation. There is even a warning about adding something other than exit after an exec:

      exec LIST
       exec PROGRAM LIST
               The "exec" function executes a system command and never
               returns-- use "system" instead of "exec" if you want it to
               return.  It fails and returns false only if the command does
               not exist and it is executed directly instead of via your
               system's command shell (see below).

               Since it's a common mistake to use "exec" instead of "system",
               Perl warns you if there is a following statement which isn't
               "die", "warn", or "exit" (if "-w" is set  -  but you always do
               that).

The 'exec' is called in a forked process and should replace that forked process by the monitor or the alert.
The 'exec' can fail (and thus return) when there is some ressources missing (we where short on memory when this happened).
But it could also happen if you delete a monitor or alert scripts (looking for scripts is done only at startup).

In the 'mon' code, there is a 'return' after the call to 'exec'. That's bad. As the exec should never return, we must put an 'exit' after.
Without the 'exit', the code symply returns to the main loop and we have a forked version of mon running in parallel with the parent one.

Here is the patch we've written to solve this issue.

diff -Naur mon-1.2.0/mon mon-1.2.0-bugexec/mon
--- mon-1.2.0/mon       2009-12-16 13:46:33.808765600 +0000
+++ mon-1.2.0-bugexec/mon       2009-12-16 13:53:04.613773000 +0000
@@ -3611,9 +3611,12 @@

            if (!exec @args)
            {
-               syslog ('err', "could not exec '@args': $!");
+               syslog ('err', "run_monitor: could not exec '@args': $!");
                exit (1);
            }
+           syslog ('err',
+                   "run_monitor: (unreachable!) could not exec '@args': $!");
+           exit(1);
        }

        $sref->{"_last_check"} = scalar (time);
@@ -5078,10 +5081,12 @@
            }

            if (!exec @execargs) {
-               syslog ('err', "could not exec alert $alert: $!");
-               return undef;
+               syslog ('err', "call_alert: could not exec alert $alert: $!");
+               exit(1);
            }
-           exit;
+           syslog ('err',
+                   "call_alert: (unreachable!) could not exec alert $alert: $!");
+           exit(1);
        }

I hope this will help.

Denis Choulette

den...@or...


Equant France
CS&O/ITD/France Customer Application Management/Transversal Activities/Service Assurance & Financial Management


BP 91235 Rue de la Touche Lambert
Bâtiment 7
F35512 Cesson Sévigné Cedex France

Phone:             +33 (0) 2 23 28 41 09
Fax:                 +33 (0) 2 23 28 45 83
http://www.equant.com


-----Original Message-----
From: Anders Synstad [mailto:and...@ba...]
Sent: 17 November 2011 10:38
To: mon...@li...
Subject: [Mon-devel] mon "fork bomb"

Hello,


We've been running mon for a decade now, and it's been working great.
However, the last month we've started to run into a problem.  The best explaination I have is that mon "fork bombs", and the load goes thru the roof.

I've only been able to do a dump of ps before we had to reboot the system, and it lists:

365 of these:
qroot       607  0.0  3.0 225952 124644 ?     S    13:36   0:00
/local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid
root      3044  2.6  3.3 225952 137156 ?     D    13:38   0:09
/local/bin/perl /local/etc/mon/mon -l -f -c
  /etc/mon/mon.cf -P /var/run/mon.pid

and 1684 of these:
root      3043  0.7  0.0     0    0 ?        Z    13:38   0:02 [mon]
<defunct>


This week is has happened 3 times already. This is something I've haven't seen in the past.

During normal use, it doesn't seem to be overloaded:

ro...@mo... mon]# free
              total       used       free     shared    buffers     cached
Mem:       4040056    1654504    2385552          0      68576    1119588
-/+ buffers/cache:     466340    3573716
Swap:      4192944          0    4192944

[ro...@mo... mon]# uptime
  10:10am  up   1:11,  5 users,  load average: 3.11, 3.05, 2.77


I'm still trying to debug whenever this happens, but there is limits to how long we can debug each time as monitoring is down in this period, and deubgging with triple-digit load time is tideous. I haven't found any indicators in any logfiles either.


Does anyone have any ideas what could be causing this?



--
Anders Synstad
Basefarm AS

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mon-devel mailing list
Mon...@li...
https://lists.sourceforge.net/lists/listinfo/mon-devel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.

Re: [Mon-devel] mon "fork bomb"

[<den...@or...>]

Hello,

We had the problem some years ago. We fixed it and I sent a patch. It seems it was never integrated to the source.

The problem is due to the fact that sometime the 'exec' function call used to run a monitor or an alert script *does* return.
It should not. It's written in the 'exec' documentation. There is even a warning about adding something other than exit after an exec:

      exec LIST
       exec PROGRAM LIST
               The "exec" function executes a system command and never
               returns-- use "system" instead of "exec" if you want it to
               return.  It fails and returns false only if the command does
               not exist and it is executed directly instead of via your
               system's command shell (see below).

               Since it's a common mistake to use "exec" instead of "system",
               Perl warns you if there is a following statement which isn't
               "die", "warn", or "exit" (if "-w" is set  -  but you always do
               that). 

The 'exec' is called in a forked process and should replace that forked process by the monitor or the alert.
The 'exec' can fail (and thus return) when there is some ressources missing (we where short on memory when this happened).
But it could also happen if you delete a monitor or alert scripts (looking for scripts is done only at startup).

In the 'mon' code, there is a 'return' after the call to 'exec'. That's bad. As the exec should never return, we must put an 'exit' after.
Without the 'exit', the code symply returns to the main loop and we have a forked version of mon running in parallel with the parent one.

Here is the patch we've written to solve this issue.

diff -Naur mon-1.2.0/mon mon-1.2.0-bugexec/mon
--- mon-1.2.0/mon	2009-12-16 13:46:33.808765600 +0000
+++ mon-1.2.0-bugexec/mon	2009-12-16 13:53:04.613773000 +0000
@@ -3611,9 +3611,12 @@
 
 	    if (!exec @args)
 	    {
-	    	syslog ('err', "could not exec '@args': $!");
+	    	syslog ('err', "run_monitor: could not exec '@args': $!");
 		exit (1);
 	    }
+	    syslog ('err',
+		    "run_monitor: (unreachable!) could not exec '@args': $!");
+	    exit(1);
 	}
 
 	$sref->{"_last_check"} = scalar (time);
@@ -5078,10 +5081,12 @@
 	    }
 	    
 	    if (!exec @execargs) {
-		syslog ('err', "could not exec alert $alert: $!");
-		return undef;
+		syslog ('err', "call_alert: could not exec alert $alert: $!");
+		exit(1);
 	    }
-	    exit;
+	    syslog ('err',
+		    "call_alert: (unreachable!) could not exec alert $alert: $!");
+	    exit(1);
 	}
 
I hope this will help.

Denis Choulette

den...@or...

 
Equant France
CS&O/ITD/France Customer Application Management/Transversal Activities/Service Assurance & Financial Management

 
BP 91235 Rue de la Touche Lambert
Bâtiment 7
F35512 Cesson Sévigné Cedex France
 
Phone:             +33 (0) 2 23 28 41 09
Fax:                 +33 (0) 2 23 28 45 83
http://www.equant.com


-----Original Message-----
From: Anders Synstad [mailto:and...@ba...] 
Sent: 17 November 2011 10:38
To: mon...@li...
Subject: [Mon-devel] mon "fork bomb"

Hello,


We've been running mon for a decade now, and it's been working great. 
However, the last month we've started to run into a problem.  The best explaination I have is that mon "fork bombs", and the load goes thru the roof.

I've only been able to do a dump of ps before we had to reboot the system, and it lists:

365 of these:
qroot       607  0.0  3.0 225952 124644 ?     S    13:36   0:00 
/local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P /var/run/mon.pid
root      3044  2.6  3.3 225952 137156 ?     D    13:38   0:09 
/local/bin/perl /local/etc/mon/mon -l -f -c
  /etc/mon/mon.cf -P /var/run/mon.pid

and 1684 of these:
root      3043  0.7  0.0     0    0 ?        Z    13:38   0:02 [mon] 
<defunct>


This week is has happened 3 times already. This is something I've haven't seen in the past.

During normal use, it doesn't seem to be overloaded:

ro...@mo... mon]# free
              total       used       free     shared    buffers     cached
Mem:       4040056    1654504    2385552          0      68576    1119588
-/+ buffers/cache:     466340    3573716
Swap:      4192944          0    4192944

[ro...@mo... mon]# uptime
  10:10am  up   1:11,  5 users,  load average: 3.11, 3.05, 2.77


I'm still trying to debug whenever this happens, but there is limits to how long we can debug each time as monitoring is down in this period, and deubgging with triple-digit load time is tideous. I haven't found any indicators in any logfiles either.


Does anyone have any ideas what could be causing this?



--
Anders Synstad
Basefarm AS

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mon-devel mailing list
Mon...@li...
https://lists.sourceforge.net/lists/listinfo/mon-devel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.

[Mon-devel] mon "fork bomb"

[Anders S. <and...@ba...>]

Hello,


We've been running mon for a decade now, and it's been working great. 
However, the last month we've started to run into a problem.  The best 
explaination I have is that mon "fork bombs", and the load goes thru the 
roof.

I've only been able to do a dump of ps before we had to reboot the 
system, and it lists:

365 of these:
qroot       607  0.0  3.0 225952 124644 ?     S    13:36   0:00 
/local/bin/perl /local/etc/mon/mon -l -f -c /etc/mon/mon.cf -P 
/var/run/mon.pid
root      3044  2.6  3.3 225952 137156 ?     D    13:38   0:09 
/local/bin/perl /local/etc/mon/mon -l -f -c
  /etc/mon/mon.cf -P /var/run/mon.pid

and 1684 of these:
root      3043  0.7  0.0     0    0 ?        Z    13:38   0:02 [mon] 
<defunct>


This week is has happened 3 times already. This is something I've 
haven't seen in the past.

During normal use, it doesn't seem to be overloaded:

ro...@mo... mon]# free
              total       used       free     shared    buffers     cached
Mem:       4040056    1654504    2385552          0      68576    1119588
-/+ buffers/cache:     466340    3573716
Swap:      4192944          0    4192944

[ro...@mo... mon]# uptime
  10:10am  up   1:11,  5 users,  load average: 3.11, 3.05, 2.77


I'm still trying to debug whenever this happens, but there is limits to 
how long we can debug each time as monitoring is down in this period, 
and deubgging with triple-digit load time is tideous. I haven't found 
any indicators in any logfiles either.


Does anyone have any ideas what could be causing this?



-- 
Anders Synstad
Basefarm AS

Re: [Mon-devel] Mon wiki

[Nathan G. <na...@cm...>]

On 10/19/2011 7:30 PM, Jim Trocki wrote:
> On Mon, 17 Oct 2011, Kastus wrote:
> 
>> Hi,
>>
>> I apologize if I am asking something obvious.
>>
>> Does anybody know what happened to Mon wiki? It seems like everything is gone
>> from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/
>> looks dead too.
> 
> The wiki will be restored, but that task is blocked while waiting for some
> new hardware.
> 

It appears up now.
Finally.

> The mailing list will be migrated elsewhere, to where I'm not yet sure.
> 

Oh did that get toasted?
Let me know where / when I've got a new monitor, and some monitor tweaks
ready.


-- 
Sincerely,

Nathan Gibbs

Systems Administrator
Christ Media
http://www.cmpublishers.com

Re: [Mon-devel] Mon wiki

[Jim T. <tr...@gm...>]

On Mon, 17 Oct 2011, Kastus wrote:

> Hi,
>
> I apologize if I am asking something obvious.
>
> Does anybody know what happened to Mon wiki? It seems like everything is gone
> from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/
> looks dead too.

The wiki will be restored, but that task is blocked while waiting for some
new hardware.

The mailing list will be migrated elsewhere, to where I'm not yet sure.

Re: [Mon-devel] Mon wiki

[Jim T. <tr...@gm...>]

On Mon, 17 Oct 2011, Kastus wrote:

> Hi,
>
> I apologize if I am asking something obvious.
>
> Does anybody know what happened to Mon wiki? It seems like everything is gone
> from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/
> looks dead too.
>
> Was it migrated somewhere after attacks on kernel.org or was it simply
> shut down?

It's been shut down and needs to be migrated to somewhere.

[Mon-devel] Mon wiki

[Kastus <ks...@tp...>]

Hi,

I apologize if I am asking something obvious.

Does anybody know what happened to Mon wiki? It seems like everything is gone
from http://www.kernel.org/software/mon/, and https://mon.wiki.kernel.org/index.php/
looks dead too.

Was it migrated somewhere after attacks on kernel.org or was it simply 
shut down?

Thanks,

Kastus