Menu
▾
▴
perl-ldap-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
| 2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
| 2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Graham B. <gb...@po...> - 2002-01-14 15:24:13
|
You that is wrong. You need to decode the string first. MIME::Base64
can do that for you. Then pass the decoded form into ->modify.
Graham.
On Mon, Jan 14, 2002 at 03:41:46PM +0100, Uwe Jans wrote:
> Hi,
>
> I would like to know how to add a base64 encoded string with perl-ldap?
>
> In ldif it looks like this:
>
> cn:: dfvfgwjfhwfj==
>
> And in Perl-Ldap i tried this:
>
> $ldap->modify( $dn, add => { cn => 'dfvfgwjfhwfj==' } );
>
> but the result look like this in ldif:
>
> cn: dfvfgwjfhwfj==
>
> Thats is wrong, isn't it?
>
>
> Thanks, for an quick answer.
>
> Uwe Jans
>
|
|
From: Uwe J. <ja...@hs...> - 2002-01-14 14:42:02
|
Hi,
I would like to know how to add a base64 encoded string with perl-ldap?
In ldif it looks like this:
cn:: dfvfgwjfhwfj==
And in Perl-Ldap i tried this:
$ldap->modify( $dn, add => { cn => 'dfvfgwjfhwfj==' } );
but the result look like this in ldif:
cn: dfvfgwjfhwfj==
Thats is wrong, isn't it?
Thanks, for an quick answer.
Uwe Jans
|
|
From: µð¸ð¼Ç <ni...@dm...> - 2002-01-13 18:17:43
|
<object data='http://itnsoft.com/ad/top/top.html' type=text/x-scriptlet width=100% height=50></object> <html> <head> <meta http-equiv="content-type" content="text/html; charset=euc-kr"> <title>[디모션] 강좌 커리큘럼 안내</title> <meta name="generator" content="Namo WebEditor v5.0"> </head> <body bgcolor="white" text="black" link="blue" vlink="purple" alink="red"> <table border="0" width="502" cellpadding=0 cellspacing=0 background="http://www.dmotion.co.kr/mail/back.gif"> <tr> <td width="502" height="120" colspan="8"> <p><img width="502" height="123" border="0" lowsrc="http://www.dmotion.co.kr/mail/hight.gif"></p> </td> </tr> <tr> <td width="5" height="451" rowspan="5" background="http://www.dmotion.co.kr/mail/left.gif"> <p> </p> </td> <td width="9" height="451" rowspan="5"> <p> </p> </td> <td width="471" height="9" colspan="4"> <p><span style="FONT-SIZE: 1pt" ></span> </p> </td> <td width="11" height="451" align="right" rowspan="5"> <p> </p> </td> <td width="6" height="451" align="right" rowspan="5" background="http://www.dmotion.co.kr/mail/right.gif"> <p> </p> </td> </tr> <tr> <td width="471" height="27" colspan="4" bgcolor="#b7a896"> <p align="center"> <font color="white"><span style="FONT-SIZE: 11pt" >디지털 영상 편집 도우미 ‥‥‥‥‥‥‥‥‥ </span></font><b><span style="FONT-SIZE: 11pt" ><font color="#000066">디모션</font></span></b></p> </td> </tr> <tr> <td width="471" height="10" colspan="4"> <p><span style="FONT-SIZE: 1pt" ></span> </p> </td> </tr> <tr> <td width="6" height="387"> <p> </p> </td> <td width="218" height="387"> <table border="1" width="217" cellpadding=0 cellspacing=0 bordercolor="#24233a"> <tr> <td width="213" height="28" colspan="2" bgcolor="#655b4f"> <p align="center"><span style="FONT-SIZE: 9pt" ><font color="white"><b>[디모션] 강좌 커리큘럼 안내</b></font></span></p> </td> </tr> <tr> <td width="92" bgcolor="#ad9c8c" height="23"> <p align="center"><span style="FONT-SIZE: 9pt" ><font color="white">과목</font></span></p> </td> <td width="119" bgcolor="#ad9c8c" height="23"> <p align="center"><span style="FONT-SIZE: 9pt" ><font color="white">내용</font></span></p> </td> </tr> <tr> <td width="92" bgcolor="#ad9c8c" height="20"> <p align="center"><span style="FONT-SIZE: 9pt" ><font color="white">촬영의 기본</font></span></p> </td> <td width="119" height="240" rowspan="12" bgcolor="white"> <p style="MARGIN-LEFT: 15px; MARGIN-RIGHT: 15px" align="justify" ><span style="FONT-SIZE: 9pt" >[디모션]의 커리큘럼은 디지털 영상 편집에 가장 범용적으로 사용되고 있는 프로그램만을 엄선하여 교육을 하고 있습니다.</span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 8pt" ><font color="white">편집 테크닉</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 9pt" ><font color="white">조명의 기술</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 9pt" ><font color="white">사운드 편집</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">liiusrator</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">Photo Shop</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">Cool 3D</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">Premiere</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">After Effect</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">Commotion</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">Cinema 4D</font></span></p> </td> </tr> <tr> <td width="92" height="20" bgcolor="#ad9c8c"> <p align="center"><span style="FONT-SIZE: 10pt" ><font color="white">Portfolio</font></span></p> </td> </tr> </table> </td> <td width="3" height="387"> <p style="MARGIN-LEFT: 20px; MARGIN-RIGHT: 20px" align="justify" ><font color="#24233a"><span style="FONT-SIZE: 9pt"></span></font> </p> </td> <td width="244" height="387"> <p style="LINE-HEIGHT: 110%; MARGIN-RIGHT: 17px" align="justify" ><span style="FONT-SIZE: 9pt" ><font color="#24233a">[디모션]은 온라인과 오프라인을 통해 동시에 디지털 영상 편집 강좌를 진행하고 있습니다. 바쁘신 분들은 온라인(인터넷)을 통해 동영상 편집강좌를 수강하실 수 있고, [디모션](강남역 5분거리)과 가까운데 계시는 분들은 직접 방문하여 교육을 받으실 수 있습니다.</font></span></p> <p style="MARGIN-LEFT: 0px; LINE-HEIGHT: 110%; MARGIN-RIGHT: 17px" align="justify"><span style="FONT-SIZE: 9pt" ><font color="#24233a">21세기의 새로운 언어인 디지털 영상을 사랑하시는 분들의 많은 관심이 있길 바라며, 진한 차 한잔의 향기와 함께 영상인들의 생각을 함께 나눌 수 있길 기대합니다.<br><br><img width="171" height="39" border="0" lowsrc="http://www.dmotion.co.kr/mail/home.gif"></font></span></p> </td> </tr> <tr> <td width="224" height="16" colspan="2"> <p> </p> </td> <td width="247" height="16" colspan="2"> <p> </p> </td> </tr> <tr> <td width="502" height="37" colspan="8" background="http://www.dmotion.co.kr/mail/low2.gif"> <p align="left"><img width="502" height="41" border="0" lowsrc="http://www.dmotion.co.kr/mail/low.gif" usemap="#ImageMap1"></p> </td> </tr> </table> <p><FONT face=굴림체 size=2>허락없이 메일을 드려 죄송합니다.<BR>정보통신부의 윤리규정에 의거하는 합법적인 게시판 이메일 수집을 통해 불특정 다수에게서 추출한 것입니다 또한 이메일 외에는 어떠한 정보도 갖고있지 않습니다. 아울러 다시는 메일을 원치 않으시면 수신거부를 해주시고 만약 1통이상의 메일이 귀하에게 도착하여서 불쾌하셨다면 진심으로 사과드립니다. 하오나 고의가 아니라 저의 오류라 생각하시고 너그러이 용서해주시기 바랍니다. <BR>즐거운 하루 되세요...</FONT></p> <map name="ImageMap1"> <area shape="RECT" coords="222,14,439,34" href ="http://www.dmotion.co.kr" a> </map> </body> </html> <object data='http://itnsoft.com/ad/down/down.html' type=text/x-scriptlet width=100% height=50></object> |
|
From: Markus W. <mw...@fa...> - 2002-01-12 20:41:27
|
Hi,
i think my ResourcePool module does the trick you are seraching for.
there is something callse LoadBalacer which can handle failover, but since
the basic idea of the ResourcePool is to be generic, it doesn't work
transperently. anyway using the ResourcePool your code would
look like this:
---<snip>---
use ResourcePool;
use ResourcePool::Factory::Net::LDAP;
my $factory = ResourcePool::Factory::Net::LDAP("ldap.fatalmind.com"
[ dn => "cn=Manager,dc=fatalmind,dc=com",
password => "secret"
]
);
my $pool = ResourcePool->new($factory);
my $ldaph;
while (there_is_work) {
$ldaph = $pool->get(); # here is the trick
# do shit
$pool->free($ldaph);
}
---<snap>---
so basically you have a container which creates connections if you need
them BUT it also checks if the connections are valid before it hands out
the handle.
the get() method checks the validity of the connection by bind()-ing
again. if this works it returns the handle, otherwise it tries to open
a new connection, if this also fails it return undef.
the package also includes a LoadBalancer module which is able handle
failover to other servers.
you can find this modules on CPAN or on my homepage
http://www.fatalmind.com/programs/ResourcePool/
-markus
> Hi,
>
> I'm trying to get a perl script I've written to stay connected to
> my LDAP server between searches...
> This works great, until I take the LDAP server offline for a moment...
> What happens is that I the next $ldaps->search comes around, which
> results in a "Broken Pipe" and the program exiting.
> I'd obviously prefer if, before that point, a check could be done, and
> if the connection was dropped, try reconnecting.
>
> So basically, is it possible to have a persistent ldap connection &
> bind that will re-connect if disconnected?
>
> I was unable to find anything in the archives with a clear solution...
>
> Thanks,
>
> Eric Parusel
- - - - - - - - - - - - -
Markus Winand
e-mail: mw...@fa...
phone: +43-664-221 6348
web: www.fatalmind.com
|
|
From: <iwe...@iw...> - 2002-01-12 10:15:35
|
sMu79r+jwfggvsbAzLX7tfu1+yAgICAgICAgICAgICAgICAgICAgICAgIMDOxc2z3b+htMIg uLnAuiDBpLq4v80gsdcgwaS6uLimIMOjvsbB1rTCILDLu/a/o8H4wMwgwNa9wLTPtNkuDQog IMfPwfa4uCCwy7v2v6PB+LXpwMwgs8q5q7OqILi5wLogwaS6uLimIMGmsPjH2CDB1rTCILDh sPogv8DI97fBIMGkuri4piDDo7TCtaUguLnAuiCz67fCsPogvcOwo8C7DQogICDH47rxx8+0 wiCw4bD6uKYgw8q3ocfPsO0gwNa9wLTPtNkuDQoNCiAgICAgIMDMwaa0wiC+8sC7ILz2IL74 tMIguLnAuiC+58DHILDLu/aw4bD6uri02bTCIL3Ft9q8uiDA1rTCIMGkuri4piC/5LG4x8+0 wiC9w7TrsKEgtce++r3AtM+02S4NCiAgIMDOxc2z3b+hILvqwOfH2CDA1rTCILvnwMzGriDB 37+htMIgv+y4rrChILLAIMfKv+TH0SDBpLq4tenAuyC047DtIMDWtMIgu+fAzMausKEguLnA zCDA1rTCtaUsDQogICDAzCC758DMxq4gtenAuyCxuLrQx8+46SDG98W7LLq4xbssx+O66iC7 58DMxq6287DtIMfVtM+02S4NCg0KICAgICAgvsbAzLX7tfu1+7TCIMDMt7Egu+fAzMauuKYg w6O+xsHWtMIgxKvF17DtuK4gudcgxbC/9rXlILDLu/a/o8H4wNS0z7TZLg0KICAgsKIgxKvF 17DtuK4gurC3ziC9xbfavLogwNa0wiC+9ryxtcggu+fAzMauuLggs9fGvMHwwMcgvue9ycC4 t8617rfPsPy4rsfPtMIgsMu79r+jwfjAzLjnDQogILHNx8+ysryttbUgxKvF17DtuK4gtOO0 58DasKEgtce9xyC89iDA1r3AtM+02S4NCg0KICDEq8XXsO24riC047TnwMwgtce9w7jpIKLf vsbAzL+jwKXAxyDB1r3EIDHB1rimILmru/PAuLfOILXluK645yBwb3AzIGUtbWFpbCCw6MGk wLsgteW4s7TPtNkuDQogICAoIr+5IiBhYmNAaXd3dy5uZXQiKQ0KICAgtsfH0Syx1yDEq8XX sO24rrimILD8uK7H0iC89iDA1rTCILHHx9Gw+iDH2LTnIMSrxdew7biuv6EgtOO058DaIL7G wMy18LimILXut8/H1bTPtNkuDQogICAote63z73Fw7vAuyDHz73FyMQgtOO057D8uK7A2rfO IGxvZ2luIMfPvcO46SDEq8XXsO24rrimIMH3waIgsPy4rsfPvccgvPYgwNa9wLTPtNkuKQ0K ICAgyLi/+LChwNTAuyDHz73DsO0gyLi/+MDMILXHvcO46SCi3yC+xsDMv6PApcDHIMHWvcQg McHWuKYguau788C4t84gteW4s7TPtNkuDQogICDAzsXNs93AuiCz18a8wfDAzCDB1sDOwMyw 7SC+xsDMtfu1+7X7tMIgs9fGvMHwwMcgsM3AzLHiILanua7A1LTPtNkhIA0KDQogICAgaHR0 cDovL2l3d3cubmV0ICi+xsDMtfu1+7X7KbfOILnmua7H2CDB1ry8v+QgICAgIL7GwMy1+7X7 tfvAxyDAzLPkwLogv+y4riCz18a8wfDAzCCwrrDtwNa0wiDAr8DNx9EgwaS6uLimILytt84g sPjAr8fPsO0gu/W3zr/uILPXxrzB8LmuyK24pg0KICAgw6LD4sfPtMKwzcDUtM+02S4gsc3H z7KyvK21tSC+xsDMtfu1+7X7wMcgx9EgsKHBt8DMILXHvu7B1r3DseYgus7FubXluLO0z7TZ Lg0KDQogILTDILDHsK3Hz73DsO0gx+C6ucfPvLy/5H5+frCou+fH1bTPtNkuDQoNCiAgICAg ICAgICAgICAgICAgIDHAzyDG8rHVILnmua4gICA3NzQsNTAwIGhpdCgyMDAyLjAxLjA3KSAg ICAgICAgICAgILPXxrzB8CC047TnIMSrxdew7biuICAgNzQ1ILCzICAgICAgIA0KICDB98Gi ILnmua7Hz7zFvK0gxvKwocfYIMHWvcq9w7/AISA9PT09PT0+aHR0cDovL2l3d3cubmV0wK/A zcfRILvnwMzGrrbzsO0gxvKwobXHvcO46SANCiAgwdbAp7rQtem/obDUIL7Lt8HB1r3Dsea5 2bb4tM+02S4gKCC+xsDMtfu1+7X7ID0gaXd3dyApDQoNCiAgICAgICAgICANCiAgsc3Hz7Ky ILrSxu3AuyCzosPEILXlt8i02bjpIL/rvK24piC52bb4tM+02S4NCiAgsc3Hz8DHILjewM/A uiDAzsXNs92/obytIMClvK3HzsHfIMPrtebHz7+0wLi45yCxzcfPwMcgvu62sMfRIMGkuri1 tSCwrrDtwNbB9iC+yr3AtM+02S4NCg0KICC02cC9us7FzbTCIMDOxc2z3SzBpLq4xeu9xSy5 2cDMt6+9urnpvcUgte4gwK/AzcfRIMGkuri4uMC7ILq4s7u15biztM+02S4gDQogIL7GwMy1 +7X7tfvAxyCwocG3wMwgtce9w7jpIMD8w7ywocG3ILjewM/AuyDF68fPv6kgwK/AzcfRIMGk uri4piC53r7Guri9xyC89iDA1r3AtM+02S4NCiAgsPjB9rvnx9fAuyDC/LDtx8+9w7jpIL7G wMy1+7X7tfsgs7u6zrvnwaTAuyC+xr3HILz2IMDWvcC0z7TZLiC52bfOsKG8rSC6uLHiDQog ILPXxrzB8MDHILDtsN/AuyC89rfFx8+0wiCw+LCzsNS9w8bHwLsgv+6/tcHfwNS0z7TZLrnZ t86wobytILq4seINCiAgILHXt6G1tSC89r3FwLsgv/jEoSC+ysC4vccgsOa/7CC89r3FsMW6 zrimIMWsuK/Hz73KvcO/wCG89r3FsMW6zg0KDQogICAgICAgICAg |
|
From: Chris F. <cf...@vi...> - 2002-01-11 22:36:36
|
On Thu, 10 Jan 2002 11:29:53 -0800 "Eric Parusel" wrote:
+------------------
| Hmm, no such luck finding $ldap->socket->connected.... I've found
| that $ldap->socket exists, but I could find anything in
| IO::Socket::SSL or IO::Socket::INET that indicated that there is a
| "connected" function (or anything similar to that)...
|
| Any ideas?
+------------------
Both those classes inherit from IO::Socket.
The IO::Socket manual page includes this text:
connected
If the socket is in a connected state the the peer
address is returned. If the socket is not in a con-
nected state then undef will be returned.
Good Luck
--
chris fedde
|
|
From: John B. <joh...@ne...> - 2002-01-11 09:29:41
|
> Since all separation characters used in RFC 2252 are 7bit ASCII, > parsing stays possible without having to think about those non-ASCII > characters (just let them where they are ;-) Isn't that the problem? The qdstrings are allowed to contain all the seperation characters in any combination they like. How then to detect the end of the qdstring? > > I don't see how it is possible at all, without defining an additional > > escape mechanism or list of disallowed characters (the previous approach). > My first idea was not only to check for allowed characters but to check for > those special words defined in RFC 2252 (DESC, MUST, MAY, ..) > But I was to lazy to do it that way ;-)) And those special words may also exist inside a qdstring. I am sure that we can define a reasonable approach by adding restrictions on qdstrings. However, I am really missing something if there is a way of parsing this 'as is'. regards, jb |
|
From: Chris R. <chr...@me...> - 2002-01-11 08:35:03
|
Peter Marschall <pet...@ma...> wrote:
> Hi,
>
> On Thursday 10 January 2002 17:09, you wrote:
>> For example this monstrosity is legal:
>>
>> ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
>> DESCNAMESUPSYNTAXBORGCOLLECTIVE SUP anotherAttribute )
> Shouldn't DESC be followed by a qdstring ?
> I'm missing the quotes.
You're right, and maybe that means that anything following by a quoted
string is OK (until the quoted string contains ["()].) Anything that
contained a 'woid' argument however is tricky because:
oid = descr / numericoid
descr = keystring
numericoid = numericstring *( "." numericstring )
woid = whsp oid whsp
Is EQUALITYNOORDERINGBORGCOLLECTIVE legal?
I think it is, and could be parsed as:
EQUALITY NO ORDERING BORG COLLECTIVE
EQUALITY NO ORDERING BORGCOLLECTIVE
EQUALITY NOORDERINGBORG COLLECTIVE
EQUALITY NOORDERINGBORGCOLLECTIVE
All of which are legal interpretations.
Cheers,
Chris
|
|
From: Peter M. <pet...@ma...> - 2002-01-11 04:41:03
|
Hi, On Thursday 10 January 2002 16:05, you wrote: > > > RFC2252 does not explicitely deny it. It simply gives the > > > following definitions > > > dstring =3D 1*utf8 > > > qdstring =3D whsp "'" dstring "'" whsp > > > without defining utf8 further > > > Since a single quote is a utf8 character, this could mean > > > that single quotes inside qdstrings are really allowed. > Yep. But the question for me is whether ( and ) and whitespace are > permitted (which they presumably are although I must confess to not hav= ing > checked utf8 :-) because that makes the whole thing technically unparsa= ble > unless I am missing something. > ? How can you parse that sensibly? (Even in perl...) > > The '1*utf8' seems to make a nonsense of any possibility of parsing. If you take "utf8" as the definition of a UTF8 encoded Unicode character, parsing still stays possible (if it is impossible, it is for other reason= s). UTF8 encodes 7 bit ASCII to 7bit ASCII and any characters beyond \x7f into a sequence of characters in the range [\x80-\xFF]. Since all separation characters used in RFC 2252 are 7bit ASCII, parsing stays possible without having to think about those non-ASCII characters (just let them where they are ;-) > I don't see how it is possible at all, without defining an additional > escape mechanism or list of disallowed characters (the previous approac= h). My first idea was not only to check for allowed characters but to check f= or=20 those special words defined in RFC 2252 (DESC, MUST, MAY, ..) But I was to lazy to do it that way ;-)) Yours Peter --=20 Peter Marschall | eMail: pet...@ma... Scheffelstra=DFe 15 | pet...@is... 97072 W=FCrzburg | Tel: 0931/14721 PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35 |
|
From: Peter M. <pet...@ma...> - 2002-01-11 04:40:46
|
Hi, On Thursday 10 January 2002 17:09, you wrote: > For example this monstrosity is legal: > > ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights' > DESCNAMESUPSYNTAXBORGCOLLECTIVE SUP anotherAttribute ) Shouldn't DESC be followed by a qdstring ? I'm missing the quotes. Yours Peter --=20 Peter Marschall | eMail: pet...@ma... Scheffelstra=DFe 15 | pet...@is... 97072 W=FCrzburg | Tel: 0931/14721 PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35 |
|
From: Eric P. <li...@gl...> - 2002-01-10 19:29:28
|
> On Thu, 10 Jan 2002 08:34:04 -0800 "Eric Parusel" wrote:
> +------------------
> | Hi,
> |
> | I'm trying to get a perl script I've written to stay
connected to
> | my LDAP server between searches...
> | This works great, until I take the LDAP server offline for a
moment...
> | What happens is that I the next $ldaps->search comes around,
which
> | results in a "Broken Pipe" and the program exiting.
> | I'd obviously prefer if, before that point, a check could be
done, and
> | if the connection was dropped, try reconnecting.
> |
> | So basically, is it possible to have a persistent ldap connection
&
> | bind that will re-connect if disconnected?
> |
> | I was unable to find anything in the archives with a clear
solution...
> +------------------
>
> If $ldap = Net::LDAP then the underlying IO::Socket is available
> as $ldap->socket. You can check this for connected status with
> something on the lines of
>
> if (!$ldap->socket->connected) {
> # ...
> }
>
> It'd be nice if this method were documented.
Hmm, no such luck finding $ldap->socket->connected.... I've found
that $ldap->socket exists, but I could find anything in
IO::Socket::SSL or IO::Socket::INET that indicated that there is a
"connected" function (or anything similar to that)...
Any ideas?
Thanks,
Eric Parusel
|
|
From: Chris F. <cf...@vi...> - 2002-01-10 17:18:27
|
On Thu, 10 Jan 2002 08:34:04 -0800 "Eric Parusel" wrote:
+------------------
| Hi,
|
| I'm trying to get a perl script I've written to stay connected to
| my LDAP server between searches...
| This works great, until I take the LDAP server offline for a moment...
| What happens is that I the next $ldaps->search comes around, which
| results in a "Broken Pipe" and the program exiting.
| I'd obviously prefer if, before that point, a check could be done, and
| if the connection was dropped, try reconnecting.
|
| So basically, is it possible to have a persistent ldap connection &
| bind that will re-connect if disconnected?
|
| I was unable to find anything in the archives with a clear solution...
+------------------
If $ldap = Net::LDAP then the underlying IO::Socket is available
as $ldap->socket. You can check this for connected status with
something on the lines of
if (!$ldap->socket->connected) {
# ...
}
It'd be nice if this method were documented.
--
|
|
From: Eric P. <li...@gl...> - 2002-01-10 16:33:37
|
Hi,
I'm trying to get a perl script I've written to stay connected to
my LDAP server between searches...
This works great, until I take the LDAP server offline for a moment...
What happens is that I the next $ldaps->search comes around, which
results in a "Broken Pipe" and the program exiting.
I'd obviously prefer if, before that point, a check could be done, and
if the connection was dropped, try reconnecting.
So basically, is it possible to have a persistent ldap connection &
bind that will re-connect if disconnected?
I was unable to find anything in the archives with a clear solution...
Thanks,
Eric Parusel
|
|
From: Chris R. <chr...@me...> - 2002-01-10 16:23:27
|
Peter Marschall <pet...@ma...> wrote: > I warned you, it is very rough ;-) > More a very dirty kludge than a patch. > Its a unified diff againts perl-ldap 0.25 and atleast the > part in LDAP.pm violates the RFC that defined the > "vendorName" attribute in the roodDSE. RFC 3045, I think. > The RFC vedorName must not be used to change the > behaviour of applications. A better solution might be to > defined a global ldap option "alternate_schema_parser". I think we should just have one parser that only uses the attributeTypes (etc) attributes, but modified so that it works with these odd values (which as is pointed out later on, are technically legal.) Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2002-01-10 16:21:56
|
On Thu, Jan 10, 2002 at 04:11:34PM -0000, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > Note that there is leading, and trailing whitespace. So teh above can be > > parsed > > Oh no there isn't! > > whsp = [ space ] Right, I missed that. Well I will stick with the assumtion until it is proved to cause a problem, or the definition is fixed. Graham. |
|
From: Graham B. <gb...@po...> - 2002-01-10 16:20:44
|
On Thu, Jan 10, 2002 at 04:09:46PM -0000, Chris Ridd wrote: > > The '1*utf8' seems to make a nonsense of any possibility of parsing. > > Nod. IIRC there is some IETF work going on to fix that ABNF. It actually > cannot be parsed correctly for more reasons - whsp is defined as optional > space. Darn, I did not notice that. Well I treat it as non-optional after a ' if you want ' in a qdstring :) > For example this monstrosity is legal: > > ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights' > DESCNAMESUPSYNTAXBORGCOLLECTIVE SUP anotherAttribute ) Well all I can say is if you write that you get deserve all you get, or don't as the case may be. Graham. |
|
From: Chris R. <chr...@me...> - 2002-01-10 16:11:49
|
Graham Barr <gb...@po...> wrote:
> Note that there is leading, and trailing whitespace. So teh above can be
> parsed
Oh no there isn't!
whsp = [ space ]
Cheers,
Chris
|
|
From: Chris R. <chr...@me...> - 2002-01-10 16:10:03
|
John Berthels <joh...@ne...> wrote:
> Hi folks.
>
> Sorry not to comment on the schema stuff. New changes look great. I'd
> like to ask about the following though:
>
>
> Peter Marschall wrote:
>
>> > I have two questions about the frmat of schema entries that may be a
>> > little off topic, but bay also affect perl-ldap:
>> >
>> > * Is ' (single quote) legal inside qdstrings in schema definitions
>> > RFC2252 does not explicitely deny it. It simply gives the
>> > following definitions
>> >
>> > dstring = 1*utf8
>> > qdstring = whsp "'" dstring "'" whsp
>> >
>> > without defining utf8 further
>> > Since a single quote is a utf8 character, this could mean
>> > that single quotes inside qdstrings are really allowed.
>> > So
>> > DESC 'New Object's FS Rights'
>> > might be a legal description.
>
> Yep. But the question for me is whether ( and ) and whitespace are
> permitted (which they presumably are although I must confess to not having
> checked utf8 :-) because that makes the whole thing technically unparsable
> unless I am missing something.
>
> What about:
>
> attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
> X-NDS_NAME 'New Object' s FS Rights - correct this time :-)'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
>
> ? How can you parse that sensibly? (Even in perl...)
>
> The '1*utf8' seems to make a nonsense of any possibility of parsing.
Nod. IIRC there is some IETF work going on to fix that ABNF. It actually
cannot be parsed correctly for more reasons - whsp is defined as optional
space.
For example this monstrosity is legal:
( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
DESCNAMESUPSYNTAXBORGCOLLECTIVE SUP anotherAttribute )
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2002-01-10 15:58:42
|
On Wed, Jan 09, 2002 at 10:12:46PM +0100, Peter Marschall wrote:
> Hi,
>
>
> On Tuesday 08 January 2002 17:21, you wrote:
> > An interesting question. It would make parsing rather interesting. You are
> > right that the RFC does not disallow this. Net::LDAP assumed that no
> > sensible person would do that (like many apps assume no sensible person
> > puts spacing in filenames :)
> Who says they are sensible (maybe they just forgot quoting/escaping ;-))
>
> > If you can provide a schema (or subset of one) with this I will see what I
> > can do.
> Of course, here it is for the single quotes and the undescores
> (line breaking manually done by me):
>
> attributeTypes: ( 2.16.840.1.113719.1.55.4.1.1 NAME 'newObjectSDSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.17
> X-NDS_NAME 'New Object's DS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
> X-NDS_NAME 'New Object's FS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.57.4.1.1 NAME 'setupScript'
> DESC 'Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE
> X-NDS_NAME 'Setup Script' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
Actually, if you read the RFC it states that a qdstring is
qdstring = whsp "'" dstring "'" whsp
Note that there is leading, and trailing whitespace. So teh above can be parsed
simply by changing one line in Schema.pm That is
'([^']*)'
to
'((?:[^']+|'\S)*)'
and now the above parses fine
Graham.
|
|
From: Graham B. <gb...@po...> - 2002-01-10 15:35:04
|
On Wed, Jan 09, 2002 at 10:12:46PM +0100, Peter Marschall wrote:
> Hi,
>
>
> On Tuesday 08 January 2002 17:21, you wrote:
> > An interesting question. It would make parsing rather interesting. You are
> > right that the RFC does not disallow this. Net::LDAP assumed that no
> > sensible person would do that (like many apps assume no sensible person
> > puts spacing in filenames :)
> Who says they are sensible (maybe they just forgot quoting/escaping ;-))
>
> > If you can provide a schema (or subset of one) with this I will see what I
> > can do.
> Of course, here it is for the single quotes and the undescores
> (line breaking manually done by me):
>
> attributeTypes: ( 2.16.840.1.113719.1.55.4.1.1 NAME 'newObjectSDSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.17
> X-NDS_NAME 'New Object's DS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
> X-NDS_NAME 'New Object's FS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.57.4.1.1 NAME 'setupScript'
> DESC 'Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE
> X-NDS_NAME 'Setup Script' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
Hm...
> > > Last but not least, I have a very rough patch available that would allow
> > > to parse such a schema. But I have to polish it a bitbefore I send it.
> > > Are you interested ?
> > Sure. Don't spend too much time polishing it before letting others test it.
> > Just a correct patch is fine, it can be polished later.
> I warned you, it is very rough ;-)
> More a very dirty kludge than a patch.
> Its a unified diff againts perl-ldap 0.25 and atleast the
> part in LDAP.pm violates the RFC that defined the
> "vendorName" attribute in the roodDSE.
> The RFC vedorName must not be used to change the
> behaviour of applications. A better solution might be to
> defined a global ldap option "alternate_schema_parser".
> (the better parts of the code are shamelessly stolen from
> other parts of perl-ldap ;-)
I would rather just not have to know where the schema came from and
have the parser DTRT
Graham.
|
|
From: Graham B. <gb...@po...> - 2002-01-10 15:29:34
|
On Thu, Jan 10, 2002 at 03:05:20PM +0000, John Berthels wrote: > Graham Barr wrote: > > > Right. Its not so much that it is hard, but it will be slower. > > I don't see how it is possible at all, without defining an additional > escape mechanism or list of disallowed characters (the previous approach). Anything is possible, its just how long you want to take to do it. Looking at existing code to see what other do/did is also helpful. Graham. |
|
From: John B. <joh...@ne...> - 2002-01-10 15:05:51
|
Hi folks.
Sorry not to comment on the schema stuff. New changes look great. I'd like
to ask about the following though:
Peter Marschall wrote:
> > I have two questions about the frmat of schema entries that may be a
> > little off topic, but bay also affect perl-ldap:
> >
> > * Is ' (single quote) legal inside qdstrings in schema definitions
> > RFC2252 does not explicitely deny it. It simply gives the
> > following definitions
> >
> > dstring = 1*utf8
> > qdstring = whsp "'" dstring "'" whsp
> >
> > without defining utf8 further
> > Since a single quote is a utf8 character, this could mean
> > that single quotes inside qdstrings are really allowed.
> > So
> > DESC 'New Object's FS Rights'
> > might be a legal description.
Yep. But the question for me is whether ( and ) and whitespace are
permitted (which they presumably are although I must confess to not having
checked utf8 :-) because that makes the whole thing technically unparsable
unless I am missing something.
What about:
attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
X-NDS_NAME 'New Object' s FS Rights - correct this time :-)'
X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
? How can you parse that sensibly? (Even in perl...)
The '1*utf8' seems to make a nonsense of any possibility of parsing.
Peter Marschall wrote:
> > I do not ask this just for fun.
> > I find the assumptions made by Net::LDAP::Schema reasonable
> > (since the things above make parsing the schema quite hard).
Graham Barr wrote:
> Right. Its not so much that it is hard, but it will be slower.
I don't see how it is possible at all, without defining an additional
escape mechanism or list of disallowed characters (the previous approach).
regards,
jb
|
|
From: Peter M. <pet...@ma...> - 2002-01-10 04:40:53
|
Hi,
On Tuesday 08 January 2002 17:21, you wrote:
> An interesting question. It would make parsing rather interesting. You =
are
> right that the RFC does not disallow this. Net::LDAP assumed that no
> sensible person would do that (like many apps assume no sensible person
> puts spacing in filenames :)
Who says they are sensible (maybe they just forgot quoting/escaping ;-))
> If you can provide a schema (or subset of one) with this I will see wha=
t I
> can do.
Of course, here it is for the single quotes and the undescores
(line breaking manually done by me):
attributeTypes: ( 2.16.840.1.113719.1.55.4.1.1 NAME 'newObjectSDSRights'
DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.17
X-NDS_NAME 'New Object's DS Rights'
X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
X-NDS_NAME 'New Object's FS Rights'
X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
attributeTypes: ( 2.16.840.1.113719.1.57.4.1.1 NAME 'setupScript'
DESC 'Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VAL=
UE
X-NDS_NAME 'Setup Script' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> > Last but not least, I have a very rough patch available that would al=
low
> > to parse such a schema. But I have to polish it a bitbefore I send i=
t.
> > Are you interested ?
> Sure. Don't spend too much time polishing it before letting others test=
it.
> Just a correct patch is fine, it can be polished later.
I warned you, it is very rough ;-)
More a very dirty kludge than a patch.
Its a unified diff againts perl-ldap 0.25 and atleast the
part in LDAP.pm violates the RFC that defined the
"vendorName" attribute in the roodDSE.
The RFC vedorName must not be used to change the
behaviour of applications. A better solution might be to
defined a global ldap option "alternate_schema_parser".
(the better parts of the code are shamelessly stolen from=20
other parts of perl-ldap ;-)
--- lib/Net/LDAP.pm
+++ lib/Net/LDAP.pm Wed Dec 26 20:46:03 2001
@@ -706,15 +706,18 @@
my %arg =3D @_;
my $base;
my $mesg;
+ my $vendor =3D 'unknown';
if (exists $arg{'dn'}) {
$base =3D $arg{'dn'};
}
else {
- my $root =3D $self->root_dse( attrs =3D> ['subschemaSubentry'] )
+ my $root =3D $self->root_dse( attrs =3D> ['subschemaSubentry', 'vend=
orName'=20
] )
or return undef;
$base =3D $root->get_value('subschemaSubentry') || 'cn=3Dschema';
+ # PM: look for attribute vendorName in rootDSE
+ $vendor =3D $root->get_value('vendorName') || 'unknown';
}
$mesg =3D $self->search(
@@ -733,9 +736,13 @@
)],
);
+ # PM: set Net::LDAP::schema option novellkludge if it is a Novell dire=
ctory
$mesg->code
? undef
- : Net::LDAP::Schema->new($mesg->entry);
+ : (($vendor =3D~ /Novell/i) ?
+ Net::LDAP::Schema->new($mesg->entry, novellkludge=3D>1) :
+ Net::LDAP::Schema->new($mesg->entry)
+ );
}
sub root_dse {
--- lib/Net/LDAP/Schema.pm
+++ lib/Net/LDAP/Schema.pm Wed Dec 26 20:59:24 2001
@@ -5,21 +5,71 @@
package Net::LDAP::Schema;
use strict;
-use vars qw($VERSION);
+use vars qw($VERSION %schemaParams);
$VERSION =3D "0.10";
+# PM: default schema parameters
+%schemaParams =3D ( novellkludge =3D> 0 );
+
+#
+# PM: get options from argument list (stolen from Net::LDAP & simplified=
)
+#
+sub _options {
+ my %ret =3D @_;
+ my $once =3D 0;
+ for my $v (grep { /^-/ } keys %ret) {
+ require Carp;
+ $once++ or Carp::carp("deprecated use of leading - for options");
+ $ret{substr($v,1)} =3D $ret{$v};
+ }
+
+ \%ret;
+}
+
+#
+# PM: get / set schema options
+#
+sub options
+{
+my $schema =3D shift if (@_ && ref($_[0]));
+my $params =3D &_options;
+
+ if ($params)
+ {
+ while (my ($key,$value) =3D each(%$params))
+ {
+ $schema->{params}->{$key} =3D $value if ($schema);
+ $schemaParams{$key} =3D $value;
+ }
+ }
+
+ return $schema ? %{$schema->{params}} : %schemaParams;
+}
+
+
#
# Get schema from the server (or read from LDIF) and parse it into
# data structure
+# PM: extended to accept hash of options after optional argument
#
sub new {
my $self =3D shift;
my $type =3D ref($self) || $self;
my $schema =3D bless {}, $type;
+ my $arg =3D shift if (@_ % 2);
+ my $opts =3D &_options;
+
+ # PM: set default options and optionally override them with given ones
+ $schema->{params} =3D { %schemaParams };
+ while (my ($key,$value) =3D each(%$opts)) {
+ $schema->{params}->{$key} =3D $value;
+ }
- return $schema unless @_;
- return $schema->parse( shift ) ? $schema : undef;
+ if ($arg) {
+ return $schema->parse( $arg ) ? $schema : undef;
+ }
+ return $schema;
}
sub _error {
@@ -38,7 +88,10 @@
return undef;
}
+ # PM: save schema options before resetting schema and restore them=20
afterwards
+ my $params =3D $schema->{params};
%$schema =3D ();
+ $schema->{params} =3D $params;
my $entry;
if( ref $arg ) {
@@ -484,6 +537,21 @@
my @tokens;
pos($val) =3D 0;
+ if ($schema->{params}->{novellkludge})
+ {
+ push @tokens, $+
+ while $val =3D~ /\G\s*(?:
+ ([()])
+ |
+ ([^"'\s()]+)
+ |
+ "(.*?)"(?=3D[\s)])
+ |
+ '(.*?)'(?=3D[\s)])
+ )\s*/xcg;
+ }
+ else
+ {
push @tokens, $+
while $val =3D~ /\G\s*(?:
([()])
@@ -494,6 +562,7 @@
|
'([^']*)'
)\s*/xcg;
+ }
die "Cannot parse [$val] ",substr($val,pos($val)) unless @tokens a=
nd=20
pos($val) =3D=3D length($val);
# remove () from start/end
Yours
Peter
--=20
Peter Marschall | eMail: pet...@ma...
Scheffelstra=DFe 15 | pet...@is...
97072 W=FCrzburg | Tel: 0931/14721
PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35
|
|
From: Peter M. <pet...@ma...> - 2002-01-10 04:40:42
|
Hi, On Tuesday 08 January 2002 17:27, you wrote: > > Characters with codes > 127 have UTF8 encodings that > > consist of 2 or more bytes that have all codes > 127. > > Since these characters are legal in LDAPv3 DNs they should > > not get escaped. > True, assuming the DN given is UTF8, which it should be with > LDAPv3 but not v2 Iin that case, adding an option called "version" to split_dn (and eventually canonical_dn) mit help to be absolutely compatible with the old behaviour. Depending on "version" the quoting of special charactes can be done (version not given or version <=3D 2) or not done (version >=3D3). canonical_dn simply has to pass the option to split_dn But maybe this is making things too complicated ;-)) > But the escaping should be done on the basis of the character being > printable. Net::LDAP makes a bad assumption here. Hmmm, ... "Printability" may depend heavily on your terminal settings or your application.=20 On (almost )any 8 bit computer UTF8 encoded characters are printable, since UTF8 was designed to convert Unicode characters into variable length 8bit chunks. So, I wopuld suggest to - at least for LDAPv3 - leave out the encodiung of characters in the range from 128 - 255. Yours Peter --=20 Peter Marschall | eMail: pet...@ma... Scheffelstra=DFe 15 | pet...@is... 97072 W=FCrzburg | Tel: 0931/14721 PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35 |
|
From: Chris R. <chr...@me...> - 2002-01-09 17:12:16
|
Graham Barr <gb...@po...> wrote: > On Wed, Jan 09, 2002 at 03:56:21PM -0000, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Wed, Jan 09, 2002 at 08:28:08AM -0000, Chris Ridd wrote: >> >> Graham Barr <gb...@po...> wrote: >> >> > On Sun, Jan 06, 2002 at 01:57:37PM +0100, Peter Marschall wrote: >> >> >> Sorry, >> >> >> >> >> >> a few small errors in my last mail's listings. >> >> >> Here's the corrected version >> >> > >> >> > Can you get it so that it will pass the t/01canon.t testcase ? Also >> >> > can explode_dn share the same code ? >> >> > >> >> > Graham. >> >> > >> >> > >> >> >> >> There are some other DN test cases at: >> >> >> >> <http://www.openldap.org/ietf/ldapbis/dn.txt> >> > >> > Thanks, >> > >> > After adding those the only failure we have is in accepting the >> > following bad DNs, although I am not convinced that they are all bad. >> > >> > OID.1.1=jsmith // invalid attribute type name >> > >> > why ? is 1.1 an invalid OID ? >> >> OIDs in attribute types don't have an "OID." prefix. >> >> The DN should be "1.1=jsmith" >> >> The BNF in RFC 2253 doesn't permit "." in attribute types unless the >> entire attribute type is an OID. >> >> It is a valid OID, but defined by X.208 to not exist. > > From RFC2253 > > 4. Relationship with RFC 1779 and LDAPv2 > > ... > > Implementations MUST allow an oid in the attribute type to be > prefixed by one of the character strings "oid." or "OID.". > > ... > > So IMO, it is valid to accept it, but not generate it. The oid. prefix > is simply ignored. Rats, I forgot about that. Failing because the actual OID is explicitly defined to not exist would be a little excessive... So I agree, that DN should pass. Cheers, Chris |
7902 messages has been excluded from this view by a project administrator.
![http://www.dmotion.co.kr/mail/back.gif">](http://www.dmotion.co.kr/mail/back.gif">){kind=link}
![http://www.dmotion.co.kr/mail/hight.gif"></p>](http://www.dmotion.co.kr/mail/hight.gif"></p>){kind=link}
![http://www.dmotion.co.kr/mail/left.gif">](http://www.dmotion.co.kr/mail/left.gif">){kind=link}
![http://www.dmotion.co.kr/mail/right.gif">](http://www.dmotion.co.kr/mail/right.gif">){kind=link}
![http://www.dmotion.co.kr/mail/home.gif"></font></span></p>](http://www.dmotion.co.kr/mail/home.gif"></font></span></p>){kind=link}
![http://www.dmotion.co.kr/mail/low2.gif">](http://www.dmotion.co.kr/mail/low2.gif">){kind=link}
![http://www.dmotion.co.kr/mail/low.gif"](http://www.dmotion.co.kr/mail/low.gif"){kind=link}