[sniffer] Testers wanted...

2008-10-06 Thread Pete McNeil 
Hello Sniffer Folks,

If you are interested in working with us to test SNF on the following
platforms please let us know:

SNF4Alligate -- SNF external filter on Alligate.

SNF4ASSP - SNF plugin for ASSP 2.0.

New SNF control script for any of:

OpenBSD, FreeBSD, CentOS, RedHat, SUSE, Ubuntu

Please respond off list to support@

Thanks,

_M

-- 
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.


#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: Update Script - Path apparently doesn't tolerate embadded blanks

2008-10-06 Thread Pete McNeil 




Hello Andrew,

Monday, October 6, 2008, 12:40:04 PM, you wrote:




>


 
Pete,
 
We aren't windows-greeking the call='xyz/getrulebase.cmd' call on the installer.  
Do we want to do that on this next release?  The XYNTService double quotes the calls, so I'm not worried about that but if it failed for him, why wouldn't it fail for others?





You're right. We will need to tweak that in the installer if it isn't already.

_M

-- 
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.



#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: Update Script - Path apparently doesn't tolerate embadded blanks

2008-10-06 Thread Andrew Wallo 

Pete,

We aren't windows-greeking the call='xyz/getrulebase.cmd' call on the 
installer.  
Do we want to do that on this next release?  The XYNTService double quotes the 
calls, so I'm not worried about that but if it failed for him, why wouldn't 
it fail for others?

_A
  - Original Message - 
  From: Pete McNeil 
  To: Message Sniffer Community 
  Sent: Monday, October 06, 2008 8:26 AM
  Subject: [sniffer] Re: Update Script - Path apparently doesn't tolerate 
embadded blanks


  Hello Andy,




  Sunday, October 5, 2008, 11:25:37 PM, you wrote:




>
   Hi Pete,



Found a bug (I think):







With THIS configuration, the script apparently gets never launched. 
What's particularly disturbing is, that I didn't find any place where the 
service reports/logs any errors about the update process?
   




  
http://www.armresearch.com/support/articles/software/snfServer/config/node/network/update-script.jsp




  When the update launcher detects that a new rulebase file is ready it passes 
the contents of call= to the system() function. The system() function _SHOULD_ 
exist on every platform, but it's implementation can be different on every one.




  More importantly for this question - the result code returned by system() is 
implementation specific, so there is no way to know what that result code will 
be (what it means) without actually testing every case. Worse than that an 
apparently successful call to system() might only indicate that the OS supports 
syste(), or that the command interpreter didn't crash or didn't have a problem 
with the command string even though the command string didn't necessarily do 
anything.




  When testing a new update script you need to install it and see if SNFServer 
can launch it successfully by testing the result of the script -- did it do 
what it was supposed to do?




  We are considering some features for the next minor upgrade to help test this 
feature such as the ability to trigger it and a log entry that returns whatever 
system() returned (that will have to be interpreted by the user according to 
their platform's documentation for that call).




  For now you can trigger this feature by changing the timestamp of your .snf 
file. If the .snf file's timestamp is earlier than the timestamp of the file 
available from our system then the update-script feature will fire.




>
   

After spending some time, trying to narrow down the problem but not 
finding any diagnostic info, I eventually decided to eliminate spaces from the 
path:







and now it DOES seem to work.
   




  Everything in call= is passed to system() as a string. No additional parsing 
takes place.




  In theory that means if you can type the contents of call= at the command 
line and get your desired result then SNFServer will be able to do the same.




  A couple of things can get in the way of that --




  * Does SNFServer have the correct permissions to do what you have put into 
call= ?




  * Does the system() function on your platform interpret this string correctly 
?




  On Windows systems spaces can be a problem whenever one program is calling 
another. Wherever possible it is usually best to use tilde to eliminate spaces 
in file or directory names -- otherwise the spaces are likely to be interpreted 
as breaks between command line parameters.




  Best,




  _M




  -- 

  Pete McNeil

  Chief Scientist,

  Arm Research Labs, LLC.


#

This message is sent to you because you are subscribed to

  the mailing list .

To unsubscribe, E-mail to: <[EMAIL PROTECTED]>

To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>

To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>

Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: Update Script - Path apparently doesn't tolerate embadded blanks

2008-10-06 Thread Pete McNeil 




Hello Andy,

Monday, October 6, 2008, 10:20:05 AM, you wrote:




>


Hi Pete:
>>http://www.armresearch.com/support/articles/software/snfServer/config/node/network/update-script.jsp<<
 
Yep, had read that – but that page just instructs me to use the full path, which I did. Does NOT tell me that the Windows platform requires to quote the string or use DOS style paths





It will shortly. I wanted to get the link out there for those following along.






>


 
As you know, there are a few different ways to launch programs in Windows – some of them accept a full path as a separate parameter (spaces allowed). I don’t think it’s safe to assume that your customers would know which function call you had chosen, and to predict what its limitations might be. Some of us are Win32 API programmers – many probably aren’t.





Indeed.

Since SNF is cross-platform software I could not chose a Windows specific call to launch the external script. I also had to chose something that would be thread safe. The system() call is a posix standard -- posix having been around a very long time.




>


 
I really don’t have a problem with either including the string in quotes or using DOS style paths, etc. – it’s just that there was nothing helpful in the product or documentation that would have lead me to conclude that either before or after it didn’t work.





There will be shortly.

Thanks for your detailed posts!

_M

-- 
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.



#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

[sniffer] Re: Update Script - Path apparently doesn't tolerate embadded blanks

2008-10-06 Thread Andy Schmidt 
Hi Pete:

>>http://www.armresearch.com/support/articles/software/snfServer/config/node
/network/update-script.jsp
 <<

 

Yep, had read that - but that page just instructs me to use the full path,
which I did. Does NOT tell me that the Windows platform requires to quote
the string or use DOS style paths - or, how to test if the script will
launch and, if not, where to see the return codes that the service
encounters. 

 

I had looked through your log files and I expected to see some XML row
similar to:

  "MMDD HHMMSS: Update Script %1 launched. RC=%2" 

- but didn't.

 

Knowing how to trigger it manually is good to know - thank you for sharing
this. In this case, it still wouldn't have helped me debug the problem,
since neither the fact THAT a call had occurred at all and the return code
apparently were being logged.

 

>> We are considering some features for the next minor upgrade to help test
this feature such as the ability to trigger it and a log entry that returns
whatever system() returned (that will have to be interpreted by the user
according to their platform's documentation for that call).<<

 

I think that would be necessary.

 

>> Everything in call= is passed to system() as a string.<<

 

As you know, there are a few different ways to launch programs in Windows -
some of them accept a full path as a separate parameter (spaces allowed). I
don't think it's safe to assume that your customers would know which
function call you had chosen, and to predict what its limitations might be.
Some of us are Win32 API programmers - many probably aren't.

 

I really don't have a problem with either including the string in quotes or
using DOS style paths, etc. - it's just that there was nothing helpful in
the product or documentation that would have lead me to conclude that either
before or after it didn't work.

 

Thanks again for your time and consideration.

 

Best Regards,

Andy

[sniffer] Re: Update Script - Path apparently doesn't tolerate embadded blanks

2008-10-06 Thread Pete McNeil 




Hello Andy,

Sunday, October 5, 2008, 11:25:37 PM, you wrote:




>


Hi Pete,
 
Found a bug (I think):
 

 
With THIS configuration, the script apparently gets never launched. What’s particularly disturbing is, that I didn’t find any place where the service reports/logs any errors about the update process?





http://www.armresearch.com/support/articles/software/snfServer/config/node/network/update-script.jsp

When the update launcher detects that a new rulebase file is ready it passes the contents of call= to the system() function. The system() function _SHOULD_ exist on every platform, but it's implementation can be different on every one.

More importantly for this question - the result code returned by system() is implementation specific, so there is no way to know what that result code will be (what it means) without actually testing every case. Worse than that an apparently successful call to system() might only indicate that the OS supports syste(), or that the command interpreter didn't crash or didn't have a problem with the command string even though the command string didn't necessarily do anything.

When testing a new update script you need to install it and see if SNFServer can launch it successfully by testing the result of the script -- did it do what it was supposed to do?

We are considering some features for the next minor upgrade to help test this feature such as the ability to trigger it and a log entry that returns whatever system() returned (that will have to be interpreted by the user according to their platform's documentation for that call).

For now you can trigger this feature by changing the timestamp of your .snf file. If the .snf file's timestamp is earlier than the timestamp of the file available from our system then the update-script feature will fire.




>


 
After spending some time, trying to narrow down the problem but not finding any diagnostic info, I eventually decided to eliminate spaces from the path:
 

 
and now it DOES seem to work.





Everything in call= is passed to system() as a string. No additional parsing takes place.

In theory that means if you can type the contents of call= at the command line and get your desired result then SNFServer will be able to do the same.

A couple of things can get in the way of that --

* Does SNFServer have the correct permissions to do what you have put into call= ?

* Does the system() function on your platform interpret this string correctly ?

On Windows systems spaces can be a problem whenever one program is calling another. Wherever possible it is usually best to use tilde to eliminate spaces in file or directory names -- otherwise the spaces are likely to be interpreted as breaks between command line parameters.

Best,

_M

-- 
Pete McNeil
Chief Scientist,
Arm Research Labs, LLC.



#
This message is sent to you because you are subscribed to
  the mailing list .
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>