First package update

The Debian installer created a fairly adequate APT configuration for a testing installation:

$ cat /etc/apt/sources.list
#

# deb cdrom:[Debian GNU/Linux stretch-DI-alpha3 _Stretch_ - Official Snapshot amd64 NETINST Binary-1 20150911-21:26]/ stretch main

#deb cdrom:[Debian GNU/Linux stretch-DI-alpha3 _Stretch_ - Official Snapshot amd64 NETINST Binary-1 20150911-21:26]/ stretch main

deb http://deb.debian.org/debian/ stretch main
deb-src http://deb.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

However here the goal is setting up a system that will continue to track the Debian testing branch, even after one particular version has been released as stable. Moreover, having a permanent Internet access makes the use of local CD repositories inconvenient and superfluous. Hence, edit the repository list:

# vi /etc/apt/sources.list

until it looks like:

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian testing main

deb http://deb.debian.org/debian-security testing-security main

Then install a package manager front-end:

# apt update && apt install --no-install-recommends aptitude

and execute the first package update:

# aptitude update && aptitude safe-upgrade

Some packages will be upgraded, if you answer "Y" when asked for confirmation. These commands can be used from now on, in order to keep the system up-to-date.

Special cases

Sometimes some of the packages that need to be upgraded won't be: they will be "kept back". This can happen, e.g., when the new candidate version of the package has some unsatisfied dependencies that are not present in the currently installed version: when that happens, the aptitude safe-upgrade command may refuse to upgrade the package. You can use:

# aptitude full-upgrade

to upgrade these packages as well.

During an upgrade, some unused packages may be removed: if you have no special need to keep their configuration files, you can manually purge them. Use the following command to see which packages have been removed without purging their configuration files:

$ aptitude search ~c

Then purge the packages whose configuration files are no longer useful:

# aptitude purge oldpackage uselesspackage

If you want unused packages to be purged as soon as they are automatically removed, you may use the --purge-unused command-line option, as in:

# aptitude update && aptitude --purge-unused safe-upgrade

or in:

# aptitude --purge-unused full-upgrade

During an upgrade, some newly recommended packages may be pointed out to the superuser, but they are not automatically installed. If you are interested in them, you can manually install them and immediately mark them as if they had been automatically installed:

# aptitude install firstrecompackage+M secondrecompackage+M

Upgrading the kernel

Sooner or later, an upgrade will involve the kernel. The linux-image-amd64 package should be already installed:

$ aptitude search linux-image-amd64
i   linux-image-amd64               - Linux for 64-bit PCs (meta-package)
p   linux-image-amd64-dbg           - Debugging symbols for Linux amd64 configuration (meta-package)

This package depends on the latest Linux kernel image package available from Debian repositories: when this package is upgraded, a new kernel image is automatically installed. After that, you should reboot as soon as possible, in order to take advantage of the new kernel.

Please note that, you could mark the newly installed kernel image as if it had been manually installed, in order to prevent its automatic removal in the future:

# aptitude unmarkauto linux-image-x.y.z-r-amd64

However, doing so is superfluous, thanks to the APT configuration setting that specifies some linux image packages in the NeverAutoRemove section (see file /etc/apt/apt.conf.d/01autoremove-kernels), which forbids any automatic removal of recent Linux kernel image packages.

After a number of kernel upgrades, you might end up having several kernel images installed at the same time (the GRUB boot menu lets you choose which one is to be loaded): you can purge the oldest ones:

# aptitude purge linux-image-a.b.c-s-amd64

but remember that it's a good idea to keep at least two of them which work for sure.

In order to improve the compression of initialized RAM disk images (initrd), you may want to have the following package installed:

# aptitude install zstd

Anything to restart?

After the upgrade, some programs could still be using old versions of the files replaced by the upgrade (this situation typically arises when a library is upgraded, and there are programs linked to it which are still running). In order to fully get the benefits of the upgrade, the above-mentioned programs have to be restarted. Which programs? You can issue the checkrestart command to find out. This command is included in the debian-goodies package, hence you have to install it first:

