Mach mal nen Reboot
Never reboot a running system! zeigefinger_nach_oben.gif
Mach mal nen Reboot
Never reboot a running system! zeigefinger_nach_oben.gif
Ich.kann.so.nicht.arbeiten. ![]()
Da kommt ne Liste mit ü50 Einträgen raus...
Hatte ich zunächst glatt überlesen… ![]()
Aber nachdem nun ein Wochenende seit dem obigen Beitrag vergangen ist, wurde die Liste durch Wirken des verantwortlichen/verantwortungsbewussten Administrators inzwischen um eine Größenordnung reduziert, oder? ![]()
Gegebenenfalls interessant zum Thema UniFi (ohne, dass ich diesen Geräten jemals selbst direkt ausgesetzt gewesen wäre): "UniFi ist DRECK – Doppeltes NAT, Firewall, VPN, DMZ, WLAN"
Wirft das auch nicht gefixte Lücken für `stable` aus? Ich meine mich zu erinnern (kann gut flasch sein), dass debsecan für testing/unstable optimiert war.
debsecan --suite buster funktioniert genau so gut wie debsecan --suite sid – die Ausgaben basieren immer auf den Daten des Debian Security Bug Trackers (security-tracker.debian.org/tracker), da gibt es insoweit keinerlei "Optimierung", die nicht auf entsprechende Datenpflege zurückzuführen wäre.
(PS: Nicht nur für Minimalinstallationen, bei welchen die Abhängigkeiten von debsecan "nicht gefallen", bietet sich alternativ die Re-Implementation debcvescan an.)
(PPS: Ubuntu-Nutzer sollten hier – bei Verwendung von debsecan – unbedingt einen Blick auf ust2dsa werfen.)
Und in meiner aktuellen Hardware-Upgrade-Orgie teste ich jetzt endlich mal ein "richtiges" VoIP-Telefon im Heimnetzwerk: Grandstream GXP1615
Ich selbst bin mit meinem T-Concept CPA720 nach wie vor sehr zufrieden und verstehe so gar nicht, warum man jedes Vierteljahrhundert oder noch öfter das Telefonmodell wechseln wollte… Never change a running system! ![]()
Wie ich hier schon schrieb, meine Listen...
Eigentlich nichts daran auszusetzen. Ausschlaggebend ist im Zweifelsfall letztlich aber eh' die Ausgabe von debsecan …
Eine Woche später, also insgesamt 3 Wochen seit Aufsetzen ist immer noch nichts da....
Es ist natürlich möglich, einen manuellen Abgleich der umformatierten Ausgabe von dpkg-query -W mit der aktuellen Paketliste für Buster durchzuführen. Aber wenn der Aufruf von apt-get update; apt-get upgrade keine Warnungen/Fehlermeldungen bringt, kann höchstens die Liste der Repositories falsch sein.
(Wenn es darum geht, eine schnelle Übersicht aller Versionen eines Pakets zu bekommen, mag ein Blick auf snapshot.debian.org nützlich sein, da gibt es entsprechende Suchmöglichkeiten.)
Bedauerlicherweise scheint die Update-Frequenz der Pakete insgesamt in der letzten Zeit immer weiter abzunehmen. Ich überwache selbst mehrere Dutzend Pakete bei Debian und Ubuntu im jeweils neuesten/aktuellen Repository, und selbst prominente Pakete wie postfix hinken seit Monaten dem Upstream hinterher… ![]()
kann es sein, dass es im Netcup-Netz ein Routing-Problem bei IPv6 gibt?
Ich verwende mein eigenes Rettungssystem, aber wurde im vorliegenden Fall schon einmal probiert, das Netcup-Rettungssystem zu booten und die Tests damit zu wiederholen? Wenn da eine IPv6-Adresse vergeben/erhalten wird und es damit auch nicht funktioniert, ist das IMHO sofort eine Sache für den Support.
Abends konnte ich z.B. oft nicht gemütlich durch Reddit scrollen, weil die Bilder nicht vernünftig geladen haben.
Ideen?
Bereits mehrere Nutzer haben festgestellt, dass es derzeit wohl Probleme mit .com-Domänen gibt (wahrscheinlich ein Problem, das mit Signierung von DNSSEC-Einträgen zusammenhängt); da die Netcup-eigenen DNS-Server für diese Domänen keine gültigen Werte weiterliefern, können andere DNS-Server diese nicht (erneut) übernehmen und allenfalls Ergebnisse aus ihrem Cache zurückliefern:
[2021-08-13T10:14:16+0200] ueberall_l@desktop01:/tmp% for usual_suspect in 1.1.1.1 8.8.8.8 9.9.9.9; do dig +short -t NS thexperiments.com @${usual_suspect}; done | wc
0 0 0
[2021-08-13T10:14:36+0200] ueberall_l@desktop01:/tmp% for usual_suspect in 1.1.1.1 8.8.8.8 9.9.9.9; do dig +short -t NS example.org @${usual_suspect}; done | wc
6 6 120
Testweise einmal versuchen, einen Dummy-TXT-Eintrag im DNS hinzuzufügen oder eine andere Modifikation vornehmen, was die Signierung erneut anstoßen sollte. Bleibt das Problem bestehen – oder unabhängig davon, um es Netcup gegenüber bekannt zu machen – hilft nur eine Kontaktierung des Supports.
So, I'm new to this and half of the things are in german and I'm completely overwhelmed. I've rented a vServer and i need to upload files to it. How do I do it? can't login to Debian because I don't know the logins and the email only includes a password? and when i use root as the username and the password from the email i got it doesnt work? and half the times it isnt even typing a password? and for files, do i use ftp/ftps to upload them? what are the logins and url? help pls!!!
You'll need to familiarize yourself with the CCP and the SCP* first (the latter allows you to access the console on your server where the provided root password will work) and install vsftpd or the like afterwards in order to be able to use [S]FTP[S] in the first place. The Netcup wiki is written in German, but using machine translation (like the links shown here) might help you out.
* accessible both via the forementioned CCP and at https://www.servercontrolpanel.de/
ich wollte nur mal kurz in die Runde fragen (und vielleicht auch eine Diskussion anstoßen?) welche Filesync-Lösung ihr verwendet, um eure Daten zwischen Rechnern und Telefonen zu synchronisieren.
Ich verwende Syncthing (LDAP-spezifische Informationen siehe hier); da steht wirklich die vollautomatische, verzeichnisbasierte Synchronisation von Dateien – mit Versionierung, falls erforderlich – im Vordergrund. Soweit ich weiß, gibt es für iOS zumindest eine Beta-Version.
Vielen Dank, das habe ich gesehen. Nach einem Einlesen in NUT, insbesondere was die Verteilung von Nachrichten anbelangt, und Sichtung einiger schon jahrelang offener Issues habe ich mich dazu entschlossen, lieber gleich auf neuere Komponenten zu setzen, die ich bereits an anderer Stelle verwende/n werde, und NUT oder Einzeltreiber wie usbhid-ups außen vor zu lassen, auch wenn das Rahmenwerk weit verbreitet ist und für Viele etwas als mitgelieferte Lösung von NAS-Systemen gute Dienste leisten mag. Der resultierende Modifikations- und Wartungsaufwand für meine Anwendungszwecke erscheint mir dadurch deutlich geringer/überschaubarer.
welche USV ist dass denn? meine APC hat zum glück ARM...
Ich würde aber eher sagen, dass es nicht wirklich geht, bezüglich amd64 auf. eher amd64 auf arm64/aarch64.
Es ist eine CP1500EPFCLCD. Hatte gestern bei CyberPower angefragt, wie es mit aarch64/arm64-Unterstützung aussieht, und sie haben mir geantwortet, dass sie ihrerseits in Taiwan bei der Entwicklungsabteilung nachfragen. Wenn es klappt, ist das natürlich ein Schritt nach vorn. (Der Raspberry Pi Zero W hat nur 32 Bit, aber ggf. wird in Zukunft dann ein leistungsfähigerer, wenn auch stromhungrigerer Radxa ROCK Pi Zero damit betraut; der sollte notfalls auch stark genug für eine Emulation sein. Alternativ gäbe es wohl die Möglichkeit, einen Raspberry Pi Zero W als reinen "USB-Forwarder" einzusetzen, vgl. hier, aber wenn ich schon einen zusätzlichen SBC als "Netzwerkkartenersatz" dazunehme, dann möchte ich gerne, dass der dediziert die ganze Arbeit – Überwachungsergebnisse via MQTT weiterleiten – alleine erledigt.)
Gibt es hier stolze Besitzer eines Raspberry Pi Zero W oder anderer kleinster Raspberrys/Clones, die schon Erfahrungen damit gesammelt haben, ob man in einer chroot-Umgebung mit QEmu eine amd64-Kommandozeile hochziehen kann, ohne an RAM-Grenzen zu stoßen? Dass das mit den neuen/größeren Modellen geht, weiß ich[*]; die Frage wäre, wie man da möglichst günstig (Kosten, Strombedarf) hinkommt.
Ich hatte nämlich die Idee, die neue USV mit so einem Ding zu verheiraten, und die mitgelieferte Software – amd64-Binärprogramme, die im Wesentlichen am USB-Port lauschen – direkt mit einem MQTT-Client zu verheiraten (ein wenig wie kürzlich in der c't propagiert).
Wer ein wenig Zeit und Platz und einen kleinen Raspberry vorliegen hat, kann die grundsätzlichen Schritte beispielsweise anhand des amd64-arm-Projekts ausprobieren.
[*] Für Testzwecke kann ich auf ODROID N2+ zurückgreifen, die will ich damit aber nicht im Produktivbetrieb (sic!) belasten, da sie anderweitig eingespannt werden.
wegen dem port, würdest du eher 587 oder 465 nutzen?
#Lesenswert: Why TLS is better without STARTTLS
Chrome habe ich vollständig neu installiert sogar deswegen, schaffte auch keine Abhilfe.
Das impliziert "Version 92.0.4515.131 (Offizieller Build) (64-Bit)". Hier friert damit nichts ein (trotz einer Vielzahl von anderen offenen Tabs); allerdings sehe ich, dass die Seite (mit temporärer Erlaubnis, was die Ausführung von Scripts anbelangt) Komponenten von insgesamt vier externen Domänen lädt – wp.com und gstatic.com (erlaubt) sowie googlesyndication.com und steadfastsystem.com (hier durch NoScript gesperrt). Das könnte ein Ansatzpunkt sein: Gegebenenfalls mittels Add-on NoScript abwechselnd/sukzessiv die Script-Ausführung erlauben und sehen, ob dann eine Verzögerung eintritt. Danach einmal schauen (entweder über die Browser-Konsole und den Netzwerk-Reiter oder extern), ob im Hintergrund irgendwelche "obskuren" weiteren Server kontaktiert werden (evtl. erfolglos), da hier fehlschlagende DNS-Auflösungen ebenfalls zu einer Verzögerung führen können.
Jap, ging hauptsächlich um den Speicherplatz. Will ich mir und 2 Freunden aber nicht antun, dass man auf irgendwas klickt und dann gegebenfalls erstmal mehrere Sekunden auf eine Reaktion warten muss.
Ich verweise hier immer wieder gerne auf das VServer IOPS Comparison Sheet, welches auch reinen Cloud-Speicher miteinbezieht. ![]()
Was manuell funktioniert ist, wenn ich folgenden Befehlt ausführe:
wget -q -O - "https://<domain>/template/load/cron.php?password=xxxxxxxxx"
Scheint aber nicht automatisiert zu funktionieren.
Dieser Befehl kann auch in einen cron-Eintrag umgewandelt werden; sicherheitshalber den Pfad des Programms angeben und die Ausgabe verwerfen:
PS: Ich würde ggf. die Nennung der Domäne aus dem vorherigen Posting entfernen (sollte man noch editieren können).
PPS: Das obengenannte Thema bzgl. wget wurde übrigens kürzlich schon einmal diskutiert.
Update:
Ich habe jetzt testweise über cron-job.org den cron hinterlegt. Es gab folgende Fehlermeldung:
301 Moved Permanently
Hier empfiehlt sich, den wget-Befehl von der Kommandozeile auszuführen; Umleitungen wird in der Regel gefolgt und man sieht so die letztlich verwendete URL. Diese Funktionalität kann allerdings eingeschränkt werden, und ggf. ist das genau der Fall auf der obigen Website.