Neues System zur Dokumentation getaner Arbeit gesucht


#1

Hi.
Bisher besteht mein Logbuch, in das ich alle Arbeitsschritte eintrage, die ich erledigt habe, aus einfachen TXT Dateien, die mit auf dem Proxmox-Server liegen. Das “System” ist natürlich schnell aber bietet sonst keine Struktur o.ä. Daher wollte ich mal in die Runde fragen, was ihr dazu sinnvollerweise einsetzt?
Evtl ein Wiki? Es muss auch zukünftig schnell gehen und von überall aus funktionieren, sollte aber eine saubere Trennung bieten, welchen Host man wann und wie konfiguriert hat. Sicher gibt es da X Lösungen…

Schönen Gruß,
Michael


#2

Hallo Michael,

wenn ich mich richtig erinnere, bist Du doch schon Check-MK Nutzer. Dort gibt es auch ein DokuWiki. Praktisch ist, dass jeder Host- und Service-Check mit einem Link ins Wiki versehen werden kann. Im Zusammenspiel mit dem auch integrierten NagVis ist so alles an einer Stelle zu finden. Check, Visualisierung und Doku.

Die Regeln, um die Links (Custom Notes) pro Check zu aktivieren, lauten:

  • Notes URL for Hosts --> /site//wiki/doku.php?id=$HOSTNAME$:$HOSTNAME$
  • Notes URL for Services --> /site/wiki/doku.php?id=$HOSTNAME$:$SERVICEDESC$

grafik

Grüße


#3

Hallo.

Oh, sehr guter Tipp. Das schaue ich mir an. :+1:
Hatte zwischenzeitlich die Seite
http://www.mkdocs.org/
entdeckt, die (alternativ) auch ganz gut aussieht. Aber am besten nicht noch ein System aufmachen.

Ein Problem bei Check_MK bei uns ist, dass wir das System auf einfachen RaspberryPis betreiben und es dort schon öfter zu Aussetzern der SD-Karten gekommen ist. Wenn man das ganze stabiler haben will, muss man vielleicht doch auf einen “richtigen” Host oder eine VM umziehen?? :thinking:

Michael


#4

Hey!

