[debian etch] clamd 100% cpu usage

maandag 28 juli 2008 14:18

Ik zou eerst eens de laatste versie van clamav installeren, dit is versie 0.93.3.

Je zou eens strace kunnen uitvoeren (strace -o /tmp/dump -P $pid_van_clamd) als de CPU piekt. In het bestand /tmp/dump moet je dan kunnen zien wat ie allemaal aan het doen is.

Acties:

maandag 28 juli 2008 14:23

are we there yet?

Topicstarter

De nieuwste versie wordt "lastig", omdat ik de etch release van debian volg. Maar als ik dit probleem niet opgelost krijg, is dat mijn laatste redmiddel. Gelukkig komt Lenny in september; misschien maakt dat nog iets uit.

Anyway, met strace krijg ik continue zulke output:

code:

read(9, "148a8b:Trojan.Hupigon-2835\n26880"..., 4096) = 4096
read(9, "0c6f743eaba0:Trojan.Proxy-600\n21"..., 4096) = 4096
read(9, "78:Trojan.Downloader-7333\n13312:"..., 4096) = 4096
read(9, "61f83b6b60:Worm.VB-185\n86016:d33"..., 4096) = 4096
read(9, "0d089c26454f790d:Worm.VB-195\n860"..., 4096) = 4096
read(9, "5:Worm.VB-227\n155648:9dc96c7a525"..., 4096) = 4096
read(9, "30f47dd6382:Trojan.Downloader-75"..., 4096) = 4096
brk(0xab30000)                          = 0xab30000
read(9, "jan.Downloader-7633\n5120:52436ff"..., 4096) = 4096
read(9, "cf771697cc9c16eb81384c0055a28:Tr"..., 4096) = 4096
read(9, ":Trojan.Downloader-7604\n10752:f9"..., 4096) = 4096
read(9, "3f9394f426:Trojan.Hupigon-2939\n3"..., 4096) = 4096
read(9, "05af8d7d5b3bb7a:Trojan.Spy-6710\n"..., 4096) = 4096
read(9, "7d4221be0c3f25ee0af26:Trojan.Ban"..., 4096) = 4096
read(9, "b:Trojan.Spy-6789\n11776:0ee98a78"..., 4096) = 4096
read(9, "23552:d87ec45c699949f870aab159cc"..., 4096) = 4096
read(9, ":762d862693f69922dbaad85e8ace0de"..., 4096) = 4096
read(9, "2f4:Trojan.DNSChanger-534\n512:76"..., 4096) = 4096
read(9, ":Trojan.Bancos-4439\n379904:5a066"..., 4096) = 4096
read(9, "9374b1ca971c1d:Trojan.Downloader"..., 4096) = 4096
read(9, "d22dd5102f94:Trojan.Spy-7134\n225"..., 4096) = 4096
read(9, "bdb0511ee17e5359:Trojan.Bancos-4"..., 4096) = 4096
read(9, "rojan.Spy-6904\n926720:c3b2e42b2f"..., 4096) = 4096
read(9, "Trojan.DNSChanger-541\n33280:1fbe"..., 4096) = 4096
read(9, ":Trojan.Rukap-177\n417792:c2705f9"..., 4096) = 4096
read(9, "92651d5709:Trojan.Downloader-774"..., 4096) = 4096
read(9, "771:Trojan.Delf-837\n270848:3516c"..., 4096) = 4096
read(9, "bdbc3e038da80656c72155df52531:Tr"..., 4096) = 4096
read(9, "214bf41c91925eaf9e22add534d:Troj"..., 4096) = 4096
read(9, "096:16dc3aaeae2f4c329c13c4c37303"..., 4096) = 4096
read(9, "an.Agent-4370\n42496:fb0a0d490f06"..., 4096) = 4096
brk(0xab51000)                          = 0xab51000
read(9, "20e6b:Trojan.SdBot-5924\n24520:75"..., 4096) = 4096
read(9, "8:d07a491b4ee6cbb7f3b3c1cc579c18"..., 4096) = 4096
read(9, "705deba5a7ee2987cbc68d61:Trojan."..., 4096) = 4096
read(9, "er-8016\n590848:20199ce716c3f7f45"..., 4096) = 4096
read(9, "ba23facdd225:Trojan.Hupigon-3084"..., 4096) = 4096
read(9, "e68759ee4a2318f2535b4bdbfbf:Troj"..., 4096) = 4096
read(9, "223665da6f14a9b03ad7ebd:Trojan.D"..., 4096) = 4096

