Beiträge von GTAzoccer

Zitat von RAD750

pasted-from-clipboard.png

Das ist das erste Mal dass ich dieses Problem habe, kann mir da jemand bitte schnell helfen? Bisher hat das so immer funktioniert... Ist Debian 12

Aus der manpage von adduser.

--disabled-password

Ruft passwd(1) nicht zum Setzen eines Passworts auf. Allerdings sind in den meisten Fällen Anmeldungen weiterhin möglich (beispielsweise über SSH-Schlüssel oder PAM). Die Gründe hierfür liegen außerhalb der Verantwortung von adduser. --disabled-login wird zusätzlich die Shell auf /usr/sbin/nologin setzen.

--disabled-login wird zusätzlich die Shell auf /usr/sbin/nologin setzen.

Also vielleicht su mal zusätzlich mit --shell /bin/bash aufrufen?

Zitat von Bud

Weitere Grüße aus dem Urlaub mit einem weiteren meiner Hobbys

Pizza in Pools werfen? .-.

Ich finde ja viel interessanter, dass bei modernen Smartphones, die Bilder beim reinzommen irgendwie comichaft oder AI generiert aussehen. Sieht man hier ganz gut bei der Vegetation.

Zitat von ThomasChr

Klar, den Hersteller, aber eine wirklich schuldige Person wie bei den meisten altuellen Autounfällen hast du halt nicht.

Genau. Und mehr brauchst du bei einem fundamentalem Designfehler eines Produktes auch nicht. Die Schuld hat das Unternehmen. Wie die intern damit umgehen, ist ja deren Sache.

Und darum geht es mir ja. Wenn man bei einer neuen Technik erst die Frage stellen muss, wer den Schwund abfängt, dann ist unser stand der Technik halt einfach noch nicht bereit für die Masse. Es ist nicht die Lösung, den Big-Techs jetzt einen Freifahrtschein für Gammel-Software zu geben.

Zitat von ThomasChr

Und wie wir damit klarkommen dass Menschen einfach sterben weils halt ein Softwarefehler war und es keinen wirklich schuldigen gibt ist auch so ne Frage.

Woher kommt eigentlich die Mentalität, dass Softwarefehler keine Menschlichen Versagen sind?

Wenn ein physisches Bauteil einen Unfall begünstigenden Designmangel aufweist, kommt es schnell zu Rückrufaktionen und in der Produktentwicklung und/oder Management rollen Köpfe. Ggfs. kommen sogar Schadensersatzforderungen. Aber Softwarefehler sind Naturkatastrophen. Kann man nichts machen ... Da waren ja schließlich keine Menschen an Planung, Entwicklung und QS beteiligt.

Schon mal versucht eine "normale" Screensitzung zu öffnen und erst innerhalb dieser java -jar -Xmx6G spigot-1.20.1.jar nogu zu starten?

Dann würdest du zumindest schon mal die (Fehler-)Meldungen des Javaprozesses sehen können, weil sich Screen nicht mehr direkt nach dem Beenden schließt.

Rein theoretisch könnte man dann seinen Router neustarten für eine neue IP.
FritzBoxen haben sogar einen Button bei den Internetoptionen, der sie veranlasst eine neue IP anzufordern. Ohne Neustart. Also theoretisch.

Sollte du hinter CG-NAT stecken, ists allerdings ein Glücksspiel, ob du danach einem Neuen zugewiesen wirst.

IPv6? Erneuer einfach den DHCP-Lease deines PCs.

Beim rekonstruieren des Fehlers in einer VM, um dir sagen zu können, wie du erkennst ob er weg ist, ist mir noch eine Kleinigkeit aufgefallen.

Nach

dpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force

Muss stattdessen ein

apt install ca-certificates-java

folgen. Das Paket ist nämlich nicht nur in einem unkonfiguriertem Zustand sondern die Installation vollständig gescheitert/abgebrochen.

Zitat von Bud

Wie kann ich mir den Fehler davor anzeigen lassen, und wie danach überprüfen, ob das funktioniert hat?

