move IT Home Base

Telnet

anonymous@undisclosed.example.com (Anonymous) — Fri, 29 Nov 2019 13:47:38 +0000

Telnet

Die Vorraussetzungen für die Installation von zusätzlicher Software auf der LinkStation ist ein Telnet-Zugang, der von Haus aus nicht verfügbar bzw. noch nicht aktiviert ist. Um Telnet auf der LinkStation aktivieren zu können wird das Java-Programm ACP-Commander benötigt. Dieses Programm kann hier heruntergeladen werden. Entpacken Sie das ZIP-komprimierte Programm auf ihre Festplatte ihres Windows-PC in einen beliebigen Ordner. Öffnen Sie nun die Kommandozeile ihres PC indem Sie auf <START> klicken und anschliessend auf <Ausführen>. In dem sich dann öffnenden Eingabefeld geben Sie CMD ein. Nun befinden Sie sich in der DOS-Eingabeaufforderung. Wechseln Sie nun mit dem Kommando cd <Ordnername> in den Ordner in dem Sie den ACP-Commander gespeichert haben. Geben Sie nun folgendes Kommando ein:

java -jar acp_commander.jar -t IP-Adresse -o

Statt IP-Adresse geben Sie die richtige IP-Adresse Ihrer LinkStation an, z.B. 192.168.0.10. Anschliessend drücken Sie die <ENTER>-Taste. Es erscheint dann folgendes:

Using random connID VALUE = FB6A7FCF57E6
Using target: 192.168.0.10/192.168.0.10
** NO message **
** NO message **
Password changed.

Nun können Sie sich über Telnet auf der LinkStation einloggen. Dazu wird folgende Eingabe in einem DOS-Eingabefeld gemacht:

telnet IP-Adresse

Statt IP-Adresse geben Sie wieder die richtige IP-Adresse Ihrer LinkStation ein. Anschliessend drücken Sie wieder die <ENTER>-Taste.

<note important>Auf Windows Vista und Windows7 müssen Sie den Telnet-Client auf Ihrem System erst aktivieren. Um Telnet auf Windows Vista und Windows7 zu aktivieren klicken Sie auf <Start> und danach auf <Systemsteuerung>. Klicke im Systemsteuerungsfenster auf <Programme und Funktionen>. Klicke jetzt links im Menü auf <Windows-Funktionen ein- oder ausschalten>. Scrollen Sie zum Punkt <Telnet-Client> und aktivieren Sie ihn. Abschliessend klicken Sie auf <OK>. Telnet steht nun nach einem Neustart des Systems zur Verfügung.</note>

Es kommt nun eine Aufforderung den Benutzernamen einzugeben. Geben Sie als Benutzernamen root ein und bestätigen Sie mit der <ENTER>-Taste. Als Passwort geben Sie nichts ein und bestätigen ebenfalls mit der <ENTER>-Taste. Sie sind nun per Telnet auf der LinkStation eingeloggt. Um den Telnet-Zugang dauerhaft zu aktivieren müssen Sie eine Änderung an der Datei rcS vornehmen. Gebt dazu in der Kommandozeile von Telnet ein:

vi /etc/init.d/rcS

Vi ist der integrierte Editor in der LinkStation. Suchen Sie in der Datei rcS nach der Zeile:

#/usr/sbin/telnetd

und entfernen Sie die Raute vor diesem Eintrag. Bei manchen LinkStationen ist dieser Eintrag noch nicht vorhanden. Sollte das bei Ihnen der Fall sein so müssen Sie ihn neu anlegen. Nachdem Sie die Datei gespeichert haben wird der Telnet-Zugang auch bei einem Neustart der LinkStation aktiviert bleiben.

Es ist zur Zeit noch kein Passwort für den Telnet-Zugang vorhanden, denn er wurde mit dem ACP-COMMANDER gelöscht. Der Telnet-Zugang sollte unbedingt passwortgeschützt sein, sonst kann die LinkStation auch von unbekannten Personen verändert werden. Geben Sie in der Telnet Eingabeaufforderung folgendes ein:

passwd

Die LinkStation fragt nun nach einem neuen Passwort. Geben Sie ein neues Passwort ein und bestätigen Sie es mit <ENTER>. Der Telnet Root-Zugang zur LinkStation ist nun mit einem Passwort geschützt. Beim nächsten Einloggen in die LinkStation via Telnet müssen Sie für den User root das neue Passwort bei der Abfrage password eingeben. Sollten Sie das Root-Passwort einmal vergessen, können Sie es mit Hilfe des acp_commander jederzeit wieder löschen.

