Debian GNU/Linux

Leírás

A Debian GNU/Linux használatával, adminisztrálásával kapcsolatos kérdések és válaszok fóruma.

Kdump +crash - Debian

Fórumok

Sziasztok!

épp kdump-ot állítok be egy régebbi szerveren (Linux P 4.19.0-6-686-pae #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) i686 GNU/Linux), kisebb nagyobb sikerrel és a segítségeket szeretném kérni.

A crash dumpok létrejönnek egy kiprovokált kernel-panic után, viszont nem tudom megnézni a dump fileokat. Crash file-ok:
/var/crash/:
összesen 16
drwxr-xr-x 2 root root 4096 okt 16 14:44 201910161444
drwxr-xr-x 2 root root 4096 okt 17 12:14 201910171214
-rw-r--r-- 1 root root 273 okt 17 12:16 kexec_cmd

/var/crash/201910161444:
összesen 26672
-rw------- 1 root root 52793 okt 16 14:44 dmesg.201910161444
-rw------- 1 root root 27256695 okt 16 14:44 dump.201910161444

/var/crash/201910171214:
összesen 33964
-rw------- 1 root root 51742 okt 17 12:14 dmesg.201910171214
-rw------- 1 root root 34725070 okt 17 12:14 dump.201910171214

Az egyikről bővebben:
# file ../201910171214/dump.201910171214
../201910171214/dump.201910171214: Kdump compressed dump v6, system Linux, node , release 4.19.0-6-686-pae, version #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20), machine i686, domain (none)

A crash meg sem tudja nyitni a dump-ot, mert szerinte nem matchel a kernellel:
# crash /usr/lib/debug/lib/modules/4.19.0-6-686-pae/vmlinux /var/crash/201910171214/dump.201910171214

crash 7.2.5
Copyright (C) 2002-2019 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

crash: page excluded: kernel virtual address: c194a9e4 type: "possible"
WARNING: cannot read cpu_possible_map
crash: page excluded: kernel virtual address: c194a9dc type: "present"
WARNING: cannot read cpu_present_map
crash: page excluded: kernel virtual address: c194a9e0 type: "online"
WARNING: cannot read cpu_online_map
crash: page excluded: kernel virtual address: c194a9d8 type: "active"
WARNING: cannot read cpu_active_map
crash: page excluded: kernel virtual address: c18bd79c type: "pv_init_ops"
crash: page excluded: kernel virtual address: c1a832a8 type: "shadow_timekeeper xtime_sec"
crash: page excluded: kernel virtual address: c18b11c4 type: "init_uts_ns"
crash: /usr/lib/debug/lib/modules/4.19.0-6-686-pae/vmlinux and /var/crash/201910171214/dump.201910171214 do not match!

Usage:

crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)

Enter "crash -h" for details.

Találkoztatok már ilyennel?

Üdv.:
V007

Kdump +crash - Debian

Fórumok

Sziasztok!

épp kdump-ot állítok be egy régebbi szerveren (Linux P 4.19.0-6-686-pae #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) i686 GNU/Linux), kisebb nagyobb sikerrel és a segítségeket szeretném kérni.

A crash dumpok létrejönnek egy kiprovokált kernel-panic után, viszont nem tudom megnézni a dump fileokat. Crash file-ok:
/var/crash/:
összesen 16
drwxr-xr-x 2 root root 4096 okt 16 14:44 201910161444
drwxr-xr-x 2 root root 4096 okt 17 12:14 201910171214
-rw-r--r-- 1 root root 273 okt 17 12:16 kexec_cmd

/var/crash/201910161444:
összesen 26672
-rw------- 1 root root 52793 okt 16 14:44 dmesg.201910161444
-rw------- 1 root root 27256695 okt 16 14:44 dump.201910161444

/var/crash/201910171214:
összesen 33964
-rw------- 1 root root 51742 okt 17 12:14 dmesg.201910171214
-rw------- 1 root root 34725070 okt 17 12:14 dump.201910171214

Az egyikről bővebben:
# file ../201910171214/dump.201910171214
../201910171214/dump.201910171214: Kdump compressed dump v6, system Linux, node , release 4.19.0-6-686-pae, version #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20), machine i686, domain (none)

A crash meg sem tudja nyitni a dump-ot, mert szerinte nem matchel a kernellel:
# crash /usr/lib/debug/lib/modules/4.19.0-6-686-pae/vmlinux /var/crash/201910171214/dump.201910171214

crash 7.2.5
Copyright (C) 2002-2019 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

crash: page excluded: kernel virtual address: c194a9e4 type: "possible"
WARNING: cannot read cpu_possible_map
crash: page excluded: kernel virtual address: c194a9dc type: "present"
WARNING: cannot read cpu_present_map
crash: page excluded: kernel virtual address: c194a9e0 type: "online"
WARNING: cannot read cpu_online_map
crash: page excluded: kernel virtual address: c194a9d8 type: "active"
WARNING: cannot read cpu_active_map
crash: page excluded: kernel virtual address: c18bd79c type: "pv_init_ops"
crash: page excluded: kernel virtual address: c1a832a8 type: "shadow_timekeeper xtime_sec"
crash: page excluded: kernel virtual address: c18b11c4 type: "init_uts_ns"
crash: /usr/lib/debug/lib/modules/4.19.0-6-686-pae/vmlinux and /var/crash/201910171214/dump.201910171214 do not match!

Usage:

crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)

Enter "crash -h" for details.

Találkoztatok már ilyennel?

Üdv.:
V007

Samba + AD auth cachelve?

Fórumok

Hi!

Egy samba-t kellene felállítanom az egyik telephelyre, melynek a 100km-re lévő AD-ből kellene a userek engedélyét lekérni/ellenőrizni. A problémás résznek a "távolsági kapcsolatot" érzem: mi történik akkor, ha nem elérhető az AD szerver? Ez esetben a samba mellett lévő cliensek nem tudják elérni a samba megosztásait, mert nem tudnak auth-olni?
Aki épp bent van a samba-n, az gondolom még egy ideig tudja használni....

Szóval a kérdésem, hogy van arra lehetőség, hogy az AD usereit a samba-n cache-ljem?

Illetve, mi a fenti problémára a megoldás? (stabil netkapcsolaton kívül ;-) )

Előre is köszönök minden ötletet, javaslatot linkelt leírást!

PHP GD memóriakezelés

Fórumok

A PHP imagecreatefromjpeg() utasítása a Debian 9 disztribúcióval szállított PHP 7.0 alatt úgy működik, hogy nem tölti be a képet a memóriába. Más, helyben fordított PHP verziókkal azonban a parancs annyi memóriát felhasznál, amekkora a kép tárolásához szükséges, ugyanazon php.ini mellett is.
Egy régebbi Ubuntu disztribúcióban az 5.3-as PHP ugyanígy viselkedik, azaz az imagecreatefromjpeg() parancs külön memória allokálása nélkül nyitja meg a képet.
Kerestem a php fordítási opciói között olyan paramétert, amivel ezt befolyásolni tudom. Nem találtam.
Tud valaki magyarázatot a jelenségre? Hogyan oldhatom meg, hogy az általam fordított php ugyanúgy kezelje a képeket, mint a disztribúció által fordított?
Én egy 3000x2000 pixeles jpg képpel teszteltem, a következő PHP kóddal:


<?php
printf( 'Php verzio: %s Memory_limit:%s<br>', phpversion(), ini_get( 'memory_limit' ) );
printf( 'Start: %dKB<br>', round(memory_get_usage()/1024) );
list($w, $h) = getimagesize( 'src.jpg' );
$orig = imagecreatefromjpeg( 'src.jpg' );
printf( 'Size (%dx%d): %dKB<br>', $w, $h, round(memory_get_usage()/1024) );

A kimenetem pedig a disztribúció 7.0-ás php moduljával:


Php verzio: 7.0.33-0+deb9u3 Memory_limit:64M
Start: 352KB
Size (3000x2000): 354KB

Más PHP-k esetén azonban kb 30MB memória szükséges a végén.

ClamAV kérdés

Fórumok

Ma frissítettem egy Debiant, és feltelepült (frissült) ez a jószág: ClamAV 0.101.4/25590/Wed Oct 2 10:31:24 2019

A bejövő levelekre a frissítés óta ez a hiba jön:


Oct 2 04:16:57 mail amavis[993]: (00993-01) (!)WARN: all primary virus scanners failed, considering backups
Oct 2 04:19:21 mail amavis[992]: (00992-02) (!)connect to /var/run/clamav/clamd.ctl failed, attempt #1: Can't connect to a UNIX socket /var/run/clamav/clamd.ctl: No such file or directory
Oct 2 04:19:22 mail amavis[992]: (00992-02) (!)connect to /var/run/clamav/clamd.ctl failed, attempt #1: Can't connect to a UNIX socket /var/run/clamav/clamd.ctl: No such file or directory
Oct 2 04:19:22 mail amavis[992]: (00992-02) (!)ClamAV-clamd: All attempts (1) failed connecting to /var/run/clamav/clamd.ctl, retrying (2)
Oct 2 04:19:28 mail amavis[992]: (00992-02) (!)connect to /var/run/clamav/clamd.ctl failed, attempt #1: Can't connect to a UNIX socket /var/run/clamav/clamd.ctl: No such file or directory
Oct 2 04:19:28 mail amavis[992]: (00992-02) (!)ClamAV-clamd av-scanner FAILED: run_av error: Too many retries to talk to /var/run/clamav/clamd.ctl (All attempts (1) failed connecting to /var/run/clamav/clamd.ctl) at (eval 98) line 613.\n


