Web, mail, IRC, IM, hálózatok

Sziasztok!

Az opendkim ilyeneket logol nekem:

opendkim[750]: 1CF99889C5B4: key retrieval failed (s=20161025, d=gmail.com): '20161025._domainkey.gmail.com' query timed out

De ugyan ezen a gépen simán le tudom kérni:

# dig -t TXT 20161025._domainkey.gmail.com

; <<>> DiG 9.11.2-P1 <<>> -t TXT 20161025._domainkey.gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30624
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;20161025._domainkey.gmail.com. IN TXT

;; ANSWER SECTION:
20161025._domainkey.gmail.com. 300 IN TXT "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqR" "tqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB"

;; Query time: 24 msec
;; SERVER: 11.123.122.122#53(11.123.122.122)
;; WHEN: K júl. 17 02:47:38 EDT 2018
;; MSG SIZE rcvd: 462

Hol keressem a hibát?

Köszi,

L

Sziasztok,

Egy régi OTRS 3.3-at kellene upgradelnem 6-osra. Ezt egy lépésben nem lehet, előbb fel kell patchelni 3.4->4.0->6.0 vonalon. Ezzel nincs is bajom, viszont Ubuntu 18.04-re próbálom felrakni a jelenlegi 3.3-at és itt elvégezni a frissítést (mert ugye az élesen nem csinálhatom).

Minden modult sikerült felraknom, kivéve egy hasal el:

/opt/otrs# ./bin/otrs.CheckModules.pl
o Archive::Tar.....................ok (v2.24)
o Crypt::Eksblowfish::Bcrypt.......ok (v0.009)
o Crypt::SSLeay....................ok (v0.73_04)
o Date::Format.....................ok (v2.24)
o DBI..............................ok (v1.640)
o DBD::mysql.......................ok (v4.046)
o DBD::ODBC........................Not installed! (optional - Required to connect to a MS-SQL database.)
o DBD::Oracle......................Not installed! (optional - Required to connect to a Oracle database.)
o DBD::Pg..........................Not installed! (optional - Required to connect to a PostgreSQL database.)
o Encode::HanExtra.................ok (v0.23)
o GD...............................ok (v2.66)
o GD::Text.......................ok (v0.86)
o GD::Graph......................ok (v1.48)
o IO::Socket::SSL..................ok (v2.056)
o JSON::XS.........................ok (v3.04)
o List::Util::XS...................ok (v1.46_02)
o LWP::UserAgent...................FAILED! Not all prerequisites for this module correctly installed.
o Mail::IMAPClient.................ok (v3.39)
o IO::Socket::SSL................ok (v2.056)
o ModPerl::Util....................ok (v2.000010)
o Net::DNS.........................ok (v1.10)
o Net::LDAP........................ok (v0.65)
o PDF::API2........................ok (v2.033)
o Compress::Zlib.................ok (v2.074)
o Text::CSV_XS.....................ok (v1.34)
o Time::HiRes......................ok (v1.9741)
o Time::Piece......................ok (v1.31)
o XML::Parser......................ok (v2.44)
o YAML::XS.........................ok (v0.69)

Az LWP::UserAgent nem akar jó lenni.
Látszólag fel van téve:
cpan[1]> install LWP::UserAgent
Reading '/root/.cpan/Metadata'
Database was generated on Mon, 09 Jul 2018 11:29:02 GMT
LWP::UserAgent is up to date (6.34).

/opt/otrs# perl -MCPAN -e 'install Bundle::LWP'
Reading '/root/.cpan/Metadata'
Database was generated on Mon, 09 Jul 2018 11:29:02 GMT
MIME::Base64 is up to date (3.15).
Digest::MD5 is up to date (2.55).
URI is up to date (1.74).
Net::FTP is up to date (3.11).
HTML::Tagset is up to date (3.20).
HTML::Parser is up to date (3.72).
HTML::HeadParser is up to date (3.71).
LWP is up to date (6.34).

Próbáltam rákeresni mik az előfeltételei, de sehol sem találtam. Tudna valaki tippet adni, hogy melyik csomagom hiányzik?

Köszi,
N

Sziasztok!

Az alábbi problémába futottam bele: Adott egy full alap konfiggal futó nginx és hiába adok meg két különböző domain-t két külön szerver blokkban, mindig csak az egyiket használja az nginx.

/etc/nginx/sites-enabled-ben semmi nincs (default is kitörölve), az example.com.tld.conf és az example.com.blog.conf linkeket leszámítva.

Előbbi (example.com.tld.conf) tartalma:

server {
listen 80;


root /var/www/example.com/tld;
index index.php index.html

server_name example.com www.example.com;

location / {
try_files $uri $uri/ =404;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.2-fpm.example.com.sock;
}

location ~ /\.ht {
deny all;
}
}

example.com.blog.conf tartalma:

server {
listen 80;


root /var/www/example.com/blog;
index index.php index.html

server_name blog.example.com www.blog.example.com;

location / {
try_files $uri $uri/ =404;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.2-fpm.example.com.sock;
}

location ~ /\.ht {
deny all;
}
}

nginx -t ennyit dob:

nginx: [warn] conflicting server name "" on 0.0.0.0:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful


Az example.com címet megnyitva viszont a blog.example.com állományai jelennek meg a böngészőben.

Valaki segítene rájönni arra, hogy mit szúrok el?

Mennyire megbízható, hogy ha egy IP címhez tartozó nevet kérek le, akkor az valós lesz? Mennyire hamisítható a reverse feloldás?
A levelezőszerveremet folyamatosan kóstolgatja a 38.65.24.200 IP cím, amit feloldva a mail-wm0-f45.google.com. nevet kapom, amit ismét feloldva a 74.125.82.45 IP címet.
Ez akkor vélhetően egy hamis feloldás, vagy tényleg a google-től jönnek a kérelmek?

Van egy exim levelezőszerverünk, ahol az egyik ügyfél számára backup mx szolgáltatást nyújtunk.
Az ügyfél levelezőszervere lerohadt pár napja, és nem tudja helyreállítani. Lassan kezd pánikba esni.
Van rá valamilyen mód, hogy a nálunk gyűlő leveleket ne egy MX-re továbbítsuk, hanem valamilyen harmadik e-mail címre, anélkül, hogy az eddig bejött leveleket kockáztassuk?
Persze manuálisan ki lehetne vadászni a queue-ból, de valamilyen egyszerűbb, egzakt, korrekt megoldást tud valaki ilyen esetre?

Sziasztok,
Tudtok olyan oldalt ahol objektíven össze vannak szedve a különböző framework-ok?
Szaporodnak mint a gomba és szinte képtelenség követni.
Ilyenre gondolok:

Backend :
PHP : Symphony,Zend,Yii2(tag:MVC),Aura,Laravell...
Perl : Mojolicious,Dancer
Python : Django,Pyramid,Flask

Frontend :
JavaScript : Angular1,Angular2,Jquery,React,Lodash,Underscore,Vue.js,Backbone,Ember,Knockout,Aurelia,Meteor,

Meg némi leírás, tapasztalat, linkek...

Mai napon tele van az access.log az alábbi bejegyzésekkel:

138.201.19.161 - - [20/Jun/2018:20:15:00 +0200] "CONNECT 1xbet.com:443 HTTP/1.1" 405 466 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/25.0.1386.108 Safari/537.36"
115.159.218.135 - - [20/Jun/2018:20:15:00 +0200] "GET http://acs.m.taobao.com/h5/mtop.taobao.detail.getdetail/6.0/?&data=%7B%… HTTP/1
.1" 404 486 "-" "Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16"
113.103.117.148 - - [20/Jun/2018:20:15:00 +0200] "POST http://hb-api.longzhu.com/user/collect?roomId=2271803&version=4.6.4&dev… HTTP/1.1" 404 406 "-" "Mozilla/5.0 (compati
ble; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; Alexa Toolbar)"
118.25.208.174 - - [20/Jun/2018:20:15:00 +0200] "POST http://hb-api.longzhu.com/user/collect?roomId=2277506&version=4.6.4&dev… HTTP/1.1" 404 406 "-" "Mozilla/5.0 (compatib
le; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; Alexa Toolbar)"
220.177.175.236 - - [20/Jun/2018:20:15:00 +0200] "CONNECT www.baidu.com:443 HTTP/1.1" 405 466 "-" "-"
123.129.217.16 - - [20/Jun/2018:20:15:00 +0200] "CONNECT 182.247.249.77:80 HTTP/1.1" 405 466 "-" "-"
49.69.183.249 - - [20/Jun/2018:20:15:01 +0200] "CONNECT help.steampowered.com:443 HTTP/1.1" 405 466 "-" "-"

Nem sikerült rájönnöm, hogy mi okozhatja ezt, percek alatt méretes log file keletkezik. A google pedig ellenőrzést kér, hogy nem vagyok-e robot mert túl nagy forgalom megy a gépem felöl.

A tegnapi logokban nem látok hasonló bejegyzéseket. Sok apache2 modult kikapcsoltam már, a weblapok nagy részét is letiltottam, de egyenlőre nincs változás.

Tapasztal valaki ehhez hasonlót?

Több ügyfélnél és irodáknál is évek óta sikeresen működik a nextCloud/ownCloud szolgáltatás. Most azonban felmerült egy olyan igény, hogy bizonyos nagy méretű fájlok küldésének leegyszerűsítése érdekében legyen beüzemelbe a Thudnerbird levelező kliensbe a nextCloud bővítmény. Azonban gondok vannak, konkrétan a nextcloud szolgáltatáshoz való csatlakozás nem működik. Az alábbi hibaüzenetet adja:
"An error occured while setting up the account"

