Beiträge von Tamerlain

    Moin zusammen,


    auf gut Deutsch denke ich, mysql wird wohl ganz verschwinden - sprich es ist tot, man weiß es nur noch nicht (oder will es nicht wahrhaben).
    Die Open Gemeinde wird Maria verwenden und zurecht nicht einsehen, warum für mysql teuer bezahlen, wenn es für lau das Bessere gibt. Ähnlich wird es wohl auch der kleine Mittelstand tun.


    Im größeren Business Umfeld hat mysql eh nie eine große Rolle gespielt (sinnigerweise, weil kostenlos und was nix kost, kann auch nix sein), das Business verwendet die teuren Brummer DB2 oder Oracle(Rac).

    Moin zusammen,


    mei ist halt a Unix ... die sind drauf ausgelegt zu laufen und zu laufen und zu laufen .....


    Ich hatte mal ein virtuelles SLES unter der Fuchtel mit Uptime von 2300 Tagen :thumbup: (nein Kunde wollte keinen Reboot, keine Upgrades ... nix) - seine Sache aber nunja das zeigt WIE stabil die Unix Boliden sind :)

    Moin zusammen,


    Manfred, Du hast in jedem Linux die Möglichkeit der guten alten Handarbeit. Der Standard-Automat ist nur was für Faule bzw. Leute, die schnell ein Linux mal haben wollen ohne allzu viel Zeit in Wissen zu investieren.
    Das macht Linux ja so mächtig auf der einen und so anfällig auf der anderen Seite.
    Man kann an jeder Stellschraube drehen, gehört man aber zur Fraktion -denn sie wissen nicht was sie tun - haut man sich den Pinguin schneller kaputt als man A sagen kann.
    Aber, nur aus Fehlern lernt man. :)


    Ein Kollege sagte mir einmal: Ein guter Admin installiert sein 1. System von Hand so wie er es braucht und für jedes Weitere baut er sich daraus einen autoyast/kickstart/whatever um sich dann entspannt zurückzulehnen und zukünftig den Automaten arbeiten zu lassen :)

    Moin zusammen,


    also ich habe x mal von mysql auf maria updated (im Zuge von System update) - null Unterschied zu vorher (unter Voraussetzung, dass man die deprecated Configs aus der my.cnf vorher rauswirft/ersetzt).


    Ich bilde mir sogar ein, dass die maria performanter läuft als die alte mysql.

    Moin zusammen,


    du sollst auch nicht via smb einfach verschieben, sondern scp benutzen.
    Ob Du vom windows aus winscp oder pscp (Putty) verwendest ist schnurz.


    wichtig ist nur, dass du 1. das korrekte Passwort zu dem auf der NAS eingerichteten User hast und
    2. in ein Verzeichnis kopierst, auf das der betreffende User bzw seine Gruppe oder Beides auf der NAS auch _Schreibrechte_ hat.


    Alternativ (aber Vorsicht, du solltest _genau wissen_ was Du tust) nimm den NAS Root. Der hat überall Rechte (daher auch _genau wissen was Du tust_).


    Btw. sudo ist ein sehr mächtiges Instrument mit dem man Berechtigungen sehr fein granulieren kann wenn es gut implementiert und das secondary logging an ist.

    Moin zusammen,


    NAS ist per se eine lahme Ente - ebenso wie der 'Oberbau' einer Homecloud.
    Wenn das 'OS' auf der NAS das hergibt (einige NAS können das), kopiere mit scp, das ist wesentlich schneller.


    Sicherungskopien auf meine Homecloud mache ich prinzipiell nur über scp, da rennen die Daten nur so durch die Leitung. :)

    Moin zammen,


    Sterun da sag ichs mal mit den altabgedroschenen Admin Worten: RTFM :saint: . Ohne Scherz es gibt dermassen viele Dokus, Howtos, Examples etc. zum Thema LVM im Netz, dass einem schwindlig wird.
    Letztenendes bleibt Dir aber nur, ausprobieren, selber Erfahrung sammeln. Keine noch so gute Doku ersetzt die eigene Erfahrung.
    Ich habe wie fast jeder Admin auch den LVM in Schulungen und Doku Lesen gelernt. Das ist ne gute ausgangsbasis für ein grundsätzliches Verständnis. Das wirkliche Leben aber bringt einem dann Dinge nahe, die findest Du in keiner Doku und in keiner Schulung. Da musst du dann selber durch oder hast wenn du Glück hast einen Kollegen bei der Hand der langjährige Erfahrung hat und sein Wissen weitergibt. und irgendwann wenn du lange genug dabei bist, wirst Du zu dem erfahrenen kollegen, der sein Wissen weitergeben kann. :)


    Neuland, wenn ich unter LVM ne kaputtgehende Festplatte habe und eine Neue brauche, ist das ebenso easy. neue Platte einbauen, als PV markieren, zur entsprechenden VG zufügen, LVs umziehen, fertig. Voraussetzung ist, dass du deine LVs so angelegt hast, dass sie auf einem PV residieren (also sprich wenn deine VG aus 2 PVs besteht, die LVs jeweils strikt auf einem PV anlegen. tut man das nicht, verteilt der LVM die Daten auf den beiden angeschlossenen PVs). Alternativ wenn die gesamte VG auf der eiernden Platte ist, vgmove auf die neue Platte und gut is. Ist auch ein Erfahrungswert von mir, VGs wo möglich samt aller Volumes auf EINE Platte, also sprich VG1 auf Platte 1 VG2 auf Platte 2.
    Im laufenden Betrieb wird sich das sicher verschieben wenn die Platten vollaufen, aber auch hier gilt, immer eine GANZE Platte zu einer VG zufügen nicht Partitionen einer Platte munter unter die VGs verteilen. Man verliert den Überblick und bei kaputtgehenden Platten geht das Suchspielchen los was denn nun wo liegt.
    Danach kannste die alte pfeifende Platte ausbauen und vollends himmeln.


    Was das nicht Recoverable angeht, nicht der LVM ist da der Casus Knacktus, sondern das Filesystem was da drauf liegt und die Daten enthält.
    LVM ist nur eine Zwischenschicht.
    Du kannst den LVM auch problemlos auf einem RAID Verbund installieren. Dann besteht Deine 'Festplatte' aus dem was Dir der RAID zur Verfügung stellt. Physisch untendrunter hast Du 1-n Platten je nach RAID. Im Privatsektor hat sich nach meiner Erfahrung Raid 1 mit HotSpare bewährt.
    Wenn Dir da eine wegfliegt, who cares, raus ausm RAID damit, Neue einbauen, ins RAID einziehen, Syncen lassen, fertig.
    Bei RAID5 brauchst du 1. mehr Platten und 2. muss die Parität erhalten bleiben. d.h. wenn Dir mal 3 Platten ausfallen beim 5er, dann wars das. Die 2 Intakten retten Dir da nix mehr.


    Grundsätzlich sollte man aber über eine gute und korrekte Datensicherung nachdenken. LVM und RAID sind keine Allheilmittel gegen Plattencrash.

    Moin zusammen,


    warum Grub in den MBR wenn UEFI da ist?
    Sicherstellen, dass im UEFI Mode gebootet wird, Stick dran, Linux hochfahren, verifizieren, dass auch wirklich im UEFI bist, sicherstellen, dass der efi bootmgr installiert ist, efi Partition anlegen, wie in meinem vorherigen Post auch, ne chroot Partition anlegen für /boot, vor dem chroot noch die efi Partition dort hineinmounten, dort dann update-grub und grub-install --verbose (damit man auch schön sieht was er treibt) und gut is.


    Wurde übrigens hier schon sehr gut beschrieben (damaged grub2 reparieren ... ist aber de facto die gleiche Prozedur wie die Umstellung von MBR auf uefi, nur dass man zuvor halt noch ne efi Partition bauen muss):
    LEAP 42.3 Repair a broken UEFI/GRUB2/openSUSE boot scenario