sandros összes bejegyzése

Hétköznapi

Web hosting in 2025?

Between 2010 and early 2014, I was immersed in building a control panel, which I called GSCP. I actually got it working on both Linux and Windows, though it was super focused just for managing game servers. It felt like a pretty big personal project at the time.

There were a number of versions. The first one worked fine on both Windows and Linux, but then from version 2.0.0, I just went all-in on Linux. Then, things got even cooler, with GSCP 2.2 I managed to add support for Apache virtual hosts, and by 2.3, Postfix/Dovecot accounts were in. The real mind-blower was 2.3.2 it could actually scale horizontally and run with redundancy, and even got it to work as a load-balanced cluster with Apache and DB replication. Like how nuts is that for something I was just tinkering with?

It ended up being good for so much stuff, and over those 3-4 years of coding, it evolved to a point where it could securely handle really busy websites. Well, it did not handle the websites, but the auto configuration for the stack.
Since I mainly built it for myself and a small group of friends and clients, and it did everything I needed, I kind of considered it „done” (you know, „feature-complete.”) After that, it only got little bug fixes every now and then.

Then, after 2014, my focus just drifted. I started messing around with other hardware projects, even offline stuff, only occasionally touched web analytics or web auth. The GSCP project just kind of stayed put. And honestly I thought it probably wouldn’t have made much sense to keep going anyway, because that was the time when all the microservices and containerization stuff started blowing up, and my „native-first” approach just felt a bit oldschool.

What’s now?

Since 2020 I somehow found myself back in web hosting, and well… Seriously, almost nothing has changed in the big picture if we only compare shared hosting, since online site builders are out of my scope. Like, okay, sure, 15 years ago we weren’t throwing Nginx in front of every Apache server in existence, there was no QUIC, maybe not even HTTP/2. But if you strip those away, you’re pretty much getting the exact same setup in a supposedly „modern” environment as I was working with back then.

And what does that even mean? Is this actually okay?

For shared hosting, there are some decent options out there now in case of control panels, for sure. Like, HestiaCP seems pretty solid if you install it on a basic Debian/Ubuntu server out of the box. If you don’t think about it much just install it, you’re pretty much good to go, even if you host a bigger number of sites, because they recently added resource limits.

But then you see other stuff that I’m hoping vendors and contributors will add. For example IPv6 is not currently something you can just use with Hestia, it needs manual work to enable as of now but it’s a community project so might aswell contribute to it. And there are things even in paid options, like the complete lack of everything needed for a secure and stable experience which is mad.

Okay so I just wanted to add that it might seem like I’m really shilling for Hestia, but I totally don’t want to. There are a ton of projects you can pick from, but this one just happens to be the closest to me. I also think the contributors and main devs behind it are really cool, even though I don’t know any of them personally, just from seeing them in GitHub issues and discussions.

I really hope I didn’t accidentally sneak in any hidden suggestions for you. I’m definitely not trying to tell you what provider, service, panel, or anything else to choose. I just wanted to share my past thoughts and what I’m currently thinking about how things were and how they are now, from my perspective.

The only thing I can and do want to suggest is this: support the project you genuinely like and use every day. If you can, of course. It doesn’t matter whether it’s a monetary donation, contributing quality code, or just respectfully reporting issues. It really matters, and it shows that you care.

GSCP not coming back, there’s no point. In very rare cases when we need High Availability and Load balancing, I do it manually.

SysAdm

Saját E-mail kiszolgáló – 3. SPF, DKIM, DMARC rekordok

Az e-mail hitelesítés három kulcsfontosságú eleme az SPF, DKIM és DMARC rekord. Ezek a DNS bejegyzések segítenek megakadályozni, hogy illetéktelenek küldjenek e-maileket a nevünkben, valamint javítják a kézbesítési arányt, csökkentve a spam mappába kerülés esélyét.

1. Mi az SPF rekord?

