Beiträge von Berichtigung

    Da herrscht wohl ziemliche Begriffsverwirrung, die ich etwas lichten möchte.


    Unter einem Live-System versteht man allgemein ein bootbares Image.
    Die Images, die man von den Distributionen runterladen kann, um dann davon zu installieren,
    sind i.d.R. eben genau das: Abbilder von CD/DVD- ROMS.
    Ein solches Image enthält einen Bootsektor, ein Dateisystem und das ladbare Betriebssystem mit allen seinen Dateien.
    Aber das Dateisystem ist -es ist ja das Abbild einer CD/DVD- natürlich NICHT (so ohne weiteres) beschreibbar.


    Schreibt man ein solches Abbild korrekt auf die Platte, und bootet dann von dieser, startet ein Linuxsystem, das man als Live-System laufen lassen kann, oder zum Installieren verwenden kann. Das ist bei openSUSE so, bei anderen Distris kann das (erheblich) abweichen. Wählt man das Live-System kann man NICHT ohne weiteres irgendwelche Daten speichern. Es ist aus Sicht des Betriebssystems noch immer nur eine DVD, die da gebootet wurde.
    Um den Unsinn, den man in einem solchen Live-System produziert, auch speichern zu können, kann man eine weitere Partition HINTER dieser "CD/DVD Partition" anlegen und die dann für Schreibvorgänge nutzen. Damit das aus Sicht des Users einheitlich bleibt und aussieht, wird dazu ein sogenanntes Overlaydateisystem verwendet.
    Das beschreibbare Dateisystem wird zusammen mit dem read-only Dateisystem als eines angezeigt. Reine Lesevorgänge der Originaldateien lesen die Dateien vom CD/DVD Dateisystem, Schreibvorgänge finden prinzipiell und prinzipbedingt nur auf der anderen Partition statt.


    Das möchte der Threadersteller haben. Jedoch in der Variante, dass auf seiner USB-Platte mehrere solcher bootbaren CD/DVD Abbilder liegen.
    Das ist möglich, erfordert jedoch sehr viel Wissen und Handarbeit. Es ist davon abzuraten. Ich skizziere diesen Weg dennoch, muss aber vorher ein wenig über GRUB erklären.


    Grub ist der GRandUnifiedBootloader. Man kann einen grub verwenden auf einer Platte, oder viele grubs auf vielen Platten und sogar sehr viele grubs auf einer Platte oder sehr vielem Platten. Jede Variante ist möglich. (Ob das Sinn macht sei dahingestellt; für Normalsterbliche Linuxuser ist das Käse)


    Die einzige Bedingung, um zu Laufen, ist, dass das BIOS oder das (U)EFI einen davon anspringen kann.
    Der ganze Rest ist lediglich eine Frage der richtigen Konfiguration dieses ERSTEN Grubs.
    Egal, wie viele Betriebssysteme man installiert haben will, es genügt ein einziger Grub. (Auch wenn man von dem viele andere -meist überflüssig, wie ich meine- rufen kann).


    Da das nun Wissen ist, das man eher selten braucht, und auch gehöriges Grundverständnis voraussetzt, kursieren im Netz leider viele Mythenbis hin zur total falschen Aussagen .
    Eine davon ist, dass man den grub "in den MBR installieren" könne. Das ist faktisch totaler Unsinn. Der MBR ist nur eine Datenstruktur von exakt 512 Bytes (nix Kilko, nix Mega, nix Giga). Dort sind lediglich 4 Einträge für die berühmten vier möglichen primären Partitionen einer "MBR- formatieren" Platte, ein paar Bytes Verwaltungsinfo und ein minikleines Maschinenprogrämmchen (es passen grade mal ca. 10 Zeilen Code rein), das letztlich nur ein Sprung zum eigentlichen Bootloader eines Betriebssystem ist, ODER den "Rest" von grub von egal welcher Partition von egal welcher Platte lädt.
    Grub ist also in zwei "Stages" aufgeteilt. Die Initialisierung und der ganze Rest samt buntbewegtem Bootmenu, der Grubshell (ja, es ist eine limitierte Shell auf dieser Ebene vorhanden) samt diversen Modulen für Verschlüsselung ("Diskencryption"), verschiedene Dateisystemtreiber (Filesysteme, wie ext2, btrfs oder "Mapper", wie RAID und LVM), dazu noch für alle möglichen Betriebssysteme einige Spezialdateien (z.B. ein "appleloader, *BSD- Zeugs und ähnliches).
    (Unter besonderen Umständen können Stage 1 und 2 von grub auch "zusammengefasst" sein, dann nennen wir es Stage1.5)


    Beim Booten eines UEFI Rechner sind prinzipiell dieselben Schritte nötig. Es heißt dann eben nicht mehr BIOS, sondern EFI. (auch hier mischen sich die Bezeichnungen zur allgemeinen Verwirrung). Und oft ist ein UEFI System mit der neuere Partitionierungsart GPT formatiert. (Das ist NICHT zwingend, aber M$ setzt es für neuere Versionen voraus. Und eine GPT ist natürlich vernünftiger, weil sie den Umgang mit sehr großen Partitionen einfacher macht.)


    Der openSUSE Live-Stick enthält letztlich drei Partitionen. Einmal die für EFI vorgeschriebene EFI Partition, dann ein tatsächliches ISO (also das Komplettabbild einer bootfähigen CD/DVD und zuletzt eine "normale" Partition, die für zu schreibende Daten im Live-Betrieb verwendet wird.
    Wie es andere Distris machen, weiß ich nicht. Es dürften ähnliche Konzepte verwendet werden.
    Oder halt auch nicht.


    Und damit wären wir bei dem eigentlichen Problem: Will man nun mehrere solcher Live-Distris als installierbare und arbeitsfähige Live-Systeme vorhalten, so muss zuallererst diese USB Festplatte bootbar gemacht werden. Also eine kleine Partition mit ext3. Ich würde hier kein anderes Dateisystem nehmen, weil man damit so ziemlich alle Arten von Betriebssystemen (samt deren Installation) aufrufen kann. Aber es gehen natürlich auch andere Dateisysteme. Hauptsache man kann davon booten und hat dort eine genügend große /boot Partition, in der man die jeweiligen Treiber und Programme die für das Booten aller anderen Live-Systeme nötig sind, vorhalten kann.


    Für alle anderen Installationsmedien erzeugt man dann die jeweils dafür nötigen weiteren Partition und kopiert die Dateien entsprechend.
    Natürlich muss man für jedes Livesystem einen jeweils angepassten Grubmenueintrag erzeugen.
    Und man muss unbedingt bei dem primären Bootmenu das jeweilige Livesystem via chainloading den jeweiligen Urloader aufrufen.
    Es erscheint dann zuerst das primäre Bootmenu zur Auswahl des zu installierenden Systems und dann. von da aus gerufen, das "echte Bootmenu" der tatsächlichen Live-Distribution.


    So weit die Theorie.
    Kann man machen, will man aber wohl gar nicht.
    Es steht nun nämlich im jeweiligen Einzelfall zu testen, ob das auch funktioniert.
    Hat sich z.B. ein openSUSE installiert und fordert zum Neustart auf, so wird schlicht ein chroot gemacht. Das mag funktionieren, meistens wohl eher nicht.
    In solchen Fällen wird man dann nicht umhin kommen das Live-Medium der jeweiligen Distribution anzupassen.
    Auch das kann man alles in den Griff kriegen.


    Schafft man das, ist man auf jeden Fall ein Linux Senior Chief Technical Installer und kann für x-beliebige Betriebssysteme blind beliebige Installationsmedien basteln.
    Betrunken, rückwärts unter Wasser.

    Es ist ziemlich egal, was in Shellvariablen steht.
    Und du benennst die Dinge nicht, sondern schreibst über sie.
    Es ist besser zu schreiben: "Ich habe das Script ./scripts/install" ja ausführen lassen, stat "das lief ja durch".
    Es ist auch meist falsch irgendwelche Annahmen für wahr zu halten ( "da das script lief, muss ja auch...")
    Das Script verwendet mkdir -p .....
    Per definitionem gibt dieser Befehl KEINE Fehlermeldung aus.
    Von daher hat Sauerland schon recht, wenn er nachfragt, ob das Verzeichnis auch vorhanden ist.
    Wenn das Script ohne gesetzte Variable TEXMFLOCAL und ohne Argument aufgerufen wird, so erzeugt es fälschlicherweise im Root seine Verzeichnisse.


    Was ergibt denn


    Code
    ls -al /usr/share/texmf

    ?

    @senior Entschuldigen Sie bitte, dass ich geantwortet habe.
    Zu Ihren Fragen stelle ich mich wie folgt:
    Es geht hier sowohl so manchen etwas an, wenn in einem deutschen öffentlichen Forum nach einer Anleitung gesucht wird, ein Passwort zu umgehen.
    Das ist in Deutschland nämlich eine strafbare Handlung.
    Aus Ihrem Post war nicht ersichtlich, dass es sich um Ihren eigenen Drucker handelt.
    Deshalb werden hier auch viele einfach nichts geschrieben haben.


    Da ich schon ein wenig länger EDV mache und auch in Hochsicherheitsrechenzentren schon tätig war, hatte ich (und habe ) den Glauben, dass man mit einer Steuersequenz nicht das Passwort eines halbwegs modernen Druckers zurücksetzen könnte. Das ist schlicht ein kapitales Sicherheitsloch (außer Kyocera, die sind jetzt auf der Blacklist).
    Kann ich den Druckserver eines Netzwerkdruckers so einfach übernehmen, habe ich einen sehr netten Angriffsvektor, der mir bei minimalen Aufwand die Übernahme eines Firmennetzes leicht ermöglicht.
    Die Formulierung, dass ich das nicht glauben könne, bringt meinen nicht weiter begründeten Standpunkt dazu zum Ausdruck.
    Nicht ein Wissen.
    Wenn Sie daraus ableiten, dass ich alle Welt für Lügner hielte und die Weisheit mit Löffeln gefressen hätte, so mag das in Ihren sozialen Kreisen üblich sein, für mich ist das befremdlich und weitab vom Thema.
    Dass ich den Webbrowser empfohlen habe, hat auch seinen Grund: Ich GLAUBE, dass dort -auch ohne Passwort- zumindest ablesbar sein KÖNNTE, welche Druckserversoftware dort arbeitet. die Sie zu nennen ja versäumten. Dann hätte man weiter suchen können.
    Auch die Anleitungen im Netz sind immer mir Vorsicht zu genießen. Viele halten sich länger, als sie taugen. Hätten Sie die Güte gehabt wenigstens dorthin zu verlinken, wären auch hier kein Mutmaßungen oder tapfere Annahmen nötig gewesen.


    Bei Ihrer Sozialisation verzichte ich auch in jedem Falle darauf, Ihnen das Zähneputzen zu erklären.
    Was ausdrücklich nicht heißt, dass ich der Überzeugung wäre, dass in Ihren Kreisen keine Workshops zu grundlegenden Kulturtechniken nötig wären.


    Glücklicherweise hat Ihr Drucker ja ein riesiges Sicherheitsloch und Sie das Glück den angeblich Ihren Drucker jetzt selbst erfolgreich gehackt zu haben,
    was uns hoffentlich eine weitere Antwort erspart.

    Gib im Browser einfach die IP des Druckers ein.
    Das mag wenigstens helfen rauszufinden, ob du überhaupt eine Chance hast.
    Es mag dir ohne Password wenigstens sagen, mit welcher Druckserversoftware das Ding arbeitet.


    Ich glaube nicht, dass du bei einem halbwegs modernen Drucker mit eigenem Druckserver eine Chance hast mit der ziemlich alten Methode ein paar Steuersequenzen zu senden.


    Darf man wissen, warum du das Passwort nicht hast?
    Hilfe beim Hacken mögen fast alle nicht.

    Zu wenig Info, was du wirklich am Start hast.
    (Bitte schreibe solche Angaben künftig gleich;
    Nicht "läuft nicht auf port 22" sondern: "läuft nicht auf 22 sondern auf halligalli")



    Prüfe, ob in der fail2ban

    • der nichtstandard Port des SSH- Dienstes korrekt eingetragen ist.
    • Füge notfalls ein backend = systemd ein
    Code
    /usr/bin/netcat -n  XX.X.X.XXX 2112 > /abaserp/abas/erp/applizier/SCANNER.ERR > /abaserp/abas/erp/applizier/SCANNER.LOG

    Es wird die Standardausgabe ZWEIMAL umgeleitet.
    Der Code funktioniert.
    Aber nicht so, wie du es meintest.


    du willst diese Umleitung:
    2>/abaserp/abas/erp/applizier/SCANNER.ERR > /abaserp/abas/erp/applizier/SCANNER.LOG


    Dein Code schreibt sehr wohl. Aber halt nur in die .ERR.


    Und es gibt den Befehl pidof oder man lässt sich mit eiem ps- Format (-output ) gleich die pid mit ausgeben; ps -rf -o pid . "pid" ist nur ein vorgegebener Formatbezeichner. Es gibt sehr viel mehr. Die wichtigsten: -o pid,user,cmd würde in der ersten Spalte die Pid, in der zweiten den User und in der dritten das Commando ausgeben.



    @boser Es gibt in keinem Linux extra Rechte für Streams. Entweder der User darf, oder er darf nicht. Und ein 00 in crontabs ist sehr wohl zulässig. Es ist besser erst die Manpages zu lesen, denn wilde Theorien zu verbreiten. Lese man 5 crontab