Schlagwörter: ubuntu Kommentarverlauf ein-/ausschalten | Tastaturkürzel

  • mc 18:02 am 6. January 2016 permalink | Antwort
    Tags: , , , , , , ubuntu   

    Raspberry Pi – /dev/ttyUSB0 ist weg 

    Zu Weihnachten habe ich von meinen Schwiegereltern einen „Raspberry Pi 2 Model B“ geschenkt bekommen. Dieser sollte meinen Raspberry Pi (1) Model B ablösen – und hat das inzwischen auch getan 😉 Boah, ist der neue Pi schnell!! Zwischen den beiden Generationen liegen Welten!

    Der Umzug an sich war relativ unspektakulär: SD-Karte (boot) umgesteckt, USB Stick umgesteckt (root), alle Kabel umgesteckt, gebootet – fertig! Alles gut!

    Oder doch nicht alles. Ich stellte relativ schnell fest, dass meine Temperatursensoren nicht mehr erkannt wurden. /dev/ttyUSB0 war plötzlich nicht mehr vorhanden!??! „Na klar, muss am Umzug auf den neune Pi liegen!“ dachte ich so bei mir und hab dann mal schnell ne Stunde Zeit verbraten, um den Port wieder herbeizuzaubern. Erfolglos. Leider. Dann rief mich das Bett…

    Heute Morgen ließ ich mir das Ganze nochmal durch den Kopf gehen und besann mich dann auf einen Ausspruch meines Schwagers Hilmar – seines Zeichens Mediziner: Koinzidenz bedingt keine Kausalität!

    Diesem Leitsatz folgend habe ich das Problem dann nochmal neu beleuchtet und festgestellt, dass die Sensoren schon seit ein paar Tagen außer Gefecht waren! Die Ursache war nach dieser Erkenntnis schnell behoben: ich hatte nach dem letzten apt-get update && apt-get upgrade vergessen mit rpi-update (ggf. mit sudo apt-get install rpi-update installieren) den Kernel zu aktualisieren! Kernel, Treiber und Module passten also nicht mehr zusammen. Aber warum war mir das nicht vorher aufgefallen? Naja, auch das ist leicht zu erklären: ich habe auf meinem Mailserver bei Strato zum Ende des letzten Jahres den Mailversand ausschließlich auf SSL umgestellt – und vergessen, die Konfiguration am Pi anzupassen. Er konnte mir also noch nicht mal per Mail mitteilen, dass er nicht mehr Mailen konnte…

    cum hoc ergo propter hoc!

     
    • Lutz 13:01 am 28. Februar 2021 permalink | Antwort

      Danke, hat mir eben bei genau dem Problem geholfen

  • mc 19:31 am 9. January 2014 permalink | Antwort
    Tags: , , ubuntu,   

    Mails per bash herunterladen und als Datei speichern 

    Heute stand ich vor dem Problem, dass ich die Autoresponder-Mails eines Newsletter-Postfachs auslesen und auswerten wollte. Das Ganze natürlich per cronjob angetriggert und vollautomatisch. Es scheiterte zuerst an der grundsätzlichen Möglichkeit, Mails über POP3 abzurufen und als Textdatei zu speichern. Müsste doch gehen – ist doch Linux. Geht auch: fetchmail heißt das (quasi Standard-) Zauberwort. Fetchmail war mir aber zu aufgeblasen und wie man’s konfiguriert weiß ich auch nicht. Als Alternative fiel mir irgendwann getmail in die Hände – und schon war’s einfach…

    Zuerst mal getmail installieren und das Konfigurationsverzeichnis anlegen:
    $ sudo apt-get install getmail4
    $ sudo mkdir ~/.getmail

    Dann braucht man noch dort eine (simple) Konfigurationsdateim (~/.getmail/getmailrc):
    [retriever]
    type = SimplePOP3Retriever
    server = pop3.dein-server.de
    username = username@dein-server.de
    password = dEiNPassWOrt!

    [destination]
    type = Maildir
    path = ~/path/to/maildir

    [options]
    delete = true

    Der unter destination/path festgelegte Ordner muss über eine gültige maildir Struktur verfügen und die Unterordner cur, new und tmp enthalten. Mit
    $ getmail
    kann man nun an der Konsole Mails abrufen. Fertig ist die Laube…

     
  • mc 10:57 am 25. July 2013 permalink | Antwort
    Tags: , , mysql, ubuntu   

    MySQL Datenverzeichnis verschieben. Leicht gesagt. 

    Auf meinem neuen Linux Webserver wollte ich – um mir das Datensicherungsgehähe zu vereinfachen – den Datenbankpfad für MySQL verschieben. Eigentlich ganz einfach, da nur der Eintrag datadir = /var/lib/mysql in der Datei /etc/mysql/my.cnf anzupassen ist. Blöderweise ließ sich nach dieser Anpassung der Dämon (mit Error 13 – Zugriff verweigert) nicht mehr starten. Schuld ist AppArmor, welches das neue Datenverzeichnis noch nicht kennt und den Zugriff dort hin blockiert.

    Zum Glück ist die Lösung einfach und hier gut dokumentiert. Man muss die AppArmor Konfiguration in der Datei /etc/apparmor.d/usr.sbin.mysqld um den neuen Datenpfad ergänzen. Dazu werden die folgenden Zeilen angefügt:

    /srv/mysql/ r,
    /srv/mysql/** rwk,

    Nach einem Neustart von AppArmor mit sudo service apparmor restart lässt sich dann auch myssql wieder starten: sudo service mysql restart

    Nochmals Danke an Matthias!

     
c
Neuen Beitrag erstellen
j
nächster Beitrag/nächster Kommentar
k
vorheriger Beitrag/vorheriger Kommentar
r
Antwort
e
Bearbeiten
o
zeige/verstecke Kommentare
t
Zum Anfang gehen
l
zum Login
h
Zeige/Verberge Hilfe
Shift + Esc
Abbrechen