Um das nun aber zu beantworten.

Erstens wird dich jede Datenbank veränderte apt Aktion (apt install/autoremove/remove/purge usw.) an den inkonsistenten Zustand der drei Pakete erinnern, bis dieser Umstand behoben ist.

Zweitens zeigt dir dpkg --list ca-certificates-java openjdk* den Zustand der Pakete an.

Aus

+++-====================-============-============-=====================================
iF  ca-certificates-java 20230103     all          Common CA certificates (JKS keystore)
un  openjdk-11-jdk-headless       <keine>            <keine>      (keine Beschreibung vorhanden)
iU  openjdk-17-jre:amd64          17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT
iU  openjdk-17-jre-headless:amd64 17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT (headless)

sollte also

+++-====================-============-============-=====================================
ii  ca-certificates-java 20230103     all          Common CA certificates (JKS keystore)
un  openjdk-11-jdk-headless       <keine>            <keine>      (keine Beschreibung vorhanden)
ii  openjdk-17-jre:amd64          17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT
ii  openjdk-17-jre-headless:amd64 17.0.7+7-1~deb12u1 amd64        OpenJDK Java runtime, using Hotspot JIT (headless)

werden.

Das Problem hatte ich beim Upgrade von Debian 11 auf 12 ebenfalls. Hier drehen sich wohl leider die Abhängigkeiten des JRE und der Java Cert Library im Kreis.

Das heißt beide sind von einem vollständig installierten/konfigurierten Version des anderen abhängig. Was nicht funktionieren kann, wenn der Konfigurationsprozess von ca-certificates-java bereits java-code ausführt.

Meine Lösung war:

dpkg-reconfigure openjdk-17-jre openjdk-17-jre-headless --force
dpkg-reconfigure ca-certificates-java

Also die Konfiguration der JRE erzwingen und danach die Cert Library (normal) konfigurieren.

Zitat von Bud

Well... War nicht bewusst, aber warum darf ich das nicht machen?

Auch zu bedenken ist, dass Minecraft nie unter Annahme als root gestartet zu werden entwickelt wurde und somit keinen Privilege-Drop durchführt. Der Prozess/Dienst wird also alle Aufgaben weiterhin als root ausführen.

Und ein Dienst, der alle Netzwerk/User Inputs mit den höchsten Systemprivilegien verarbeitet, ist sicherheitstechnisch eine Katastrophe.

Modded Minecraft ist nicht nur der RAM zu beachten. Die Single-Core Performence ist hier auch ein Problem. Minecraft kann, AFAIK, leider kein Multi-Threading.

Zitat von hoedlmoser

Code

sudo bash

Wenn, dann bitte sudo -i. Damit auch eine neue Login-Shell samt Umgebungsvariablen des root Users geöffnet wird und nicht irgendwelche Tools ihre Configs als root ins eigene Home schreiben wollen.

Zitat von Bud

Hat das einen Grund das die ihre Server/wasauchimmer alle ausschließlich beim roten H holen?

Ich würde jetzt nicht davon ausgehen, dass das ihre eigenen Server sind.

Zitat von H6G

Das gilt ebenso für Software unter anderen UIDs, da diese per su zu deinem Nutzer springen können - und die werden nach dem Passwort des Zielnutzers gefragt.

Moment. Reden wir jetzt von passwd -d oder passwd -dl?

Ich würde mal naiv davon ausgehen, dass Paul Zweiteres meint. Denn Beides würde ich aus der Bequemlichkeit heraus als "Passwortlose Benutzer" bezeichnen, es gibt ja aber wohl signifikanten Unterschied.

Zweiteres verwende ich selbst bei (reinen) SSH-Usern, bei denen ein Passwort nicht nötig/erwünscht ist.

Hallo.

Zitat von tab

Also, /dev/sda is probably the raw device and not a partition like /dev/sda1.

Das wird er schon verstanden haben.

Zitat von Glubschi

Erstellen eines Offline-Images der Root-Partition

