Hallo,

Ich habe in den Artikel Rechte den Abschnitt über Windows-Partitionen eingefügt. Dies habe ich ohne Baustelle gemacht, denn da kann man nicht viel falsch machen.

Meines Erachtens gehört zum Thema "Rechte" auch die Rechte-Verwaltung im Netzwerk. Diese wird zwar in den Seiten NFS und Samba Client cifs mehr oder weniger deutlich angesprochen, aber eine Gegenüberstellung im Kontext "Rechte" wäre meines Erachtens kein Fehler.

Für diesen Zweck wäre dann eine "Baustelle/Rechte" sinnvoll.

Gruß - Max-Ulrich

Hallo,

sollen wir den Artikel in die Baustelle schieben?

Gruß, noisefloor

Meiner Ansicht nach, ja. Aber sollen wir noch ein bisschen auf andere Meinungen warten?

Gruß - Max-Ulrich

Hallo,

können wir auch.

Gruß, noisefloor

Ich habe nochmal nachgedacht und mir die Seite Rechte nochmal genauer angesehen.

Es gibt noch vieles mehr, was zum Thema "Rechte" zu sagen wäre (sudo, SUID-Bit bei Dateien und Ordnern, SGID-Bit, ACL, Rechte bei ssh....). Das meiste davon (nicht alles) findet man zwar irgendwo im Wiki ganz gut beschrieben, aber von einer Seite "Rechte" erwartet man eigentlich so eine Art Wegweiser-Funktion: Kurz vorstellen, was das ist, und dann ein Link zur weiterführenden Seite. Das ist bis jetzt nicht zufriedenstellend verwirklicht.

Die Seite Samba haben wir in diesem Sinne umgestaltet und erweitert. Nach den Reaktionen im Forum zu schließen kommt dies gut an.

Deshalb (also nicht nur wegen des Netzwerks) bin ich jetzt sehr dafür, die Seite Rechte für ca. 2 Monate in die Baustelle zu verschieben. Bitte sagt Eure Meinung und bringt ggf. Vorschläge.

Gruß - Max-Ulrich

Ich bin der Meinung, dass der Artikel zwar etwas suboptimal benannt ist, und besser Dateirechte o.ä. heißen sollte, aber die Rechte von Samba, NFS, SSH usw. haben da drin meiner Ansicht nach nichts verloren. Sonst könnte man auch noch die Rechteverwaltungen von verschiedenen FTP-Servern, IMAP-Servern, Content-Management-Systemen usw. mit reinpacken. Wo soll die Grenze sein?

SUID, SGID, ACLs etc. würde zwar thematisch reinpassen, aber den Charakter als Einsteigerartikel deutlich verfehlen. Deswegen finde ich das in Ordnung, dass das in chmod o.ä. beschrieben und in Rechte nur verlinkt wird. Einen Link auf ACL würde ich aber begrüßen.

otzenpunk hat Recht. Die Gefahr, dass das ausufert und unübersichtlich wird, sehe ich auch.

Ich hatte auch bei den Netzwerken nur daran gedacht, kurz anzudeuten, wie diese mit den Dateirechten umgehen. Bei NFS gibt es da nicht viel zu sagen (2 Zeilen), bei Samba schon etwas mehr. Bei sehr vielen Forum-Anfragen zu Samba geht es um Probleme mit den Datei-Rechten. Irgendwie werden die Benutzer nicht zu den entsprechenden Stellen im Wiki gelenkt, oder diese sind nicht verständlich genug geschrieben. Aber auch hier hatte ich nur an eine kurze Andeutung des Problems und an einige Links gedacht (ähnlich wie beim Abschnitt "Windows-Dateisysteme", eher noch kürzer).

Auf Fragen der Zugriffsrechte und Authentifikation wollte ich natürlich hier nicht eingehen! Das würde ins Uferlose führen. Außerdem ging es mir darum, den Artikel "Rechte" im Sinne eines Wegweisers etwas besser zu verlinken. Dem würde otzenpunk sicher zustimmen.

Die Benennung "Rechte" ist sicher nicht optimal, aber plakativ und einprägsam. Man denkt wohl auch bei dieser Benennung zuerst mal an Dateirechte. Ich würde sie so stehen lassen. Vielleicht ein kleiner präzisierender Hinweis in der Einleitung.

SUID, SGID, ACLs etc. würde zwar thematisch reinpassen, aber den Charakter als Einsteigerartikel deutlich verfehlen

Natürlich! Auch da hatte ich nur an einen ganz kurzen Hinweis gedacht, dass es so etwas gibt, und an Links zu den entsprechenden Stellen, mehr auf keinen Fall.

Da es sich bei alledem doch nur um kleinere Ergänzungen handelt, die die Struktur des Artikels nicht wesentlich beeinflussen, könnte ich mir auch vorstellen, diese ohne Baustelle einfach nach und nach so einzubringen. Es liegt letztlich im Ermessen des Wiki-Teams, ob man für so etwas eine Baustelle braucht.

Gruß - Max-Ulrich

Hallo,

