Torrent Download Through Proxy

[Karon Howey]

Iam currently trying to using pacman behind my college's proxy server. It requires a username and password. In firefox/opera , I set the proxy server as bsnlproxy.iitk.ac.in and port as 3128 and firefox/opera automatically asks for a username and password. I tried the following for pacman , but it did not work.

I did not use wget. I used aria2c. But, yes the behaviour of libdownload is weird. I think the problem is somewhere in the syntax, although I really dont know for sure. I'll report it tomorrow after trying it with wget too and rechecking the syntax.

I was curious if anyone has experience connecting to their license manager through a reverse proxy? We have a public site that our employees can connect to the portal URL through, we were hoping that they would be able to use the portal URL through the public portal and connect, but I'm getting this message here:

I spoke with our network administrator, and I mentioned checking the certificate on SSLLabs, we did so and found that it had been revoked. Thankfully he had the ability to reissue the certificate, so we uploaded a new CSR and got it reissued, and boom, everything started coming through as normal. We're able to access the License Manager both on and off network. What gave me the hint was that Field Maps stated the certificate was untrusted, even though there was no warning when navigating.

For this reason, and to avoid complexity/opening up firewalls, I typically recommend clients to get their licenses from ArcGIS Online. If an organisation is 'secure' and can't use AGOL for licensing, then it typically suggests that the firewall issue won't be a problem and the FlexLM port will only be needed internally.

Thank you for the response, I was curious if it may have been the port that it is working through, I was under the assumption that once made through 7443, it would then work through 27000 or similar to get to the license manager right off the portal. I'll allow 27000 through just to see what happens.

I agree that it would be complex and insecure to open up the firewall to any further ports, but we'd like to attempt and move away from AGOL licenses for the most part, but if that's the move, then we'll go that way!

Sorry, I should have thought to share that. In NZ we tend to use AGOL because of Civil Defence risks and the fact that AGE may not be available. Most of our data centres are in EQ or Volcano areas! I sometimes forget the rest of the world may not think like that.

Just one other thought on all of this. A lot of the environments that I get to interact with have different zones. By which I mean, the internet comes in on 443 (and your new ports). This routes to the web server. That then routes through an inner firewall to the application server on 7443.

If you're zoned like this, then remember that your inner firewall ports will need to be opened as well, and you'll be effectively routing from the internet to your application zone. There may be better ways of dealing with this, but it will come down to what's in your IT kit bag to allow it....

No worries at all, we're currently discussing this with our network administrators to find a plan for action regarding this. It may be a situation of just using ArcPro offline while users are out of office, which was sadly against what we wanted initially, but if that's just how it goes then not much I can do.

Now I have the situation that Apache needs to retrieve a URL as well, via that same proxy. And that is where it goes wrong. The request times out. From the browser I can reach that internal URL fine, because the browser is using the proxy for its requests.

The thing is you are expecting wrong. If you want to retrieve a url then it is done via code that runs inside apache. AFAIK, apache is for serving content not retrieving content. Retrieving content is done by either code (like php, java , etc) or tools like wget or curl. Both wget and curl very well support connecting through proxy.

I first saw this solution on another site, but posting the link seemed to get my post silently removed, so I've left it out this time. I can't take credit for coming up with this answer, though I have rewritten it, hopefully to make it simpler and clearer.

This is the straw that broke the camel's back for me. I like SourceTree, but the requirement to have a BitBucket account is barely acceptable, and then to have obscure proxy / login issues crop up because of this unnecessary BitBucket marketing ploy is unacceptable. I'm moving on to something else.

Same for us. We're a BitBucket data center customer and we have the same issues. When SourceTree was developed by an independent company, it would just install with no problems. Any networking issues could be handled in the settings afterwards. With Atlassian's ownership, they've inserted this login registration step that frequently just doesn't work. If the user can log into our BitBucket server using their browser, but can't get the SourceTree installation to accept the exact same URL and login credentials, what am I supposed to tell the user? Exactly: use something else. That's what I'm telling all of our users now.

Ok, SourceTree is now dead to me since it cannot install in what is a common enterprise situation. I'll stick with TortoiseGit for the time being as it actually installs and doesn't require an account with a repository service I don't intend to use.

Thank you very much for the detailed guide that was described above. But unfortunately, I have other problems now. When I go to different sites, they block me as soon as I try to log in there. I have already tried all the free proxies that were possible. I also think about how I can get rid of the reduced Internet traffic. Maybe the point is that I should try using a paid proxy server? I just watched different guides on YouTube on how to fix various problems with the network. I came across the site proxies.com , where you can buy high-quality proxy servers. Here I think, whether it is worth trying.

Exactly! The answers above, and the communities answer aren't pertinent to the actual question - they address how to use git, and set git configuration - that it is SourceTree calling git is incidental, it's all a git issue.

The actual question is about how to install SourceTree. You cannot install it behind a strict proxy, because you must log in to Atlassian, and you cannot log in because the proxy is blocking that.

Configuring your git proxy won't help you there. I know because I have SourceTree 1.7 working through a proxy. I have git working through a proxy, but I still cannot install SourceTree 2.4.7.0, due to the requirement to log in to Atlassian (nor could I install 1.8 for that matter).

Yes, I think the spam filter got it, it often does with links. I'm not sure I disagree - a lot of work I get has been generated by "I did this thing I found on stack overflow and now my Atlassian stuff is broken"

So that brings us back to the proxy and to me the answer being, you will need to determine the URLs, IPs and Ports that are called as part of the Teams application, which can be found somewhat in the URL I provided previously and other Microsoft documentation. You would then exclude this in the PAC and that would effectively be excluding Teams.

Not sure what proxy you are using but another way to work this out, would be to do a trace, specify an internal IP and monitor what traffic gets generated as part of say a Teams call and use that to build up your exclusion list.

My use case is that we are in our own Amazon VPC and want to forward some logs to our Splunk Cloud instance. However, the machines in the various subnets need to go through a proxy to access anything outside of the VPC.

If you wish to secure your forwarder-to-indexer traffic behind a proxy, note that as of 6.3, Splunk supports the use of SOCKS v5 proxies for forwarder-to-indexer traffic. Details are available on-line at:

Keep in mind that with option 1, you are creating a single point of failure and are limiting the spray of data from many universal forwarders, down to one intermediate forwarder. The result is that the data is less distributed on the indexes because the single forwarder will auto load balance but in chunks. Always better to have many endpoints sending their respective chunks to indexers thereby producing a more random (less serial) spray of data.

This matters because when you search the data, you want it to load from many indexers in parallel so it'll be fast. If a chunk of the data is all on the same indexer, you are limited in search speed by that indexer's ability to get the data back.

Example: Imagine trying to get a 10GB file from a single host, vs 1GB files from 10 hosts. The bottleneck is reading from the host (not network), and as such, the 1GB from 10 hosts is going to me like 10x faster.

There is no internal proxy setting for Splunk itself (although ES has a modular input for the Threatlists that allows for a proxy setting.) Instead you should be configuring your proxy at the OS level. Both *nix and Windows have this feature..

As must have been explained in the earlier answers..... typically proxy connections are only for http requests. Your forwarder needs to connect over TCP on specific port to send the data... this may not be http. If the objective is to get the data into splunk cloud ... it will have be be designed and setup in collaboration with the network security and AWS teams. Eg: Setting up some standard servers as intermediate forwarders in your VPC and opening them up at the firewall might help.

3a8082e126