Debian GNU/Linux

Sziasztok.

A Következő problémám van.

Van 2 Cég akivel leveleznék, de mikor levelet küldenek nekem.
MX rekordba jól van megadva, ami így néz ki: mail.[DOMAIN].hu.
Nekem meg úgy küldik a levelet, hogy XYZ@[DOMAIN].hu, valamiért viszont visszapattan a levél a feladónak a következő hibaüzenettel.:

"Hi. This is the qmail-send program at enger.nicom.hu.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
[DOMAIN SZOLGÁLTAT IP CÍM] does not like recipient.
Remote host said: 554 5.7.1 : Relay access denied
Giving up on [DOMAIN SZOLGÁLTAT IP CÍM]."

Tehát lényegében valahol útközben átíródik a domain és nem nekem érkezne meg a levél látszólag hanem a DOMAIN SZOLGÁLTATÓ-nak.
Kérdésem, hogy miért lesz az @[DOMAIN].hu -ból @ns.[DOMAIN_SZOLGÁLTATÓ].hu

Látott már valaki ilyet?
Ha igen mi a megoldás???

Köszönöm szépen előre is...

Szervusztok!

Ismét egy olyan téma, amihez nem értek, de azt gondolom, hogy valami hiba leledzik itt. A következő szabályok a INPUT filter táblában vannak:

iptables -v -n -L INPUT -t filter | egrep "67:68|destination"
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0            udp dpts:67:68
    0     0 DROP       udp  --  !eth1  *       0.0.0.0              0.0.0.0/0            udp dpts:67:68
  138 79488 mi_ez_HE   udp  --  *      *       0.0.0.0              0.0.0.0/0            udp dpts:67:68

A két releváns sor szabálya így készül:

-A INPUT -i !eth1 -s 0.0.0.0 -p udp --dport 67:68 -j DROP
-A INPUT          -s 0.0.0.0 -p udp --dport 67:68 -j mi_ez_HE

Ezek után a napló meg ilyet ír nekem:
"Ki érti ezt, ki érti ez? Én nem."

Feb  9 05:38:09 naja kernel: [24523.195056] mi_ez_HEIN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:50:46:5d:61:6d:c4:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=556

Tudja cifrázni is:

Feb  9 05:47:05 naja kernel: [25059.227840] mi_ez_HEIN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:17:31:dc:05:29:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=576 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=556

A rendszer:

uname -a
Linux naja 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

lsb_release -a
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	Debian
Description:	Debian GNU/Linux 7.8 (wheezy)
Release:	7.8
Codename:	wheezy

iptables -V
iptables v1.4.14

Kösz előre is a segítséget!
Egyébként a DIGI hálózat irányából jön.
Üdv,
vfero

Megpróbáltam lefordítani a következő, egyszerű példaprogramot:
http://tldp.org/HOWTO/IO-Port-Programming-9.html

fatal error: asm/io.h

Persze, hiszen az a mostani felállásban itt van:

/usr/src/linux-headers-3.2.0-4-common-rt/arch/x86/include/asm/io.h

Az architektúra, a legalapvetőbb i386.
Mi itt a korrekt megoldás?
Hogy tudom megmagyarázni a gcc -nek hogy hol vannak a headerek?

"Hirtelen" szükségem lett egy Wheezy32 -re. Az aktuális diszkemen volt még egy kis üres hely - 8G /dev/sda9 (250G SATA egy kis partíciója). "Gyorsan" felmázoltam egy kis rendszert, még épp hogy a minimálnál tartok, amikor kiszúrtam, hogy mind a "mount" mind a "df -h" parancs a root csatlakozási ponton egy ilyen érdekeset ír ki, hogy "/dev/block/8:9"
Látszólag minden jól működik - amennyit ilyenkor ebből látni lehet. Egyébként most a 6 -os partíción lévő 64 bites Wheezy adja a fő boot loadert - lilo - itt csak a partíció elején van egy boot szektor amit a saját (/dev/sda9) lilo csinált oda és tulajdonkéépen meg sem jelenik hiszen a "fő" menűben kiválasztom és ez elég.
Én még ilyet nem láttam Debianon (Squeeze, Wheezy 64 vagy Jessie 64 -en).
Mi okozhatja azt hogy nem /dev/sda9 hanem ez az izé?
Olyan mintha valami félállapotban lenne, nincs teljesen felinicializálva.
Ötlet?
(Mintha az udev használna ilyesféle jelölést a diszkekre ...)

Sziasztok!

