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.

iSPConfig e-mail rekordok

Fórumok

Üdv ismét.

Ha iSPConfig 3-bol honnan tudom, hogy mit kell beállítanom e-mailhez?

Gondolok itt pl: https://mxtoolbox.com/domain/zsolti.hu/

Ezeket a hibákat hogyan tudom javítani?
Miket kell beírogatnom még a dns -hez?

E-mail -> Mail domain -t mikor hozzáadtam, ott bepipáltam: DomainKeys Identified Mail (DKM)
Aztán rányomtam a Generate DKIM Private-key -re, az létrehozta a kulcsot, illetve kiírta a DNS recordot, azt hozzáadtam domainem szolgáltatójának a dns konfigurációjánál.

NGINX lassú

Fórumok

Sziasztok!

Van egy szerverem, ami elég nagy: 8 mag, 16 GB RAM, 2x1 TB HDD... Ezen fut egy Debian 9, VestaCP, de a weboldalak nagyon lassúak rajta. Előzőleg egy másik szerveren volt, és ott sokkal gyorsabb volt.

Néztem a RAM használatot: kb 1,5 GB-ot használ összesen, az előző gépen 3-3,5 GB-ot evett, mégse volt érezhető. Az average load viszont perpill is 3.83. Mondjuk ez se olyan sok, de az előző gépen 0,1-1 között mozgott nagyon max.

A VestaCP nginx+apache+php-fpm -et használ. Tudtok segíteni, miért ilyen dög lassú? Mit nézzek?

Ismerem a weboldalaim sebességét, nagyjából tudom, milyen gyorsnak kell lennie egy-egy oldalnak.

Pl. egy sima WP admin felület úgy 1-2 perc (!) alatt tölt be fullon, azért ennek pikk-pakk be kéne tölteni, de legalább is 20mp -en belül.

Köszönöm előre is a segítségeT.

E-mail fiók tiltása

Fórumok

Sziasztok!

Abban kérném a segítségeteket, hogy hogyan lehetne megoldani azt, hogy a (postfix+dovecot) levelezőrendszerben a felhasználónak ne jöjjenek be a levelek, de felhasználóként még fel tudjon lépni az imap-ra. (Egy régi levélcím, melyet megszűntettünk, de a régi levelekre még szükség lehet, de a spam-ek ne jöjjenek már rá ezerrel...)

Előre is köszönöm a segítségeteket!

iSPConfig csomagfrissítés

Fórumok

Hali!

Egy pár vpsre raktam már fel iSPConfigot, nagyon tetszik bombabiztos cucc..
Egy problémám van vele, hogy iszonyat régi csomagokkal dolgozik..
Pl.: Phpmyadminból 4.6.6 -tal még, és már 4.9 van..

Olvasgattam telepítési leírásokat a hivatalos oldalon közölt "howtoforge" -os manuális iSPConfig telepítésről, próbáltam is párat, de mindeggyikkel elakadtam valahol valami hibába, egyik sem hibátlan sajnos. Automatikus telepítővel raktam saját vpsre, viszont ebbe marharégiek a csomagok.

A script ez: https://github.com/servisys/ispconfig_setup

[MEGKERÜLVE] APC Back UPS 600i és a nut

Fórumok

"Házi szerverem" megérett a szoftver frissítésre Debian 6.x -> Debian 10
Feltelepítettem a nut -ot (az volt a régi rendszerben is) az UPS kezelésére.
Azt mondanám egész könnyű volt, de azzal szembesültem, hogy a leggenerikusabb driver a genericups alacsony akkumulátort jelez. A Debian 6 -nak nincs ilyen gondja.

# upsc APC600

device.mfr: APC
device.model: Back-UPS
device.type: ups
driver.name: genericups
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.parameter.upstype: 2
driver.version: 2.4.3
driver.version.internal: 1.36
ups.mfr: APC
ups.model: Back-UPS
ups.status: OL

Ugyanez a Debian 10 -ben így fest:
# upsc APC600

device.mfr: APC
device.model: Back-UPS
device.type: ups
driver.name: genericups
driver.parameter.LB: DCD
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.parameter.synchronous: no
driver.parameter.upstype: 2
driver.version: 2.7.4
driver.version.internal: 1.36
ups.mfr: APC
ups.model: Back-UPS
ups.status: LB OL

Ráadásul, a "driver.version.internal: 1.36" verzió azonos!

