Schlagwortarchiv: Planet

Tag für den Ubuntuusers.de Planeten.

F-Droid – Freie und Open Source Software Repository für Android

F-Droid stellt ein Repository bereit, über welches Freie und Open Source Software (FOSS) für das Betriebssystem Android bezogen werden kann.

Damit stellt das F-Droid-Repository eine Alternative bzw. Ergänzung zum Google Play-Store dar. Um die Gründe zu erläutern, die für eine Nutzung von F-Droid sprechen, möchte ich Finn Christiansen zitieren:

1. Man hat kein Google Konto, kann also den Play Store nicht nutzen, möchte aber trotzdem komfortabel Apps installieren und verwalten. (Wie in meinem Fall)
2. Man hat ein Google Konto, nutzt den Play Store, möchte aber einige Apps lieber aus dem F-Droid Repository installieren (Misstrauen gegenüber dem Play Store / keine Kosten in F-Droid)

Finn hat in seinem Artikel „Das F-Droid-Repository für Android installieren“ sehr schön beschrieben, wie man das F-Droid-Repository unter seinem Android-Gerät einrichten und nutzen kann. Leider führt der Link zu Finns Anleitung heute ins Leere. Doch lässt sich F-Droid heute auch ganz einfach, ohne gesonderte Anleitung, einrichten.

Ich möchte noch eine Empfehlung zum Schutz eures Android-Gerätes beifügen. Man muss die Installation aus Quellen unbekannter Herkunft erlauben, um F-Droid bzw. Apps aus dem F-Droid-Repository installieren zu können. Dies stellt ein Sicherheitsrisiko für euer Gerät dar. Mit dieser Einstellung kann es passieren, dass Apps oder Webseiten ohne euer Wissen Schadprogramme auf eurem Gerät installieren. Doch durch die Deaktivierung dieser Funktion nach Installation von F-Droid und der gewünschten Apps lässt sich dieses Risiko zum Glück sehr einfach minimieren.

Während der normalen Nutzung bleibt damit die Installation aus Quellen unbekannter Herkunft untersagt. Diese Option aktiviere ich nur direkt vor der Installation einer neuen App aus dem F-Droid-Repository und deaktiviere sie anschließend wieder. Die bereits installierten Apps lassen sich anschließend problemlos weiterverwenden.

Als ich diesen Artikel 2015 geschrieben habe, konnte man die Installation aus unbekannten Quellen nur global für das gesamte Gerät aktivieren. Heute ist es auf den meisten Android-Geräten möglich, diese Berechtigung für einzelne Apps zu aktivieren. Wem das oben beschriebene Prozedere zu mühsam ist, kann so z.B. ausschließlich der App „F-Droid“ die Installation aus unbekannten Quellen erlauben. Damit ist sichergestellt, dass andere Apps nicht einfach etwas nachinstallieren dürfen.

Neugierig geworden? Probiert es aus. Es tut nicht weh. Mich hat F-Droid in den vergangenen Tagen überzeugt.

ownCloud’s Federated Cloud kurz erklärt

Federated Cloud Sharing[1. Federated Cloud Sharing – Share across ownClouds!] ist eine Funktion von ownCloud. Mit dieser Funktion ist es möglich, Dateien und Verzeichnisse der eigenen ownCloud mit anderen ownClouds zu teilen.

Dies ist angeblich so einfach wie eine E-Mail zu schreiben. Man nutzt dazu die sogenannte Federated Cloud ID. Diese entspricht dem Muster username@example.com/owncloud.

Bildquelle: https://owncloud.org/federation/
Bildquelle: https://owncloud.org/federation/

Die Dokumentation[2. Using Federated Cloud Sharing] erklärt, wie es funktioniert. Dies möchte ich hier kurz wiedergeben.

Bei den zu teilenden Dateien bzw. Verzeichnissen klickt man auf das Icon zum Teilen des Elements und trägt die Federated Cloud ID der Ziel-ownCloud ein. Also z.B. username@example.com/owncloud. Wenn der eigene ownCloud-Server erfolgreich eine Verbindung zum Zielserver aufbauen kann, wird die Berechtigung in der eigenen ownCloud gespeichert.

