About owen

owen · ‎11-19-2013

Hi Jay, Most of the 'Stingray' part of the Splash site is devoted to TrafficScript examples. Here are a couple of places to get you started: Collected Tech Tips: TrafficScript examples Top Traffic Manager Examples and Use Cases Best regards Owen

owen · ‎11-11-2013

Hi Rob, As David Nahas showed, you may use http.setPath() to change the URL in the request. Stingray will then send the modified request to the selected server; the remote client does not see the changed request. The other common method is to use http.redirect(); this sends a 302 Redirect response back to the client telling it to 'try this URL'. The redirect is visible to the end user. One possible gotcha when using http.setPath() is that embedded relative links or redirects from the content may not work, so images, stylesheets and the rest may not be displayed (this may be why you see a cut-down, low-res version of the site). For example, if you modify a URL from /scotland/index.html to /scotland.html , then the web client will look for resources relative to /scotland/ , although the content was served from / . Use the developer tools in your web browser to see if your client is requesting resources that return an unexpected 404 Not Found. regards Owen

owen · ‎11-05-2013

Hi André, You can use the SOAP or REST API functions to push new CRL files into the Stingray configuration, for example, using a daily cron job. It should be possible to write a script that lists the CA files in the Stingray configuration (using one of the APIs), retrieves each file and extracts the CRL URI from it, retrieves the current CRL and pushes that back. Hope this helps, Best regards Owen

owen · ‎11-05-2013

Mark Boddington's solution is a great approach. Just for completeness, here's a few alternatives that illustrate how to: Count Events (e.g. countries) in a database: Being Lazy with Java Extensions Record and read events: Slowing down busy users - driving the REST API from TrafficScript - you could adapt that to bandwidth-limit certain countries if they exceed 100 requests per minute (for example) Apply rate limits: Stingray Spider Catcher - this example rate-limits users; you could trivially modify it to rate-limit by country Throttle traffic if the site slows down: Dynamic rate shaping slow applications - combine this with the selective rate limiting to just slow down certain countries

owen · ‎10-22-2013

Try setting the host header, as described here: Getting Started - Load-balancing to a website using Stingray Traffic Manager

owen · ‎10-22-2013

Hi Mario, If you use a redirect, then the remote user will see the parameters. You could modify the URL, for example, to add a query string, and then forward the request on to a back-end server as normal. regards Owen

owen · ‎10-17-2013

Hi Mathew, The situation you cite from the docs is for the case where you want to have multiple active traffic managers. In that case, you have two (or more) default gateways and you need to partition your servers so that they use the correct gateway*. Yes - if one traffic manager goes down its partition is offline, and if all of the servers in a partition fail, you need to persuade the traffic manager to failover. It's not a great solution. In the simpler case, you have one active traffic manager and use the configuration I suggested. I suspect that if you just have two nodes, you aren't going to need two active traffic managers? regards Owen * It may be possible to overcome this using source-based routing on the back-end servers, keyed on the source MAC address. Mark Boddington's A guide to Policy Based Routing with Stingray (Linux and VA) illustrates how to do this on the traffic manager; you could replicate his 'Multiple Links' / 'Auto-Last-Hop' configuration on the back-end servers. I've not tried it, but if you're feeling confident, it's worth a go.

owen · ‎10-15-2013

Hi Rob, This is really easy to do, either using RuleBuilder or TrafficScript. RuleBuilder is a simple 'if-condition-then-action' GUI front-end to TrafficScript. Before you write your rule: Ensure you have configured a 'Pool' for your most common web traffic. Set this to be the 'default pool' for your virtual server. All traffic will be handled by that pool unless a rule intercepts the traffic and selects a different pool. Create a pool for the /scotland traffic. This pool should contain the server(s) you want to use to handle that traffic. Let's call that pool 'scotland' Then you need to create a rule using RuleBuilder, or write a rule using TrafficScript, to intercept the /scotland traffic and divert it to the scotland pool: RuleBuilder IF HTTP Path is '/scotland' - AND - IF HTTP Host Header is 'www.suckeggs.com' - THEN - Use Pool 'scotland' TrafficScript if( http.getHostHeader() == "www.suckeggs.com" ) { if( http.getPath() == "/scotland" ) { pool.use( "scotland" ); } } Hope that this helps Owen