Az SPF (Sender Policy Framework) egy DNS rekord, amely meghatározza, hogy mely szerverek jogosultak e-maileket küldeni egy adott domain nevében. Az e-mail fogadó szerverek ezt a rekordot ellenőrzik, és ha az e-mail egy nem engedélyezett szerverről érkezik, azt spamként kezelhetik vagy elutasíthatják.

SPF rekord példa:

v=spf1 mx include:_spf.google.com -all

Ebben a példában:

  • A v=spf1 jelzi, hogy SPF rekordról van szó.
  • Az mx azt jelenti, hogy a domainhez tartozó levelezőszerver küldhet e-maileket.
  • Az include:_spf.google.com lehetővé teszi, hogy a Google szerverei küldjenek levelet a domain nevében.
  • A -all azt jelzi, hogy minden más szerver elutasításra kerül.

2. Mi az a DKIM rekord?

A DKIM (DomainKeys Identified Mail) egy olyan mechanizmus, amely digitális aláírást ad az e-mailekhez. Ez a fogadó szerver számára biztosítja, hogy az üzenet valóban az adott domaintől származik, és nem módosították útközben.

DKIM rekord példa:

default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Ebben a példában:

  • A default._domainkey.example.com a DKIM rekord neve.
  • A v=DKIM1 jelzi, hogy DKIM rekordról van szó.
  • A k=rsa az RSA titkosítási algoritmust használja.
  • A p= utáni hosszú karaktersor a nyilvános kulcs, amelyet a fogadó szerverek az aláírás ellenőrzésére használnak.

3. Mi a DMARC rekord?

A DMARC (Domain-based Message Authentication, Reporting & Conformance) egy szabályrendszer, amely előírja, hogy az SPF és DKIM ellenőrzéseknek hogyan kell működniük a domain esetében. Segítségével beállítható, hogy a sikertelen ellenőrzések esetén mi történjen az e-mailekkel, valamint jelentések kérhetők a levélfogadási problémákról.

DMARC rekord példa:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Ebben a példában:

  • A v=DMARC1 jelzi, hogy DMARC rekordról van szó.
  • A p=quarantine azt határozza meg, hogy a sikertelen ellenőrzéseket végző leveleket karanténba (spam mappába) helyezzék.
  • Az rua=mailto:dmarc-reports@example.com e-mail címre kerülnek a jelentések a sikertelen hitelesítési próbálkozásokról.

4. Miért fontos ezeknek a rekordoknak a beállítása?

Ha helyesen konfiguráljuk az SPF, DKIM és DMARC rekordokat, az e-mailjeink hitelesítésen mennek keresztül, és kisebb az esélye annak, hogy a címzett spamszűrője kiszűri őket. Emellett védelmet nyújtanak az e-mail hamisítás (spoofing) és az adathalászat ellen.

SysAdm

Saját E-mail kiszolgáló – 2. Hitelesítés

Az e-mail küldésekor számos tényezőt figyelembe kell venni annak érdekében, hogy az üzenet elérje a címzettet, és ne minősüljön kéretlen levélnek. Az alábbiakban bemutatjuk, milyen technikai beállítások szükségesek a sikeres kézbesítéshez.

1. Az e-mail hitelesítés alapjai: SPF, DKIM és DMARC

A levelező rendszerek egyre szigorúbb ellenőrzéseket végeznek a nem kívánt üzenetek kiszűrése érdekében. Három alapvető DNS rekord segíthet a hiteles levélküldésben:

  • Az SPF (Sender Policy Framework) meghatározza, hogy egy adott domain nevében mely szerverek küldhetnek levelet.
  • A DKIM (DomainKeys Identified Mail) digitális aláírással látja el az üzeneteket, így biztosítva azok hitelességét és érintetlenségét.
  • A DMARC (Domain-based Message Authentication, Reporting & Conformance) irányelveket határoz meg az SPF és DKIM ellenőrzések érvényesítésére, valamint jelentéseket küld a beérkező e-mailek állapotáról.

Ha ezek a rekordok megfelelően be vannak állítva, a küldött levelek nagyobb eséllyel érnek célba anélkül, hogy spamként lennének kezelve.