Die empfangende ownCloud zeigt dem Benutzer einen Hinweis, den der Benutzer bestätigen muss, um die Freigabe seiner ownCloud hinzuzufügen.

Bildquelle: https://doc.owncloud.org/server/8.0/user_manual/files/federated_cloud_sharing.html
Bildquelle: https://doc.owncloud.org/server/8.0/user_manual/files/federated_cloud_sharing.html

Damit ist auch schon alles getan. Die geteilte Datei bzw. das geteilte Verzeichnis erscheint nun in der ownCloud des Empfängers. Ich würde sagen, dies ist wirklich so einfach wie E-Mail.

vlc-logo

Einzelne Bilder aus Video extrahieren

Dieser Artikel beschreibt, wie man sehr einfach mit Hilfe eines kostenlos erhältlichen Programms einzelne Bilder aus einem Video extrahieren kann.

Diese Anforderung entstand, nachdem ich ein Gewitter mit meiner Digitalkamera gefilmt habe und anschließend einzelne Bilder herausschneiden wollte.

Sehr einfach lässt sich diese Aufgabe mit der freien, quelloffenen und kostenlosen Software „VLC media player“ erledigen. VLC ist sowohl für Ubuntu-Linux als auch für Windows erhältlich. Unter Ubuntu kann das Programm einfach aus den offiziellen Paketquellen installiert werden:

sudo apt-get install vlc

Für Windows kann man sich das Programm von der offiziellen Website herunterladen.

Hat man das Programm gestartet, kann man unter Werkzeuge -> Einstellungen -> Video konfigurieren, in welchem Pfad und mit welchem Präfix die zukünftigen Schnappschüsse gespeichert werden sollen.

vlc-settings

Werkzeuge -> Einstellungen -> Video

Um Schnappschüsse aus dem Video erstellen zu können, muss noch die „Erweiterte Steuerung“ aktiviert werden. Dies erledigt man unter Ansicht -> Erweiterte Steuerung. Nun erhält man vier neue Buttons. Die wichtigsten sind dabei das kleine Kamera- und das Film-Symbol. Diese sind auf dem folgenden Screenshot gelb hinterlegt.

vlc-enhanced-control

VLC Erweiterte Steuerung

Kommt man in dem Video zu einer Stelle, von der man gern ein Bild erstellen möchte, so pausiert man das Video und erstellt mit der Kamera-Schaltfläche einen Schnappschuss. Dieser wird in dem konfigurierten Pfad abgespeichert. Mit Hilfe der Film-Schaltfläche kann man in dem Video Frame für Frame vorwärts gehen. So ist es möglich, jedes Einzelbild des Videos zu betrachten, um von den schönsten Stellen einen Schnappschuss erstellen zu können.

Statt ständig die Maus schubsen zu müssen, können die oben beschriebenen Schritte auch mit den folgenden Tastenkombinationen ausgeführt werden:

  • Video pausieren/fortsetzen -> Leertaste
  • Schnappschuss erstellen -> Umschalt+s
  • Frame für Frame vorwärts -> e

Das war auch schon alles. Einfach, praktisch, gut!

Standardgateway mit dem Linux-Kommando „route“ hinzufügen

Im Mai brachte mir ein DSM-Update auf meiner Synology Diskstation DS213air einigen Ärger ein. Nach dem Update fehlte meiner Diskstation das Standardgateway, so dass diese ihren Weg in das Internet nicht mehr finden konnte. Zum Glück lässt sich das Standardgateway mit dem folgenden Befehl schnell und einfach zur Routingtabelle hinzufügen. Und dies funktioniert nicht nur auf der Diskstation, sondern prinzipiell unter jedem Linux-Betriebssystem.

Auf der Diskstation muss man sich zuerst via SSH als root anmelden. Anschließend wir das Standardgateway wie folgt wieder hinzugefügt:

route add default gw IP-ADRESSE SCHNITTSTELLE

In meinem Fall wurde als Schnittstelle das Interface „wlan0“ verwendet. Der Befehl sieht dann konkret wie folgt aus:

route add default gw 192.168.178.188 wlan0