Operating System: Debian GNU/Linux 9 (stretch)
Kernel: Linux 4.9.0-11-amd64
Architecture: x86-64

/var/run/clamav# ls -l
srw-rw-rw- 1 clamav clamav 0 okt 2 04:26 clamd.ctl

Rákeresve a hibára a Google-el, volt ilyen már 2011-ben, 2016-ban, stb... többféle megoldással, de egyik sem illik most ide. Átmenetileg az amavis-ban kikapcsoltam a vírusellenőrzést, így már megérkeznek a bejövő levelek.

Valaki futott mostanság ebbe bele?

Köszönöm

Grafana és a TS3 szerver

Fórumok

Sziasztok!

A terv:
Grafana kapjon adatokat a TeamSpeak3-as szerverről egy ilyen dashboardhoz: https://grafana.com/grafana/dashboards/3020

A probléma:
Nagy nehezen sikerült beindítani https://github.com/thannaske/telegraf-teamspeak3 ezt a programot(?), végre egy sudo go run /root/teamspeak.go parancs után mutatja szépen az adatokat a TS szerverről.

Ha csinálok egy tesztet a telegraffal akkor is normálisan mutatja az adatokat:

root@Server5:~# sudo telegraf --config /etc/telegraf/telegraf.conf --input-filter exec --test
2019-09-23T22:04:18Z I! Starting Telegraf 1.12.1
> teamspeak_server,host=Server5,id=1,port=9987 autostart=1,avg_ping=0,bytes_in=12100542,bytes_in_control=121105,bytes_in_keepalive=1865435,bytes_in_speech=10114002,bytes_out=17213273,bytes_out_control=74996,bytes_out_keepalive=1821261,bytes_out_speech=15317016,channels=18,ft_bytes_in_total=35536,ft_bytes_out_total=53599,m_clients=32,online=1,packets_in=136965,packets_in_control=676,packets_in_speech=91878,packets_keepalive_in=44411,packets_keepalive_out=44421,packets_out=184024,packets_out_control=668,packets_out_speech=138935,pl_control=0,pl_keepalive=0,pl_speech=0,pl_total=0,q_clients=1,reserved_slots=1,uptime=18149,v_clients=0 1569276259000000000

Viszont a dashboardon ezek az adatok nem akarnak megjelenni, egyáltalán nem kap adatokat.

Telegraf config:
[[inputs.exec]]
commands = ["sudo go run /root/go/src/github.com/thannaske/telegraf-teamspeak3/teamspeak.go"]

Valaki segítsen légyszi, már nincs ötletem mit kellene vele csinálnom :S

Köszi

webinart felvenni

Fórumok

Holnap és holnapután egy webinart szeretnék követni, de holnap délután nem tudok a gépnél lenni.

Fel szeretném venni, amit mond és mutat az előadó. A cég maga a webinarról nem tudom, készít-e felvételt, de nem osztják meg velünk (feltételezem, nem szeretnék, ha kikerülne).

Az első (és egyetlen) ötletem az, hogy egy screen recordert fogok munkára, felveszi ami a képernyőmön van.
Első akadály: ha nem vagyok a gépnél, akkor is működnie kellene. Ideális esetben a gép észreveszi, hogy történés van, és hagyja békén. Kevésbé ideális esetben megpróbálom mindenhonnan kivenni a képernyő kikapcsolás meg sleep meg automatikus lockolás és hasonló beállításokat.

Második: google hozott nekem millió találatot (na jó, ilyeneket, hogy a top 20 screen recorder linux alá).

Nincs időm holnap reggelig végigpróbálgatni 20-at vagy többet, ezért arra vagyok kíváncsi, mi az, ami bejött nektek. Esetleg azt is, hogy miért

Peremfeltételek: ez egy tanfolyam, reggeltől estig tart, szóval órákon át kell a felvételt készíteni. Ezt valahogy úgy kellene becsomagolni on the fly, hogy ne fussak ki tárhelyből. A kész anyagot nfs-en felmountolt NAS-ra kellene menteni. A NAS-on van 800G hely, a laptopom csak 13G, félek, ebből egy sok órás HD felvétel kifutna.
Vas: egy 9 éves HP laptop. OS: Debian stable. KDE5-öt használok.

