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

Nextcloud SSL gond

A problémám a következő: Nextcloud telepítve proxmox VM-ben. Innen. (Egyébként szuper munka, ha valakinek kell egy előkonfigurált natív nextcloud vm, jó szívvel ajánlom. A post install script is zseniális!) A VM importálása és a telepítés is simán zajlott. Http-n tökéletesen üzemel. Szerettem volna saját tanúsítvánnyal validálni. Ehhez ezt a leírást követtem. Feltöltöttem a megfelelő könyvtárakba a pem és a key fájlokat, módosítottam a default-ssl.conf állományt. Majd amikor újraindítottam az apache2 service-t akkor ezt kapom:

Jun 06 10:48:53 nextcloud systemd[1]: Starting apache2.service - The Apache HTTP Server...
Jun 06 10:48:53 nextcloud apachectl[2031]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Jun 06 10:48:53 nextcloud systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
Jun 06 10:48:53 nextcloud systemd[1]: apache2.service: Failed with result 'exit-code'.
Jun 06 10:48:53 nextcloud systemd[1]: Failed to start apache2.service - The Apache HTTP Server.
root@nextcloud:~# systemctl start apache2.service 
Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xeu apache2.service" for details.

Itt ugye az a helyzet, hogy saját fix ip-n van a szolgáltatás (illetve van FQDN is), de ő a 127.0.1.1 címen keresi. Vagy más a hiba?

Mit kell tennem, hogy működjön?

Mi a hivatalos módja egy gépen a saját cert importálásának?

Köszönöm!

[ Megoldva ] Outlook 365 levél törlése IMAP-on keresztül

Imap protokollal kapcsolódom egy Outlook 365 e-mail címhez. Rendben elérem a leveleket, le is tudom tölteni, de amint megpróbálom a \Deleted flag-et állítani (pl.: "A 2 STORE +FLAGS \Deleted"), a szever kurta "NO" válasszal jelzi, hogy érti ugyan, de nem tudja megcsinálni. Próbáltam más flag-et is állítani (Seen, Flagged), de mindegyikre hasonlóan reagál.

Közvetlenül az INBOX-ban próbálom állítani, de az AI tanácsa alapján próbáltam áthelyezni a a töröltek mappába, szintén sikertelenül.

Mivel minden levelet ki akarok törölni a mappából, egyszerű sorszámmal próbálkozom, de próbáltam az UID-t is használni, hasonló eredménnyel.

Van az outlook 365 imapjának valami speciális szabványa erre? Vagy ezt lehet a szerver oldalon tiltani, és ott kellene próbálkoznom a rendszergazdákkal?

Megoldás: A fiók kiválasztásához a SELECT imap parancsot kell használni.

PHP imap_open office 365 fiókra

Egy ügyfelünk office365 e-mail fiókját kellene PHP-val elérnem. Az imap_open() paranccsal eddig más fiókokat el tudtam eddig érni, de ezt az office365 fiókot nem sikerül. A fiók vállalati, így tartozik hozzá egy rendszergazda, aki nem tudta biztosan megmondani, hogy outlook.office.com vagy outlook.office365.com a szerver, amihez csatlakozni kell, így próbálkozom mindkettővel. Állítása szerint a korlátozásokat levette, sőt a powershelljében nem is lát sikertelen csatlakozási kísérleteket, míg PHP oldalról csak hibás csatlakozások történtek. A hibaüzenet: "LOGIN failed.". Bár már sikerült elérnem, hogy ezek után adjon még egy másik hibaüzenetet is: "Too many login failures". A rendszergazda nem tudja törölni a próbálkozási kísérletek limitjét, mert nem is lát hibás csatlakozást. Talán azért nem lát, mert én más szerverhez csatlakozom, mint kellene?

A e-mail címmel és jelszóval az outlook webes felületére gond nélkül be lehet lépni.

Az AI még tanácsolta, hogy a rendszergazda generáltasson alkalmazásjelszót a fiók jelszava helyett, de erre azt a választ kaptam, hogy ebben az esetben ez nem fog menni. (Talán, mert nincs 2FA a fiókon?)

Csak remélni tudom, hogy nem én vagyok az egyetlen, akinek PHP-val kellene egy felhős outlook fiókot elérni, és valaki tud tanácsot adni, hogyan próbáljam meg, netán van konkrét csatlakozási kódja, ami nála működik is. Mindenképp jó lenne tudni egy biztos szervernevet, amihez csatlakoznom kell.

HTV: új távoli asztali kliens fejlesztés alatt – vélemények, ötletek?

HTV – Könnyű, gyors és titkosított távoli asztal (fejlesztés alatt)

A HTV egy saját fejlesztésű, jelenleg is aktívan fejlesztett távoli asztal program, amelynek célja egy könnyű, gyors, de biztonságos alternatíva nyújtása a népszerű távvezérlő megoldásokra. A projekt több fejlesztő együttműködésével készül, fókuszban a teljesítmény, egyszerűség és hordozhatóság.

✅ Alapfunkciók:

  • Távoli vezérlés – Interaktív desktop hozzáférés
  • Attended & Unattended hozzáférés – Felhasználói jelenléttel vagy nélküle
  • Fájlátvitel – két gép között, beépített fájlkezelő felülettel

⚙️ Technikai megvalósítás:

  • P2P kapcsolat UDP-n keresztül, BBR congestion control alkalmazásával
  • Saját képkódoló (codec) alacsony késleltetéssel és jó tömörítéssel
  • Keresztplatformos (Windows/Linux), bár a legtöbb funkció jelenleg csak Windows alatt működik

🔐 Biztonság:

  • AES titkosítás minden hálózati adatcsomagon
  • Jelszóval védett hozzáférés

🖥️ Felület & kezelhetőség:

  • Windows tálca ikon
  • HUD típusú ablak távoli gépen
  • Beépített fájlkezelő

📦 Kompatibilitás & Telepítés:

  • Windows és Linux kliensek (Linuxon csak kliens)
  • Telepítésmentes, egyetlen .exe fájl (Windows-on), nem igényel admin jogokat

⭐ Kiemelt egyediség:

  • Extrém kis méret: jelenleg ~650 KB
  • Gyorsabb kapcsolatépítés és adatátvitel, mint más távoli asztal programoké, köszönhetően a BBR-alapú UDP protokollnak

📥 Letöltés:

➡️ https://mediscope.hu/htv.exe

➡️ https://mediscope.hu/htv_unpck.exe UPX mentes verzió.

➡️ https://mediscope.hu/htv_linux

Google drive

Véleményeket, hibajelentéseket és ötleteket szívesen fogadunk itt a fórumban. 😊

Megoldhatatlan reCAPTCHA (végtelen ciklus)

Ami van kéznél:

  • Linuxos PC-k, több is (most épp Debian 12)
  • Windows PC-k, több is (most épp Windows 11)
  • Naprakész böngészők (most épp Firefox 128ESR, Chrome 136, Edge 136)
  • Szűz böngésző-profilok (mindenféle tárolt előzmény és kukik nélkül)
  • Többféle Internet-kapcsolat (Telekom GPON, Vodafone DOCSIS, NIIF egyetemi háló, stb.), dual-stack IPv4 és IPv6 konnektivitás.

Sorozatosan futok bele abba a problémába, hogy a különböző weboldalakon a reCAPTCHA-kat képtelenség megfejteni. Végtelen ciklusban adja az újabb és újabb feladványokat, majd néhány feladvány után kiírja, hogy "try again later".

A Google nem segít. Ezernyi hasonló találat van, tehát nem vagyok egyedül a problémával, de valódi megoldást nem sikerült köztük találni.

A tapasztalatok alapján, Chrome-ból a legnagyobb a success rate, de ott is távol van a 100%-tól. Az esetek kb. 60%-ában 4-5 feladvány után megjön a zöld pipa. Már a 4-5 feladvány is bosszantó, de a legnagyobb probléma az, amikor egyáltalán nem jön meg a zöld pipa. A legrosszabb a helyzet talán Firefoxban, ahol a feladványok többségét egyáltalán nem lehet megfejteni, tippre a success rate 10% alatt van.

A probléma a demo oldalon is jelentkezik:
https://google.com/recaptcha/api2/demo

Próbálkoztam sok mindennel:

  • Enhanced tracking protection kikapcsolása,
  • Mindenféle XSS protection kikapcsolása,
  • Reklámszűrő kikapcsolása,
  • A Javascript konzolon lévő mindenféle errorok és warningok debuggolása
  • Szűz profil, pornómód, stb.
  • User agent string módosítás
  • IP cím váltás