Leider verliert die Diskstation das Standardgateway bei jedem Neustart wieder. Ich habe daher auch eine Support-Anfrage an Synology gestellt. Leider verlief die Bearbeitung nicht meinen Wünschen entsprechend. Da ich das Standardgateway nicht nach jedem Neustart manuell hinzufügen möchte, habe ich mir daher etwas anderes einfallen lassen.

Als Workaround dient folgendes Skript. Dieses prüft, ob in der Routingtabelle ein Standardgateway vorhanden ist. Fehlt dieses, wird es durch das Skript hinzugefügt. Die IP-Adresse des Standardgateways und die verwendete Schnittstelle können dem Skript dabei über Parameter mitgeteilt werden.

Dieses Skript habe ich auf meiner Diskstation abgelegt. In den Dateieigenschaften habe ich unter „Genehmigungen“ die Berechtigung zum Ausführen der Datei erteilt. Anschließend habe ich das Skript in den Aufgabenplaner eingetragen und lasse es von nun an stündlich ausführen.

Diese Lösung ist nicht schön, aber sie stabilisiert den Betrieb meines NAS. Ich hoffe, mit diesem Beitrag meinen Leidensgenossen helfen zu können, die ebenfalls mit diesem Problem zu kämpfen haben.

Update 2015-07-05T14:05
Da das Skript im Feed nicht mit angezeigt wird, reiche ich hiermit den Link zum Skript auf GitHub nach.

Defekte Einträge im ownCloud-Kalender finden und löschen

Vor ein paar Wochen trat ein Problem mit einem meiner ownCloud-Kalender auf, welches nun endlich gelöst werden konnte.

Einer der Kalender ließ sich plötzlich nicht mehr mit dem Thunderbird Lightning Kalender oder dem Kalender unter Android synchronisieren. Zu meiner großen Freude fand ich nun auf GitHub Hilfe und konnte das Problem lösen.

Die Ursache für das Problem waren zwei defekte Einträge in diesem Kalender.

Defekte Kalendereinträge lassen sich mit folgender MySQL-Abfrage in der Datenbank finden:

SELECT * FROM oc_clndr_objects WHERE calendardata NOT LIKE '%END:VCALENDAR%'\G

Die defekten Einträge können anschließend mit dem folgenden Befehl gelöscht werden:

DELETE FROM oc_clndr_objects WHERE calendardata NOT LIKE '%END:VCALENDAR%'\G

Nachdem ich mit diesen beiden Befehlen die defekten Kalendereinträge entfernt habe, konnte ich den Kalender erneut sowohl mit Lightning als auch mit Android synchronisieren.

Logging und logrotate mit NGINX

In diesem Artikel wird beschrieben, wie ich das Logging und logrotate meines NGINX-Servers konfiguriert habe. Dabei gehe ich kurz auf die beiden verwendeten Direktiven error_log und ngx_http_log_module ein.

Damit dient dieser Artikel meiner Dokumentation und evtl. euch als Anregung, ein eigenes Logging zu konfigurieren.

Logging

Informationen zum Logging findet man in der offiziellen NGINX-Dokumentation.[1. NGINX-Dokumentation] Im folgenden werden die Direktiven error_log[2. NGINX core module error_log] und ngx_http_log_module[3. NGINX – ngx_http_log_module] verwendet.

Mein Server liefert mehrere Webseiten aus. Ich möchte gern für jede Webanwendung ein separates Error-Log und Access-Log schreiben. Dabei wird folgendes Muster verwendet:

  • Log-Verzeichnis: /var/www//logs
  • Name für error_log: _error.log
  • Name für access_log: _access.log

Konfiguration des Error-Log

Die Error_log-Syntax ist denkbar einfach:

error_log log_file [ log_level ]

log_file gibt den Pfad zur Log-Datei an. Mit log_level wird bestimmt, wie viele Informationen protokolliert werden sollen.

