Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

Canonical erweitert Langzeitunterstützung (LTS) auf 12 Jahre

Von: jdo
26. März 2024 um 05:12

Canonical hat eine Erweiterung für Ubuntu Pro angekündigt, die sich Legacy Support nennt. Damit erweitert sich der Support für LTS-Versionen auf 12 Jahre. Das Add-on wird für Ubuntu 14.04 LTS und später verfügbar sein. Per Standard werden LTS-Versionen 5 Jahre lang mit Security-Updates unterstützt. Dank Ubuntu Pro bekommst Du bis zu 10 Jahre Support – sowohl für das Haupt- als auch für das Universe-Repository. Abonnenten von Ubuntu Pro können nun auch das neue Legacy Support nutzen, um damit zwei weitere […]

Der Beitrag Canonical erweitert Langzeitunterstützung (LTS) auf 12 Jahre ist von bitblokes.de.

Fedora 38

19. April 2023 um 15:50

Der Frühlingsreigen neuer Distributionen hat begonnen, überraschenderweise mit Fedora statt wie sonst mit Ubuntu. (Ubuntu 23.04 ist diese Woche auch noch an der Reihe.) Heute habe ich einen ersten Blick auf Fedora 38 geworfen. Mein letzter derartiger »Minitest« liegt schon eineinhalb Jahre zurück (siehe Fedora 35).

Um es kurz zu machen: Abseits neuer Versionsnummern gibt es wenig Neuerungen — sowohl an der Oberfläche als auch hinter den Kulissen. Dass es überhaupt optische Änderungen gibt, ist dem neuen Hintergrundbild sowie Gnome 44 geschuldet. Selbst die Release Notes, sonst ein Konglomerat technischer Details, sind diesmal verblüffend leer.

Fedora 38 mit Gnome 44

Software-Versionen

Wie üblich konzentriere ich in dieser Kurzvorstellung auf die Workstation-Variante von Fedora. Die wichtigsten Versionsnummern des Software-Stacks sehen so aus:

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      6.2   Gnome          44   bash       5.2   Apache     2.4
glibc      2.37   Gimp         2.10   gcc       13.0   CUPS       2.4
X-Server   1.20   LibreOffice   7.5   git       2.40   MariaDB   10.5
Wayland    1.21                       Java        17   OpenSSH    9.0
Mesa       23.0                       PHP        8.2   qemu/KVM   7.2
Systemd     253                       Podman     4.4   Postfix    3.7
NetworkMan 1.42                       Python    3.11   Samba     4.18
GRUB       2.06 

Auf die Angabe der Versionsnummern von Thunderbird, Firefox und Chromium verzichte ist — diese Pakete werden ohnedies regelmäßig aktualisiert.

Technische Neuerungen

Fedora arbeitet an einem Unified Kernel Support. Das Ziel ist es, von am Rechner erzeugten Initramfs-Dateien wegzukommen und stattdessen den Kernel und die Initramfs-Datei als ein Paket auszuliefern. Das soll langfristig die Sicherheit verbessern. Details zu diesem Projekt können Sie auf der folgenden Seite nachlesen. Aktuell steckt das Projekt allerdings noch in den Kinderschuhen. Fedora 38 soll lediglich das Fundament für weitere Tests schaffen.

https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1

Links

Wöchentlicher Google Analytics Report per Mail

03. September 2010 um 09:22

Ist euch Google Analytics zu überladen und ihr verliert schnell den Überblick über eure Daten. Dann könnte Metric Mail genau das richtige für euch sein. Dieser Service (natürlich noch Beta) schickt euch wöchentlich einen Analytics Report per Mail zu. Klar bei Google Analytics kann man sich auch Mails schicken lassen, ich finde den wöchentlichen Report von Metric Mail dennoch ganz nett, denn man muss keine Einstellungen vornehmen. Die Anmeldung geht schnell über den Google Account und die Wochenreporte im PDF Format sind auch sehr übersichtlich. Also einfach mal austesten, kostet ja Nichts.

metric mail

 

Bundesliga-Spielplan Saison 2010/2011

