<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Ok... Todays update......<BR>
 <BR>
SUCCESS AT LAST (with some minor bugs).<BR>
 <BR>
I've been banging my head on the wall for days now trying to figure out why the first line in my "startnos" file crashes, when called as a script on bootup.<BR>
 <BR>
My first line in the file being "cd /jnos".<BR>
 <BR>
Seems many others out there in the world are also having this issue.<BR>
 <BR>
SEVERE hunting on internet forums revealed the answer.<BR>
 <BR>
I found a posting that stated the command "cd" (as in "cd /jnos") can *not* be called when calling from an executable script. <BR><BR>
Script line commands are intrerperted as an actual command file that must exist in the "/bin" directory. And there is no "CD" in this directory. (on my linux flavor of Ubuntu)<BR>
 <BR>
To test this posting, I made a new test file that only had one line:<BR>
ECHO "TEST TEST TEST - HELLO"<BR>
 <BR>
When I then called the test script with the "exec" command, sure enough 'TEST TEST TEST - HELLO' was printed on my screen<BR>This being because the command file called "ECHO" exists in the "/bin" directory.<BR>
 <BR>
So, the article went on to say how to overcome this "need to be in directory /xyz".<BR>
 <BR>
The article notes on overcoming were somewhat mute, as starting JNOS is *suppose* to already have a trailing command that specifies where to find the directory that JNOS is suppose to use.<BR>
 <BR>
Most can start JNOS from a command prompt (when already in the JNOS directory) by using "./jnos -d /jnos -v" <BR>
 <BR>
The "./jnos" portion stating to RUN JNOS<BR>The "-d /jnos" portion telling JNOS to look for all required files in directory "/jnos"<BR>and the "-v" portion stating to verify (or show) each line being processed  from the "autoexec.nos" file.<BR>
 <BR>
So, with that in mind, I decided to re-write my "startnos" file slightly, and came up with this:<BR>
==================================================================================<BR>rm -f /jnos/spool/mqueue/*.lck 2> /dev/null<BR>rm -f /jnos/spool/mail/*.lck 2> /dev/null<BR>export TZ=PST8PDT<BR>exec /jnos/jnos -d/jnos -v </dev/tty4>/dev/tty4 2>&1<BR>==================================================================================<BR>
 <BR>
Noting that there is no "cd /jnos" anywhere in there, and also noting that the last line has no period before the first "/jnos".<BR>
 <BR>
Now any of you following me yesterday saw, I was attempting to boot this in console 5. The file above uses console 4 only because I was testing console 4 just to see if somehow console 5 had any kernal reserves to it. On my Ububtu, console 7 is reserved for the GUI window.<BR>
 <BR>
Then, I was able to re-write my "tty4.conf" file to this:<BR>
========================================================================<BR># tty4 - getty<BR>#<BR># This service maintains a getty on tty4 from the point the system is<BR># started until it is shut down again.<BR>
 <BR>
start on runlevel [23]<BR>stop on runlevel [!23]<BR>
 <BR>
respawn<BR># exec /sbin/getty -8 38400 tty4<BR>exec /jnos/startnos tty4<BR>========================================================================<BR>
 <BR>
Upon reboot WHAM! console 4 came to life and JNOS ran.<BR>
 <BR>
The minor bugs issue is that when I was first logged in as ROOT, and issuing these commands manually, they ran fine *because I was logged in as ROOT*.<BR>
 <BR>
Some of the commands I have in my "autoexec.nos" file wont run correctly this way, because on auto-boot-up, the console 4 is not root.<BR>
 <BR>
While JNOS will boot and run, these commands (from autoexec.nos) need root permissions:<BR>
"shell iptables -t nat -A PREROUTING -d 192.168.1.7 -p tcp --dport 6300 \-j DNAT --to 44.2.14.1:23"<BR>"shell /sbin/ifconfig tun0 192.168.1.7 pointopoint 44.2.14.1 mtu 1500 up"<BR>"shell arp -s 44.2.14.1 00:e0:18:02:dd:e0 pub"<BR>"shell echo 1 >/proc/sys/net/ipv4/ip_forward"<BR>"shell iptables -t nat -A POSTROUTING -s 44.2.14.1/32 -o eth0 -j MASQUERADE"<BR>  <BR>So, I look at these as minor (for now) and will work to address some sort of SUDO injection into them so they work.<BR>(Anyone wanting to lend a hand there, go right ahead)<BR>
 <BR>
Now, after reboot, and console 4 coming to life, I waited for JNOS to fully load. Then, I told it to "exit".<BR>
 <BR>
After it exited, "respawn" kicked in and re-started it.<BR>
 <BR>
Finally !!!<BR>
 <BR>
Bill<BR>KG6BAJ<BR><BR> <BR>

<HR id=stopSpelling>
Date: Sat, 27 Nov 2010 21:22:02 -0500<BR>From: bobtenty@gmail.com<BR>To: nos-bbs@tapr.org<BR>Subject: Re: [nos-bbs] Ubuntu 10.04 file run error<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>Well I used and still use Ubuntu 10.04 at a lot of packet systems with the same script and never had a problem<BR>with it.<BR><BR>I'm mystified..<BR><BR>73,<BR><BR>Bob VE3TOK<BR>                                      </body>
</html>