|
|
|
|
|
|
|
| |
...
am ... wurde eine an Sie gerichtete E-Mail ... automatisch überprüft. Diese E-Mail hat einen oder mehrere Links enthalten. ... wurde diese E-Mail deshalb blockiert und wird gelöscht.
Mit freundlichen Grüßen
Security Operations Center
IT.Niedersachsen
Fachgebiet 15 – Cyber Defense Operations Center | |
e: Das Endergebnis ist, dass die Leute dann händisch eine Mail zurückschreiben und sich für ihre IT entschuldigen und dann darum bitten die Mail postalisch oder per Fax zu übersenden.
Fax-over-IP könnte in Deutschland noch ne richtig tolle Zukunft haben!
Fun-Fact, im Organigramm gehört das Cybercenter zum Fachbereich Kunden & Lösungen, und nicht zum Fachbereich "Zentraler Betrieb" (wo Fachgebiete wie "Leistand" und "Netzwerke" anzutreffen sind). Hm.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 27.01.2020 18:14]
|
|
|
|
|
|
|
|
|
Streng dich halt ein bisschen an den Link zu maskieren.
|
|
|
|
|
|
|
|
|
|
|
Tach! Kleines Problem mit bestimmt einer einfachen Lösung:
Raspberry mit Hass drauf. Will Hass per SSH von irgendwo starten. Geht auch, allerdings nur solange die SSH-Sitzung aktiv ist. Sobald ich den Terminal schließe, geht auch Hass aus.
Hab jetzt eigentlich keinen Bock auf das Autostart-Gefrödel, würde das aber tun, falls es nicht eine Möglichkeit gibt Hass per SSH so zu starten, dass ich die Konsole zumachen kann.
|
|
|
|
|
|
|
|
|
|
|
Einfachster aber "schmutziger" weg:
| |
| Code: |
$ nohup hass &
$ exit
|
|
Nohup anleitung
besser ist, wenn du dir screen oder tmux drauf schaffst 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 27.01.2020 23:11]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Einfachster aber "schmutziger" weg:
| |
| Code: |
$ nohup hass &
$ exit
|
|
Nohup anleitung
besser ist, wenn du dir screen oder tmux drauf schaffst
| |
nohup hats gebracht, danke. Screen klingt interessant, schau ich mir an. Hass zieht aber demnächst eh auf einen neuen Rechner um. Hab mir bei recycle-it nen Rechner für 22 Euro gekauft um mal etwas größer rumzutesten. Da is jetzt manjaro drauf, aber der Umstieg von apt auf pacman stresst mich jetzt schon. 
|
|
|
|
|
|
|
|
|
|
|
|
Warte nur bis du dich mit AUR Helpern auseinander setzt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und nimm tmux, taugt besser.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und das nicht etwa, weil Screen irgendwie schlecht wäre oder so, aber man merkt tmux einfach sehr deutlich an, dass es ein viel neueres und moderneres Projekt ist, welches viel von Screen gelernt hat.
|
|
|
|
|
|
|
|
|
|
|
ausser dass ich den tag verflicht bei dem sie strg+b als standard kommand da genommen haben.
ich mein: wtf?
das erste was ich mach ist das auf ..+a umzumappen um mir nicht die hand zu brechen.
fakeedit:
neuer intel CPU bug.
https://cacheoutattack.com/
[x] hat ne eigene domain
[x] hat nen eienes logo
-> muss was ernstes sein
|
|
|
|
|
|
|
|
|
|
|
|
der wirklich einzige Grund, aus dem wir jetzt gerade wieder Intel-Server genommen haben, ist SAP Hana. Das läuft bisher nur auf denen (und IBM Power, aber please...), weil da die TSX-Erweiterungen zumindest auf der Hana-Instanz zwingend nötig zu sein scheinen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
das erste was ich mach ist das auf ..+a umzumappen um mir nicht die hand zu brechen.
| |
Hehe. Ich nutze schon lange und glücklich Screen. Wenn auch nicht übermässig viel. TMUX steht irgendwie schon ewig auf der Liste von Dingen, die ich mal ausprobieren sollte.
Irgendwann. Ganz bestimmt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
ausser dass ich den tag verflicht bei dem sie strg+b als standard kommand da genommen haben.
ich mein: wtf?
das erste was ich mach ist das auf ..+a umzumappen um mir nicht die hand zu brechen.
fakeedit:
neuer intel CPU bug.
https://cacheoutattack.com/
[x] hat ne eigene domain
[x] hat nen eienes logo
-> muss was ernstes sein
| |
Die Dinger haben inzwischen etwas von Werbeanzeigen oder umgekehrten Stellenanzeige. Ich habe das PDF angeklickt und kurz reingelesen, aber meine Neugierde diesbezüglich schränkt sich zunehmend ein. Sandy Bridge scheint mal wieder alt genug zu sein um gar nicht erst betroffen zu sein. Wieder ein guter Grund beim ThinkPad X220 zu bleiben. Bedingt durch die ganzen Mitigations sollte es langsam in der Performance aufholen. Hat eine gewisse Ironie.
Ich frage mich zunehmend ob AMD nicht die Ressourcen oder Unvernunft hatte, um sich mit den Optimierung von Out-Of-Order-Execution und SMT in solche Schwierigkeiten zu bringen. Wahrscheinlich konzentriert sich die Forschung schlicht auf das leichtere Opfer?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 28.01.2020 11:54]
|
|
|
|
|
|
|
|
|
Ich sehe da einen Unterschied in der Mentalität der Designs. Das Execution Model von AMD ist so, dass sie immer Berechtigungen prüfen, bevor der Zugriff stattfindet. Das ist natürlich tendenziell langsamer als Intel's Weg, erst auf etwas zuzugreifen und irgendwann später zu prüfen, ob man das eigentlich durfte, besonders wenn man diesen Zweig der Ausführung eh verwirft und die Intel CPU daher nie die Überprüfung gemacht hat.
Das man sich mit dem Intel-Modell früher oder später Probleme einhandelt, war zumindest prinzipiell recht lange bekannt.
Edit: Unabhängig von Spectre, was man als ein Missverständnis auf großer Breite betrachten könnte.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 28.01.2020 14:29]
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
weil da die TSX-Erweiterungen zumindest auf der Hana-Instanz zwingend nötig zu sein scheinen.
| |
ach, habe die sieben affen wieder nicht zugehört, als intel anno 2013 TSX auf grund von fundamentalen problemen in allen Haswell chips abschalten musste oder neuerlich, als das als eine der hauptproplematiken für die ausnutzung der ganzen speicherberechtigungssachen war?
TSX ist so dermassen verbuggt, dass es für nichts ernsthaft verwendet werden kann. nutzt du da bestimmte instruktionen, hängt sich die CPU auf.
als nächstes benötigen die dann MPX/SGX, was halt so wunderbar zum exfiltrieren verwendet werden kann, dass selbst intel in teilen inzwischen vom einsatz abrät.
|
|
|
|
|
|
|
|
|
|
|
|
ist doch geil, wenn man seine zentrale Datenbanktechnologie damit aufbaut. Ich mein, die nutzen ja auch Javascript für ihr Enterprise-Frontend. Vermutlich trösten die sich damit, dass die meisten Kunden die HanaDb auf nem dedizierten Cluster laufen lassen, der von aussen nicht zu erreichen ist.
|
|
|
|
|
|
|
|
|
|
|
|
ist das das gleiche „die meisten“, wie bei „die meisten S3 buckets sind sicher und verlieren keine daten“?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
dass die meisten Kunden die HanaDb auf nem dedizierten Cluster laufen lassen, der von aussen nicht zu erreichen ist.
| |
ahahaha, also ich mag ja naiv sein, aber das _hoffe_ ich doch.
ein system was "von aussen" zu erreichen ist, musst du up to date halten können, ohne wenn und aber.
das steht dem "business critical" und "zentrales ding ohne das nix geht" als was ich so ne installation einschätze irgendwie fundamental entgegen.
wenn die _das_ verkacken dann gehören die daten an die öffentlichtkeit.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
ist doch geil, wenn man seine zentrale Datenbanktechnologie damit aufbaut. Ich mein, die nutzen ja auch Javascript für ihr Enterprise-Frontend. Vermutlich trösten die sich damit, dass die meisten Kunden die HanaDb auf nem dedizierten Cluster laufen lassen, der von aussen nicht zu erreichen ist.
| |
War es nicht sogar afaik so, dass TSX und MPX in der Praxis langsamer waren als bisherige Techniken für Locking und STM?
|
|
|
|
|
|
|
|
|
|
|
bei TSX kommt das stark drauf an, wie das umgesetzt ist.
bei haswell war es wohl so, dass das nen monitoring über die caches war, wobei dann die daten in den L1 geschrieben wurden und nur dann commited, wenn sich die cache referenzen nicht zwischenzeitlich geändert haben.
das problem dabei war und ist halt, dass du OOO hast und mehrere cores, wenn da dann irgendwas den cache anfasst, wars das und du kannst von vorne anfangen.
die variante die in skylake vorhanden ist, soll wohl anders sein.
das dämliche an TSX ist eigentlich, dass das ursprünglich mal als x86 variante von den "load with reservation" / "store conditionally" sachen von RISC gedacht war. funktioniert halt auch ähnlich, nur ohne die explizite behandlung von den jeweiligen fällen, was dann zu enormer komplexität bei der TSX implementation führt.
AMD hat auch was ähnliches gebaut, allerdings bisher in keiner CPU integriert oder aktiviert. vermutlich auch aus sehr guten gründen.
|
|
|
|
|
|
|
|
|
|
|
Ist doch wieder einmal geil. Man kriegt von überbezahlten Beratern "aufgezwungen" Intel Hardware zu kaufen, wegen eines "dringend" benötigten Features, welches dann aber gar nicht so toll ist und auch vom Hersteller selbst inzwischen eigentlich für Tod erklärt wird.
Die Berater stopfen sich die Taschen voll mit BestechungsgeldHonorar. Und Intel lacht sich ins Fäustchen und macht ein Rekordquartal nach dem anderen. Und das obwohl die Xeon-Chips im Moment wirklich (fast) keine Daseinsberechtigung mehr haben.
Wie mich das triggert. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von GarlandGreene
dass die meisten Kunden die HanaDb auf nem dedizierten Cluster laufen lassen, der von aussen nicht zu erreichen ist.
| |
ahahaha, also ich mag ja naiv sein, aber das _hoffe_ ich doch.
ein system was "von aussen" zu erreichen ist, musst du up to date halten können, ohne wenn und aber.
das steht dem "business critical" und "zentrales ding ohne das nix geht" als was ich so ne installation einschätze irgendwie fundamental entgegen.
wenn die _das_ verkacken dann gehören die daten an die öffentlichtkeit.
| |
da wär ich sehr vorsichtig. SAP hat grad noch ein paar Ankündigungen rausgebracht, die den Betrieb von Netweaver (der Application Server, auf dem die eigentliche Anwendung läuft) und Hana (nur die Datenbank) auf einer Instanz erlauben, bisher war das nur getrennt möglich. Wie viele dieser Installationen dann ohne OData-Gateway (die empfohlene Konfiguration der SAP für S4) direkt ins Internet gehängt werden, damit der CIO die Fiori-Apps auch unterwegs nutzen kann, will ich nicht wissen. Unabhängig von den vielen Installationen, in denen die HanaDb in einer virtuellen Umgebung einfach so mitläuft und damit dafür sorgt, dass die ganze Umgebung TSX eingeschaltet haben muss. Wird bei uns vermutlich nicht viel anders sein, mal schauen wie das in 2-3 Jahren aussieht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GarlandGreene am 29.01.2020 10:27]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Das man sich mit dem Intel-Modell früher oder später Probleme einhandelt, war zumindest prinzipiell recht lange bekannt.
| |
Ich habe keine Kompetenz in CPU-Entwürfen. Lediglich intiutiv möchte ich die Worte zumindest prinzipiell recht lange streichen. Superskalara-Prozessoren sind tolles Konzept, also auch Out-Of-Order-Execution. Vom Gefühl her hat mir SMT nie zugesagt, dass teilen der Hardware und ablegen der Daten in verschiedenen Caches scheint zusammen it Out-Of-Order-Execution eine Abschottung schwierig zu machen.
| | Zitat von csde_rats
Ich sehe da einen Unterschied in der Mentalität der Designs. Das Execution Model von AMD ist so, dass sie immer Berechtigungen prüfen, bevor der Zugriff stattfindet. | |
Wenn AMD prinzipiell so agiert hat, wäre es gut. Hört sich an wie das Grundprinzip der Informatik, erst die Eingabe prüfen und danach handeln.
| | Zitat von [NBG]HLord
Wie mich das triggert.
| |
Nachvollziehbar, aber sieh es positiv. Es sieht nach Unvermögen aus. Wir haben in der IT oft genug böswillige Absicht und da ist mir Unvermögen lieber.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 29.01.2020 11:50]
|
|
|
|
|
|
|
|
|
|
Oh ja. Es war ja letztes mal (2001?) überhaupt nicht böse Absicht, dass Intel Hersteller und Händler dafür bezahlt hat, aktiv keine AMD-Modelle anzubieten.
|
|
|
|
|
|
|
|
|
|
|
Leider gibt es auch drei Jahre ach dem epyc Launch keine entry-Level Server mit AMD 
|
|
|
|
|
|
|
|
|
|
|
sagen wir mal so, es gibt nicht viele hersteller die welche anbieten, bzw. die boards dafür.
man kann jetzt bei den epyc preisen auch fragen, was man da unter entry level verstehen darf/soll. bei intel war das halt bisher primär über den preis und die mögliche menge an ram segmentiert.
einen 16-kern epyc bekommt man aktuell ab 475 euro aufwärts, den 8-kerner gibts ab knapp 400 euro. ich hab damals für meine e3 chips um die 370 euro auf den tisch gelegt. die e5 waren da halt bei mind dem doppelten.
die epyc boards sind in etwa nen 100er teurer, als die e3 boards. dafür bekommst du halt auch deutlich mehr cores und mehr I/O, als auch die möglichkeit für sehr sehr viel mehr ram.
da ist halt die segmentierung nicht wirklich vorhanden.
wenn man da jetzt von nem ryzen ausgehen würde (ohne den threadripper, weil das halt nen kastrierter und teurerer epyc ist), der 8 core kostet irgendwo um die 320 euro, nen board dafür, dass server grade ist in etwa 210 euro (mit 2x 10g nic ca 320).
da stellt sich dann die frage ob der unterschied sinnvoll ist.
davon abgesehen liefert AMD halt auch schon seit ryzen 1 alles, was die boardhersteller für entry level systeme benötigen würden. die CPUs haben alle den ECC support unlocked und die chipsätze können nahezu beliebig konfiguriert werden, womit man halt sachen abschalten kann, die nicht verwendet werden. z.b. audio.
letzteres macht intel ja nicht wirklich anders. die gesamte C2xx serie von chipsätzen hatte und hat den vollen funktionsumfang des Zxxx chipsatzes, wobei ersterer halt diverse sachen via strapping abgeschaltet hat und einige I/O lanes umgeroutet sind/werden.
das was mich halt eher wundert ist, dass die firmen nicht auf die idee kommen, dafür barebones zu bauen, die sich z.b. an edge server richten oder für transcoding maschinen. die zen chips zerstören intel halt in den gebieten. crypto und multimedia monster.
ich wollte demnächst eh mal nen paar sachen bei supermicro anfragen, weil ich dieses jahr auch mal wieder einen oder zwei systeme upgraden muss, also rz geräte.
der vollständigkeit halber:
ryzen server board:
https://geizhals.de/asrock-rack-x470d4u-a2009567.html
https://geizhals.de/asrock-rack-x470d4u2-2t-a2135212.html
angeblich hat tyan auch eines, allerdings wohl nicht frei verkäuflich.
ich neige inzwischen dazu für die rz geräte wohl auch epycs zu nehmen, weil die einfach günstiger sind, wenn ich da nen 16 core haben will. die frequenz für die ist da auch eher weniger relevant. wobei es ja inzwischen auch als gesichert scheint, als das AMD auch bei den epycs wohl keine sperre gegen übertaktung vornimmt. man müsste da dann halt nur boards mit entsprechenden VRMs finden, was wohl das problem sein wird.
wobei, je mehr ich da wieder drüber nachdenke wird das problem wohl eher darin liegen, dass die ganzen firmen und ihre systemhausidioten, deren "gute berater" denen zu intel raten, weil die AMD vermutlich gar nicht kennen oder das gute prinzip von "seit jeher intel" fahren.
das ist in etwa so, als wenn du denen was von linux oder mac erzählen willst. die haben davon einfach null ahnung.
das was AMD mal dringend machen sollte, so in sehr grossem umfang, sind von denen organisierte events, bei denen man genau solche leute einlädt und denen dann mal kurz erklärt was sache ist und das es da noch ein paar mehr als intel gibt. also ne solide PR veranstaltung für leute, die im consulting aka "ich kann nichts" bereich tätig sind.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
wobei, je mehr ich da wieder drüber nachdenke wird das problem wohl eher darin liegen, dass die ganzen firmen und ihre systemhausidioten, deren "gute berater" denen zu intel raten, weil die AMD vermutlich gar nicht kennen oder das gute prinzip von "seit jeher intel" fahren.
| |
Ja, dieses. Wobei das mit Linux nicht stimmt. Aber auf Fragen nach AMD wird mit "Ne wir haben schon immer Intel gemacht" geantwortet. Ist natürlich auch super einfach, wenn man eh schon einen Vertrag hat, wahrscheinlich in beide Richtungen.
Very good.
|
|
|
|
|
|
|
|
|
|
|
|
mit der Virtualisierung kommt noch ein anderer Faktor dazu: Live-VMotion zwischen Intel und AMD ist so ohne weiteres anscheinend nicht möglich. Wenn man etwas größer ist, tauscht man ja nicht einfach seine komplette Umgebung aus, sondern nur mal hier und da was. Wenn man da mal mit Intel angefangen ist, kommt man da nur über viele Jahre Handarbeit wieder raus. Mit AMD natürlich genauso, aber das Problem werden in der Praxis nur wenige Unternehmen haben.
|
|
|
|
|
|
|
|
|
|
|
wenn ihr da einfach sauber AMD64 als instruction set nutzt, bei den vector sachen SSE bis einschliesslich SSSE3 nutzt bzw AVX2, dann dann ist selbst ne live migration dazwischen möglich. das sind effektiv die gleichen sachen die man beachten muss, wie wenn man zwischen zwei intel architekturen migriert.
da ist nichts aussergewöhnliches bei. ausser man reden halt von schlechter software, die vorgibt eine virtualisierungslösung zu sein und in der realität nichts virtualisiert. in dem fall geht das natürlich nicht wirklich gut. das problem hat man dann aber auch, wenn man z.b. von haswell auf skylake (also intels aktuellste) wechseln will, da gibts dann nämlich auch den spass mit unterschiedlichen feature sets.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