06. Juli 2010 um 11:36

Bereits gestern wurde der Bundesliga Spielplan für die neue Saison 2010/ 2011 veröffentlicht.

Wer keine Dauerkarte für seinen Verein besitzt, der sollte sich schonmal Karten für ein paar Spiele sichern.

Downloadmöglichkeiten für das 13 Seiten PDF:

  • Chip.de
  • Bundesliga.de

Oder einfach alle Spieltage online nachschauen

Lösung: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead

19. Januar 2023 um 17:24

Was ist apt-key?

Die Man Pages beschreiben apt-key wie folgt:

apt-key is used to manage the list of keys used by apt to authenticate packages. Packages which have been authenticated using these keys will be considered trusted.

apt-key wird verwendet, um die Liste der Schlüssel zu verwalten, die von apt zur Authentifizierung von Paketen verwendet werden. Pakete, die mit diesen Schlüsseln authentifiziert wurden, werden als vertrauenswürdig eingestuft.

Der Vollständigkeit halber hier der Punkt zur "deprecated" Meldung:

update (deprecated)
Update the local keyring with the archive keyring and remove from the local keyring the archive keys which are no longer valid. The archive keyring is shipped in the archive-keyring package of your distribution, e.g. the ubuntu-keyring package in Ubuntu.

Note that a distribution does not need to and in fact should not use this command any longer and instead ship keyring files in the /etc/apt/trusted.gpg.d/ directory directly as this avoids a dependency on gnupg and it is easier to manage keys by simply adding and removing files for maintainers and users alike.

Was bedeutet apt-key is deprecated?

In der Fehlermeldung "apt-key is deprecated. Manage keyring files in trusted.gpg.d" sind zwei Meldungen versteckt:

Bisher wurden Schlüssel in trusted.gpg verwaltet. In Zukunft sollten die Schlüssel einzeln unter trusted.gpg.d verwaltet werden. Der Grund für das Abschaffen des alten Vorgangs ist die schlicht die Sicherheit.

Zusätzlich wird apt-key als veraltet eingestuft. Da es sich hier nur um eine Warnung handelt, kann diese bis jetzt auch einfach ignoriert werden. Im Prinzip möchte sie den Nutzer weg von apt-key hin zu gpg schubsen und genau das möchte ich hier zeigen.

Bei einem apt update wirft ein Ubuntu beispielsweise folgenden Warnungen in Bezug auf nodejs und yarn Repositorys

reading package lists... Done
W: https://deb.nodesource.com/node_16.x/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
W: https://dl.yarnpkg.com/debian/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Lösung -  Schlüssel aus trusted.gpg in trusted.gpg.d umziehen

Die Lösung für die oben aufgeführte Problematik ist das bereits erwähnte Umschichten von trusted.gpg zu trusted.gpg.d.

Zunächst werden die betreffenden Schlüssel aufgelistet:

sudo apt-key list
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
pub   rsa4096 2014-06-13 [SC]
      9FD3 B784 BC1C 6FC3 1A8A  0A1C 1655 A0AB 6857 6280
uid           [ unknown] NodeSource <gpg@nodesource.com>
sub   rsa4096 2014-06-13 [E]

pub   rsa4096 2016-10-05 [SC]
      72EC F46A 56B4 AD39 C907  BBB7 1646 B01B 86E5 0310
uid           [ unknown] Yarn Packaging <yarn@dan.cx>
sub   rsa4096 2016-10-05 [E]
sub   rsa4096 2019-01-02 [S] [expires: 2023-01-24]
sub   rsa4096 2019-01-11 [S] [expires: 2023-01-24]


Schlüssel in eine eigene Datei verschieben

Danach die letzten 8 Zeichen der zweiten Zeile unter pub kopieren. In diesem Fall ist das 6857 6280. Das Leerzeichen zwischen den Zahlen muss entfernt werden.
Der zukünftige Name kann beliebig gewählt werden, es liegt allerdings nahe, ihn nach dem installierten Paket bzw. Repository zu benennen:

sudo apt-key export 68576280 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/nodejs-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-key export 86E50310 | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/yarn-key.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

sudo apt-get update

Nun sollten die Warnungen der Vergangenheit angehören.

Neue Schlüssel hinzufügen

Sollte ein neuer Schlüssel hinzugefügt werden, wird in Zukunft nicht mehr mit apt-key gearbeitet, sondern gpg verwendet werden.

Früher

curl -sS https://download.spotify.com/debian/pubkey_5E3C45D7B312C643.gpg | sudo apt-key add -


Heute

curl -sS https://download.spotify.com/debian/pubkey_7A3A762FAFD4A51F.gpg | sudo gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/spotify.gpg

 

Potenzielle Mehrwerte einer Red Hat Enterprise Linux Subscription

12. Juni 2022 um 05:00

Wer Red Hat Enterprise Linux (RHEL) betreiben möchte, benötigte dazu eine sogenannte Subskription, im Folgenden RHEL-Sub genannt. Die Kosten für eine RHEL-Sub ergeben sich aus der Art der RHEL-Sub und dem damit verbundenen Service-Level. Der schon etwas ältere Artikel Support-Subskriptionen von SUSE und Red Hat gibt hierzu einen kleinen Einblick.

Da RHEL-Klone wie AlmaLinux und Rocky Linux kostenlos verfügbar sind, kommt schnell die Frage auf: „Warum soll ich für RHEL soviel Geld bezahlen, wenn ich quasi das gleiche OS unter anderem Namen kostenlos nutzen kann?“

Um bei der Beantwortung dieser Frage zu helfen, stelle ich in diesem Artikel einige potenzielle Mehrwerte vor, die man mit dem Erwerb einer RHEL-Sub erhält.

Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.

Kostenlose RHEL-Subs

Nicht alle RHEL-Subs kosten Geld. Es gibt auch zwei Subskriptionen, mit denen sich RHEL und bestimmten Rahmenbedingungen kostenlos betreiben lässt.

Red Hat Developer Subscription for Individuals

Ein jeder kann über das Red Hat Developers Program (engl.) kostenlos eine persönliche RHEL Developer Subscription (engl.) erhalten. Mit dieser Sub erhält der Besitzer das Recht, bis zu 16 Systeme (physisch oder virtuell) zu betreiben; auch in Produktion.

Die Subskription muss jedes Jahr verlängert werden. Die Verlängerung ist ebenfalls kostenlos.

Die Subskription beinhaltet keinen kommerziellen Support. Man hat lediglich Zugriff auf die Wissensdatenbank und die Customer Portal Community. Die SaaS-Dienste Red Hat Insights und Image Builder können auch mit dieser Subskription genutzt werden.

Red Hat Developer Subscription for Teams

Im Unterschied zur oben vorgestellten individuellen Subskription dürfen Systeme mit der RHEL-Sub-for-Teams nicht in Produktion betrieben werden. Sie dient ausschließlich der Entwicklung, dem Test und der Qualitätssicherung. Dafür dürfen mit dieser Sub eine sehr große Anzahl RHEL-Systeme provisioniert werden.

Ich bin mir nicht sicher, ob ich eine genaue Zahl nennen darf. Darum glaubt mir bitte, wenn ich euch sage: „Es sind wirklich eine Menge Berechtigungen für physische und virtuelle Systeme enthalten.“

Diese Subskription erhaltet ihr nur über euer Red Hat Account Management. Falls ihr dieses (noch) nicht kennt, wendet euch im Zweifel an die Firma, wo ihr eure RHEL-Subs kauft.

Mich selbst hat es einige Mühen gekostet, an diese Sub zu kommen. Laut Aussage meines Account-Managers war ich der erste Kunde in Deutschland, der diese Sub kannte und haben wollte. Dank der Red Hat Accelerators und meines Account-Managers, der nicht aufgegeben hat, hat es schlussendlich geklappt. Falls ihr Probleme habt, diese Sub zu bekommen, schreibt mich einfach an. Vielleicht habe ich noch einen Tipp für euch.

Für den Support, Zugriff auf Red Hat Insights und Image Builder gelten die gleichen Bedingungen wie für die RHEL Developer Subscription for Individuals.

Support

Support meint an dieser Stelle nicht die Hilfe und Unterstützung, die man auf Mailinglisten, in Foren oder Chats erhalten kann. Gemeint ist ausschließlich der kommerzielle Support der Firma Red Hat, welchen man per Telefon, E-Mail oder das Customer Portal erreichen kann.

Über den Support hat man Kontakt zu den Menschen, die sich vermutlich am besten mit dem Produkt auskennen. Hier sitzen Menschen, die dafür bezahlt werden, uns Kunden bestmöglich zu unterstützen. Dabei mag es von Fall zu Fall Schwankungen in der Reaktionszeit und/oder der Qualität geben.

Mir persönlich hat der Support schon in etlichen Fragestellungen und bei einigen hartnäckigen Problemen weiterhelfen können. Dabei waren so schöne Dinge wie Kernel Panic bei Zugriff auf eine eingehängte DFS-Ressource, deren Shares in einer HNAS-Speicher-Infrastruktur liegen. Ich glaube, sowas haben die wenigsten Menschen bei sich daheim im Keller stehen. Und die Chance, bei diesem Problem Hilfe in einem Forum oder Chat zu finden, dürfte dementsprechend gering sein. Der Support stellte in diesem Fall Kontakt zu einem Engineer her, der über eine hervorragende Kenntnis der beteiligten Protokolle und Protokollversionen verfügte und beim Debugging unterstützte. Am Ende erhielten wir einen angepassten Kernel, der das Problem löste und den wir nutzen konnten, bis das Problem auch Upstream und im regulären RHEL-Kernel gefixt wurde.

Nicht zuletzt ist kommerzieller Support ein guter Verbündeter, wenn man selbst nicht weiterweiß und sich Druck aufbaut. Nach dem Motto: „Wenn selbst der Hersteller nicht weiter weiß, woher soll ich dann wissen, warum es nicht geht?“ Es ist nie schön, wenn es soweit kommt. Noch hässlicher wird es, wenn man dann nicht auf jemand anderen zeigen kann.

Red Hat Insights

Zu Red Hat Insights (engl.) habe ich in der Vergangenheit bereits eine eigene Serie geschrieben, auf die ich an dieser Stelle verweise:

  1. Einführung in Red Hat Insights
  2. Erkundung von Red Hat Insights — Advisor
  3. Schwachstellen-Management mit Red Hat Insights
  4. Red Hat Insights – Compliance
  5. Red Hat Insights – Patch and Drift
  6. Persönliche Bewertung von Red Hat Insights

Dieser Dienst steht auch mit den kostenlosen Developer-Subs zur Verfügung. Vorausgesetzt, die Nutzung ist unter geltendem Recht möglich, stellt dieser Dienst einen echten Mehrwert dar. Ein vergleichbarer Dienst existiert für AlmaLinux und Rocky Linux nicht.

Image Builder (SaaS)

In größeren Umgebungen (IHMO >2 Systeme) werden Server meist nicht mehr individuell installiert, sondern von sogenannten Images oder Templates provisioniert. Diese sind initial zu erstellen und fortlaufend zu pflegen.

Image Builder ist ein SaaS-Dienst in Red Hat Insights, welcher bei der Erstellung solcher Templates unterstützt. Dabei können Images direkt für die Cloud Anbieter Amazon Web Services, Google Cloud Platform, Microsoft Azure, VMware vSphere, KVM/QEMU (.qcow2) und Bare Metal erstellt werden.

Es handelt sich dabei um einen noch recht jungen Dienst, der einige Einschränkungen hat. So ist das einzige derzeit unterstützte Dateisystem für Images XFS. Ein RFE, um Ext4 als unterstütztes Dateisystem hinzuzufügen, ist gestellt.

Auch lassen sich aktuell über diesen Dienst noch keine User oder SSH-Public-Keys in die Images integrieren. Für diese Funktionalität habe ich ebenfalls bereits RFEs geschrieben.

Ich bin gespannt, wie Red Hat diesen Dienst weiterentwickelt. In meinen Augen hat er das Potenzial, zu einem nützlichen Werkzeug zu reifen.

Diesen Dienst kann man ebenfalls mit den kostenlosen Developer-Subs nutzen, während ein vergleichbarer Dienst meines Wissens für AlmaLinux und Rocky Linux nicht existiert.

Fazit

Ob die genannten Mehrwerte tatsächlich zum Tragen kommen, muss jeder für sich und seine Organisation selbst beurteilen. Sie sollten jedoch vor einer Entscheidung in die Überlegungen mit einbezogen werden.

Die Nutzung von Red Hat Insights ist in unserem Rechtsraum schwierig, bis nahezu unmöglich. Dort wo der Dienst genutzt werden kann, stellt er ein gutes Werkzeug dar, welches dem Admin die tägliche Arbeit erleichtert.

Ich werde ein kleines Heimlabor aus RHEL-Servern aufbauen und diese in Red Hat Insights integrieren. Vielleicht gewinne ich dadurch Erkenntnisse, die sich auch auf den Betrieb im Rechenzentrum übertragen lassen.

Der Image Builder ist als SaaS in seiner jetzigen Form nur von geringem Nutzen für mich. Ich hoffe, dass meine RFEs akzeptiert und umgesetzt werden, um diesen Service und dessen Nutzen weiter auszubauen.

Wie kann ich von der Shell aus prüfen, ob ein entfernter TCP-Port erreichbar ist?

04. April 2022 um 06:00

Diese Frage habe ich mir selbst schon mehrmals gestellt. Und mindestens genauso oft wurde sie mir schon von anderen gestellt. Als Antwort kommen hier meist zuerst telnet oder netcat (nc) in den Sinn. Doch in einer RHEL-Minimal-Installation sind diese beiden Programme nicht enthalten und müssen erst nachinstalliert werden. Was tut man in diesem Fall (ohne den Paketmanager zu starten)?

Ich möchte in diesem Artikel mehrere Antworten auf die Eingangsfrage festhalten. Dabei beginne ich mit denen, die ich auf stackoverflow gefunden habe.

Bash und timeout

Von RHEL 6 aufwärts sollte das Programm timeout in der Minimal-Installation enthalten sein. In Fedora 35 und Debian 11 ist es ebenfalls enthalten. Es stammt aus dem Paket coreutils, in dem es meines Wissens spätestens seit Version 8.22 enthalten ist.

Kommando

$ timeout $TIMEOUT_SECONDS bash -c "</dev/tcp/${HOST}/${PORT}"; echo $?

Beispiele

Erfolgreicher Verbindungstest

$ HOST=beispiel.de
$ PORT=443
$ timeout 5 bash -c "</dev/tcp/${HOST}/${PORT}"; echo $?
0

Selbstverständlich funktioniert auch folgender Befehl:

$ timeout 5 bash -c "</dev/tcp/beispiel.de/443"; echo $?
0

Fehlgeschlagener Verbindungstest

Jetzt nutze ich einen Port, der nicht erreichbar ist:

$ timeout 5 bash -c "</dev/tcp/beispiel.de/4433"; echo $?
124

Nutzung von nc

Sollte nc bereits installiert sein, kann man auch dieses Programm für einen Verbindungstest nutzen:

Kommando

$ nc -w $TIMEOUT_SECONDS -v $HOST $PORT </dev/null; echo $?

Beispiele

Erfolgreicher Verbindungstest

$ HOST=beispiel.de
$ PORT=443
$ nc -w 2 -v $HOST $PORT </dev/null; echo $?
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 23.21.157.88:443.
Ncat: 0 bytes sent, 0 bytes received in 0.54 seconds.
0

Fehlgeschlagener Verbindungstest

$ nc -w 2 -v beispiel.de 4433 </dev/null; echo $?
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: TIMEOUT.
1

Zusammenfassung

Mit timeout und nc habe ich meine beiden Favoriten festgehalten. Mit beiden lässt sich die Erreichbarkeit von entfernten TCP-Ports testen (die von lokalen TCP-Ports übrigens auch).

Falls ihr noch weitere Möglichkeiten kennt, mit Bordmitteln, die in der Minimal-Installation einer Distribution enthalten sind, um einen Verbindungstest durchzuführen, schreibt sie mir gern in die Kommentare. Ich nehme sie dann gern mit in den Artikel auf.

Zammad sichern und wiederherstellen

Von: zefanja
06. Juli 2019 um 07:05

Seit einigen Jahren verwenden wir Zammad als Support- bzw. Helpdesk-Software in unserer Schule. Wir sind damit sehr zufrieden, denn Zammad bietet viele Features und ein angenehm zu bedienende Benutzeroberfläche. Vor einiger Zeit mussten wir unseren Server umziehen und somit auch unsere Zammad-Installation. In diesem Artikel möchte ich kurz zeigen, wie man Zammad sichern und wiederherstellen kann.

Zammad sichern

Zammad bietet von Haus aus ein Backup-Skript, welches aber standardmäßig deaktiviert ist. Man kann das Skript dazu benutzen, um regelmäßige Backups anzulegen. Es befindet sich unter /opt/zammad/contrib/backup/. Das Backup-Skript greift auf eine Konfigurationsdatei zu, in der alle wichtigen Einstellungen vorgenommen werden. Diese Datei muss man zuerst umbenennen:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Anschließend öffnet man die Datei und kann einige wenige Dinge einstellen:

$ nano /opt/zammad/contrib/backup/config 

...
BACKUP_DIR='/var/tmp/zammad_backup'
HOLD_DAYS='10'
DEBUG='no'

BACKUP_DIR legt fest, wohin die Backups gespeichert werden sollen. Das Verzeichnis muss existieren! HOLD_DAYS gibt an, wie lange ein bzw. wie viele Backup(s) aufbewahrt werden sollen.

Nun kann man das Backup-Skript ausführen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_backup.sh

Das Skript legt zwei Archive an (Datenbanksicherung und Zammad-Ordner), die sich nun im konfigurieren Backup-Ordner befinden.

Hinweis: Wenn man eine Installation migrieren möchte, ist es sinnvoll, Zammad vorher anzuhalten und erst dann das Backup zu erstellen. Das spielt aber nur bei größeren Installationen eine Rolle.

Zammad wiederherstellen

Wenn man ein Backup auf dem gleichen Host wiederherstellen möchte, kann man das mit dem Wiederherstellungsskript erledigen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Fertig 🙂

Wenn man allerdings eine Zammad-Installation umziehen möchte (Migration, Neuinstallation), gibt es einige Dinge zu beachten:

  • Zammad muss installiert sein (inklusive Elasticsearch)
  • die Zammad-Version sollte gleich oder höher sein (als die vom Backup)
  • es sollte die gleiche Datenbank verwendet werden (ein Wechsel ist wohl möglich, aber sehr aufwändig, da die Daten abgepasst werden müssen).
  • Es sollte genügend freier Speicherplatz vorhanden sein (ca. 2x so viel wie die Größe des Backups)

Wenn alle Bedingungen erfüllt sind, muss man zuerst die Konfiguration auf dem Zielsystem aktivieren:

$ mv /opt/zammad/contrib/backup/config.dist /opt/zammad/contrib/backup/config

Danach die Backupdateien in den konfigurierten Backup-Ordner kopieren (mit cp oder wenn man LXD-Container verwendet mit lxc file push/pull) und letztendlich das Wiederherstellungsskript laufen lassen:

$ cd /opt/zammad/contrib/backup
$ ./zammad_restore.sh

Weitere Informationen finden sich in der offiziellen Dokumentation.

Fazit

Zammad bringt einen einfachen Sicherungs- und Wiederherstellungsmechanismus mit, der zuverlässig funktioniert. Wer seine Zammad-Installation nicht anderweitig sichert, kann für das Backup-Skript auch einen Cron-Job einrichten, um regelmäßig ein Backup zu erstellen.

 

1 Kommentar

Der Beitrag Zammad sichern und wiederherstellen erschien zuerst auf .:zefanjas:..

❌
❌