2. Az ingyenes e-mail szolgáltatások korlátai

Ha Gmail, Outlook vagy más ingyenes levelező szolgáltatást használunk, a DNS rekordok beállítása nem módosítható, mivel ezek a szolgáltatók kezelik a domaint. Emiatt saját e-mail hitelesítést nem tudunk végrehajtani.

Egyes szolgáltatók lehetőséget biztosítanak külső SMTP szerver használatára, amelyen keresztül üzenetek küldhetők. Ha egy rendszer vagy alkalmazás támogatja ezt a megoldást, érdemes kihasználni. Bizonyos esetekben azonban, például egyes hírlevélküldő platformoknál vagy szervezeti levelezőrendszerekben, nincs lehetőség külső SMTP beállítására. Ilyenkor az ingyenes e-mail címet nem lehet megfelelően használni levélküldésre.

3. A saját domain előnyei a levélküldés során

Saját domain használatával sokkal nagyobb ellenőrzésünk lehet az e-mail hitelesítési folyamat felett. A DNS rekordok beállításával biztosíthatjuk, hogy üzeneteink megfelelően hitelesítve legyenek.

Milyen lépések szükségesek a beállításhoz?

  • Az SPF rekordban meg kell adni, hogy mely szerverek küldhetnek levelet a domain nevében.
  • A DKIM segítségével digitálisan aláírhatjuk az üzeneteket, amelyeket a fogadó szerverek ellenőrizhetnek.
  • A DMARC szabályozza, hogy a fogadó rendszerek hogyan kezeljék az SPF és DKIM ellenőrzéseket, valamint visszajelzést küld a küldési eredményekről.
SysAdm

Saját E-mail kiszolgáló – 1.5 Mailu beüzemelése

Az alább olvasható leírás egy nagyon leegyszerűsített, felületes leírása annak, hogy milyen lépéseket kell megtenni a Mailu sikeresen konfigurálásához és futtatásához.

Mindenképpen az aktuális hivatalos leírást kell követni a megfelelő működéshez. A tartalom írásának idején a 2024.06 verzió érhető el melyet ide kattintva lehet megtalálni. A leírás 1:1-ben történő lemásolásának nem látom értelmét. Ha valóban az a terv, hogy egy működő Mailu install jöjjön létre, azt kell követni.

A terep előkészítése: A szerver és a domain

Mielőtt bármibe is belekezdenénk, elengedhetetlen, hogy biztosítsuk a megfelelő alapot. Ez azt jelenti, hogy szükségünk van egy Linux-alapú szerverre. A Mailu, mint egy modern levelezőszerver, Docker konténerekben fut, ami nagy rugalmasságot és egyszerű kezelhetőséget biztosít. Az Ubuntu vagy Debian disztribúciók kiváló választások, mivel széles körben támogatottak és stabilak.

A szervernek rendelkeznie kell egy publikus IP-címmel, hogy a külvilág elérhesse. Gondoljunk csak bele, a levelezés lényege a kommunikáció, és ehhez elengedhetetlen, hogy a szerverünk elérhető legyen az internetről. Ne feledkezzünk meg a megfelelő erőforrásokról sem. A RAM és a tárhely kulcsfontosságúak a zökkenőmentes működéshez. Egy levelezőszervnek képesnek kell lennie kezelni a beérkező és kimenő leveleket, tárolni a felhasználói postafiókokat, és futtatni a szükséges szolgáltatásokat.

A domain név a mi digitális identitásunk lesz. Ez az a cím, amelyet az emberek használni fognak, amikor e-mailt küldenek nekünk. Regisztráljunk egy domain nevet, és állítsuk be az A rekordot a szerverünk IP-címére. Ez a DNS rekord köti össze a domain nevünket a szerverünkkel, lehetővé téve, hogy az e-mailek eljussanak a megfelelő helyre.

Docker és a Docker Compose telepítése

A Mailu Docker konténerekben fut, ami azt jelenti, hogy a telepítés és a frissítés egyszerű és gyors. A Docker egy konténerizációs platform, amely lehetővé teszi, hogy az alkalmazásokat elszigetelt környezetekben futtassuk. A Docker Compose pedig egy eszköz, amely segít a többkonténeres alkalmazások kezelésében.

Az Ubuntu/Debian rendszereken a Docker és a Docker Compose telepítése egyszerű. Először frissítjük a csomaglistát, majd telepítjük a szükséges csomagokat. Ez a folyamat biztosítja, hogy a legfrissebb verziókat kapjuk, és hogy minden szükséges függőség telepítve legyen.

Mailu konfigurálása

A Mailu konfigurációjának szíve a mailu.env fájl. Ebben a fájlban adjuk meg a levelezőszerverünk alapvető beállításait. A MAILU_HOSTNAME változóban adjuk meg a levelezőszerverünk hostname-jét, például mail.pelda.hu. Ez a név lesz használva a levelezőszerver azonosítására az interneten.

A MAILU_ADMIN_PASSWORD változóban adjuk meg az adminisztrátori jelszót. Ez a jelszó védelmezi a Mailu webes felületét, ahol a felhasználókat és a domaineket kezelhetjük. Válasszunk egy erős jelszót, amely nehezen kitalálható.

Mailu futtatása

A Mailu telepítéséhez letöltjük a Mailu Docker Compose fájlját (docker-compose.yml). Ez a fájl leírja a Mailu konténereit és azok beállításait. A Docker Compose segítségével könnyedén elindíthatjuk a Mailu-t egyetlen paranccsal: docker-compose up -d.

Ez a parancs letölti a szükséges Docker konténereket, elindítja őket, és a háttérben futtatja a Mailu-t. A -d opció biztosítja, hogy a konténerek a háttérben fussanak, így nem kell folyamatosan nyitva tartanunk a terminált.

Webes felület és az e-mail kliensek

A Mailu webes felülete a https://mail.pelda.hu/admin címen érhető el. Itt jelentkezhetünk be az adminisztrátori jelszóval, és kezelhetjük a felhasználókat, domaineket és egyéb beállításokat.

Az e-mail kliensekben a következő beállításokat kell használnunk:

  • Bejövő levelek (IMAP/POP3): mail.pelda.hu
  • Kimenő levelek (SMTP): mail.pelda.hu
  • Felhasználónév: felhasználónév@pelda.hu
  • Jelszó: a felhasználói fiók jelszava
SysAdm

Saját E-mail kiszolgáló – 1. Szoftverek kiválasztása

Az e-mail kiszolgáló létrehozása és üzemeltetése komoly technikai kihívásokat jelent, de többféle megoldás létezik attól függően, hogy milyen mértékű irányítást és testreszabhatóságot szeretnénk.

Saját E-mail kiszolgáló manuális telepítése és konfigurálása

Ha teljes ellenőrzést szeretnénk az e-mail szerverünk felett, manuálisan telepíthetünk és konfigurálhatunk egy teljes körű levelezési rendszert. Ez nagy technikai tudást igényel, de teljes rugalmasságot biztosít.

A szükséges komponensek:

  • Exim/Postfix – Az e-mailek küldéséért és fogadásáért felelős MTA (Mail Transfer Agent).
  • Dovecot/Cyrus IMAP – Az IMAP és POP3 protokollokat biztosító levélkézbesítő szerver.
  • Sieve – Szabályalapú e-mail szűrés és automatizált üzenetkezelés.
  • SpamAssassin (spamd) – Kéretlen levelek szűrésére használt eszköz.
  • Amavis/ClamAV – Vírusellenőrzést végző alkalmazások.
  • Roundcube/RainLoop – Webmail felület, amely lehetővé teszi az e-mailek böngészőből történő elérését.
  • Let’s Encrypt vagy más tanúsítványkezelő – Titkosított kommunikáció biztosítása SSL/TLS segítségével.

Előnyök:

  • Teljes kontroll az e-mail szerver beállításai felett.
  • Testreszabhatóság és egyedi szabályok kialakítása.

Hátrányok:

  • Magas technikai tudást igényel.
  • Folyamatos karbantartás és biztonsági frissítések szükségesek.
  • Nehezebb hibaelhárítás és skálázás.

Kész E-mail megoldások

Akik nem szeretnének minden egyes komponenst külön beállítani, választhatnak előre elkészített, könnyebben kezelhető e-mail szerver megoldásokat. Ezek a rendszerek tartalmazzák az összes szükséges komponenst és gyakran webes kezelőfelületet is biztosítanak.

Népszerű megoldások:

  • Mailcow – Teljes funkcionalitású levelezési rendszer Docker alapokon, amely tartalmazza a Postfix, Dovecot, SoGo, ClamAV, SpamAssassin és más kulcsfontosságú szolgáltatásokat.
  • Mailu – Könnyen telepíthető, minimalista levelezőszerver, amely Postfix, Dovecot és más e-mail komponenseket kombinál.
  • Mail-in-a-Box – Automatizált levelezési rendszer Ubuntu alapokon, amely egyszerűsített telepítést és konfigurációt biztosít.
  • Zimbra – Professzionális levelezőrendszer, amely teljes körű vállalati funkciókat biztosít, beleértve a webmailt, naptárkezelést és csoportmunkát.

Előnyök:

  • Gyors és egyszerű telepítés.
  • Egyszerűbb karbantartás a manuális megoldásokhoz képest.
  • Rendszerint beépített webes kezelőfelület és felhasználókezelés.

Hátrányok:

  • Kevesebb rugalmasság és testreszabhatóság.
  • Néhány rendszer erőforrásigényes lehet.
  • Egyes megoldások nem teljesen ingyenesek (pl. Zimbra vállalati verziója).
3D

3D Nyomtatás: BMW E90, E92 olaj tartó csomagtartóba

Korábban találtam egy csomagtérbe tehető kis betétet, amely stabilan tart 1L-es olajat. Ez elég hasznos tud lenni, mert gyárilag a hátsó erősítős modellekben szinte semmi hely nincs a bal oldali tartóban ilyenre, jobb oldalon pedig a gyári elsősegélycsomag helye túl nagy erre és bizonyos esetekben simán kirepül belőle az olaj (vagy bármi nagyobb).

Ez a modell Motul 1L-hez (8100) lett tervezve, de már volt igény Liqui-Moly változatra is, így abban is elérhető.

Ha szeretnél készen kézhez kapni egy ilyet, írj egy üzenetet.

Ha már van 3D nyomtatód és megpróbálkoznál a nyomtatásával, innen letöltheted a szükséges fájlt.

Random

Anti EU süti törvény

Nem tudom hogy vagy vele, de nekem már mindenem kivan a sok „fogadd el a sütit” csíkokkal. Én egy helyre sem tettem ki, minek? Ártott eddig valakinek egy pár süti? Szerintem sem.

Mi lenne a lényege? Az, hogy bizonyos oldalak és szolgáltatások az engedélyed nélkül ne követhessék a tevékenységeidet. Mi a valóság? Ugyanúgy követik. Érdekel ez bárkit is? Nem. Aki nem akarja, hogy követhető legyen, azt pont nem ez fogja megvédeni, hanem a megfelelő böngésző beállítások, az AdBlock / uBlock Origin / hasonló bővítmények, valamint ilyen célból üzemeltetett DNS szerverek és specifikusan erre készült egyéb szoftverek.

Mi a hátránya annak, hogy követnek?

Böngészési információkat általában két okból gyűjtünk. Egyrészt statisztika miatt (milyen korosztály látogatja az oldalt, honnan érkeztek a látogatók, meddig nézték az oldalt, milyen funkciókat használnak, stb). Ez azért fontos az üzemeltetők számára, mert ilyen információkból tudják tovább fejleszteni az oldalt / szolgáltatást jó irányban. Másrészt releváns hirdetések megjelenítésére használjuk. Ha már reklámokat vagyunk kénytelenek megjeleníteni, akkor egy film bemutatója alatt sokkal jobban mutat egy mozit reklámozó szalag, mintha egy mosógépet próbálnánk rásózni a gyanútlan látogatóra.

Ezek az információk értékesíthetők

A megjelenített hirdetések után a szolgáltatás üzemeltetője pénzt kap. (Nyilván nem azért helyezünk ki hirdetéseket, mert szépek.) Mivel releváns dolgokat találsz az oldalon, nem pedig random hülyeségeket, ezért elképzelhető, hogy rá is kattintasz párra, amiből mégtöbb részesedést kapunk. Van ezzel baj? Nincs. Ugyan ez megy a TV-ben, rádióban, kivéve, hogy ott nincs igazán célozva egy-egy hirdetés.

Ha már ennyi inkompetens hoz törvényeket, hogyan védekezzünk a csíkok ellen?

Mint korábban említettem, AdBlock / uBlock Origin és egyedi DNS szerver.
Az AdBlock-ból az AdBlock Plus változatot ajánlom. Itt alapértelmezetten engedélyezve vannak a „nem zavaró” hirdetések, amiket egyéni ízlésednek megfelelően le is tilthatsz. uBlock esetén az Origin változatot ajánlom, ahol a haladó beállítások engedélyezése után sok-sok listát kiválaszthatunk.

A bejegyzés írásának idejében egyikben sincs alapból benne a Prebake lista, mely a süticsíkok eltávolítására hivatott. A bővítmények telepítése után ezt itt engedélyezheted: http://prebake.eu/

Egyedi DNS szerverekkel a süticsíkok ellen nem is, de a követés ellen hatásosan védekezhetsz teljes otthoni hálózatodon is. Ezt nem feltétlenül kell minden egyes gépen beállítani. A routered admin felületére belépve keress DNS1 és DNS2 részeket. Itt add meg az általad választott szolgáltató címeit, mentsd el, majd indítsd újra a routered. Itt fontos megemlítenem, hogy nem minden egyedi DNS szolgáltatás biztosít követés elleni védelmet. Van, amelyik a biztonságra megy, másik gyorsaságra. Itt van pár példa, amiket szabadon használhatsz:

    • Open DNS
    • Fool DNS
    • Next DNS

Használhatom ezeket a megoldásokat telefonon és tableten is?

Amennyiben a DNS megoldást választottad és routeren állítottad be, úgy amíg a saját WiFi hálózatodon használod az eszközt, azon is ugyan úgy működik. Ha mobilneten ill. máshol is meg szeretnéd tartani a reklámmentes élményt, úgy három választásod van:

    • Firefox for Android
      Itt ugyan úgy telepítheted a bővítményeket (uBlock, AdBlock), mint gépen.

    • Alkalmazások
      Pl.: https://block-this.com/
      Fontos! Vannak olyan „reklámblokkoló” alkalmazások, amelyek több kárt okoznak, mint hasznot. Csak óvatosan!

Konklúzió

A „fogadd el a sütiket” hülyeségnek semmi értelme nincs. Ha valóban védekezni akarsz vagy el akarod kerülni ezeket a szarokat, lásd a megoldásokat fentebb.

Update: Ugyan eltelt pár év azóta, hogy megírtam ezt a bejegyzést, de végeredményben az álláspontom nem változott. Annyival egészíteném ki, hogy nagyjából ennek az egésznek a kezdetén indult be a nagyon invazív profilalkotás, ami már nem csak általános navigációs előzményekből tevődik össze, hanem cross-platform alkalmazott különféle megfigyelési/lehallgatási procedúrákból (keress rá, számtalan demo létezik arról, hogy mit csinál 1-1 alkalmazás a háttérben). Ezzel szemben aktívan fel kell lépnie a felhasználóknak és a szabályozó szervezeteknek is.

A mai napig nem sikerült megoldani, hogy az ilyen sütis borzadályok tiszteletben tartsák a böngésző beállításait ahelyett, hogy felugornának, blokkolnák az oldal használatát ésatöbbi. Nyilván így könnyebb rávenni a felhasználót, hogy fogadja el és betöltse az összes létező spywaret.

Androidon gyárilag megjelent a Private DNS funkció (már jó pár verzióval ezelőtt, talán 9-ben először), amelyet megfelelően használva egész jó eredményeket lehet elérni a követő szolgáltatók, de nem utolsó sorban a malware site-ok és hirtedések blokkolásával. A sok közül talán az egyik legjobban személyre szabható szolgáltatás a nextdns.io. Érhető leírásuk van, hogyan tudod használni és beállítani. Választhatod a self-hosted utat is pl. AdGuard Home instance-el, ha kicsit kalandvágyóbb vagy és van erre erőforrásod.

Hétköznapi

Lépések, hogy az elhagyott telefon hamarabb visszajusson tulajdonosához

Zárképernyő és azon megjelenő információk

Zárképernyőt minden esetben tanácsos beállítani (PIN, Pattern, Smart Lock és/vagy ujjlenyomat), mert ebben az esetben ha a megtaláló kíváncsi vagy nem becsületes, nem tud személyes adatokhoz hozzáférni és nem tudja gyári beállításokra visszaállítani a telefont.

Zárképernyőre érdemes kiírni egy másik telefonszámot amin elérhetnek, vagy egyéb elérhetőséget.

Amennyiben nincs ujjlenyomat olvasó a telefonon, ajánlom a PIN vagy Pattern lock mellé a Smart Lock használatát. Ezzel be tudod állítani, hogy általad megadott helyeken (pl. otthon) vagy bizonyos eszközökhöz csatlakozva (pl. óra, bt hangszóró) ne kérjen azonosítást a feloldáshoz. Ezek mellett van lehetőség Face unlock használatára, ami az előlapi kamerát használva azonosít, illetve On-body detection-re, ami azt figyeli, hogy mindvégig nálad volt-e a készülék.

Android Device Manager

Az alkalmazás használatához engedélyezned kell a Location history-t (magyarul Helyelőzmények), amit a Google Beállítások részen tehetsz meg. Ezt engedélyezve a készülék rögzíti és elküldi a tartózkodási helyét, így követni lehet, hogy éppen hol van. Az alkalmazással továbbá meg lehet csörgetni a telefont és végső esetben törölni lehet annak teljes tartalmát. Az alkalmazás böngészőből is elérhető a play.google.com oldalon a Beállítások menüből.

SD Kártya és készülék titkosítása

Android 5.1.1-től lehetőség van az SD kártyák titkosítására (4.4.4-től a telefonok titkosítására), így hiába veszi ki valaki a kártyát, nem tud hozzáférni semmilyen adathoz. Ezt a Beállítások – Biztonság részen kapcsolatod be.

Régebbi készülékek

Mivel a Google Play Services régebbi verziókon is frissül jelenleg is, így az Android Device Manager is működik. SD kártya titkosításra nincs lehetőség, így ha nagyon paranoid vagy, akkor a sexy time tartalmakat a belső memórián tárold.

Még mit?

Számtalan olyan app van, ami azt reklámozza magáról, hogy tisztítja a telefont és extra védelmet biztosít. Ezek 99.9%-a bullshit! Kerüld el messziről az összes CM-el kezdődő és CleanMaster által publikált appokat. Komolyan. Ezek nem gyorsítanak, inkább lassítanak. Biztonság helyett pedig a háttérben szivárogtatja a telefonodon lévő adatokat és reklámokkal halmoz el.

Random

SQL Indexes for president

Volt már olyan, hogy teljesen elfelejtettél MySQL táblákban indexeket megadni? Nem? Akkor jó.

