Beiträge von PInguin


    Du solltest einen anderen "Aussen"-Port verwenden und den auf den Port 22 des RPi umleiten, z.B. 10022 ==> 22
    Grund: Üblicherweise scannen die 'bösen' Jungs die Standard-Ports als erstes, dann wird bei einem offenen 22ziger Port natürlich versucht, den anzugreifen... so einfach sollte man es den Jungs nicht machen

    Und das wichtigste: einen Zugang per SSH niemals mit Benutzer/Kennwort benutzen, sondern N.U.R. mit PKA!!!

    Warum? Darum! :D

    Im Ernst: Benutzer und Kennwort können ausprobiert werden. Es macht überhaupt keine Mühe, ein Skript zu schreiben, das pro Sekunde mehrere Tausend Kombinationen testet. Einen SSH-Schlüssel zu knacken oder durch Testen herauszubekommen, ist nach heutigem Stand der Technik nicht innerhalb einer Lebensspanne eines normalen Menschen möglich.

    Und wenn Du trotzdem den Zugang per Benutzer und Kennwort betreiben musst, dann tue Dir selber einen Gefallen und schreiben diese Zeilen in die /etc/rc.local:


    Code
    /sbin/iptables -N SSH_LIMIT 
    /sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 11122 -j SSH_LIMIT
    /sbin/iptables -A SSH_LIMIT -m state --state NEW -m limit --limit 3/min --limit-burst 3 -m tcp -p tcp --dport 11122 -j ACCEPT 
    /sbin/iptables -A SSH_LIMIT -m tcp -p tcp --dport 11122 -j DROP


    Wobei Du den Port natürlich an Deinen Server anpassen musst. Diese Zeilen sorgen dafür, daß pro IP nur maximal 3 Anmeldeversuche innerhalb einer Minute akzeptiert werden. Danach wird die IP geblockt. Das bremst Scanner erheblich aus, so daß Dein Rechner dann einfach uninteressant wird.

    Zur Sache mit der Stromversorgung: ich habe jetzt einen aktiven USB-Hub an den Pi geklemmt, der alle angeschlossenen USB-Geräte, auch die Speicher-Zäpfchen, mit Strom versorgt, und aus einem Port auch den Pi selber. Mit anderen Worten: der Eingang des Hub ist an eine USB-Buchse des Pi angeschlossen, und eine der Ausgänge des Hub versorgt des Pi selber mit Strom.

    Und was soll ich sagen? Seit dem läuft der Pi ohne einen einzigen Absturz. :)

    Die wichtigste technische Anforderung lautet: möglichst wenig Strom verbrauchend!

    Einen alten, ausrangierten PC dahin zu stellen, ist kein Problem. Aber das belastet die Stromrechnung zu sehr.

    Außer der Agfeo-Software soll noch Faxversand und -empfang mit capi4hylafax¹ laufen, sowie ein paar Skripte, die von Zeit zu Zeit Dateien zwischen zwei angeschlossenen NAS kopieren. Wobei das die NAS auch selber machen sollen, der Rechner soll das nur anstoßen können.

    Also eigentlich alles, was der Pi kann. Wenn er denn einen x86 hätte, um die Agfeo zu bedienen...

    [1] Ob mit interner ISDN-Karte oder per USB-ISDN-Adapter, wäre nebensächlich.

    Eben. Und ich finde es schon erstaunlich, daß der Pi zwischen /dev/mmcblk0p1 und /dev/sda1 unterscheidet. Da beide Speicher über USB angeschlossen sind, denn auch der SD-Kartenleser geht, so weit ich weiß über den USB-Controller, müsste die Karte eigentlich sda und das erste Speicher-Zäpfchen dann sdb sein. :s

    Mir fällt gerade etwas ein: kann es sein, daß der verwendete Boot-Loader einfach keine Parameter verarbeiten kann, in denen zwei mal ein Gleichheitszeichen vorkommen? Das könnte es erklären, wieso das Label nicht funktioniert.


    Ich verstehe jetzt Dein Anliegen nicht. Du kannst doch eine andere Gerätedatei als root-fs angeben.

    Richtig. Aber eben nur in der Form /dev/sdxy. Den Parameter "root=LABEL=xxx" kennt der Kernel des Pi nicht. Normalerweise gibt es auch die Möglichkeit, den Parameter "root=UUID=...." zu benutzen. Ob der Pi-Kernel den kennt, habe ich noch nicht ausprobiert. Ich vermute, daß diese Optionen beim Komilieren nicht aktiviert wurden.

    Zitat


    Dass Du den Slice und das Blockdevice (also /dev/mmcblk0p2) angeben musst, ist afaik so, weil der Kernel zu diesem Zeitpunkt ja noch kein root-fs hat und demzufolge mithilfe von fstype und partition über den Treiber das rootfs direkt lädt und einhängt. Das war zumindest unter SysVR4 so.
    Demzufolge bringt ein label in einer /etc/fstab nix, weil die zu o.g. Zeitpunkt noch gar nicht existiert.

    Das ist unter Linux mittlerweile etwas anders. Wie ich schon sagte: soll der Kernel beim Starten auf ein Dateisystem zugreifen, müssen die entsprechenden Treiber (ext2, xfs,...) beim Übersetzen des Quellcodes entweder fest eingebunden werden, oder als Modul in eine spezielle Datei gepackt werden, die beim Starten als RAM-Disk benutzt wird. Aber auch diese Init-RAM-Disk muss natürlich auf einem Dateisystem stehen, auf die der Kernel OHNE weitere Module laden zu müssen, zugreifen kann.

    Zitat

    Mal ganz abgesehen davon: imho ist es simpler, ein Filesystem auf einer Platte zu erzeugen und über den Eintrag /dev/sda1 in der cmdline.txt dem System bekannt zu geben als vorher die Partition noch ( i.d.R dann auch noch möglichst falsch :fies: ) zu labeln.

    Gerade die Möglichkeit, ein Label zu benutzen, macht das Umstecken von Platten sehr einfach, wie auch meigrafd beschrieben hat:

    Warum man nicht einfach nur root=/dev/sda1 in die cmdline.txt einträgt hat den einfachen Grund dass das selbe Device nicht immer mit dem selben Devicename (/dev/sda1) eingehängt wird, sondern manchmal auch als /dev/sdb1 , wenn zum Beispiel beim booten noch ein anderes Blockdevice angeschlossen ist also in diesem Fall ein 2.USB-Stick ... dann kommt es eben leider mal vor das der root-Stick nicht mehr /dev/sda1 ist sondern /dev/sdb1 und somit würde das booten fehlschlagen..

    Eben darum geht es. Nicht nur USB-Geräte werden nicht immer in derselben Reihenfolge erkannt, auch SATA-Controller können angeschlossene Festplatten u.U. durcheinander würfeln, wenn eine Platte mal einen langsamen Tag hat und sich nicht schnell genug meldet. Und dann ist das, was vorher sda war, plötzlich sbd, und der Spaß geht los! ;)

    Zitat

    Diese Unterteilung ist beim PI nötig da die GPU nur FAT Partitionen lesen kann, und da der PI kein BIOS hat übernimmt die GPU den Bootvorgang

    Richtig, so ist es beim Pi. Aber Früher™ hatte man das Problem, daß ohne Frack und Zylinder nichts ging. :D Wenn eine Festplatte eine bestimmte Anzahl von Zylindern überschritt, konnte der Bootloader nicht auf Partitionen zugreifen, die hinter dieser Grenze lagen. Daher musste der Linux-Kernel auf einer Partition stehen, die unterhalb dieser Grenze lag. Daher die getrennte Boot-Partition.

    Noch ein Tipp: Du kannst Dir die Sache mit dem Umkopieren mit "dd" etwas einfacher gestalten: einfach die komplette Root-Partition auf das neue Medium kopieren. Das solltest Du aber an einem anderen Rechner machen, nicht auf dem Pi im laufenden Betrieb. ;)


    Und das ist afaik auch Humbug, weil weder Linux noch Xenix noch Unix irgendwas mit dem BIOS eines PC machen.

    Also irgendwie steh' ich heute wohl daneben.
    Aber was solls ;) ....

    Dann hast Du noch nie das Problem gehabt, daß ein angeschlossener USB-Speicher mal sda und ein anderes mal sdb war? Darum geht es. USB-Geräte werden nicht immer als das gleiche Gerät angesprochen. Und bei vielen USB-Hubs ist auch die Reihenfolge der Belegung der Ports ausschlaggebend, welcher Stick sda und welcher zu sdb wird.

    Wir reden hier ein wenig aneinander vorbei.

    Die Boot-Partition ist die, die Du später auch unter /boot im Verzeichnisbaum eingehangen findest. Das ist die Partition, auf der der Bootloader installiert ist, der Kernel und die cmdline.txt zu finden ist.

    Das Root-VZ ist die oberste Ebene im Verzeichnisbaum, zu erreichen mit "cd /". Diese VZ kann auf einem beliebigen Medium liegen, auf die der Kernel zugreifen kann, also dessen Treiber er zum Zeitpunkt des Startens kennt, entweder durch festes Einkompilieren, oder durch Bereitstellung der Module in einer Init-RAM-Disk.

    Nachdem der Bootloader von der Startpartition den Kernel geladen hat, übernimmt der Kernel den weiteren Startvorgang und hängt die Partitionen in den VZ-Baum ein. Als erstes natürlich das Root-VZ, und dann sucht er in /etc/fstab nach weiteren Medien/Partitionen, die er einhängen muss. Ab diesem Zeitpunkt wird die Startpartition eigentlich gar nicht mehr benötigt, sie wird nur der Bequemlichkeit unter /boot/ eingehangen, um Änderungen einfacher durchführen zu können.

    Heutzutage macht man vielfach keine extra /boot-Partition mehr, sondern benutzt ein einfaches Verzeichnis im Root-VZ. Diese Unterteilung war früher nötig, als das BIOS der Rechner Probleme mit zu großen Festplatten hatte. Da war es wichtig, daß der Kernel von einer Partition geladen werden konnte, die das BIOS erreichen konnte. Das ist heute im allgemeinen nicht mehr nötig.

    Alle Klarheiten beseitig? :)

    Da könntest Du einem Trugschluss erliegen: Du hast das Root-Verzeichnis auf der SD-Karte liegen, auf derselben Partition, der zweiten, auf der es standardmäßig sowieso eingerichtet und vom Kernel erwartet wird.

    Probiere mal, das Root-VZ auf einen USB-Stick zu packen, den zu labeln und dann diesen Parameter zu benutzen. Und lösche die Partition auf der Karte, damit der Kernel sie wirklich nicht findet!

    Ich versteh zwar nicht wofür das gut sein soll,

    Ganz einfach: wenn die Platte/Partition kaputt ist oder wenn sie wegen Platzmangels umgetopft werden muss, nimmst Du eine neue, versiehst sie mit demselben Label, und musst Dich nicht im UUID oder Devices kümmern.

    Zitat

    aber soweit ich weiß kann man das auch in /etc/fstab festlegen :huh:

    Ja, aber ich rede jetzt von der Option, die man bei Linux dem Kernel direkt beim Booten mitgeben kann, z.B. in GRUB.

    Hallo!

    Diese Option fehlt leider in Raspbian bisher. Gibt es eigentlich etwas Neues in dieser Angelegenheit? Vor einigen Wochen habe ich etwas darüber gelesen, daß das in Arbeit sei. (Ich weiß aber nicht mehr wo.) Wäre schön, wenn diese Option benutzt werden könnte, das würde einiges vereinfachen.

    Hallo!

    Ich muss das alte Thema noch mal aufwärmen.


    Wie kann ich nun auch Faxe senden ?

    Hast Du das inzwischen hinbekommen?

    Ich muss in einem Büro das vorhandene Faxgerät durch ein virtuellen ersetzen, und ein Pi mit einem Fax-Modem wäre unschlagbar, was den Preis, den Stromverbrauch und die Netzwerkfähigkeit angeht. Mit Hylafax und den verschiedenen Clients unter Windows und Linux habe ich außerdem nur gute Erfahrungen gemacht, so daß ich diese Lösung natürlich bevorzugen würde.

    Kannst Du (oder jemand anderes) mir dazu etwas sagen? Funktioniert das mit diesem USB-Modem?

    dbv:
    Ein Fax hat gegenüber einer e-mail auch im 21. Jahrhundert immer noch den Vorteil der gesetzlich geregelten Rechtssicherheit, wenn es um den Nachweis des Sendens geht. Es gibt sogar bestimmte Geschäftsbereiche, in denen e-mail eher zum Nachteil des Sendenden gereichen, z.B. in juristischen Kreisen.


    Das hat also eigentlich nix mit Linux zu tun sondern mit der Art und Weise wie der RaspberryPI bootet -> in herkömmlichen Rechnern sorgt ein BIOS dafür die Devices usw zu managen, aber ein RaspberryPI hat kein BIOS sondern da übernimmt die GPU den Startvorgang (laden des Kernels usw). Deshalb wird auch unbedingt eine SD Karte mit mindestens der 32MB grossen boot Partition benötigt damit der RPI startet, sobald das erledigt ist kann aber das System auch von einem USB-Stick/HDD geladen werden o.ä....

    Aha. Die Grafikeinheit übernimmt also den Startvorgang. Interessant. Ich hatte mich schon gefragt, wieso das Raspian nicht von einer ext2 starten kann, wie jedes andere Linux auch.

    Wobei sich da für mich sofort die nächste Frage anschließt: wieso haben die Entwickler des Pi sich entschlossen, in die GPU die Unterstützung eines mit Patenten behafteten Dateisystems eines kleinen unbedeutenden Software-Unternehmens aus Redmond/USA zu implementieren, und nicht ein quelloffenes und patentfreies System wie das z.B. ext2 Dateisystem? Wäre m.M.n. die bessere Wahl gewesen.

    Durch Zufall habe ich die Lösung gefunden: ich wollte mit gparted die Größe der Partitionen der Karte etwas verändern, als mir das Programm sagte, daß die erste Partition eine ungültige Clustergröße verwendet. Ich habe daraufhin die boot-Partition neu formatiert (nachdem ich die Dateien gesichert hatte!), und dieses mal als fat16 angelegt. Zuvor war sie als fat32 formatiert.

    Seit dem tritt dieser Fehler nicht mehr auf, und der Pi bootet wieder innerhalb von ca 30 Sekunden ohne Aussetzer.

    Ja, schon irgendwie klar. Aber ucf hat nur bei diesem einem Paket php5-common gemeckert. Andere Pakete, die auch von mir veränderte Konfigurationsdateien benutzen, wurden nicht angemeckert. Das fand ich sehr seltsam.

    Doch: php5 war installiert, das brauche ich ja. Aber ich glaube, der Fehler kam vom Paket "ucf". Das habe deinstalliert, dann konnte ich auch das Paket "php5-common" wieder installieren. Verstehe nur nicht, wieso "ucf" einen Fehler verursachen kann, der die Installation von "php5-common" verhindert, obwohl es doch keine Abhängigkeiten zwischen den Paketen gibt.