I like this as well.
On Feb 15, 2011 6:11 PM, "
kitepilot@kitepilot.com" <
kitepilot@kitepilot.com>
wrote:
>> Example 1: Use NX Free edition to get a desktop on another computer, and
>> then run your browser on that.
> Man, why so cumbersome...
> ssh -fCXY myuser@remotebox firefox
> will do...
> ET
>
>
>
> Kevin Fries writes:
>
>> On 02/15/2011 11:51 AM, Joseph Sinclair wrote:
>>> I would assume that he's talking about broad testing within a local
>>> network, rather than testing against localhost directly.
>>> I often do this because I can insert firewalls, routers, etc... as/where
>>> desired to emulate probable scenarios. It's particularly helpful to
>>> emulate 4in6 or 6in4 connections when using external providers that do
>>> not provide sufficient IPv6 support.
>>>
>>> It's just easier to create a hostfile entry on the test client(s) than
to
>>> create or modify public DNS (sometimes that's not even possible). This
>>> is particularly true when the service you're testing is already live and
>>> you need to black-box test a component of an interconnected SOA system.
>> Yes, I understand that. My point is to question if this is wise at all.
>> I have seen far too many times where a computer sends traffic out to its
>> public address, and still does not respond the same way it does in
>> production. The reason is one NIC. You are routing from yourself to
>> yourself, and it will get turned around at the NIC. I have worked R&D for
>> the past 4 1/2 years, and trust me, this happens far more than most
people
>> think. You would be better off bouncing off another computer, that
>> redirects the traffic truly from another machine.
>>
>> Example 1: Use NX Free edition to get a desktop on another computer, and
>> then run your browser on that.
>>
>> Example 2: Use a *Nix machine for which you have root access to create a
>> forwarded port (ssh -R 80:mypublicip:80 root@server). This makes the IP
>> address on the foreign machine tunnel back to yourself, and cuts out
>> optimizations at both the NIC and the switch and gives you a true
>> experience as to what your clients will see.
>>
>> Example 3: Have a second NIC. Force traffic out through NIC-1 to the
>> public IP on NIC-2. The switch and NIC have no idea that the machine
>> sending and responding are one in the same. Therefore, once again, you
>> can eliminate any ability of the devices to optimize.
>>
>> As I said in my original comment. The goal is to avoid the "It works on
>> my machine" situation.
>>
>> I hope my comments made more sense this time.
>>
>> Kevin
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)