SCCM

anonymous@undisclosed.example.com (Anonymous) — Thu, 23 Sep 2021 09:10:38 +0000

SCCM

Microsoft System Center Configuration Manager (SCCM) (seit Version 1910 Microsoft Endpoint Configuration Manager) ist eine Software-Managementsuite von Microsoft, mit der Benutzer eine große Anzahl an Windows-Computern verwalten können. SCCM bietet Fernverwaltung, Patch-Verwaltung, Installation von Betriebssystemen, Netzwerkschutz und andere Dienste.

https://www.microsoft.com/de-at/security/business/microsoft-endpoint-manager

Websites

PXE-Boot

anonymous@undisclosed.example.com (Anonymous) — Sat, 22 Aug 2020 21:40:34 +0000

PXE-Boot

Vorwort

Das booten eines Betriebssystems von einem zentralen Repository im lokalen Netzwerk statt vom lokalen Datenträger bietet viele Vorteile, beispielsweise lassen sich so temporär oder zum testen Betriebssysteme laden die lokal nicht installiert sind, oder es können Betriebssysteme installiert werden (auch als Rollout im gesamten LAN), auch wenn kein USB-Anschluss oder optisches Laufwerk (CD/DVD) vorhanden, oder wenn der passende Installations-Datenträger auf DVD gerade nicht verfügbar ist und es lassen sich so ganz komfortabel komplette Tools wie die „Ultimate Boot-CD“ laden um beispielsweise Probleme mit einer Windows-Partition zu bereinigen. In Firmen werden (neue) Betriebssysteme und Aktualisierungen (Patches) fast immer über ein zentrales Repository der IT-Administration ausgerollt, beispielsweise über Microsofts SCCM (System Center Configuration Manager). Für den Privatbereich gibt es einige Netzwerkspeicher wie beispielsweise die aktuellen NAS-Modelle von Synology die von Haus ein PXE-Boot unterstützen. Ab der Firmware Synology DSM 4.2 ist es möglich direkt vom NAS zu booten.

Microsoft´s SCCM kann seit dem 22.3.2018 nicht mehr mit Linux umgehen, da der dazu normalerweise benötigte Agent von Microsoft in der aktuellen SCCM-Version (seit SCCM 1902) rausgenommen wurde. Es bleibt jetzt nur noch die Möglichkeit eines „Handovers“ indem der SCCM einen externen PXE-Boot-Server (z.B. DNSmasq) antriggert. Alternative ist Microsoft Azure. Damit zukünftig beide Systeme (Windows/Linux) für Rollouts, oder Live-Systeme unterstützt werden können, muß parallel zum Microsoft DHCP-Server mit SCCM UEFI Boot-Server ein separater PXE-Server aufgesetzt werden der Deployments ausserhalb der Windows-Welt möglich macht. Dieser separate PXE Boot-Server kann auf einem beliebigen Windows-, oder Linux-PC installiert werden. Für Windows gibt es z.B. die fertige Lösung „AOMEI PXE Boot Free 1.5“, die allerdings nur immer ein bestimmtes ISO-Image ausliefern kann. Für Linux bietet sich „DNSmasq“ an, da dieser bereits alle notwendigen Komponenten wie DHCP-Proxy und TFTP-Server integriert hat.

Scenarios

Grundsätzlich gibt es zwei verschiedene Netboot-Scenarios:

Live-System laden ohne Installation - Man bootet über das Netzwerk um darüber ein Live-System zu starten, das ohne Installation auskommt und daher auch keine Festplatte benötigt. Da das komplette Live-System ins RAM geladen wird ist die Auswahl an Live-Systemen sehr klein, der Rechner sollte mindestens 4 GB RAM haben, besser 8 GB RAM und das OS sollte möglichst klein sein, damit noch Platz für die Arbeitsdateien im RAM bleibt. In diesem Fall läuft alles ausschliesslich im RAM ab, die Festplatte bleibt komplett unberührt.

Installation übers Netzwerk - Man bootet über das Netzwerk um darüber ein Betriebssystem zu installieren das auf der lokalen Festplatte eingerichtet wird. In diesem Fall lädt man per Netboot nur einen Installer, der anschließend die restlichen Daten aus einem zentralen Repository im LAN oder über das Internet holt.

Voraussetzungen