Ezek egy része talán érzésre javított a success rate-en, legalábbis igéretesnek tűnt, aztán pár órával később ugyanúgy nem sikerült megfejteni a captchákat.

A dolog ott lett tarthatatlan, hogy manapság már sok olyan weboldal is recaptcha-val védett, ami a mindennapos munka során létfontosságú. (Ideértve pl. állami/közigazgatási oldalakat is)

Kinek mik a tapasztalatai?

Mielőtt még megírnátok:

  • Nem, nem vagyok robot
  • Igen, felismerem a tűzcsapokat, motorkerékpárokat, lépcsőket és közlekedési lámpákat

[Megoldva] SSL sulinet hálózatán

Sziasztok!

Most,hogy a Pro M Zrt átvette a sulinet üzemeltetését nem tudom pontosan kinek és hogyan is kellene megfogalmaznom az igényeinket. Ebben kérem a tisztelt segítségeteket!

Jelenleg van egy weboldalunk az intézménynév.edu.hu domainen. Ennek van természetesen https elérése. Van az intézmény belső VLAN védett hálózatán egy proxmox szerver sok kis apró szolgáltatással (nextcloud, smb, media, pihol, stb) 2 éve hibátlanul működik. Ez természetesen kívülről nem elérhető és ezen nem is szeretnénk változtatni. Jelenleg ip:port eléréssel használjuk a szolgáltatásokat. Amit szeretnénk, hogy intézményen belül működjön egy névfeloldás és https az összes subdomainen. Tehát pl https://media.intézménynév.edu.hu vagy https://nc.intézménynév.edu.hu és így tovább. 

A dns feloldás megoldható szerintem, mert a dashboard felületen ki lehet választani, hogy az adott domainhoz milyen ip-vel szeretnék subdomaint rendelni. 

Kérdéseim:

Szóval lehetséges egyáltalán, hogy a meglévő oldal ssl tanúsítványát használjuk? Ha nem milyen free megoldások adottak? Ha a proxmox szerveren beállítom a https elérést minden szolgáltatást is külön kell konfigurálni, vagy automatikusan veszik át a tanúsítványt? Mennyiben okoz gondot, hogy az egész  miskulancia védett VLAN mögött van? 

Köszönöm!

Let's Encrypt cert megújítási hiba (DNS A rekord lekérési hiba)

Sziasztok!

Let's Encrypt tanúsitványt akartam megújítani (lego acme), de hibába futok bele, pedig évek óta fut a megújítás három havonta.
Elsőként alkalommal CAA rekordot keresett, ezért nem újította meg. Ezt megoldottam. Erre mint egy kalandjátékban új akadály jött:
A mail.cegnev.hu domainra újítanám meg, itt a megújítás kimenete

2025/04/26 22:54:49 [INFO] [mail.cegnev.hu] acme: Trying renewal with 133 hours remaining
2025/04/26 22:54:49 [INFO] [mail.cegnev.hu] acme: Obtaining bundled SAN certificate given a CSR
2025/04/26 22:54:50 [INFO] [mail.cegnev.hu] AuthURL: [eltávolítottam]
2025/04/26 22:54:50 [INFO] [mail.cegnev.hu] acme: use tls-alpn-01 solver
2025/04/26 22:54:50 [INFO] [mail.cegnev.hu] acme: Trying to solve TLS-ALPN-01
2025/04/26 22:55:35 [INFO] Deactivating auth: [eltávolítottam]
2025/04/26 22:55:35 error: one or more domains had a problem:

[mail.cegnev.hu] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: query timed out looking up A for mail.cegnev.hu; DNS problem: query timed out looking up AAAA for mail.cegnev.hu, url:

A DNS A rekordjának a lekérdezése nem sikerül. Amit ma beállítottam, az egy CAA rekord volt, mert erre is panaszkodott a megújítás kérésekor (legutóbb még nem).
A DNS-ben ugyanolyan elnevezéssel szerepel egy 'CAA' és egy 'A' rekord is ("mail")

A googli szerint másnak is volt ilyen gondja és a nameserver üzemeltetője oldotta meg. Írtam már én is nekik, de hétvége van.

Más futott bele ilyenbe, mi lett a megoldás?
Köszi

szilárd

Frissítés1 

Román postától meg (nem) kapott levelek

Sziasztok!

Egy kis segítséget szeretnék kérni. Napi szinten küld a részünkre a román posta elszmolásokat emailben, amit az email szolgáltatónk rfc meg nem felelés miatt elutasít, tehát nem kapjuk meg.

Részletek:

A RO posta a levelet elküldi az info@muzeugelarie.ro és a mindenki.mef@gmai.com címre. A gmailes címre megjön, a másikra nem.
A levelező szolgáltatónk tájékoztatása szerint a következő hibaüzenettel utasítja el a rendszerük a levelet:

F=<mindenki.mef+caf_=info=muzeugalerie.ro@gmail.com> rejected after DATA: syntax error in 'From:' header when scanning for sender: malformed address: <noreply@ro.post> may not follow noreply@ro.post  in "noreply@ro.post <noreply@ro.post>"

Valamint a kommentjük: ha az e-mail címhez tartozó név speciális karaktert is tartalmaz, akkor idézőjelben kell lennie. ( RFC5322 ). Ezt a hibaüzenet - amit már továbbítottuk - egyértelműen jelzi.

A román postával igen nehéz a kommunikáció. Mit írjunk nekik, mit kellene változtatniuk, hogy jó legyen a levél, ne legyen ez a hiba? Ugyanis én nem látok a címben hibát.

Mellékelem az üzenet fejlécét:

Delivered-To: mindenki.mef@gmail.com
Received: by 2002:ac8:624d:0:b0:475:1c70:5e76 with SMTP id kt13csp2582982qtb;
        Tue, 15 Apr 2025 01:06:42 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCWEok/1ho2cIdH3oJFI6Y5RMn804sE9kwH0/lt7Qm47QoAXckXlUWDcYIcr9gpLbZw6YOXp63rxdU4mZtk=@gmail.com