owen · ‎10-15-2013

Hi Mario, If you need to store the information permanently, then you can't rely on the global data segment as it is discarded when the traffic manager software is restarted. You can store the information in the resources section of the Stingray configuration. The article Slowing down busy users - driving the REST API from TrafficScript illustrates how to do this. You could also store the information in an external database (this is much more difficult). Use a Java Extension or an event handler to push information into the database, and a Java Extension to read data from the database. There are some examples here: Being Lazy with Java Extensions - writing to a MySQL database Authenticating users with Active Directory and Stingray Java Extensions - reading from LDAP It might be easier to use a database with an HTTP interface (such as Riak) to get and set the per-IP records. Here's another example: Detecting false login attempts and blocking the attackers Best regards Owen

owen · ‎10-15-2013

Hi Mathew, Yes - you can do this, and there's a description in the product documentation. In short, you create a single-hosted traffic IP group that contains a front-end (public) and a back-end (private) traffic IP address, and set the 'keeptogether' flag in the group so that the IPs are raised on the same traffic manager. Use the back-end traffic IP address as the default route for your back-end servers. regards Owen ps. Life is much easier if you can avoid using Layer-3 IP transparency (IP Transparency: Preserving the Client IP address in Stingray Traffic Manager)!

owen · ‎10-14-2013

Hi Mario, Yes - you can use the global data segment to store the list. This is simpler than the solution I described above, but it has two disadvantages: Data does not persist - it is lost when the traffic manager restarts Data is not shared between traffic managers in a cluster Either will work - you can select the approach that is best for you Best regards Owen

owen · ‎10-14-2013

Hi Ashley, Are you using the Stingray software or the virtual appliance? With the software, you're responsible for setting up networking, DNS and the like, so you'll want to verify that /etc/resolv.conf and /etc/hosts are set appropriately on both traffic managers. The virtual appliance is a closed system. You use the 'System' settings in the UI to configure many of the operating system properties, such as the DNS server setting, and any fixed DNS mappings in /etc/hosts. Note that (unlike most of the traffic manager configuration) these items are specific to each traffic manager, so you will need to configure them appropriately on each traffic manager in your cluster. Finally, get a shell on each traffic manager and verify that each machine can resolve and ping its peer. It's generally good practice to configure the names of all of the traffic managers as fixed DNS names (implemented via /etc/hosts) on every traffic manager in your cluster. This avoids the possibility of your cluster failing because of a DNS failure or misconfiguration. Hope that this helps Owen

owen · ‎10-11-2013

Take a look at Stingray's Service Protection policies; they may do what you need (I can't recall if they can block-all and whitelist some). Otherwise a simple trafficscript request rule will do what you need: $allowed = [ "192.168.1.1", "92.27.24.216", "131.111.131.1", "8.8.8.8" ]; if( ! array.contains( $allowed, request.getRemoteIP() ) { http.sendResponse( "401 Not Authorised", "text/plain", "", "" ); } If you'd like to match the client IP against IP subnets, then the easiest strategy would be to list these in the array and iterate through the array, testing the IP against each array element using string.ipmaskmatch( $ip, $element );

owen · ‎10-09-2013

Please see the discussion thread Re: How can I block ips with a custom script with Stingray Traffic Manager?

owen · ‎10-09-2013

Hi Mario, You can inspect and modify the Stingray configuration from within a TrafficScript rule. This article (Slowing down busy users - driving the REST API from TrafficScript) gives an example. The basic principle is that you can make a REST request using http.request.get to retrieve the configuration file for a service protection policy. The config file is plain-text; you can modify it in the rule with a little care, and then store the changes using http.request.put. This should help to solve your problem. Alternatively, you could use a modified version of the Slowing down busy users - driving the REST API from TrafficScript article. The advantage of this solution is that it would let you implement a timeout - users don't have to be blocked forever and you don't have an ever-growing list of banned IP addresses. Hope that this helps - best regards Owen

owen · ‎10-09-2013

Here you go: https://gist.github.com/ogarrett/6901360 - best regards - Owen

owen · ‎10-02-2013

Hi Harsh, From memory, this is most likely to happen when Stingray is reading an HTTP request and the HTTP headers exceed the max_client_buffer limit. At 64k, this is a high limit for HTTP headers, so it's possible that you are encountering either a possible DoS attack (some webservers were vulnerable to large HTTP headers), a badly-behaved client or a request with a very large number of cookies. The biggest effect of increasing this limit is increased memory usage, followed by reduced ability to detect and discard bad HTTP requests. Unless you are running at very high levels of CPU or using very large amounts of memory*, it's perfectly safe to increase this value. When the system is running stably, you can use the Connections report to examine GET requests (i.e. those without a request body) that are unusually large (client data read). You'll find it useful to identify which sorts of requests are approaching or exceeding the 64k buffer limit. Owen * memory usage is hard to judge because Stingray will grab much of the free memory and reserve it for cache space. Our support team will help you interpret the memory profile of Stingray (hint - the client_buffer is allocated from the zeus.zxtm processes' heap). You can probably just increase the buffer limit and check that Stingray is not using significantly more memory and is not swapping to disk.

owen · ‎09-19-2013

Hi Adrien - you'll find the event log in ZEUSHOME/zxtm/log/errors - any crashes (albeit unlikely!) will be recorded there. ZEUSHOME is typically /usr/local/zeus (software installs) or /opt/zeus (virtual appliance). The Stingray software does not log to syslog unless you configure an event handler to do so. You can also view the event log through the UI (from the home page). You should raise this as a P1 case with support if you have not already done so, as per Mark Boddington's suggestion regards Owen

owen · ‎09-17-2013

Hi Andriy, You're exactly right in your statements above, and you need to make a judgement as to whether the concerns are serious enough that you look to an alternative to the Transparent Session Persistence method. Points #1 and #2 are broad; there are lots of ways to 'fingerprint' the web infrastructure. If you're concerned that the X-Mapping-Cookie is an obvious indicator that Stingray is in use, you could use an alternative session persistence method (e.g. IP, SSL-Session-ID, or Universal) that does not leave any external fingerprint. Check out the list of session persistence methods in this doc Feature Brief: Session Persistence in Stingray Traffic Manager that do not use client-side cookies. Points #3 and #4 relate to the ability to exploit session persistence to target specific nodes in the cluster. This is a consequence of any session persistence method, and you can mitigate against it by deploying session persistence selectively - see HowTo: Controlling Session Persistence for a simple example. If an attacker is mounting a volume-based attack, exploiting session persistence to target an individual node, then the best mitigation would be rate limiting, using the techniques and examples in Feature Brief: Bandwidth and Rate Shaping in Stingray Traffic Manager. Finally, it may be possible to inspect and modify the X-Mapping cookie using trafficscript. You may be able to encode it further once it is set using a response rule, and then decode it in a request rule before the load-balancing decision is made. I'm not completely sure if this is possible, but perhaps an interesting exercise to try! I hope that these explanations help - thanks for pointing out these concerns Best regards Owen

owen · ‎07-16-2013

Hi Mathew, Perl and LWP can be picky about self-signed SSL certificates, and I think that might be the root of your problem. Could you try either or both of: #1: set an environment variable at the top of your script: $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME}=0; #2: set an SSL option after you create your $conn SOAP::Lite object: $conn->proxy->ssl_opts( SSL_verify_mode => 0 ); These two steps are illustrated by this article: Tech Tip: Reading Stingray's internal diagnosis report using Perl and SOAP and I have found that one or other of them address most SSL certificate problems (it seemed to depend on the precise version of LWP) regards Owen

owen · ‎07-10-2013

Hi Matt - this article - Tech Tip: Using Perl/SOAP to list recent connections in Stingray Traffic Manager - describes how to use SOAP to retrieve the current and recent connections table from a traffic manager Best regards Owen

