Weblog entry #6 for muondude
See all weblog entries made by muondude.
and password.
All the examples I've seen require you to embed the username and password
in the proxy specification (either in apt.conf or an environment variable
not a good idea).
For example:
export http_proxy=http://username:password@proxyserver.net:port/
export ftp_proxy=http://username:password@proxyserver.net:port/
or you can configure this in the apt.conf file using a similar format
but it still requires one to include the u/p.
Is there a way to have apt/aptitude prompt the user for the username/password?
Comments on this Entry
Not that I know of, but seeing as you have to run apt-get as root (or via sudo etc.) anyway, why not just `chmod 600 /etc/apt/apt.conf` and embed the username/password in there -- it truely is the easiest way to do it?
Cheers.
[ Parent | Reply to this comment ]
[ Send Message | View muondude's Scratchpad | View Weblogs ]
username and password to any file where it could be viewed. The proxy
authentication is the same for several other services that exist within this intranet and therefore this is not a good approach.
In general saving any passwords as plain text should be avoided.
It seems like apt can't be configured to prompt the user for the Username and password, bummer! I've posted here and searched quite a bit and even read the documentation with no luck. I even posted to my local Linux UG with no response yet. Time for a feature request?
[ Parent | Reply to this comment ]
I understand the privacy issue, I guess, but if you're administering systems, why not create a throw-away account and use that for the proxy auth? Even better, do it the way we do and have a central apt-proxy server that you route through instead of the edge web proxy -- then you don't need to auth at all because the apt-proxy takes care of all that.
Cheers.
[ Parent | Reply to this comment ]
[ Send Message | View muondude's Scratchpad | View Weblogs ]
but unfortunately, I'm not the one administering the proxy, etc.
My systems run within an Intranet administered by others and they have recently clamped down on the network big-time.
I'm trying to convince them to allow certain traffic from internal Machine X to
a specific external machine Y (Debian mirror only) without having to login to the
proxy. The Firewall/proxy admin folks seem to be swamped addressing the hell they
have created (primarily due to the fact that most of the systems within the Intranet are windoze boxes).
We have run our own internal mirror server - but there were problems with that - but I'm thinking that this might be the best option.
thanks for your suggestions.
For now my systems sit cut off from their updates/upgrades. :-(
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Acquire::http::Proxy "http://MYDOMAIN\user:pass@annoying.proxy.server:portnum/";in /etc/apt/apt.conf (or /etc/apt/apt.conf.d/).
This doesn't address your privacy concerns, but it might make it work for you ( I found this handy tip on the ubuntu forums, fwiw).
Here's another proposal:
If the privacy thing is really a concern, you could divert apt-get itself, and put a wrapper script in its place. This is not for the faint of heart. Do:
mv /usr/bin/apt-get{,.distrib}
dpkg-divert /usr/bin/apt-get
and then create the following file as /usr/bin/apt-get: #!/bin/sh # script to set up relatively opaque proxy settings for apt: http_proxy="http://MYDOMAIN\user:pass@annoying.proxy.server:portnum/" exec /usr/bin/apt-get.distrib "$@"and finally, make this script unreadable by anyone but root:
chmod 0711 /usr/bin/apt-get chown root:root /usr/bin/apt-getIf at any time you don't like this, you can roll it back with:
mv /usr/bin/apt-get{,.wrapper-script}
mv /usr/bin/apt-get{.distrib,}
dpkg-divert --remove /usr/bin/apt-get
If anyone thinks i'm making a big mistake by suggesting this, i hope folks will correct me publicly here.
[ Parent | Reply to this comment ]