A probléma a következő. Adott egy bind szerver és egy domain szerver oldalon. Adott több eszköz, aminek a publikus IP-je dinamikus, és statikus néven szeretnék rájuk hivatkozni. Viszont az egyes hostokat el kéne választani egymástól, mint egy tipikus DDNS szolgáltatás keretében, tehát mindenki csak a saját rekordjait láthatná. Erre nem találtam megoldást,hogy ez hogyan valósítják meg. A legnagyobb probléma az autentikáció és a dns rekordok összekötése. Dinamikus DNS-t használok lan-on,de ott dhcp-vel összehangolva van vagy épp saját script frissít autentikáció nélkül.

Kérdés: Van-e valakinek tapasztalata ebben és tud-e segíteni,hogy merre induljak, mit keressek a neten?

Segítségetek előre is köszönöm!

Csabi

üdv,

debian 6-os, pár hosztolt wordpress, postfix/courier virtual konfiguráció, amavis, spamassassin (howtoforge szerint), ezek egy másik szerverhez csatlakoznak mysql-hez, de ez lényegtelen.

a mail.log-ban ilyenek ütik fel a fejüket napi szinten 30-1800 alkalommal:

Jan 7 11:15:11 debian postfix/smtp[11223]: smtp_session_activate: dest=[127.0.0.1]:10024 host=127.0.0.1 addr=127.0.0.1 port=10024 features=0x49f8f, ttl=266, reuse=12
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: RSET
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_fflush_some: fd 12 flush 6
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 12 got 19
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.0.0 Ok RSET
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_tweak_tcp: TCP_MAXSEG 16384
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: XFORWARD SOURCE=LOCAL
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: MAIL FROM: SIZE=766 BODY=8BITMIME
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: RCPT TO: ORCPT=rfc822;amirkoko31@yahoo.com
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: DATA
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_fflush_some: fd 12 flush 156
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 12 got 23
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.5.0 Ok XFORWARD
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 12 got 132
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.0 Sender OK
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 250 2.1.5 Recipient OK
Jan 7 11:15:11 debian postfix/smtp[11223]: < 127.0.0.1[127.0.0.1]:10024: 354 End data with .
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_buf_get_ready: fd 11 got 829
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 59 data Received:
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 53 data ?id 1399DF
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 24 data To: amirko
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 54 data Subject: F
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 40 data X-PHP-Orig
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 45 data From: "Ern
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 48 data Reply-To:"
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 23 data X-Priority
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 18 data MIME-Versi
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 46 data Content-Ty
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 31 data Content-Tr
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 58 data Message-Id
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 43 data Date: Wed,
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 0 data
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 1 data ?
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 6 data div?
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 171 data a href="h
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 7 data /div?
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type N len 0 data
Jan 7 11:15:11 debian postfix/smtp[11223]: rec_get: type X len 0 data
Jan 7 11:15:11 debian postfix/smtp[11223]: > 127.0.0.1[127.0.0.1]:10024: .
Jan 7 11:15:11 debian postfix/smtp[11223]: vstream_fflush_some: fd 12 flush 768
Jan 7 11:15:14 debian amavis[3146]: (03146-08-10) Blocked SPAM, -> , quarantine: spam-4qXt6dfBUHiy.gz, Message-ID: <20150107101444.0BB32FF8BA@debian.akarmi.hu>, mail_id: 4qXt6dfBUHiy, Hits: 11.513, size: 773, 5221 ms
Jan 7 11:15:14 debian postfix/smtp[11227]: vstream_buf_get_ready: fd 12 got 48
Jan 7 11:15:14 debian postfix/smtp[11227]: < 127.0.0.1[127.0.0.1]:10024: 250 2.7.0 Ok, discarded, id=03146-08-10 - SPAM
Jan 7 11:15:14 debian postfix/smtp[11227]: 0BB32FF8BA: to=, relay=127.0.0.1[127.0.0.1]:10024, conn_use=10, delay=30, delays=0.01/25/0/5.2, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=03146-08-10 - SPAM)
Jan 7 11:15:14 debian postfix/smtp[11227]: rec_put_type: 68 at 1024
Jan 7 11:15:14 debian postfix/smtp[11227]: vstream_fflush_some: fd 11 flush 1
Jan 7 11:15:14 debian postfix/smtp[11227]: name_mask: resource
Jan 7 11:15:14 debian postfix/smtp[11227]: name_mask: software
Jan 7 11:15:14 debian postfix/qmgr[21904]: 0BB32FF8BA: removed

