staging.inyokaproject.org

Benno-007 schrieb:

Macht dir Spaß, einem so eine Liste vorzuklatschen, oder?

Nein, ganz sicher nicht. Denn das Zusammenstellen einer solchen Checkliste ist sehr aufwendig, denn sie soll ja eine konkrete Hilfestellung sein und erfordert daher eine intensive Beschäftigung mit der jeweiligen Baustelle und ihrem Inhalt. Aber wenn Du keine Hilfe benoetigst bzw. diese nicht als solche erkennen und annehmen kannst... kein Problem, ich werde sie zukuenftig nicht mehr anbieten.

Ok, dann werd ich das mal so glauben und die 🐸 schlucken.

Grüße, Benno

Hallo,

aasche hat geschrieben, dass er den Artikel nicht für verschiebbar hält und dann, im Nachgang, noch einen viel detaillierte Liste als üblich dazu gepostet. Die kannst du, Benno-007, jetzt bei Interesse Punkt für Punkt erledigen, um dem Wiki den finalen Schliff für's Wiki zu geben.

Wobei ich bevorzugen würden, wenn zuerst die inhaltlichen Punkte geklärt würden. Syntax korrigieren geht schnell, dass können du und wir am Ende machen.

Wenn du den Artikel nicht nochmal korrigieren möchtest bitte hier kurz posten, dann markiert das Wikiteam den Artikel als "verlassen" und hofft darauf, dass ihn in den nächsten Monaten jemand fit für's Wiki macht.

Gruß, noisefloor

Danke für das Angebot - klingt einigermaßen lukrativ. Ich komme darauf zurück, sobald die Grundsatzdiskussion abgeschlossen ist.

Grüße, Benno

PS: Wie darf ich den Linkfix zur Grundsatzdiskussion von march verstehen: Ist es nun verboten, Forenlinks auszuschreiben und ich werde gezwungen, mir neue Syntax wie post: anzugewöhnen oder war das eine Kann-man-machen-Entscheidung und ich kann das weiterhin machen, wie ich das möchte, gemessen an meinen begrenzten Fähigkeitsressourcen für Syntax?

Hallo,

gewünschter Standardsyntax zu Links ins Forum sind [post:123456:hier steht der Text] oder [topic:foo-bar-spam-egg:hier steht der Text].

Wobei sich "falsche" Links ja schnell korrigieren lassen, da das Topic oder die Post-ID ja im "falschen" Link drin stehen.

Gruß, noisefloor

Was spricht gegen meine Gewohnheit