solange der Artikel in sich konsistent bleibt, d.h. der Artikel ist in sich stimmig kannst du die Änderungen auch im Wiki machen. Da es nach deiner Aussage kleine Ergänzungen sind sollte das wohl machbar sein.

Gruß, noisefloor

solange der Artikel in sich konsistent bleibt, d.h. der Artikel ist in sich stimmig

Dann will ich es 'mal so versuchen. Aber wohl erst nach den Feiertagen.

Gruß - Max-Ulrich

So, ich meld mich auch mal ein wenig.

Aktuell ist Rechte ja eher suboptimal (wurde ja hier auch schon festgestellt). Was aber in diesem Artikel erklärt werden sollte:

• Wie funktionieren Dateirechte (Mode & Mask)

• Wann funktionieren sie nicht (NTFS, FAT32 usw...)

• Wie kann man diese grafisch ändern, ich denke aber nicht das wir jeden Dateimanager im Hauptartikel haben sollten, das wäre zuviel des guten

• Der Artikel sollte vermitteln wie Dateirechte unter Linux funktionieren, und was es mit rwx, 0755 usw.. auf sich hat

Was nicht in den Artikel gehört:

• ACL's

• Set-UID usw..., also die "Sonderbits" würde ich gerne nicht in dem Artikel haben, es verwirrt doch sehr auch sind das sachen die ein normaler Linux Einsteiger eher selten brauchen dürfte. Das kann man dann ja auch auf chmod erklären.

mfg Betz Stefan

Was encbladexp vorschlägt, ist aber schon eine größere Änderung. Wenn wir uns dafür entscheiden sollten, dann wäre schon eine Baustelle nötig!

Es geht jetzt also in erster Linie darum, zu entscheiden, ob kleinere Korrekturen am bestehenden Artikel (ohne Änderungen an der Struktur und am Layout) ausreichen, oder ob eine Neufassung nötig ist.

Ich würde aber gerne daran festhalten, dass dem Artikel neben der Erstinformation vor allem die Funktion eines Wegweisers mit möglichst vielen Links zu weiter führenden Seiten zukommen sollte - so ähnlich wie bei der Seite Samba.

Gruß - Max-Ulrich

Hallo,

sagt einfach "Baustell, bitte", wenn ihr eine braucht. Den Vorschlag von encbladexp finde ich auch gut.

Gruß, noisefloor

noisefloor schrieb:

sagt einfach "Baustell, bitte", wenn ihr eine braucht.

Ja, mach bitte ne Baustelle drauß.

Was haltet ihr von folgendem Layout:

• Rechte Die Einsteigsseite schlechthin, hier kommt alles über Mode, Eigentümer und Gruppe hin. Auf umask können wir prima verlinken

• Rechte/GNOME Nautilus und seine Eigenheiten

• Rechte/XFCE dito für XFCE

• Rechte/KDE dito für KDE, KDE4 kann man da auch mit reinmachen

Haben wir sonst noch was relevantes? So wäre es schön sauber aufgeteilt. Man bekommt jede Menge Hintergrundwissen und kann darauf Prima verlinken, gleichzeitig wird man nicht von X Dateimanagern erschlagen.

mfg Betz Stefan

Hallo,

done: Baustelle/Rechte. Unterartikel für die drei Desktop-Umgebungen sind IMHO ok.

Gruß, noisefloor

Das Konzept von encbladexp finde ich im Prinzip schon ok, nur sollte man bei einem so groß angelegten Projekt schon wissen, wer das machen kann und will. Ich jedenfalls kann das in solcher Ausführlichkeit nicht machen, das ist mir klar. Dazu fehlen mir auch schlichtweg einige Kenntnisse. encbladexp selbst ist mit der Bearbeitung von pyNeighborhood (nicht der Wiki-Seite, sondern dem Programm selbst!) ziemlich im Stress, und ein paar von den Samba-Seiten fehlt auch noch der fachkundige letzte Schliff (z.B. Samba Server/smb.conf). Das müsste zuerst mal ganz fertig sein.

Dann gibt es das Problem, dass wir im Moment mit KDE allgemein nicht recht weiter kommen. Das liegt wohl auch an den großen Unterscheieden zwischen KDE-3 und KDE-4.

Schließlich eine (vielleicht sehr dumme) Frage: Was haben die Rechte mit den Desktop-Umgebungen zu tun? Doch nur, dass es ein paar grafische Tools zum Verändern der Rechte gibt, die je nach Desktop ein bisschen verschieden aussehen. Ich finde das Konzept, die Seiten für GNOME und KDE und ggf. Xfce zu trennen, schon richtig, aber eben bei den Themen, bei denen es relevante Unterschiede gibt. Ist das bei Rechte wirklich der Fall?

Gruß - Max-Ulrich

EDIT:

@noisefloor:

Wieder die Bilder... Eben sehe ich, dass zwar in Baustelle/Rechte die Bilder vorhanden sind, dass sie aber aus dem Artikel Rechte verschwunden sind. Wenn dieser Artikel während der Baustellen-Zeit weiter verwendbar bleiben soll, muss man sie noch dahin kopieren.