Aktivieren von PXE-Boot im BIOS (Preboot Execution Environment)
Funktioniert nur im LAN
Funktioniert nur mit dynamischer IP via DHCP
Zusätzlicher DHCP-Proxy
Zusätzlicher TFTP-Server
OS-Image als fertiges Netzwerk-Installationsprogramm oder als Live-System ohne Installation
Im BIOS muß Secure Boot deaktiviert werden, da fast alle bootbaren ISO-Images nicht digital signiert sind

Pre-Install

Im BIOS prüfen ob sich der Rechner auf Netzwerk-Boot (PXE-Boot) umschalten lässt. Alternativ über das Boot-Menü (je nach Rechner via F8, F10 oder F12) den Netzwerkadapter als Startgerät auswählen. Falls dieser nicht auswählbar ist, im BIOS nachsehen ob er als Startgerät aktivierbar ist.
Secure Boot muß deaktiviert werden
Fast immer muß auch UEFI-Boot deaktiviert werden, stattdessen Legacy Boot einschalten

Testumgebung

Da der Test für Netboot nur in einer abgeschotteten, vom restlichen Netzwerk getrennten Test-Umgebung stattfinden kann um den produktiven Betrieb im Netzwerk nicht zu stören, wurden zwei Rechner an einen separaten Netzwerk-Switch gehangen der keinen physikalischen Anschluss an das restliche Netzwerk hat. Der als PXE-Server fungierende Rechner muß dabei eine statische IP-Adresse haben, damit diese feste IP in die LAN-Konfiguration der Clients eingetragen werden kann. Nun kann man in dieser abgeschotteten Umgebung allerdings nicht den tatsächlichen Verlauf eines Netboots simulieren, denn es fehlen DNS, DHCP und Gateway. Somit kann kein Netboot mit Installation getestet werden, sondern nur Netboot mit einem Live-System ohne Installation. Beim starten des Clients bekommt dieser keine IP-Adresse des DHCP-Proxys zugewiesen, denn dieser kommt ausschliesslich vom richtigen DHCP-Server. DNS wird benötigt um die Namensauflösung zu garantieren, sonst kann nur mit statischen IP gearbeitet werden, das ist aber in der Produktivumgebung so nicht der Fall. Bei einem vorhandenen DHCP darf DNSmasq nur als DHCP-Proxy laufen, oder der vorhandene DHCP muß einen IP-Bereich frei lassen der dann von DNSmasq benutzt werden kann. Das Gateway (Internetzugang) wird benötigt um das Installationsimage vom Repository nachzuladen wenn ein Netboot mit anschließender Installation ausgewählt wird. Bei DNSmasq müsste eine Forwarder-DNS angegeben werden, aber ohne Gateway auch kein Nameserver in höherer Instanz.

DNSmasq

DNSmasq ist:

DNS-Server für das lokale Netzwerk
DNS-Forwarder
DNS-Cache
DHCP-Server / DHCP-Proxy
TFTP-Server

DNSmasq bzw. genauer DNSmasq_base ist in allen aktuellen Debian-basierenden Linux-Distributionen enthalten. DNSmasq_base wird dabei vom Network Manager benutzt. Um DNSmasq als PXE Boot-Server einzusetzen muß zunächst eine vollständige DNSmasq Installation eingerichtet werden. In allen Debian-basierenden Linux-Repositorys ist dieser bereits enthalten. Installation mit:

sudo apt-get install dnsmasq

Anschliessend muß DNSmasq passend konfiguriert werden:

sudo gedit /etc/dnsmasq.conf

Folgende Konfiguration ist in der DNSmasq Konfigurationsdatei einzutragen:

# Den in DNSmasq enthaltenen DNS-Server deaktivieren port=0 # Bei Bedarf die DHCP-Transaktionen mitloggen, sonst auskommentieren log-dhcp # Root-Verzeichnis mit den Boot-Images auf dem TFTP-Server setzen enable-tftp tftp-root=/var/lib/tftpboot #Boot-Filename für PXE-Boot setzen dhcp-boot=pxelinux.0 # Boot-Filename, Server-Name, Server-IP # Erster Parameter = Option 67 mit File-Location auf dem Server # Zweiter Parameter = Server-Hostname # Dritter Parameter = IP-Adresse des PXE-Servers dhcp-boot=pxelinux, pxeserver, 192.168.1.1 # Doppelte DHCP-Benutzung deaktivieren um alte DHCP-Clients nicht zu verwirren dhcp-no-override # Bekannte Rechner-Architekturen vorauswählen. Damit kann gezielt das passende # Boot-Images ausgerollt werden. Diese werden auch genutzt wenn der Anwender # im Boot-Menü keine Auswahl trifft # x86PC, PC98, IA64_EFI, Alpha, Arc_x86, Intel_Lean-Client, IA32_EFI # BC_EFI, Xscale_EFI, X86-64_EFI pxe-service=x86PC, „Boot via PXE-Server“, pxelinux # Möglichkeit 1: zusätzlicher DHCP IP-Bereich und Lease-Time angeben dhcp-range=192.168.1.1,192.168.1.100, 12h # Möglichkeit 2: oder als DHCP-Proxy der keine IP vergibt dhcp-range=192.168.1.1,proxy,255,255,255,0 # Interfaces und Adressen auf die der DHCP reagieren soll interface=eth0 listen-address=127.0.0.1 listen-address=192.168.1.1

Anschließend muß die neue DNSmasq Konfiguration geladen werden:

sudo service dnsmasq restart

Damit werden Legacy BIOS PXE Anfragen von DNSmasq abgefangen und umgeleitet, wobei der Microsoft DHCP immer noch seine SCCM UEFI-Optionen hat und – falls dieser Server einmal ausfallen sollte – diese bereitstellt, da DNSmasq die UEFI-Anfragen gar nicht wahrnimmt.

Denn die DHCP Option 60 PXEClient ist nur dann von Nöten wenn der WDS/SCCM als eigenständiger DHCP-Proxy agieren soll, was er aber nicht braucht, weil die DHCP-Optionen sowieso vom DHCP-Server ausgeliefert werden.

Microsoft DHCP-Server

Der bestehende Windows DHCP-Server muß umkonfiguriert werden, sodaß ein Client über das Netzwerk auf den FOG-Server zugreifen kann: Option 66 = IP-Adresse des FOG-Servers Option 67 = undionly.kpxe

SCCM-Konfiguration

TODO

Facts

Ein TFTP-Server ist nicht zwangsläufig Vorraussetzung für PXE, denn seit UEFI 2.5 kann anstelle des TFTP-Servers auch http verwendet werden. Somit wäre ein Nachteil egalisiert (UEFI-Boot statt Legacy-Boot).
DHCP-Discover ist ein Broadcast auf UDP-Port 67
Etherboot, ab Sommer 2006 auch „gPXE“
Mit iPXE und manuell eingegebener Netzwerk-Konfiguration ermöglich booten über das Netzwerk, auch ohne DHCP und ohne TFTP
Proprietäre Weiterentwicklung von PXE ist WDS (Windows Deployment Services) von Microsoft
HTTP ist schneller als TFTP
SCCM nutzt auch iPXE
Intel beendet im Jahr 2020 den Support von BIOS Legacy Boot. Das bedeutet langfristig muß eine Lösung her die auch mit UEFI-Boot funktioniert.

Alternativen

iPXE ist eine alternative PXE Methode ohne eigenen DHCP und ohne TFTP-Server:

iPXE mit manuell eingegebener Netzwerk-Konfiguration und booten über das Internet
iPXE ist Open Source Software mit Hauptquelle auf ipxe.org

FOG-Server

Am 5.4.2019 wurde auf einem Linux Ubuntu Client-PC eine eigenständige OS-Deployment Lösung auf Basis der Open Source Software „FOG“ (fogproject.org) installiert. Dieser bietet bereits alle erforderlichen Ressourcen mit um geklonte Betriebssysteme über das Netzwerk auszurollen. Bei Verwendung des FOG-Servers ist es nicht mehr erforderlich, jeden Rechner manuell von einem Bootmedium zu starten. Wenn die Bootsequenz der Rechner so eingestellt ist, dass zunächst von der Netzwerkkarte aus gestartet wird, wird beim Systemstart überprüft, ob ein Klon-Auftrag vorliegt. Ist das der Fall, wird dieser automatisch ausgeführt. Andernfalls startet das lokal installierte System. Dadurch kann eine beliebige Anzahl an Rechnern von einer zentralen Stelle aus mit wenigen Mausklicks geklont werden. Zusätzlich ermöglicht der FOG-Server einige weitere Dienste wie beispielsweise die automatische Installation von Druckern, das Nachverteilen von Software und die automatische Aufnahme in eine bestehende Domänenstruktur. Der FOG-Server kann ein Image per Multicast gleichzeitig an viele Computer verschicken. Das bedeutet, dass das Image nur einmal von den Serverplatten gelesen und nur einmal über die Netzwerkkarte des Servers übertragen werden muss. Die Einrichtung der MulticastFunktionalität ist allerdings schwierig und erfordert vertiefte Netzwerkkenntnisse. Insbesondere muss auf allen verwendeten Switchen IGMP-Verkehr erlaubt werden. Sofern sich der FOG-Server in einem anderen Subnetz befindet als die Clients, muss der verwendete Router die Multicast-Pakete richtig weiterleiten. Dies ist nicht bei allen Geräten möglich. Wenn eine Firewall zwischen den Netzen eingerichtet ist, müssen einige Ports freigegeben werden (TCP: 20-22, 80, 111, 443, 2049, 1024-65535 sowie UDP: 69, 111, 1024-65535).

