Ich will für Logfiles gleich auf DBlog setzten und muss mich für eine DB entscheiden.
Grundsätzlich ist klar, das Sqlite schlanker ist, nur aus einer Datenbankdatei besteht und somit ressourcenschonender, als der große Bruder. Mysql läuft als eigener Prozess auf dem RPI 3.
Ich will als Einsteiger da jetzt technisch gar nicht so tief einsteigen - gibt ja genug anderes zu tun.
Was mich aber interessieren würde:
1. Läuft Mysql ordentlich auf dem RPI 3, oder kann es dadurch zu Performanceproblemen kommen?
2. Was kann Mysql bezogen auf den Usecase "Logfiles" in FHEM besser als Mysql?
3. Ab wann könnte man mit Sqlite an Grenzen stoßen?
Hi,
ich bin irgendwann mal von sqlite auf mariaDB umgestiegen - Hauptgrund war, dass sqlite gefühlt - vor allem bei Plots - sehr langsam wurde. Sowohl die sqlite, als auch die mariaDB liefen bzw. laufen auf dem FHEM RasPi mit. Letztendlich taugen beide DBs für FHEM. Wenn du eh schon eine mySQl hast, würde ich die mit verwenden.
Grüße,
Oli
Ich darf getrost feststellen, dass ich mehrere Millionen Datensätze nie wieder angesehen habe. Archivierung erfolgt bei mir seitdem nur mit Hilfe von grafischen Darstellungen.
Und als Einsteiger hat man normalerweise andere Planungsprobleme...
LG
pah
Daten sammeln bis zur Ohnmacht möchte ich gar nicht. Maximal ein Jahr, dann soll (am besten automatisch) alles wieder überschrieben werden. Irgendwann platzt so ein System ja sonst.
Ich war bisher in dem Glauben, ich müsste eine Datenbank, bzw. eine Textdatei zum Loggen erstellen, um eine grafische darstellung daraus generieren zu können?
Grundsätlich scheue ich den Aufwand nicht, direkt eine Datenbank einzurichten. Es gibt ja zahlreiche gute Anleitung sowohl zu MySql als auch zu SQlite.
Ich persönlich würde immer zur MySQL greifen wenn möglich.
Hauptgrund ist für mich vor allem der sichere und problemlose Betrieb mit parallen Schreib- oder Löschvorgängen die ich mit DbRep durchaus nutze.
Aber ich bin sicher auch etwas subjektiv weil ich diese DB und deren Möglichkeiten mag. ;)
Grüße
Heiko
DbRep funktioniert laut Wiki ja auch mit SQlite.
Läuft MySql auf einem RPI3 denn so geschmeidig, dass es zu keinen Performanceengpässen kommt (wenn nur FHEM und MySql darauf laufen)?
Welchen Mehrwert bringt mir MySql?
P.S.: Was ich oben vergessen habe...Ich möchte später auch verschiedene Readings miteinander verrechnen und das Ergebnis in die DB speichern, um daraus ein Notify zu erstellen.
Ja natürlich funktioniert DbRep auch mit SQLite, darauf habe ich geachtet. Aber der Nutzer muss bei SQLite darauf achten parallele Schreibvorgänge zu vermeiden weil diese DB nicht so gut damit umgehen kann.
Dafür gibt es im DbRep auch Methoden, z.B. schließen der Dblog Verbindung für die Zeit der Parallelfunktion.
Wie gesagt, du musst abwägen. Ist ein Betrieb von MySQL auf deiner Hardware aus Sicht der Ressourcen problemlos möglich wäre meine Entscheidung MySQL.
Ist das nicht gegeben, naja dann bleibt ja nur SQLite.
Für deinen Anwendungsfall im PS halte ich MySQL für genau das Richtige für einen geschmeidigen Betrieb wenn deine Hardware ausreicht.
Hallo stonev,
Ich habe mit sqlite angefangenen und dann festgestellt das nur Local und nicht über IP darauf zugegriffen werden kann. Ich habe verschiedene fhem-SERVER und die sollen alle in die gleiche DB schreiben. Ich habe jetzt MySQL auf meinem NAS (QNap) und bin zufrieden. Auf dem raspi3 habe ich es versucht aber nicht so richtig hinbekommen. Da hatte ich auch noch eine sd-karte im raspi3. Jetzt betreibe ich diesen mit einer ssd-platte. Von dieser wird auch gestartet. Läuft viel besser, stabiler.
Pejonp
PS:
Ich habe einen BananaPi + SSD 120 GB Anleitung hier (https://blog.doenselmann.com/banana-pi-mit-ssd-hdd-betreiben/) und einen Raspi3 + SSD 120GB Anleitug hier (https://raspberry.tips/raspberrypi-tutorials/raspberry-pi-von-ssd-festplatte-booten)
SSD sind beide von hier https://www.pollin.de/p/ssd-intenso-high-performance-3813430-sata-iii-120-gb-703088) und bin damit mehr zufrieden als mit der SD-Karte.
OK, die Tendenz geht zu MySql. Es gibt so viele Anleitungen von Leuten, die das auf den RPI bügeln, dass es ja irgenwie gehen muss.
Vielleicht melden sich ja hier noch ein paar Leute, die Erfahrungen damit gesammelt haben.
Hier habe ich noch Optimierungstips zur Anpassung von Mysql für den RPI gefunden:https://der-linux-admin.de/2015/01/raspberry-pi-mysql-server-installieren-und-optimieren/
Über eine kleine SSD mit USB Controler denke ich mal nach. Kostet ja auch nicht die Welt. Ich frage mich nur, ob 10MB/s zu 40MB/s bei den paar Readings einen so großen Unterschied machen...
Zitat von: stonev am 04 Januar 2019, 22:38:46Ich frage mich nur, ob 10MB/s zu 40MB/s bei den paar Readings einen so großen Unterschied machen...
Vorteil der SSD ist, dass sie für permanente Schreibzugriffe ausgelegt ist - eine SD-Karte aber nicht. Und eine Datenbank schreibt nunmal auch viel.......
Werde jetzt noch einen PI3 B+ mit SSD bei Pollin Orden. Welchen USB SATA Controller nutzt ihr? Gibt es da etwas zu beachten?
Ich neige zu diesem Gehäuse: https://www.pollin.de/p/6-35-cm-2-5-festplatten-gehaeuse-usb-3-0-zu-sata-721757
Oder https://www.pollin.de/p/usb3-0-festplattengehaeuse-cnmemory-spaceloop-sata-2-5-bulk-703512
Es gibt auch reine Kabel/Stecker Lösungen, allerdings hätte ich dabei die Sorge, dass sich Stecker und SSD mal unfreiwillig trennen.
Der Nachteil von SSD beim Pi ist, das es über den USB geht. Wenn Du noch andere USB-Geräte am Pi betreibst, solltest Du wissen, was Du tust .... der USB-Bus beim Pi ist prinzipiell unsicher und Linux (als Unix) "mag" es nicht, wenn ein Datenträger "mal eben weg ist" (Wobei es heute stabiler als früher ist)
Ich habe 2 Geräte (siehe post#7) mit ssd und bin zufrieden. Auf jedenfall besser als mit SD-Karte, da sind schon einige ausgefallen und konnten mit Mühe wiederhergestellt werden.
Mit einer kleinen hd-Festplatte ging es auch nur die Stromaufnahme ist dann etwas höher.
Der Banana-pi hat einen extra sata-festplattenanschluss.
Pejonp
Zitat von: stonev am 08 Januar 2019, 06:34:50
...
Ich neige zu diesem Gehäuse: https://www.pollin.de/p/6-35-cm-2-5-festplatten-gehaeuse-usb-3-0-zu-sata-721757
...
Ist zwar etwas OT, aber ich habe genau dieses Teil und würde es nicht empfehlen.
Warum? Die HDD hängt nur am SATA-Port und kann nicht weiter arretiert/ verschraubt werden. Der Adaptereinschub wird zwar seitlich mit klitzekleinen Schräubchen gesichert, aber dies verhindert nur das Herausrutschen. Die HDD schlabbert und wabbert im Gehäuse leicht umher und das Gehäuse selbst ist auch schlecht irgendwo festzuschrauben. Meines hab ich letztlich auf Hutschiene montiert (alten Metallbaukasten zu Rate gezogen ;) ) und das Gehäuse sitzt fest, aber die HDD darin würde keine großen Erschütterungen ertragen.
Ich hoffe dies hilft bei der Suche.
Viele Grüße
rob
Wenn es zur Speicherung von "Performance Daten" oder "Sensor Daten" geht um daraus eine schöne Grafik darzustellen, warum dann nicht die INFLUXDB?
Läuft bei mir super.
Gruß
Hermann
Zitat von: hermann1514 am 08 Januar 2019, 16:27:22
Wenn es zur Speicherung von "Performance Daten" oder "Sensor Daten" geht um daraus eine schöne Grafik darzustellen, warum dann nicht die INFLUXDB?
Die Antwort ist einfach: Ich hatte von dieser Möglichkeit noch nichts gehört. Gibt ja auch ein paar Anleitungen dazu. Aber wenn man nach Fhem und DB sucht, ploppen auf den ersten Seiten immer nur MySQL und Sqlite auf. Ich habe influxDB deswegen auch mal in den Titel mit aufgenommen.
Wie sieht es bei influxDB denn mit der Ressourcenbelastung auf dem PI aus? Läuft die ausschließlich lokal, oder kann man da auch von außen mit einem Client darauf zugreifen?
@rob: Danke für den Hinweis, werde das Gehäuse dann meiden.
Zitat von: pejonp am 08 Januar 2019, 10:46:25
Der Banana-pi hat einen extra sata-festplattenanschluss.
Ich schau mir den Banana mal an. SATA onboard wäre dann schon interessant. Ist denn die Insatallation auf dem Banana vergleichbar mit der auf dem PI? Oder müsste ich mich da neu aufstellen?
BananaPi hat mehrere Variante mit SATA oder sogar PCIE, interessantes auch der Odroid HC1.
Für alle gibts diverse fertige OS-Images - ist auch nicht viel anders wie mit dem Raspberry Pi.
@stonev
Ich habe den Banana Pi nicht den Pro (https://www.amazon.de/dp/B00JWSH7SO/ref=twister_B00TQV2CPK?_encoding=UTF8&psc=1)
http://wiki.lemaker.org/LeMaker_Banana_Pro/Pi.
Es gibt verschiedene Software (http://www.lemaker.org/product-bananapro-resource.html)
Pejonp
Hab gerade mal ein wenig recherchiert. Aktuell wäre dann noch der
Banana PI M2 Berry (http://www.banana-pi.org/m2ub.html) für knapp unter 40 Euro
oder der
Banana PI M2 Ultra (http://www.banana-pi.org/m2u.html) für etwa 60 Euro
Bei Golem ist zu lesen, dass der Berry keinen echten SATA hat, sondern nur eine onboard USB-SATA Brücke. Dementsprechend limitiert ist auch die Geschwindigkeit mit etwa 40MB/s. Bei der Rechenleistung ist er dem RPI 3 unterlegen.
Der Ultra scheint interessanter, da er einen echten SATA haben soll. Zudem sind 8GB onboard Flashspreicher verbaut, was für eine Datenbank ausreichend sein sollte. Eine SSD wäre dann sicher entbehrlich.
Insgesamt liest man aber immer wieder, dass die herstellerseits zur Verfügung gestellten Distributionen nicht wirklich ausgereift sein sollen. Solange Fhem darauf stabil läuft, wäre das aber sicher zu verschmerzen.
Hmm, also bei allen Recherchen zu Alternativen zum Raspberry erscheint der odroid HC1 am vielversprechendsten. Aber auch er hat nicht nur Vorteile in Form des am USB 3.0 hängenden SATA-Anschlusses.
Er soll spürbar mehr Strom benötigen (Idle 4-5 Watt, Vollast 12 Watt - Quelle: http://www.raspberry-pi-geek.de/Magazin/2018/02/Odroid-HC1-von-Hardkernel-im-Test/(offset)/2 ), hat nur einen USB Anschluss und keine Pins.
Dazu lese ich immer wieder von nicht ganz ausgereifter Software und (z. B. bei Banana) von veralteten Kerneln.
Ich neige dazu, doch den RPI 3 B+ zu nehmen. Dieses Gehäuse hier:
http://www.raspberrypiwiki.com/index.php/X820_Metal_Case_V3.0_Version
könnte für Ordnung sorgen (kostet aus China unter 20 Euro) und versorgt USB-SATA Controller und SSD extern mit Strom.
Muß es ein SBC sein?
Ansonsten gingen auch noch Zotac, BRIX, NUC & Co.. Die benötigen zwar auch etwas mehr als die 3,5W, liegend damit aber immer noch im Bereich des HC1 (oder einer Fritte).
Und sind "richtige" x86-Technik mit der entsprechenden Einbindung der externen Schnittstellen...
Und so hoch ist der Zuschlag im Einkauf dann auch nicht.....
Zitat von: Wernieman am 09 Januar 2019, 18:18:16
Und so hoch ist der Zuschlag im Einkauf dann auch nicht.....
Hmm, unrecht habt ihr nicht. Der Banana PI M2 ultra mit nativen SATA liegt bei 60 Euro zzgl. SSD (20 Euro für 120GB) und ein Gehäuse (15 Euro pauschal) macht 95 Euro. Der wäre bei Einplatinenrechnern wahrscheinlich meine Wahl, wenn die Unsicherheiten einer vernünftigen Softwareversorgung nicht wären. Der RPI 3 käme mit Gehäuse auf etwa 75 Euro.
Ich habe mal nach den X86 geschaut:
https://www.notebooksbilliger.de/pc+systeme/barebones+pc+systeme/page/1?sort=price&order=asc&availability=alle
Da ist einiges in der Preisklasse 100 bis 130 dabei. zzgl. 20 Euro für die 120er SSD und 25 Euro für 4GB Ram, macht 145 - 175 Euro. Bei Finanzierung gehen noch 50 Euro runter, dann macht es gar keinen Unterschied mehr.
Welchen würdet ihr davon empfehlen? Sind verschiedene Intel-Prozessoren:
Celeron N3000,2x1,04 GHz, TDP 4W Braswell - Brix GB-Bace-3000 - 112,-
Celeron N3060 2x1,6 GHz, TDP 6W Braswell - Zotac BL324 - 99,-
Celeron J3160, 4x1,6 GHz, TDP 6W Braswell - Brix GB-Baca-3160 - 111,-
Celeron N3160, 4x1,6 GHz, TDP 6W Braswell - Zotac BI325 - 114,-
Celeron N3050, 2x1,6 GHz, TDP 6W, Braswell - NUC
Celeron J3450, 4x1,5 GHz, TDP 10W, Apollo Lake - NUC6CAYH und Brix 3455 ca. 125
Celeron N3350, 2x1.1 GHz, TDP 6W, Apollo Lake - Brix 3305C - 135,-
Pentium N3700, 4x1,6 GHz, TDP 6W, Braswell, ASUS VM065M - 139,-
Vlt. kennt sich mit den Dingern ja einer gut aus und kann mir nen Tipp geben...
:)
..ist nicht ganz einfach, weil den ultimativen Einblick auch keiner hat...
Scheinen alle (jedenfalls die ersten paar) passiv zu sein, das würde ich in jedem Fall empfehlen. Prozessorleistung ist dagegen für reinen FHEM-Betrieb ziemlich egal. Worauf du achten solltest, ist Linux-Kompabilität, die ist bei manchen NUC-Varianten ein Problem (von den anderen habe ich sowas bisher nicht gehört); da sollte aber auch die Herstellerseite Auskunft geben, in der Regel gilt hier auch: (etwas) älter ist besser.
Du kannst ja mal die Forensuche bemühen, mit jeweils dem konkreten Modell, es gibt da diverse Threads, in denen dieses Thema immer mal wieder diskutiert wurde und diverse Leute ihre Lösungen präsentiert haben. Außer dem Linux-Kompabilitätsthema scheinen kaum Probleme aufgekommen zu sein, egal, ob BRIC, Zotac oder (kompatibler!) NUC: Alle soweit erkennbar zufrieden...(Auch die Leute, die einen Thin-Client haben, scheinen zu der Gruppe zu gehören ;) ). x86 ist halt "richtige" PC-Technik und tendenziell eben wegen größerer Verbreitung der verbauten Komponenten (Linux-)stressfreier.
Na ja. Ich habe seit kurzem einen Beelink M1 in Betrieb - da war die Installation von Linux und FHEM vollkommen stressfrei. Man muss halt wissen, was man tut.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 10 Januar 2019, 17:57:14
Na ja. Ich habe seit kurzem einen Beelink M1 in Betrieb - da war die Installation von Linux und FHEM vollkommen stressfrei. Man muss halt wissen, was man tut.
...Immer wieder was neues, den kannte ich noch nicht, stützt aber die These, das x86-Hardware an sich halt in der REgel ziemlich stressfrei ist :) ...
Vielleicht sollten wir im Wiki eine Seite bauen für x86-Hardware? Die veraltet zwar schneller, als man schreiben kann, aber wichtiger ist vermutlich die Botschaft: Es gibt Alternativen zum Pi oder anderen SBCs. Und: wer ein Haus baut, sollte vielleicht nicht grade an der Server-Hardware zu sehr knausern, sondern (so man nicht Virtualisieren will und ein Windows als Hostsystem nutzen) lieber nach einem Blick in die Linux-Kompabilität "richtige" fanless-Hardware holen. (Verbunden mit ein paar Links zu passenden Beiträgen).
Ich habe mich mal ein wenig mit den o. g. Prozessoren beschäftigt.
Auf dem System soll nur FHEM und Mysql laufen. Fhem ist single threaded - da bringen 4 Kerne nichts. Mysql ist zwar grundsätzlich multi threaded, aber jede Verbindung mit der Datenbank wird in einem Thread abgearbeitet. Da es nur Fhem als Datenbankverbindung gibt, wird auch da alles über einen Kern abgearbeitet (so habe ich das verstanden - falls falsch bitte korrigieren).
Soweit o. a. Annahmen stimmen, wäre ein auf single thread optimierter Dual Core wohl die bessere Wahl. Hier wäre das imho der Brix mit dem Celeron N3350 aus der neueren Apollo Lake Generation.
Bei den Vierkernen wären der J3455 oder der N3450. Ersterer ist zwar in der Anschaffung etwas günstiger, hat aber aber 10 statt 6 Watt TDP im Vergleich zum N3450, welcher aus diesem Grund meine Wahl bei vier Kernen wäre. Der wird auch aktuell im Zotec CI327 verbaut.
Könnt ihr o. g. Annahme bzgl. 2 oder 4 Kernen bestätigen, oder bin ich da auf dem Holzweg?
Ich würde "single-Threaded" bei einem Unix-Server-System nicht so ernst nehmen. Bei einem Simplem System Deiner Idee hast Du:
1 Kern FHEM (oder bei Non-Blocking mehr!)
1 Kern MySQL
1 Kern fürs System
Bitte jetzt die Analyse nicht sooo ernst nehmen, bei Kern zähle ich Hyperthreading mit dazu.
Also heute würde ich mindestens ein 2 kern-System nehmen, eher mehr. Würde deshalb auch eher den N3450 nehmen.
Habe hier ein älteren Zotac CI320 mit dem N2930 und total Glücklich. Allerdings macht der deutlich mehr als "nur" FHEM. Der ist für FHEM eigentlich schon total überdimensioniert.
Das Problem bei den lüfterlosen Minis ist, dass die wirklich eine sehr kurze Generationenfolge haben. Tipps und Anleitungen veralten also schnell.
@stonev: Ich sehe immer noch keinen Use Case für eine komplexe Datenbank nur fürs Logging. Mein Tipp:Mehr Energie in eine gute FHEM-Installation stecken, als in die Datenbank.
LG
pah
@Pah: So wie ich das bisher verstanden habe, muss ich die Readings doch irgendwo loggen, um mit den SVG Plots darauf zugreifen zu können. Wenn es einen anderen Weg gibt, gib mir bitte Tipp, wo ich suchen muss.
P.S.:
Mal nebenbei: Was nimmt man am Besten für Fhem? Debian Stretch Server?
Zitat von: stonev am 13 Januar 2019, 22:30:49
@Pah: So wie ich das bisher verstanden habe, muss ich die Readings doch irgendwo loggen, um mit den SVG Plots darauf zugreifen zu können. Wenn es einen anderen Weg gibt, gib mir bitte Tipp, wo ich suchen muss.
P.S.:
Mal nebenbei: Was nimmt man am Besten für Fhem? Debian Stretch Server?
ad logging: es gibt auch das einfache fileLog, siehe https://wiki.fhem.de/wiki/Quick-Start
ad OS: Möglichkeiten gibt es viele, vermutlich ist Debian am stressfreisten, da ausgereift und bei vielen die Basis. Da dann jeweils das aktuellste (also nur im Moment stretch ;) )... Installationsanleitung für ein sehr reduziertes System mit ssh-Zugang, Einrichtung von sudo usw. findest du im Wiki bei den Thin-Clients (ist auch x86 ;) ).
FileLog, mit täglichem Wechsel der Datei. Wenn man da von 5 Devices jede Minute 1x etwas schreibt, sind das pro Tag rund 7000 Zeilen, die noch problemlos von den Plotroutinen verarbeitet werden können. Und mit dem hin- und her Blätterm kann ich auch vorige Tage anzeigen lassen - also was ist das Problem ? Am Ende eines Monats kommt dann etwas in Monatslog.
Alle nicht direkt benötigten Dateien werden automatisch archiviert (bei mir um Mitternacht auch auf die NAS geschoben). Und einmal im Jahr alle gelöscht. Denn es ist vollkommen sinnlos zu wissen, welche Vorlauftemperatur am 1. Oktober um 17:30 im Warmwasserkreislauf herrschte.
Edit: Alles dies lernt man und versteht man natürlich erst, wenn man FHEM am Laufen hat. Das genau ist doch der Grund, aus dem ich die ganze Vorab-Diskussion um den Typ der Datenbank für vollkommen obsolet halte. Wenn sich beim laufenden FHEM ergibt, dass man aus irgendwelchen Gründen (etwa wegen vorhandener Dokumentationspflichten) eine Datenbank doch benötigt, kann man sich diese Gedanken immer noch machen.
Ach ja: Debian Server ist viel zu groß - was soll man denn mit dem ganzen Zeug anfangen ? Der beste Beginn ist eine Minimalversion, auf der man ruckzuck alle benötigten Pakete nachinstallieren kann. Mit dieser Minimalversion starte ich FHEM auch auf virtuellen Maschinen und größeren Systemen.
Also noch einmal: Erst mal anfangen, dann iterativ weiter arbeiten.
LG
pah
Filelog kenne ich. Ich hatte Pah irgendwie so verstanden, als gäbe es eine dritte Möglichkeit. War wohl ein Missverständnis.
@Pah:
Es ist nicht so, dass ich nicht bereits angefangen hätte. Derzeit läuft ein Fhem auf dem RPI3 mit SD Karte. Den hatte ich noch.
Rolladen, Temperatursensoren, Netatmo, Wetter etc laufen auch bereits gut.
Angefangen hatte ich mit FileLog. Nach den ersten Posts habe ich auch schon mal eine MariaDB auf der Synology eingerichtet und schreibe da aktuell die Daten hin. Läuft auch ganz gut, aber ich finde es inzwischen suboptimal, da das NAS (und die HDDs) ja dann gar nicht mehr zur Ruhe kommen.
Ein Grund der bei mir für eine DB spricht, ist dass ich zwei Fhem Systeme aufsetzen muss. Für mich und eins für den Schwager. Letzterer kann aber nur benutzen und nicht das System warten. Ich will das aber auch nicht ständig bei ihm machen. Bei einer DB kann ich sicher auch einmal im Monat alles was älter als 1 Jahr ist automatisiert löschen lassen.
Zum Linux:
Zur Server-Version bin ich gekommen, weil da die grafische Oberfläche schon fehlt, die ich ja nicht brauche. Ich dachte, das wäre dann schon "minimaler". War aber auch als Frage an euch gedacht, weil ihr euch schon damit beschäftigt habt. Meine Linuxrechner hießen bisher immer RPI, da kam Raspian drauf und gut. Beim X86 sieht das anders aus. Googelt man minimal Installationen von Linux, kommen weit mehr als 10 Vorschläge. Die wollte ich nicht alle ausprobieren.
@Pah: Welches Linux nutzt Du denn auf deinem Beelink?
@Beta-User: meinst du das hier: https://wiki.fhem.de/wiki/Thin_Client_Hardware
Demnach wäre es eine "normale" Debian-Installation ohne GUI
Bei "älterer" Harware und Ziel eines reinen FHEM-Systems würde ich auf Debian setzen.
Wenn "der Kernel" zu alt für die Hardware, würde ich eher auf ein Ubuntu-Server setzen.
Bei beiden: Nur Server-Version! Ohne Desktop!
Hier in der Firma sind wir (wegen Softwarealters) mittlerweile bei ziemlich allen Servern auf Ubuntu-Server umgestiegen. Aber (s.o.) das ist bei einem FHEM-System nicht nötig.
Vorteil Debian: Es wird laaangsam (dafür in Richtung Stabilität) entwickelt.
Vorteil Ubuntu: Ist aktueller, dafür nicht so "sauber" wie Debian. Ist mit apt-get auch "fast" ein Debian ;o)
Es gibt noch mehr Distris, aber für Anfänger würde ich bei den obigen Bleiben.
Zitat von: stonev am 14 Januar 2019, 14:35:46
@Beta-User: meinst du das hier: https://wiki.fhem.de/wiki/Thin_Client_Hardware (https://wiki.fhem.de/wiki/Thin_Client_Hardware)
Demnach wäre es eine "normale" Debian-Installation ohne GUI
Ja, der Artikel war gemeint. Nach meinem Verständnis ist das - so wie es dort beschrieben ist - aber keine "normale" Installation, sondern eben eine minimalistische, bei der "fast nichts" installiert wird; es wird praktisch alles abgewählt, nur ssh (-server) ist "ad on" (und "mc").
@Wernieman wegen der Aktualität und Ubuntu-Server:
Bin jetzt nicht so durch, aber mit den "normalen" (K)Ubuntu-Versionen habe ich so meine gemischten Erfahrungen auf diversen Laptops gemacht... (Sofern es in der Server-Variante überhaupt was anderes gibt:) Du würdest aber auch ausschließlich die letzte LTS-Version empfehlen, oder?
Hast du eine Idee, wie groß der Unterschied von stable Ubuntu zum Debian-testing-Zweig ist? Sonst würde ich unterstellen, dass der in der Regel ähnlich stabil ist und ggf. eine Empfehlung wert?
Naja ... Debian-Testing ist mit den nicht LTS-Versionnen von Ubuntu nicht ganz vergleichbar aber ziemlich vergleichbar ... LTS-Versionen sind dann noch etwas anderes.
Würde ein Testing (oder nichts LTS) nicht auf einen Server verwenden!
Mit den Kubuntu-Versionen stimme ich Dir übrigens zu, die wahren in der Vergangenheit häufig grottig (nach meeinen Erfahrungen. habe hier als Desktop deshalb ein Lubuntu ....
Aber zu Ubuntu-Server gibt es dann doch noch große Unterschiede. z.B. setzt der nicht auf den Networkmanager, alle anderen (k,u,l,.....)buntu-Versionen dagegen ....
Wie man (auch ich) hier schon häufig schrieb: Dekstop und Server sollte man vermeiden!
So, nun ist ein Zotac Cl327 angekommen und ich will Debian drauf bügeln.
Eine Verständnisfrage bzgl. Root-Passwort, welches bei der Installation abgefragt wird:
Ist es aus Sicherheitsgründen überhaupt sinnvoll, eins zu vergeben?
Ich habe es so verstanden, dass wenn ich keins angebe, wird der direkte Rootzugang nicht aktiviert. Stattdessen muss dann sudo installiert werden - also so wie auf dem Raspi auch. Mit dem normalen User (in die Gruppe Sudo gepackt) kann ich dann per sudo Root-Rechte in Anspruch nehmen.
Also ich würde root ein Passwort geben (und sicher aufbewahren). Ist im Notfall immer gut, wenn man auch mal direkt an die Maschine kommt.
ABER ... normalerweise nicht verwenden!
Ein "Böser", der auf Deiner Maschine ist, kommt auf "root-Ebene", egal ob der ein Passwort hat oder nicht. Also ist DAS kein Hindernis