Túlmelegedés

Fórumok

Van egy laptopom. Új korában is hajlamos volt a túlmelegedésre, bár akkor főleg Windows alatt jelentkezett a probléma (pl. tömörítéskor). Pár éves korában, még a 3 éves garancia lejárta előtt ki is jött egy ember a HP-től és kicserélte a hűtés pár alkatrészét, megtakarítgatta, javult a helyzet. Nem állt le ugyanattól a terheléstől.

Közben eltelt megint 6 év, és most már kezd megint nem rendesen hűlni. Persze most már nem garanciális, maximum a ventilátor elé beszorult pormacskákat tudom kiporszívózni, meg a rátettem egy dokkolóra, így az alján a ventilátor másik nyílása is kb. két ujjnyi magasan lett (ezt megfigyeltem, hogy ha az asztalon van, köszködik a levegő beszívásával, felpolcolva lényegesen jobban hűt.

A lényeg az, hogy mostanában ha pl. elindítok egy video tömörítést, akkor kiírja, hogy elmolyol rajta 2-3 órát, de kb. 1 óra munka után kikapcsol, hogy megvédje saját magát.

A kérdésem az, hogy a mechanikus javítgatások mellett (beütemeztem egy új porszívózást, ráirányítok majd egy külső ventilátort) szoftveresen milyen lehetőségeim lehetnek.

Amennyiben nem kritikus, hogy mennyi idő alatt végez (mert mondjuk este elindítom és csak az érdekel, hogy reggelre legyen kész, az nem, hogy 2, 3 vagy 6 óra kellett hozzá), van-e valami olyan módszer, amivel korlátozni tudom a melegedést?

Olyasmik jutottak eszembe, hogy elindítom konzolról, és ha melegnek tűnik, akkor kézzel felfüggesztem a processzt (de ehhez persze figyelni kell órákon át, messze nem az ideális megoldás).
Vagy ugyanezt automatizálva: időzítve vagy valami hőmérsékletet figyelve suspend ha hűteni kell, kis várakozás után resume.

Vagy van-e esetleg olyan beállítás, amivel azt lehet mondani, hogy adott processz csak a processzor negyedét, nyolcadát használhatja?
Esetleg leveszem a max órajelet a minimumra, aztán tovább tart de kevésbé melegszik.
Vagy bármi hasonló, ami most segíteni tudna?

HP8440p, i7 (2010 vagy 2011-es), 4G RAM. Mostanában főleg linuxszal használom.

[MEGOLDVA] Debian 10 courier-imap-ssl csomag eltünt

Fórumok

Már megint valami változott. A Debian 6.x szerverke építésnél, még az imap szerver telepítését úgy kezdtem hogy telepítettem a courier-imap-ssl csomagot, ami húzta magával a többit. Most már nincs ilyen csomag.
Hol tudom megnézni mi történt ezzel?

Anno, mivel a Debian rendszerekben az "alapértelmezett" mta az exim4 az imap funkcionalitást a courier-imap biztosította. Lehet valami más "kombót" kéne használnom?
A régi rendszerből átbogarászni >14G levelezést egy másik imap szerverbe ijesztőnek találom.

SZERK: Erősen túl dimenzionált. Sok felesleges körrel.
Végeredmény: courier helyett dovecot és az egyszerű perl sciptel konvertált IMAP könyvtár konverziója, helyben.

Régi szerverm megújítás vagy ránc felvarrás

Fórumok

Próbálok életet lehelni a régi Debian 6.x szerverembe - újra építem az egészet Debian 10 -re, vas csere nélkül.
Folyton furcsa hibákba ütközök (hplip nem akar printer portról szkennelni, nut dumb/simple kommunikációval nem működik a "gyári" systemd script készlet, még jóü hogy már nem kell FAX - email bridget építeni).
Viszont, a window 10, a Debian 10 -en futó böngészők (Chrome, Firefox) kidobják a "mókus postát" vagy a samba -t mert mind elavult, self signed certificate stb.
Van amit a kliens szinten meg lehet oldani, de pl. egy "jól felépített" vállalati gépen a mókus postát nem lehet megnyitni (olyan veszélyes).

A kérdés az, hogy legalább átmenetileg, meg lehet oldani, hogy a szigorúbb biztonsági beállításoknak megfeleljen a https (gondolom apache2) és a mókus posta?