Software

PXE-Server

anonymous@undisclosed.example.com (Anonymous) — Thu, 16 Jan 2020 09:25:04 +0000

PXE-Server

Schematischer Aufbau eines PXE Boot-Servers:

Netzwerk-Boot von einem zentralen Repository

Windows-Systeme

In Firmen mit Windows-Clients werden Betriebssysteme, Aktualisierungen (Patches) und Konfigurationen fast immer über ein zentrales Repository der IT-Administration ausgerollt, beispielsweise über Microsofts SCCM (System Center Configuration Manager). Allerdings kann Microsoft´s SCCM seit dem 22.3.2018 nicht mehr mit Linux umgehen, da der dazu normalerweise benötigte Linux-Agent von Microsoft in der aktuellen SCCM-Version (seit SCCM-Version 1902) rausgenommen wurde.

Heterogene Netzwerke

In einem heterogenen Netzwerk, dass nicht nur aus Windows-Systemen besteht, muss daher eine Alternative bzw. eine zweite Boot-Server Instanz zum SCCM geschaffen werden. Es bleibt entweder die Möglichkeit eines „Handovers“ indem der SCCM einen externen PXE-Boot-Server antriggert, oder es wird der DHCP komplett umgangen indem die Netzwerkkonfiguration manuell erfolgt und per IPXE gebootet wird.

Damit zukünftig beide Systeme (Windows/Linux) für Rollouts, oder Live-Systeme unterstützt werden können, muß parallel zum Microsoft DHCP-Server mit SCCM UEFI Boot-Server ein separater PXE-Server aufgesetzt werden der Deployments ausserhalb der Windows-Welt möglich macht. Dieser separate PXE Boot-Server kann auf einem beliebigen Windows-, oder Linux-PC installiert werden. Für Windows gibt es z.B. die fertige Lösung „AOMEI PXE Boot Free 1.5“, die allerdings nur immer ein bestimmtes ISO-Image ausliefern kann. Für Linux bietet sich „DNSmasq“ an, da dieser bereits alle notwendigen Komponenten wie DHCP-Proxy und TFTP-Server integriert hat.

Für den Privatbereich gibt es einige Netzwerkspeicher wie beispielsweise die aktuellen NAS-Modelle von Synology die von Haus ein PXE-Boot unterstützen. Ab der Firmware Synology DSM 4.2 ist es möglich direkt vom NAS zu booten.

Alternative ist Microsoft Azure.

Scenarios

Grundsätzlich gibt es zwei verschiedene Netboot-Scenarios:

Keine Installation (Live-System) - Man bootet über das Netzwerk um darüber ein Live-System zu starten, das ohne Installation auskommt und daher auch keine Festplatte benötigt. Da das komplette Live-System ins RAM geladen wird ist die Auswahl an Live-Systemen sehr klein, der Rechner sollte mindestens 4 GB RAM haben, besser 8 GB RAM und das OS sollte möglichst klein sein, damit noch Platz für die Arbeitsdateien im RAM bleibt. In diesem Fall läuft alles ausschliesslich im RAM ab, die Festplatte bleibt komplett unberührt.

Installation übers Netzwerk (Net-Install) - Man bootet über das Netzwerk um darüber ein Betriebssystem zu installieren das auf der lokalen Festplatte eingerichtet wird. In diesem Fall lädt man per Netboot zunächst nur einen Installer, der anschließend die restlichen Daten aus einem zentralen Repository im LAN oder über das Internet holt.

Voraussetzungen

