Debian GNU/Linux

Eljutottam oda, hogy újra felhúztam a samba -t, ami a Debian 9.x buster -ben a 4.9.5 verzió. Gondolom (sajnos most nincs kéznél egy win10 gép sem), hogy erre a win10 is gond nélkül kapcsolódik, nem kell vissza "csalnom" az SMBv1 -et. Viszont, az öreg XP -s gépem, csak úgy tud csatlakozni ha a global szekcióban beállítom hogy:

server max protocol = NT1  - szerintem itt korlátozza SMBv1 -re a protokollt

lanman auth = yes

ntlm auth = yes

Így már megy az XP.

Tudtok valami jobb megoldást?

(Azon kívül, hogy dobjam ki az XP  -t - sok még élő munka van vele/rajta)

A frissen telepített debian buster -en a syslog tele van az ntpd bejegyzésekkel.

Turkáltam a netet de nem találtam használható megoldást az ilyen üzentekre:

ntpd[vlmi PID]: Soliciting pool server 84.2.46.29

Esetleg át lehet irányítani, hogy naplózzon máshova?

Adva van két 1T SATA2 HDD, ami régóta fekszik de még sosem volt használatban.
# sfdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZRX-00A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x1d22a38e

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 16001023 15998976 7.6G fd Linux raid autodetect
/dev/sda2 16001024 32002047 16001024 7.6G fd Linux raid autodetect
/dev/sda3 32002048 48003071 16001024 7.6G fd Linux raid autodetect
/dev/sda4 48003072 1953523711 1905520640 908.6G fd Linux raid autodetect

Ugyanaz a típus és partíciók a /dev/sdb
Ezekből készült négy raid1 sw tömb
md1 sda1+sdb1, md2 sda2+sdb2, md3 sda3+sdb3 és md4 sda4+sdb4

Az első szimptóma az volt, hogy valamiért tunya lett a login.
Aztán ránéztem a tömbökre - cat /proc/mdstat és azt láttam, hogy resyncing meg (PENDING).
Az md2 és az md4 még formázva sem volt, az md3 pedig a swap. Miért kell re-szinkronizálni?
Az md4 -et leformáztam, így szépen leszinkronozta a semmit.
Az md3 (swap) végül így indítottam be # mdadm --readwrite /dev/mdX
Leszinkronozott, reboot.
Elkezdett mindenféle hibaüzeneteket küldözgetni a sata alrendszerről.
De bebootolt, viszont az eredmény teljesen érthetetlen a számomra:
md1 sda2+ removed
md2 sda1+sdb1
md3 sda3+sdb3
md4 sda4+sdb4

# mount
/dev/md1 on / type ext4 (rw,relatime,errors=remount-ro)

Hogy tud mountolni és bootolni egy üres (épp csak felformázott) tömb egyik lemezére?

Olyat már láttam és kezeltem ha a tömb egyik lemeze kiesik, de hogy helyet cserél ez nekem teljesen új.
Mit csinálhatok ezzel?
Kezdjem újra az egészet?

A házi szerverkém felújítása zajlik (még mindig).
Régebbi topicban már megoldottam, hogy cups és hplip segítségével működésre bírjam az eléggé öreg multifunkciós lézeremet - nyomtat és szkennel :)
A feladathoz letöltöttem a hplip Debian forrását és újraforgattam paralel port opcióval. A teszt rendszeren jól működik.
Eddig mindig csak windows gépeknek, samba -n keresztül nyújtott printer szerver szolgáltatást, ahol fel lett telepítve a HP1100A driver (sok évig megbízhatóan működött). Most eljutottam oda, hogy szeretném ha a Linux gépeim is tudnának így nyomtatni (eddig ez ritka volt és megoldottam pdf nyomtatással amit a windows kliens kinyomtatott - eléggé nyakatekert de működik).
A Debian wiki szerint, ehhez a "task-printer-server" nevű csomagot kellene feltelepítenem a szerverre. Kipróbáltam a homokozómban dry feltelepíteni a csomagot ami rögtön azzal kezdi, hogy "cups-bsd{a}" aztán olyan dolgok mint "printer-driver-cjet{a}" illetve egy kupac más "printer-driver" kezdetű cuccot, "usb-modeswitch", tcl és tk csomagok, no meg az "xterm{a}".
Kérdés, tényleg kellenek ezek a csomagok amellett, hogy már ott van egy működö cups, hplip, sane és a megfelelő ppd fájl (az az egy ami nekem kell)?
Aztán itt jön a másik oldal, a Debian 9 (egyelőre) kliens amiről én úgy tudtam kell a "cups-browsed". Csak dry megnéztem mit telepítene, nem látok benne printer drivert. Lehet nem is kell? Elvilegf a wiki -ben írnak olyan verzióról ahol a kliensnek nem kell printer driver.
El kéne egy kis segítség.
SZERK: Esetleg tud valaki jó leírást?

Tudom lerágott csont, több fórum bejegyzést átolvastam, 2014-re visszamenőleg. Szeretném ezt kicsit aktualizálni. Tanácsokat kérek - ha tudom megfogadom.
Két 1T diszket, egyformán "aprítottam" négyfelé és tettem raid1 -be, a Debian 10 telepítő segítségével.
Az egyik diszk így fest:
root@nusi:~# sfdisk -l /dev/sda
Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10EZRX-00A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x1d22a38e

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 16001023 15998976 7,6G fd Linux raid autodetect
/dev/sda2 16001024 32002047 16001024 7,6G fd Linux raid autodetect
/dev/sda3 32002048 48003071 16001024 7,6G fd Linux raid autodetect
/dev/sda4 48003072 1953523711 1905520640 908,6G fd Linux raid autodetect

root@nusi:~# sfdisk -V /dev/sda
/dev/sda:
Remaining 1456 unallocated 512-byte sectors.

A grub telepítésekor, kaptam egy üzenetet (sajnos nem tudom szó szerint), hogy az EFI boot -al lehetnek gondok. Semmilyen gond nem volt, gyorsan és megbízhatóan bootol. Mivel a diszk 2T kisebb így az EFI/UEFI -re nincs szükségem. Nem gpt hanem csak dos. A partíciós tábla is ezt igazolja.
Kezdjem újra és gyúrjak EFI -re?
A partíciós táblában az első két partíció rendszer partíció lesz, míg a harmadik a swap és a negyedik a /home lesz. Szerintetek, ráfogom tudni venni az első partícióba telepített grub -al, hogy a második partíciót bootolja?
Az elgondolás az lenne, hogy ha legközelebb distrót kell váltani, azt ellehessen rendezni, mondjuk a második partícióban. Így ha minden kötél szakad akkor visszaléphetek az előző verzióhoz. Nem tervezek mást mint Debian -t de azt már látom, hogy ha hagyom elavulni a rendszert az nagyon fáj - igaz >5 évet húztam a Debian 6 - al soha többé ilyet nem teszek.
Úgy emlékszem, létezik valami minimál grub rendszer, amit esetleg feltehetek egy kisebb partícióra, lehet az jobb mint egy teljes értékű rendszer mindkét rendszer partíción?
A másik nagy kérdés csoport, hogy lehet menteni és visszaállítani egy ilyen rendszert grub bootloader esetén (nem adat/home csak OS)?
A lilo -val jó kapcsolatot alakítottam ki, tudtam komplett rendszert tar archívumból visszarakni és bootolhatóvá tenni. Működhet ez grub -al?

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

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

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!

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.

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