Newsgroups: gmane.linux.debian.user Date: 2006-12-12
Posted by Vivek on Monday May 9, 05
This article summaries package management command along with it usage and examples for you.
Newsgroups: gmane.linux.debian.user Date: 2006-12-12
I got the following message from "aptitude dist-upgrade" all of a sudden:
. . . Do you want to continue? [Y/n/?] y WARNING: untrusted versions of the following packages will be installed!
. . .
> > It could be caused by a number of things. Try running apt-get update. > > That did fix the problem yesterday! Dist-upgrade went through > without any error. > > I did "aptitude update; aptitude dist-upgrade" when I got the error > (quoted in the subject of this message). Does that mean that > "aptitude update" is different from "apt-get update" or > that something has changed between the time I got the error > and yesterday?
AFAIK you get the untrusted sources for packages that were installed from repositories that are not official (for packages that weren't built by official debian maintainers).
Check if you have non-official repositories in your /etc/apt/sources.list
What could have changed is that the package first appeared in unofficial repositories and then propagated to the official ones, or that there was something wrong done with the specific package and it was fixed.
> Anyway, thank you for your help and pointer to the secure-apt > documentation. > > > For docs, see http://wiki.debian.org/SecureApt[]
Micha Feigin
Secure apt always downloads Release.gpg files when it's downloading Release files, and if it cannot download the Release.gpg, or if the signature is bad, it will complain, and will make note that the Packages files that the Release file points to, and all the packages listed therein, are from an untrusted source. Here's how it looks during an apt-get update:
W: GPG error: http://ftp.us.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
If you ignore that warning and try to install a package later, apt will warn again:
WARNING: The following packages cannot be authenticated! libglib-perl libgtk2-perl Install these packages without verification [y/N]?
The debian-archive-keyring package is used to distribute keys to apt. Upgrades to this package can add (or remove) gpg keys for the main Debian archive.
For other archives, there is not yet a standard location where you can find the key for a given apt repository. . . . so you might have to hunt for it.
gpg itself has a standard way to distribute keys, using a keyserver that gpg can download a key from and add it to its keyring. For example:
$ gpg --keyserver pgpkeys.mit.edu --recv-key 010908312D230C5F gpg: requesting key 2D230C5F from hkp server pgpkeys.mit.edu gpg: key 2D230C5F: "Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>" not changed gpg: Total number processed: 1 gpg: unchanged: 1
Note that the second half of the long number is the key id of the key that apt doesn't know about, in this case that's 2D230C5F.
You can then export that key from your own keyring and feed it to apt-key:
$ gpg -a —export 2D230C5F | sudo apt-key add - OK
documented on: 2007-08-25
edit file /etc/apt/apt.conf
add the following line to it
Acquire::http::Proxy "http://username:password@Proxy_IP:port";
Ignore username and password if your proxy server does not require authentication to connect to internet.
Ref: http://www.ee.iitb.ac.in/uma/~shanmuga/linux.html[]
For those of you who need to get DSL working from behind your company's proxy server,
export http_proxy='http://userid:password@proxy.yourcompanyserver.com:port' export ftp_proxy='http://userid:password@proxy.yourcompanyserver.com:port'
save to the .bash_profile file so next time you reboot it will all be set for you..
documented on: 2007.05.01
Newsgroups: gmane.linux.debian.user Date: Sat, 11 Nov 2006 12:26:48 +0000
> Somehow I get a mixed system, mixed packages from testing/unstable are > mingled in my system. > > Is there any way to list which packages are from unstable or testing?
'apt-show-versions' is what you want.
Liam O'Toole
Description: lists available package versions with distribution
apt-show-versions parses the dpkg status file and the APT lists for the installed and available package versions and distribution and shows upgrade options within the specific distribution of the selected package.
This is really useful if you have a mixed stable/testing environment and want to list all packages which are from testing and can be upgraded in testing.
documented on: 2006.11.11
Newsgroups: gmane.linux.debian.user Date: Sat, 11 Nov 2006 12:25:04 -0600
> What is the recommended way to 'aptitude update' daily and update the > files in /var/cache/apt/archives/ as well (without actually install > anything)?
Package: cron-apt Priority: optional Section: admin Installed-Size: 88 Description: automatic update of packages using apt-get
Contains a tool that is run by a cron job at regular intervals. By default it just updates the package list and download new packages without installing. You can instruct it to run anything that you can do with apt-get (or aptitude).
It can optionally sends mail to the system administrator on errors, log to syslog or a separate log file.
Observe that this tool may be a security risk, so you should not set it to do more than necessary. Automatic upgrade of all packages is NOT recommended unless you are in full control of the package repository.
Tag: admin::package-management, interface::daemon, role::sw:server, suite::debian, use::downloading, works-with::software:package
John Hasler
> Package: cron-apt > Description: automatic update of packages using apt-get...
Hi, thanks for the respond.
The research on cron-apt actually led me to the discovery that apt has the feature already, no need for an extra package:
See comments in /etc/cron.daily/apt …
T
by joe on 14 Jun 2005
Basically, cron-apt is a very flexible program that can manage automating apt via cron (I suppose thats how it got its name…). You can install it like so:
apt-get install cron-apt
You can configure cron-apt in the /etc/cron-apt directory and you can specify when it runs in the /etc/cron.d/cron-apt file. Personally, I just have everything set to default except for one line in /etc/cron-apt/config:
MAILON="always"
Just as it would imply, it will email me the results of the nightly run no matter what.
By default, cron-apt will only download updates — it will not install them. I know other packages for other distributions like up2date will automatically install the updates for you, but I've learned to like this and that in the long run, automatically installing updates is a Bad Thing. Why? Well when I was experimenting with auto-installs, I ran into problems:
Even though I told apt to say Yes to everything, it still prompted me for input on config file conflicts (was I doing something wrong?). This caused the script to hang indefinitely in the background until it was killed.
Auto-accepting configuration changes can ruin your day. With Debian, it's fairly easy to back out of a change and hopefully you have a backup copy of the config file, but that's not the point. Good System Administration means you should never be in that position in the first place. "OK, what if I just deny all configuration changes and leave my copy?", you ask. Well, what if the upgraded program uses new syntax in its config file. Your program is now broke and you're in the exact opposite position as you were with auto-accepting.
Just as you should always review configuration file changes, always review what packages are being installed. If you know that installing that new version of Samba will mean some extra work in other places, don't install it yet.
Bottom line: Yes, it can be very tedious to manually review each update batch — especially if you have several servers — but that is part of your job when you are running a server. Deal with it!
OK, with that rant done with, lets get back to cron-apt.
So right now we have cron-apt downloading updates for us every day and emailing us about them. Each morning I review the updates to see if there's anything critical that needs updated (like if I've seen a security advisory on BugTraq or something). If not, I usually wait until I have time on the weekend to do the update. If anything, the daily emails serve as a nagging reminder to update your server.
I simply run:
apt-get dist-upgrade
I do one final review and then install the packages and clean up any config file conflict during installation.
That's really it. As mentioned before, cron-apt is very flexible. If you read over the example config in /usr/share/doc/cron-apt/examples, you'll get a better understanding for this flexibility.
For example, you can specify a different package repository to download from at night than when you use apt daily on the command line. Or you can add different arguments or even use completely different programs to do the actual downloading. Out of the box, it works just fine, but if you have some weird special need, it can do it for you.
by lb on Fri 21 Jul 2006
My firewall server settings are pretty tight, and restrict outgoing traffic to absolute minimum. In order not to pierce holes into the ruleset for apt, I created a short shellscript that dynamically opens up the firewall for outgoing traffic during the update/upgrade process, and closes the firewall again, when finished. The script analyses the /etc/apt/sources.list/ and allowes ftp and http connections. after finishing cron-apt, the newly created rules are deleted again. It basically works like this:
create a script /usr/local/sbin/my-cron-apt that calls the firewall-rules script apt-fw.sh first, then executes cron-apt, and afterwards calles apt-fw.sh again.
in /etc/cron.d/cron-apt, replace /usr/sbin/cron-apt with /usr/local/sbin/my-cron-apt
The advantage of splitting the process in two seperate files is, that you can call apt-fw.sh manually, when executing aptitude update or the like.
The scripts are:
#!/bin/bash /usr/local/sbin/apt-fw start test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /usr/local/sbin/apt-fw stop
#!/bin/bash IPTABLES=/sbin/iptables GREP=/bin/grep AWK=/usr/bin/awk TAIL=/usr/bin/tail CHAIN="aptChain" function d_start() { $IPTABLES -N $CHAIN $IPTABLES -A $CHAIN -p udp --dport 53 -j ACCEPT $IPTABLES -A $CHAIN -p tcp -m multiport --dport 21,80 -j ACCEPT $IPTABLES -A $CHAIN -j REJECT for APT in `$GREP ^deb /etc/apt/sources.list | $AWK '{print $2}' | uniq`; do APT=`echo $APT | $AWK '{sub (/[fht]*p:\/\//,"",$1); print}'` APT=`echo $APT | $AWK '{sub (/\/[a-zA-Z0-9\-_/]*\/?/,"",$1); print}'` $IPTABLES -A OUTPUT -d $APT -j $CHAIN done } function d_stop() { $IPTABLES -F $CHAIN I=`$IPTABLES -L OUTPUT -n --line-number | $GREP $CHAIN | $TAIL -n 1 | $AWK '{print $1}'` while [ "$I" != "" ]; do $IPTABLES -D OUTPUT $I I=`$IPTABLES -L OUTPUT -n --line-number | $GREP $CHAIN | $TAIL -n 1 | $AWK '{print $1}'` done $IPTABLES -X $CHAIN } case "$1" in start) d_start ;; stop) d_stop ;; *) echo "Usage: $0 {start|stop}" >&2 exit 1 ;; esac exit 0
Newsgroups: gmane.linux.debian.user Date: Tue, 12 Sep 2006 21:13:30 +0200
> For a couple of month I have seen an annoying change in behavior of > aptitude update and apt-get update. Formerly, a couple of package > files where downloaded which took a few seconds. Now I normally see > that aptitude update downloads hundreds of files named like > > Get:282 2006-09-11-1318.15.pdiff [13.3kB] Get:283 > 2006-09-11-1318.15.pdiff [13.3kB] Get:284 > 2006-09-11-1318.15.pdiff [34.3kB] Get:285 > 2006-09-11-1318.15.pdiff [34.3kB] Get:286 > 2006-09-11-1318.15.pdiff [34.3kB] > > and this takes quite long. From the name I guess these are only > differences two package files so that less data have to be > transferred. However, the overhead of nearly 300 TCP connections > causes this to take *much* longer on some systems than simply > downloading the whole package file.
Apt is configurable in this respect, it just isn't documented yet (see Bug #376158):
apt-get update -o Acquire::Pdiffs=false
or, to make this setting permanent, put the following in /etc/apt/apt.conf:
Acquire::PDiffs "false";
All package management tools using apt should honour this.
Jochen Schulz
Try putting this line in /etc/apt/apt.conf (creating the file if it doesn't already exist) to turn off pdiffs:
Acquire::PDiffs "false";
I guess you can put it in a separate file in /etc/apt/apt.conf.d/ instead if that directory exists on your system.
Kevin B. McCarty
Your Local Debian Mirror
Koen Noens December 2005
When you're experimenting with Linux, or when you're maintaining a network with lots of Linux hosts, you may be downloading the same packages over and over again, for each machine. It would make sense to keep them on your local netwswork (not wasting bandwidth, and as a fall back fgor when your internet connection is slow or down).
apt-proxy mimics the file hierarchy of 'real' debian mirror, so it can be used in sources.list, and functions as a caching proxy : it will serve the desired packages from its cache if possible. It will get packages from public mirrors of the desired packeage is not in the cache or if newer versions exist, and serve those to the clients, updating its cache along the way. So if you're maintaining multiple Debian hosts (e.g. for hands-on learning projects), you have a Linux server handy and/or considering automatic installations, apt-proxy is worth having a look at.
For a quick intro about what it is and what it does : see the apt-proxy home page
apt-proxy used to be in the unstable branch because of dependencies to packages that have not yet made it to testing or stable, but is now available in both stable and testing, so you can just install whatever version matches your server : apt-get install apt-proxy .
This is fairly straightforward. All configuration is in /etc/apt-proxy/apt-proxy-v2.conf (for version2). There are 2 types of entries :
This allows using a dedicated directory, partition or disk for the cache, specify ip address and port number the (proxy-)server should be listening on (default port: 9999), indicate how long packages should remain in cache, etc.
the servers where apt-proxy will download from. You can specify multiple servers, like ftp://ftp.belnet.be/debian, or http://archive.ubuntu.com/ubuntu - so all in the format protocol://server/top-level-dir. The three under the toplevel directory will be taken care of automaticaly.It is advised to use sections such as [Debian] and [Ubuntu], each with their own list of sources.
If you've moved the location of the cache, eg to /srv/cache/apt-proxy, you will have to check that the user 'apt-proxy' can write to this directory and its subdirectories. The default /var/cache/apt-proxy is owned by root:root and has drwxr-xr-x permissions.
Here's a list of Official Debian Mirrors you can use in the apt-proxy config. Alternative and additional sources are already listed in apt-proxy-v2.conf, and you can easily add your own.
That's all. Al that remains is to let your clients use your apt-proxy as apt source.
Matching sources/list to apt-proxy sections and back-end servers
replace the sources.lists of your clients with something like
deb http://myproxy.dom.com:9999/debian stable main contrib deb http://myproxy.dom.com:9999/debian testing main
deb http://myproxy.dom.com:9999/security stable/updates main
http://APTPROXY:9999/debian in sources.list refers to [debian] section in apt-proxy.conf; For sources that follow the Debian repository structure, you'd add the archive next (stable, testing, unstable for Debian, or Sarge, Etch, or Dapper for Ubuntu, and so on), then the desired components (main, contrib, non-free, restricted, multiverse, and so on). These indications are resolved automatically by apt-proxy, which will also create the corresponding file hierarchy in its cache so the whole system is transparant for the clients.
Of course, you can stil add additional sources to the client's sources.list, but that does not make much sense : they can also be added to the apt-proxy back-end lists - so you won't need to maintain sources/lists on your debian hosts. Nicely centrally managed, that is.
"unofficial" servers usually do not have this standard subdivisin. For those, you can add "./" (ie current directory) as "directory" following the URL
in sources.list, download paths take the form
deb protocol://server[:port]/path division [component [component [component [...]]]]
when using apt-proxy, path in sources.list should refer to a [section] in /etc/apt-proxy/apt-proxy-v2.conf (and apt-proxy will create a directory with that name in its cache).
That means you can have a sources list with "http://myproxy.dom.com:9999/debian" and a apt-proxy section "debian', but it might as well be "http://myproxy.dom.com:9999/my_favorite_os" and a apt-proxy section "my_favorite_os" , which can serve as a debian mirror if the backend servers in that section are real debian mirrors
In the sections of apt-proxy-v2.conf, you list the server(s) that this section should query. So for a Debian client, whether the section is called "debian" or "my_favorite_os", the servers could be
ftp://ftp.latnet.lv/linux/debian http://ftp.belnet.be/debian ftp://ftp.ccc.uba.ar/pub/linux/debian/debian (and so on)
Note that you need to define the URL down to the directory where the Release (or Packages ?) file is kept. That also goes for non-debian-like archives. They'd go in their own section(s), but again the URL is defined down to the location of Realease, or down to the package itself :
http://debian-knoppix.alioth.debian.org ftp://ftp.freenet.de/pub/debian-openoffice http://ftp.sh.cvut.cz/MIRRORS/OpenOffice.deb
And remember that the sources list of the clients just needs to point to proxy_server[:port]/section [repository components]
deb http://my_apt-proxy:9999/ubuntu dapper main restricted universe multiverse deb http://my_apt-proxy:9999/ubuntu dapper-updates main restricted
deb http://my_apt-proxy:9999/ubuntu-security dapper-security main restricted
[ubuntu]
backends =
ftp://ftp.belnet.be/mirror/ubuntu.com/ubuntu
http://be.archive.ubuntu.com/ubuntu
http://archive.ubuntu.com/ubuntu
[ubuntu-security]
backends =
http://ftp.belnet.be/linux/ubuntu/ubuntu/
http://security.ubuntu.com/ubuntu
apparently there are some issues with apt and apt-proxy in Ubuntu Dapper Drake, and they do not always work well together.
http://www.debianplanet.org/node.php?id=1319 https://launchpad.net/distros/ubuntu/+source/apt-proxy/+bug/46776
Apt-proxy doesn't do pinning : it handles requests from apt on the client system. It is apt that uses pinning to decide where a package should come from before it issues a request. There is an order of preference in the apt-proxy back-ends lists, but that is specific to the section it is under, so you still need to maintain a preferences file to have control over what gets installed when your running a mixed system (stable - testing, ubuntu - debian …).
You can have a collection of backend servers under the same section, but they only come in to play when a server is unavailable / unreachable / … If the first server can't be reached, the second one is queried. However, if the first backend server [of a particular section] is available but does not contain the requested package, the other backend servers [of that section] are ignored and you get a "package not found" error. Therefore, mixing mirrors (eg main ` backports ` 3th party) in 1 section does not always work well.
The only alternative to that, to my current knowledge, is to create a real debian mirror server and organise it so that you can make that mix. This also means you will have to maintain a Packages file and so on. Look at apt-move, apt-ftparchive, dpkg-scanpackages, … You can also have a look at this page about creating packages and running a partial debian mirror.
the server itself is also an apt client, so its sources.list could also point to the apt-proxy instead of directly to external sources. It will have at least some packages (kernel, base system, libraries, …) in common with the rest of your hosts so it could benefit from caching.
documented on: 2008-06-13
This chapter describes the two major Linux packaging systems, the Red Hat Package Manager (RPM) and the Debian GNU/Linux Package Manager.
documented on: 2004.11.09