Log-Level[4. How To Configure Logging and Log Rotation in Nginx on an Ubuntu VPS]

  • emerg: Notfall, in dem sich das System in einem nicht nutzbaren Zustand befindet
  • alert: Ernste Störung. Sofortiger Eingriff ist erforderlich
  • crit: Kritische Probleme, um die man sich kümmern sollte
  • error: Ein Fehler ist aufgetreten. Hier funktioniert etwas nicht
  • warn: Ein ungewöhnliches Ereignis ist aufgetreten. Dies ist jedoch kein Grund zur Sorge
  • notice: Normale Vorgänge werden ebenfalls protokolliert
  • info: Unnützes Wissen – Nice to know
  • debug: Debugging-Informationen, welche helfen, ein Problem näher zu analysieren

Die Log-Level sind nach Priorität angeordnet. Wird das Level auf „error“ gesetzt, so werden alle Events der Level error, crit, alert und emerg protokolliert.

Möchte man rein gar nichts protokollieren, muss das Log nach /dev/null umgeleitet werden.

error_log /dev/null crit;

Konfiguration des Access-Log

Das Modul ngx_http_log_module besteht aus den Direktiven access_log, log_format und open_log_file_cache, von denen ich hier nur die ersten beiden verwenden werde.

Mit der Direktive log_format kann das Format der Log-Dateien konfiguriert werden. Die einzelnen Formate werden über einen Bezeichner ausgewählt. Dies kann z.B. wie folgt aussehen:

log_format compression '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $bytes_sent '
                       '"$http_referer" "$http_user_agent" "$gzip_ratio"';

access_log /spool/logs/nginx-access.log compression buffer=32k;

Eine detaillierte Beschreibung aller verfügbaren Parameter kann der offiziellen Dokumentation entnommen werden.[5. NGINX -log_format]

Ich selbst verwende aktuell ausschließlich das Format combined. Dieses ist bereits in der Standardinstallation enthalten. Es sieht wie folgt aus:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Für die Protokollierung meiner Webanwendungen wird daher folgendes in die jeweiligen Server-Direktiven eingetragen:

server {
...
access_log /var/www//logs/_access.log combined;
...
}

Falls man das Access-Log deaktivieren möchte, kann man dies durch den folgenden Eintrag erreichen:

access_log off;

Nun werden schon mal alle Log-Dateien nach Webanwendungen getrennt in das Verzeichnis /var/www//logs geschrieben.

Im nächsten Abschnitt gehe ich darauf ein, wie man verhindert, dass die Festplatte mit Log-Dateien vollgeschrieben wird.

Rotation der NGINX Log-Dateien

Zum Rotieren der Logs verwende ich die Anwendung logrotate. Diese ist bei Ubuntu bereits in der Standardinstallation enthalten.

Es wird ein Skript im Verzeichnis /etc/logrotate.d erstellt und folgender Inhalt eingefügt.

/var/www//logs/*.log {
        daily
        missingok
        rotate 31
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
                [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
        endscript
}

Mit diesem Skript wird logrotate angewiesen, die Log-Dateien im Verzeichnis /var/www//logs/ täglich zu rotieren und die letzten 31 Log-Dateien zu behalten. Die Log-Datei wird nicht rotiert, falls sie leer ist, also keine Einträge enthält. Die älteren Dateien werden dabei komprimiert, um Speicherplatz zu sparen.

Die generelle Beschreibung von logrotate würde den Rahmen dieses Artikels sprengen. Weitere Informationen sind in der Manpage zu finden.[6. logrotate(8) – Linux man page]

Damit ist der verspätete Frühjahrsputz auf diesem Server beendet.

SSL-Schwachstelle bedroht Web- und Mail-Server

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.[1. Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet] [2. Tausende Web-Server betroffen: Neue HTTPS-Sicherheitslücke aufgetaucht] [3. Guide to Deploying Diffie-Hellman for TLS]

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt „3.“ nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden „Cipher Suites“ und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.

Thunderbird Adressbuch mit ownCloud Kontakten synchronisieren

Dieser Artikel basiert auf der offiziellen ownCloud Dokumentation[1. Thunderbird – Synchronize Addressbook] und beschreibt die Einrichtung eines Thunderbird-Adressbuchs zur Synchronisation mit den ownCloud-Kontakten.

contacts-carddav-link

Menü zum CardDAV-Link