[http://forum.ubuntuusers.de/topic/baustelle-pam-time pam-time]

? Ich möchte gern die Freiheit behalten, das weiter so zu machen, wie ich es bestimmt schon mindestens 1000 Mal gemacht habe und wo sich auch nie jemand beschwert hat.

Grüße, Benno

PS: Falls das offtopic wird, bitte ins Grundsatzthema verschieben oder wohin ihr meint, dass es abgetrennt werden müsste.

Was spricht gegen meine Gewohnheit... wo sich auch nie jemand beschwert hat.

Sollte sich im Hintergrund von Inyoka etwas an der Struktur ändern haben diese InterWiki-Links den entscheidenden Vorteil, dass sie schnell und einfach angepaßt werden können. Eine Änderung an dieser einen Stelle wirkt sich auf das komplette Portal aus und somit müssen die anzen Wikiartikel nicht einzeln durchgegangen und verändert werden. Abgesehen davon findet man diese Links dann eh kaum noch... Ebenso bleiben Posts in Threads und Links im Ikhaya aktuell. Was die Gewohnheit anbelangt: eventuell wurde es in Wikiartikeln übersehen. Threads kontrollieren wir nicht. 😉 Im Wiki bitte IWL nutzen - sofern vorhanden.

Hallo,

weiter geht's.

aasche schrieb:

• keine Doppelpunkte in Ueberschriften

Erledigt.

• keine gelben Markierungen (in Befehlen)

Gerne. Wäre es in Grün lieber? Oder wie hättet ihr es denn gern, wenn man was im Befehl hervorheben muss? Ich hab's: Mit sowas wie XXX und YYY? Hab es besser erledigt!

Übrigens: Machen andre Artikel auch und steht gar nicht in euren obigen beiden Regellinks. Sind die Regeln etwa ungeschrieben? Ist dieses Versäumnis schwerwiegender als das Versäumnis, nichtgeschriebene Regeln nicht zu beachten?

• Nummerierung in Ueberschriften vermeiden

Erledigt.

• Das enthaltene Bild sollte verkleinert dargestellt werden, um mehr Platz fuer den eigentlichen Text zu lassen. Faustregel, damit es auch auch auf Smartphones ohne Scrollen anzeigen laesst: max. 300 Pixel.

Erledigt. Und Rahmen ergänzt.

• bitte die Sprache externer Links mit Flaggen kennzeichnen

Hast du zwischenzeitlich erledigt. ☺

• Wissensblockverweise idealerweise in aufsteigender Reihenfolge

Wenn du die Tabellen meinst: Hab die Operatoren nun nach vorn verlegt, weil es das erste Zeichen sein kann - auch wenn es didaktisch nicht so gut ist, gleich damit zu "nerven".

• nano ist ein moeglicher Editor. Bei einem Verweis auf den Wissensblock kann jede/r ihren/seinen Lieblingseditor einsetzen. Und wenn ein Editor erwaehnt wird, braucht es IMHO keine Befehlszeilen mit sudo sh -c "echo ...", sondern ein einfacher Codeblock reicht aus.

Der Artikel richtet sich an Erziehungsberechtigte, für die nach deinen Aussagen in der Diskussion zu Kinder sogar Unity zu kompliziert sei. Nun maße ich mir schon an, denen Befehlszeilen zum Kopieren zu geben. Und nun sollen sie sich auch noch für einen Editor entscheiden? Und in Systemdateien fummeln? Besser nicht, finde ich. Es sei denn, das Artikelbeispiel soll gar nie zur Anwendung kommen - da wird es nämlich enden.

Aber wir können ja auch gern den Artikel chroot bisschen entrümpeln. Paar Links zu mount und fstab sollten doch reichen - und dazu vielleicht noch der Lieblingseditor - ach nein, besser gleich 10. Nicht dass noch jemand auf die Idee kommt, er käme mit dem Artikel ernsthaft ans Ziel, ohne gefälligst die Grundlagen von mindestens 10 Editoren ausprobiert zu haben. 😉

• Kommentare zum Einfuegen in andere Artikel bitte auskommentieren und an den Anfang des Artikels verschieben. Dann wissen die Kollegen, die den Artikel aus der Baustelle holen Bescheid, wohin und mit welchem Text er verlinkt werden soll.

Sehr aufmerksam, sehr gut. Verschiebe ich nun nach oben.

Inhaltlich:

• Gelten die Aenderungen sofort oder ist ein Neustart des Rechners erforderlich?

Meines Wissens nach sofort und überflüssige Sätze wie "Kein Neustart erforderlich." habe ich daher weggelassen.

• eindeutigere Gliederung (Spruenge zwischen "time.conf" und "Services aktivieren" vermeiden)

Dazu müsste ich mehr Ahnung von der Materie haben - dadurch kam es dann wachsend zu dem Rumgeeier. Aber ich bin mir sicher, ich arbeite hier mit Vollprofis zusammen, die mir sicherlich inhaltlich bessere Vorschläge unterbreiten können, damit der Genuss des Artikels stetig erhöht werden kann, bevor er vielleicht Ostern 2015 mal zur Ausstrahlung kommt. 😉

• was hat die crontab mit der crypttab zu tun?

Gute Frage - wahrscheinlich ein Nervenzusammenbruch aufgrund der befürchteten Kritik, die noch umfangreicher als in den kühnsten Träumen wurde. 😉 Ausgebessert.

• Warum wird root als Beispiel genutzt, um einen Benutzer auszusperren? Service und Wartung jetzt nur noch zwischen 8 und 10 Uhr vormittags an allen Tagen ausser Mo, Mi und allen ungeraden Wochenenden?

Weil dazu steht: "Der Admin root sollte sich damit aber nicht wirklich selbst aussperren, außer er leidet an akutem Schlafmangel durch nächtliche Überarbeitung.". Und wer sich zwischen 3 und 4 Uhr nachts aussperrt, ist entweder privater Stümper, der da sowieso schläft oder ein Admin, der nachts gepennt hat. Ich nenne root nun einfach in tom um.

• Insgesamt sehr viel umschreibender Text. Evtl. ginge es auch ein wenig zielfuehrender bzw. praegnanter?

Am Anfang sicherlich, aber dazu fehlt mir das Wissen, wie das alles genau zusammenhängt. Das sind Erfahrungen durch Versuch und Irrtum + etwas Doku. Und jetzt weiß ich es sowieso nicht mehr, wie es war, nachdem mir gehörig die Lust vergangen war. Auch wenn sich die Kritik mit etwas Abstand etwas substanzieller anhört als im ersten Moment.

Dennoch musste ich hier und da schon mal zurückkritisieren, weil es mir meine Emotionen so geboten haben. 😉 Gerade das mit dem Gelb ging mir doch nochmal gegen den Strich, weil ihr selbst nicht so unfehlbar seid. 😇

Na dann mal sehn, wie es weitergeht. Ich rechne mit Anforderungen, keine Sorge.

Insgesamt tut es mir etwas leid, wie es gelaufen ist, aber inhaltlich irgendwie auch nicht - der nächste Moment, wo es mir wieder nicht mehr leid tut, kommt bestimmt irgendwann irgendwo, darum bereue ich auch nichts, was ich zu dem Zeitpunkt sagte. 😉

Wer streng durchregiert und nicht mal die eignen Regeln niederschreibt oder sich an sie hält (chroot, Shell/Bash-Skripting-Guide für Anfänger - vergleiche Unzufriedenheit mit dem Wiki-Team) sowie Artikel mit falschem Vorbild im Wiki lässt, muss sich dann nicht wundern, wenn die Strenge nicht gewürdigt wird - nach Tagen unermüdlichem Einsatzes, zerrissen und mit Aufgaben zerfleddert. Und da ich dafür von niemandem bezahlt werde, kritisiere ich das auch, begrüße aber den Schritt zu Howto allgemein.

Für ein Howto hätte ich mir aber die ganzen Tabellen sparen können - alles nur für euch. 😉

Grüße, Benno

Fühlt sich jemand vom Wikiteam für den Artikel zuständig? Ein kurzes "erst nach Weihnachten" oder so würde mir schon reichen, aber mit einem "bin nicht zuständig" auf Nachfrage in paar Wochen bin ich nicht einverstanden, drum hät ich gern einen Ansprechpartner, welcher jetzt dieser Tage noch das weitere Vorgehen mit mir terminiert. 😇

Grüße, Benno

Hallo,

ja, alle.

Aber was ist denn jetzt genau die Frage / das Anliegen? Hast du den Artikel gem. der o.g. Punkt überarbeitet? Willst du noch? ...?

Gruß, noisefloor

Hab ich - steht doch mehrmals zu den Punkten "Erledigt" im Text. Wozu geh ich überhaupt auf die Punkte ein, wenn's eh keiner liest?

Grüße, Benno

Moin moin,

das ist keine leichte Kost und ein großer Happen dazu, verzeihe bitte, wenn nicht jeder Wikimod binnen 24h ein vollständiges Review hinlegen mag. Zumal Du das nicht als Hilfestellung bzw. Teil eines normalen Ablauf zu sehen scheinst. Wer hat schon Lust sich mühsam einzuarbeiten um sich dann Schikane vorwerfen zu lassen?

Benno-007 schrieb:

• Wissensblockverweise idealerweise in aufsteigender Reihenfolge

Wenn du die Tabellen meinst: Hab die Operatoren nun nach vorn verlegt, weil es das erste Zeichen sein kann - auch wenn es didaktisch nicht so gut ist, gleich damit zu "nerven".

Tabellen waren hier nicht gemeint. Man setzt im Text an passenden Stellen mittels [1], [2], [3], ... Verweise auf den Wissensblock am Anfang des Artikels. Die Nummerierung folgt idealer- bzw. üblicherweise der Reihenfolge, in der die Verweise im Text vorkommen.

Damit kann man bestimmten Benutzern die Anmeldung für bestimmte Dienste und Programme an bestimmten zu bestimmten Tagen an bestimmten Uhrzeiten den Zugriff zeitlich erlauben oder verbieten.

Da passen zwei Sachen nicht, so dass ich auch nicht ganz sicher bin, ob ich die Intention richtig verstehe:

Damit kann man bestimmten Benutzern die Anmeldung für bestimmte Dienste und Programme an bestimmten Tagen zu bestimmten Uhrzeiten erlauben oder verbieten.

So?

Rechtschreibung (bin ich zwar selbst kein Held, aber Tippfehler finde ich wohl noch 😉 ) und Grammatik kann ich noch mal drüber gehen, wenn es ansonsten fertig ist. Und da warten wir immer einige Tage, damit auch die ihren Senf abgeben können, die nicht 24/7 online sind.

Gruß, cornix

Hallo,

habe den Artikel jetzt 3x an verschiedenen Tagen gelesen und muss leider sagen: ich finde ihn in weiten Teilen unverständlich. Da ich mich mit der beschriebenen Thematik noch nie vorher beschäftigt habe kann ich den Artikel also in der Tat mit Noob-Augen lesen.

So steht z.B. im Abschnitt "Bedienung" der Satz:

Eine Konfiguration besteht aus mindestens einem zu konfigurierten Element in einer Zeile. Jede Zeile besteht aus vier Elementen, die zwingend ausgefüllt werden müssen. Es dürfen dabei jedoch Platzhalter verwendet werden.

Das ist IMHO ein Widerspruch im 1. und 2. Satz. "mindestens" vs. zwingend". Oder soll da (eigentlich) gesagt werden: "Pro Konfiguration wird einen Zeile benötigt, wobei jede Zeile aus vier Elementen besteht, von denen mindestens ein angegeben sein muss. Die anderen können (müssen aber nicht) durch Platzhalter ersetzt werden."

Im Abschnitt "Aktivierung für Services" ist mir z.B. nicht klar, _was_ man jetzt wirklich wo eintragen muss. Und auch nicht, wie und wann man ein @include... benutzen soll / muss.

Auch die Bespiele haben da nicht zur Erhellung geholfen. Und besonders das 3. Beispiel login ; * ; !root ; WdMo0300-0400 ist IMHO verwirrend. Im zugehörigen Text wird von Nutzer "Tom" gesprochen - der taucht aber im Beispiel gar nicht auf?

Und vielleicht wäre es auch besser / einfacher - auch für die Wartbarkeit, das komplexe Beispiel in ein Howto auszulagern.

Rein sprachlich könnte man das sicherlich auch noch an der einen oder anderen Stelle vereinfachen, zwecks Verbesserung der Verständlichkeit. Doppelte Verneinungen helfen da z.B. in der Regel nicht.

Gruß, noisefloor

Hallo. ☺

cornix schrieb:

Moin moin,

das ist keine leichte Kost und ein großer Happen dazu, verzeihe bitte, wenn nicht jeder Wikimod binnen 24h ein vollständiges Review hinlegen mag.

Das hab ich auch nicht verlangt - mir kam es nur so vor, als wurden meine Diskussionskommentare nicht gelesen und darauf folgte dann meine Reaktion, warum ich es dann überhaupt niederschreibe. Quasi der Red-ich-mit-einer-Wand-Reflex, wenn etwas kommentiert wird, was gar nicht gelesen wurde - sonst wären dem ersten Eindruck nach die Fragen nicht aufgekommen, da mehrmals "erledigt" im Text stand. Aber das ist ja kein Drama, also weiter. 😉

Benno-007 schrieb:

• Wissensblockverweise idealerweise in aufsteigender Reihenfolge

Wenn du die Tabellen meinst: Hab die Operatoren nun nach vorn verlegt, weil es das erste Zeichen sein kann - auch wenn es didaktisch nicht so gut ist, gleich damit zu "nerven".

Tabellen waren hier nicht gemeint. Man setzt im Text an passenden Stellen mittels [1], [2], [3], ... Verweise auf den Wissensblock am Anfang des Artikels. Die Nummerierung folgt idealer- bzw. üblicherweise der Reihenfolge, in der die Verweise im Text vorkommen.

TO DO: Werd ich noch ändern, sobald die inhaltlichen Punkte geklärt sind.

Damit kann man bestimmten Benutzern die Anmeldung für bestimmte Dienste und Programme an bestimmten zu bestimmten Tagen an bestimmten Uhrzeiten den Zugriff zeitlich erlauben oder verbieten.

Da passen zwei Sachen nicht, so dass ich auch nicht ganz sicher bin, ob ich die Intention richtig verstehe:

Damit kann man bestimmten Benutzern die Anmeldung für bestimmte Dienste und Programme an bestimmten Tagen zu bestimmten Uhrzeiten erlauben oder verbieten.

So?

Ja, "den Zugriff" muss ein Überbleibsel einer sprachlichen (und menschlichen, im doppelten Sinne.....) Überarbeitung sein, ansonsten hast du nur an/ zu vertauscht in deinem Satz. Setze ich gleich vorm Absenden um.

Rechtschreibung (bin ich zwar selbst kein Held, aber Tippfehler finde ich wohl noch 😉 ) und Grammatik kann ich noch mal drüber gehen, wenn es ansonsten fertig ist. Und da warten wir immer einige Tage, damit auch die ihren Senf abgeben können, die nicht 24/7 online sind.

Da kann ich nochmal Vorarbeit leisten, sobald inhaltliches geklärt ist. Der Feinschliff macht ja keinen Sinn, wenn das noch 100 Mal umgeworfen oder gar der ganze Artikel verworfen würde. 😉

Gruß, cornix

Grüße, Benno

noisefloor schrieb:

Hallo,

habe den Artikel jetzt 3x an verschiedenen Tagen gelesen und muss leider sagen: ich finde ihn in weiten Teilen unverständlich.

Ich weiß, dass man manches anders formulieren sollte - da fehlte mir aber zuerst der technische Durchblick nach einigen Tests und dann die Zeit. Das Zeitproblem geh ich nur an - den begrenzten Durchblick (nicht zuletzt auch dank zerstückelter Doku) bekomm ich aber nicht weg - kann aber Spekulationen (Erklärversuche) eindämmen und einfach rekonstruieren, was ich gemacht habe.

Allerdings sind diese Erklärungen dann vielleicht doch nötig, um auf anderen Ubuntu-Derivaten (oder neuen Versionen) mit Abweichungen auf die Erklärungen zurückgreifen zu können, um z.B. das Vorhandensein mancher Zeilen zu beachten.

Da ich mich mit der beschriebenen Thematik noch nie vorher beschäftigt habe kann ich den Artikel also in der Tat mit Noob-Augen lesen.

So steht z.B. im Abschnitt "Bedienung" der Satz:

Eine Konfiguration besteht aus mindestens einem zu konfigurierten Element in einer Zeile. Jede Zeile besteht aus vier Elementen, die zwingend ausgefüllt werden müssen. Es dürfen dabei jedoch Platzhalter verwendet werden.

Das ist IMHO ein Widerspruch im 1. und 2. Satz. "mindestens" vs. zwingend". Oder soll da (eigentlich) gesagt werden: "Pro Konfiguration wird einen Zeile benötigt, wobei jede Zeile aus vier Elementen besteht, von denen mindestens ein angegeben sein muss. Die anderen können (müssen aber nicht) durch Platzhalter ersetzt werden."

Ja. Ich schau dann gleich im Entwurf nochmal, ob ich das so oder ähnlich ändern würde.

Im Abschnitt "Aktivierung für Services" ist mir z.B. nicht klar, _was_ man jetzt wirklich wo eintragen muss. Und auch nicht, wie und wann man ein @include... benutzen soll / muss.

Das ist auch nicht ganz so einfach, siehe oben. Darum schob ich den folgenden Absatz nach, der vielleicht dazu beitrug, dass aasche den Artikel etwas lang fand:

"Es müssen also für das Laden aller für pam_time notwendigen Module beide Zeilen in einer Datei eines Services enthalten sein, wobei der Eintrag @include common-auth in zum Beispiel login bereits die in common-auth selbst nachgetragene Zeile account required pam_time.so enthalten kann, so dass letztere in der login nicht nochmal eingetragen werden braucht. Doppelungen in einer Datei durch bereits vorhandene Einträge sind zu vermeiden."

Auch die Bespiele haben da nicht zur Erhellung geholfen. Und besonders das 3. Beispiel login ; * ; !root ; WdMo0300-0400 ist IMHO verwirrend. Im zugehörigen Text wird von Nutzer "Tom" gesprochen - der taucht aber im Beispiel gar nicht auf?

Da hab ich den kritisierten root entfernt und es vorn vergessen, hol ich gleich nach.

Und vielleicht wäre es auch besser / einfacher - auch für die Wartbarkeit, das komplexe Beispiel in ein Howto auszulagern.

Wenn ihr eine Regel einführt, dass man im Wiki auf einzelne Howtos oder zumindest den Howto-Bereich als ganzes hinweisen/ verlinken darf, könnte man das eventuell überlegen. Grundsätzlich war aber mein Ziel, dem Artikel Kinder mit einer simplen, schnellen Lösung auf die Sprünge zu helfen. Aufgrund der Wikiregeln, dass man alles mit 1000 Dingsbums-Tabellen etc. garnieren soll, wurde es dann nicht nur sehr viel, sondern auch sehr komplex - so dass es nun sogar euch zu viel und komplex ist.

Es wäre halt schön, wenn man die Lösung in Kinder auch anbieten könnte. Dafür hab ich den Artikel geschrieben. pam_time war mir eigentlich ansich zu hoch, wurde aber von aasche vorgeschlagen, mit dem Angebot, dann mein Anliegen der Zugangsbeschränkung als Beispiel dort mit einzubauen.

Vielleicht hat ja jemand noch eine Version als Vorschlag, die das Thema für in Kinder verlinkbar abdeckt und noch verständlich ist, indem ihr da vermeintlich überflüssiges rauswerft bzw. im Quelltext auskommentiert und einen Hinweis gebt, das z.B. auf einen Absatz zusammenzufassen oder so. Ob das dann für mich machbar ist, weiß ich nicht. Paar Absätze verschlanken schaffe ich vielleicht zeitlich und inhaltlich - ein kompletter Rewrite ist nur für den langen, unverständlichen Anfang angedacht.

Rein sprachlich könnte man das sicherlich auch noch an der einen oder anderen Stelle vereinfachen, zwecks Verbesserung der Verständlichkeit. Doppelte Verneinungen helfen da z.B. in der Regel nicht.

Ich schau jetzt nochmal durch und liefer dann nochmal eine Version zum Diskutieren ab.

Gruß, noisefloor

Grüße, Benno

Doppelte Verneinungen helfen da z.B. in der Regel nicht.

Das liegt vielleicht am Prinzip von pam_time, wenn mit "!" Rechte entzogen werden. Dann schreibt man in der Erklärung sowas wie z.B. "Nutzer XY ist Z nicht erlaubt" anstatt "...verboten".

Neue Version 1.7 des Artikels (noch nicht ganz 2.0):

• Anfang: Verständnis komplett überarbeitet und gekürzt.

• Reihenfolge der Fußnoten angepasst, bis es endlich trotz Edits passte.

• root → tom geändert.

• Beanstandete Formulierungen überarbeitet.

• Paar Sachen aus Hinweis-/ Expertenboxen gelöscht, teils was dahin ausgelagert.

• Das Konkretes-Beispiel-Nutzungszeit-beschraenken erklärt die bisherigen Unklarheiten der Nutzung exakt, so dass eventuell weiterbestehende Unklarheiten dadurch beseitigt werden und unerwünschter Dauerlogin verhindert wird, damit die Loginsperre auch greifen kann.

• Beispiel extrem gekürzt, doppeltes auch raus, allgemeines in den Hauptteil ausgegliedert.

Grammatikcheck mach ich am Schluss gerne noch, so weit sind wir aber noch nicht. Wie ist euer Feedback zur Version 1.7?

Grüße, Benno