tény, hogy az akarmi.hu domain-ről érkeznek ezek a szarok, ziher hogy a wordpress-en keresztül, de képtelen vagyok megfogni... :(

5 másik szerverünkön ubuntu futkorászik, egy-kettő hosztol wordpress-tartalmat, de ilyen jelenség nincs, pedig van php mail() lehetőség mindegyiken, valamint a levelezsre használt szerverünkön a mail.log nem tartalmaz túl sok szemetet a debian-hoz képest (lásd 6 egymást követő bejegyzésből megállapítható a küldő és a címzett...), illetve spam-küldés csak felcsapott fiókkal sikerült ez alatt a pár év alatt, egy felhasználó esetében...

a /usr/sbin/sendmail-t átneveztem, mert (elegem lett és) nem találtam megoldást, így a kérdéseim:

-ha status=sent és ugyanakkor discarded, akkor kiment az a levél, vagy sem?
-ha ezek a levelek kimentek, akkor miért mentek ki, ha egyszer SPAM jelzőt kaptak?
-ha minden wordpress-es domain-hez köthető php-fpm konfigurációban a feladót a $domain@http.szerverneve.hu-nak jelöltem meg, miért tudja felülírni bárki is a feladó nevét? (<>, random nevek, fent látható erna_rowe, stb...)?
-hogyan tudnám megszüntetni ezt a jelenséget/próbálkozást?

nyilván a php mail() tiltása lehetne a megoldás (preferálom), de ez több dolog miatt nem lehetséges. azok a dolgok viszont mind úgy működnek, ahogyan mi szeretnénk használni.

tippek?

Sziasztok! Debian+xfce alatt...

Van sok szépen paraméterezett alias-om. Hogyan lehet rávenni az xdg-open-t arra, hogy ha egy adott könyvtárban kiadom az xdg-open * parancsot, akkor az adott default app (be)paraméterezett alias-át hívja meg?

pl. a ~/.bashrc-ben van egy ilyenem: alias vlc="vlc --fullscreen --repeat --quiet --no-video-title-show --key-play-pause '5' --key-next '3' --key-prev '9' --key-faster '1' --key-slower '7'"
Ha vlc * a parancs, akkor a fenti paraméterek működnek. Ha viszont xdg-open *, akkor nem.

Átmeneti megoldásként az adott fájlra jobb-klikk és Megnyitás -> Egyéni parancs használata sorba bepastézva működik, de a fájlok változnak és nem akarnám/tudnám folyamat ezt eljátszani.

Bash script írásban sem vagyok jártas, de ha azzal meg lehetne oldani a fájltípus felismerést, majd annak az alias-szal való megnyitását, akkor az is jó lenne :)

Valaki tudna segíteni, hogy pontosan milyen parancsot kellene adnom debian alatt, hogy egy konkrét könyvtár teljes állománya permamensen olyan attribútumokkal rendelkezzen,amit adok neki.
A következő a helyzet.
Van egy felhasználó, aki stp-n keresztül töltené fel a www könyvtárba a módosított file-okat, viszont folyamatosan kidobja a rendszer,miszerint nincs kellő jogosultsága.
Én adtam a www könyvtár összes alkönyvtárának chmod -R 777 paranccsal teljes írási jogot is, viszont egy alkönyvtárban az összes file gyakorlatilag pár mp után egyszerűen visszaállítja magát az eredeti beállításokra és adhatom neki újra a 777-et, majd megint visszaáll.

Na ennek kiküszöbölésében kellene segítség.
Köszönöm!

Sziasztok.

Ujdonsult laptopra felraktam egz debian alapu artistX distribet.
Kerdesem csupan az, hogy mit kell vajon felraknom ahhoz, hogy a munkaasztalok szamat egyrol tobbre novelhessem?

(Az az erzesem, mintha az artistx-et lebutitottak volna egy desktopos win98-szeru rendszerre, amin van egy dokkolo opengl-animacioval es ezzel kesz is.)

Sziasztok!

Mivel közeleg a hivatalos megjelenés, gondoltam kipróbálom egy virtuális játszótéren igy dist-upgrade előtt. A virtuális gépen
2 db 2 GB -os merevlemezt szerettem volna RAID1-be rakni. A telepités sikerese,stb jönnek a szokásos dolgok, azaz grub sda-ra sdb-re, initramfs-nek bootdegraded=true. Az elméleti hibát szimulálva, az sda kiszedve, sdb marad, gép indul, grub bejön, de a kernel után sajna nem megy tovább,initramfs sajnálkozás, hogy nemtudja visszaállitani az md arrayokat. Ugyanezen combó Debian 7 és Ubi 14.04 alatt természetesen tökéletesen működött. Valakinek esetleg ötlete?