Neben dem Thunderbird-Mailclient wird die Erweiterung Lightning[2. Mozilla Thunderbird Lightning Calendar] benötigt. Wie man diese Erweiterung nutzt, um z.B. den ownCloud-Kalender mit Thunderbird zu synchronisieren, habe ich bereits an dieser Stelle beschrieben.

Um neben dem Kalender auch die Kontakte synchronisieren zu können, wird darüber hinaus der Sogo Connector[3. Sogo Connector] benötigt. Am einfachsten installiert man diese Erweiterung, indem man einen Rechtsklick auf die Erweiterung ausführt und „Ziel speichern unter..“ aus dem Kontextmenü auswählt. In Thunderbird richtet man diese Erweiterung ein, indem man im Add-on Menü die Option „Add-on aus Datei installieren…“ auswählt.

Sind die beiden Erweiterungen erfolgreich installiert, kann das Adressbuch eingerichtet werden. Dazu öffnet man das Thunderbird-Adressbuch aus der Symbolleiste. Im sich öffnenden Fenster wählt man Datei->Neu->Remote-Adressbuch.

Der Verbindungsname kann frei gewählt werden. Bei URL wird der CardDAV-Link eingetragen, den man in den Einstellungen der ownCloud-Kontakte findet. Die Einstellungen verbergen sich hinter dem kleinen Zahnradsymbol.

remote-addressbook-settings

Remote-Adressbuch-Einstellungen

Die weiteren Optionen können nach den persönlichen Vorlieben gewählt werden. Einzig den Haken bei „Nur lesbar“ sollte man nicht setzen, wenn man über Thunderbird auch neue Kontakte in der ownCloud anlegen möchte.

Fertig. Damit sind die ownCloud-Kontakte in den Mailclient integriert und lassen sich z.B. für die Autovervollständigung der E-Mail-Adressen in neuen Nachrichten nutzen.

Cisco AnyConnect VPN Client unter Ubuntu installieren

Dieser Artikel beschreibt die Installation des Cisco AnyConnect VPN Client unter Ubuntu Trusty Tahr.

Laut einem Dokument[1. AnyConnect – Unterstützte Betriebssysteme und Systemvoraussetzungen], dass ich bei der Universität Bielefeld gefunden habe, werden Ubuntu 9.x und 10.x unterstützt. Ich konnte den Client jedoch auch problemlos unter Ubuntu 14.01.1 LTS installieren.

Dazu habe ich einfach das Installationsskript vpnsetup.sh heruntergeladen, ausführbar gemacht und ausgeführt.

:~$ wget https://github.com/Tronde/Schriftrolle/blob/master/vpnsetup.sh
:~$ sudo chmod u+x vpnsetup.sh
:~$ sudo ./vpnsetup.sh

Ist das Setup durchgelaufen, kann der Client aus dem Anwendungsmenü heraus gestartet werden.

cisco anyconnect secure mobility client

Cisco AnyConnect Secure Mobility Client

In das Feld „Connect to“ müsst ihr nun nur noch eureb Verbindungsserver eintragen und schon kann es losgehen.

Die Installation ist damit abgeschlossen. Das war es schon. :-)

Das lokale Paketarchiv aufräumen

Während ich im Artikel „Automatische Installation von Sicherheitsupdates“ beschrieben habe, wie man Sicherheitsupdates unter Ubuntu automatisch installieren lassen kann, werde ich hier kurz beschreiben, wie das lokale Paketarchiv automatisch bereinigt werden kann.

In der Datei /etc/apt/apt.conf.d/10periodic gibt es unter anderem den folgenden Eintrag:

APT::Periodic::AutocleanInterval "0";

Dieser Wert gibt an, in welchem Intervall (in Tagen) das lokale Archiv der Paketquellen bereinigt werden soll. Dieser Wert steht standardmäßig auf „0“. Damit wird das Paketarchiv gar nicht automatisch bereinigt. Um dies zu ändern trägt man hier einfach einen Wert seiner Wahl ein. So lasse ich das Paketarchiv bspw. alle 28 Tage bereinigen:

APT::Periodic::AutocleanInterval "28";

Viele Grüße
Tronde