X-Google-Smtp-Source: AGHT+IHo2jidAuj42aqduBWYKbprz1Bc2NJifA/Tm4kFTVIx1/ms/peJg+8PUY+2dGLc09S0QsQN
X-Received: by 2002:a05:690c:6907:b0:6ef:6f24:d093 with SMTP id 00721157ae682-7055998ec9dmr256024867b3.6.1744704402446;
        Tue, 15 Apr 2025 01:06:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1744704402; cv=none;
        d=google.com; s=arc-20240605;
        b=J4EZKEmmPu4i6JExVxVf50WbnB9H+ZEATJEkfD+I9cABm/yGhwcCGwIVxabwTpV0Rp
         eeGXIapQfwraPmQy8V3oYiSd8rzvSX5L5KnYhe2L0SC8RzPnHTJnl3Vu3ggiuPWpiyKP
         yab/aZDLXWa9AhahLvdhpSNdA12rEBc9qRocHwgiFkynYuqBLk1TIJx8PN8ZphRGpTvX
         y6dq6DNyZoML2NYHQYN5wNGQ79Ruo8MJEtUAD/ijD3wTySNyFz9sgZIcpW6Nv92e9yfl
         oL3sRJnNGTfTz1Kheq3GOcL7GJL/ecSfX4h3XlKZJcQDjY4QUHEbIZ4BBOO8BJYifGPs
         xoFg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=date:from:message-id:subject:to:mime-version:dkim-signature;
        bh=nkFlSPE1Gqb9ZI12fVBS5TRoG3p7XBBqPkb6hcwh64A=;
        fh=H79OlrvpVRihXO/Nsw1P9iOFDUweI01BTcqHzBet9Ag=;
        b=Lhyfpwn0VCjQ0F1fuctNFtVYvir16BzndhVCIil76DN5GWl3kgr8Wq1PhK6DtLpFmK
         KGyBmnfcE91PYvDCSymI//500F9ooz+O+31Xzk9/y3TbloRA9Fhbo18RTLppPfrUzJ8R
         Q7OCxTs4fQJBAzUkRB8oAzalfdXjYTZ6q6gH4swQ/z16j4sA2HNerge9xDJGgOoETs4Q
         B9w0It3ah/qrBBeE6Z9QijFlHncEpmYEbs1GutbR7vs2o1Rp0dwnbBuCugGjjEhT6lbZ
         peU0wWa/lkX9czOL3SE4SGWKY5QAb/emWLymqNqwjn89vJ68PEHELvOb6ty5LgSfwDiR
         10BQ==;
        dara=google.com
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@ro.post header.s=nzath202411 header.b=HhGMELia;
       spf=pass (google.com: domain of msprvs1=20200vwvwymka=bounces-1682@spmailtechnolo.com designates 147.253.211.76 as permitted sender) smtp.mailfrom="msprvs1=20200vwvWYMKa=bounces-1682@spmailtechnolo.com";
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ro.post
Return-Path: <msprvs1=20200vwvWYMKa=bounces-1682@spmailtechnolo.com>
Received: from mta-253-211-76.smtp-out.sparkpostmail.com (mta-253-211-76.smtp-out.sparkpostmail.com. [147.253.211.76])
        by mx.google.com with ESMTPS id 00721157ae682-7053e138665si193917327b3.143.2025.04.15.01.06.42
        for <mindenki.mef@gmail.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 15 Apr 2025 01:06:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of msprvs1=20200vwvwymka=bounces-1682@spmailtechnolo.com designates 147.253.211.76 as permitted sender) client-ip=147.253.211.76;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@ro.post header.s=nzath202411 header.b=HhGMELia;
       spf=pass (google.com: domain of msprvs1=20200vwvwymka=bounces-1682@spmailtechnolo.com designates 147.253.211.76 as permitted sender) smtp.mailfrom="msprvs1=20200vwvWYMKa=bounces-1682@spmailtechnolo.com";
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ro.post
X-MSFBL: c1u0l6v9TKSDEcFzVBk7tEyjyzsWoMmlkIMWsjx7VOI=|eyJ0ZW5hbnRfaWQiOiJ zcGMiLCJtZXNzYWdlX2lkIjoiNjdmNDkxMTNmZTY3M2RlMzIxOTgiLCJzdWJhY2N vdW50X2lkIjoiMCIsImN1c3RvbWVyX2lkIjoiMTY4MiIsInIiOiJtaW5kZW5raS5 tZWZAZ21haWwuY29tIn0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ro.post; s=nzath202411; t=1744704402; i=@ro.post; bh=nkFlSPE1Gqb9ZI12fVBS5TRoG3p7XBBqPkb6hcwh64A=; h=To:Subject:Content-Type:Message-Id:From:Date:From:To:Cc:Subject; b=HhGMELia+y9hhY6u3fDJFcHu+HHtQG5Nkm2Y5neiCx9tCLauAOsqNANq5/SxW7AYF
     iFNi6yo8FxxSw20yz7UuH4rWU2kC6tDeEaNOpxg3PPT92bQdW85woE4BXL8miw7VXn
     5dybjuuYmcihs09Hiz30lmPc5iNDhw2gNSUpTI6g=
Authentication-Results: i-0d93dc8e2d1653229.mta1vsmtp.sd.prd.sparkpost smtp.user=<hidden>; auth=pass (PLAIN)
Received: from [159.69.68.133] ([159.69.68.133:56002] helo=nl) by i-0d93dc8e2d1653229.mta1vsmtp.sd.prd.sparkpost (envelope-from <t-bounce-8ed73a2e-19d0-11f0-8db7-1118684969ec@nl.ropost.ro>) (ecelerity 4.8.0.74368 r(msys-ecelerity:tags/4.8.0.17)) with ESMTPSA (cipher=AES-256-GCM) id 89/1A-64280-1931EF76; Tue, 15 Apr 2025 08:06:42 +0000
MIME-Version: 1.0
To: "info@muzeugalerie.ro" <info@muzeugalerie.ro>, "mindenki.mef@gmail.com" <mindenki.mef@gmail.com>
Subject: Fisiere : MUZEU GALERIE SRL transmise in data : 15-04-2025
Content-Type: multipart/mixed; boundary="----MIME delimiter for sendEmail-565177.01277426"
Message-Id: <20250415080638.35623.8ed73a2e-19d0-11f0-8db7-1118684969ec.nl@nl.ro.post>
X-Newsman-RP: t-bounce-8ed73a2e-19d0-11f0-8db7-1118684969ec@nl.ro.post
From: "noreply@ro.post" <noreply@ro.post>
Date: Tue, 15 Apr 2025 08:06:39 -0000

 

Gábor