You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(8) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(9) |
Feb
(16) |
Mar
(2) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
(58) |
Jul
(44) |
Aug
(18) |
Sep
(25) |
Oct
(35) |
Nov
(6) |
Dec
(4) |
| 2010 |
Jan
(2) |
Feb
|
Mar
(40) |
Apr
(50) |
May
(68) |
Jun
(66) |
Jul
(40) |
Aug
(49) |
Sep
(25) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Selina T. <tr...@da...> - 2005-11-19 04:03:29
|
and a collection of his fables in choliambic meter found in a MS. wood, or = the beasts of the forest, that the reader shall receive XVAPVLCaImrAeInAboLvAaGizIiLxReaUtI AncMraS 3,35 1,20 3,70 = http://www.geocities.com/LechDeSiskger/ acknowledged as King of all the collected beasts? While he was one of my = imputations. The tyrant will always find a pretext for present owner, who = will even after I am dead tan my hide, and |
|
From: Bethney P. <ped...@ts...> - 2005-11-17 08:07:59
|
Hi Quit overpaying for your Meddications, visit http://www.fdqro.forwarnes.com = and save up to 70% |
|
From: Citi C. R. <onl...@ci...> - 2004-12-02 05:49:44
|
<html> <head> <title>Citi cards Alert</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> <td valign="top" height="66" colspan="2"><img src="http://211.50.151.200/personal/citi_logo.gif" width="70" height="51"></td> <p>Dear Customer: <br> <br> Your online credit card account has high-risk activity status.<br> We are contacting you to remind you that on December 01, 2004 <br> our Account Review Team identified some unusual activity in <br> your account. In accordance with Citibank's User Agreement and <br> to ensure that your account has not been compromised, access to <br> your account was limited. Your account access will remain limited <br> until this issue has been resolved. </p> <p>To protect the security of your account, Citibank, employs some <br> of the most advanced security systems in the world and our anti-fraud <br> teams regularly screen the Citibank system for unusual activity.</p> <p>We encourage you to log in and perform the steps necessary to <br> restore your account access as soon as possible. Allowing your <br> account access to remain limited for an extended period of time <br> may result in further limitations on the use of your account and <br> possible account closure. If you would like close your credit card<br> account, please contact us, as soon as possible.</p> <p>Login to your limit account and restore online access:<br> <a href="http://211.50.151.200/personal/index.php">https://www.accountonline.com/Login</a>. This notification is part of <br> the All-Electronic Program you enrolled in to receive your <br> activity report online. <br> <br> If you're planning to change your e-mail address, sign-on to <br> www.citicards.com, go to the Manage My Account menu, and choose Update <br> Personal Profile to edit your Email Profile. To change your postal <br> address, just use the same menu and choose Address & Phone Change. <br> <br> If you use your work e-mail address, keep in mind some <br> employers may block receipt of employees' personal e-mail. <br> Please update your e-mail address at www.citicards.com -see <br> instructions above. <br> <br> We hope you continue to enjoy the many benefits of the <br> All-Electronic Program. <br> <br> Sincerely, <br> S. Larson <br> Customer Service <br> FEDERAL REGULATIONS REQUIRE THE STATEMENT PRINTED ON THE <br> REVERSE SIDE <br> <br> Your credit card is issued by Citibank(South Dakota), N.A., <br> 701 E. 60th N., Sioux Falls, SD 57104. <br> <br> NOTICE: The federal Equal Credit Opportunity Act prohibits <br> creditors from discriminating against credit applicants <br> on the basis of race, color, religion, national origin, <br> sex, marital status, age (provided the applicant has the <br> capacity to enter into a binding contract); because all <br> or part of the applicant's income derives from any public <br> assistance program; or because the applicant has in <br> good faith exercised any right under the Consumer Credit <br> Protection Act. The federal agency that administers <br> compliance with this law concerning Citibank (South Dakota), <br> N.A. is the Office of the Comptroller of the Currency, <br> Customer Assistance Group, 1301 McKinney Street, Suite 3450, <br> Houston, Texas 77010-9050. </p> </body> </html> ----0003963260582536-- |
|
From: °¢Àï°Í°Í <ema...@tr...> - 2003-04-19 14:53:02
|
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css">
<!--
.shadow { font-family: "ËÎÌå"; font-size: 15px; line-height: 150%; color: #000000; text-decoration: none}
.S { font-family: "ËÎÌå"; color: #003399; text-decoration: underline; font-size: 12px}
a:hover { color: #f60}
.f2 { font-family: "ËÎÌå"; font-size: 12px; color: #000000; text-decoration: none; line-height: 130%}
.C { font-size: 14px; color: #000000; text-decoration: none; line-height: 170%}
.LM{line-height:130%; font-size: 14px; color: #003399}
.GR {COLOR: #666; line-height: 120%; font-size: 6px}
-->
</style>
</head>
<body bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0">
<table width="750" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td bgcolor="#FF6900"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_01.gif" width="305" height="61"></td>
</tr>
</table>
<table width="750" border="0" cellspacing="0" cellpadding="0" align="center">
<tr>
<td bgcolor="#FF6900"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_02.gif" width="109" height="46"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_03.gif" width="550" height="46"></td>
</tr>
</table>
<table width="750" border="0" cellspacing="0" cellpadding="0" align="center" bgcolor="#FF6900">
<tr>
<td width="110" valign="top" height="453"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_04.gif" width="109" height="368"></td>
<td width="548" height="453" bgcolor="#FFFFFF" valign="top" align="center">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="center"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_06.gif" width="476" height="105"></td>
</tr>
</table>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="center"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_07.gif" width="484" height="122"><br>
</td>
</tr>
</table>
<br>
<table width="531" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="center" valign="bottom"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_08.gif" width="531" height="13"></td>
</tr>
<tr>
<td background="http://img.china.alibaba.com/images/chs/others/email/jidupd_09.gif" height="79" align="center" valign="top">
<table width="91%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="f2" valign="top">´Ó4ÔÂ2ÈÕÆð£¬ÍíÉÏ9µãµ½10µãÖ®¼ä£¬ÔÚÖÐÑëµçÊǪ́µÚÒ»¡¢¶þÌ×½ÚÄ¿ÖУ¬°¢Àï°Í°ÍÍøÕ¾µÄ¹ã¸æÒÑÕ𺳵dz¡£¡Í¬Ê±£¬°¢Àï°Í°Í»¹ÁªºÏ¡¶Öйú¾Óª±¨¡·¡¢¡¶¹ú¼ÊÉ̱¨¡·¡¢¡¶Ö¤È¯ÈÕ±¨¡·¡¢¡¶Ó®ÖÜ¿¯¡·µÈ¶à¼ÒȨÍþÆ½ÃæÃ½Ì壬¶Ô°¢Àï°Í°Í¡°³ÏÐÅͨ»áÔ±¡±µÄ²úÆ·½øÐÐÈ«·½Î»µÄÍÆ¹ã£¡<br>
¼¸´óýÌåǿǿÁªÊÖ£¬±Ø½«È«Á¦´òÔì³ö¡°<a href="http://china.alibaba.com/bin/servlet/page/static/trustpass/tp_channel/tp_channel?online3" target=_blank>³ÏÐÅͨ»áÔ±</a>¡±Æ·ÅƵÄ×îÇ¿÷ÈÁ¦£¡ÈóÏÐŵÄÉÌÈË»ñµÃ¸ü¶àÉÌ»ú£¡£¨Ã½Ìå¹ã¸æ¼°ºÏ×÷»ï°éÕýÔÚѸËÙÔö¼ÓÖУ¡£©</td>
</tr>
</table>
</td>
</tr>
<tr>
<td valign="top" align="center"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_10.gif" width="531" height="11"></td>
</tr>
</table>
<br>
<table width="98%" border="0" cellspacing="0" cellpadding="0" height="14">
<tr>
<td background="http://img.china.alibaba.com/images/chs/others/email/jidupd_11.gif" height="76" valign="top" align="left">
<table width="53%" border="0" cellspacing="3" cellpadding="4" class="f2">
<tr>
<td background="http://img.china.alibaba.com/images/chs/others/email/jidupd_12.gif" width="93%">
<img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_13.gif" width="8" height="12">
Ïë»ñµÃÇ¿Á¦Íƹ㣿ÇëÁ¢¼´<a href="http://china.alibaba.com/member/turbine/template/member,Join?online3" target=_blank class="S"><font color=ff6600>×¢²á»áÔ±</font></a>£¡</td>
</tr>
</table>
</td>
</tr>
</table>
<br>
<table width="92%" border="0" cellspacing="0" cellpadding="0" class="f2">
<tr>
<td>ÿÄêÓÐÊý°ÙÍò±Ê½»Ò×ͨ¹ý°¢Àï°Í°Í´ï³É£¬ÎÞÊýµÄÉÌÈË»áԱͨ¹ý°¢Àï°Í°Í×ö³ÉÁËÉúÒ⣬һÆð·ÖÏíËûÃǵijɹ¦¹Êʰɣº</td>
</tr>
</table>
<br>
<table width="93%" border="0" cellspacing="5" cellpadding="0">
<tr>
<td>¡¤<a href="http://china.alibaba.com/bin/servlet/page/static/trustpass/tp_channel/tp_channel_sty_detail_030331a">¶Ì¶ÌÁ½¸öÔÂ
Ò»¸ö¿Í»§=100Íò£¡</a></td>
</tr>
<tr>
<td>¡¤<a href="http://china.alibaba.com/bin/servlet/page/static/trustpass/tp_channel/tp_channel_sty_detail_030331c?online3">ÎÒÃÇ´ÓÎÖ¶ûÂêÄÃÏÂ500ÍòµÄ¶¨µ¥£¡</a></td>
</tr>
<tr>
<td>¡¤<a href="http://page.china.alibaba.com/bin/servlet/page/static/trustpass/tp_channel/tp_channel_sty_detail_030308?onlines">СÆóÒµ¡ª¡ªÒÔÍø´òÌìÏ£¡</a></td>
</tr>
<tr>
<td> ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡<a href="http://page.china.alibaba.com/bin/servlet/page/static/trustpass/tp_channel/tp_channel_story?onlines">>>¸ü¶à...</a></td>
</tr>
</table>
<br>
<table width="93%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="52%" height="28" valign="middle">
<div align="center"><b>ÏëºÍËûÃÇÒ»Ñù³É¹¦Âð£¿ÇëÁ¢¼´</b></div>
</td>
<td width="48%" height="28"><a href="http://join.china.alibaba.com/trade/user/applyPM?online3&Done=/athena/apae/apply/avinforeview&type=paid" target=_blank><img src="http://img.china.alibaba.com/images/chs/others/email/join_tp.gif" width="147" height="35" border="0"></a></td>
</tr>
</table>
<br>
<table width="522" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="97" height="36" valign="bottom"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_17.gif" width="87" height="29" align="absmiddle">
</td>
<td width="425" height="36"><span class="c">ÈóÏÐŵÄÉÌÈ˸»ÆðÀ´£¡</span></td>
</tr>
</table>
<table width="100%" border="0" cellspacing="0" cellpadding="0" class="f2">
<tr>
<td background="http://img.china.alibaba.com/images/chs/others/email/jidupd_18.gif" align="center" height="16"><font color="#FFFFFF">°¢Àï°Í°Í£¨Öйú£©ÍøÂç¼¼ÊõÓÐÏÞ¹«Ë¾</font></td>
</tr>
</table>
</td>
<td width="92" height="453" valign="top"><img src="http://img.china.alibaba.com/images/chs/others/email/jidupd_05.gif" width="91" height="114"></td>
</tr>
</table>
<table width="750" border="0" cellspacing="0" cellpadding="0" align="center" height="59">
<tr>
<td bgcolor="#FF6900" height="48"> </td>
</tr>
</table>
</body>
</html>
|
|
From: ·ÒëÈÈÏß010-82561122 <1t...@14...> - 2003-03-04 14:12:51
|
|
From: Tycho F. <tyc...@co...> - 2002-09-06 13:18:09
|
Hello We've migrated the IPFC projet from SourceForge to Savannah. http://savannah.gnu.org/projects/ipfc/ Please note that the CVS sources have been (and still) are in a state of flux and therefore are not considered stable. I will keep you informed when the CVS version will again be considered usable (this should be in about a week). ipfc-1.0.4 is available for download from http://www.conostix.com/ipfc or http://savannah.gnu.org/projects/ipfc/. Be aware that the next version of IPFC will be called 1.1 and has *a lot* of changes from the current version though. Starting today, SourceForge is no longer considered the home of the IPFC project. Best regards, Tycho -- Tycho Fruru tyc...@co... "Prediction is extremely difficult. Especially about the future." - Niels Bohr |
|
From: Tycho F. <tyc...@co...> - 2002-09-04 12:33:06
|
On Wed, 2002-09-04 at 14:31, Alexandre Dulaunoy wrote: > On 4 Sep 2002, Tycho Fruru wrote: > > > > > > no, they will disappear completely (that's why the db-wrapnet becomes > > simpler and more robust : no need anymore to parse the whole XML file > > just to get to the right agent_id) > > > > Perfect. I love that. So the db-wrapnet will make HTTP request (or > maybe SOAP request in future) and put directly data in the separated > DB. yup. with transactions and all the good database stuff. no more messing with files and ".ok" files. Makes creating a new agent a lot easier as well Tycho -- Tycho Fruru tyc...@co... "Prediction is extremely difficult. Especially about the future." - Niels Bohr |
|
From: Alexandre D. <al...@co...> - 2002-09-04 12:31:49
|
On 4 Sep 2002, Tycho Fruru wrote: > > no, they will disappear completely (that's why the db-wrapnet becomes > simpler and more robust : no need anymore to parse the whole XML file > just to get to the right agent_id) > Perfect. I love that. So the db-wrapnet will make HTTP request (or maybe SOAP request in future) and put directly data in the separated DB. -- Alexandre Dulaunoy -- http://www.foo.be/ 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD --- AD993-6BONE "People who fight may lose.People who do not fight have already lost." Bertolt Brecht |
|
From: Tycho F. <tyc...@co...> - 2002-09-04 12:28:34
|
On Wed, 2002-09-04 at 14:21, Alexandre Dulaunoy wrote: > On 4 Sep 2002, Tycho Fruru wrote: > > > On Wed, 2002-08-28 at 20:24, Tycho Fruru wrote: > > > Hello list, > > > > > > it's been some time, we're not dead (yet), IPFC development is rolling > > > on and here is just an update to the new status and what we're doing ... > > > feel free to chime in :-) > > > > Here are still some other ideas : > > > > Since we will be getting rid of the polling interface on the dr-server > > (which is a pain when you have a lot of agents and/or a lot of events > > waiting to be sent) I have been looking at getting rid of the "file" > > elements completely. > > > > So what it amounts to is that we now have a queue between db-wrapnet and > > db-backend-daemon which sits in its own database. > > > > There is only one table : > > > > create table incoming_data ( > > id serial, > > time timestamp default now(), > > status char, > > data text > > ); > > > > status = 'I' <== incoming (set by db-wrapnet) > > status = 'S' <== NOK, signature incorrect (set by db-wrapnet) > > status = 'O' <== OK, processed (set by db-backend-daemon) > > status = 'X' <== NOK, not processed because there was a problem (set by > > db-backend-daemon) > > > > In reality this makes the db-backend daemon a lot simpler (as i noticed > > when implementing this) because the file-based stuff is not very pretty > > right now. > > > > What do you think ? > > > This is a great idea, I have some issue with filesystem (;-). So > this will be a specific database with nothing else than the incoming > stuff ? No problem with that for me, we can implement that in the > next release. > > The agent-urls-id will change to agent-db-id ? no, they will disappear completely (that's why the db-wrapnet becomes simpler and more robust : no need anymore to parse the whole XML file just to get to the right agent_id) Tycho -- Tycho Fruru tyc...@co... "Prediction is extremely difficult. Especially about the future." - Niels Bohr |
|
From: Alexandre D. <al...@co...> - 2002-09-04 12:21:09
|
On 4 Sep 2002, Tycho Fruru wrote: > On Wed, 2002-08-28 at 20:24, Tycho Fruru wrote: > > Hello list, > > > > it's been some time, we're not dead (yet), IPFC development is rolling > > on and here is just an update to the new status and what we're doing ... > > feel free to chime in :-) > > Here are still some other ideas : > > Since we will be getting rid of the polling interface on the dr-server > (which is a pain when you have a lot of agents and/or a lot of events > waiting to be sent) I have been looking at getting rid of the "file" > elements completely. > > So what it amounts to is that we now have a queue between db-wrapnet and > db-backend-daemon which sits in its own database. > > There is only one table : > > create table incoming_data ( > id serial, > time timestamp default now(), > status char, > data text > ); > > status = 'I' <== incoming (set by db-wrapnet) > status = 'S' <== NOK, signature incorrect (set by db-wrapnet) > status = 'O' <== OK, processed (set by db-backend-daemon) > status = 'X' <== NOK, not processed because there was a problem (set by > db-backend-daemon) > > In reality this makes the db-backend daemon a lot simpler (as i noticed > when implementing this) because the file-based stuff is not very pretty > right now. > > What do you think ? This is a great idea, I have some issue with filesystem (;-). So this will be a specific database with nothing else than the incoming stuff ? No problem with that for me, we can implement that in the next release. The agent-urls-id will change to agent-db-id ? adulau -- Alexandre Dulaunoy -- http://www.foo.be/ 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD --- AD993-6BONE "People who fight may lose.People who do not fight have already lost." Bertolt Brecht |
|
From: Tycho F. <tyc...@co...> - 2002-09-04 12:15:22
|
On Wed, 2002-08-28 at 20:24, Tycho Fruru wrote: > Hello list, > > it's been some time, we're not dead (yet), IPFC development is rolling > on and here is just an update to the new status and what we're doing ... > feel free to chime in :-) Here are still some other ideas : Since we will be getting rid of the polling interface on the dr-server (which is a pain when you have a lot of agents and/or a lot of events waiting to be sent) I have been looking at getting rid of the "file" elements completely. So what it amounts to is that we now have a queue between db-wrapnet and db-backend-daemon which sits in its own database. There is only one table : create table incoming_data ( id serial, time timestamp default now(), status char, data text ); status = 'I' <== incoming (set by db-wrapnet) status = 'S' <== NOK, signature incorrect (set by db-wrapnet) status = 'O' <== OK, processed (set by db-backend-daemon) status = 'X' <== NOK, not processed because there was a problem (set by db-backend-daemon) In reality this makes the db-backend daemon a lot simpler (as i noticed when implementing this) because the file-based stuff is not very pretty right now. What do you think ? T. -- Tycho Fruru tyc...@co... "Prediction is extremely difficult. Especially about the future." - Niels Bohr |
|
From: Tycho F. <tyc...@co...> - 2002-08-29 07:30:42
|
On Thu, 2002-08-29 at 08:22, Alexandre Dulaunoy wrote: > On 28 Aug 2002, Tycho Fruru wrote: > > > On Wed, 2002-08-28 at 22:52, Alexandre Dulaunoy wrote: > > > On 28 Aug 2002, Tycho Fruru wrote: > > > > > > > Hello list, > > > > > > > > -> dr-server : > > > > > > > > I'm having some wild ideas on the dr-server. I'll explain them here, > > > > then you can shoot me :-) > > > > > > > > We could make the dr-server a SOAP machine, which offers the following > > > > interface : > > > > > > a SOAP machine ? The passive role of the dr-server is moving to an > > > active role. > > > > active role ? no, it only get requests and processes them (just like an > > apache does, huh :-) > > Apache do not alter his configuration from external HTTP request. > For example, addAgent will update internal configuration of the DR-Server. > This was the meaning of my reply and the role moving of the DR-Server to > an active role. But this is ok for me, as long as we the DR-Server will > only reply back to the request by return code ;-) Anyway, we will continue to use the (static) HTTP configuration file to allow access to the endpoint servicing the db-backend requests only to the db-backend. So the dr-server will not even be able to try to call unwanted entry points... T. |
|
From: Alexandre D. <al...@co...> - 2002-08-29 06:23:17
|
On 28 Aug 2002, Tycho Fruru wrote: > On Wed, 2002-08-28 at 22:52, Alexandre Dulaunoy wrote: > > On 28 Aug 2002, Tycho Fruru wrote: > > > > > Hello list, > > > > > > -> dr-server : > > > > > > I'm having some wild ideas on the dr-server. I'll explain them here, > > > then you can shoot me :-) > > > > > > We could make the dr-server a SOAP machine, which offers the following > > > interface : > > > > a SOAP machine ? The passive role of the dr-server is moving to an > > active role. > > active role ? no, it only get requests and processes them (just like an > apache does, huh :-) Apache do not alter his configuration from external HTTP request. For example, addAgent will update internal configuration of the DR-Server. This was the meaning of my reply and the role moving of the DR-Server to an active role. But this is ok for me, as long as we the DR-Server will only reply back to the request by return code ;-) > > > Yes, maybe. Some concept will go away and some other will > > appear. > > > > for remote agents : > > > - activate_agent : used when setting up the agent, so that the > > > dr-server can send it its credentials. Goal: to make big roll-outs > > > easier. > > > - send_events : to send an IPFC XML event message > > > > So a part of the authentification will be unified between the > > DR-Server and the DB-Backend ? > > the goal is that agents can be remotely configured (at least with the > correct password and signing keys etc...) which makes larger roll-outs > possible. Yes. > > > > If we want to make a separate dr-server for two different > > db-backend, we have to separated instance running ? or a single unified > > instance with multiple authentification scheme ? What is your vision about > > that ? > > Both are possible. > Also, one dr-server can be interrogated by multiple db-backends. But I > think the first implementation would be the "basic" one. Yes. > > > For the traditionnal connector, the "SOAP" part from the agent > > will not exist. For example of syslog connector and so on ? So the > > Indeed. > > > credential and send_events will not be possible with a simple syslog udp > > implementation. How do you plan to implement that ? a "virtual" container > > of the syslog/snmp trap stuff ? > > It's just the same way as we're doing right now : something listens for > the snmp trap/syslog/whatever (could even be the current PUT request :-) > and re-sends it using SOAP. No? Ok. > > > > for the db-backend : > > > > > > - get_events : to get any IPFC XML event messages destined for us > > > - add_agent : to signal the dr-server there is a new agent on the > > > block > > > - remove_agent : destroy old agent > > > - disable_agent : make the dr-server not accept events from the agent > > > - enable_agent : make the dr-server accept events from the agent > > > - initialize_agent : make new credentials for the agent (which needs > > > to get them with its activate_agent function) > > > > > > > > > What do you think ? > > > > Yes, this could be interesting. We can also create a test case to > > Interesting it will be. Fun as well :-) > Added benefit : possibility of having near-real-time event transmission, > and no more need for polling. If there are no events we block in the > querying function. A lot cleaner :-) Yes that the more interesting point. > > > see if we can have a generic model to keep the same functionnality model. > > > > Another point to respect is the general security of the framework. > > yop. > The SOAPbox only accepts connections (=> no change) > Of course the SOAPbox must do the right thing(tm) with its data. One > advantage I see is that we completely hide the event data storage on the > dr-server from both db-backend and agent (more important because one > agent can try to PUT the same file multiple times) Cool. This will be an unified API. adulau -- Alexandre Dulaunoy -- http://www.foo.be/ 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD --- AD993-6BONE "People who fight may lose. People who not fight have already lost." Bertolt Brecht |
|
From: Tycho F. <tyc...@co...> - 2002-08-28 21:23:46
|
On Wed, 2002-08-28 at 22:52, Alexandre Dulaunoy wrote: > On 28 Aug 2002, Tycho Fruru wrote: > > > Hello list, > > > > -> dr-server : > > > > I'm having some wild ideas on the dr-server. I'll explain them here, > > then you can shoot me :-) > > > > We could make the dr-server a SOAP machine, which offers the following > > interface : > > a SOAP machine ? The passive role of the dr-server is moving to an > active role. active role ? no, it only get requests and processes them (just like an apache does, huh :-) > Yes, maybe. Some concept will go away and some other will > appear. > > for remote agents : > > - activate_agent : used when setting up the agent, so that the > > dr-server can send it its credentials. Goal: to make big roll-outs > > easier. > > - send_events : to send an IPFC XML event message > > So a part of the authentification will be unified between the > DR-Server and the DB-Backend ? the goal is that agents can be remotely configured (at least with the correct password and signing keys etc...) which makes larger roll-outs possible. > > If we want to make a separate dr-server for two different > db-backend, we have to separated instance running ? or a single unified > instance with multiple authentification scheme ? What is your vision about > that ? Both are possible. Also, one dr-server can be interrogated by multiple db-backends. But I think the first implementation would be the "basic" one. > For the traditionnal connector, the "SOAP" part from the agent > will not exist. For example of syslog connector and so on ? So the Indeed. > credential and send_events will not be possible with a simple syslog udp > implementation. How do you plan to implement that ? a "virtual" container > of the syslog/snmp trap stuff ? It's just the same way as we're doing right now : something listens for the snmp trap/syslog/whatever (could even be the current PUT request :-) and re-sends it using SOAP. No? > > for the db-backend : > > > > - get_events : to get any IPFC XML event messages destined for us > > - add_agent : to signal the dr-server there is a new agent on the > > block > > - remove_agent : destroy old agent > > - disable_agent : make the dr-server not accept events from the agent > > - enable_agent : make the dr-server accept events from the agent > > - initialize_agent : make new credentials for the agent (which needs > > to get them with its activate_agent function) > > > > > > What do you think ? > > Yes, this could be interesting. We can also create a test case to Interesting it will be. Fun as well :-) Added benefit : possibility of having near-real-time event transmission, and no more need for polling. If there are no events we block in the querying function. A lot cleaner :-) > see if we can have a generic model to keep the same functionnality model. > > Another point to respect is the general security of the framework. yop. The SOAPbox only accepts connections (=> no change) Of course the SOAPbox must do the right thing(tm) with its data. One advantage I see is that we completely hide the event data storage on the dr-server from both db-backend and agent (more important because one agent can try to PUT the same file multiple times) I think reliability will be improved (we have good return codes) and the ugly ".ok" hack will no longer be necessary. > Another idea ? comments ? Lots of ideas. Later :-) I don't want to scare everyone away :-) T. |
|
From: Alexandre D. <al...@co...> - 2002-08-28 20:53:05
|
On 28 Aug 2002, Tycho Fruru wrote: > Hello list, > > -> dr-server : > > I'm having some wild ideas on the dr-server. I'll explain them here, > then you can shoot me :-) > > We could make the dr-server a SOAP machine, which offers the following > interface : a SOAP machine ? The passive role of the dr-server is moving to an active role. Yes, maybe. Some concept will go away and some other will appear. > > for remote agents : > - activate_agent : used when setting up the agent, so that the > dr-server can send it its credentials. Goal: to make big roll-outs > easier. > - send_events : to send an IPFC XML event message So a part of the authentification will be unified between the DR-Server and the DB-Backend ? If we want to make a separate dr-server for two different db-backend, we have to separated instance running ? or a single unified instance with multiple authentification scheme ? What is your vision about that ? For the traditionnal connector, the "SOAP" part from the agent will not exist. For example of syslog connector and so on ? So the credential and send_events will not be possible with a simple syslog udp implementation. How do you plan to implement that ? a "virtual" container of the syslog/snmp trap stuff ? > > for the db-backend : > > - get_events : to get any IPFC XML event messages destined for us > - add_agent : to signal the dr-server there is a new agent on the > block > - remove_agent : destroy old agent > - disable_agent : make the dr-server not accept events from the agent > - enable_agent : make the dr-server accept events from the agent > - initialize_agent : make new credentials for the agent (which needs > to get them with its activate_agent function) > > > What do you think ? Yes, this could be interesting. We can also create a test case to see if we can have a generic model to keep the same functionnality model. Another point to respect is the general security of the framework. Another idea ? comments ? adulau -- Alexandre Dulaunoy -- http://www.foo.be/ 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD --- AD993-6BONE "People who fight may lose. People who not fight have already lost." Bertolt Brecht |
|
From: Tycho F. <tyc...@co...> - 2002-08-28 18:24:28
|
Hello list, it's been some time, we're not dead (yet), IPFC development is rolling on and here is just an update to the new status and what we're doing ... feel free to chime in :-) -> db-backend : events are now stored in a different way than before : now we serialize the event object and store it in a compressed format in the database. We noticed that this *does* reduce database size (ie. it's more efficient) - develop a generic query system (a la DBIx::SearchBuilder) to interrogate the database in a flexible way - develop an indexing system to speed up the queries without the overhead of having all attributes as indexed elements (which we have now) -> frontend : we're redesigning the frontend, based on the RT look (www.fsck.com/rt). It will be a lot better than the current stuff :-) -> dr-server : I'm having some wild ideas on the dr-server. I'll explain them here, then you can shoot me :-) We could make the dr-server a SOAP machine, which offers the following interface : for remote agents : - activate_agent : used when setting up the agent, so that the dr-server can send it its credentials. Goal: to make big roll-outs easier. - send_events : to send an IPFC XML event message for the db-backend : - get_events : to get any IPFC XML event messages destined for us - add_agent : to signal the dr-server there is a new agent on the block - remove_agent : destroy old agent - disable_agent : make the dr-server not accept events from the agent - enable_agent : make the dr-server accept events from the agent - initialize_agent : make new credentials for the agent (which needs to get them with its activate_agent function) What do you think ? Cheers, Tycho |
|
From: Alexandre D. <al...@co...> - 2002-05-13 11:54:11
|
Dear developer, patcher, contributor,... As you can read IPFC is moving to the jungle... euh, I mean to savannah.gnu.org We invite every developer to create an account on savannah. (So you will have access to the future cvs and so on..) Thanks for your collaboration. adulau PS : You will receive a mail when the project has been fully migrated. -- Alexandre Dulaunoy ad...@co... http://www.conostix.com/ |
|
From: Tycho F. <tyc...@co...> - 2002-04-03 13:18:16
|
Dear all, today, ipfc-1.0.4 was released. ipfc-1.0.4 features the introduction of OO. There are classes for Events, EventGroups and LogUnits, as well as database interaction. All log-parsing is now performed using classes with a standard interface. 2 correlation modules were added : Simple, which tries to correlate everything, and WithContext which is context-dependant. Shortly, there will be a 1.0.5 with cleanups and documentation fixes. As usual, downloads on http://www.conostix.com/ipfc/ -- Tycho Fruru tyc...@co... Users' impressions of different operating systems, expressed as emoticons: Linux: :) Windows: XP |
|
From: Sweth C. <log...@as...> - 2002-04-01 11:53:11
|
On Mon, Apr 01, 2002 at 01:37:07PM +0200, Alexandre Dulaunoy wrote: > > are successfully pushed. If that's true, why would you need to stop the > There is multiple way : I wasn't asking how. I was asking why. -- Sweth. -- Sweth Chandramouli Idiopathic Systems Consulting sv...@id... http://www.idiopathic.net/ |
|
From: Alexandre D. <adu...@co...> - 2002-04-01 11:37:38
|
On Sun, 31 Mar 2002, Sweth Chandramouli wrote: > On Fri, Mar 29, 2002 at 04:58:12PM +0100, Tycho Fruru wrote: > > Only caveat is that you have to stop the network part from sending out the > > messages whenever it's inconvenient. (stoppig the process works like a > > charm ;-) Messages will then remain in the outbound queue. > OK, I've grovelled through the source, and it appears that > ipfc on the client side has two daemons--one that reads the logfiles and > converts them into XML files in a queue directory, and then another that > scans that directory every ten seconds (well, with a ten second interval > between scans), and attempts to use LWP::Agent to push any XML records > found to the listening daemon on the loghost, deleting those records that > are successfully pushed. If that's true, why would you need to stop the > process (other than not wasting resources if you know that you'll be > offline for a while, and not filling the ipfc logs with messages about > failed connect attempts)? There is multiple way : * Stopping the wrapnet part is quite easy and re-starting it quite easy. (it's a separated process) kill `cat $IPFCDIR/var/wrapnet.pl.pid` and to restart it ($IPFCDIR/bin/wrapnet.pl) or * Editing the wrapnet to what you want. or * Wait for the new version (1.0.5 not 1.0.4) of the wrapper where there is multiple mode of operation : - flush everytime (aggresive mode) - try if return true (of specific external script (up interface ?)/ or function) - queue and don't flush until manual action (and call the : wrapctl flush) For the flushing method. There is also some additional method of operating for each method. (a timeout, a specific number of line or a combinaison of the two) If you have any comments don't hesitate, Free Software developement is a dynamic process ;-) Thanks. adulau -- Alexandre Dulaunoy ad...@co... http://www.conostix.com/ |
|
From: OutBack D. <di...@mi...> - 2002-03-07 20:57:16
|
Count me in..... > Dear All, > > We are planning to create multiple drafts documents of the protocol and > general framework in use for the IPFC framework. The main purpose is to > create an effective and useful documentation that can be used for other > protocols and/or other methods of logging, management and > authentification. > But that can also used to enter the "independent submissions" process of > the IETF. > > The documents will be following (for the basis) : > > * ipfc-dtd > (draft-authors-ipfc-dtd-00.txt) > > IPFC Document Type Definition is a document that defines the syntax and > the semantics of the message used in the framework to communicate with > each nodes. All message is specified in XML syntax to describe a concise > XML DTD. > > * ipfc-exchange-protocol-http > (draft-authors-ipfc-exchange-protocol-00.txt) > > IPFC Exchange Protocol using HTTP/TLS is a document that defines a > method of exchanging data, in a stateful way, between nodes. > > * ipfc-secure-logging > (draft-authors-secure-logging-00.txt) > Depends on : ipfc-dtd and ipfc-secure-logging > > IPFC Secure logging is a document that defines a method for doing secure > logging of nodes in a hostile environment using ipfc-dtd and > ipfc-exchange-protocol-http. > > More documents can be done but these documents are the basis for the > complete protocol/framework overview of the basic IPFC. > Extensions that can be done are : > > - The use of another exchange protocol > (Blocks Extensible Exchange Protocol (BXXP), SMTP/OpenPGP...) > > - The extension of the secure logging to other methods. > > - Reuse in other protocol like (for example) OpenSST. > > - and lots more... > > > So, we are looking for volunteers that want to have an active > participation into the documentation process and the reviewing of the > documents. > > Don't hesitate to contact us via the ipfc-developer-list (ipf...@li...) > > I hope we can extend the collaborative Free Software process. > > Thanks a lot. > > Alex > > -- > Alexandre Dulaunoy ad...@co... > http://www.conostix.com/ > > > > > --__--__-- > > _______________________________________________ > Ipfc-developer mailing list > Ipf...@li... > https://lists.sourceforge.net/lists/listinfo/ipfc-developer > > > End of Ipfc-developer Digest |
|
From: Alexandre D. <al...@co...> - 2002-03-07 09:28:59
|
Dear All, We are planning to create multiple drafts documents of the protocol and general framework in use for the IPFC framework. The main purpose is to create an effective and useful documentation that can be used for other protocols and/or other methods of logging, management and authentification. But that can also used to enter the "independent submissions" process of the IETF. The documents will be following (for the basis) : * ipfc-dtd (draft-authors-ipfc-dtd-00.txt) IPFC Document Type Definition is a document that defines the syntax and the semantics of the message used in the framework to communicate with each nodes. All message is specified in XML syntax to describe a concise XML DTD. * ipfc-exchange-protocol-http (draft-authors-ipfc-exchange-protocol-00.txt) IPFC Exchange Protocol using HTTP/TLS is a document that defines a method of exchanging data, in a stateful way, between nodes. * ipfc-secure-logging (draft-authors-secure-logging-00.txt) Depends on : ipfc-dtd and ipfc-secure-logging IPFC Secure logging is a document that defines a method for doing secure logging of nodes in a hostile environment using ipfc-dtd and ipfc-exchange-protocol-http. More documents can be done but these documents are the basis for the complete protocol/framework overview of the basic IPFC. Extensions that can be done are : - The use of another exchange protocol (Blocks Extensible Exchange Protocol (BXXP), SMTP/OpenPGP...) - The extension of the secure logging to other methods. - Reuse in other protocol like (for example) OpenSST. - and lots more... So, we are looking for volunteers that want to have an active participation into the documentation process and the reviewing of the documents. Don't hesitate to contact us via the ipfc-developer-list (ipf...@li...) I hope we can extend the collaborative Free Software process. Thanks a lot. Alex -- Alexandre Dulaunoy ad...@co... http://www.conostix.com/ |
|
From: Tycho F. <tyc...@co...> - 2002-02-26 22:21:40
|
On Tue, 26 Feb 2002, Alexandre Dulaunoy wrote: > > We need to find people for making documentation. Often, they don't have > the "time" or the "power" to use CVS . So the SF interface is not perfect, > but it's open to documentation people. > > Maybe my wiki could be used for that purpose and it's more flexible. > > http://null.foo.be/ I like that better > > alx > > > On Tue, 26 Feb 2002, Tycho Fruru wrote: > > > Perhaps Im stupid, but why don't we just use the CVS ? > > > > SF.net's interface is not exactly UF ... > > > > Cheers > > Tycho > > > > > > On Mon, 25 Feb 2002, Alexandre Dulaunoy wrote: > > > > > Hello, > > > > > > The documentation part of IPFC seems to be very important (as we see in > > > some email ;-). Here is a small TODO for the documentation : > > > > > > INSTALL > > > > > > * INSTALL-DBBACKEND > > > Description: How to install a dbbackend > > > * INSTALL-DRSERVER > > > Description: How to install a dr-server. > > > * INSTALL-WRAPPER > > > Description: Guide for installing IPFC wrapper on various platform > > > > > > RFC > > > > > > * DRAFT-IPFC-SECURE-LOGGING > > > Description: IPFC Secure logging > > > * DRAFT-IPFC-DTD > > > Description: IPFC Document Type Definition > > > * DRAFT-IPFC-EXCHANGE-PROTOCOL-HTTP > > > Description: IPFC Exchange protocol using HTTP > > > > > > You can directly edit/create/update these documents on the sourceforge > > > site. https://sourceforge.net/docman/index.php?group_id=19759 > > > > > > If there are some people who want to care of the documentation part, don't > > > hesitate. > > > > > > I hope we can have a complete documentation by the end of may. (ok this > > > looks like a deadline ;-)) > > > > > > thanks. > > > > > > alx > > > > > > > > > > > > > > > > > > -- Tycho Fruru tyc...@co... Users' impressions of different operating systems, expressed as emoticons: Linux: :) Windows: XP |
|
From: Alexandre D. <adu...@ma...> - 2002-02-26 21:44:02
|
We need to find people for making documentation. Often, they don't have the "time" or the "power" to use CVS . So the SF interface is not perfect, but it's open to documentation people. Maybe my wiki could be used for that purpose and it's more flexible. http://null.foo.be/ alx On Tue, 26 Feb 2002, Tycho Fruru wrote: > Perhaps Im stupid, but why don't we just use the CVS ? > > SF.net's interface is not exactly UF ... > > Cheers > Tycho > > > On Mon, 25 Feb 2002, Alexandre Dulaunoy wrote: > > > Hello, > > > > The documentation part of IPFC seems to be very important (as we see in > > some email ;-). Here is a small TODO for the documentation : > > > > INSTALL > > > > * INSTALL-DBBACKEND > > Description: How to install a dbbackend > > * INSTALL-DRSERVER > > Description: How to install a dr-server. > > * INSTALL-WRAPPER > > Description: Guide for installing IPFC wrapper on various platform > > > > RFC > > > > * DRAFT-IPFC-SECURE-LOGGING > > Description: IPFC Secure logging > > * DRAFT-IPFC-DTD > > Description: IPFC Document Type Definition > > * DRAFT-IPFC-EXCHANGE-PROTOCOL-HTTP > > Description: IPFC Exchange protocol using HTTP > > > > You can directly edit/create/update these documents on the sourceforge > > site. https://sourceforge.net/docman/index.php?group_id=19759 > > > > If there are some people who want to care of the documentation part, don't > > hesitate. > > > > I hope we can have a complete documentation by the end of may. (ok this > > looks like a deadline ;-)) > > > > thanks. > > > > alx > > > > > > > > > > -- Alexandre Dulaunoy ad...@co... http://www.conostix.com/ |
|
From: Tycho F. <tyc...@co...> - 2002-02-26 16:49:42
|
Perhaps Im stupid, but why don't we just use the CVS ? SF.net's interface is not exactly UF ... Cheers Tycho On Mon, 25 Feb 2002, Alexandre Dulaunoy wrote: > Hello, > > The documentation part of IPFC seems to be very important (as we see in > some email ;-). Here is a small TODO for the documentation : > > INSTALL > > * INSTALL-DBBACKEND > Description: How to install a dbbackend > * INSTALL-DRSERVER > Description: How to install a dr-server. > * INSTALL-WRAPPER > Description: Guide for installing IPFC wrapper on various platform > > RFC > > * DRAFT-IPFC-SECURE-LOGGING > Description: IPFC Secure logging > * DRAFT-IPFC-DTD > Description: IPFC Document Type Definition > * DRAFT-IPFC-EXCHANGE-PROTOCOL-HTTP > Description: IPFC Exchange protocol using HTTP > > You can directly edit/create/update these documents on the sourceforge > site. https://sourceforge.net/docman/index.php?group_id=19759 > > If there are some people who want to care of the documentation part, don't > hesitate. > > I hope we can have a complete documentation by the end of may. (ok this > looks like a deadline ;-)) > > thanks. > > alx > > > > -- Tycho Fruru tyc...@co... Users' impressions of different operating systems, expressed as emoticons: Linux: :) Windows: XP |