owen · ‎07-08-2013

Hi Arnold, The warning message "Rule references an unknown pool via pool.activenodes" is emitted by the TrafficScript function 'pool.activenodes( $pool )'. In the code above, $pool should only be either: one of the values in $poolmap ("p_RCD_prod.start.rs.com_http", "p_RCD_prod.rs.com_http", etc), or... the empty string Line 20-21 in the code captures the empty-string possibility and terminates the rule by sending a response immediately to the client. This suggests that one of the values in $poolmap is incorrect - it does not correspond to the name of a pool in your configuration. Perhaps there is a typo or mismatch in your config? It's unfortunate that the error message does not contain the name of the pool that does not exist. If you can't determine which value (if any) is wrong, then you could insert this line just before line 26 where you call 'pool.activenodes( $pool )': log.info( "Checking pool '" . $pool . "'" ); This will log the name of the pool, and when you next see the 'unknown pool' error in your log, look for the 'Checking pool' message next to it to find the name of the pool. regards Owen

owen · ‎06-28-2013

Hi Arnold, I've annotated the rule you provided with some comments - I hope that they make it clear. If your rule encounters a host header that it does not recognise, it will set $pool to the empty string (""). This will provoke the warning message you report, so I've added a test for that situation too. regards Owen # Retrieve the host header provided by the client. This is generally the domain name in the URL. # The getHostHeader() function simplifies the host header, removing any port component, # converting to lowercase, remove trailing '.', etc, so the result is unambiguous $hh = http.getHostHeader(); # Now try to determine the webserver pool that serves requests for that host header $poolmap = [ "start.rs.com" => "p_RCD_prod.start.rs.com_http", "www.rs.com" => "p_RCD_prod.rs.com_http", "rs.com" => "p_RCD_prod.rs.com_http", "prod.rs.com" => "p_RCD_prod.rs.com_http", "authentication.rs.com" => "p_RCD_prod.authentication.rs.com_http", "service.rs.com" => "p_RCD_prod.services.rs.com_http", "reports.rs.com" => "p_RCD_prod.reports.rs.com_http" ]; $pool = $poolmap[ $hh ]; # If $pool is empty, that's because the hostheader $hh did not match a key in $poolmap # Let's return an error (404 is typical for an unrecognized host header) if( $pool == "" ) { http.sendResponse( "404 Not Found", "text/plain", "Unrecognised host ".$hh, "" ); } # If none of the nodes in the pool are functioning, the pool will return an error. We can # test this and return a different error if we want (Zeus users will recognize this message) if( pool.activeNodes( $pool ) == 0 ) { http.sendResponse( "503 Unavailable", "text/plain", "No suitable nodes are available to serve your request", "" ); } # Everything appears OK. $pool contains the name of a valid, working pool. Let's use it pool.use( $pool );

owen · ‎06-26-2013

> Is this stated in the documentation? Only by omission. I've updated Feature Brief: Bandwidth and Rate Shaping in Stingray Traffic Manager to make it known.

owen · ‎06-25-2013

Hi Gavin, The rate class limits are counted and applied per-Stingray-instance. In an active/active cluster, one option would be to configure the rate limit to half the value you want; assuming even traffic distribution across the cluster, this would give you the effect you need. If you need a very strictly-applied rate limit, you would be better to run active-passive with respect to the traffic that should be limited. One additional observation - the bandwidth classes can be configured to operate across the cluster; in an active-active scenario, the traffic managers continually negotiate to get an appropriate share of the total bandwidth allocation. Best regards Owen

owen · ‎06-19-2013

Hi Patrice - looks like a very sensible change - thanks for sharing it. I've updated the library accordingly. Best regards Owen

owen · ‎05-21-2013