Nicht ganz das, was du meinst, aber vielleicht hilfreich in diesem Zusammenhang: etckeeper (siehe z.B. https://www.thomas-krenn.com/de/wiki/Etc-Verzeichnis_mit_etckeeper_versionieren)

Etckeeper packt deinen kompletten etc-order in ein git-repo. Du hast somit eine Doku und einen Vorher-Nachher-Vergleich.

Gruß
Frithjof


#5

Hallo, liebe Mitstreiter,

auch ich bin auf der Suche nach einem Doku-System für Todo-Listen und Howtos, die sich im Lauf der Zeit angesammelt haben und die wir im Netzwerkteam jetzt “kooperativ” machen wollen. Meine erste Idee ist, im Schulportfolio einen Abschnitt “Netzwerk” einzufügen und dessen Zugriffsrechte auf die Netzwerk-Administratoren zu beschränken - sofern möglich.

Interessiert bin ich auch - wie Michael - an anderen Vorschlägen und Erfahrungen.

Viele Grüße

Bernd

OHG Nagold


#6

Hallo morpweb!

Wo müssen die Einträge gesetzt werden? Ich finde keine Möglichkeit. Auf Kettners-Seite finde ich nur etwas, das als nicht mehr gepflegt wird markiert ist.
Dieser Artikel wird nicht mehr gepflegt und ist unter Umständen nicht mehr gültig!

Bitte erleuchte mich. Danke!

Beste Grüße

Thorsten


#7

Hallo,

Genau so mach ich das, das geht natürlich

http://www.openschulportfolio.de/praxistipps/accesscontrol

Dokuwiki ist hervorragend geignet, das Netz zu dokumentieren. Ich verwende folgende Prinzipien:

  • Verschlagwortung: Jedes Gerät (Switch, NAS, Server…) bekommt ein z.B. als Schlagwort den Verteilerschrank, in dem es wohnt. So bekomme ich als Logik für jeden Verteilerchrank eine Liste mit allen Dokus.
  • Tagebuch: Ich verwende das Blog Plugin als Arbeitstagebuch. Dort CnP ich oft einfach Befehle, Links und Configs rein, die mir geholfen haben ein Problem zu lösen.
  • Alle Passwörter und Zugangsdaten sind dort hinterlegt, dafür verwende ich das Plugin https://www.dokuwiki.org/plugin:encryptedpasswords

Ich würde davon abraten, das bei OMD mitgelieferte DW zu verwenden, einfach weil: “One Task, one Tool”. Die Integration macht eine Abhägikeit die ich nicht brauche.

VG

Frank

Edit: Bildchen zur Inspiration…

Auswahl_098

Auswahl_103


#8

Hi Frank (@ironiemix)
Die Lösung via Openschulportfolio ist natürlich auch schick! Wir haben bereits ein (altes) DokuWiki. Es müsste ja problemlos möglich sein, alle Files von dort in ein OSP umziehen zu lassen. Das sind meines Wissens alles einfache Text-Dateien mit etwas Markup, oder?

Und wenn ich mich für OSP entscheide: Wäre das jetzt der Zeitpunkt, das per docker laufen zu lassen – so wie du es uns in den Videos neulich beigebracht hattest? Oder lieber klassisch?

Woher hast du die Icons/Menuleiste im ersten Bild? Wie es aussieht, ist das nicht per default dabei, oder?

Schönen Gruß,
Michael


#9

Hallo Thorsten,

Grundsätzlich ist das Wiki zu finden unter:

https://x.x.x.x/“sitename”/wiki/

Sollen “Custom Notes” von Hosts oder Services" direkt ins Wiki verlinkt werden, können diese über folgende Regeln aktiviert werden.

Wato --> Host und Service Parameter --> Notes URL for Hosts
Wato --> Host und Service Parameter --> Notes URL for Services

Das Wiki kann aus Check_mk heraus bequem über ein Snapin aufgerufen werden.

grafik

Hoffe, dies ist so ausreichend, falls nicht, kann ich gerne einen Screencast zu diesem Thema erstellen.

Viele Grüße
Bertram


#10

Hi.
Ich habe mir jezt mal unser laufendes DokuWiki vorgenommen und das etwas hübscher gemacht. Das default-Layout sieht mir etwas zu altbacken aus. Aber zum Glück gibt’s ja Templates, wie z.B. das bootstrap3, das mir ganz gut gefiel. Ich habe unsere Logbücher schon an das neue Layout angepasst. Macht sich ganz gut …
Trotzdem immer wieder sinnvoll, auch solche Dinge hier zu diskutieren, meine ich.
Michael


#11

Ein Beitrag wurde in ein neues Thema verschoben: Zugriffsrechte DokuWiki/OpenSchulportfolio


#12

Hallo Michael, hallo Liste,

wir haben bei uns seit Anbeginn der Zeit “Redmine” als Ticketsystem laufen.

Ist per LDAP an den Schulserver angebunden.

Über Tickets handhaben wir die alltägliche Arbeit (Kollegen können z.B.
Fehler an PCs eintragen, Schulassistent und ich werden dann
benachrichtigt und der, der es macht, übernimmt das Ticket). Intern
versioniere ich darüber unsere Images (Unterprojekt, da schiebe ich dann
z.B. auch Feature-Requests von Kollegen hin). Auch die Pflege von Moodle
(Wünsche von Kollegen, diesen oder jenen Kurs zu löschen) handhabe ich
über ein eigenes Projekt.

Eher nebenbei gebe ich auch die Zeiten an, die ich benötige - ganz
hilfreich bei Diskussoinen über Entlastungsstunden (“Was genau machen
sie eigentlich immer?”).

Für jedes Projekt kann man sehr flexibel “Mitarbeiter” einrichten, die
dann entsprechen Schreibrechte haben oder per Email benachrichtigt
werden - auch, wenn Tickets (Smartboard defekt) geschlossen werden.

Die langfristige Dokumentation habe ich in einem Wiki gesammelt - da hat
sich über die Jahre ziemlich was angesammelt, was inzwischen so oft
überarbeitet wurde, dass an es gut im Alltag verwenden (und ergänzen) kann.

Viele Grüße,

Thomas


#13

Hi. Redmine hatte ich irgendwann mal ausprobiert (5.1er Zeiten??). Da das daaaamals noch direkt mit auf dem Server war, gab es da imho ein Problem mit Ruby bzw der benötigten Software. Wie/Wo lässt du es laufen? Extra VM, docker-Container oder direkt auf Blech??
(Übrigens läuft das DokuWiki jetzt ganz gut. Ich glaube nicht, dass ich so schnell wechseln werde… Aber rein aus Interesse gefragt…)
Michael


#14

Hallo zusammen,

da ich auch auf der Suche nach einem neuen Dokumentationssystem für unser Netzwerk bin, klinke ich mich hier mal ein.

An der alten Schule hatte ich ein Dokuwiki betrieben. Das war ok, da ich es (fast) alleine betrieben habe. Nachteile, die ich dabei sehe:

  1. Dienstleister (verschiedene) sollen da auch dokumentieren, was sie wie gemacht und konfiguriert haben. Ich befürchte, denen ist die Hürde, eine (neue) Wikisysntax lernen zu müsssen, zu hoch.
  2. Beim Crash des Servers, auf dem das Wiki läuft, kann nicht mehr darauf zugegriffen werden. Und genau dort liegen dann die Informationen, die man in diesem Fall bräuchte.

Ich überlege nun, die Dokumentation einfach in die (interne) Cloud zu legen (Nextcloud, Seafile o.ä.). O.g. Nachteile sehe ich dabei gelöst:

  • man schiebt einfach irgendwelche Dateien hoch und muss keine Wikisyntax lernen/verwenden.
  • durch den automatischen Sync mit lokalen Clients sind die Dateien auch nach einem Servercrash verfügbar.

Außerdem können Dateitypen unterschiedlichster Art einfach verwendet werden, ohne, dass man sich darum kümmern muss, wie man das jetzt am besten in eine Wikiseite einbettet.

Was haltet Ihr davon? (Wo) seht Ihr Nachteile?

Danke und viele Grüße,
Jochen


#15

Hi Jochen.
Also ich finde ein DokuWiki auch für externe Dienstleister geradezu ideal: Sie können ihre Arbeitsschritte per copy / paste dort einfügen und ein paar Sternchen und Einrückungen für die mehr-als-billig-Syntax kriegt wohl jeder hin, oder?? Durch die Einschränkungen der Berechtigungen kann man dem Dienstleister einen eigenen Bereich zur Verfügung stellen…

Aber die Alternative, die ich oben schon genannt hatte:
https://www.mkdocs.org läuft mit Markdown und unterscheidet sich nur leicht von der Syntax im
DokuWiki. Dafür gibt es allerdings einen schicken Online-Editor, der
live übersetzt (da sieht man auch gleich, wie einfach die Syntax gestrickt ist):
https://stackedit.io

Andererseits: Die Idee, das ganze per Cloud zu regeln ist auch nicht soooo schlecht. Dann hast du aber evtl das Problem, dass sich viele Dateien ohne Struktur anhäufen?! Ich finde im DokuWiki gerade gut, dass alles global durchsuchbar ist und man dann auch alle Treffer findet. Da das Wiki bei uns nicht auf dem linuxuster-Server läuft, haben wir den von dir genannten Nachteil bei uns nicht.
Bis später,
Michael