Aktivieren von PXE-Boot im BIOS (Preboot Execution Environment)
Funktioniert nur im LAN
Funktioniert nur mit dynamischer IP via DHCP
Zusätzlicher DHCP-Proxy
Zusätzlicher TFTP-Server
OS-Image als fertiges Netzwerk-Installationsprogramm oder als Live-System ohne Installation
Im BIOS muß Secure Boot deaktiviert werden, da fast alle bootbaren ISO-Images nicht digital signiert sind

Pre-Install

Im BIOS prüfen ob sich der Rechner auf Netzwerk-Boot (PXE-Boot) umschalten lässt. Alternativ über das Boot-Menü (je nach Rechner via F8, F10 oder F12) den Netzwerkadapter als Startgerät auswählen. Falls dieser nicht auswählbar ist, im BIOS nachsehen ob er als Startgerät aktivierbar ist.
Secure Boot muß deaktiviert werden
Fast immer muß auch UEFI-Boot deaktiviert werden, stattdessen Legacy Boot einschalten

Testumgebung

OpenHAB

anonymous@undisclosed.example.com (Anonymous) — Tue, 28 Sep 2021 11:28:46 +0000

OpenHAB

openHAB (Home Automation Bus) ist eine in Java entwickelte Open Source Software, die Komponenten zur Gebäudeautomatisierung („Smart Home“) von den verschiedensten Anbietern hersteller- und protokollneutral in einer Plattform miteinander verbindet. openHAB wurde von Kai Kreuzer 2010 initiiert und hat viele Mitentwickler. Derzeit werden über 200 Produkte beziehungsweise Hersteller unterstützt, beispielsweise AVM, Bose, LG, Minecraft, Hue, Tesla, ZigBee, macOS, somfy, Alexa, Chromecast, Gardenia und viele mehr.

IssueTracker

anonymous@undisclosed.example.com (Anonymous) — Thu, 24 Feb 2022 09:02:24 +0000

IssueTracker

Diese Anleitung ist zur Zeit in Bearbeitung und daher noch nicht vollständig! Wenn Sie zu dieser Anleitung etwas beitragen möchten können Sie sich kostenfrei als Mitglied registrieren und haben dann die Möglichkeit Seiten zu editieren, oder sich Änderungen an Seiten per E-Mail zuschicken zu lassen (abonnieren).

Preamble

Der IssueTracker ist ein Plugin für DokuWiki und ergänzt dieses um ein leicht zu handhabendes, einfaches Ticket-System mit dem Aufgaben erfasst, verwaltet und bearbeitet werden können. Er stützt sich dabei auf die bereits vorhandene Zugriffs- und Rechteverwaltung von DokuWiki, sowie anderer Core-Funktionen. Der IssueTracker selbst liefert eine Eingabemaske zum Erstellen der Tickets, sortier- und editierbare Übersichtslisten und Detailansichten. Der Administrator kann wählen welche Produkte oder Themen er in einem Projekt behandeln möchte. Über die Verwendung von Projekt und Produkt/Thema lassen sich auch unterschiedliche Kundenprojekte getrennt voneinander adressieren und darstellen. Mit der entsprechenden ACL-Konfiguration von Dokuwiki ist es auch möglich kundenspezifische Ticketportale zu schaffen.

Eigenschaften

Durch die Vergabe von voreingestellten Filtern können die Anwender gezielt geleitet werden, aber auch selbst die Filter anpassen. Zum Blättern über der Übersichtsliste und den Filtern auf Stati oder Priorität werden entsprechende Kontrollelemente bereitgestellt. Das gesamte Erscheinungsbild des IssueTracker läßt sich nach eigenen Vorstellungen gestalten. Einige Eigenschaften sind sehr einfach über die Konfiguration umstellbar. Es lassen sich eigene Symbole für Status und Priorität einstellen, für andere optische Finessen braucht es etwas Erfahrung mit CSS.

Trotz seiner überschaubaren Anzahl an Konfigurationsparametern läßt er sich recht flexibel für unterschiedliche Anwendungsfälle einstellen. So können Sie je nach Bedarf Elemente der Eingabemaske ausblenden, die Darstellung der Übersichtsliste für Benutzer reduzieren, DokuWiki Gruppen als Ressourcen verwenden, die Anzahl und Bezeichnung für Stati und Prioritäten festlegen, sowie diese mit eigenen Bildern gestalten und noch vieles mehr. Zur besseren Orientierung der Anwender in der Übersichtsliste besitzen die einzelnen Einträge neben dem Erstellungsdatum einen weiteren Zeitstempel. Dieser gibt Auskunft wann das Ticket letztmalig bearbeitet wurde. Zusammen mit der sortierbaren Übersichtsliste der Tickets lässt sich so sehr schnell ein Überblick über die Aktualität verschaffen.

Tickets suchen und finden

Da die Tickets und Kommentare wegen ihres Objektcharakters nicht als Seiten im DokuWiki Format gespeichert werden können, kann die DokuWiki-interne Suchfunktion leider nicht verwendet werden. Dies trifft auch auf die Funktion „Letzte Änderungen“ zu. Der IssueTracker hat aber eine eigene Suchfunktion mit der alle Tickets nach einem Suchbegriff durchsucht werden können. Eine Änderungsverfolgung ist allerdings nicht implementiert.

Zusätzlich zum Hinzufügen von Kommentaren lassen sich in der Detailansicht eines Tickets viele Elemente je nach Nutzerrolle verändern. Werden beispielsweise Kommentare nachträglich geändert, so erhalten sie einen entsprechenden Hinweis, inklusive einem Zeitstempel. Auch die ursprünglichen Titel und Beschreibungen eines Tickets oder die Links lassen sich nachträglich abändern. Der Arbeitsablauf wird mit einigen Automatismen unterstützt. Wenn Sie beispielsweise einem Ticket eine Ressource zuweisen, dann wird auch der zugehörige Status geändert, oder wenn Sie in der Detailansicht eines Reports einen Lösungseintrag schreiben, dann erhält das Ticket den entsprechenden Lösungs-Status gesetzt. Je nach Anwendungsfall lassen sich die automatisch versandten Status E-Mails variabel einstellen. Damit kann der Administrator entscheiden, ob und welche Art von Änderungen per E-Mail Benachrichtigung versendet werden.

Einsatzgebiet

Das Einsatzgebiet des IssueTrackers reicht vom Ticket-System bis hin zur sehr einfachen Kommunikationsplattform. Der IssueTracker wird durch seinen Entwickler sehr aktiv gewartet und Fehler zügig behoben. Auch funktionalen Erweiterungen steht er sehr aufgeschlossen gegenüber. Darüber hinaus ist das Plugin auch in der DokuWiki Dokumentation beschrieben und wird seitens der Community unterstützt. Der IssueTracker hat nicht den Anspruch kommerzielle, datenbankgestützte Ticket-Systeme für internationale Großprojekte mit hochkomplexen Service-Prozessen (ITIL) zu ersetzen. Sein Einsatz ist an DokuWiki geknüpft und ist gut geeignet um dafür eine Aufgabenverwaltung umzusetzen.

Installation

Wir gehen davon aus das Sie bereits ein fertig laufendes DokuWiki in der aktuellen Version installiert haben. Den IssueTracker können Sie auf zwei verschiedene Weisen in das DokuWiki als Funktionserweiterung installieren. Entweder nutzen Sie den sehr bequemen Weg über die Plugin-Administration, indem Sie dort in das Eingabefeld die URL des IssueTracker-Downloads eingeben, oder per FTP direkt auf den Webserver.

Eingabeseite: neue Tickets eines beliebigen Produkts eines bestimmten Projekts erstellen

Beispiel-Syntax:

~~NOCACHE~~
{{issuetracker>project=projektname|display=form}}

Eingabeseite: neue Tickets eines bestimmten Produkts eines bestimmten Projekts erstellen

Beispiel-Syntax:

~~NOCACHE~~
{{issuetracker>project=projektname|product=produktname|status=all|severity=all|display=form}}

Ausgabeseite: alle Tickets aller Produkte eines bestimmten Projekts als Übersichtsseite anzeigen

Beispiel-Anwendungsgebiet

Alle Produkte eines Herstellers anzeigen. Der Kundenname wird zum Projektnamen.

Beispiel-Syntax

~~NOCACHE~~
{{issuetracker>project=projektname|product=all|status=all|severity=all|display=issues|view=500}}

Ausgabeseite: alle Tickets eines bestimmten Produkts eines bestimmten Projekts als Übersichtsseite anzeigen

Beispiel-Syntax:

