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

Be van állítva a mail.log fájlra, hogy a logrotate naponta rotálja, mégis tegnap egy napot kihagyott. Előtte is rotált, ma is rotált. Mi lehet az oka?

A logrotate.d/mail fájl tartalma:

/var/log/mail.log
{
    rotate 378
    daily
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

A /var/lib/logrotate/status fájlban minden nap, azaz tegnap is bekerült az aktuális napi dátum.

A naplóban mindhárom napon szerepelnek a következő sorok:

Starting logrotate.service - Rotate log files...
logrotate.service: Deactivated successfully.
Finished logrotate.service - Rotate log files.

Néha még a "logrotate.service: Consumed 2.218s CPU time." sor is szerepel, de más nem, azaz hibaüzenet sincs.

A cron naplójában sem látok semmi furát, eltérést a napok között, nincs hibaüzenet.

Az /etc/logrotate.conf fájlban nincs globálisan megadva a "size" paraméter.

A nem rotált naplóból látszik, hogy minden nap sok sor kerül bele, így a "notifempty" opció sem okozhatta.

Van ötletetek, miért marathatott egyben a tegnapi és a tegnapelőtti log?

Ennek a topiknak a kapcsán gondolkodtam el, hogy mégis, mi haszna? Használná valaki?

Mert hát, ha egy weblapra valami kis izgő-mozgó biszbasz kell, arra sokkal jobb és hatékonyabb a GIF. De még rövid videókra is, mert elég sokat fejlődtek a kvantáló és dithering algoritmusok (aki nem hiszi, látogasson el a giphy-re).

Ha meg valakinek tényleg szűkös a GIF, azoknak régóta ott a WEBP, ami szintén elérhető minden böngészön, kezel palettás képeket, true-color képeket, alfa csatornát és animációt is (nem összekeverendő a WEBM-mel, ami csak videókra jó, transzparens animációkra nem). Egyszóval mindent tud, amit az APNG akar nyújtani, csak hát sokkal jobb a tömörítése.

Szóval a kérdés az, lát-e valaki gyakorlati hasznot abban, hogy szabvány lett az animált PNG? Szerintetek meg fog ugrani az APNG képek száma a wenoldalakon ezután, ha ezidáig elhanyagolható volt annak ellenére, hogy eddig is támogatták a böngészők?

ps: az, hogy az APNG nem hatékony és szar, nem újdonság. Az eredeti PNG fejlesztők is így gondolják, ezért inkább átdolgozták, és a hivatalos PNG oldalon is az MNG-jüket próbálják propagálni helyette (ez se mai gyerek, 1998-as, mégse volt képes ledönteni a GIF-et ez se a trónról).

Próbálom Exim alatt korlátozni, hogy egy IP címről csak mondjuk 5 hibás címzettre tudjon megpróbálni levelet küldeni valaki. Sajnos az eddig próbálkozásaim nem sikerültek. Az exim kézikönyvben nem is látok per_ip opciót a ratelimit-hez.

Ha valaki csinált már ilyet, megköszönnék egy működő szabályt.

2-3 napja eltűnt a YT-videók automatikus lejátszást ki-bekapcsolásának dedikált gombja  (a beállítások gombtől balra volt 1-2 cm-re).

Kicsit szétnéztem, és több friss reddites bejegyzés alapján többek szerint, ez a Google válasza az adblock kiegészítőkre, mivel az adblock kipacsolása után egyeseknél ismét volt leállítási lehetőség az autoplayre.... Valamint a YT automatikusan összeállít egy lejátszási listát a jobb oldali oszlopban, ami véglegesen lelőni sem lehet (ekkor csak összecsukódik).  Ha pedig e lista kerete alatti "szóló" klippre kattintok, akkor új listát állít össze.

Firefox-ESR alapú LibreWolfot használok MX Linuxon incognito módban,  de mivel ez több böngészőben (Chrome, Brave, Firefox)  és Windows alatt is fenáll,  így nemigen nálam lesz a hiba.

Reklámblokkolónak a uBlock Originalt használom, pliuszban még a CanvasBlockert van fenn, de ha uBO-t kikapcsoltam majd a böngésző gyorsítótárának tartalmát törölve (teljes) újrabetöltöttem a YT-ot, akkor sem jelent meg az autoplay on/off gomb.

Tehát akkor vagy nem az adblock miatt van ez, hanem ez egy új "feature" a YT-on, tessék neki örülni.  Vagy pedig valahogy a Google  mégiscsak  valahogy be tud azonosítani a valótlan canvas-adatok és az incognitó-mód ellenére is, és a korábbi blokkoló-használat miatt már listán vagyok, és így nálam már sosem lesz autoplayt kikapcsoló gomb ? ... Ez utóbbi valószínűtlennek gondolom, de sosem tudni. Elvégre "a Google a legjobb barátod",  nem igaz ?

Keresgéltem a Firefox addon-ok közt, de nem igazán találtam olyat, ami:

-- kicsi  (50-60 kB-nál nem nagyobb),

-- ténylegesen kikapcsolja/blokkolja az automatikus lejátszást mellékhatások és a uBlocK Origin kikapcsolása nélkül is,

-- és  lehetőleg nyílt forráskódú.

Általában már az első két feltételen elvéreztek a beépülők.

Tud bárki valami  megoldást, pl. kerülőutasat  az about:config beállításai közt,  vagy akár egy olyan addont, ami valóban blokkolja az automatikus lejátszászt, nem több száz kB-os, nem akad össze az uBO-nel, és lehetőleg opensource is ?

Akár alternatív YT-böngészőt is ajánlhattok.  Minitube-ot próbáltam a böngésző helyett, de olyan kevés funkció van benne, hogy egyelőre nem használnám, ha egy mód van rá.  (Pl. a keresés eredményeként valószínűleg szintén a YT-által összeállított listát tölti be, és pl. a "Kistehén"-re keresve, a listába már nagyon sok nem odaillőt is berak  (az hagyján, hogy más hasonló, "alternatív" zenekarokat is betett a listába, de mikor a "zsiguzsululés cigánygyereket tolta a képembe, az már sok volt).

Köszi minden tippet !

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!

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.

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 – 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. 😊

Sziasztok,

E-mail szolgáltatót keresek, aki saját domainemmel, 2-5 fiókkal, imappal elbír.

Mit tudnátok ajánlani?

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