APT 1.0 was released on the 1. April 2014 [0]! The first APT version was announced on the 1. April exactly 16 years ago [1].

The big news for this version is that we included a new “apt” binary that combines the most commonly used commands from apt-get and apt-cache. The commands are the same as their apt-get/apt-cache counterparts but with slightly different configuration options.

Currently the apt binary supports the following commands:

list: which is similar to dpkg list and can be used with flags like--installed or --upgradable.

search: works just like apt-cache search but sorted alphabetically.

show: works like apt-cache show but hide some details that people are less likely to care about (like the hashes). The full record is still available via apt-cache show of course.

update: just like the regular apt-get update with color output enabled.

APT 1.0 was released on the 1. April 2014 [0]! The first APT version was announced on the 1. April exactly 16 years ago [1].

The big news for this version is that we included a new “apt” binary that combines the most commonly used commands from apt-get and apt-cache. The commands are the same as their apt-get/apt-cache counterparts but with slightly different configuration options.

Currently the apt binary supports the following commands:

list: which is similar to dpkg list and can be used with flags like--installed or --upgradable.

search: works just like apt-cache search but sorted alphabetically.

show: works like apt-cache show but hide some details that people are less likely to care about (like the hashes). The full record is still available via apt-cache show of course.

update: just like the regular apt-get update with color output enabled.

Recently the ansible apt module got fnmatch (shell) style wildcard support for installing packages. Aparently this broke the workflow for some users who passed a “*” via a variable to apt to get the candidate version installed.

A more descriptive way of achiving this is to use the one of the special words “candidate”, “installed”, “newest” in the version tag or in the release tag.

Recently the ansible apt module got fnmatch (shell) style wildcard support for installing packages. Aparently this broke the workflow for some users who passed a “*” via a variable to apt to get the candidate version installed.

A more descriptive way of achiving this is to use the one of the special words “candidate”, “installed”, “newest” in the version tag or in the release tag.

My friend Peter (Kiwinote) has a very interessting new project called AppGrid. Its a replacement for the ubuntu software center written from scratch. Peter contributed a lot to the original software-center so he knows the problem domain quite well. You should give it a try, it can be added via:

My friend Peter (Kiwinote) has a very interessting new project called AppGrid. Its a replacement for the ubuntu software center written from scratch. Peter contributed a lot to the original software-center so he knows the problem domain quite well. You should give it a try, it can be added via:

One of the projects I created a while ago is called “rapt (restricted apt)“. As I was asked about it on irc about recently I thought I should mention it here as well :)

It is a python-apt app that will allow regular users to install/update software or install build-depends via sudo without giving them full root access. rapt will ensure that there is no interaction (like conffile prompts or debconf) that might allow the user to get a rootshell. It allows blacklisting and with a suiteable sources.list it is a easy way to give limited access to more trusted users. One use-case is to allow developers to install build dependencies on a staging machine.

You can install it via

$ bzr branch lp:rapt

and just run the binary via sudo (and a sudoers file that allows to run it). All it needs is python and python-apt (which is installed on most system anyway).

One of the projects I created a while ago is called “rapt (restricted apt)“. As I was asked about it on irc about recently I thought I should mention it here as well :)

It is a python-apt app that will allow regular users to install/update software or install build-depends via sudo without giving them full root access. rapt will ensure that there is no interaction (like conffile prompts or debconf) that might allow the user to get a rootshell. It allows blacklisting and with a suiteable sources.list it is a easy way to give limited access to more trusted users. One use-case is to allow developers to install build dependencies on a staging machine.

You can install it via

$ bzr branch lp:rapt

and just run the binary via sudo (and a sudoers file that allows to run it). All it needs is python and python-apt (which is installed on most system anyway).

When using ansible and its “setup” module to gather ad-hoc facts-data about multiple hosts, remember that it runs the jobs in parallel which may result in out-of-order output. With “ansible -f1″ the number of parallel processes can be limited to one to ensure this won’t happen. E.g.:

When using ansible and its “setup” module to gather ad-hoc facts-data about multiple hosts, remember that it runs the jobs in parallel which may result in out-of-order output. With “ansible -f1″ the number of parallel processes can be limited to one to ensure this won’t happen. E.g.:

I recently started using ansible to automate some server administration tasks.

Its very cool and easy to learn/extend. One nice feature is the “facts” gathering. It will collect information about the host(s) and stores them in its internal variables. This is useful for conditional execution of tasks (see below) but also as a ad-hoc way to gather information like DMI information or the running kernel.

I recently started using ansible to automate some server administration tasks.

Its very cool and easy to learn/extend. One nice feature is the “facts” gathering. It will collect information about the host(s) and stores them in its internal variables. This is useful for conditional execution of tasks (see below) but also as a ad-hoc way to gather information like DMI information or the running kernel.