<HTML dir=ltr><HEAD><TITLE>Using Expect to access the omshell</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16850" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText55702 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>I use OMAPI-PERL for doing this stuff. It's damn easy. It compiles up to version 3.1.x. Have not tried it with DHCP 4.x yet. There is also OMCMD which will make this easier too.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><A href="http://freshmeat.net/projects/omcmd/"><FONT face=Arial size=2>http://freshmeat.net/projects/omcmd/</FONT></A></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Brad</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> dhcp-users-bounces@lists.isc.org on behalf of Martin McCormick<BR><B>Sent:</B> Thu 7/23/2009 11:47 AM<BR><B>To:</B> Users of ISC DHCP<BR><B>Subject:</B> Using Expect to access the omshell<BR></FONT><BR></DIV>
<DIV><BR>
<P> <FONT size=2>We use omshell to manage static bootP hosts on our DHCP<BR>servers. it has been necessary at times to move hundreds of<BR>hosts out of one subnet into another via omshell and we have<BR>used an expect script to do this. The pattern is to send a<BR>command, wait for the prompt and send the next command. No more<BR>output is sent until we see the prompt each time. Is it safe to<BR>let expect run as fast as it can or can the input buffer in<BR>omshell be overrun even if we are waiting for the next prompt<BR>before sending?<BR><BR> We have been re-subnetting some buildings so these<BR>megamoves are unusual and a real test of one's scripting<BR>abilities.<BR><BR> Recently after a move of several-hundred bootP hosts, a<BR>few didn't get deleted. I first thought it was a buffering<BR>issue, but I think now it was my script wasn't thorough enough.<BR>Letting expect loose at full speed is the best outcome since it<BR>finishes faster. No need in slowing it down if that isn't an<BR>issue.<BR><BR> Thanks for any constructive thoughts. Even at full<BR>speed, it has always appeared to behave logically.<BR><BR>Martin McCormick WB5AGZ Stillwater, OK<BR>Systems Engineer<BR>OSU Information Technology Department Telecommunications Services Group<BR>_______________________________________________<BR>dhcp-users mailing list<BR>dhcp-users@lists.isc.org<BR><A href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</A><BR></FONT></P></DIV></BODY></HTML>