Excellent help provided promptly by Florian Schlaich, Darren Dunham and John Julian. Thanks to all. Original Question:- > 1) I have a sun pci qfe card in an E250 (Sol 2.6 > usual > patches), appropriate entries in /etc/hosts and > /etc/hostname.qfe0 and an ethernet cable plugged > into > port 0. > > /var/adm/messages confirms all is well:- > Apr 18 16:00:59 slinger unix: SUNW,qfe0: Using > Internal Transceiver > Apr 18 16:00:59 slinger unix: SUNW,qfe0: 100 Mbps > full-duplex Link Up > > From my reading of the manual that came with the > card > it looks like you can inspect and set the speed,mode > or status of the four ports using the ndd command. > As root: > slinger# ndd -set /dev/qfe instance 0 > slinger# ndd /dev/qfe instance > 0 > > That seems fine as it is port 0 that is active. But > if > I try to force the post to be inactive I get: > slinger# ndd -set /dev/qfe link_status 0 > operation failed, Permission denied > > Also it seems to be telling fibs about the other > three > ports on the card - all of which are not connected: > slinger# ndd -set /dev/qfe instance 3 > slinger# ndd /dev/qfe instance > 3 > slinger# ndd /dev/qfe link_status > 1 > I get similar porkies being told about the speed and > the mode as well. Any idea what I'm doing wrong > here? > The trick is to check the value of the parameter transceiver_inuse first and if this returns a 1 ( not in use) then don't bother going any further checking the status of this instance:- slinger# ndd /dev/qfe instance 3 slinger# ndd /dev/qfe transceiver_inuse 1 slinger# ndd -set /dev/qfe instance 1 slinger# ndd /dev/qfe transceiver_inuse 1 slinger# ndd -set /dev/qfe instance 0 slinger# ndd /dev/qfe transceiver_inuse 0 You can also use ndd /dev/qfe \? to see which parameters are either read only or read/write for ndd. Note also that the param 100hdx_cap (for example) is read only and reports on the capability of the transceiver whilst adv_100hdx_cap is read/write and reports on the actual operational mode. > 2) Anybody know of an encryption tool that would > keep > shell scripts encrypted until you want to run them, > then prompt for a password, decrypt and run them and > then re-encrypt them again? Two solutions provided using crypt. I haven't tried them yet, but both look promising... crypt < myscript.ksh > /usr/local/scripts/myscript.crpt rm myscript.ksh to run: crypt < myscript.crpt | ksh you could wrap crypt with a script: #!/bin/ksh # run - syntax: run file if [ -f /usr/local/scripts/$1.crpt ] then crypt < /usr/localscripts/$1.crpt | ksh fi you would run the script with: run myscript You would have to get fancier to pass parameters to the script. script: use a code like in a shell archive (shar) e.g.: a) crypt your shell script using crypt <script >crypted-script b) edit the crypted script by PREpending the following three lines #! /bin/ksh awk 'NR>3{print}' $0 | crypt | ksh -s exit be careful about stdout and stderr! (man pages) Thanks again Matt ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ieReceived on Thu Apr 19 11:20:11 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:53 EDT