Closed Bug 23459 (squid) Opened 25 years ago Closed 17 years ago

install a WWW-proxy (squid 2.0) that can be used to limit bandwidth

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
x86
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: endico, Assigned: mrz)

References

Details

Some bugs like 20827 only occur on low bandwidth links but developers usually have extremely fast links and can't duplicate certain bugs. If we set up squid to simulate a 28.8 or 14.4 link then they could debug a lot more bugs.
Blocks: 20827
Status: NEW → ASSIGNED
Squid 2.2 running on tegu, port 3128. It's currently allowing netscape.com with speed 4800 kbps. I need to know what sites it needs to accept and with what speeds?
Is there any reason not to let it accept everyone? Does tegu have special privs? To the netscape.com intranet? To other mozilla.org machines? I don't think so.
We can't just have open proxy - if it will be found it would provide a way for hackers etc to get to sites through us. Also, some non-US people could use it to access some sites they aren't allowed (like download 128-bit crypto Communicator). So, we somehow have to limit who can access it.
Blocks: 21961
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Squid proxy is ready. It's running on tegu.mozilla.org. There are different instances for different speeds: 3125: 1200 bps 3126: 2400 bps 3127: 9600 bps 3128: 14400 bps 3129: 28800 bps 3130: 56000 bps Authentication is based on cvs logins (eg. "risto%netscape.com") and your cvs password (updated once an hour). If other accounts are needed please let me know. Also, if there are any problems please open bugzilla ticket about it to server operations group.
Status: RESOLVED → VERIFIED
marking verified, I tried it out and it works swell.
Alias: limiting-proxy
new alias, easier to remember
Alias: limiting-proxy → squid
We no longer have this on Tegu and it would be nice to get it set up on one of our publically available machines. Not a major priority, but a resource we used to have that now we don't.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
And unfortunately, nobody thought to grab the old configs off of tegu. We have several squid instances scattered around now (mostly for load balancing purposes), so this shouldn't be too hard to rig up again.
Assignee: rkotalampi → justdave
Status: REOPENED → NEW
QA Contact: endico → myk
This is a mass-reassign of bugs that I'm not actively working on right at this moment to the default component owner, since we now have a larger IT staff than just me. These bugs will be getting redistributed to other sysadmins as sysadmin time becomes available.
Assignee: justdave → server-ops
Priority: P3 → --
Closing because this does not seem to be a priority anymore. Please correct us if we are wrong.
Status: NEW → RESOLVED
Closed: 25 years ago → 20 years ago
Resolution: --- → WONTFIX
According to the dupe, we still need this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Status: REOPENED → NEW
QA Contact: myk → justin
--- chris hofmann 2008-05-01 17:52:23 PDT --- justin mentioned "the cloud" as a possible choice. this one looks pretty interesting too. http://www.xk72.com/charles/wiki/features and sounds like the have some kind of firefox extension that goes along with it to control the server... --- Comment #2 [reply] Justin Fitzhugh 2008-05-01 21:10:43 PDT --- http://www.shunra.com/ - software was create when I used it last, but was some time ago.
> in response to comments 10 and 12 back in 2004-5 we didn't have the size and diversity of user base we have now or volume of and bandwidth/network bugs and reports. We also didn't have the QA resources needed to investigate these kind of bugs so having this drop off the radar might have made sense. Now is a good time to move forward on getting this capability up and running again, and expanding with some new capability to simulate a variety of random network errors and other features if possible...
Assignee: server-ops → mrz
Is it sufficient for this to run out of Landings? Or out of the colo but behind the firewall (and you'd have to VPN in to get to it)? Either of those routes makes it easier to deploy without worrying about becoming an open proxy or having to deal with user authentication.
> this one looks pretty interesting too. > http://www.xk72.com/charles/wiki/features and sounds like the have some kind of > firefox extension that goes along with it to control the server... It is cool and can run locally on OSX, Windows or Linux. The extension doesn't control Charles - it only autoconfigures proxy settings which in itself is useful. Fakes SSL certs to decrypt payload content which has some value too. Sure was fun loading pages at 28.8Kbps.
> Is it sufficient for this to run out of Landings? this would be a good start and would allow marcia and others on the moco QA staff to start testing some of the bugs that need it right now. > Or out of the colo but behind the firewall (and you'd have to VPN in to get to it)? this might get us more access from trusted volunteers in the testing community and everyone that might be doing testing from other work or home locations with high speed links.
I think we should spin up the simplest thing that we can use to chase the immediate bugs, and add other access mechanisms as we need them. It seems like any tester can install Charles and start working with that today? The trail-blazing QA folk could write up the specific configuration they use in a wiki.m.o page to help others who want to jump in later.
Is what Shaver suggested going to get you what you need? Otherwise, I need a better understanding of the problem and what's needed to duplicate it.
I haven't heard anything on this and I think between my comments and Shaver's there's a viable solution. As I mentioned in comment #19, if that's not true, I need a better understanding of the problem I'm trying to solve.
yeah, shaver's suggestion works for those that have time to set stuff up. no one has jumping in with the suggested wiki page documentation shows how short people are on time to figure this out and set it up. I image that will happen some day, maybe after fx3 ships... having some solutions around that are ready to use still seems useful.
That doc is best written by people who are using the tools to find bugs, since their knowledge is most practical (and they'll know where the existing docs for the tool are insufficient). Don't think this is an IT issue, not sure what component it should be in as a request for QA documentation...
shaver, sure. jay, the docs on charles and any useful configuration settings might be something to build into the qa companion like you have for for some of the other QA reference docs. or the place to put this stuff might be on qmo as part of the documentation on other tools that help control or observe the testing environment as litmus test or bug verifications are run. ( stuff like tom cat's leak monitoring doc's, etc.) even simple things like having some subset of test day testers run at 56k bps using charles might expand test coverage and turn up some interesting bugs related to speed, timing and connections to proxies. It's 4 or 5 simple installation and configuration steps to get this going on a testers machine. Here is the start of what might be some documentation for this. Download and Install Charles http://www.charlesproxy.com/download.php Install the Charles Firefox Extension http://www.charlesproxy.com/charles.xpi Then configure speed at Proxy | Throttle Setttings and turn on throttling with Proxy | Throttle Settings Charles is a bit naggy about asking for donations to help support development. Maybe Mozilla ought to contribute to what they need if we ask a bunch QA people to start using it on behalf of trying to test Firefox and its a tool that lots of QA volunteers start using to control and observe more about what is going on while testing. (cc sethb too for possible future community grant work)
the naggy message from charles is about only allowing you to run for 30 minutes at a time (if you haven't registered?). thats a bit of a pain. there might also be a bit of work needed to get charles playing nicely with the login stuff on the qa companion if it gets integrated there. might be related to or fixed in handling https://bugzilla.mozilla.org/show_bug.cgi?id=433770
also add some stuff to set up and installation about adding the Charles CA cert to your trusted certificates. that would make it much less painful dealing with https sites. more detail in bug 433770
We can definitely get a quick tutorial on QMO and try to leverage our betatesters community during the next few Test Days to do some limited bandwidth and proxy testing. I will pass along the Charles info to the QA execution team so we can get started soon...
Jay, is this something I can toss to you?
mrz: No, I rather have IT set the server up. QA will handle the documentation and testing once it's up. Thanks!
jay, we decided that it might just be easier for any tester that wants to do band rate throttling as part of some testing to just install Charles on their own PC, and use the proxy locally. It's a fairly simple and straight forward process as described in comment 23. From there, they could also see a variety of other tools in Charles that they could play with to help in diagnosing bugs and running tests. Documentation could be expand as testers find more interesting uses. If we hold to that, this just becomes a documentation bug for work on QMO or the quality section of wikimo.
> If we hold to that, this just becomes a documentation bug for work on QMO or > the quality section of wikimo. I agree. Who can I assign this to (or which component) or should I resolve it fixed?
mrz: please close this bug. i will create a new bug to get content added to the QMO site.
Status: NEW → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.