(A Thunderbird hibakonzol eredménye ITT látható.)

Sajnos a problémára megoldást sehol nem találtam, ezért most itt vetem fel a témát, hátha valaki már találkozott ezzel a tünettel. Minden más kliensből (desktop, android, iPhone) működik a csatlakozás.

(Thunderbird és nextCloud is a legfrissebb verzió, a telepített plugin szintén...)

Előre is köszönöm a javaslatokat és segítségeket!

A napokban 2 olyan levelet is dobott Dömötör (a mailer daemon, ha valakinek nem esne le helyből), amelyeket nem tudok értelmezni. Kérem valami hozzáértő magyarázza meg!1.

<ABCDE@freemail.hu>: host fmx.freemail.hu[84.2.43.65] said: 550 5.7.1
<ABCDE@freemail.hu>: Recipient address rejected: u'Receive - Email does
not exist (incoming: ABCDE@freemail.hu, after decryption:
ABCDE@freemail.hu)' (in reply to RCPT TO command)

Az 5.7.1-es hibakód szimplán egy statikus "Delivery not authorized", kár hogy amikor ez visszapattant, akkor 4-5 másik freemail-es címre elment a levél. Az 550 ugye a szövegben szintén jelenlevő nemlétező postafiók.
De a lényeg: Zavaros az u'Receive - email .... kezdetű szöveg, kicsit olyan, mintha külön jelezni szeretné valamiért, hogy Unicode, de korábban mintha nem így tette volna. Meg nem értem az "after decryption" szöveg előfordulásának okát.

2.

<ABCDE@gorbehaza.hu>: host gorbehaza.hu[87.229.26.17] said: 454 4.7.1
<ABCDE@gorbehaza.hu>: Relay access denied (in reply to RCPT TO
command)

Hogymivan? gorbehaza.hu azt mondja, hogy nem relay-zik gorbehaza.hu -felé???? Az előzőhöz képest ez ugye 4.7.1, tehát elvben akár meg is próbálhatnánk később. (A 454 meg mintha inkorrekt autentikáció lenne.)

De én magát a hibaüzenetet szeretném mind a két esetben megérteni, hogy miért ezt (és így) mondja.

Sziasztok!

Van egy .hu domain regisztrátor, akinél úgy működik a domain hosszabbítás, hogy a lejárat előtt 90 nappal küld egy lejárati értesítőt,
melyben leírja, hogy a domain 90 nap múlva lejár és és ha NEM akarom meghosszabbítani, akkor a lejárat előtti 30. napig jelezzek vissza.

Több levelet ezzel kapcsolatban nem küld!

Ezzel a módszerrel több bajom is van:

- nem egyértelmű, hogy a címzett a levelet megkapta,
- A 30 nap egy önkényes határidő a részéről,
- a domain szolgáltatás határozott idejű szerződés, ráutaló magatartás nélkül egy ilyen szerződés nem meghosszabbítható. Az nem ráutaló magatartás, hogy nem mondtam, hogy nem kell.
- a regisztrátor nem tudhatja, hogy nem veszett-e el a levelem, amit neki küldtem a lemondásról

Ő nem megszünteti a domain reg. szolgáltatást, hanem azt mondja, hogy a díjat ő saját maga már befizette (hu, com esetén) és küldi a számlatartozást. Olyan domainre is, amit három(!) éve nem fizetünk, de ő mind a három évre kéri. Ez sem üzletileg, se józan ész szerint nem érthető viselkedés a részéről.

Mivel ez egy bevett üzleti gyakorlat a részéről, az a kérdésem, hogy mivel tudnám neki egyértelműen jelezni, hogy amit tesz az nem törvényes?
Nem vagyok jogtudós, ügyvédet nem keresnék, ha józanul is meglehetne beszélni.

Köszönöm!

Frissítés:

A sok helyen széttagolt ÁSZF, megrendelő lap szövegben ezt találtam:

A fenntartási idő lejárta előtt 60 nappal az Igénylő a domain fenntartását a Regisztrátornál meghosszabbíthatja. Meghosszabbítás kizárólag akkor történik meg, ha a Regisztrátor részére az éves fenntartási díj befizetésre került legkésőbb a fenntartási idő lejárata előtt 30 nappal. Meghosszabbítás híján a domain név fenntartás felmondottnak tekintendő a domain név törlésre kerül. Nem kiegyenlített regisztrációs, fenntartási, domain szolgáltatási díjtartozás esetén az Igénylő domainjeinek fenntartását a Regisztrátor felmondja.

Írtam neki, kértem, hogy jelölj meg, hogy az ÁSZF mely pontja támasztja alá az ő követelését.