|
|
|
|
Kannst du nicht wenn du das environment beherrscht ohnehin den Linker umkonfigurieren und hast so oder so gewonnen?
|
|
|
|
|
|
|
Nicht zwingend. In meine Bashrc kann jeder mit meinen Userrechten schreiben. Firefox neu bauen und in /usr/bin/ neu ausrollen nicht
Gut, man könnte das schädliche binary in ~/bin/ ablegen und ~/bin/ zum Pfad hinzufügen.
Und selbst dann braucht man immernoch die ganzen Build-Dependencies. Die sind evtl. vorhanden, vielleicht aber auch nicht. Ist schon ein anderes Unterfangen als eine Env-Variable zu setzen
|
|
|
|
|
|
|
Ja. (e: Ghandi: LD_PRELOAD, LD_LIBRARY_PATH)
Aber als Fehler-vermeidungs-Werkzeug wäre das vielleicht schon sinnvoll — der Artikel empfiehlt es etwa, das in die .bashrc zu tun
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 17.08.2017 17:23]
|
|
|
|
|
|
Stimm, an LD_LIBRARY_PATH hatte ich gar nicht gedacht
|
|
|
|
|
|
|
Danke! Gut zu Wissen, dass grösste Problem an der Verschlüsselung ist nämlich das man an den eigenen Traffic - bei quellgeschlossenen Anwendung besonders - nicht heran kommt und Reverse Engineering schwierig bis unmöglich wird. Hier mehr, spezifisch zur cURL. Zu euren Variablen darf man noch das "böse" Gegenstück vom Linker nicht vergessen, die Option RPATH.
Google hilft nicht viel, falls man sein Passwort vergisst. Ich habe Verständnis für den Ärger, aber keines für diese Erwartungshaltung. Google wird von ihm nicht bezahlt.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 18.08.2017 10:19]
|
|
|
|
|
|
|
|
|
|
| Zitat von hoschi
Nur ist fünfmal Drücken zu oft, zweimal bekommt man in Panik vielleicht noch hin.
| |
Gott bewahre. Manche Samsungs schicken bei 5x drücken schon lange SOS an Kontakte. Das bekommen die Leute regelmäßig ausgelost. Wenn das nur 2x wäre und an die Polizei geht.. ohweh.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 18.08.2017 12:05]
|
|
|
|
|
|
Solche Funktionen sind super wenn man Kinder hat
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Zitat von Rufus
Manche Samsungs schicken bei 5x drücken schon lange SOS an Kontakte. Das bekommen die Leute regelmäßig ausgelost. Wenn das nur 2x wäre und an die Polizei geht.. ohweh.
| |
Stimmt. Aber in dem Fall weniger ein Problem, da noch kein SOS gesendet wird. Hauptfunktion für mich ist die Abschaltung der Biometrie (Fingerabdrucksensor) um so eine Entsperrung durch physischen Zwang (durch Kriminelle oder Behördern) zu verhindern.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 18.08.2017 16:01]
|
|
|
|
|
|
sagt mal, wie ist das bei fibre channel eigentlich mit port aggregation?
ist das wie bei ethernet mehr so ein load balancing oder eher so in richtung wir vermehrfachen tatsächlich die nutzbare bandbreite?
kann man dafür "normale" OM3 LC/LC kabel verwenden oder muss man da auf was bestimmtes achten? (geht um max 120 meter länge)
|
|
|
|
|
|
|
Ist das nicht alles über MPIO bei FC?
|
|
|
|
|
|
|
|
|
|
|
| I think it would be really interesting to build something like dispora as a suite of dockerised micro-services which would allow you to add and extend functionality based on a new social-networkong protocol in a language-agnostic way. It would also be very easy to incorporate email and xmpp which are already federated protocols. | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hat hier jemand einen x270? Könnte mein Fujitsu S935 dafür (je mit i5) eintauschen. Irgendwie will ich aber nicht von 2560px auf 1920px runterfallen.
|
|
|
|
|
|
|
um nochmal auf diese irre interface renaming sache von letztens zurück zu kommen.
ich hab hier übers wochenende nen hardware raid controller (3ware 9650SE-12ML) in in den oxy kasten gesteckt, seit dem ist das interface, was bisher "enp4s2" war zu "enp5s2" geworden.
scheinbar wandert so ein PCI (!) gerät, was fest auf dem board verlötet ist gelegentlich mal von slot zu slot.
damit muss ich dann jetzt alle programme, die nen interface zugeordnet bekommen haben, manuell ändern um dieses sehr viel besser und stabilere und vor allem persistente nameszeugs zu fixen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 21.08.2017 23:55]
|
|
|
|
|
|
Ich hab mir udev rules gemacht, die Namen nach MAC vergibt.
// Und als Bonus, ich brauchte bei Migration auf neue Hardware nichtmal rumprobieren welche MAC zu welchem Port gehört, weil es ernsthaft in der richtigen Reihenfolge war. Auf altem Server neue MACs in die udev rule eingetragen, shutdown, SSD in neuen Wechselrahmen eingebaut, Kabel umgesteckt, angemacht, lief.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 21.08.2017 23:58]
|
|
|
|
|
|
das werde ich zwangsläufig auch machen und dann gleich mal die namen etwas leserlicher machen.
ich wollte dem kram halt mal ne chance geben, aber es hat sich in den letzten jahren wohl scheinbar absolut gar nichts in richtung bugfixing in dem bereich getan.
ebenfalls werde ich wohl die tage dann nen entsprechenden bug report bei debian einreichen.
das ist halt schon recht standard und leicht abgehangene server hardware, da erwarte ich einfach, dass der shit sauber läuft und ich nicht in solchen irrsinn reinlaufe.
das ganze zeugs um und inkl. systemd ist einfach nicht für irgendwas professionelles gemacht, dass ist einfach so pillepalle software für desktops, die absolut keine anforderungen stellen. dort wiederum ist es inzwischen absolut absurd von seiten der ursprünglichen argumentation, dass der kram schneller starten soll und alles wunderbar parallel laufen muss. den teil mit SSDs und schnellen CPUs haben die irgendwie damals nicht so ganz mitbekommen...scheinbar.
/e
es wäre schön, wenn devuan auf dem gleichen software level (stretch) wäre, wie debian es ist. der jessie kram ist für die sachen hier leider ein wenig zu alt.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 22.08.2017 0:54]
|
|
|
|
|
|
| Zitat von Traxer
um nochmal auf diese irre interface renaming sache von letztens zurück zu kommen.
| |
"not our bug" :/
|
|
|
|
|
|
|
also doch predictable unpredictable interface names?
was war noch gleich der sinn hinter dem kram?
ich mein, was genau ändert sich dadurch, ausser das 30 jahre dokumentation jetzt nicht mehr so ganz stimmt? bessere namen sind das jetzt nicht, wenn die sich mit ändernder hardware config ändern und sie genau das eben als grund angegeben haben, dass das damit verhindert werden soll.
|
|
|
|
|
|
|
"The default network names are only predictable for a stable hardware configuration." lol. Da geb ich Traxer echt recht, warum haben sie sich dieses Zeug eigentlich ausgedacht?
|
|
|
|
|
|
|
Unter welchen Umständen wäre denn ethN bei stable hardware configuration nicht predictable?
|
|
|
|
|
|
|
| The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. | |
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
|
|
|
|
|
|
|
Wie sollte denn ein konstantes Namensschema auch implementiert werden, wenn man zulässt, dass sich die Hardware ändert? Irgendwas muss konstant bleiben, sonst gibt es dazu schlicht keine Möglichkeit. Auch MAC Adressen können sich ändern.
|
|
|
|
|
|
|
Stell doch solche Fragen nicht.
|
|
|
|
|
|
Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |