Auf einem meiner Server rauscht die Entropie beständig und sehr schnell komplett in den Keller:
Der Server ist neu eingerichtet (auch nicht anders als all die anderen) und es läuft noch gar nichts drauf (außer dem üblichen Standardkrempel, der aber auch auf all meinen anderen Servern läuft)
Hat jemand eine Idee, wie ich rausfinden kann, was hier meine Entropie auffrisst?
Auch wenn Du höchstwahrscheinlich ein Scalper bist
Ich glaube du hast Recht... Domain und IP aus einem alten Screenshot passen zusammen. Wie ich mich nun im Nachhinein ärgere dabei geholfen zu haben den Server ans Netz zu bekommen. 
Naja, bleibt zumindest die Hoffnung, dass die Kiste, die ja offen wie ein Scheunentor zu sein scheint, bald einen neuen "Besitzer" findet. 
Auf einem meiner Server rauscht die Entropie beständig und sehr schnell komplett in den Keller: […]
Hat jemand eine Idee, wie ich rausfinden kann, was hier meine Entropie auffrisst?
Also ich bin ein wenig sehr enttäuscht, habe jetzt vom VPS 3000 auf das neue Root Gen 9.5 System, RS 2000 G 9.5 geupdatet und die performance der SSD ist in meinen Augen dürftig, wenn man davon ausgeht, dass die Performance um 20/21 Uhr noch mal deutlich sinken wird.
test1: (groupid=0, jobs=1): err= 0: pid=1076: Fri Mar 18 12:20:49 2022
read: IOPS=32.7k, BW=128MiB/s (134MB/s)(3070MiB/24028msec)
bw ( KiB/s): min=60752, max=159136, per=100.00%, avg=130874.65, stdev=31378.86, samples=48
iops : min=15188, max=39784, avg=32718.65, stdev=7844.70, samples=48
write: IOPS=10.9k, BW=42.7MiB/s (44.8MB/s)(1026MiB/24028msec); 0 zone resets
bw ( KiB/s): min=20320, max=52982, per=100.00%, avg=43740.29, stdev=10642.19, samples=48Nach drei Stunden noch mal einen Test durchgeführt und es macht anscheinend überhaupt keinen Unterschied ob VPS oder Root, die Werte brechen teilweise für mehrere Sekunden auf unter 1MB/s.
So würde mein Kamerafeed, wenn er in dem Moment speichert eventuell frames verlieren. Das sind mir keine 16 Euro über 12 Monate Laufzeit wert.
fio --randrepeat=1 --ioengine=libaio --direct=1 --g tod_reduce=1 --name=test1 --filename=test1 --bs=4k --iodepth=64 --size=4G --read write=randrw --rwmixread=75
test1: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, i oengine=libaio, iodepth=64
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [m(1)][4.8%][r=34.6MiB/s,w=11.6MiB/s][r=8850,w=2976 IOPS][eta 00m Jobs: 1 (f=1): [m(1)][7.3%][r=74.1MiB/s,w=24.7MiB/s][r=18.0k,w=6318 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][10.2%][r=87.9MiB/s,w=29.1MiB/s][r=22.5k,w=7456 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][13.3%][r=97.2MiB/s,w=32.5MiB/s][r=24.9k,w=8312 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][15.9%][r=80.6MiB/s,w=26.5MiB/s][r=20.6k,w=6775 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][19.0%][r=88.3MiB/s,w=29.6MiB/s][r=22.6k,w=7568 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][21.4%][r=75.3MiB/s,w=25.5MiB/s][r=19.3k,w=6522 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][23.3%][r=61.2MiB/s,w=20.7MiB/s][r=15.7k,w=5301 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][25.6%][r=60.7MiB/s,w=20.6MiB/s][r=15.5k,w=5274 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][27.3%][r=64.7MiB/s,w=21.7MiB/s][r=16.6k,w=5555 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][29.5%][r=57.1MiB/s,w=19.4MiB/s][r=14.6k,w=4968 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][31.1%][r=45.7MiB/s,w=15.2MiB/s][r=11.7k,w=3901 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][32.6%][r=59.1MiB/s,w=19.6MiB/s][r=15.1k,w=5026 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][34.0%][r=27.2MiB/s,w=9073KiB/s][r=6950,w=2268 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][37.0%][r=95.3MiB/s,w=32.1MiB/s][r=24.4k,w=8214 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][40.0%][r=91.5MiB/s,w=31.0MiB/s][r=23.4k,w=7940 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][43.2%][r=96.6MiB/s,w=32.0MiB/s][r=24.7k,w=8200 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][46.5%][r=102MiB/s,w=34.5MiB/s][r=26.1k,w=8842 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][50.0%][r=98.7MiB/s,w=33.0MiB/s][r=25.3k,w=8456 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][52.4%][r=75.9MiB/s,w=25.8MiB/s][r=19.4k,w=6612 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][54.8%][r=87.0MiB/s,w=29.0MiB/s][r=22.3k,w=7433 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][57.1%][r=44.2MiB/s,w=14.8MiB/s][r=11.3k,w=3779 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][56.8%][r=2520KiB/s,w=816KiB/s][r=630,w=204 IOPS][eta 00m:1 Jobs: 1 (f=1): [m(1)][57.8%][r=35.5MiB/s,w=12.1MiB/s][r=9084,w=3093 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][60.0%][r=72.2MiB/s,w=23.7MiB/s][r=18.5k,w=6059 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][62.2%][r=61.7MiB/s,w=20.4MiB/s][r=15.8k,w=5222 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][64.4%][r=66.9MiB/s,w=22.2MiB/s][r=17.1k,w=5674 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][66.7%][r=77.9MiB/s,w=25.9MiB/s][r=19.9k,w=6625 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][68.9%][r=78.8MiB/s,w=26.7MiB/s][r=20.2k,w=6837 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][72.7%][r=94.9MiB/s,w=31.9MiB/s][r=24.3k,w=8157 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][75.0%][r=93.8MiB/s,w=31.9MiB/s][r=24.0k,w=8160 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][79.1%][r=103MiB/s,w=34.8MiB/s][r=26.2k,w=8897 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][81.4%][r=76.5MiB/s,w=25.5MiB/s][r=19.6k,w=6535 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][83.7%][r=83.5MiB/s,w=27.0MiB/s][r=21.4k,w=7160 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][86.0%][r=77.8MiB/s,w=25.4MiB/s][r=19.9k,w=6501 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][88.4%][r=13.7MiB/s,w=4372KiB/s][r=3503,w=1093 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][88.6%][r=27.2MiB/s,w=9252KiB/s][r=6969,w=2313 IOPS][eta 00 Jobs: 1 (f=1): [m(1)][88.9%][r=45.6MiB/s,w=15.1MiB/s][r=11.7k,w=3878 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][93.2%][r=85.6MiB/s,w=28.6MiB/s][r=21.9k,w=7314 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][95.5%][r=83.2MiB/s,w=27.7MiB/s][r=21.3k,w=7083 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][97.7%][r=58.7MiB/s,w=19.3MiB/s][r=15.0k,w=4949 IOPS][eta 0 Jobs: 1 (f=1): [m(1)][100.0%][r=95.2MiB/s,w=31.1MiB/s][r=24.4k,w=7958 IOPS][eta 00m:00s]
test1: (groupid=0, jobs=1): err= 0: pid=2362: Fri Mar 18 14:51:26 2022
read: IOPS=17.7k, BW=69.3MiB/s (72.7MB/s)(3070MiB/44286msec)
bw ( KiB/s): min= 1672, max=121512, per=100.00%, avg=71080.38, stdev=29637.7 2, samples=88
iops : min= 418, max=30378, avg=17770.08, stdev=7409.44, samples=88
write: IOPS=5930, BW=23.2MiB/s (24.3MB/s)(1026MiB/44286msec); 0 zone resets
bw ( KiB/s): min= 480, max=39760, per=100.00%, avg=23753.33, stdev=9862.59, samples=88
iops : min= 120, max= 9940, avg=5938.33, stdev=2465.64, samples=88
cpu : usr=2.05%, sys=14.86%, ctx=360549, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=69.3MiB/s (72.7MB/s), 69.3MiB/s-69.3MiB/s (72.7MB/s-72.7MB/s), io=30 70MiB (3219MB), run=44286-44286msec
WRITE: bw=23.2MiB/s (24.3MB/s), 23.2MiB/s-23.2MiB/s (24.3MB/s-24.3MB/s), io=10 26MiB (1076MB), run=44286-44286msec
Disk stats (read/write):
sda: ios=783608/261914, merge=0/8, ticks=1782695/978268, in_queue=2746484, uti l=99.35%Zitatread: IOPS=32.7k, BW=128MiB/s (134MB/s)(3070MiB/24028msec)
write: IOPS=10.9k, BW=42.7MiB/s (44.8MB/s)(1026MiB/24028msec); 0 zone resets
Ich finde 134 MB/s read eigentlich nicht "dürftig"
ZitatNach drei Stunden noch mal einen Test durchgeführt und es macht anscheinend überhaupt keinen Unterschied ob VPS oder Root, die Werte brechen teilweise für mehrere Sekunden auf unter 1MB/s.
Vielleicht testen auf den Host zu viele die Festplatte. 
aRaphael, ja finde ich auch, nicht dürftig.
Aber das dann die write Werte so stark abfallen, auf unter 1MB/s das geht nicht. Da hätte ich deutlich mehr erwartet von der 9.5er Serie.
READ: bw=69.3MiB/s (72.7MB/s), 69.3MiB/s-69.3MiB/s (72.7MB/s-72.7MB/s), io=30 70MiB (3219MB), run=44286-44286msec
WRITE: bw=23.2MiB/s (24.3MB/s), 23.2MiB/s-23.2MiB/s (24.3MB/s-24.3MB/s), io=10 26MiB (1076MB), run=44286-44286msecDie CPU ist aber top, da hat Netcup nicht zu wenig versprochen, eher zu viel des guten.
Aber das dann die write Werte so stark abfallen, auf unter 1MB/s das geht nicht. Da hätte ich deutlich mehr erwartet von der 9.5er Serie.
Ja, das ist leider das prinzipielle Problem bei den virtualisierten Systemen hier.
Man hat zwar in der Regel durchaus gute Durchschnittswerte, was die Festplattenperformance angeht und bei den G9.x auch sehr gute mittlere Werte bei der Netzwerk-Bandbreite, aber es wird bei beidem immer temporäre Flaschenhälse geben, an denen die Performance einbricht, wenn alle gleichzeitig die Ressourcen nutzen.
Das lässt sich ja auch gar nicht vermeiden.
Für die Fälle, in denen ich garantiert immer die vollen Ressourcen brauche, nehme ich mir dann ein echtes Blech.
Ja, das ist leider das prinzipielle Problem bei den virtualisierten Systemen hier.
Ein kleines bisschen kann man das positiv beeinflussen, indem man darauf achtet, dass man ohne Swap-Space auskommt, welcher ansonsten bei länger laufenden KVM-Instanzen doch irgendwann einmal vollläuft und nicht ohne weiteres wieder freigegeben wird. (Betrifft aber insbesondere die älteren SAS-Modelle.)
Und wie kürzlich in einem anderen Diskussionsfaden erwähnt: Auch der Einsatz von tmpfs lohnt sich.
FYI: Famous NPM Package Deletes Files To Protest Ukraine War
Ich möchte aufgrund eigener/früherer Erfahrungen Dritter, aber auch der unlängst wieder im Forum angesprochenen Problematik der „Unzuverlässigkeit“ einiger GeoIP-Datenbanken, die individuelle IP-Adressen in abweichenden Regionen verorten können (aufgrund nicht-zeitnaher, vernachlässigter Datenpflege), daran erinnern, dass Provider, welche betriebsbedingt IPv4-Adressblöcke erstehen, aber nur begrenzt Einflussnahme über die obige Datenhaltung haben (insbesondere, wenn es um „inoffizielle Kopien“ auf Drittservern geht) und deren Kunden damit konfrontiert sein können, dass Schadcode auf Basis der obigen Verhaltensweise insbesondere eben auch Server in D/A/CH angreifen kann.
Via Twitter habe ich einmal beim @BSI_Bund angefragt, ob dort entsprechende Warnungen aufgrund des obigen Vorfalls in Betracht gezogen werden. Mal sehen, ob es eine Antwort gibt.
dass Provider, welche betriebsbedingt IPv4-Adressblöcke erstehen, aber nur begrenzt Einflussnahme über die obige Datenhaltung haben
irgendwo ist mal sinngemäß folgendes gestanden:
"man soll den User-Agent beim ausliefern von HTML nicht berücksichtigen, der User-Agent weiß selbst wie er damit umzugehen hat"
selbiges gilt auch für die IP[v6]-Adresse;
und da ja anscheinend ein Wildwuchs dieser sogenannten Geolocation Datenbanken¹ exisitert; zumal ja nichtmal aus dem WHOIS eindeutig ersichtlich sein muss,
zu welchem Land eine IP gehört, ist es nur eine Frage der Zeit, bis hier mal was gröberes passiert;
ein automatisches Abklopfen des Clients durch den Webserver ist da dann das kleinere Problem;
(aber auch sowas hatte ich vor x Jahren mal beim Ansurfen von spiegel.de erlebt);
¹ bei Maxmind beantrage ich jedesmal wenn sich meine IPv4 ändert eine Datenänderung - ist auch nervig,
wenn z.B. jedesmal in der Zeitung Inhalte aus einer anderen Region des selben Landes kommen;
aber wo muss man da noch überall aktiv werden, dass die Daten geändert werden;
Mal sehen, ob es eine Antwort gibt.
man wird davon vermutlich völlig überrascht tun und dann mindestens solange darüber nachdenken, wie in der causa kaspersky. 
in der manpage werd ich nicht schlau, kann ich da auch eine Regular expression od. so angeben?
z.B. "ip(6)?tables:"
BRE und ERE regexe sind erlaubt. tester -> https://www.rsyslog.com/regex/
in der manpage werd ich nicht schlau, kann ich da auch eine Regular expression od. so angeben?
https://www.rsyslog.com/doc/v8-stable/configuration/filters.html
ich habe testweise ein Ubuntu 20.04.4 LTS laufen (mein erstes Ubuntu).
Nach dem Login bekomme ich ein paar Sysinfos. Wo kommen die her?
ich habe bereits die ~/.profile ~/.bash.rc sowie die Pendants in /etc durchsucht
finde aber nichts
extremmichi Diese Dateien gibt es doch (mit leicht unterschiedlichem Namen) auch systemweit in /etc?
Ich würde dort mal suchen...
Blödsinn, hast Du ja schon geschaut. Ich sollte bis zum Ende lesen 
EDIT: Dürfte das PAM-Modul für die MOTD sein...
https://kofler.info/ubuntus-ssh-login-nachrichten-reduzieren/
Vielleicht kann mir ja hier jemand helfen.
Wieso tut Stop-Process in diesem Kontext nichts? Alleinstehend kein Problem; powerpnt.exe ausführen ist auch kein Problem.
$filewatcher = New-Object System.IO.FileSystemWatcher
$filewatcher.Path = ""
$filewatcher.Filter = "pp*.pptx"
$filewatcher.IncludeSubdirectories = $true
$filewatcher.EnableRaisingEvents = $true
$writeaction = {
Stop-Process -Name "powerpnt"
$path = $Event.SourceEventArgs.FullPath
powerpnt.exe /S $path
}
Register-ObjectEvent $filewatcher "Created" -Action $writeaction
while ($true) {sleep 5}ip6tables -t mangle -A FORWARD -i LANDEV -o WANDEV -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1281:1536 -j TCPMSS --set-mss 1280
Kruzifix, das funktioniert tatsächlich. Ich verstehe zwar was da passiert, aber der Zusammenhang wie das jetzt das Problem löst (bzw. was überhaupt das Problem war) erschließt sich mir noch nicht ganz.
Kannst mir kurz jemand die Sprünge helfen?
EDIT: Nach ein bisschen Try and Error - ich komme mit 1433-1536 hin und ner neuen MSS von 1432. Bei 1492er MTU aufm PPPoE Interface.
EDIT 2: Also was ich jetzt rausgefunden habe, ist, dass die MSS im Normalfall scheinbar bei 1440 liegt. Sprich, der Webserver vom Forum kommt damit nicht klar und frisst nur eine maximale MSS von 1432? O.o
whoami0501 Moderatoren
...
Also note that MSS clamping is a hack and is only needed if you have broken end-user applications.
könnte sich mal jemand diesem Problem annehmen?
weil es ist auch unlogisch ist, dass z.B. ein curl -6 -I https://forum.netcup.de/
von einem vServer außerhalb des netcup-Netzes ohne dem hack funktioniert,
aber kein ping6 forum.netcup.de;
von innerhalb des netcup-Netzes (z.B. einem vServer) funktioniert der IPv6-Ping hingegen;
Ich würde MSS Clamping nicht auf die end-user Applikationen reduzieren. Das Problem entsteht, wenn ICMPv6 Nachrichten nicht durchkommen. Entweder werden sie nicht vom Server generiert, oder sie werden auf dem Weg zum Client geblockt.
Sorry, da war ich ungenau. Es betrifft beide Richtungen. ICMPv6 Nachrichten müssen bi-direktional sauber durchkommen.