Hier wurde ein Abbild des Inhalts der Partition erstellt. Das SCP erwartet aber wohl ein Abbild des gesamten Datenträgers. Er sitzt nun also vor einer virtuellen Platte ohne MBR/GPT/Partitionierungstabelle. Hier kann keine Partition erweitert werden, weil es keine gibt.

Anstatt die (nicht existierende) Partitionierung bearbeiten zu wollen, könnte man jetzt wohl schon direkt das Dateisystem erweitern. Dessen Grenzen nun nur noch die Sektoren/Blöcke des kompletten Datenträgers darstellen.

Wie sauber das ganze aber für einen Produktivbetrieb sein wird, will ich nicht beurteilen. Und vor allem, wie das Ding überhaupt ohne MBR oder EFI-Partition überhaupt booten konnte.

Zitat von aRaphael

Das war eine echte Katastrophe

Hast du da ein konkretes Beispiel?

Also vorab: Ich muss hier nicht von Acronis "weg überzeugt" werden. Nutze ich nicht und habe bei dem Unternehmen (in Sachen Backuplösung) keine Erfahrungen. Aber so rein aus Interesse. Ich finde ein "XY ist Mist." ohne Begründung immer etwas ernüchternd. Und ggf. hilft eine Erläuterung auch anderen als (weitere) Warnung, die die Software in Erwägung gezogen haben.

Zitat von mainziman

Ähm, irgendwie werd ich gerade wahnsinnig;

in einem File steht eindeutig

Jan  1 00

(zwischen Jan und 1 echt 2 Spaces und die 00 bedeutet was anderes, nicht die Jahreszahl;

wieso zum Henker wird bei folgendem

var=$(cat ./file)

bei echo $var dann nur?

Jan 1 00

(mit einem Space zwischen Jan und 1)

macht man aber cat ./file

dann stehen da eindeutig 2 Spaces dazwischen, und die brauch ich

hab ich aber nicht, weil ... | grep $var liefert nichts, weil eben nur 1 Space statt 2;

Alles anzeigen

echo "$var"

Sonst bekommt echo drei Parameter/Schalter, welches es dann wieder mit einem einzelnen Space getrennt ausgibt.

Zitat von larsVegas

Kann ich die Abfrage Serverseitig für meinen Client deaktivieren?

Nein.

Das ist alles reine Client Sache. Der Server bekommt beim Login nur einen Fingerprint des Keys und danach die entschlüsselte Challenge als Nachweis über den Besitz des Privaten Schlüssels.

Ob du den Privaten Schlüssel auf deinem Client mit einem Passwort schützt, entscheidest du allein auf dem Client. Entweder beim Erstellen des Keys die Frage nach dem Passwort leer lassen, oder nachträglich beim Passwort Ändern das neue Passwort leer lassen.

Die Konsequenz daraus sollte dir aber klar sein: Sollte dir der Private Schlüssel abhanden kommen. Seis durch böswillige Software auf deinem Gerät, oder physischer Verlust des gesamten Geräts, kann sich jeder sofort mit diesem Key einloggen. Du musst dieses in dem Fall also umgehenden vom Server entfernen. (Und hoffen, dass du den Verlust rechtzeitig bemerkst)

Zitat von ASS

Und nein, meine Anlage hatte KEINE Störung.

Das mag ja sein. Aber, wenn dein SIP-Provider bzw. deren Server, oder der Provider der Gegenstelle eine Störung hat (oder halt das peering/routing zwischen den beiden grad falsch abbiegt), hört der Anrufende auch nur tut-tut-tut und denk sich "Hm, besetzt." und bei dir lokal ist nichts angekommen/protokolliert.

Will damit aber an sich niemanden verteidigen. Nur die Möglichkeit in Betracht ziehen, dass man es sehr wohl >wirklich versucht< haben kann, ohne das etwas bei einem ankommt.

In Mehrparteienhäusern hängt die Klingelanlage am Gemeinschaftsstrom. Soll heißen, er gehört dir nicht.