Lijkt erop dat er vanalles ingeladen wordt, maar zeker weten doe ik het niet.

Acties:

maandag 28 juli 2008 15:07

Ja, je moet het niet meteen draaien als clamd wordt gestart. Dan leest ie volgens mij die virus definitie database in of wanneer ie een signaal krijgt van clamupdate o.i.d.

Ik zou het gedurende 1 of 2 minuten draaien, en die output bekijken of ergens online zetten.

Ik weet niet of er tussen 0.90 en 0.93 iets veranderd is dat relevant is voor jou, maar misschien kan je ergens een backport vinden vanuit unstable? (Zonder dat je meteen 100 andere libs moet upgraden).
Of anders zal vanaf source bakken als je dat lukt.

Acties:

maandag 28 juli 2008 15:23

are we there yet?

Topicstarter

vanaf source bakken kan inderdaad ook nog. Dat is verder geen probleem. Maar ik ga eerst eens kijken naar die dependencies. Heel soms valt het mee en kan ik .deb bestand downloaden en los installeren.

Wat betreft strace: ik heb het proces ruim 25 minuten laten draaien, en mijn dump blijft eruit zien zoals hierboven weergegeven. Het blijft "doorscrollen".

Acties:

maandag 28 juli 2008 15:52

Trax_Digitizer schreef op maandag 28 juli 2008 @ 15:07:
vanaf source bakken kan inderdaad ook nog. Dat is verder geen probleem. Maar ik ga eerst eens kijken naar die dependencies. Heel soms valt het mee en kan ik .deb bestand downloaden en los installeren.

Wat betreft strace: ik heb het proces ruim 25 minuten laten draaien, en mijn dump blijft eruit zien zoals hierboven weergegeven. Het blijft "doorscrollen".

Hij leest dus continue die virusdefinities in? En alleen maar dat?

Acties:

maandag 28 juli 2008 15:57

The what goes where now?

Trax_Digitizer schreef op maandag 28 juli 2008 @ 13:14:
Nu blijkt dat clamd 100% CPU usage vreet. Uit de MRTG grafiek blijkt dat dit ongeveer een uur aanhoudt, dan meestal 2 uur (soms 1) verdwijnt, en dan weer een uur lang op 100%. Erg vreemd.

Zit er regelmaat in? Zo ja, wat voor regelmaat? Post desnoods wat van die grafiekjes hier.

Hoeveel mails verwerkt je clamav? Grote mails, kleine mails? Zit er een overeenkomst tussen de hoeveelheid mails en het CPU gebruik van clamav?

Ik draai debian etch en mijn huidige versie van clamav is 0.90.1.

Welke clamav packages heb je precies geinstalleerd, en welke versies precies?

Iemand enig idee waar ik het kan zoeken? Ik verwacht zelf dat het niks met de kernel te maken heeft, maar omdat het toevallig samenvalt met het in gebruik nemen van een nieuwe kernel, vind ik dat wel de moeite waard om even te melden.

Als je je webcam even kunt missen, dan zou je een dag ofzo met de oude kernel kunnen draaien. Als clamav zich dan koest houdt, dan is die kernel de moeite van verder onderzoek waard

smesjz schreef op maandag 28 juli 2008 @ 13:34:
Ik zou eerst eens de laatste versie van clamav installeren, dit is versie 0.93.3.

Dat lijkt me nou niet zo handig, al was het maar omdat je dan geen Debian updates van clamav meer krijgt. Bovendien wordt de versie die in Etch zit natuurlijk door veel meer mensen gebruikt, dus het is waarschijnlijk dat hij echt wel normaal moet kunnen werken.

smesjz schreef op maandag 28 juli 2008 @ 15:23:
Hij leest dus continue die virusdefinities in? En alleen maar dat?

Hmm, hoe weet je zeker dat dat het inlezen van virusdefinities is?

Acties:

maandag 28 juli 2008 16:19

are we there yet?

Topicstarter

Zojuist die dumpfile van 1,2 MB eens doorgelezen. Ik zie wel wat andere dingen staan. Hieronder niet de volledige logfile maar wel een overzicht van verschillende soorten informatie die elkaar opvolgen.

1. Het begint met flink aantal read 9 entries zoals hierboven weergegeven.

2. Op een gegeven moment komt dit voorbij:

code:

read(9, "7b1796ca9e499d521371b5ba262804f9"..., 4096) = 569
read(9, "", 4096)                       = 0
close(9)                                = 0
munmap(0xb7ef2000, 4096)                = 0
open("/var/lib/clamav/daily.inc/daily.zmd", O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=2922, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000
read(9, "Worm.Bagle.Gen-3-zippwd:1:*:8550"..., 4096) = 2922
brk(0x8685000)                          = 0x8685000
read(9, "", 4096)                       = 0
close(9)                                = 0
munmap(0xb7ef2000, 4096)                = 0
open("/var/lib/clamav/daily.inc/daily.fp", O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=5340, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000
read(9, "d1ef8a0e477570ad39f4667129400b05"..., 4096) = 4096
read(9, "41ded315:1413:2385184\n79c164f814"..., 4096) = 1244
read(9, "", 4096)                       = 0
close(9)                                = 0
munmap(0xb7ef2000, 4096)                = 0
getdents64(8, /* 0 entries */, 4096)    = 0
close(8)                                = 0
fcntl64(7, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
close(7)                                = 0
unlink("/var/lib/clamav/daily.inc/.dbLock") = 0
open("/var/lib/clamav/main.cvd", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=8189490, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef2000
_llseek(7, 0, [0], SEEK_SET)            = 0

3. Waarna het verder gaat met read 7:

code:

read(7, "ClamAV-VDB:31 Dec 2006 13-09 +01"..., 4096) = 4096
read(7, "Z\303\373\343\30\315\223\340`t\365DP;}\354\21\315vu\27"..., 4096) = 4096
read(7, "i\'e:\324\3\277\253\223\274\207\316H8\366\246K\234\253"..., 4096) = 4096
read(7, "\326;c$\337\3\357=\247-\231E\277\353\371\364H<\35\206t"..., 4096) = 4096
read(7, "\'7\221\237R\376\4C\271\35\333\22\233\320\263)N(XI\325"..., 4096) = 4096
read(7, "\350si\376\233=\266\356\330\223\30\306J\223\226\211FS9"..., 4096) = 4096
read(7, "\'\\\331\326^[Z\240\314\366\340A\221D\376\225\343\300r"..., 4096) = 4096
read(7, "\n\30\360r\3268Z3\2753~\1\222!\243\35Z\3015d\332\21\340"..., 4096) = 4096
read(7, "\374\35\347\347\242\3333\234\6@\343\261\'\306b\311\243"..., 4096) = 4096
read(7, "\t\334\242\300V\264*A\177\202\315\230:\373\343\301\231"..., 4096) = 4096

4. Na een tijdje stopt read 7 en komt dit:

code:

read(7, "|\25\330\231\347\25\267\363\304\20:p\273\0\311\345\261"..., 4096) = 1586
read(7, "", 4096)                       = 0
read(7, "", 8192)                       = 0
dup(7)                                  = 8
lseek(8, 512, SEEK_SET)                 = 512
gettimeofday({1217248013, 8249}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
gettimeofday({1217248013, 8397}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
gettimeofday({1217248013, 8522}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
gettimeofday({1217248013, 8650}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
gettimeofday({1217248013, 8776}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
gettimeofday({1217248013, 8901}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
gettimeofday({1217248013, 9026}, NULL)  = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834

5. Na een flink aantal gettimeofday entries komt ineens dit:

code:

gettimeofday({1217248013, 12165}, NULL) = 0
times({tms_utime=10257, tms_stime=12, tms_cutime=0, tms_cstime=0}) = 1740351834
mkdir("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd", 0700) = 0
fcntl64(8, F_GETFL)                     = 0 (flags O_RDONLY)
fstat64(8, {st_mode=S_IFREG|0644, st_size=8189490, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef1000
_llseek(8, 0, [512], SEEK_CUR)          = 0
read(8, "\37\213\10\0\0\0\0\0\0\3\354\275ms\34\267\222&z\276n\307"..., 16384) = 16384
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/COPYING", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000
write(9, "\t\t    GNU GENERAL PUBLIC LICENSE"..., 4096) = 4096
write(9, "sly and appropriately publish on"..., 4096) = 4096
write(9, "ble work, complete source\ncode m"..., 4096) = 4096
write(9, "or by copyrighted interfaces, th"..., 4096) = 4096
write(9, "g with this program; if not, wri"..., 1608) = 1608
close(9)                                = 0
munmap(0xb7ef0000, 4096)                = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/main.db", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000

6. Waarna het verder gaat met write 9 en af en toe een read 8:

code:

write(9, "_0017_0001_000=21b8004233c999cd2"..., 4096) = 4096
write(9, "704e81e\nGen.0099##=038dbe8b058db"..., 4096) = 4096
write(9, "bd274f889960b01\n_0224_0008_000=c"..., 4096) = 4096
write(9, "40b9b200cd21b80157\n_0356_0006_00"..., 4096) = 4096
write(9, "9b80157cd21b43ecd2180be050201\n_0"..., 4096) = 4096
write(9, "0242e88c00b440b92b0490ba0001cd21"..., 4096) = 4096
read(8, "\300S<L\0168\373\302\201c\333\247\253\302\271F\\\232\216"..., 16384) = 16384
write(9, "7f8\nGen.1704.Cascade  - Version "..., 4096) = 4096
write(9, "1b440cd21b43ecd21b409ba3a01cd21c"..., 4096) = 4096
write(9, "268 (Clam)=6035cd2181fb34127403e"..., 4096) = 4096
write(9, "233c933d2cd215e568b441a\nAD-173=4"..., 4096) = 4096
write(9, "570721865ba42d00379f63146e2c7bea"..., 4096) = 4096
write(9, "0072028c8f9200\nAlabama-A=c673072"..., 4096) = 4096
write(9, "01\nAmazon Queen-500=81ed05004444"..., 4096) = 4096
write(9, "9f80080fc30750981fefdcd7503bfcda"..., 4096) = 4096
write(9, "0005a\nAnthrax-A=832e130402cd12b1"..., 4096) = 4096
read(8, "\323\343\335\30\307\306\317bE\336\350\352\340\225\335\230"..., 16384) = 16384
write(9, "90300ba8d00b440cd21b002e81800b94"..., 4096) = 4096
write(9, "03bf6703578bf2807c013a750d8a042e"..., 4096) = 4096
write(9, "0300bab605cd21b80157\nArgentina.1"..., 4096) = 4096
write(9, "0e80200eb208a8637078db63501b9000"..., 4096) = 4096

7. Dan ergens tussendoor dit:

code:

write(9, "0:Trojan.PcClient-89\ne78da303cfd"..., 2588) = 2588
close(9)                                = 0
munmap(0xb7ef0000, 4096)                = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/main.ndb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000
write(9, "Exploit.HTML.ObjectType:3:*:3c6f"..., 4096) = 4096

waarna het weer verder gaat zoals in punt 6, met write 9 en af en toe een read 8

8. Dan komt het volgende:

code:

write(9, "Trojan.Pakes-529:1:S0+80:216b868"..., 1224) = 1224
close(9)                                = 0
munmap(0xb7ef0000, 4096)                = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/main.zmd", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000
write(9, "Worm.Padowor.A-zippwd:1:*:72767:"..., 217) = 217
close(9)                                = 0
munmap(0xb7ef0000, 4096)                = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/main.fp", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000
write(9, "d1ef8a0e477570ad39f4667129400b05"..., 1904) = 1904
close(9)                                = 0
munmap(0xb7ef0000, 4096)                = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/main.info", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 9
fstat64(9, {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000
write(9, "ClamAV-VDB:31 Dec 2006 13-09 +01"..., 276) = 276
close(9)                                = 0
munmap(0xb7ef0000, 4096)                = 0
close(8)                                = 0
munmap(0xb7ef1000, 4096)                = 0
stat64("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
umask(0)                                = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/.dbLock", O_RDWR|O_CREAT|O_TRUNC, 0774) = 8
umask(0)                                = 0
fcntl64(8, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9
fstat64(9, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl64(9, F_SETFD, FD_CLOEXEC)         = 0
getdents64(9, /* 10 entries */, 4096)   = 304
open("/tmp/clamav-bd1ae098a23a4bf3318d6e12d23832bd/main.db", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0666, st_size=4737478, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef1000

9. Waarna het geheel verder gaat met read 10 en na een tijdje verder gaat met read 9 tot EOF, met een vergelijkbare structuur dan in mijn vorige post.

Ik kan er geen chocola van maken...

Acties:

maandag 28 juli 2008 16:42

are we there yet?

Topicstarter

deadinspace schreef op maandag 28 juli 2008 @ 15:52:
[...]

Om even een antwoord te geven op een aantal van je vragen.

ClamAV packages (uit aptitude):

clamav 0.90.1dfsg
clamav-base 0.90.1dfsg
clamav-daemon 0.90.1dfsg
clamav-freshclam 0.90.1dfsg
clamav-testfiles 0.90.1dfsg

het klopt dat de versie overal gelijk is.

Verder denk ik dat ik vanavond laat wel even zou kunnen rebooten met mijn vorige kernel, om te kijken wat er dan gebeurd.

Dan twee plaatjes van CPU usage. Let op: 50% CPU usage in het plaatje is 100% in werkelijkheid. (Ik heb MRTG nog niet lekker aan de praat). Mijn uptime is nu 2 dagen en bijna 16 uur. Je ziet dat het toen ook ongeveer begonnen is. De eerste piek zal komen door het kernelcompilen, daarna de reboot en toen kwamen die "vreemde pieken" erin. Aan het plaatje van de gehele week zie je dat dit gedrag met de oude kernel niet voorkwam. De rare pieken van vanmiddag komen trouwen van het testen.

Dag:
Afbeeldingslocatie: http://www.baaten.com/images/various/clamav_dag.png

Afbeeldingslocatie: http://www.baaten.com/images/various/clamav_dag.png

Week:

(excuses voor eventuele traagheid van de plaatjes)

Acties:

_JGC_

oudere versies van clamav zijn enorm inefficient bij het herladen van de signature database. Dat het bij jou om de 2-3 uren gebeurt is het resultaat van Freshclam die nieuwe signatures ophaalt.

Overigens kan je gewoon de nieuwste clamav voor etch verkrijgen via het Debian volatile project:
http://www.debian.org/volatile/
Bovenstaande URL kan je ook gebruiken voor een iets meer recente versie van Spamassassin.

maandag 28 juli 2008 16:47

Acties:

maandag 28 juli 2008 17:56

_JGC_ schreef op maandag 28 juli 2008 @ 16:42:
oudere versies van clamav zijn enorm inefficient bij het herladen van de signature database. Dat het bij jou om de 2-3 uren gebeurt is het resultaat van Freshclam die nieuwe signatures ophaalt.

Overigens kan je gewoon de nieuwste clamav voor etch verkrijgen via het Debian volatile project:
http://www.debian.org/volatile/
Bovenstaande URL kan je ook gebruiken voor een iets meer recente versie van Spamassassin.

Je zou verwachten dat alleen de daily.cvd (of hourly.cvd) etc wordt ingelezen en dat die paar 100 (at max) gewoon worden toegevoegd aan de definities die op dat moment al in het geheugen staan. Het herladen van de complete main.cvd + daily zal idd wel inefficient zijn.

Ik volgde altijd unstable maar zo'n volatile is voor de wat meer conversatieven onder ons een goede keus. Ben benieuwd of het dit probleem oplost van de TS.

Acties:

maandag 28 juli 2008 21:59

are we there yet?

Topicstarter

Zojuist volatile packages geïnstalleerd (kreeg ook een nieuwe postgrey) en het probleem lijkt opgelost! Veel dank! $_/-\o_$

Hoe dit rare probleem dan ineens ontstaat na een nieuwe kernel is me echter nog steeds onduidelijk...

Acties:

Keeper of the Keys

Ik ben eigenlijk erg nieuwsgierig, als je het toch al een 'bleeding edge' kernel gebruikt en deze machine een desktop is (ik neem tenminste aan dat de webcam aan een desktop hangt) waarom gebruik je dan niet testing of unstable?

maandag 28 juli 2008 23:43

Acties:

dinsdag 29 juli 2008 20:22

are we there yet?

Topicstarter

Deze machine is geen desktop, maar is al ruim 6 jaar server voor meerdere domeinen met "alles erop en eraan". Ik draai debian stable, maar compileer mijn kernel altijd zelf van de meest recente stable source op kernel.org. Ik draai eigenlijk pas sinds kort weer een nieuwere kernel. Heb een tijdje terug de server moeten verhuizen na een uptime van ruim 757 dagen.

En die webcam: die is bedoeld als een soort 'security cam'. En gezien de server 24/7 aan staat is dat voor mij het meest voor de hand liggende systeem om een 'security cam' aan te sluiten. En het werkt prima! :-)

En ik gebruik dus geen testing of unstable, omdat het een server is...

[ Voor 5% gewijzigd door Trax_Digitizer op 28-07-2008 23:45 ]

Acties:

dinsdag 29 juli 2008 22:14

The what goes where now?

Trax_Digitizer schreef op maandag 28 juli 2008 @ 16:19:
ClamAV packages (uit aptitude):
clamav 0.90.1dfsg
clamav-base 0.90.1dfsg
clamav-daemon 0.90.1dfsg
clamav-freshclam 0.90.1dfsg
clamav-testfiles 0.90.1dfsg
het klopt dat de versie overal gelijk is.

Hmm, maar de meest recente versies in Etch + security updates zijn 0.90.1dfsg-3.1+etch14. Pas je de security updates wel toe?

_JGC_ schreef op maandag 28 juli 2008 @ 16:42:
Overigens kan je gewoon de nieuwste clamav voor etch verkrijgen via het Debian volatile project:
http://www.debian.org/volatile/

Volatile is altijd wel een goed idee voor dit soort software ja, maar ik wist niet dat daar naast de nieuwe datafiles ook nieuwere versies van de software (of iig clamav) stonden.

Trax_Digitizer schreef op maandag 28 juli 2008 @ 17:56:
Zojuist volatile packages geïnstalleerd (kreeg ook een nieuwe postgrey) en het probleem lijkt opgelost! Veel dank! $_/-\o_$

Hoe dit rare probleem dan ineens ontstaat na een nieuwe kernel is me echter nog steeds onduidelijk...

Mooi dat het helpt, maar ik snap inderdaad ook niet waarom het (pas?) optrad na een nieuwe kernel

Trax_Digitizer schreef op maandag 28 juli 2008 @ 23:43:
Ik draai debian stable, maar compileer mijn kernel altijd zelf van de meest recente stable source op kernel.org.

Dat hoeft niet altijd een goed idee te zijn. Het QA proces is voor een deel verschoven van de Linux kernel developers naar de vendors (distributeurs), dus kernel.org kernels hebben soms wel eens wat probleempjes.

Bovendien kunnen er bij nieuwere kernels dingen veranderen waar jij of Etch niet op voorbereid is. Denk aan IDE drives die ineens ook maar /dev/sd? zijn gaan heten ipv /dev/hd?, of aan devfs dat verwijderd is (nou heeft Debian nooit default devfs gebruikt, maar toch). Of clamd's die ineens heel veel CPU gaan trekken

En tot slot krijg je natuurlijk geen security updates op je zelfgecompilede kernel.

Heb een tijdje terug de server moeten verhuizen na een uptime van ruim 757 dagen.

En zelf compile je ook al geen nieuwe kernels voor security fixes zo te zien

Acties:

dinsdag 29 juli 2008 22:53

are we there yet?

Topicstarter

Ja zeker pas ik security updates toe. Dat is vaak het enige wat je na een major release aan updates krijgt: security updates. Verder inderdaad vreemd dat het probleem ineens ontstaat na een kernelupdate maar mooi dat het met volatile is opgelost. Wist namelijk niet van het bestaan van volatile af.

Wat betreft de kernel: er zit niet echt een beleid achter. Ik complieer een specifieke kernel voor mijn systeem, met alleen hetgene dat nodig is. Security vind ik redelijk belangrijk, maar het blijft een (erg uit de hand gelopen) hobby. Dus als een kernel niet werkt, problemen geeft of wanneer ik erachter kom dat een bepaald type kernel een lek heeft dan ga ik een over op een nieuwere versie. Werkt het niet; dan ga ik terug op de oude kernel en zoek ik uit waar het probleem ligt. Dus inderdaad geen strak security beleid voor wat betreft de kernel, maar het heeft zeker wel enige aandacht...

Maar misschien inderdaad een leuk idee om eens te kijken naar de kernels uit de Debian release en hoe dat precies in zijn werk gaat. Wat dat betreft leg ik wellicht teveel vertrouwen in de Linux kernel developers. Want van die wijzigingen in het QC proces wist ik namelijk niet. Thanks for the tip.

Acties:

dinsdag 29 juli 2008 23:05

The what goes where now?

Trax_Digitizer schreef op dinsdag 29 juli 2008 @ 22:14:
Ja zeker pas ik security updates toe.

Dan blijf ik het vreemd vinden dat jouw versies van de clamav software niet overeenkwamen met wat ik verwachtte. Kun je eens kijken wat de versies van de volgende packages op jouw systeem zijn?

dpkg -l bind9-host e2fsprogs libdns22 libpcre3 openssh-server tar vim-tiny

Dit zijn de versies die ik verwacht te zien:

ii  bind9-host     9.3.4-2etch3                         Version of 'host' bundled with BIND 9.X
ii  e2fsprogs      1.39+1.40-WIP-2006.11.14+dfsg-2etch1 ext2 file system utilities and libraries
ii  libdns22       9.3.4-2etch3                         DNS Shared Library used by BIND
ii  libpcre3       6.7+7.4-4                            Perl 5 Compatible Regular Expression Library
ii  openssh-server 4.3p2-9etch2                         Secure shell server, an rshd replacement
ii  tar            1.16-2etch1                          GNU tar
ii  vim-tiny       7.0-122+1etch3                       Vi IMproved - enhanced vi editor - compact v

Maar misschien inderdaad een leuk idee om eens te kijken naar de kernels uit de Debian release en hoe dat precies in zijn werk gaat. Wat dat betreft leg ik wellicht teveel vertrouwen in de Linux kernel developers. Want van die wijzigingen in het QC proces wist ik namelijk niet. Thanks for the tip.

Je mag van mij best zelf gecompilede kernels draaien, zolang je je maar bewust bent van de potentiele nadelen.

Het is verder ook niet dramatisch van die stock kernels, maar de primaire 'klanten' van de Linux kernel zijn tegenwoordig de vendors en niet zozeer individuele eindgebruikers. Dat is een beetje geleidelijk verschoven. Het is tegenwoordig ook minder gebruikelijk dan vroeger om stock kenels te draaien.

Acties:

dinsdag 29 juli 2008 23:27

are we there yet?

Topicstarter

Een beetje met de tijd meegaan is nooit verkeerd. Heb deze server nu al bijna 10 jaar, dus op een gegeven moment blijven oude gewoontes gewoon hangen...

Anyway, mijn output van dpkg:

code:

||/ Name                                                  Version
+++-=====================================================-======================
un  bind9-host                                            <none>
ii  e2fsprogs                                             1.39+1.40-WIP-2006.11.
ii  libdns22                                              9.3.4-2etch3
ii  libpcre3                                              6.7+7.4-4
ii  openssh-server                                        4.3p2-9etch2
ii  tar                                                   1.16-2etch1
un  vim-tiny                                              <none>

twee van de door jou geselecteerde pakketten staan niet op mijn systeem...

offtopic: hoe krijg je die quotes zo met die zwarte achtergrond? (kan het niet vinden in de ubb-code lijst...

Acties:

Zwerver

Trax_Digitizer schreef op dinsdag 29 juli 2008 @ 23:05:
Een beetje met de tijd meegaan is nooit verkeerd. Heb deze server nu al bijna 10 jaar, dus op een gegeven moment blijven oude gewoontes gewoon hangen...

Anyway, mijn output van dpkg:
code:
1
2
3
4
5
6
7
8
9
||/ Name                                                  Version
+++-=====================================================-======================
un  bind9-host                                            <none>
ii  e2fsprogs                                             1.39+1.40-WIP-2006.11.
ii  libdns22                                              9.3.4-2etch3
ii  libpcre3                                              6.7+7.4-4
ii  openssh-server                                        4.3p2-9etch2
ii  tar                                                   1.16-2etch1
un  vim-tiny                                              <none>
twee van de door jou geselecteerde pakketten staan niet op mijn systeem...

offtopic: hoe krijg je die quotes zo met die zwarte achtergrond? (kan het niet vinden in de ubb-code lijst...

[cmd] gebruiken....

Maaruh, hoe kan het nou dat je clamd achterliep maar de rest niet? Heb je toevallig een upgrade uitgevoerd die je daarvoor een hele tijd niet gedaan had?

Ik wil overigens wel een kritische noot kraken over je "Security vind ik redelijk belangrijk, maar het blijft een (erg uit de hand gelopen) hobby.". Hangt die machine aan het internet en is die bereikbaar via internet? Dan zou je er meer mee bezig moeten zijn. Linux-machines zijn namelijk de targets als het gaat om hackers en crackers. Dan heb ik het dus niet over spyware en trojans die je per mail binnen krijgt, maar juist aanvallen via scans e.d.

Woonachtig Down Under. Ik negeer je insults niet, maar tegen de tijd dat ik ze lees zijn ze meestal niet relevant meer

dinsdag 29 juli 2008 23:28

Acties:

woensdag 30 juli 2008 04:06

The what goes where now?

Trax_Digitizer schreef op dinsdag 29 juli 2008 @ 23:05:
Anyway, mijn output van dpkg:

Hmm, die versies zijn gewoon wat ik verwacht iig (ik kan alleen niet de volledige versie van e2fsprogs zien, die is afgekapt). Wat geeft het volgende commando?

apt-cache show clamav-daemon | egrep '^Version:'

twee van de door jou geselecteerde pakketten staan niet op mijn systeem...

Dat kan

Ik zou eigenlijk niet weten of bind9-host standaard is, of dat ik die altijd zelf installeer, en als je geen vim gebruikt of juist de volledige versie gebruikt, dan is vim-tiny ook niet echt nodig (maar die is iig wel geinstalleerd na een default Etch install). Ik koos maar wat random packages waarvan ik wist dat er security updates zijn geweest.

offtopic: hoe krijg je die quotes zo met die zwarte achtergrond? (kan het niet vinden in de ubb-code lijst...

[cmd][/cmd]. Dat kun je trouwens ook zien als je 'view' of 'quote' doet op mijn post

Acties:

CyBeR

💩

Trax_Digitizer schreef op maandag 28 juli 2008 @ 17:56:
Zojuist volatile packages geïnstalleerd (kreeg ook een nieuwe postgrey) en het probleem lijkt opgelost! Veel dank! $_/-\o_$

Hoe dit rare probleem dan ineens ontstaat na een nieuwe kernel is me echter nog steeds onduidelijk...

Niet, is een of andere vreemdheid in clamd als 'ie draait met een nieuwer type virusdefinitie dan clamd zelf.

All my posts are provided as-is. They come with NO WARRANTY at all.

woensdag 30 juli 2008 09:13

Acties:

woensdag 30 juli 2008 09:16

are we there yet?

Topicstarter

Wat geeft het volgende commando?

Version: 0.93.1.dfsg-volatile1
Version: 0.90.1dfsg-3.1+etch14
Version: 0.90.1dfsg-3etch11

Dus ik heb toch de nieuwe etch-versie + security update gehad... aptitude laat dus niet de "volledige" versie zien. Althans niet in het overzicht dat ik bekeken heb. (Gebruik normaal geen aptitude, maar doe alles via apt-get)

maar die is iig wel geinstalleerd na een default Etch install

Misschien bij een nieuwe install, maar mijn install is het resultaat van dist-upgrades vanaf Woody en wellicht nog verder terug... Misschien dat ie dan niet meegenomen wordt, omdat ie alleen pakketten upgrade die op je systeem staan.

CyBeR schreef op woensdag 30 juli 2008 @ 04:06:
Niet, is een of andere vreemdheid in clamd als 'ie draait met een nieuwer type virusdefinitie dan clamd zelf.

als ik je goed begrijp, zeg jij dus dat het aan clamd lag en niet aan de kernel?

Acties:

Arnout

Cyber heeft gelijk, ik heb dit laatst ook gezien op een server die met een oude clamav versie draaide en inderdaad bij elke update een half uur tot een uur 100% belasting gaf. 't Rottige is dat als je je mail via clamav hebt lopen, deze ook vertraagt.

woensdag 30 juli 2008 09:44

Acties:

woensdag 30 juli 2008 10:06

are we there yet?

Topicstarter

Dat zou kunnen verklaren dat ik wel eens de indruk kreeg dat mails er langer over deden, wanneer het een lokale bezorging betreft.

Nog even een reactie op een post van Zwerver die ik over het hoofd had gezien:

Hangt die machine aan het internet en is die bereikbaar via internet?

Ja. En ik ben het met je eens dat ik mijn kernel wellicht vaker moet updaten, maar ik vraag af of het echt zoveel uitmaakt wanneer ik de laatste stable van kernel.org pluk of wanneer ik de kernel van debian etch volg. Ok, de compatibiliteit met je bestaande systeem is dan wellicht beter geborgd, maar is het ook aantoonbaar beter in het kader van bijvoorbeeld security?

Acties:

CyBeR

💩

Trax_Digitizer schreef op woensdag 30 juli 2008 @ 09:13:
[...]

als ik je goed begrijp, zeg jij dus dat het aan clamd lag en niet aan de kernel?

Yep, bug in clamav. Doe maar 's een losse clamscan en zie hoe lang dat duurt vs clamscan als je een up-to-date versie hebt.

All my posts are provided as-is. They come with NO WARRANTY at all.

woensdag 30 juli 2008 11:51

Acties: