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

Opera cookies és site data beragad

Sziasztok

A probléma
Opera cookies és site data beragad.
Először Privaccy Security lapon nyomok egy
Céear Browsing data gombot, a History-n kívül mindent töröl elvileg,
majd lemegyek az All data and site data gombra.
Ott bevan ragadva kb minden oldal sütije, ahol voltam,
plusz a Fész, G sütijei.
Ezeket mindet törlöm, majd ujra megnézve ujra ott vannak.
Ezt így vagy 10x ujracsinálva kezdett felmenni a vérnyomásom.
Third party süti tiltva, kepp local data until I
wuit my provser bejelölve.
Rendszer Debian 64bit.
Mintha Windows-os Opera alatt törlődnének ezek.
Hol vannak beragadva?

kösz a választ

Közösségi tartalom / nézettség

Sziasztok,

Szeretném kikérni véleményeteket egy szerintem minden vállalkozó számára fontos dologban. YT és FB közösségi médiáról van szó. Egy barátommal kutatunk és tesztelünk dolgokat egy ideje és megrökönyödve látjuk az eredményt.

Röviden szólva azt tapasztaljuk, hogy egy "mechanizmus" a háttérben blokkolja a mai felhasználót attól, hogy feliratkozó vagy követő közönséget tudjon létre hozni ingyen, de főleg nem könnyedén. És inkább agresszív módon olyan irányba akar kényszeríteni mindenkit ez a mechanizmus, hogy mindenképp fizessen nem keveset azért, hogy a videói nagyobb közönség elé kerüljenek. Ez logikus a szolgálató szempontjából.

Félre értés ne essék. Az természetes, hogy nagy a verseny és hogy ma már egyre jobb tartalom kell azért hogy figyelmet találj és hogy a reklámból nagy pénz esik be a nagy cégeknek. Viszont az alábbi nem normális dolgokat látjuk:

Teljes nyugat <-> keleti láthatatlan tűzfal. Bármit csinálsz, nem jelenik meg a videód a gazdag nyugati szférában. Beraktunk érdemi, érdekes kontenttel csak angolul 45-80 ezres FB csoportba videót, és max 4-5 megtekintés érkezett. Ugyanez 30 db! ilyen csoporttal is max 10 a megtekintés száma, feliratkozóról ne is beszéljünk. Követők csak Pakisztán, India. Félreértés megint ne essék, nem velük van a gond. Ugyanez YT esetén. Nem hozza fel keresésre a videót. Ajánlott tartalmat nyilván nem tudjuk ellenőrizni.

Szerintetek belenyúlhat a találatokba a szolgáltató? Csak kérdezem, nem feltételezem. Nyilván erős érdeke fűződne mindenkinek hozzá hogy ki és mi mennyiszer és hol jelenik meg - komoly marketing érték, viszont most már a nem normális határon túl érzékeljük. Populáris témában is csinál videót barátom és közel nulla megtekintés hosszú időn keresztül gondosan megválasztott leírással és gondos hash tag-ekkel profin megvágva. Az nem normális szerintem hogy nem tudsz összeszedni 20-30 megtekintésnél többet fél éven keresztül adott videón gondos keyword-ökkel angolul profi vidwóval populáris témában.

Nyilván az is érthető hogy a nagy néptömeg az élvezeti és vicces termék kategóriát nézi leginkább. Arra is gondolunk, hogy ma már az emberek nem keresnek a keresőben, hanem csak arra klikkelnek amit feldob a fő oldal. Ezt nem akarom elhinni.

Cáfoljatok meg nyugodtan, érdekelne a véleményetek. Nem spekulálni akarok, hanem megérteni hogy kemény fél év munkával ma miért ilyen nehéz 30-40 embernél többhöz eljutni. Ennyire agresszív lett a piac? Nyilván nem érdeke a nagy cégeknek és még sok más szférának, hogy a "domb" alján lévők figyelmet tudjanak generálni. A hierarchiai struktúrát fenn szeretnék tartani, sőt, csökkenteni a piramis csúcs által bezárt szöget. :) De ezt megint nem akarom elfogadni. A piac nagy része szerintem elég szabad és van lehetőség. Csak éppen a fenti 2 közösségi médiát nem lehet már érdemben használni?

Vagy arról van szó hogy ma már tényleg sikerült az egész iparnak úgy átprogramozni meg elhülyíteni a nagy néptömeget, hogy csak a kaja-pia-szex-sorozat-vicces videók-celebek érdekeljék a népet és ráadásul ott sem keresnek, hanem csak az ajánlott tartalmat fogyasztják? Ezt sem akarom elfogadni.

Többfajta témában is próbálkozik barátom teszt jelleggel, de sikertelenül. Kérlek értsétek úgy, hogy ez egy teszt és alulról vizsgáljuk a dolgot. Tehát nem úgy hogy miért nincs 100e nézettség, hanem hogy fél év alatt még véletlenül sem jut el a videó 30-40 emberhez se. Hangsúlyozom, nem feliratkozóról beszélek hanem megtekintésről! Itt már valószínűségeknek is be kell lépnie.

Mi folyik itt gyöngyösön? :)

Köszi.

Oldal ami kinyírja a Chromiumot

Következő oldal azonnali lemezdarálást, 100%-os processzorterhelést okoz. Már a konzolra váltás és a Chromium kilövése is nehezen jön össze. Kétszer próbáltam, az eredmény ugyanaz. Firefox gond nélkül megnyitja.
Böngésző: Version 62.0.3202.75 (Official Build) Built on Ubuntu

https://port.hu/cikk/mozi/minden-idok-50-legjobb-filmje-a-kritikusok-sz…

PGP kulcs nem frissül

Lehet hogy nem jó kategóriát választottam...

Nemrég módosítottam a PGP kulcsomat androidon: hozzáadtam egy email címet az identities-hez, és eltávolítottam egy másikat. Az OpenKeychain nevű app-al.

Ezután egy másik gépen thunderbird/enigmail-ban rákerestem az email címemre (egy nappal később), és megtalálta a kulcsot. Le is töltötte, de nem az új hanem a régi verziót. Kétszer is ellenőriztem, és ugyan azt a kulcsszervert adtam meg.

Szóval mi okozhatja ezt? Ha küldök egy revocation-ot egy identity-re akkor annak elég gyorsan meg kellene jelennie mindenhol nem?

Csoport tagok elérhetősége

Sziasztok!

Olyan free/opensource web alapú alkalmazást keresek, melynek segítségével egy csoport tagjai jelezni tudják, hogy elérhetők-e egy bizonyos eseményen/időpontban/stb. Az események ad-hoc jellegűek, időpontilag és a helyszín tekintetében nagyban változnak.
Nem lenne baj, ha lehetőség lenne megadni azt, hogy ki milyen képességekkel/eszközökkel/stb rendelkezik és egy egy esemény, vagy időpont kiválasztásánál megadhatnák, hogy mi elérhető a részükre éppen.

Próbáltam a neten kutatni, de sajnos csak ilyen HR-es alkalmazások jöttek szembe, vagy sima naptár alkalmazások. Ezek biztos nagyon jók, de a részünkre nem megfelelőek.

Ha tudna valaki ilyen alkalmazást ajánlani, azt nagyon megköszönném.

Üdv:
J.

Webszerver domain létrehozás - how to

Sziasztok!

Mint ahogy a cím is mutatja,kisebb problémám akadt a domain létrehozással.Mielőtt vázolnám a helyzetet,előrevetíteném,hogy ez egy iskolai projekt része,és sajnos 0 hálózati tudással kell ezt megvalósítanunk.

A feladat így hangzik:
"A vállalat 3 aldomaint használ a webszerveren
-valami1.[cegneve].hu
-valami2.[cegneve].hu
-valami3.[cegneve].hu
Az aldomainokat virtual host-ként kell létrehozni a webszerveren."

Na már most adott egy Ubuntu Server 16.04 VMware Workstationben,rajta Apache2 webszerver. ISPConfig 3.1-gyel próbáltam felkonfigurálni,de valahogy nem igazán sikerült.
A DNS Zone Wizarddal csináltam egy ilyet(az sftdev a fiktív vállalat neve):
https://imgur.com/a/r3RZ9

Létrejön 3 DNS A record: 1 mail nevezetű,1 sftdev.hu nevezetű és 1 www nevezetű,mind az ifconfig által mutatott IP címre hivatkozva.Van még két NS record,sftdev.hu névvel.Az egyiket egy netes útmutató alapján 8.8.8.8 és 8.8.4.4 IP címre írtam(azt hiszem ezek a Google névszerverei).Hozzáadtam kézzel még két CNAME recordot a másik két domainnek.MX record is generálódott mail.sftdev.hu névvel.

A böngészőbe beírva bármelyik címet(sftdev.hu,crm.sftdev.hu stb.) nem hoz be semmit és arra hivatkozik,hogy a kért oldal DNS címe nem található.

Valakinek van valami ötlete,hogy mit csinálhatok rosszul?
Minden segítséget köszönök.

postfix return-path

Hali,

Egy fejlesztőcégnek mi küldjük ki a leveleit user1[AT]cegdomain.hu feladóval, amit DKIM alá is ír, minden nagyon szuper.
Most olyat kellene megoldani, hogy a levelek Return-Path mezőjébe egy user2[AT]bouncedomain.hu kerüljön.
Ők az mondják, hogy nem tudják azt megoldani, hogy kliens oldalon bekerüljön ez a mező, ezért nekünk kellene postfix-el ezt megoldani.

Amit próbáltam:

1. eset
main.cf-be

smtp_generic_maps = hash:/etc/postfix/generic

/etc/postfix/generic tartalma:

user1[AT]cegdomain.hu user2[AT]bouncedomain.hu

Eredmény: levél aláíródik, de mivel átírja a From és a Return-Path mezőt is, a célhelyen DKIM fail lesz. NEM JÓ!

2. eset
main.cf-be

sender_canonical_maps = hash:/etc/postfix/sender_canonical

/etc/postfix/sender_canocical tartalma:

user1[AT]cegdomain.hu user2[AT]bouncedomain.hu

Eredmény: levél nem íródik alá és átírja a From és a Return-Path mezőt is. NEM JÓ!

Hogyan tudom megoldani, hogy a From maradjon meg az eredeti, a DKIM is aláírja és a Return-Path user2[AT]bouncedomain.hu legyen?

Google maps térkép megjelenítési hiba

Érdekes maps hibát találtam (van nálam?), kb. 2 hónapja. Vagy nem jó kifejezésekre kerestem, vagy más még nem találkozott vele, de a Google nem volt a barátom. Az eredeti hiba Chrome és Firefox alatt is előállt.

Hiba: a www.google.hu/maps oldalt betöltve, egy pillanatra megjelenik a térkép, majd eltűnik, és csak a világos rács marad. Zoomolni tudok, de csak a rács mérete változik.
Ha átváltok műholdas nézetre, akkor az rendben megjelenik. Visszaváltra térkép nézetre, megint csak a rács jelenik meg.

Eddig úgy kerültem meg a problémát, hogy a www.google.com/maps oldalt nyitottam meg. Ilyenkor ugyan szintén átváltott a .hu/maps oldalra, és a térkép egy pillanat után ugyanúgy eltűnt. Azonban alul volt egy link, amivel már ténylegesen a .com/maps oldalt töltötte be a böngésző, és ott jó volt a térkép.

Kb. két hete ez megváltozott. A Chrome-ban a .com/maps cím helyett továbbra is a .hu/maps-et tölti be, de a .cöm/maps-re váltásra szolgáló link már nem jelenik meg. A firefoxban továbbra is működik az előbbi workaround, de nincs már rá szükség, mert a .hu/maps is jól működik.

(A maps.google[.hu|.com]-ról indulva is ugyanígy hibás a megjelenítés.)

A hétvégén Ubuntu 17.04-ről 17.10-re upgradeltem, de ebből a szempontból nem változott semmi. A uBlock Origin kikapcsolásával már próbálkoztam.

Tipp, ötlet, javaslat?

Bejövő emailek kezelése központilag

Sziasztok!

Cégünk központi email címére érkező leveleket jelenleg 2 kolléganő próbálja kezelni megosztott Exchange postaládán keresztül. Ezen szeretnénk változtatni, mivel előfordul, hogy fontos üzenetek "elkallódnak". Korábban az volt az elv, hogy mindenki látott mindent, de így sem volt jó hiszen nem volt semminek gazdája, mindenki foglalkozott mindennel de senki nem intézett el semmit.
Egy olyan rendszer után kutatok, amely hozzáilleszthető egy, vagy több postaládához, és a beérkező levelek kapnak egy pl. ügyszámot majd azzal ha valaki foglalkozik az a többiek számára is látszik. Ha elintézte lezárja stb.
Gondoltam az OTRS-re is, de kicsit okosabb rendszer mint az adott feladat.
Van ötletetek, hogy a legegyszerűbben hogyan lehet ennyit megoldani?

Köszi!

LWIP TCP RAW HTTP kommunikáció pontosan hogyan?

Egy kis erőforrásigényű webszervert készítek, az LWIP tcp kezelésére alapozva, de nem sikerül megtalálnom az optimális HTTP csomagküldési módszert.
Ha az LWIP netconn csomagjára bízom a teljes pufferkezelést, akkor viszonylag gyakran előáll a termelő-fogyasztó probléma, emiatt befagy a kérelem kiszolgálása.
Emiatt az LWIP raw csomagját használom, ami szép gyorsan képes kiszolgálni a kérelmeket, de sehol semmilyen dokumentációt nem találok arról, hogy hogyan kellene generálnom egy HTTP kérésre a választ.
A példák alapján:
- ha tcp-echo szerű válaszokat akarnék, azaz egy csomagra egy csomagot válaszul, akkor a kérelem TCP csomag fogadásának (tcp_recv) eseményénél rögtön el is küldhetem tcp_write művelettel a válasz csomagot.
- ha fix, nagyméretű pufferből akarnák választ kiszolgálni, akkor a beérkező csomag fogadásánál elküldök egy tcp_sndbuf() által meghatározott maximális méretű csomagot, majd a csomag fogadásának visszaigazolása után egy újabbat és egy újabbat ...
De mi van, ha dinamikusan akarok sok válaszcsomagot küldeni egyetlen beérkező tcp kérelemre?
Ha a tcp_recv eseményénél elkezdem tcp_write()-tal teleírni a puffert, a válasz soha nem jut el a kérelmezőhöz.
Olyan, mintha a tcp_recv esemény lefutása után kezdené csak el kiüríteni a tcp_write()-tal teleírt puffert. Azaz pici, rövid válaszokat könnyű itt generálni, de nagy hosszú válaszokatat nem. S bár van olyan művelet, amivel tudom jelezni, hogy a kérelem csomagja már feldolgozva, ezek után sem kezdődik meg rögtön a válasz elküldése.
Mivel a dokumentációk sehol sem említik ezt, azt várnám, hogy a tcp_write()-tal teleírom a puffert, ami a háttérben, azonnal elküldésre kerül, amint lehetőség nyílik rá. Tehát írok, majd várok, ha már nincs hely a tcp puffer-ban, és ha kiürült a puffer, folytatom tovább az írást.
Ez azonban rém lassú kommunikációt ereményez. Ha néha manuálisan beteszek egy tcp_output() műveletet, hogy küldje ki a puffert, ez gyorsít, de még mindig nem azonnali a válasz.
Nem tudom, hogyan kellene használnom a tcp_write parancsot hogy optimálisan tudja visszaküldeni a választ.
Jelenleg a legjobb megoldásom, hogy a kérelem fogadásánál elindítok egy külön szálat, ami elkezd tölteni egy puffert, és az eredeti szálban pedig figyelem, hogy van-e a pufferban adat, ha igen, akkor a tcp_write()-tal elküldöm, míg a puffer ki nem ürül, és lezárásra nem kerül. Ekkor én is lezárom a tcp kapcsolatot.
Az eredmény bár működik, de mégis nyökögős és siralmas.
A tcp_write már maga is kezel egy puffert, teljesen feleslegesnek tűnik párhuzamosan még egy kezelése. De nem tudom, mi lenne az optimális módja a csomagok küldésének. És akkor még a POST kérelmekről nem is beszéltem, ahol a POST adat egy külön csomagban érkezik, tehát nem elég az első fogadott csomagot ismernem ahhoz, hogy válaszoljak. Természetesnek tűnik, hogy akkor először fogadjunk minden csomagot, és ezek után kezdjünk csak el válaszolni, de ez meg túl erős megkötésnek tűnik, ha például egy fájlfeltöltést akarnánk kezelni, ahol POST-ban jön a feldolgozandó adat folyamatosan.
Tehát minden beérkező kérelem esetén kellene tudnom valamekkora választ generálnom, és ezt folyamatosan vissza kellene tudnom juttatni a kliens felé, függetlenül a válasz méretétől. Ha pedig megtelik a puffer, valahogy várakoztatnom a válasz generálását.
A feladatot csak nehezíti az, hogy nem túl sok erőforrás áll a webszerver rendelkezésére, így az nem megoldható, hogy először legenerálom a teljes választ egy pufferbe, majd onnan szépen egyesével kiküldöm a csomagokat, mivel a teljes válasz egyszerűen nem fér el a memóriában.
Ha valakinek van tapasztalata alacsony szintű webszerver készítésében, érdekelne, hogyan oldotta meg ezt a problémát.
De, ha tudtok egy jó leírást arról, hogy pontosan hogyan is kell zajlania a HTTP alatt a csomagok cseréjének, és ezt az LWIP hogyan támogatja, az is nagy segítség lenne.
És köszönöm, már azt is, ha csak eddig elolvastad. ;)