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…
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$
Oh, sehr guter Tipp. Das schaue ich mir an.
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??
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.
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.
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.
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?
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
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.
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
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:
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.
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.
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
Was @thoschi über Redmine geschrieben hatte, fand ich recht interessant (bislang liefen Tickets und Dokumentation bei uns getrennt). Ich habe mir daher kürzlich das ISO von Redmine geholt und auf einer eigenen VM (unter proxmox) installiert. Derzeit läuft es im Testbetrieb, sieht aber ganz gut aus.