Íme a syslog kivonat:
Aug 27 16:52:52 nusi upsdrvctl[501]: UPS type: APC Back-UPS (940-0020B/C cable)
Aug 27 16:52:52 nusi upsdrvctl[501]: parse_input_signals: input overrides specified, but no effective difference - check for typos?
Aug 27 16:52:52 nusi upsdrvctl[501]: Network UPS Tools - UPS driver controller 2.7.4
Aug 27 16:52:53 nusi upsd[506]: fopen /var/run/nut/upsd.pid: No such file or directory
Aug 27 16:52:53 nusi upsd[506]: listening on 127.0.0.1 port 3493
Aug 27 16:52:53 nusi upsd[506]: listening on 127.0.0.1 port 3493
Aug 27 16:52:53 nusi upsd[571]: Startup successful
Aug 27 16:52:53 nusi upsmon[776]: fopen /var/run/nut/upsmon.pid: No such file or directory
Aug 27 16:52:53 nusi upsmon[776]: UPS: APC600@localhost (master) (power value 1)
Aug 27 16:52:53 nusi upsmon[776]: Using power down flag file /etc/killpower
Aug 27 16:52:53 nusi upsmon[780]: Startup successful
Aug 27 16:52:53 nusi systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Aug 27 16:52:53 nusi upsmon[781]: Init SSL without certificate database
Aug 27 16:52:54 nusi upsd[571]: User monmaster@127.0.0.1 logged into UPS [APC600]
Aug 27 16:52:54 nusi upsmon[781]: UPS APC600@localhost battery is low

A dokumentációban nem látok olyan újdonságot ami ezt okozhatja. Szétkaptam az UPS -t (hátha mégis hiba van) de nem találtam ilyet, az akku 13,6V állt (furcsa is lenne, márciusban cseréltem YUASA 12V10Ah 5 évig bírta).
Még azt is kipróbáltam, hogy a régi (debian 6) konfigurációs fájljait töltöttem be, de semmi változás.
Googliztam, többször átfutottam a dokumentáció idevágó részeit, de nem találtam semmi idevágót (persze ez megint egy régiség, nem igen használ ilyet senki).
Van valami ötlet?

OFF: A nálam lévő 4 darab alapvetően diszkrét, analóg áramkörökből épül fel, szinte mindene javítható, van kapcsolási rajz, sőt alap bemérési utasítás.
Saját gyártmányú kábellel működik, sok éve megbízhatóan.

SZERK: Az összes kínomat a systemd scriptek időzítése okozta. Reanimáltam a /etc/rc.local -t mint systemd service -t és ott indítom a systemd startup scripteket. Így most jól működik.

Lokális apt repo

Fórumok

Szükségem van egy olyan lokális repora, ami felül írja a hivatalos apt Debian repo -t.
A nyomtatóm üzemeltetése kapcsán, forrásból leforgattam, módosítottam a hplip csomagot, hogy újra kezelje a párhuzamos portra kapcsolt multifunkciós nyomtatómat. A módosított csomag 20 csomagra bomlik, melyeknek természetesen van saját függőségeik, így az egyszerű "dpkg -i {fájl}.deb" nem igazán működik. Ráadásul védekeznem kell, hogy ha frissül a hivatalos repoban a csomag akkor ezeket a csomagokat NE frissítse (ha kell én majd frissítek manuálisan).
Találtam olyat, hogy "local-apt-repository" de a rövid leírás nem említi, hogy ez hogy is fog működni?
Csinált már valaki ilyet? Tapasztalat?

csomagkezelési zűr

Fórumok

Sziasztok!

Egy régi programhoz szükségem volt a libstdc++2.10-glibc2.2_2.95.4-27_i386 csomagra, amit a dpkg --force-depends kapcsolójával telepítettem. A programom szépen megy, ami miatt kellett ez a csomag, viszont a csomagkezelő hiányolja a libc6:i386 csomagot, és most más csomagokat nem tudok telepíteni... Van telepítve egy libc6-i386 csomag, úgy gondolom, hogy ez látja el azt a feladatot, amit a csomagkezelő hiányol. Hogyan tudnám lebeszélni az apt-t arról, hogy panaszkodjon a hiányzó függőség miatt?

Wheezy -> Jessie frissítési probléma

Fórumok

Egy Hyper-v alatt futó Debian Wheezy-t szeretnék Jessie-re frissíteni, a frissítés során felkerül egy irqbalance nevű csomag, amit el is indít a csomagkezelő a konfigurálása után, ezután pár másodperccel lefagy a gép és reboot sem segít. Hyperv alatt próbáltam többször visszaállni az előző változatra, de amint ez az irqbalance nevű csomag felkerül és elindul a program, mindig fagyás lett a vége.

Tapasztalt esetleg valaki hasonló problémát Hyperv alatt futó Debian Wheezy -ről Jessie-re történő frissítés során?

[MEGOLDVA] HP1100A nyomtat nem szkennel

Fórumok

Belevágtam a szerverem frissítésébe. Sok kisebb nagyobb problémán túljutottam de ezzel most nem tudok mit kezdeni :(
Telepítettem a cups, printer-driver-cups-pdf hplil hpijs-ppds
printer-driver-hpijs és a sane csomagokat.
Először a nyomtató meg sem nyikkant. Rájöttem nincs /dev/lp0 és az lp modul sem fut. # modprobe lp megoldotta
A régi rendszerem alapján keresgéltem a
/usr/share/ppd/hplip/HP/hp-laserjet_1100a-hpijs.ppd drivert, de ott csak néhány gzippelt fájlt találtam. Jó letöltöttem a "frisset" (valahol 2008) és sikerült a cups -hoz hozzáadni:
# lpadmin -p HP1100A -E -v parallel:/dev/lp0 -P [az előbbi driver fájl, full path]
Sikerült parancssorból nyomtatni.
Következik a szkennelés. Semmi, nincs megfelelő eszköz - valóban nincs /dev/scenner (meg kell néznem kell e egyáltalán).
Rengeteg mindent kipróbáltam, a hplip oldalán keresgéltem, de vagy a forrásból telepítésig jutottam, vagy a "kimenetek" semmit mondóak.
Szerintem, egyszerűen nem indul a hpaio driver/modul nem tudom :(
Nincs több ötletem :(

Google Kubernetes Engine hiba? SPAM-el a Google LB?

Fórumok

Sziasztok!

A következő GCP/GKE hibával kapcsolatban várnék ötleteket:

Adott egy kubernetes cluster, amiben futnak konténerek, többek közt egy postfix konténer.
Ez a konténer a kubernetes clusternél megadott "Pod address range"-ből fogad leveleket, konkrétan a 10.8.0.0/14-ből.
Amit kap, azt továbbítja egy külső SMTP szerverünk felé a 2525-ös porton. Azt a célt szolgálja tehát, hogy a többi konténer tudjon levelet küldeni rajta keresztül.

Most másodszor fordult elő, hogy egyszercsak megjelent 10-100 ezres nagyságrendben levél (SPAM) ezen a postfix konténeren,
amit ő el is fogadott és ki is küldött, mivel a 10.8.5.1-es IP címről érkezett (vagy valamelyik másik belső tartománybeli IP címről).
Nem akarok túl sok logot idemásolni, csak egy levelet, ami hó elején volt:

Jul 09 06:29:01 mail-gateway postfix/smtpd[10668]: 4600C80026: client=unknown[10.8.5.1]
Jul 09 06:29:01 mail-gateway postfix/qmgr[108]: 4600C80026: from=, size=2863, nrcpt=6 (queue active)
Jul 09 06:29:01 mail-gateway postfix/smtpd[10668]: disconnect from unknown[10.8.5.1] ehlo=1 mail=1 rcpt=6 data=1 quit=1 commands=10
Jul 09 06:29:01 mail-gateway postfix/qmgr[108]: 4600C80026: removed

Ez a 10.8.5.1-es IP elvileg az egyik Google HTTPS load balance IP-je. Erről az IP-ről csinálja a health check-jét a HTTP-s konténereknek. Ez így néz ki a logban, a fenti bejegyzéssel kb egyidőben (a két óra eltérés csak az időzóna miatt van):

xy.hu:80 10.8.5.1 - - [09/Jul/2019:08:28:31 +0200] "GET / HTTP/1.1" 200 5304 "-" "GoogleHC/1.00

Namost az hogy lehet, hogy a load balancer IP-jéről egy olyan konténerre megy SMTP forgalom, amelyik konténerhez semmi köze nincs a load balancernek, ráadásul ez egy HTTPS load balancer, tehát SMTP forgalmat nem is tud bonyolítani? Legalábbis nem kéne neki tudni.

Felnyomták volna a Google load balancerét? Nem hiszem. Bár ez egy béta LB (vagy nevezzük Kubernetes Ingressnek?), mert a Googlenél csak a béta LB tud Let's Encrypt cetet kezelni automatikus megújítással tudtommal.

Esetleg valami hálózati anomália? Annak is kicsi az esélye szerintem.
Egyéb ötlet? Mit nézzek még meg? Mire gyanakodjak?

Megköszönném, ha valaki adna valami támpontot. A Google support nem válaszolt pár hét alatt (bár az igaz, hogy nincs külön megvásárolt support csomagunk, csak a szolgáltatásokért fizetünk).

Köszi!