~~NOCACHE~~
{{issuetracker>project=projektname|product=produktname|status=all|severity=all|display=issues|view=500}

Ausgabeseite: alle Tickets ausser abgebrochenen und gelösten Tickets anzeigen

In der Statistik erscheinen die ausgeblendeten Tickets trotzdem noch. Beispiel-Syntax:

~~NOCACHE~~
{{issuetracker>project=projektname|status=New,Assigned,External Pending,In Progress,Solved, Canceled,Double |severity=all|display=issues}}

Parameter

Die Parameter „status“, „severity“, „view“, „controls“ und „display“ werden zu folgenden Standardwerten zurückgesetzt wenn sie nicht explizit verwendet werden:

status = ALL
severity = ALL
view = 10
controls = ON
display = ISSUES

Folgende Parameter gibt es

project = Pflichtangabe, der Name darf nur einmalig verwendet werden um zwischen den einzelnen Projekten unterscheiden zu können
product = optionale Angabe, um die Eingabeseite oder Ausgabeseite auf ein bestimmtes Produkt zu begrenzen
status = optionale Angabe, definiert die Ausgabeseite auf Tickets mit einem bestimmten Status (Werte mit Komma getrennt)
severity = optionale Angabe, definiert die Ausgabeseite auf Tickets mit einem bestimmten Schweregrad (Werte mit Komma getrennt)
display = Pflichtangabe, definiert ob es sich um eine Eingabeseite oder Ausgabeseite handelt
view = optionale Angabe, definiert die Anzahl der Tickets die auf der Ausgabeseite gesamt angezeigt werden sollen
controls = optionale Angabe, prevents output of controls above and edit of the issue list (on or off)

Warum der NOCACHE Befehl?

Der NOCACHE Befehl sollte stets direkt vor der Syntax des IssueTrackers verwendet werden um zu verhindern das der Webbrowser die Daten zwischenspeichert und wohlmöglich veraltete Daten anzeigt.

Searx Fehler

anonymous@undisclosed.example.com (Anonymous) — Tue, 28 Sep 2021 21:43:35 +0000

Searx Fehler

Leider muß man sagen sind viele SearX Installationsanleitungen fehlerhaft, weil fast immer benötigte Abhängigkeiten im Betriebssystem oder verwendeten Komponenten, Modulen u.a. fehlen die in den Anleitungen referenziert werden, beispielsweise GIT, VIRTUALENV oder PIP. So kommt es regelmäßig dazu das trotz peinlichst genauen abarbeiten der einzelnen Installationsschritte es zu Fehlern kommt, auch wenn das Betriebssystem gerade erst frisch aufgesetzt wurde. Aus diesem Grund werden auf dieser Seite typische Fehler bei oder nach der Installation aufgelistet und mögliche Lösungen vorgeschlagen.

Klassische Fehler bei der Installation sind fehlenden Berechtigungen oder Abhängigkeiten. Vieles lässt sich dadurch lösen indem man sich angewöhnt vor dem Kommando ein sudo davorzusetzen. Bei vielen Installationsanleitungen fehlt dies und daher kommt es zu Fehlern.

2.ter Start schlägt fehl

Beim zweiten Start von Searx kommt ein Syntax-Fehler bei Zeile 31 weil für den Betrieb benötigte Module fehlen.

Lösung

Die benötigten Module können folgendermassen nachinstalliert werden:

sudo apt-get install python-pip pip install –upgrade -r requirements.txt

Fehlermeldung beim aktualisieren

./manage.sh: 19: ./manage.sh: pip: not found

Lösung

Auch hier ist der Grund das zum Aktualisieren Software benötigt wird die nicht Teil der Installation ist, also erst nachinstalliert werden muß. In diesem Fall ist es PIP. Dies fehlt quasi in allen gefundenen Installationsanleitungen. Zumindest in Ubuntu 18.04 muss PIP erst manuell nachinstalliert werden:

sudo apt-get install pip

Fehlermeldung beim starten

Traceback (most recent call last): File „searx/webapp.py“, line 31, in <module> import requests ImportError: No module named requests

Lösung:

Auch hier ist wieder der Grund das Module fehlen die für den Betrieb notwendig sind:

sudo apt-get install pip pip install requests pip install pyyaml pip install pygments

Das kann hier noch beliebig so weitergehen bis es zu keinen Fehlern mehr kommt. Installieren sie nach dieser Art alle fehlenden Module nach bis sich SearX fehlerfrei starten lässt. Bei SearX in der Version 0.16.0. sind dies

certifi==2019.3.9
babel==2.7.0
flask-babel==1.0.0
flask==1.0.2
idna==2.8
jinja2==2.10.1
lxml==4.3.3
pygments==2.1.3
pyopenssl==19.0.0
python-dateutil==2.8.0
pyyaml==5.1
requests[socks]==2.22.0