Proxy causing headaches

I installed openSUSE on a work machine (Don’t tell the I.T. department please :wink: ) and it connect via the networks proxy. Can surf the net just fine using the proxy settings I’ve got but I cannot install anything or do an update due to the same error the poster of that thread discribes. While he has the option to switch to a different connection, I don’t.

Curiously enough, Ubuntu 10.04 server has no problem on the same machine using the same network connection in doing anything. Update, install, download… But I want an openSUSE server!

I have setup a permanent proxy connection and this is the only way I can get zypper to actually receive some data.

I have removed all repo’s and added them again. I have rebuild the rpm database, I have done all I know and all I could find on this forum/google.

Anybody have any ideas?

Bit of detail: Corperate Active Directory Windows 2003 network, Ethernet network connection, server is not on the domain and I don’t want it to be either, currently has a fresh KDE 4.6 install which is functioning fine.

  1. What is the corporate firewall?
  2. If you can determine what the corporate firewall is, do you know how it authenticates connections, particularly if it’s Active Directory integrated?
  3. Where are you configuring Proxy settings in your openSUSE?
  4. If your proxy settings work for surfing the Internet (HTTP/HTTPS), have you verified whether your openSUSE repositories are verified HTTP also? And, if so have you tried testing the repository link with a web browser?
  5. Have you added your openSUSE to your corporate Active Directory Domain or is it operating outside of Domain network security?


1 and 2) No idea.
3) Tried under YAST - Proxy but it wouldn’t enter the credentials. Think it’s a bug. Must look at filling a bugreport. I edited /etc/sysconfig/proxy manually.
4) Can browse the repo’s no problem. Have not tried downloading a single RPM. My problem at the moment is when Yast or zypper refreshes the repo’s. Throws up an error about some file not being in gzip format. Not near the pc in question but will find the actual error when I get my hands on it again.
5) At the moment it’s outside the active directory but i would like to get it on there. Don’t have admin rights to add a pc to the domain but can swindle some from somewhere. The only active directory credentials used are in the proxy settings (http://username:password@

  • If you don’t know what the firewall is and have problems, everything is a shot in the dark in a possibly complex situation unless you involve your network sysadmins.

  • You may need to verify your repos are properly pointing to the repository catalog. Test from a browser by typing the URL constructed by combining the repo server and directory path.

  • Sometimes you can pass the proxy credentials in the URL as you’ve described, but not always. And, of course you’ll need to be careful how you describe the username as a member of the proxy’s local database or the Domain or whatever.

  • The tests I described using a web browser only test HTTP connections. You still haven’t responded verifying your Repositories are configured for HTTP downloads or not. Natch, if you’re configured for something other than HTTP, then you’ll need to test for <that>.

Because you don’t know anything about your corporate firewall, you don’t know whether it’s SOCKS4 or SOCKS5, HTTP/HTTPS only, more.


I think I’ll have a chat with the I.T. department or will install Ubuntu Server… this has no problems, somehow… Thanks for the help…

Found the problem… the networks censoring software (websense) is blocking zip files so when I do my refresh it can’t download half the information required… kinda sucks but I found that other distro’s suffer from the same problem… Work around is bypassing the internet and bring in a repo on disk >:)

I wonder if that is a sufficient reason for the Repositories to support SSL/TLS. Maybe they already do but I haven’t ever tested.You might modify to see if that addresses your problem (configure HTTPS URL/URI instead of HTTP).


Will try. Thank you for the suggetion. And yes, I would be in favour of SSL/TLS communication if possible. Maybe worth while to add it to openFATE. Must do that when home…