Én ugyanis egy jelenleg majdnem félmillió soros táblából felejtettem ki 5 indexet és csodálkoztam, hogy percekig tart 1-1 lekérés.
Az adatokat egyébként egyszerre 6 táblából nyertem, nem feltétlenül bonyolult lekéréssel. A táblák egyébként elég rendezettek, mindennek meg van a maga helye, num. azonosítóval ellátva.
Mivel általában előre megtervezem, hogy minek hol lesz a helye, így az indexeket is előre beállítom, viszont jelen esetben ez elmaradt, mert mindig utólag lett 1-1 oszlop igény szerint hozzáadva.

Szóval most a percekig tartó lekérés max. 1 másodperc alatt lefut. Thanks obama.

Hétköznapi

„A fél életem a telefonomban volt”

Mondja ezt mindenki, aki elhagyja az „új” telefonját. Elég cinkes, mikor minden kapcsolat, videó, valaha készült kép a telefonon van, esetleg az abban elhelyezett sd kártyán és elvész a készülék. Bármikor előfordulhat az is, hogy tönkre megy a készülék. Ez a kevésbé rossz, mert vagy javítható, vagy újat kapunk helyette, de azon nem változtat, hogy oda vannak az adatok. De miért? Mert pár egyszerű lépést lusták megtenni az emberek. Íme néhány tipp, hogyan biztosítsd be magad adatvesztés ellen.

Android

Új verziókban a rendszer az alkalmazás adatokat is képes szinkronizálni, így a rendesen optimalizált játékokban elért eredmény is megmarad új telefonra való áttéréskor.

Device Manager: Távolról lokalizálhatjuk, csörgethetjük, zárolhatjuk és formázhatjuk a telefont. Sokszor jól jön, mikor a lakásban elfelejtem, hová is tettem a telefonom.

Google Photos: Korlátlan mennyiségű képet lehet jó minőségben automatikusan tárolni a Google szerverein. Ha van tableted, akkor azon automatikusan megjelennek a telefonnal készült képek, és fordítva. Számítógépről is tölthetünk fel képet illetve arra is szinkronizálhatjuk a teljes képtárat. Ugyan ez érvényes a videókra is. Ha 16MP-nél nagyobb felbontású képet készítesz, akkor azt 16MP-re méretezi át, kivéve ha eredeti méretben szeretnéd feltölteni a tartalmat. Ebben az esetben ingyenesen 7GB tárterület áll rendelkezésedre, amit bármikor bővíthetsz.

Play Music: 50 ezer zeneszámot tárolhatunk ingyenesen, amiket bárhonnan el lehet érni. A zenéket offline listára téve internetkapcsolat nélkül is el lehet érni mobileszközön. Új zenék hozzáadásakor azok automatikusan letöltődnek a telefonra, tabletre, így ezzel sem kell bajlódni.

Ezek az alkalmazások alapból elérhetőek bármelyik Nexus vagy Play Edition készüléken és Google fiók hozzáadása után egyből használhatóak is. Egyéb készülékekre ingyenesen letölthetőek a Play Áruházból.

3rd-party

FolderSync: Ugyan azt tudja, mint a Google Photos, viszont nem csak képekhez jó, hanem bármihez. Konkrét mappákat lehet vele szinkronizálni FTP-re, Dropbox-ra, Drive-ra és még egy rakás helyre, így a Minecraft mapok is biztonságban lehetnek.

Spotify: Nem kell zenei fájlokkal bajlódni, ez egy online streaming szolgáltatás. Amennyiben nincs offline listád, csak internetkapcsolattal tudod használni. Előnye, hogy minden lista szinkronizálódik és bárhonnan elérhető. Havidíja 4.99 euró.

Update: Ugyan a Spotify még ma is működik, nem tudom ajánlani. Sok szempontból változott 2015-6 óta, ami miatt már nem szimpatikus számomra.
Jó alternatíva lehet az azóta megjelent YT Music a kínálata miatt (is) vagy a Tidal (minősége miatt). Ezeken kívül Apple Music-kal van hosszabb használat után tapasztalatom. Egy szolid köztes választás lehet a korábbi kettő között, viszont ennek a használata elég körülményes tud lenni, emiatt én inkább YT Music-ot használok, amit a YT Premium mellé adnak felár nélkül.