Posts by Assarbad

    Also die Regeln der Firewall kannst du ja statt an IPs auch an den Schnittstellen festmachen. So sollte sich das durchaus machen lassen.


    Ich verstehe jetzt aber eine Sache noch nicht. Oder besser gesagt, vielleicht kannst du das nochmal klarstellen.

    Grob gesagt möchte ich das ich in die eine Schnittstelle (eth1) einen z.B. Laptop, SmartTV usw. per LAN anschließen kann, in die weitere Schnittstelle (eth0) wird dann das LAN Kabel, was sonst direkt an das Gerät geht, angeschlossen.

    Okay, hier sollten wir also vielleicht mal eine Art Begriffstrennung vereinbaren. Verstehe ich dich richtig, daß an eth1 beispielsweise ein Switch oder ein anderes Gerät im Intranet angeschlossen werden soll und eth0 quasi die Verbindung ins Internet (also der Uplink) sein soll?


    Dann hättest du meinem Verständnis nach mit meinem obigen Beispiel und deiner bereits laufenden Lösung mit dem dhcpd schon den überwiegenden Weg hinter dir.

    Wichtig ist das es dabei möglichst nicht an das eine Netzwerk gekoppelt sein soll, sondern flexibel auch an anderen Orten (Netzwerken) ohne groß Problemen benutzt werden kann.

    Mit Netzwerk meinst du jetzt einfach nur das Subnetz, korrekt? Das wird wohl eher nicht gehen. Denn du mußt deinen dhcpd schon auf einen Adreßbereich festlegen. Also wenn wir mal folgenden Aufbau annehmen:


    Code
                                                  Intranet | Internet
    [Laptop]-----------\                                   |
                        \                                  |
    [Smart-TV]--------------[Billigswitch]-------[RPi(eth1)|(eth0)]------[Dein DSL-Router]

    oder auch alternativ (Weglassung des Billigswitches in deinem internen Netzwerk):

    Code
                     Intranet | Internet
    [Smart-TV]------[RPi(eth1)|(eth0)]------[Dein DSL-Router]

    ... dann mußt du zwangsläufig jenem Subnetz welches über eth1 geroutet wird einen bestimmten Adreßbereich zuweisen und diesen über den dhcpd bedienen. Die Schnittstelle eth0 ist zwar defacto auch in deinem Heimnetz (also von deinem DSL-Router oder Kabelmodem gesehen), aber einem anderen Subnetz. Das ist eigentlich auch die einzige Bedingung, daß das Subnetz auf der eth1- und der eth0-Seite sich unterscheiden. Zumindest würde es komplizierter, wenn der RPi vom DSL-Router an eth0 eine IP zugewiesen bekommt, die im Subnetz liegt welches der RPi selbst über eth1 aufspannt. Möglich sollte aber sogar das sein.


    Kurzum, für alle Geräte die direkt oder indirekt (über einen Switch) am eth1 deines RPi hängen, übernimmt der RPi im Prinzip die Rolle welche im Heimnetz normalerweise dem DSL-Router zukommt. Dafür mußt du schon ein Subnetz auf der eth1-Seite festlegen. Auf der eth0-Seite wärst du prinzipiell nicht festgelegt, hast aber dennoch das Problem, daß du nur entweder einen DHCP-Client laufenlassen kannst oder eben eine feste Adresse vorab festlegst um zum Uplink (also bspw. deinem DSL-Router) zu verbinden. Man könnte nun ggf. über Jumper an der GPIO-Leiste oder ähnliche Methoden eine gewisse Flexibilität einbauen die auch ohne Login auf dem RPi verfügbar ist.


    Nur um es nochmal klarzustellen. Je nach Uplink-Geschwindigkeit, aber auch nach der Geschwindigkeit die du eth1-seitig als Durchsatz erreichen möchtest, dürfte der RPi aufgrund seiner recht langsamen eingebauten Ethernetschnittstelle (100 Mbps) nicht unbedingt das geeignetste Gerät für dein Projekt sein. Es ist also durchaus prinzipiell machbar, erfüllt aber möglicherweise am Ende nicht alle deine Anforderungen. Aufgrund der USB-Beschränkungen dürftest du auch bei Benutzung einer Gigabit-"Karte" auf Datenraten von nicht viel mehr als 300 Mbps kommen.


    Für Spielereien wie diese, sollte man lieber eine Hardware benutzen die den Anforderungen von 1 Gbps gewachsen ist. Also bspw. einen Asus RT-N66U oder Nachfolgemodelle. Wenn es aber um geringen Platzbedarf geht und die obigen Einschränkungen nicht stören, wäre ein Carambola 2 dem RPi für den gewünschten Einsatzzweck noch immer überlegen. Dort hättest du auch gleich zwei Ethernetports eingebaut, wenngleich auch diese auf 100 Mbps beschränkt sind. WiFi ist auch drauf. Ansonsten kannst du dich auf dem OpenWRT-Wiki nach geeigneten Geräten umschauen. Wie geschrieben, wenn die Geschwindigkeitsbegrenzung nicht stört, kannst du das allemal mit dem RPi verwirklichen. Und wenn es nur ums Lernen geht, sowieso.


    Das Prinzip vom Yoggie (Yoggie Open Firewall SOHO) war noch schnuckeliger, weil sich der Yoggie am jeweiligen Gerät als USB-Ethernetadapter angemeldet hat (leider auch 100 Mbps) und dann aller Netzverkehr über den Yoggie geleitet wurde (Dank Routingtabelle die durch den dhcpd auf dem Yoggie entsprechend gesetzt war), ohne daß das Gerät an welches man den Yoggie steckte irgendeine Änderung seiner Netzwerkkonfiguration durchführen mußte. Also eine Hardwarefirewall (die Yoggies wurden vom USB-Port gespeist) welche ohne eigene Ethernetports auskam. Die Hardware der Yoggies war meines Wissens mit der ersten Generation der Carambolas vergleichbar.

    rpi444 statt `iptables -nvxL` kann man auch `iptables-save` (gern auch mit `-c`) nehmen. Persönlich finde ich das sogar übersichtlicher, aber ich weiß daß andere das nicht immer so sehen. Aber als ich es das erste Mal benutzt hatte, schien es mir deutlich angenehmer als die Alternative, zumal ich so auch gleich die NAT-Tabelle zu sehen bekomme, für die man bei der von dir gezeigten Methode noch `-t nat` anfügen muß (und dann aber ausschließlich die NAT-Tabelle sieht).

    Sollte doch vom Prinzip her mit einer beliebigen LED funktionieren, solange der Bereich bekannt ist in dem die Spannung ausreicht um ein Leuchten zu erzeugen, oder?


    Bei ebay.com und ebay.co.uk habe ich die LED im Viererpack mit tierisch hohen Versandkosten gesehen. Bei Banggood haben sie sie schonmal nicht.

    Also, paß uff. Habe nochmal nachgeschaut, allerdings habe ich nur die von mir damals verfaßte Doku zur Hand und nicht die eigentlichen Konfigurationsdateien und Skripte, denn die sind der Zeit zum Opfer gefallen ;)


    Bei uns hatten wir das sogar so gelöst, daß die Clients welche auf das entfernte Netz zugreifen können sollten eben einfach die Route zu dem entfernten Subnetz über besagten von mir eingerichteten Router laufen ließen. Das ist sozusagen eine Untermenge dessen was du willst.


    Also nehmen wir mal ganz keck an, daß dein eigenes Subnetz in dem irgendein DHCP-Server die IPs verteilt 192.168.1.1/24 ist. Nehmen wir weiters an, daß alles was nicht aus diesem Subnetz kommt oder in dieses Subnetz geht über deinen VPN-Tunnel gehen soll.


    Das Skript hatte ich also als Hookskript seitens OpenVPN-Client (in deinem Fall der RPi) an jener einzigen Schnittstelle zu laufen die unser Gateway damals hatte (wie schon geschrieben, eine Schnittstelle sollte auch für dein Szenario reichen).


    Die Regeln stimmen übrigens vermutlich so noch nicht für deinen Zweck. Ich warte da mal lieber nochmal auf deine Beschreibung. Bei dir könnte es nicht allein aufs Maskieren hinauslaufen.


    Einerlei, die obigen Regeln kann man für alle (gewünschten) lokalen Schnittstellen laufenlassen, da die Regeln ja nicht schnittstellenspezifisch sind, sondern subnetzspezifisch. Sprich: sie dienen Dazu Pakete aus dem Intranet für's Internet zu maskieren und umgekehrt.


    Das obige Skript hatte ich als /etc/network/vpn-fw-rules abgelegt und aus den Unterordnern /etc/network/if-down.d und /etc/network/if-up.d verlinkt (Symlink) um sie jeweils auszuführen. Alternativ (man interfaces) kann man natürlich auch den Aufruf des Skripts auf die entsprechende up/down-Zeile in der /etc/network/interfaces (nochmal siehe Handbuch!) setzen, falls man statt allen Schnittstellen (außer Loopback) speziellere Anforderungen hat.

    Also alles was du aufsetzen mußt ist lokal ein Router (laut deinem Plan ist das dann dein RPi) und deine Geräte müssen halt so konfiguriert sein, daß sie ausschließlich mit diesem Router kommunizieren. Wohin - bzw. über welche Verbindung (also bspw. ein VPN mit dem jeweiligen tun-Gerät) - der Router die Pakete schickt entscheidet danach allein der Router. Klingt wie ein nettes (und vor allem recht simples) Projekt für einen RPi. Vielleicht kannst du mit den hier gewonnenen Informationen ja ein Tutorial draus stricken.


    Kannst du das nochmal etwas detaillierter beschreiben, bitte?


    Ich hab sowas schonmal vor Jahren in der Firma aufgesetzt um mit einer Partnerfirma zu verbinden. Da hatten wir dann auch DNS-Abfragen und allen Pipapo in beide Richtungen. Ich schau mal nach wie ich das damals gemacht habe. So wie ich das sehe ist DNS für dich ja irrelevant (also bei uns ging es ja um die Namensauflösung innerhalb der jeweiligen Intranetze), weshalb du eigentlich nur eine Handvoll iptables-Regeln in den Hookskripten unter /etc/network brauchst und eben eine aufgebaute OpenVPN-Verbindung.


    Ach ja nochmal kurz zu deiner Frage mit den Netzwerkschnittstellen. Im Prinzip brauchst du nichtmal zwei Schnittstellen, denn du willst ja nicht sniffen und gleichzeitig durchleiten. Wenn du eine VPN-Verbindung aufbaust, laufen die Daten darin ja über eine tun-Schnittstelle. Solange der Router bspw. weiß daß "interner" Verkehr immer von einem bestimmten Subnetz stammt, reicht dies als Unterscheidungsmerkmal. Mehrere Schnittstellen würden nur noch was bringen mit Bonding oder so. Aber die Schnittstelle des RPi ist sowieso schon nicht die schnellste, also erwarte mal nicht allzuviel Durchsatz.

    Also nochmal: Änderung des Ports ist keine Sicherheitsmaßnahme, sondern eine Verschleierungsmaßnahme. Diese Maßnahme dennoch anzuwenden bleibt dir natürlich unbenommen! Aber allein hier schon von einer Absicherung zu sprechen führt komplett in die Irre. Das mag auf den ersten Blick seltsam erscheinen, aber nur weil ihr die Versuche von Logins im Log seht, heißt das ja nicht, daß das System unsicher ist. Es heißt nur, daß da jemand versucht entweder den Rechner oder dessen Netz auf Lücken abzuklopfen. Ob da Lücken sind, entscheidet sich nicht nach dem Port an dem ein Dienst läuft. Und wenn euch die Logeinträge stören, könnt ihr wahlweise rsyslogd instruieren die ins Nirwana zu schicken (würde ich zwar nicht empfehlen, aber wenn's einen so richtig juckt, ist das eine Methode) oder über fail2ban oder meinen oben beschriebenen Ansatz die Anzahl der Versuche die ein Angreifer bei euch hat so stark zu begrenzen, daß es euch eben nicht mehr juckt.


    Es gibt übrigens noch einen netteren Weg um Verbindungen zu einem SSH-Daemon zu debuggen als mit tcpdump. Also, nehmen wir mal an du hast dich auf deinen RPi im internen Netz verbunden. Jetzt richtest du deinen Router so ein, daß der Port 1022 des RPi (weiterlesen nicht vergessen!) auf einen Port der externen Adresse umgeleitet wird, auf den du ihn haben willst. Ist mir ja wumpe ob du nun den Port umbiegst. Wichtig ist, daß du verstehst daß es sich dabei um keine Sicherheitsmaßnahme handeln würde.


    Jetzt zum Port 1022. Du läßt deinen SSH-Server so laufen wie er es schon tut (Port 22) und startest eine zweite Instanz (als Root!), aber im Vordergrund und am Port 1022.


    Code
    $(which sshd) -Ddp 1022

    Der Befehl nimmt an, daß du Bash oder eine kompatible Shell einsetzt welche `$()` versteht. Was tut der Befehl nun? `which sshd` ermittelt den absoluten Pfad zu sshd ... und mit `$(which sshd)` fügst du genau diesen ermittelten Pfad als erstes in deine Kommandozeile ein. Du kannst es stattdessen je nach Distribution auch mit /usr/sbin/sshd versuchen. Kann klappen, muß aber nicht. Warum brauchen wir das? Nunja, sshd verweigert bei Aufruf ohne absoluten Pfad in manchen Konfigurationen den Dienst.


    Dann `-D` welches dafür steht daß sich sshd nicht als Daemon (Hintergrundprozeß) in den Hintergrund verabschiedet. `-d` um Debugausgaben zu erhalten. Da kannst du bis zu drei kleine d aneinanderreihen, also bspw. `-ddd` und zuguterletzt `-p 1022` welches sshd anweist an dem besagten Port zu lauschen.


    Läuft das Teil und ist dein Router entsprechend konfiguriert den Port weiterzuleiten, schaust du dir einfach die Ausgaben des sshd auf dem Terminal an, denn da werden nun jede Menge Ausgaben auftauchen, sobald sich ein Client von extern verbindet.


    Achtung: bei dieser Methode beendet sich der Daemon nachdem die Verbindung getrennt wurde. Der muß also manuell (z.B. über deine Terminalverbindung im internen Netz) wieder gestartet werden um noch einen Versuch zu unternehmen. Usw. usf. ... man kann sich mit der Methode also bei unbedachter Anwendung aussperren!


    Diese Methode kann man im übrigen auch hervorragend bei allerlei anderen Problemen mit sshd einsetzen. Habe damit schon die exotischsten Probleme in kurzer Zeit gelöst. Einzige Vorbedingungen sind 1.) ein alternativer Weg sich auf den Server einzuloggen um sshd zu starten (dazu kann man einfach den sshd auf dem Standardport laufenlassen) und 2.) falls man den Standardport weiter benutzt, ein anderen Port als 22 der zum Start der zweiten sshd-Instanz benutzt werden kann.

    Ach ja eine Bemerkung noch. IP Sets können auch andere IP Sets enthalten. Da ein einzelnes Set nur spezifisch IPv4 oder IPv6 Adressen aufnehmen kann (je nach Typ gibt es auch Sets ohne Adressen, bspw. nur mit Ports oder eben mit anderen Sets) hilft diese Methode. So verstecken sich hinter den Namen bei mir oben eigentlich zwei Sets (eines IPv4 und eines IPv6) die in dem o.g. Set zusammengefaßt sind. Die IP-Set-Erweiterung ist clever genug um zu wissen, daß wenn ich eine Adresse einem Set hinzufügen will welches aus IPv4 und IPv6-Sets besteht, es bitte die IP-Adresse je nach Art ins richtige enthaltene Set schiebt.


    Sehr mächtige Funktion, wie ich finde. Leider nicht sonderlich gut dokumentiert.

    Ändere den Port (Zugriffsport "von aussen" unbedingt auf einen andere Port (5-stellig ist gut).

    Pardon, aber das ist kompletter Unsinn. Vor allem die Behauptung man solle es auf einen fünfstelligen Port setzen. Alle Ports unter 1024 sind privilegierte Ports und können ausschließlich vom Superuser belegt werden (bzw. es benötigt der entsprechende Prozeß mindestens CAP_NET_BIND_SERVICE. Bei Ports unterhalb von 1024 kann man sich also zumindest sicher sein, daß ein privilegierter Benutzer (vulgo: Admin) den Dienst anbietet und nicht jeder dahergelaufene Benutzer der mal Bock hat sich dazwischenzuschalten. Wenn man dann noch Benutzer hat die darauf trainiert werden Warnungen zu den öffentlichen Schlüsseln zu ignorieren, ist das Desaster vollkommen.


    Generell ist von einem Umbiegen der Standardports in etwa soviel zu halten wie vom Blockieren oder Fallenlassen von ICMP-Paketen (bspw. Ping). Ein Angreifer kann auch beim Fallenlassen von ICMP-Paketen herausbekommen, daß es den Host gibt, spätestens indem der eine Dienst den der Rechner bspw. bereitstellt ganz regulär auf Anfragen antwortet. Wo ist der Sicherheit gedient wenn ich mich als Admin der Möglichkeiten von ICMP beraube - weil ich irgendwann vom Ping of Death auf Windows 95 gehört habe - aber gleichzeitig öffentliche Dienste auf dem Server anbiete? Ähnliches gilt bei SSH, auch wenn sich die Portangabe relativ komfortabel via ~/.ssh/config festlegen läßt.


    Das Stichwort hierbei ist Security Through Obscurity. Verstecken macht nichts sicherer. Es macht es nur zeitaufwendiger für irgendwelche automatisierten Prozesse deinen Host auf Dienste abzuklopfen. Aber ich hab noch nie ein Skript gesehen, welches sich beschwert hätte, weil es eine sehr langweilige Aufgabe erledigen muß.


    Allerdings ist die Idee zumindest einen Test wert, weil vielleicht der Provider Port 22 pauschal sperrt. Dann könnte ein Umbiegen des Ports angezeigt sein, aber bitte auf einen privilegierten Port. 1022 ist übrigens kleiner als 1024 und leicht zu merken ;)


    Am effektivsten ist es insgesamt in der sshd_config einzutragen daß 1. Root sich nicht einloggen darf (dann lieber einen sudoer einloggen lassen) und daß 2. nur Schlüssel und keine Paßworte akzeptiert werden.


    Netfilter kann und sollte man schon konfigurieren, ggf. delegiert man das an eine Lösung wie fail2ban. Diese Software versteht mittlerweile scheinbar auch IP Sets und ist damit technisch auf dem Stand der Zeit. IP Sets sind deutlich flexibler zu handhaben als einzelne Regeln oder Regeln die sich auf Subnetze beziehen. Das war gerade auch früher ein Problem, weil irgendwann Netfilter aufgab und keine neuen Regeln mehr annahm.


    Will man es händisch einrichten bietet sich das Recent-Modul an, welchem man auftragen kann eine Liste mit IPs innerhalb eines bestimmten Zeitintervalls vorzuhalten. Da die Kapazität und Flexibilität dieser Methode begrenzt ist, sollte man das nur als Eintrittspunkt in die Teergrube einsetzen um die Angreifer schön auszubremsen (denn die probieren vor allem massenweise Benutzernamen und Paßworte). Das kann man dann mit einem IP Set kombinieren, welches man ganz bequem per IP-Filter-Regel befüllen und aktualisieren kann. Da man den Einträgen eines IP Sets einen Timeout mitgeben kann, können Sperreinträge automatisch nach einer gewissen Zeit wieder entfernt werden. Man sollte aber vorzugsweise immer wieder den Eintrag im IP Set aktualisieren um hartnäckige Angreifer schön auf der Liste zu halten.


    Kombiniert man das noch mit einer Liste von IP-Blöcken nach Herkunftsland und weiß, daß man bspw. nie aus Bahrain zu seinem Server verbinden wird, kann man ganze Regionen pauschal vom SSH-Zugang ausschließen.


    Persönlich habe ich zwei Teehgruben basierend auf einer Unterschiedlichen Anzahl von Verbindungsversuchen. Hier mal nur für IPv4 (iptables-save-Notation):


    Code
    -A SSH -j SSHCONN
    -4 -A SSH -p tcp -m conntrack --ctstate NEW -m recent --name fastpit --set
    -4 -A SSH -p tcp -m conntrack --ctstate NEW -m recent --name slowpit --set
    -4 -A SSH -p tcp -m conntrack --ctstate NEW -m recent --name fastpit --update --seconds 120 --hitcount 3 -j SET --add-set ssh_dynblock src --exist
    -4 -A SSH -p tcp -m conntrack --ctstate NEW -m recent --name slowpit --update --seconds 600 --hitcount 5 -j SET --add-set ssh_dynblock src --exist
    -4 -A SSH -p tcp -m conntrack --ctstate NEW -m recent --name fastpit --update --seconds 120 --hitcount 3 -j REJECT --reject-with tcp-reset
    -4 -A SSH -p tcp -m conntrack --ctstate NEW -m recent --name slowpit --update --seconds 600 --hitcount 5 -j REJECT --reject-with tcp-reset

    So, da hat man nun also fastpit, welche innerhalb von 120 Sekunden nicht mehr als 3 Verbindungsversuche (nicht zu verwechseln mit Paketen an sich) zuläßt. Sowie slowpit, welche innerhalb von 10 Minuten nicht mehr als 5 Verbidungsversuche zuläßt. Sollte einer der Werte überschritten sein, landet der jeweilige "Angreifer" (oder auch ich selbst) auf der schwarzen Liste. Da ich die Regeln kenne, kann ich selbst natürlich einfach warten bis ich wieder ausgelistet bin und dann nochmal von neuem versuchen. In der Praxis passiert das aber nicht (warum? weiterlesen!).


    So, man sieht vielleicht, daß ich ganz oben erstmal in die Chain SSHCONN springe. Und die sieht so aus.

    Hier haben wir also folgendes:


    1. Eine Regel welche die IP dem Set hinzufügt, sofern die IP schon drin war. Klingt seltsam, ergibt aber zusammen mit Timeouts Sinn, weil so ein Eintrag einer IP quasi aufgefrischt wird. Die darauffolgende Regel läßt Verbindungsversuche von vertrauenswürdigen IPs direkt durch (bei mir läuft ein cron-Job der die IPs basierend auf DynDNS immer aktuell hält).

    2. Pakete bereits eingeloggter Benutzer werden immer durchgelassen. Ob ein Benutzer erfolgreich eingeloggt ist, läßt sich bequem innerhalb von PAM ermitteln und Dank des PAM-Moduls pam_exec.so kann ich ein kleines Script abfeuern welche die Herkunfts-IP dem Set hinzufügt.

    3. Schon weiter oben hat man gesehen, daß jene die in der fastpit bzw. slowpit landen auch in dem Set für dynamische Blockierung landen. Das ist sozusagen nur das Langzeitgedächtnis meiner Teergruben, wiederum mit Timeouts versehen und Dank der Regeln werden die Einträge hartnäckiger Benutzer immer aufgefrischt.

    4. Bereits verbundene Clients werden durchgelassen. Haben wir bereits einen erfolgreichen Verbindungsaufbau gehabt, kann ich mir weitere Regeln sparen.

    5. IPs aus allen Ländern außer einer von mir vorgegebenen Liste (wichtig, falls ihr auch mal VPN benutzt), werden pauschal nicht durchgelassen.

    6. Rücksprung zum Aufrufer.


    Die Methode ist verdammt effektiv und vor allem sehr ressourcenschonend für meine Server.


    Eine Alternativmethode die man einsetzen könnte um allen Quark mit DynDNS komplett zu umgehen wäre, daß man - sofern man ohnehin bspw. einen Virtual Private Server (VPS) hat - einfach einen permanenten Tunnel zu dem aufrecht erhält und sich über diesen Tunnel von dem VPS zurück ins heimische Netz hangelt. Die Methode habe ich im Februar auf meinem Blog erläutert (Englisch): https://blog.assarbad.net/20170223/ssh-reverse-tunnel/ ... ich setze sie aber schon seit vielen Jahren erfolgreich ein. Eigentlich war nur die Tatsache, daß ich eine systemd-Unit brauchte Grund einen Blogbeitrag darüber zu verfassen.


    PS: und ja, ich hab die ipfilter-Regeln tatsächlich alle selber geschrieben und mir auch selber ausgedacht.

    Moin,


    der RPi zeigt in der oberen rechten Ecke unter bestimmten Umständen (Spannung zu niedrig) einen gelben Blitz. Jetzt habe ich mich gefragt ob das quasi von der Grafikkarte direkt in de Puffer geschrieben wird und daher keine Software davon etwas mitbekommt, oder ob man 1.) den Fakt, daß zu wenig Spannung vorhanden ist und 2.) wieviel zu wenig Spannung vorhanden ist auslesen kann.


    Herzlichen Dank.

    Falls du bereits Ahnung von Linux selbst hast, kannst du als Root mit visudo die Datei /etc/sudoers (einfach "visudo" ausführen) bearbeiten, oder die Dateien welche sich unter /etc/sudoers.d/ befinden ("visudo -f <Pfad-zur-Datei>"). Die Syntax ist jeweils die gleiche ("man sudoers"). Meines Wissens nach packt Raspbian da eine Datei unter /etc/sudoers.d/ und dort wird unter anderem NOPASSWD gesetzt. Das und den darauffolgenden Doppelpunkt müßtest du händisch entfernen, falls du nicht raspi-config benutzen willst.

    Code
    www-data ALL=(ALL) NOPASSWD: /usr/bin/python /home/pi/Desktop/gpio/relayschaltung.py * *

    Ich bin verwirrt. Erstens ist mir neu, daß man dort eine Befehlszeile angeben kann wie bspw.:

    Code
    /usr/bin/python /home/pi/Desktop/gpio/relayschaltung.py * *

    ... oder Wildcards.


    Du erlaubst hier also das Programm /usr/bin/python, sowie dein Programm /home/pi/Desktop/gpio/relayschaltung.py ... die Wildcards werden vermutlich ignoriert.


    Und zweitens verstehe ich nicht ganz wozu man pauschal dem Benutzer www-data das Recht gibt alle besagten Programm, im speziellen Python, als jeder beliebige andere Benutzer (statt bspw. nur root) auszuführen. Abgesehen davon kann man auch eine Gruppe und nicht nur einen Benutzer zuweisen. Also könntest du auf einem Raspbian dem Benutzer www-data erlauben als www-data und mit der Gruppe gpio eine bestimmte Datei auszuführen.


    Bemüh doch mal "man sudoers", da steht es sehr detailliert drin. Und Dank EBNF ist es auch alles sehr eindeutig.

    Kann man nun unter raspberry bzw. linux keinen mysql-server mehr installieren? muss man sich nun zwangsweise mit mariadb abfinden?

    angeblich soll ja alles zu 99,99% laufen... ich lass mich gerne überraschen.

    Und das schneller und effizienter. Das geht mal überhaupt nicht. Lieber den MySQL-Server installieren, denn der wird ja von Oracle liebevoll weiterentwickelt. Installier dir lieber nicht dieses Teufelswerk MariaDB von Monty Widenius, dem Erfinder und ursprünglichen Kopf hinter MySQL. Oh, warte ... :P


    Oh ja, Monty hatte seine erste Datenbank nach seiner Tochter My (gesprochen in etwa Mü und nicht Mei) benannt und die Fortentwicklung MariaDB. Nun rate mal woher der Namensteil Maria rührt? ;)

    es dürfte sich um mariadb-server handeln oder?

    Der Server zu dem du dich verbindest? Klar. Hat doch auch keiner bezweifelt. Nur scheinst du mißzuverstehen, was hier der Client und der Server ist. Wenn du die MariaDB-Clientbibliotheken und -programme installierst, gibt es auch einen Kommandozeilen-Client namens mysql. Das ist auch der Grund warum man nicht gleichzeitig mysql-server und mariadb-server, bzw. mysql und mariadb als Cient - in der jeweils gleichen Version - installieren kann.


    Nur um dir ein anderes Beispiel zu geben. Netcat wird auch von mehreren Paketen angeboten. Aufgerufen werden die - drei, wenn ich es richtig gesehen habe - und die alle rufst du im Endeffekt über nc in der Shell auf.


    Einerlei, der Mechanismus dahinter ist üblicherweise https://wiki.debian.org/DebianAlternatives

    von früher kannte ich noch das ich auf der Konsole eine Maske bekam mit der Aufforderung eines Root Passwortes...

    das kam auch nicht


    Ohne Benutzer hättest du kein Terminal (oder wie du es nennst: Konsole). Da wird wohl ganz einfach ein entsprechender Eintrag in /etc/sudoers oder eine entsprechende Datei mit Eintrag in /etc/sudoers.d/ existieren. Und die besagt dann bspw. daß du bestimmte (oder alle) Programme als bestimmter (oder alle) Benutzer auf bestimmten (oder allen) Rechnern ausführen darfst. Toll was es so gibt, hmm? Einfach mal "man sudoers" (ohne die Anführungsstriche) eingeben und durchlesen.

    Kann man nun unter raspberry bzw. linux keinen mysql-server mehr installieren? muss man sich nun zwangsweise mit mariadb abfinden?

    angeblich soll ja alles zu 99,99% laufen... ich lass mich gerne überraschen.

    anscheinend scheint das 0,001% dann schonmal der Unterscheid zu sein das es wohl keinen root-Account mehr gibt oder man sich nun nicht mehr über phpmyadmin via root anmelden kann


    Was kann ich machen das ich meine Datenbank wieder importieren kann?

    Also, phpMyAdmin hat mal nix mit dem Rootbenutzer des Systems zu tun. Man kann das zwar prinzipiell so konfigurieren, daß der sich einloggen kann - sollte man aber nicht.


    Und nein, mit 99,99%iger Sicherheit hat die fehlende Abfrage des Paßworts absolut nichts mit der Installation von MariaDB statt MySQL (egal ob Client oder Server) zu tun. Eher schon, falls da immer eine Abfrage kam, findest du eine Datei Namens .sudo_as_admin_successful in deinem Homeverzeichnis, die im Prinzip dazu dient dich nicht ständig, aber hinreichend oft, mit den Abfragen zu nerven.


    Datenbankdumps kannst du bspw. bequem mit dem Client installieren den du oben bereits schonmal ausgetestet hast.

    Vielleicht möchtest du aber direkt die Chance nutzen und auf ein besseres (in der der OSS Community deutlich akzeptierteres) RDBMS wie PostgreSQL wechseln :)

    Was genau ist an MySQL weniger akzeptiert? Meines Wissens nach setzte (ob sie es noch tun weiß ich nicht) sogar Facebook MySQL ein und zwar eine modifizierte Variante mit Unterstützung für Sharding.


    Abgesehen davon gibt es nach wie vor Software die leider keine Abstraktionsbibliotheken ala SQLAlchemy benutzen, sondern direkt Queries and das Backend schicken. Und dann wird's doof, weil SQL-Dialekte eben ganz interessante und zum Teil subtile Unterschiede haben.


    Ohne Frage, PostgreSQL ist schon ein tolles Projekt und soll gern eingesetzt werden, wenn die Auswahlmöglichkeit besteht. Nur sie besteht halt nicht immer.

    Leider spann die Forensoftware beim Zitieren. Also Pardon, daß es nicht so schick aussieht wie es sollte.


    Quote

    Es geht hier nicht um pyenv sondern um PATH der Shell

    Das war schon klar. Wobei ja das besagte "Wrapper-Skript" mit absolutem Pfad aufgerufen werden kann und daher selbst PATH modifizieren und exportieren kann, bevor es speedtest-cli ausführt.


    Quote

    das nicht "gefunden wurde" kann es auch nichts aus dem pyenv laden.

    Es gilt zu unterscheiden: Python Module/Paket und Python-Script!

    Ich denke du hast mißverstanden worauf ich hinauswollte. Also nehmen wir mal ganz keck an, daß pyenv lokal im Homeverzeichnis installiert ist (im Standardpfad ~/.pyenv). Nun kannst du pyenv bekanntlich dadurch aktivieren, daß du die Ausgabe von "pyenv init" und "pyenv virtualenv-init" in Bash sourcst. Genau das meinte ich. Grob gesagt (in Bash), gefolgt dann von der Auswahl der jeweiligen Pythonversion:


    Code
    if [[ -x "$HOME/.pyenv/bin/pyenv" ]]; then
        export PATH="$HOME/.pyenv/bin:$PATH"
        eval "$(pyenv init -)"
        eval "$(pyenv virtualenv-init -)"
    fi
    Quote

    Es ist davon auszugehen dass der TE nichts an den Umgebungsvariablen von Cron verändert hat - impliziert durch "nicht wissen wie 'command not found' zu lösen geht". Demnach gilt die Standard Einstellung: /usr/bin:/bin

    Genau, daher mein Hinweis mit /usr/local/bin ... wobei natürlich je nach Shell in Cron und je nach globalem Profil der Shell auch andere Regeln gelten könnten. Ich würde aber in jedem Fall auf Nummer sicher gehen.

    Aber ich hab ohnehin schon das Gefühl, daß wir auf's gleiche hinauswollen und den TE mittlerweile mit unserer Detaildiskussion eher verwirren ;)

    Acha, und warum nicht? :conf:

    Weil man als Superuser natürlich das System global "verschmutzt". Zugegeben, wenn das jetzt ein Rezept wäre welches mit Ansible oder Chef appliziert wird, würde ich auch mehrfach überlegen ob ich nicht lieber PIP als Superuser ausführe.


    Allerdings verstehe ich dein Gegenargument nicht, da wir ja nicht alle Details kennen (oder?). Man müßte doch erstmal mit env in der crontab eruieren, ob denn /usr/local/bin im Standardpfad liegt. Ist dies der Fall hast du allerdings unumwunden recht.


    Wahrscheinlich ist es für Bastelprojekte ohnehin wumpe. Aber da ich Linux nicht nur als Bastler einsetze, habe ich da, wie scheinbar auch Linus, andere Ansprüche.