You can run tcpdump (wireshark) on Windows (Wireshark · Download). Switches in the GUI - there are two things you can do: Enable connection debugging: Virtual Server > Connection Management > Connection Error Settings: enable log!client_connection_failures and log!server_connection_failures. These settings will cause Stingray to log if a connection times out or is unexpectedly closed by the client or server Enable analytics: System > Global Settings > Logging: set recent_conns to 200 (for example), then Virtual Server > Request Tracing: enable request_tracing!enabled For the first setting, check the event log. For the second setting, you can drill down on the Activity > Recent Connections page. Neither setting will give you a complete dump of the connection data, but they may help to diagnose what is happening.

owen · ‎05-21-2013

Cheers... it would be interesting to see a tcpdump of a successful download (from client direct to server) and a tcpdump of the connection when you try to proxy through Stingray. This might give some clues as to what is going on. For example, the tcpdump might reveal that, like FTP, the FFT protocol attempts to create a secondary data channel between the client and the endpoint ("open a TCP connection to this IP:port and await the file"). In the absence of a FFT proxy in Stingray, we might be able to persuade the client (or server) to connect directly to its peer rather than the intermediate Stingray. All speculation of course... interested to see what you find

owen · ‎05-21-2013

Hi Oliver, You need to go through the login form in Stingray to generate the session cookie - you can't just use basic authentication etc. You could automate this using the following URL: https://stingray:9090/apps/zxtm/login.cgi?form_username=admin&form_password=admin&_form_submitted=form (of course, change admin:admin to your admin username and password) The login form automatically redirects you to the Stingray home page. You then need to get your client to load the following page to get the decoration-free version of the activity map: https://stingray:9090/apps/zxtm/index.fcgi?section=Map&showui=no&vserver=.all The UI pages have an automatic timeout (defined in the Permission Group for the user who is logged in): When the timeout kicks in, the page is refreshed and falls back to the login page. This timeout does not apply to the Activity map, so you can run it persistently. If anyone tries to use that browser session to access the rest of the Stingray UI, the timeout will kick them off immediately. Hope that this helps Best regards Owen

owen · ‎05-21-2013

Hi Derek, FFT is a new protocol to us I think. I can't find any specifications online so it's hard to give any firm advice. If it does operate like FTP, then it may use the model of a control connection (for control messages) and separate TCP connections for data transfers; the connections are created on demand. This sort of approach causes problems for firewalls, load balancers and other proxies because they need to inspect the control connection and prepare to admit and proxy the on-demand data connections. For example, we have an FTP proxy in Stingray that does exactly that, allowing us to proxy FTP traffic. I saw one reference here (Hidden Value - June 2001 - question "I'm having problems using Reflection 7.0") that illustrates potential problems passing FFT through a firewall, and suggests that the client can fall back to "using the session port". Perhaps that is a feature of FFT, and one you can use? If you can share the protocol spec, then we can advise further. Best regards Owen

Re: is there any examples of traffic script?

Re: Re: Simple Redirect script

Re: Automatic CRL updates to the Stingray ?

Re: Can i write to a file from Traffic script

Re: Reverse proxy

Re: How can I block ips with a custom script with ...

Re: Traffic IP as a gateway for servers (nodes)

Re: Simple Redirect script

Re: How can I block ips with a custom script with ...

Re: Traffic IP as a gateway for servers (nodes)

Re: How can I block ips with a custom script with ...

Re: The hostname X could not be resolved into an I...

Re: How can I whitelist ip range with the traffic ...

Re: Stingray Traffic Manager Block ips?

Re: How can I block ips with a custom script with ...

Re: Receiving SMS Alerts from Stingray Traffic Man...

Re: Help tuning Max_client_Buffer limit

Re: Stingray Crashed

Re: What's the X-Mapping- cookie for, and does it ...

Re: Display current connection table via SOAP / CL...

Re: Display current connection table via SOAP / CL...

Re: Re: Select Pool based on host header

Re: Select Pool based on host header

Re: Rate Class limits in a two node active/active ...

Re: Rate Class limits in a two node active/active ...

Re: libWebSockets.rts: Managing WebSockets traffic...

Re: bittorrent-like ftp client drops connection

Re: bittorrent-like ftp client drops connection

Re: Activity Map on supervision TVs

Re: bittorrent-like ftp client drops connection