# aptitude --without-recommends install debian-goodies \
  python3+M procps+M lsof+M

Now, after each package update, you can check which programs should be restarted:

# checkrestart

Easily install packages from unstable

Sometimes you may want to temporarily install one package from the Debian unstable branch (e.g.: because it fixes a bug that affects you and you cannot wait for it to migrate to the testing branch). In order to be ready to easily install packages from unstable, edit the APT preferences file until it looks like:

$ cat /etc/apt/preferences
Package: *
Pin: release o=Debian,a=testing*
Pin-Priority: 800

Then, edit the repository list until it looks like:

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian testing main
deb http://deb.debian.org/debian unstable main

deb http://deb.debian.org/debian-security testing-security main

Now, you can update packages as usual:

# aptitude update && aptitude --purge-unused safe-upgrade

Package upgrades will track the testing branch by default, except for those installed packages which are already newer than their version in testing (those packages will track the unstable branch, until their installed version is available from testing).

When you want to install a package from unstable or upgrade it to its version in unstable, you have to explicitly specify your intention to do so:

# aptitude -t unstable install package

Check bugs before updating

For a system which will go on tracking the Debian testing branch, checking bugs filed against packages before upgrading them could be a useful thing to do in order to be a little safer. A package that helps to automate that is apt-listbugs:

# aptitude install apt-listbugs reportbug

How does it work? When you are about to install/upgrade some packages, it automatically displays high severity bugs that concern the package versions to be installed. A textual user interface lets you read the bug reports you are interested in, and decide to go on with the installation, abort it, or automatically pin some packages so that they won't get installed/upgraded. The pinning will be automatically removed by a daily cron job, as soon as the bugs are fixed, downgraded or anyway no longer affect the package.

If you have some experience in reporting bugs to the Debian BTS and some familiarity with Debian policies, you may want to configure reportbug so that it runs in "standard" mode (the default mode is "novice"), when you use it from your regular user account. If this is the case, run reportbug with the following option:

$ reportbug --configure

and select "2 standard" default operating mode, "1 text" default interface. You'll be asked whether reportbug will often have direct Internet access: you should probably answer "Y". Then you'll be asked what real name and which of your email addresses to use: you may confirm the proposed ones or enter different ones. Finally, you'll be asked whether you have an MTA configured to send outgoing mail: you may answer "N" and then just press [Enter], when asked to specify your SMTP smarthost and when asked to specify your proxy.

Cleaning the system up

Sometimes a package that was previously included in Debian testing or unstable gets removed for some reason. If you had previously installed that package, nothing special warns you about this removal (unless some other upgraded package conflicts with the no longer available one).

Fortunately, you can find out which packages are installed, but not available from any of the configured repositories. In order to do this, issue the following command:

$ aptitude search ~o

Moreover, you can find out which packages are installed, but not available from any of the Debian testing configured repositories. You can do so with the following command:

$ aptitude search '~i!~Atesting'

In the output of these commands, you can find packages that you manually installed without pulling them from currently configured repositories: everything's fine, you simply have to know what you're doing! You can also find packages (especially libraries) that were previously installed to satisfy some dependency, but are now obsolete and substituted by other newer packages satisfying that dependency: you can safely purge obsolete packages, unless they have some installed reverse dependency:

# aptitude --purge-unused purge obsoletepackage

You can also find packages that were removed from Debian testing or unstable, but are still useful for you: in those cases, you'd better investigate the reasons why those packages got removed and see whether you can help in getting them back into testing or unstable, or find convenient alternatives!

You can also search for broken packages that need some kind of intervention in order to complete the installation or removal:

$ aptitude search ~b

Moreover, you can search for packages whose installed version differs from the newest one available on the configured official Debian repositories. In order to do so, install the following package:

# aptitude install apt-forktracer

and issue the following command:

$ apt-forktracer -v

Sometimes Aptitude defers some actions, rather than performing them immediately. You can see which deferred actions are waiting to be performed with the following command:

$ aptitude -s install

You can cancel undesidered actions by scheduling the opposite actions. For instance, you do not want to actually install a package waiting to be installed, you can schedule its purging:

# aptitude --schedule-only purge unwantedpackage

When you are satisfied with the scheduled actions, you can actually perform them:

# aptitude install

Cleaning APT cache

In order to prevent the APT cache from growing indefinitely and filling up the partition where /var/cache/apt/archives/ lives, you should run the following command from time to time:

# aptitude autoclean

This will get rid of old cached packages that are currently not available from any of the configured repositories.

However, it is safer to leave currently installed packages in the cache, even when they are no longer available from configured repositories (you could need to easily reinstall them). In order to do so, create the following file:

# echo 'APT::Clean-Installed "false";' > /etc/apt/apt.conf.d/local_cleaninst

# aptitude install net-tools

# netstat -taup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                           1264/dhclient

# dpkg -S $(which dhclient)
isc-dhcp-client: /sbin/dhclient

User privacy

Debian default umask is 022, which seems to be too permissive: let's set it to 007 (Debian uses private user groups by default and we want to follow this scheme, so group-permissions may be as broad as user-permissions, without any negative consequences).

Edit file ~/.profile for the user created during the installation and change its umask line into:

umask 007

The same modification must be made for future users (file /etc/skel/.profile). Other files will need similar changes as soon as other shells besides GNU Bash are installed...

On the other hand, for the root user the umask should stay 022: make sure that there is a line like:

umask 022

in the file /root/.bashrc.

Now, prevent undesired visits into root's home directory:

# chmod 0700 /root

and into the previously created user's home directory:

$ chmod 0700 ~

Check that this is the default for new users:

$ grep [^_]DIR_MODE /etc/adduser.conf
# Default: DIR_MODE=0700
#DIR_MODE=0700

and also check:

$ grep ^HOME_MODE /etc/login.defs
HOME_MODE       0700

Finally, a nice privacy-increasing trick should be already implemented for regular users:

$ cat /etc/skel/.bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.

# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi

Let's extend it to root as well:

# cp -i /etc/skel/.bash_logout /root

Boot process

Since there's only one operating system on the box, you do not want the GRUB update process to search for other ones in dual-boot. As a consequence, remove the following package:

# aptitude --purge-unused purge os-prober

Shutdown via power button

If you want the power button to initiate a (software) system shutdown, you may need the following package:

# aptitude install acpid

Unused packages

Try to avoid leaving unused packages installed. For instance, if you have openbsd-inetd installed, but you don't use it, you can:

# aptitude --purge-unused purge openbsd-inetd

Adding other users

You can add other users to the system:

# adduser --disabled-login $SOMEOTHERUSER

where $SOMEOTHERUSER should be substituted with the actual username that was chosen. Enter the user's full name, room number, work phone, home phone, and other data, as appropriate. Finally confirm the correctness of the provided data. Add the newly created user to some groups:

# for GROUP in cdrom floppy audio dip video plugdev netdev ; do \
  adduser $SOMEOTHERUSER $GROUP ; done

When the user is ready to set his or her password, you can let him or her type it:

# passwd $SOMEOTHERUSER

Now the user should be able to login and have fun!

Removing users

If you want to remove a user (along with his/her home directory, mail spool, and other owned files), issue the following command:

# deluser --remove-all-files $BADUSER

where $BADUSER should be substituted with the actual username of the user to be removed. Please note that the private user group will be automatically removed as soon as it is left without any member.

Keeping an eye on who logged in

In order to query a database of login and logout times of users and when the machine got rebooted, install the following package:

# aptitude install wtmpdb

which ships the wtmpdb command and also the last symlink-command.