Der Umbruch ist normal
ja, scheint mir auch so 
Posts by tuxOnTheRoad
-
-
Danke allen für die Ratschläge 💁
Nun, es lag am Kabel - wohl zu lang.
Und zudem zusammengesetzt = Adapter microHDMI-HDMI + Kabel HDMI-HDMI.
Alle bootupZeilen rollen nun ab, sowohl mit einem neuen 50cm und einem neuen 100cm Kabel microHDMI-HDMI, also direkt.Im Ablauf der Zeilen passiert auch jetzt ein kleiner Unterbruch (was mir normal erscheint), aber anschliessend gehts gleich zügig weiter.
-
Display More
tatsächlich eine Sache des Bildschirms ?
Danke für die Antwort 💁
das Signal geht weg:
Bildschirm wechselt vom Anzeigen der Startzeilen zu "HDM1 Kein Signal"
weitere Konsolen hab ich ausprobiert: gleiches Verhalten nach reboot per ssh
-
Hallo Mitlesende
raspi4B mit 64gb SDcard + ubuntu24.04server
Started und verbindet sich = im terminal via ssh erreichbar.
Doch der Bildschirm zeigt nur während den ersten 7 sec infoZeilen an,
dann wird und bleibt er schwarz.Danke für Ratschläge, wie ich verhindern kann, dass der Bildschirm sich verabschiedet.
-
als erledigt markiert ...
-
Problem gelöst, es lag wohl an den IPs.
Sowohl vom Handy wie auch vom Laptop via Handy aus gelange ich auf mein HeimLAN bzw. zum VPNserver im Raspberry hinter dem Router .
UbuntuInteressierten kann ich für die ClientKonfiguration den 2. Teil dieser Anleitung empfehlen
-
Von Ubuntu21 mit Wireguard zu piVPN auf Raspi4
Hallo Mitlesende
Habe piVPN auf Raspi4 laufen.
Mit AndroidHandy klappt der WireguardTunnel, kann via WireguardClient im Handy auf dem HeimLan so arbeiten wie zuhause.
Nun will ich das auch mit dem Laptop und Ubuntu21.
Wireguard ist in Ubuntu21 installiert.
Wie kriege ich in Ubuntu den WireguardClient hin?
Eine Möglichkeit den QRcode einzulesen habe ich im UbuntuWireguard nicht gefunden.
Danke für Hinweise
-
Lösung:
Mein Fehler war, dass ich das gui zu früh installieren wollte.
Nachdem update und upgrade vollständig durch waren, konnte ich auch gnomeGui installieren.Was allerdings weitere 3gb mit sich brachte.
Danke schön -
-
Listet diese sources auf:
cat /etc/apt/sources.list
deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian-security buster/updates main contrib non-free
# Backports are _not_ enabled by default.
# Enable them by uncommenting the following line:
# deb http://deb.debian.org/debian buster-backports main contrib non-free
deb http://deb.debian.org/debian/ buster-backports main contrib non-free
# raspi 4 needs a kernel and raspi-firmware newer than buster's
cat /etc/apt/sources.list.d/raspi.list
cat: /etc/apt/sources.list.d/raspi.list: No such file or directory
-
20210210_raspi_4_buster.img - value 'buster' invalid for APT
Hallo Mitlesende
Habe folgendes image auf einer 64gbSDXC im raspi4 8gb:
20210210_raspi_4_buster.img.xz
Quelle= https://raspi.debian.net/tested-images/
build date= 2021.02.10
release= 10 buster
family= 4
tested hw= 4gb
file= xz-compressed image 356mb 2021-02-10
Bin nun als root auf der Kommandozeile, kriege aber folgenden Fehler, wenn ich task-gnome-desktop installieren will:
value 'buster' invalid for APT: default-release not available in sources
Wie überwinde ich diese Hürde?
Danke für Tipps
chris -
Wordpress lokal / öffentlich
Hallo Mitlesende*r
Wie organisierst du das Zusammenspiel zwischen der lokalen Entwicklungsversion einer WebSite und der im Internet publizierten Endversion?
Um die Rahmenbedingungen der beiden Versionen möglichst ähnlich zu halten, laufen bei mir beide auf einem Apache mit Maria. Version 1 auf einem Raspberry4 im LAN, Version 2 auf dem gehosteten Server im Internet.
Einzig die Aufrufe unterscheiden sich:
1 host.local
2 domain.ch
Es interessiert mich, wie du das organsierst
-
ufw firewall defaults
Hallo Mitlesende
Nach dem Durcharbeiten mehrerer Tutorials zu ufw bin ich eher verunsichert.
Konkret: Braucht es grundsätzlich gar keine deny-in-Regeln, da per default sowieso alle ports nichts reinlassen? Ausser um allenfalls innerhalb einer allow-in-Regel Ausnahmen zu machen.
Sehe auch Beispiele, die zuerst den betreffenden Port ausdrücklich schliessen und erst in einem 2. Schritt festlegen, was rein darf.
Danke für Aufklärung
chris -
Du schlägst also ebenfalls vor, auf dem Laptop einen dhcp zu installieren, wenn ich dich richtig verstehe.
Der sorgt dann für den Anschluss ans gerade angesagte Netzwerk, sorgt für mein LAN und bedient somit alle meine Geräte immer gleich.
Wenns funktioniert, super - muss ich testen. -
Danke für deinen weiterführenden Tipp. Probiere das mit meinem UbuntuLaptop gerne aus. Muss dazu ein geeignetes Tutorial finden.
-
Einverstanden, jede Art des Reisens hat ihre Tücken bezüglich ITsicherheit.
Habe diesen Aspekt ausgeklammert, um das Problem einfach zu halten.
Wir reisen mit Camper, verbringen die Winter im Süden - wenn nicht gerade Corona das verhindert ...
Zu alt zum Arbeiten, zu jung zum Sterben, fürs Reisen topfit.
Ein kleiner mobileRouter bringt das Internet von der länderspezifischen SIMkarte übers Wlan in den Camper.
Da hängen wir beide uns dran, funktioniert so meistens.
Meine mobilen Geräte sind weitgehend ohne persönliche Daten, da sie eher abhanden kommen bzw. begehrt sind.
Einen kleinen Raspi dagegen sucht niemand, lässt sich gut verstecken.
Clouds bringen erheblichen traffic. Der zusätzliche Zeitaufwand ist verkraftbar, doch die zusätzlichen gigas können ins Geld gehen.
Lokal speichern und backups auf kleine Datenträger scheinen mir unterwegs am effizientesten.
Ganz wichtige Daten kann ich jederzeit auf der Syno zuhause ablegen. Wenn wir auf Reisen sind, wartet ein weiterer PI mit piVPN auf meinen Login. Ich wecke den NAS zuhause auf, lade zB die Fotos der letzten Wochen ab, fahre die Syno wieder herunter und loge mich aus.
-
Deine Vorschläge habe ich vorgemerkt:
- 1. statische IP + 2. dynamische IP zuweisen lassen, wenn Verbindung zu dhcpServer zustande kommt
- dhcpcd: fallback statische IP, wenn keine Verbindung zu dhcpServer zustande kommt
- dhcpcd5: adresse zuweisen, wenn keine Verbindung zu dhcpServer zustande kommt
Muss die pros und cons der 3 Varianten ansehen.
PI mit crossoverKabel direkt am Lap:
Dazu müsste ich dem Lap auch eine statische IP vergeben, da er nun isoliert ist.
Vor einer statischen IP für den LAP schrecke wegen der eingeschränkten Konnektivität zurück.
Lap im Wlan des mobileRouters, Raspi mit crossoverKabel direkt am Lap.
Das Wlan des mobilen Routers sollte ich ebenfalls auf 192.168.1.x einrichten können, was vermutlich geht.
Muss ich testen.
LAP am mobileRouter, ethernet oder wifi, und Raspi ebenfalls am mobileRouter, wifi (mobileRouter hat nur 1x ethernet)
Muss ich ebenfalls noch testen. Kommt dem Heimnetz am nächsten, einfach kabellos, mit weniger Durchsatz.
Wechsel vom HeimLAN ins mobile LAN geht ohne Einstellungen verändern zu müssen - wenn der mobileRouter mal analog zum HeimRouter funktioniert.
dhcp auf Lap würde doch wieder Umstellungen nach sich ziehen, dh umständlich und fehleranfällig für mich, leider.
-
Danke für die inspirierenden Vorschläge
Situation: Lap mit lokaler IP durch RouterDhcp.
PI mit statischer lokaler IP gemäss /etc/dhcpcd.conf
Vorschlag 'hostname' hat mich weitergebracht:
für Wordpress brauche ja gar nicht den ganzen PI anzusprechen, sondern bloss wordpress.
Und dies lässt sich in wp-config.php einrichten:
WP_HOME = https:// hostname.local = hostname der BusterInstallation + .local
Also wie bei ssh hostname.local
WP_SITEURL = https:// hostname.local
Diese beiden Einträge weisen auf den wordpress-root.
Liegt wp in einem Unterordner zB in /var/www/html/a/ müssen diese beiden Einträge entsprechend erweitert werden.
(Weiterführende Frage: Was wenn diese beiden Einträge unterschiedlich wären?
Kam damit allerdings nicht weiter, zB mit IP bloss für WP_SITEURL öffnete sich gar nichts.)
Im Browser führen nun diese urls zu folgenden Resultaten:
https:// hostname.local >>> lokale homepage
https:// 192.168.1.155 >>> lokale homepage
Also beide urls gleiches Resultat.
https:// hostname.local/wp-admin >>> lokaler wp-loginDialog
https:// 192.168.1.155/wp-admin >>> lokaler wp-loginDialog >>>
mit erfolgreichem Login wechselt im Browser url zu https:// hostname.local/wp-admin
Also beide urls gleiches Resultat.
https:// domain.ch funktioniert weiterhin wie gewohnt.
Somit gelange ich zu meiner lokalen WebSite unabhängig von der IP Raspberrys, dynamisch oder statisch, was mir vorher nicht klar war.
Danke für die Nachhilfe
Bezüglich statischer IP siehe nächste Antwort.
-
Eine interessante Lösung, danke. Die lokale WebSite kann ich via direkter Kabelverbindung (crossover?) vom Lap aus aufrufen, mit gleicher IP wie zuhause. Und der PI kann via Lap ins Internet.
Probier ich aus, berichte später darüber, wie es läuft.
Einen kleinen mobilen Router habe ich allerdings schon mit dabei, damit ich mit einer SIM des jeweiligen Landes kostengünstig ins Internet kann, zB. simyo in Spanien oder NOS in Portugal.
-
Ja, localhost bzw. 127.0.0.1 würden funktionieren, wenn die lokale WebSite auf dem gleichen Laptop liegen würde.
Dort möchte ich diese aber nicht, weil ich möglichst wenig Daten im Lap haben möchte. Um bei Verlust den Schaden gering zu halten. Und laufend alles in irgendeine Cloud zu schicken, bringt wohl zuviel Aufwand.
Den PI kann ich besser schützen als Laptop oder Handy.
