Hallo, seit vielen Jahren habe ich eine Homepage (www.bartelsos.de) um Informationen im Bereich Amateurfunk anderen Nutzern bereitzustellen. Ich suche nun nach einer neuen Software, um meine Seite darzustellen. Von Beginn an habe ich b2evolution verwendet. Nach einem Update habe ich aber größere Probleme und so ganz war ich auch mit der Gestaltung nicht zufrieden. Vielleicht ist nun Zeit auf eine anderes System umzuziehen. Was würdet ihr mir empfehlen? Umfang der Seite: -75 Posts mit 150 zugehörigen Dateien -1 Nutzer (mich) -Einen Webhoster habe ich. Was benötige ich: - Ein System für die nächsten vielen Jahre, damit Linkstrukturen erhalten bleiben können und ich besser zitiert werden kann. Dieser Punkt hat mich in den letzten Jahren auch bewogen bei b2evolution zu bleiben (und die Bequemlichkeit) - Möglichst so gestaltet, dass es keine Probleme mit der dsgvo & Co gibt. - Für die Dateien einen Downloadzähler. Es reicht, wenn dieser Zähler nur für mich sichtbar ist. - Meine Seite soll eher so etwas wie eine Art Wiki oder Handbuch sein, mit einer festen Struktur. Es soll kein Blog werden. - Das Schreiben neuer Beiträge und das Hinzufügen von Dateien für einen Download soll einfach sein. Auf eine absolute Freiheit in der Gestaltung verzichte ich gerne um mehr "Einfachheit/Bequemlichkeit" zu erhalten. - Die Seite soll dann so sicher sein, dass es eher unwahrscheinlich ist, dass ich für irgendwelche Angriffe interessant bin. Letztlich wäre dies aber nur lästig, da es nur eine Hobby-Webseite ist. Was ich nicht benötige: - Ich will keine Informationen oder Statistiken über Benutzer speichern. Es soll eine im Sinne der dsgvo unproblematische Seite werden. - Ich will wenig Pflegeaufwand - Ich will nicht programmieren (html, php,...). Hier habe ich rudimentäre Grundkenntnisse. - Keine Kommentarfunktion - Emailformular ist nicht notwendig Eine Info noch. Mein Webhoster bietet für Wordpress eine automatischen Updatefunktion mit automatischem Installationsservice an. Ist Wordpress vielleicht doch für mich zu empfehlen?
Ich benutze seit vielen Jahren DokuWiki als einfache Homepagesoftware.
Christoph Z. schrieb: > DokuWiki Nachtrag zu meinem Set-up (https://brain4free.org): Ich habe ein paar Plug-ins drin, die du in deinen Anforderungen als nicht nötig aufgeführt hast: - Blog - Kommentare Das ist bei Dokuwiki nicht von Anfang an dabei. Die Kommentar Funktion ist bisher auch selten nützlich. Zieht auch manchmal Spam an. Für dich vielleicht nützliche Plug-ins die ich bei mir habe sind: - Gallery - Notes (Info, Warn Boxen) - RefNotes (Fussnoten etc.) - Tag, TagEntry, TagCloud - Indexmenu (nötig für eine klassische Sidebar Navigation)
Schon mal bei Wordpress vorbeigeschaut? Wichtig finde ich auch ein responsive Design, d.h. dass die Seiten auch vernünftig auf einem Smartphone oder Tablet dargestellt werden können. Für Wordpress gibt es viele Themen und Plugins. Bedienung ist einfach. Viele Hoster bringen das als 1-click installer mit.
:
Bearbeitet durch User
Bei wordpress sollte man auf all die Plugins verzichten, die bereiten update und sicherheitsprobleme. Und nicht bei wordpress.com reinschauen, das ist der kommerzielle Teil, sondern bei wordpress.org.
Joern DK7JB .. schrieb: > -Einen Webhoster habe ich. Welche Skriptsprachen und Laufzeitumgebungen unterstützt denn der Webhoster? Auch wenn du nicht selber programmieren willst, so ist dennoch eine wichtige Information, da die ganzen CMS ja selbst auf eine aufbauen. Und wenn du da bspw. eine Java oder Pyhton basierte hast, dann nützt dir das nicht, wenn der Webhoster nur PHP unterstützt. Das: > - Die Seite soll dann so sicher sein, dass es eher unwahrscheinlich ist, > dass ich für irgendwelche Angriffe interessant bin. Letztlich wäre dies > aber nur lästig, da es nur eine Hobby-Webseite ist. und das: > - Ich will nicht programmieren (html, php,...). Hier habe ich > rudimentäre Grundkenntnisse. und das: > Eine Info noch. Mein Webhoster bietet für Wordpress eine automatischen > Updatefunktion mit automatischem Installationsservice an. Ist Wordpress > vielleicht doch für mich zu empfehlen? lässt eigentlich nur zu, dass du das Angebot des Webhosters wahrnimmst und Wordpress verwendest. Denn nimmst du ein anderes CMS, dann musst du es sicherheitstechnisch selber pflegen. Und das willst du ja nicht. Würdest du etwas selber programmieren, dann könntest du zwar die Angriffsfläche minimieren und wärst so vor Überraschungen durch Änderungen neuer Versionen sicher, zumal ein Selbstbau bei weitem nicht so komplex ist wie ein gewachsenes ausgereiftes CMS, gesetzt den Fall natürlich, du machst selber beim überprüfen von Eingaben und bei der sonstigen Sicherheit alles richtig, aber programmieren willst du ja nicht, bzw. fehlen dir dazu die notwendigen Kenntnisse, also fällt das auch weg. Deswegen bleibt eigentlich nur das Angebot des Webhosters übrig. Da kümmert er sich um die Updates von Wordpress und Wordpress ist leistungsfähig genug, so dass das für eine Hobbyseite mehr als ausreichen wird. Dem Ratschlag auf zusätzliche Plugins zu verzichten, schließe ich mich an. Und wenn deine Webseite dank Wordpress auch von einem Smartphone aus zu bedienen ist, dann ist das ein Vorteil den du nutzen solltest.
Wordpress Seiten waren immer mein lieblingsziel wenn mal ein Kunde nach einem Penetrationtest fragte. Über die force-download.php die wp-config.php geholt und weiter ging es. Wordpress würde ich auch sonst meiden. Viele plugins die unsicher sind.
Ich probiere gerade DokuWiki aus. Vielleicht komme ich schon damit aus. Ich muss mir nur noch einen Downloadcounter suchen und die Bedienung von DokuWiki verstehen.
Kilo S. schrieb: > Wordpress Seiten waren immer mein lieblingsziel wenn mal ein Kunde > nach > einem Penetrationtest fragte. Die Frage ist doch, lag es am Kunden (Patch nicht eingespielt oder schlecht gepflegte Plugins benutzt) oder haben die Wordpress Entwickler zu lange gebraucht um Securityfixes für bekannte Sicherheitslücken zu liefern? Bei einem gut gepflegten System, wie der TS bezüglich seinem Webhoster vorgibt, sollte nämlich, wenn, dann doch nur letztere Möglichkeit in Frage kommen. Und in dem Fall ja, nur dann macht es wirklich Sinn etwas anderes zu verwenden. Aber einfach pauschal ne Aussage zu treffen, während vielleicht die Kunden das Problem waren, reicht hier nicht. Denn dann wäre jedes andere große CMS auch nicht besser.
Ich empfehle und verwende immer Joomla. Dann gibts da ja noch Wordpress, Drupal u.a. CMS. Die Erstinstallation ist ein etwas größerer Aufwand als das Hochladen einer simplen HTML-Seite, aber dafür gehts dann später wie geschmiert ...
Nano schrieb: > Die Frage ist doch, lag es am Kunden (Patch nicht eingespielt oder > schlecht gepflegte Plugins benutzt) oder haben die Wordpress Entwickler > zu lange gebraucht um Securityfixes für bekannte Sicherheitslücken zu > liefern? Die force-download.php war einfach generell scheiße gemacht. Viele Lücken sind auch einfach nicht so schnell zu fixen, zum Teil weil sie lange existieren und nur im "untergrund" bekannt werden. (Ob man es glaubt oder nicht... aber frag mal in einschlägigen IRC Chats, wenn du sie findest ;-) und dort dann auch mal als vertrauenswürdig eingestuft wirst!) Das Problem an wordpress ist das viele plugins schlecht gewartet sind. Und das vom Entwickler selbst kaum oder sogar keine Reaktion kommt, auch die Themes sind teils anfällig für Angriffe. https://www.exploit-db.com/exploits/49115 Natürlich gibts das für alle CMS! Aber Wordpress mit 35%+ Anteil ist besonders stark gefährdet. Viele Ziele = Hohes Interesse. Zu 80% waren die Seiten aktuell gehalten. Selten und nur beim absoluten Super-DAU war es eine so stark veraltete Version das ich nicht mal testen musste sondern gleich sagte das es nichts bringt weil ich in drei Minuten den Webspace "Leer" machen kann. Einer wollte es nicht glauben... am längsten dauerte es die Kopie seiner Seite auf meinen Rechner zu laden also das archiv per webshell zu machen. Der rest war dann in Sekundenschnelle weg. Wordpress macht nur Arbeitsaufwand! Täglich nach Lücken schauen, plugins/themes rauswerfen die bis zum fix unsicher sind (wenn es nur eine Lücke ist) usw... Für die Anforderung "Sicher und Unattraktiv Für angreifer" taugt das nicht.
Mir persönlich gefällt https://getgrav.org/ sehr gut. Das System kommt ohne Datenbank aus, die Seiten lassen sich alternativ via Backend oder Texteditor bearbeiten und ein Backup besteht aus einem einfachen Archiv von Textdateien.
Kilo S. schrieb: > Die force-download.php war einfach generell scheiße gemacht. Ja gut, schlechten Code gibt's natürlich auch noch. > Das Problem an wordpress ist das viele plugins schlecht gewartet sind. > Und das vom Entwickler selbst kaum oder sogar keine Reaktion kommt, auch > die Themes sind teils anfällig für Angriffe. Ja, das ist aber ein Problem der Plugins, nicht von wordpress an sich und wie du richtig sagst, gibt's die bei anderen CMS ja auch. Auch da kann man Plugins erstellen und sich dann nicht mehr um deren Pflege kümmern. Im Prinzip ist das bei jedem Projekt so, wo Plugins möglich sind. > https://www.exploit-db.com/exploits/49115 > > Natürlich gibts das für alle CMS! > Aber Wordpress mit 35%+ Anteil ist besonders stark gefährdet. > Viele Ziele = Hohes Interesse. Oder hoher Nutzungsgrad = viele Fehler werden bekannt und dann hoffentlich gefixt. Eine große Anzahl an CVEs ist somit nicht gleich zu setzen mit, dass die Software unsicherer wäre, als eine, die nur wenige CVE Einträge hat. Viele CVE Einträge sind kein Makel, sie sind sogar positiv zu sehen, weil der Entwickler die Sicherheitslücken offen benennt, während andere sie einfach unter den Tisch kehren und den Fix dann unprotokolliert einfach unter den nächsten Patch schieben. Viel wichtiger ist somit also auch, die Geschwindigkeit mit der bekannte Sicherheitslücken gefixt werden und das sie gefixt werden. > Zu 80% waren die Seiten aktuell gehalten. Lag es aber an den Drittanbieterplugins oder am Kern der Software? > Wordpress macht nur Arbeitsaufwand! Täglich nach Lücken schauen, > plugins/themes rauswerfen die bis zum fix unsicher sind (wenn es nur > eine Lücke ist) usw... Die Frage ist halt auch, ob ein anderes CMS gleicher Komplexität, das aber nur wenige nutzen, da wirklich besser ist. Nachher fehlt da die Entwicklermanpower und notwendige Sicherheitslücken werden nicht zeitnah gefixt, sondern die Fixes brauchen viel zu lange. Prinzipiell sieht's doch so aus. Der Hoster bietet es an. Also ist es sein Bier, wenn da was schief läuft. Nutzt der TS dagegen ein anderes CMS, dann wird es zu seinem Problem, inkl. Haftungsfragen. Das sollte man sich gut überlegen ob man sich das ans Bein binden möchte. Zumal ich das Problem, wenn man dann betroffen ist, eher gering einstufen würde. Denn die eigenen Daten hat man noch auf dem Backup und für die Folgeschäden haftet, wenn, dann der Hoster, weil er dafür zuständig war, dass er sich um das CMS und dessen Sicherheit kümmert. Das schlimmste was einem aus dieser Sicht für einen also passieren kann ist: 1. Dass die eigene Webseite nicht das anzeigt, was man anzeigen wollte. 2. Dass die eigene Webseite außer Betrieb ist. 3. Der neue nun dargestellte Content einem persönlich schadet. Wenn die Daten weg sind, hat man sein Backup. Für alle anderen Probleme, die aus einer unsicheren Webseite resultieren können, ist es das Problem des Hosters, wenn er für das CMS zuständig ist. Schlimmer wird's aber, wenn man sein eigenes CMS nutzt. Kümmert man sich dann nicht richtig drum und die Homepage wird zum Umleiten auf sagen wir mal urheberrechtlich geschütze Filme mißbraucht, dann hat man selbst ein Problem. Denn dann kann man nicht sagen, der Hoster war schuld, weil er das CMS nicht abgedichtet hat, sondern man hat sich dann nicht selber darum gekümmert und wenn man das erst ein paar Wochen später bemerkt, ist man aus Fahrlässigkeit dran bzw. könnte einem untergeschoben werden, dass man das geduldet hat. Das kann einem so nicht passieren, wenn der Hoster für die Sicherheit des CMS zuständig ist.
Kilo S. schrieb: > Aber Wordpress mit 35%+ Anteil ist besonders stark gefährdet. > Viele Ziele = Hohes Interesse. Das ist zwar aus der Sicherheitsperspektive richtig, aber es ist ganz genau diese hohe Verbreitung, die die Sache für den weniger versierten Anwender so attraktiv macht: Man bekommt leichter Hilfe als für Exoten und die meisten Probleme hat irgendjemand auch schon einmal gehabt und darüber geschrieben. Da es hier nicht um irgendeine hochkritische Infrastruktur oder die Erwerbsgrundlage geht, tut ein vorübergehender Ausfall auch wenig weh. Man sollte sich des Problems bewusst sein und im Fall der Fälle spielt man eben ein Backup ein. DoS schrieb: > Joomla. Joern DK7JB .. schrieb: > Ich probiere gerade DokuWiki aus. Auch beides möglich, vielleicht könnte man noch MediaWiki ergänzen. Bevor du's ausprobierst, weil es in vielen Übersichten steht: Typo3 ist für dich völlig überdimensioniert.
Nano schrieb: > Prinzipiell sieht's doch so aus. Der Hoster bietet es an. Also ist es > sein Bier, wenn da was schief läuft. Nö, der bietet nur eine automatische Installation und autoupdate für Wordpress Core an. Für Plugins die nachträglich installiert werden gilt das aber sehr wahrscheinlich nicht. Nano schrieb: > Lag es aber an den Drittanbieterplugins oder am Kern der Software? Sowohl als auch. Wobei Core deutlich seltener. Nano schrieb: > Viele CVE Einträge sind kein Makel, sie sind sogar positiv zu sehen, > weil der Entwickler die Sicherheitslücken offen benennt, während andere > sie einfach unter den Tisch kehren und den Fix dann unprotokolliert > einfach unter den nächsten Patch schieben. Zum einen werden die NICHT vom Hersteller selbst gefunden und online gestellt und zum anderen auch nicht immer bestätigt. Auch wenn sie funktionieren! Manche Lücken wurden auch nicht mit dem nächsten Patch gefixt, oft müssten die Nutzer selbst Hand anlegen. Geh doch mal bitte selbst auf exploit-db.com, nutze die erweiterte Suche und such nur mal nach wordpress. Mittlerweile sind es hauptsächlich plugins die dort vertreten sind, wordpress core exploits bzw. Lücken sind älteren Datums. Und nun mach das selbe mal für andere CMS. Joomla/Typo3 käme wohl als nächstes, jedenfalls läuft es auf eines von denen hinaus. Nano schrieb: > Kümmert man sich dann nicht richtig drum und die Homepage wird zum > Umleiten auf sagen wir mal urheberrechtlich geschütze Filme mißbraucht Ach das macht doch schon lange kaum mehr jemand. Wenn laufen dann im Hintergrund Miner oder Exploit Tools die direkt auf die User PC's zielen. Auch beliebt ist es die mailfunktion von PHP zu nutzen um Spam zu versenden. Oder es werden webproxys geschaltet, webshells um von da aus andere Server zu hacken. Filesharing geht heute leichter und sicherer als links über gehackte Seiten zu verteilen. (Darknet) Kinox kriegen die ja auch nicht klein. Das wird mittlerweile unter zig Domains gehostet usw.. Doku/Media-Wiki und ähnliches sind schon eine gute Wahl. Trotz der geringeren Nutzerzahlen gut dokumentiert, Hilfe gibts in vielen Foren und die Zahl von exploits hält sich in Grenzen.
Hast du mal überlegt, nen Homepagebaukasten als SaaS (Software-as-a-service) zu verwenden? Rein von den Anforderungen her, so in Richtung "nicht programmieren" bzw. wenig Pflegeaufwand fänd ich das fast das Beste. Sieht auch nicht unbedingt schlecht aus bzw. kann man recht weit treiben. Aber mit einem vom Hoster gewarteten Wordpress kommste wahrscheinlich auch schon recht weit. Geht so in die Richtung smugmug, jimdo, wix oder webnode. Ist meistens recht preisgünstig oder sogar kostenfrei, bis auf die Domain selber.
Joern DK7JB .. schrieb: > Ich probiere gerade DokuWiki aus. Vielleicht komme ich schon damit > aus. > Ich muss mir nur noch einen Downloadcounter suchen und die Bedienung von > DokuWiki verstehen. Hi, ich habe mir es auch herunter geladen. Wie startet man das DokuWiki? Eine Exe Datei ist nicht dabei. :(
Ich habe auch eine Zeit lang mit Joomla, Drupal oder auch eigenem PHP gearbeitet. Inzwischen denke ich aber, das ist für eine Private Homepage vollkommen übertrieben. Aktuell nutze ich eine mittels "Sphinx" statisch erstellte Homepage die beim Update einfach per FTP auf den Webserver geschoben wird. Der Inhalt kommt aus einfachen Text-Dateien die mit einem beliebigen Editor erstellt und bearbeitet werden können. Der Inhalt muss nur entsprechend dem reST Format formatiert werden. (Ähnlich Markdown, WikiMarkup ...) Sphinx "compiliert" das dann in .html und .js Dateien. (Das Javascript wird für die Suche benutzt, bei mir zusätzlich für Bilder-Galerien) Der Vorteil davon ist, das ich mir das auch ohne Webserver lokal mit einem beliebigen Browser ansehen kann bevor ich es hochlade. Außerdem gibt es kein einziges auf dem Webserver laufendes dynamisches Skript wodurch alle damit verbundenen Einfallstore nicht vorhanden sind. Es reicht ein einfachster Webserver und man benötigt keine Datenbank. Dementsprechend gibt es auch keine Cookies oder sonstige Webseite Daten und damit auch kein Pop-Up. Das einzige was man dann wegen der DSGVO noch beachten muss ist die korrekte Einstellung der Web-Server Logs bezüglich der IP Adressenprotokollierung. (Habe ich bei mir komplett ausgeschaltet) Joern DK7JB .. schrieb: > - Für die Dateien einen Downloadzähler. Es reicht, wenn dieser Zähler > nur für mich sichtbar ist. Die Downloadinformationen kann man auch den Web-Server Protokollen entnehmen. Einmal täglich eine Statistik mittels Webalizer reicht mir aus. (Um genau zu sein schaue ich sowie nur ein paar mal im Jahr nach) Sphinx-Doc: https://www.sphinx-doc.org/en/master/ Ein paar Infos wie man damit eine Webseite machen kann: http://www.numericalexpert.com/blog/sphinx2website/ https://martin-ueding.de/posts/sphinx-personal-website/ (Eigenwerbung:) http://bastelmap.de/ (Ja ich müsste mal wieder was dran machen...)
Hallo Computerwaschel, ich habe mein Test-DokuWiki auf meinem Web-Space installiert und probiere die grundlegenen Dinge aus. Ich habe keine Ahnung, wie es lokal installiert werden kann. Siehe hier: www.dokuwiki.bartelsos.de Wenn du bei Punkt (2) im angehängten Bild den Button betätigst, kannst du den Quellcode sehen. Frage an alle: Wie kann im angehängten Bild unter Punkt (1) der dargestellte Button entfernt werden? Ich möchte, dass die linke Leiste dauerhaft dargestellt wird.
Joern DK7JB .. schrieb: > Wie kann im angehängten Bild unter Punkt (1) der > dargestellte Button entfernt werden? Ich möchte, dass die linke Leiste > dauerhaft dargestellt wird. Anderes Template verwenden. Das hier sieht mir nach docnavwiki aus. Das Standard-Template macht das nicht so. Ob dir dieses Verhalten dann besser gefällt, musst du selbst ausprobieren. Wenn du allgemein nicht möchtest, dass sich die Darstellung der Bildschirmgröße anpasst, ... nach kurzer Suche: Das wird schwierig. Responsive Design (so heißt das) ist heute quasi Standard, vor allem wenn man etwas Neues anfängt. Praktisch alle aktuellen Templates legen schon durch die Tags (responsive, mobile, bootstrap, ...) nahe, dass sie auch so funktionieren, aber du kannst dein Glück ja versuchen.
Joern DK7JB .. schrieb: > Ich habe keine Ahnung, wie es lokal installiert werden kann. XAMPP, du brauchst für die Ausführung von solchen Seiten einen Webserver mit PHP und MySQL. Computerwaschel schrieb: > Wie startet man das DokuWiki? > Eine Exe Datei ist nicht dabei. :( Siehe oben. Aber mach bitte nicht den Fehler als so blutiger Anfänger (und erst recht nicht mit XAMPP) ports ins Internet freizugeben und deinen Rechner als Server zu verwenden. Das geht sonst böse in die Hose. Besorg dir lieber einen Gratis Webspace wenn du das online stellen willst und verwende Passwörter die du NIRGENDWO sonst verwendest. In der Regel sollte im Archiv eine Datei install.php sein bzw. der erste Setupprozess kann auch durch die index.php initialisiert werden.
:
Bearbeitet durch User
Heiner schrieb: > Auch beides möglich, vielleicht könnte man noch MediaWiki ergänzen. > Bevor du's ausprobierst, weil es in vielen Übersichten steht: Typo3 ist > für dich völlig überdimensioniert. MediaWiki ist auch völlig überdimensioniert für die gestellten Anforderungen. Muss ich an anderer Stelle pflegen.
Eure Rückmeldungen zeigen mir, dass vielleicht das DokuWiki, welches ich momentan ausprobiere, wirklich die richtige Entscheidung für mich ist. Zum Dokuwiki habe ich noch einige Fragen: - Wie startet/plant man richtig das Projekt? Gemeint ist, wie man die Struktur und das Vorgehen richtig wählt, damit man später nicht so viel korrigieren muss. Es sollen rund sechs Hauptkategorien werden, die ich nun auch in den entsprechendne Namensräumen abbilden möchte. Auch sollen die Kategorien natürlich links im Verzeichnisbaum/Inhaltsverzeichnis erscheinen. Muss ich mit den Links auf die Kategorien immer auf der "start"-Seite beginnen oder kann ich die start-Seite frei mit irgendwelchen Hinweistexten gestallten? Mir würde es reichen, wenn die Kategorien nur über den linken Verzeichnisbaum angewählt werden können und nicht auf der start-Seite auftauchen. Wenn diese Fragen geklärt sind, ist vermutlich der richtig Zeitpunkt um das Wiki mit richtigen Inhalten zu füllen ;-) - Fagen zum Datenschutz und Cockies Ist es richtig, dass Dokuwiki nur technische Cockies setzt und keine Benutzerstatistiken anlegt?
Kilo S. schrieb: > Nano schrieb: >> Prinzipiell sieht's doch so aus. Der Hoster bietet es an. Also ist es >> sein Bier, wenn da was schief läuft. > > Nö, der bietet nur eine automatische Installation und autoupdate für > Wordpress Core an. Für Plugins die nachträglich installiert werden gilt > das aber sehr wahrscheinlich nicht. Die Plugins lässt man natürlich weg und dann ist es so, wie gesagt, der Hoster trägt die Verantwortung. > Nano schrieb: >> Lag es aber an den Drittanbieterplugins oder am Kern der Software? > > Sowohl als auch. Wobei Core deutlich seltener. Also, alles halb so schlimm. > Nano schrieb: >> Viele CVE Einträge sind kein Makel, sie sind sogar positiv zu sehen, >> weil der Entwickler die Sicherheitslücken offen benennt, während andere >> sie einfach unter den Tisch kehren und den Fix dann unprotokolliert >> einfach unter den nächsten Patch schieben. > > Zum einen werden die NICHT vom Hersteller selbst gefunden und online > gestellt und zum anderen auch nicht immer bestätigt. Auch wenn sie > funktionieren! Zero Day Sicherheitslücken die, wenn dann nur ein eingeschworener kleiner Kreis kennt, kann es bei jeder Software geben. Und natürlich werden die Lücken auch von anderen gefunden und dann oft der Hersteller informiert. Gegenteiliges habe ich nicht behauptet. > Manche Lücken wurden auch nicht mit dem nächsten Patch gefixt, oft > müssten die Nutzer selbst Hand anlegen. Das ist natürlich schlecht. > Geh doch mal bitte selbst auf exploit-db.com, nutze die erweiterte Suche > und such nur mal nach wordpress. Mittlerweile sind es hauptsächlich > plugins die dort vertreten sind, wordpress core exploits bzw. Lücken > sind älteren Datums. Ja, es geht hier aber nur um den Kern, nicht um Plugins von Dritten. Du findest auch über andere CMS auf eploit-db Einträge. > Und nun mach das selbe mal für andere CMS. > Joomla/Typo3 käme wohl als nächstes, jedenfalls läuft es auf eines von > denen hinaus. Wie ich oben schon sagte, die Anzahl der bekannten und protokollierten CVE Einträge sagt überhaupt gar nichts über die Sicherheit einer Software aus. Wenn, dann muss man eher sogar sagen, dass sehr viele CVE Einträge gut sind und sehr wenige sind schlecht. Denn letzteres bedeuten wenige CVE Einträge eins von dem folgenden: 1. Der Hersteller kommuniziert Sicherheitslücken nicht offen. 2. Es gibt zu wenige Nutzer, die nach Sicherheitslücken suchen oder auf diese stoßen. Im ersten Fall bedeutet es, dass der Hersteller alles unter den Teppich kehrt. Administratoren können sich daher nicht darauf einstellen. Wenn Sicherheitslücken nicht klar kommuniziert werden, dann ist damit noch nicht einmal geklärt, ob man den nächsten Patch nun dringend einspielen muss und wenn man über eine bestimmte Sicherheitslücke Informationen suchen muss, dann gibt es keine CVE Nummer, nach der man suchen könnte. Man kann auch nicht herausfinden, ob und ab welcher Version die Sicherheitslücke gefixt wurde und welche Versionen davon betroffen sind. Deswegen ist das schlecht. Im zweiten Fall kann man ne Software mit hunderten Sicherheitslücken haben ohne es zu wissen. Zu wenige Leute beschäftigen sich mit der Software, also ist sie entsprechend schlecht geprüft. Man kann das damit vergleichen, wenn man seine eigenen Verschlüsselungsroutinen implementiert, als sich auf bewährte Bibliotheken zu verlassen, die von vielen benutzt werden. Also 10000 CVE Eintrge = gut 3 CVE Einträge = schlecht So kann man das betrachten. Nur der Laie sieht es umgekehrt. > > Nano schrieb: >> Kümmert man sich dann nicht richtig drum und die Homepage wird zum >> Umleiten auf sagen wir mal urheberrechtlich geschütze Filme mißbraucht > > Ach das macht doch schon lange kaum mehr jemand. Wenn laufen dann im > Hintergrund Miner oder Exploit Tools die direkt auf die User PC's > zielen. Auch beliebt ist es die mailfunktion von PHP zu nutzen um Spam > zu versenden. > Oder es werden webproxys geschaltet, webshells um von da aus andere > Server zu hacken. Ja, die Möglichkeit gibt es natürlich auch. Aber es bleibt dabei, das betrifft nur die Webseitenbesucher und den Hoster, wenn man dessen CMS für das er die Verantwortung trägt, nutzt. Nutzt man das eigene, dann ist man selber dafür verantwortlich. Und darauf wollte ich mit meinen Beispiel ja hinaus. > Filesharing geht heute leichter und sicherer als links über gehackte > Seiten zu verteilen. > (Darknet) Das Tor Netzwerk mag kein Torrent über Tor. Und darüber ist es zu dem sehr langsam, das ist heute auch nicht viel besser geworden. Deswegen werden Links zu Filehostern immer noch bevorzugt und die Links muss man irgendwo unterbringen. Dafür können solche gekaperten Webserver dienen. > Trotz der geringeren Nutzerzahlen gut dokumentiert, Hilfe gibts in > vielen Foren und die Zahl von exploits hält sich in Grenzen. Eine geringe Nutzerzahl kann bedeuten, dass es da noch hunderte nicht bekannter Sicherheitslücken gibt. Eine Zeroday Lücke dafür zu finden, kann bei dieser Software somit viel leichter sein, als bei einer viel benutzten Software wie Wordpress.
Joern DK7JB .. schrieb: > Es sollen rund sechs Hauptkategorien werden, die ich > nun auch in den entsprechendne Namensräumen abbilden möchte. Nativ, ohne irgendwelche Plugins, hat DokuWiki keine Kategorien. Struktur gibt es grundsätzlich über Namensräume. Zusätzlich möchte man vielleicht über das Plugin Tags nachdenken. Joern DK7JB .. schrieb: > Auch sollen > die Kategorien natürlich links im Verzeichnisbaum/Inhaltsverzeichnis > erscheinen. Wenn sich das nicht täglich ändert und immer automatisch nachgezogen werden soll, macht man das von Hand: Du legst eine Seite namens "sidebar" an (kann in manchen Templates auch anders heißen), dort schreibst du direkt rein. Probier mal verschiedene Überschriften und Aufzählungen aus. Wenn dir solche Funktionen wirklich fehlen: Genau deshalb habe ich oben noch das MediaWiki erwähnt. Natürlich ist das erheblich komplexer, aber dafür kann es eben mehr. Ob das ein Vorteil oder ein Nachteil ist, musst du selbst überlegen. Joern DK7JB .. schrieb: > Muss ich mit den Links auf die Kategorien immer auf der "start"-Seite > beginnen oder kann ich die start-Seite frei mit irgendwelchen > Hinweistexten gestallten? Das kannst du machen, wie du möchtest. Seiten müssen auch gar nicht verlinkt sein, so wie z.B. die erwähnte "sidebar"-Seite. Am einfachsten legt man so etwas über die Suche an: Man sucht nach der Seite (die es nicht gibt) und ... lesen kannst du dann selber. :) Joern DK7JB .. schrieb: > Ist es richtig, dass Dokuwiki nur technische Cockies setzt und keine > Benutzerstatistiken anlegt? Ja, aber Plugins können das ändern. Das hier willst du zum Einstieg lesen: https://www.dokuwiki.org/faq:cookies
Joern DK7JB .. schrieb: > Zum Dokuwiki habe ich noch einige Fragen: > - Wie startet/plant man richtig das Projekt? Gemeint ist, wie man die > Struktur und das Vorgehen richtig wählt, damit man später nicht so viel > korrigieren muss. > Es sollen rund sechs Hauptkategorien werden, die ich > nun auch in den entsprechendne Namensräumen abbilden möchte. Es ist ein Wiki, das darf auch wachsen :-) Wenn du mit einer Sidebar arbeitest, bestimmen deine Namensräume dann auch gleich deine Navigation. Seiten lassen sich problemlos von einem Namensräume in den anderen verschieben. Ob Links in anderen Artikeln gleich angepasst werden müsste ich ausprobieren. Die Namensräume dienen dann auch dazu, deine Bilder und sonstigen Dateien die zu in den Artikeln einfügen möchtest, zu organisieren (Musst du bei Upload im Mediamanager dann halt in den gewünschten Namensraum tun.). > Auch sollen > die Kategorien natürlich links im Verzeichnisbaum/Inhaltsverzeichnis > erscheinen. Ja, genau. Meine Sidebar sieht so aus:
1 | {{indexmenu>:#1| js#thread2 navbar noscroll msort tsort nsort notoc}} |
2 | \\ |
3 | \\ |
4 | ---- |
5 | |
6 | Tag cloud |
7 | ~~TAGCLOUD:18~~ |
8 | |
9 | ---- |
> Muss ich mit den Links auf die Kategorien immer auf der "start"-Seite > beginnen oder kann ich die start-Seite frei mit irgendwelchen > Hinweistexten gestallten? Mir würde es reichen, wenn die Kategorien nur > über den linken Verzeichnisbaum angewählt werden können und nicht auf > der start-Seite auftauchen. Das indexmenu plugin listet einfach alle Seiten im gewählten Namensraum auf. Das kannst du in der Sidebar verwenden oder auch auf Übersichtsseiten. Die <namespace>:start Seite ist leicht speziell, da das indexmenu Plugin automatisch da hinzeigt für den Titeleintrag des <namespace> (ob das start heisst oder anders lässt sich in den Einstellungen des Plugins ändern). Es empfiehlt sich, zu jedem Namespace auch eine "start"-Seite zu erstellen. Zum einen um dem Leser zu erzählen, um was es in diesem Namespace/Unterkategorie geht. Zum anderen, weil so die Reihenfolge im indexmenu (entsprechend in der Sidebar) bestimmt werden kann. Für den Namespace "texte" sieht das bei mir so aus: https://brain4free.org/wiki/doku.php/texte:start
1 | {{indexmenu_n>4}} |
2 | ====== Texte ====== |
3 | |
4 | Hier sind ein paar Texte zu finden die ich gesammelt habe und sonst nicht mehr verfügbar sind oder ich selber, aus ganz verschiedenen Gründen, geschrieben habe. |
Und steht dann an der 4. Stelle im Menu (es dürfen auch Lücken in der Nummerierung sein. Also vielleicht mit 10, 20, 40,... beginnen, dann kann man Namespaces dazwischen hinzufügen). Hier ein Beispiel eines Artikels mit Bildergallerie, Bildern (links und rechts ausgerichtete), Links, Wikipedia Link, eingebettetes Video (zentriert) und Tags: https://brain4free.org/wiki/doku.php/elektronik:plattenwaschmaschine Hier der Dokuwiki Syntax dazu (gekürzt):
1 | ====== Plattenwaschmaschine ====== |
2 | {{ :elektronik:plattenwaschmaschine:l1120857.jpg?256|}} |
3 | |
4 | Ich bin ja, neben so anderen Sachen, sehr aktiv in der [[https://sfpd.cultlib.ch|Schweizerischen Stiftung Public Domain]]. |
5 | |
6 | Ich kann da auch auf den sehr guten (und langen) Wikipedia Artikel zur [[wpde>Schallplatte]] verweisen. Alles sehr interessant und vor ein paar Jahren hätte ich nicht gedacht, mal so direkt damit zu arbeiten. |
7 | |
8 | ===== Funktionsprinzip ===== |
9 | Es gibt mehrere verbreitete Prinzipien wie eine Platte von der Reinigungsflüssigkeit befreit werden kann. Wichtig ist, dass keine Rückstände zurückbleiben (leider nicht bei jeder kaufbaren Maschine gegeben). Für mich hat es sich darum schnell auf ein Prinzip reduziert, nähmlich das dass auch von Keith Monks eingesetzt wird, der sogenannte Punktsauger. |
10 | |
11 | Und weil es so schön ist, habe ich ein kurzes Video gemacht, um zu zeigen wie gut unsere Maschine, dank der starken Vakuumpumpe, eine Platte absaugen kann: |
12 | {{ :elektronik:plattenwaschmaschine:cleaning-demo.webm |}} |
13 | |
14 | |
15 | Anstatt noch viel zu schreiben, gibt es hier jetzt einfach Photos und Skizzen vom Bau der Maschine. Mit vielen Details wie, was, wo verbaut wurde. |
16 | |
17 | {{gallery>:elektronik:plattenwaschmaschine}} |
18 | |
19 | {{tag>Public Domain Platten Vinyl Waschmaschine Elektronik frei Musik audio openhardware opensource oshw}} |
20 | |
21 | |
22 | ~~DISCUSSION:off~~ |
Vielen Dank, für eure Beiträge. Sie haben mir sehr geholfen. Ich werde bestimmt einiges übenrehmen, nachdem ich es ausprobiert habe. Nun habe ich nur noch eine einzige Frage. Wie kann ich unter Dokuwiki Linkpfade so erzeugen, dass sie genauso sind wie bei meinem alten Blog. - Alter Link: https://www.bartelsos.de/dk7jb.php/calibration-of-oscillator-phase-noise - Neuer Link: https://www.dokuwiki.bartelsos.de/doku.php?id=calibration-of-oscillator-phase-noise Aus doku.php muss dk7jb.php werden und das ?id= muss ersetzt werden durch einen Schrägstrich.
:
Bearbeitet durch User
Joern DK7JB .. schrieb: > Aus doku.php muss dk7jb.php werden und das ?id= muss ersetzt werden > durch einen Schrägstrich. So wie Martin auch, hätte ich dir für diesen Zweck auch Apache mod-rewrite rules empfohlen.
Wie viele rewrite rules sind erlaubt, ohne dass z.B. der Google-Bot abbricht oder die Seite zu langsam wird. Da die Pfade sich doch stark unterscheiden, denke ich darüber nach die am häufigsten aufgerufenen Seiten direkt umzuleiten (40 Seiten und ca 100 Dateien). Der Dokuwiki-Pfad würde dann einfach so bleiben, wie er nach der Installation voreingestellt war. Das würde vermutlich wiederum ein Update vereinfachen. alt: https://www.bartelsos.de/dk7jb.php/tracking-generator-hp8594q neu: https://www.dokuwiki.bartelsos.de/doku.php?id=oszillator:selbstbau:tracking-generator-hp8594q (später natürlich ohne das "dokuwiki") .htaccess-Eintrag: RedirectMatch 301 www.bartelsos.de/dk7jb.php/tracking-generator-hp8594q(.*) www.dokuwiki.bartelsos.de/doku.php?id=oszillator:selbstbau:tracking-gene rator-hp8594q/$1 Ist ein solcher .htaccess Eintrag richtig? Ist das Vorgehen sinnvoll? Muss man dann alle möglichen Links umleiten - ohne Ausnahme (vermutlich so um die 300)? Oder reicht es nur die Wichtigsten Links umzuleiten und den Rest auf die neue Homepage (neue Startseite) zu leiten? Also alles mit www.bartelsos.de/dk7jb.php und irgendetwas folgendes (wenn es nicht schon umgeleitet worden ist) auf www.dokuwiki.bartelsos.de Also z.B. https://www.bartelsos.de/dk7jb.php/hf-bastelplatine auf www.dokuwiki.bartelsos.de Einfach nur um dem Besucher und dem Google-Bot zu helfen. Wie würde ein solcher .htaccess Eintrag aussehen?
Joern DK7JB .. schrieb: > Wie viele rewrite rules sind erlaubt, ohne dass z.B. der Google-Bot > abbricht oder die Seite zu langsam wird. Wenn du dem Google-Bot 301 (Permanently moved) redirects zurücklieferst, wird er einfach weitermachen und brav seine Datenbank updaten. Das ist ja das Ziel vom 301 und der Bot möchte eine aktuelle Datenbank haben. Ich habe keine Erfahrung mit Apache Performance. Joern DK7JB .. schrieb: > Ist das Vorgehen sinnvoll? Muss man dann alle möglichen Links umleiten - > ohne Ausnahme (vermutlich so um die 300)? Oder reicht es nur die > Wichtigsten Links umzuleiten und den Rest auf die neue Homepage (neue > Startseite) zu leiten? Müssen tust du gar nichts. Ist halt nett, wenn die alten Links noch gehen und die Suchmaschinen ihre alten Einträge ersetzen anstatt neue anzulegen. Mir ist gerade eine Idee gekommen, wie du mit ganz wenigen Rewrite rules auskommen könntest. Startseite, Impressum etc. mit 301 weiterleiten so wie du vorgeschlagen hast aber alle anderen Seiten nicht einzeln weiterleiten (eben weil es viel zu viele Rules geben würde) sondern weiterleiten auf eine Seite mit passenden Dokuwiki Suchergebnissen. z. B. bei mir ist die Such-URL: http://brain4free.org/wiki/doku.php/start?do=search&sf=1&q=%2A<suchbegriff>%2A
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.