ajtech

[ajtech]

A Nextcloud biztonsági beállításai

A Nextcloud alapvetően sok biztonsági beállítással alapból rendelkezik. A telepítési leírás során bemutattuk, hogy a Beállítások - Áttekintés (Adminisztráció alatt) menüben a webes felületen ellenőrizni tudjuk, hogy minden szükséges biztonsági beállításról gondoskodtunk-e. A Nextcloud segít nekünk, és ha valamit elfelejtettünk, akkor ebben a menüben közli velünk. 

A telepítés végére minden átfésülésen átment a rendszer, de a teljes védelem biztos meglétéért ebben a posztban felsorolom, hogy milyen lehetőségeink vannak. A telepítés során gondoskodtunk a nagy részéről, de néhány kimaradt, ezeket fogom kifejteni.

A már végrehajtott biztonsági lépések (csak felsorolás, részletek a telepítési útmutatóban):

1. Használjunk HTTPS protokollt:

SSL titkosítást csináltunk a domain-ünkhöz Letsencrypt segítségével.

Átirányítottunk minden HTTP forgalmat HTTPS-re, ami a certbot segítségével készített SSL tanusítvánnyal együtt történt.

Gondoskodtunk a HSTS meglétéről (HTTP Strict Transport Security) a Header max-age beállításával.

2. Használjunk dedikált domain nevet a Nextcloudhoz

A dedikált domain név segítségével sok előnyhöz jutunk, de biztonsági szempontból az ún. same-origin policy-t (azonos eredetű házirend) tudjuk kihasználni. Röviden ez annyit tesz, hogy csak az azonos eredetű dokumentumokat engedi hozzáférni, tehát ha egy dokumentumot egy adott címről nyitunk meg, és az aztán szeretne egy más címen elérhető dokumentumot megnyitni, akkor ezt a tevékenységet nem engedi meg, csak ha ugyanaz az eredeti címe. Ezzel gyakorlatilag annak a lehetőségét limitáljuk, hogy valamilyen vírussal fertőzött dokumentum hozzáférjen másik címről a mi dokumentumainkhoz, ezzel limitálva a vektor támadások lehetőségét. Válasszunk valamilyen cloud.domain.hu címet.

3. Utasítsuk a Webszervert, hogy a Nextcloud .htaccess fájlját használja

Az Apache2 konfigurálásakor tettünk ennek eleget a nextcloud.conf és az apache2.conf fájlok szerkesztésekor. 

Ezek után az admin felületen a Nextcloud már biztonságosnak érzi saját magát. Azonban még van egy-két lépés, amit érdemes megtenni.

A biztonság fokozása:

1. Mozgassuk át a data adatmappánkat a web gyökérből

Esetünkben a gyökér könyvtár a /var/www/html. Ide helyeztük a data mappát. Bár telepítés után közvetlenül a legegyszerűbb az áthelyezés, ez nem kötelező, és aztán bármikor megtehető. Mivel a külső meghajtók használatánál azt javasoltuk, hogy külön csatoljuk őket a Külső tároló (External storage) Nextcloud kiegészítő segítségével, így ha az eredeti helyén is marad a data mappa, a nagyobb fájljaink nem ezen az úton vannak tárolva. Aki viszont sok fontos adatot tart a data mappában, annak mindenképpen érdemes a web gyökérből átmozgatni. Ennek a módja a következő:

Ha nem közvetlenül a telepítés után helyezzük át a mappát, hanem már vannak felhasználóink akik dolgozhatnak dokumentumok, akkor elsőként érdemes karbantartási módba kapcsolni a Nextcloudot:

cd /var/www/html/nextcloud/

sudo -u www-data php occ maintenance:mode --on

Csináljunk egy új mappát ahová átmozgatni szeretnénk a data mappát. Ezt csak rajtunk múlik, tehetjük egy már csatlakoztatott külső meghajtóra (ha nem egy szép nagy SSD-n fut a rendszer akkor ezt mindenképpen ajánlom), de persze az SD kártyán vagy SSD-n futó rendszeren is tudunk helyet találni.

sudo mkdir -p /kívánt/mappa/nextcloud

A -p = parent (szülő) opció létrehozza az összes szülő mappát is amennyiben azok még nem léteznek.

Például külső meghajtó esetén:

sudo mkdir -p /mnt/hdd/nextcloud

Amennyiben a külső meghajtót a /mnt mappa alá hdd néven csatoltuk fel az fstab fájl segítségével. Ennek a módjáról külön posztban ITT (hamarosan...) olvashattok. Fontos, hogy a megfelelő jogokkal és felhasználóval (www-data) csatoljuk fel a külső merevlemezt. 

Példa2 ha maradnánk az SD vagy SSD valamelyik mappájában:

sudo mkdir -p /var/nextcloud

A továbbiakban ez utóbbit feltételezem, de természetesen a sajátunkra ki tudjuk cserélni a soron következő utasításokban.

Mozgassuk át a data mappát az mv = move utasítással:

sudo mv -v /var/www/html/nextcloud/data /var/nextcloud/data

A -v opció a verbose opció, ami kiírja a terminálban a végrehajtott lépéseket.

A Nextcloud persze továbbra is az eredeti helyén keresi a mappát, így ha most belépnénk, akkor hibaüzenet fogadna minket. Mondjuk meg a Nextcloudnak, hogy hol keresse az új helyén a data mappát:

sudo nano /var/www/html/nextcloud/config/config.php

A megnyílt fájlban keressük meg a datadirectory sort (adatmappa), és írjuk át az elérési utat az új mappához:

'datadirectory' => '/var/nextcloud/data',

Mentsünk és lépjünk ki CTRL+X - Y - Enter.

Még egy utolsó ellenőrzést végezzünk el. Nézzük meg, hogy továbbra is a www-data felhasználó kezeli-e a data mappát:

ls -la /var/nextcloud

Ha a korábbi 770-s (drwxrwx---) jogokat látjuk és a www-data felhasználó és csoport a tulaj, akkor minden rendben. Ha esetleg nem ez a helyzet, akkor állítsuk be a megfelelő jogokat (külső meghajtónál az fstab fájlban tudjuk ezt megtenni!):

sudo chown -R www-data:www-data /var/nextcloud/data

sudo chmod 770 /var/nextcloud/data

Lépjünk ki a karbantartási módból:

cd /var/www/html/nextcloud/

sudo -u www-data php occ maintenance:mode --off

Frissítsünk a webfelületen, és ha mindent jól csináltunk, akkor ismét a korábbi felület és a tárolt fájljaink fogadnak minket.

2. A tűzfal és a fail2ban beállítása

Mivel a távoli elérés miatt a router beállításokban megnyitottuk a szükséges portokat (80,443) így potenciális támadási felületet hoztunk létre. Egy korábbi posztban (itt linkelj pls) az UFW tűzfalat és a Fail2Ban segédszoftvert már bemutattam, így ezek részleteiről itt most nem számolok be, azonban a szükséges beállításokról igen.

A.) UFW:

Bár a fent hivatkozott posztban is volt szó róla, azonban itt is fontos megemlíteni, hogy a Nextcloud eléréséhez a http és https portokat a routerünk mellett az aktív UFW tűzfalon is meg kell nyitni:

sudo ufw allow 80

sudo ufw allow 443

B.) Fail2Ban

Az eredeti posztban az SSH szerverünk védelmét állítottuk be, amihez egy előre definiált szűrő konfigurációt használtunk (ez kezeli, hogy mit szűrünk), majd beállítottuk a jail szabályokat (ez kezeli a sikertelen belépési kísérleteket a szűrő feltételekkel együtt). Ugyanezt kell végrehajtani a Nextcloud-al is. Az elv ugyanaz lesz, csak a Nextcloud-hoz nincs elérhető szűrő fájl a Fail2Ban telepítésével együtt. Így most ez létrehozzuk és szerkesztjük a nano szövegszerkesztő segítségével:

sudo nano /etc/fail2ban/filter.d/nextcloud.conf

Másoljuk be a Nextcloud kézikönyvében ajánlott tartalmat:

[Definition] _groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*) failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:            ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error. datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"

Mentsünk és lépjünk ki CTRL+X - Y - Enter.

A jail szabályunkat több móson is létrehozhatjuk. A Nextcloud ajánlata a jail.d mappán belül létrehozott nextcloud.local fájlon belül megadni a szabályainkat. Természetesen használhatjuk a telepítéskor létrehozott jail.local fájlt is. Én a már meglévő jail.local mellett tettem le a voksom:

sudo nano /etc/fail2ban/jail.local

Keressük meg a “HTTP servers” szekciót a CTRL+W segítségével. Ide rögtön az elejére helyezzük el a nextcloud konfigurációt:

[nextcloud] backend = auto enabled = true port = 80,443 protocol = tcp filter = nextcloud maxretry = 3 bantime = 86400 findtime = 43200 logpath = /path/to/data/directory/nextcloud.log

Ahogy láthatjuk, a 80 és 443-as portokon bekapcsoltuk a nextcloud szűrővel kiszűrt IP címeken végrehajtandó akciókat. A maxretry értékével adjuk meg, hogy 3-szor próbálkozhatnak sikertelenül belépni egy findtime peióduson belül. Ha ezt túllépi, akkor a bantime idejére azt az IP címet kitiltja a tűzfalunk. Mind a findtime, mind a bantime másodpercekben értendő. A logpath pedig a nextcloud.log fájlunk elérési útja, ezt a log fájlt vizsgálja a fail2ban gyanús belépési kísérleteket keresve. Adjuk meg a helyes elérési utat. A korábban átmozgatott data mappán belül van ez a log fájl. Ennek megfelelően írjuk át az elérési utat. Ha az eredeti helyén van, akkor például /var/www/html/nextcloud/data/nextcloud.log kerül abba a sorba.

Indítsuk újra a fail2ban szolgáltatást, hogy az új szabályok érvénybe lépjenek:

sudo systemctl restart fail2ban

Ellenőrizzük, hogy valóban aktív-e az új jail:

sudo fail2ban-client status

Ha elég bátrak vagyunk, akkor megpróbálhatjuk, hogy jól működik-e amit bepötyögtünk. Nyissuk meg a Nextcloud webes felületét, majd jelentkezzünk be helytelen jelszóval. Elég egyszer, és ha a terminálban lekérjük a nextcloud jail státuszát máris látni fogjuk:

sudo fail2ban-client status nextcloud

Amennyiben a fenti lépéseket végrehajtottuk, úgy biztonságban érezhetjük az adatainkat. Noha nem szorosan ide kötődik, de ezek után a következő teendőnk a Nextcloud-al majd a biztonsági mentések lesznek. Ezzel nem a támadások és jogtalan hozzáférések ellen védjük a rendszert, hanem az esetleges hardveres hibától, vagy a saját hülyeségünktől. Hamarosan a backup készítés egy egyszerű módjára is kitérünk az oldalon.

VISZLÁT!

[ajtech]

Biztonsági intézkedések - UFW és Fail2Ban

A biztonság és adatvédelem nagyon fontos aspektusa minden rendszernek. Nem lenne túl rózsás egy zsaroló vírus miatt a teljes rendszerünket törölni minden nekünk kedves fájllal együtt, nem beszélve arról, hogy ezek a vírusok előszeretettel terjednek a hálózatunkon keresztül minden arra csatlakozó eszközre. 

Két szoftvert fogunk telepíteni, hogy a mini PC-nket a lehető legnagyobb biztonsági pajzzsal vértezzük fel. 

UFW Tűzfal

Az első a tűzfal amiről gondoskodnunk kell. Az UFW (uncomplicated firewall) tűzfalat telepítjük. Ez lesz az első védelmi vonalunk a port alapú támadások ellen. 

Mint mindig, most is frissítsük a rendszert. Egyébként ennek az időszakos végrehajtása nagyon javasolt, hiszen folyamatosan jönnek ki új frissítések, amelyek a biztonsági réseket igyekeznek betömködni. Ha nem tartjuk az oprendszert frissen, akkor sok ilyen biztonsági rést hagyunk szabadon.

sudo apt update && sudo apt full-upgrade -y

Ha már frissítések, korábban a sima upgrade utasítást használtuk, itt most pedig a full-upgrade-et. A különbség a kettő között, hogy a full-upgrade a csomagjaink frissítése mellett a függőségi (dependency) változásokat is leköveti.

A frissítést követően telepítsük az UFW tűzfalat:

sudo apt install ufw

A telepítés után a tűzfal még nem aktív automatikusan. Ennek kifejezetten örülhetnek azok, akik csak SSH-n érik el a Raspberry-t. Mivel a kommunikáció alapból a 22-es porton történik az SSH-n keresztüli csatlakozáskor, ha most egyből bekapcsolnánk a tűzfalat, akkor bukta az SSH csatlakozásunknak.

Így mielőtt bekapcsolnánk, nézzük meg, hogyan kell portot nyitni a tűzfalon, majd nyissuk is meg a 22-es portot ezzel a módszerrel:

sudo ufw allow PORT

azaz a 22-es port megnyitása:

sudo ufw allow 22

Ha esetleg hibára futna a portnyitás az “Error: Couldn’t determine iptables version” hibaüzenettel, akkor indítsuk újra a rendszert:

sudo reboot

Majd próbáljuk újra a port nyitást. Ha nem tudjuk egy applikáció által használt port számát, pl az SSH-ét, akkor a következő módon is megnyithatjuk a portot:

sudo ufw allow ssh

Miután minden olyan portot megnyitottunk, amire szükségünk van (de SSH miatt minimum a 22-eset nyissuk meg), bekapcsolhatjuk a tűzfalat. De még előtt egy utolsó ellenőrzésként nézzük meg milyen szabályaink vannak jelenleg a következő utasítással:

sudo ufw show added

Én a webszerverem által használt 80-as http és 443-as https portokat is megnyitottam a tűzfalon. Ha rendben van, és azokat a szabályokat látjuk, amit szerettünk volna, akkor kapcsoljuk be a tűzfalat a következő módon:

sudo ufw enable

A sor futtatása után kérdésként a következő üzenetet kapjuk (lásd lentebb a képen is):

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Ez az üzenet figyelmeztet minket, hogy az utasításunk megszakíthatja a futó SSH kapcsolatokat. Amennyiben a megfelelő portot megnyitottuk, akkor nyugodtan válaszoljunk Y - igennel és nyomjuk le az Enter-t. A bekapcsolás tényéről megerősítő üzenetet kapunk:

Firewall is active and enabled on system startup

Ez az üzenet azt is közli velünk, hogy a tűzfal aktív és a rendszer indításakor is engedélyezve van. Ha mindent jól csináltunk és SSH-n csatlakozunk, akkor a nyitott 22-es port miatt a kapcsolat nem szakad meg. A tűzfal állapotát tudjuk ellenőrizni a következő utasítással:

sudo ufw status

Megmutatja, hogy aktív-e a tűzfal, és ha aktív, akkor azt, hogy milyen szabályokat adtunk eddig hozzá.

A nyitott port persze mindig rés a pajzson. Az UFW lehetőséget biztosít egy kis extra biztonsági beállításra, amivel behatárolhatjuk, hogy hány csatlakozási kísérletet engedjen a tűzfal mielőtt kidobja a csatlakozni kívánót. Használjuk ezt a limit funkciót a 22-es porton:

sudo ufw limit 22

Ez a funkció letiltja a csatlakozást arról az IP címről, amelyikről az elmúlt 30 másodpercben hat vagy több alkalommal próbáltak meg csatlakozni. Ezzel ki tudjuk szűrni, ha egy külső támadás un. “brute force” módszerrel próbál bejutni a gépünkre (a brute force módszer, amikor minden lehetséges bejutási módot - jelszót - végigpróbál a támadó amíg meg nem találja a helyeset).

Hasznos utasításokból még néhány:

 sudo ufw deny PORT

Ahogyan engedélyezni, úgy letiltani is tudunk kommunikációt bizonyos portokon. Az allow engedélyezés párja a deny tiltás.

sudo ufw delete SZABÁLY

Példa:

sudo ufw delete allow 443

A delete utasítás után a korábban megadott egyik szabályunkat tudjuk törölni. A példában a 443-as port engedélyezve volt, ezt az engedélyező szabályt töröltem (majd persze vissza is állítottam, mivel szükség van rá).

Ha valamilyen alkalmazásunkat, szerverünket vagy weboldalunkat nem érjük el, akkor érdemes felkutatni a vonatkozó portok számát, majd azokat engedélyezni a tűzfalon. Nekem a folyamat végére 14 portot kellett megnyitnom (javarészt a HomeBridge plugin-ek miatt). Az oldalunkon található leírásokban megtaláljátok az oda vonatkozó portok számát, de a közel jövőben lesz ezekhez külön tűzfal beállítási leírás.

A Fail2Ban telepítése

Ha a Raspberry-t valamilyen szerverként használjuk, márpedig pontosan erre használjuk, akkor ennek megfelelően több port-ot is szánt szándékkal nyitunk meg. Ezek a portok mind támadási felületek. A limit funkció mellett érdemes a Fail2ban pythonban írt programot is telepíteni, valamint az egyes szerverekhez (pl. SSH, Apache2) konfigurálni a működését. A Fail2ban egy aktív védelem, ami folyamatosan átfésüli a log fájljainkat annak érdekében, hogy a gyanús tevékenységeket kiszűrje. Ha talált ilyet, akkor pedig kapcsolatba tud lépni bármilyen telepített tűzfallal, hogy az tiltsa le azt a tevékenységet (pl. többszörös sikertelen csatlakozási kísérlet). Ez nagyon fontos és biztonságosabbá teszi az internet felől elérhető Raspberry-t.

A Fail2ban telepítése a következőképpen történik:

sudo apt install fail2ban 

A telepítés során létrejött egy új mappa a /etc/fail2ban, és azon belül is a jail.conf (jail = börtön) fájl. Ezen belül tudjuk megadni a szabályainkat. De a fájl csak akkor lesz aktív, ha a tartalmát a jail.local fájlba bemásoljuk. Ez a fájl alapból nem létezik, a másolási utasítással együtt létrehozzuk, majd a nano szövegszerkesztővel megnyitjuk:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

A megnyílt fájl egy figyelmeztető szöveggel kezdődik, hogy ezt a fájlt ne módosítsuk, mert frissítésekkel a módosításaink elvesznek. Ez persze az eredeti jail.conf fájlra vonatkozik, éppen ezért kellett csinálni egy másolatot belőle. Én a tisztább átláthatóság kedvéért a kommenteket mindenhonnan kitöröltem, ha bármire szükség lenne, az eredeti jail.conf fájlban majd megtalálom. 

Az első szekció a [DEFAULT] ami az alapbeállításokat tartalmazza. Minden további szegmensben ezeket a beállításokat fogja használni a Fail2ban amennyiben azt nem definiáljuk máshogyan. Például ha egy IP fennakad a szűrőn akkor milyen módon legyen tiltva, azt a

banaction = iptables-multiport 

beállítás adja meg, ami alapból minden porton tiltja az adott IP-t. Ha ez persze nem megfelelő nekünk, akkor a /etc/fail2ban/action.d/ mappában található konfigurációkból tudunk válogatni. A minden porton tiltás nekem szimpatikus megoldás. 

Az alapbeállítások a kommentek nélkül valahogy így néznek ki:

[DEFAULT]

ignorecommand =

bantime  = 10m

findtime  = 10m

maxretry = 5

backend = auto

usedns = warn

logencoding = auto

enabled = false

mode = normal

filter = %(__name__)s[mode=%(mode)s]

destemail = root@localhost

sender = root@<fq-hostname>

mta = sendmail

protocol = tcp

chain = <known/chain>

port = 0:65535

fail2ban_agent = Fail2Ban/%(fail2ban_version)s

banaction = iptables-multiport

banaction_allports = iptables-allports

Miután átfutottuk az alapbeállításokat, rakjuk össze az SSH szerverünk szabályait.

A CTRL+W -vel keressünk rá az “sshd” szóra, amivel a törölt kommentek nélkül valami ilyesmit találunk:

[sshd]

port    = ssh

logpath = %(sshd_log)s

backend = %(sshd_backend)s

Ezt a szekciót módosítsuk a következő sorok hozzáadásával a meglévőek elé:

enabled = true

filter = sshd

Majd pedig a végére:

bantime = -1

Ezek után a szekció valahogy így fog kinézni:

[sshd]

enabled = true

filter  = sshd

port    = ssh

logpath = %(sshd_log)s

backend = %(sshd_backend)s

bantime = -1

Az első hozzáadott enabled sorral aktiváljuk az egész blokkot. 

A második sor a filter azaz szűrő, ami szintén egy előre összeállított (bonyolult) konfiguráció. Sok megszokott szerver számára van ilyen fájl előre definiálva a /etc/fail2ban/filter.d/ mappában. Érdemes belenézni, hogy milyen fájlok elérhetőek. A filter opciónál a fájl nevét kell megadni a .conf kiterjesztés nélkül. Ezért írtuk be az sshd.conf szűrő fájl használatához, hogy filter = sshd. 

A bantime utolsó sor azt adja meg, hogy mennyi időre tiltjuk a kiszűrt IP-t. A negatív érték az örökös kitiltást jelenti.

A maxretry értéket szokás megváltoztatni még ebben a szekcióban, de én hagytam ezt az alap 5 értéken. Ez azt mondja meg, hogy hány sikertelen próbálkozás után érvényesüljön a bantime-ban megadott kitiltás. Egyébként a bantime-nak pozitáv értéket másodpercekben tudunk megadni. A megadott pl. 3600 másodperc így azt jelenti, hogy a kitiltás 1 órán keresztül érvényes.

Ha elégedettek vagyunk a beállításokkal, akkor mentsünk és lépjünk ki a CTRL+X - Y - Enter billentyűkkel. Majd indítsuk újra a Fail2ban szolgáltatást:

sudo systemctl restart fail2ban

Az aktív “jail” szabályokat le tudjuk bármikor kérdezni:

sudo fail2ban-client status

Egy adott “jail” státuszát szinte ugyanígy, csak a nevét hozzáadva kérhetjük le:

sudo fail2ban-client status sshd

A fenti két sor után ezeket az információkat tudjuk meg:

Ahogy látható nálam még csak az sshd jail aktív, ami pedig ez elmúlt néhány percben még nem szűrt ki illetéktelen behatolót, de amint megteszi, itt nyomon tudom követni a kitiltott IP-ket is.

A mostani posztban csak az SSH-val kapcsolatban vizsgáltuk meg a konfigurációt. A többi szerver telepítésünk, mint például a Nextcloud az Apache2 webszerverrel, külön posztban kerül bemutatásra.

[ajtech]

A Cron lelki világa

A telepítési leírásokban sokszor említettem a Cron feladatokat. Ebben a posztban végre kifejtem, hogy mire való, és hogyan lehet több féle módon használni.

A Cron egy olyan eszköz a Unix alapú rendszereken ami segítségével különböző futtatható feladatokat tudunk ütemezni, hogy milyen gyakran hajtsa végre a rendszer őket. Például egy szkript futtatása periodikusan, log vezetése automatikusan, és számtalan más ütemezhető feladat végrehajtható ennek segítségével. A rendszer minden felhasználójának van saját fájlja, ami tartalmazza az általa futtatni kívánt feladatok listáját. Ezeket hívjuk crontab-nak. A crontab = cron table, azaz cron tábla.  

A crontab megnyitása a következő sorral lehetséges (-e opció az edit, mint szerkesztés):

crontab -e

A root (gyökér) felhasználóét más felhasználóval bejelentkezve (pl. pi) a sudo használatával a következőképpen tudjuk megnyitni:

sudo crontab -e

Ha a bejelentkezett felhasználóval másik felhasználó crontab-ját akarjuk megnyitni, és van superuser jogunk (mint a pi-nek), akkor a -u opció megadásával és a felhasználó nevével így tudjuk megnyitni:

sudo crontab -u www-data -e

Az első alkalommal megkérdezi a rendszer, hogy melyik szövegszerkesztővel kívánjuk megnyitni a fájlt. Válasszuk ki a kedvenc applikációnkat, és nyomjuk meg az Entert. Én a nano szövegszerkesztőt használom és javaslom is.

A megnyílt fájlok mind rövid leírással kezdődnek. Lépjünk egy üres sorhoz, és írjuk be az elvégzendő feladatot. A sorok szerkezete a következő hat opcióból áll össze:

m h dom mon dow  futtatható_utasítás ┬ ┬ ┬ ┬ ┬ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └── a hét egy napja (0 - 7) (0-tól 6-ig a Vasárnaptól Szombatig, vagy az angol név is használható; a 7 pedig szintén Vasárnap, mint a 0) │ │ │ └────── hónap (1 - 12) │ │ └────────── a hónap egy napja (1 - 31) │ └───────────── óra (0 - 23) └─────────────── perc (0 - 59)

Tehát gyakorlatilag meg tudjuk adni, hogy mikor futtassa, és mi az az utasítás amit futtasson. A csillag (*) karakterrel tudjuk azt megadni, hogy az adott opcióból mindegyiken érvényesüljön, a számokkal pedig pontosan tudjuk definiálni. 

Konkrét példa:

* * * * * /home/pi/valamiszkript.sh

Ez a sor minden percben, minden órában, minden napján egy hónapnak, minden hónapban és a hét mindegyik napján, összefoglalva percenként lefuttatja a “valamiszkript.sh” kódunkat.

A * karakterek helyett a fentebb megadott értékeket is beírhatjuk, például:

5 0 * * * /home/pi/valamiszkript.sh

A kódunk 5 perccel éjfél után fog lefutni minden nap. 

Az értékek mellett használhatunk intervallumokat is a “-” segítségével, például:

0 9-14 * * * /home/pi/valamiszkript.sh

Ekkor a kód futtatása minden nap reggel 9 és délután 14 óra között óránként egyszer fut le.

Az intervallum helyett felsorolással is megadhatjuk vesszővel (,) elválasztva így:

0 8,12,16 * * * /home/pi/valamiszkript.sh

Ez a kód minden nap reggel 8-kor, délben és délután 4-kor hajtódik végre.

A hét napjait, valamint a hónapokat számok helyett az angol nevükkel, vagy azok három betűs rövidítésével is megadhatjuk. Mint például Monday vagy Mon; February vagy Feb. 

15 * * Nov Monday,Wednesday,Friday /home/pi/valamiszkript.sh

Ebben a formában a kódunk minden év novemberében, hétfő, szerda és pénteki napokon, minden óra 15. percében fog lefutni.

Az utolsó mód amit sokszor használunk, az a lépésenkénti érték megadás. Ezt a per jellel (/) tudjuk megadni, mint például ha 5 percenként szeretnénk végre hajtani, akkor */5 kerül a perc opció helyére, ilyen módon:

*/5 * * * * /home/pi/valamiszkript.sh

Ha kitaláltunk egy intervallumot vagy időpontot a feladat végrehajtásához, de nem vagyunk biztosak benne, hogy jól adtuk meg ez a crontab-ban, akkor javaslom, hogy a https://crontab.guru/ honlapon pötyögjük be, és ellenőrizzük. Ez egy nagyon hasznos weblap, leírja szépen szavakkal, hogy mit írtunk be valójában.

Miután most szépen megtanultuk, hogy hogyan használjuk az opciókat, mutatok egy egyszerűsítést. Noha sok cifra időpontot ilyen módon nem tudunk megadni, de egyszerű óránkénti, vagy újraindításkor történő végrehajtásra a kukac (@) karaktert is használhatjuk a következőképpen:

@hourly home/pi/valamiszkript.sh

Így a szkript óránként fut le, ami megegyezik a 0 * * * * opcióval. A további lehetőségek:

@hourly - óránként

@daily vagy @midnight - naponta éjfélkor

@weekly - hetente egyszer, vasárnap éjfélkor

@monthly - havonta egyszer a hónap első napján, éjfélkor

@yearly - évente egyszer Január elsején éjfélkor

@reboot - újraindításkor (nagyon hasznos, ha olyan felhasználó akar újraindításkor valamilyen programot indítani, aki a rendszer inicializáláshoz nem tud hozzányúlni, így ott nem tudja automatikusra állítani a program indítását)

További crontab példákat láthattok a telepítési leírásokban az oldalon, de még egy bonyolultabbat megmutatok, hogy ne csak nagyon egyszerűekkel példálózzak. A Letsencrypt SSL tanusítványa 90 napig érvényes, de csak 30 nappal a lejárat előtti időszakon belül lehet megújítani. Erre mi magunk is írhatnánk cron feladatot, de certbot ezt megteszi helyettünk. Erről a Nextcloud telepítési leírásában is szót ejtettem. Ez a fájl így néz ki:

Az eddig leírtak alapján ki tudjuk számolni, hogy 12 óránként fut le, napi kétszer. Délben és éjfélkor. Az utasítás ami lefut, rengeteg opcióval rendelkezik. Lényegében megnézi, hogy a megújítási periódusban vagyunk-e már, és ha igen, akkor megújítja, mindezt a -q opcióval, ami a quit = csendes opció. Lényegében bármi észrevehető jelzés nélkül, szépen csendben. 

Ha csak meg szeretnénk nézni, hogy éppen milyen soraink vannak a cron táblában, akkor a -l mint list opcióval tudjuk ekképp:

crontab -l

Ellenőrzésképpen azt is meg tudjuk nézni, hogy az utóbbi időben milyen feladatokat és mikor hajtott végre a cron a háttérben:

grep CRON /var/log/syslog

Valami ilyesmit láthatunk:

A cron nagyon hasznos eszköz, sok teendőnket tudjuk vele automatikusan végrehajtani. Nagyon jól használható biztonsági mentések időszakos futtatására is, de ahogy láttuk csak a szükség és a fantáziánk szab határt annak, hogy miként használjuk.

VISZLÁT

[ajtech]

PLEX Média Szerver

A korábbiakban telepítettük a NextCloud privát felhő szolgáltatást, amivel bárhonnan meg tudjuk tekinteni, megosztani, frissíteni, eszközeinkkel szinkronizálni a fájljainkat. Telepítettük a Transmission torrent szervert és hozzá a Flexget kiegészítőt, hogy a felhőnkbe könnyen tudjunk letölteni tartalmakat manuális műveletek nélkül, kényelmesen, és szép rendezetten.

Már csak az maradt hátra, hogy kellemes formában érjük el, és jelenítsük meg a média (film, sorozat, képek, videók) tartalmainkat a tévénken, tabletünkön, vagy bármilyen eszközünkön aminek kijelzője van. Erre pedig én a PLEX média szervert használom.

A Plex számos előnnyel bír, mivel több felhasználó és több eszközön tudja használni, például a Kodi-val összehasonlítva, ami csak egy kliensként működik. A Plex minden alapfunkcióját ingyenesen elérjük, de tudnunk kell, hogy van előfizetési lehetőség ami további funkciókat tesz elérhetővé (pl. TV szolgáltatás, offline tartalom letöltés, mobil stream).

TELEPÍTÉS

Mivel a Plex repository (gyüjtemény, tárhely) https protokollt használ, így a telepítést az apt segítségével csak egy kiegészítő csomag telepítése után tudjuk elkezdeni:

sudo apt install apt-transport-https

Ez a csomag teszi lehetővé, hogy az apt https protokollon tudjon csomagokhoz hozzáférni. Ezt követően a Plex tárhely kulcsát adjuk hozzá az apt menedzser kulcs listájához. Azért van erre szükség, hogy a letöltendő fájlok biztosan ez által a kulcs által aláírt tárhelyről érkeznek.

curl https://downloads.plex.tv/plex-keys/PlexSign.key | sudo apt-key add -

Az utolsó előkészületi lépés a Plex tárhely hozzáadása az apt forrás listájához (sources.list.d mappa), majd frissítsünk:

echo deb https://downloads.plex.tv/repo/deb public main | sudo tee /etc/apt/sources.list.d/plexmediaserver.list

sudo apt update

Most következhet a Plex Média Szerver telepítése:

sudo apt install plexmediaserver

Ezek után gondoskodjunk arról, hogy a szerver felhasználója a plex hozzáférjen minden olyan mappához, amelyeknek a tartalmát hozzá akarjuk adni a könyvtáraihoz. Az én esetemben a tartalmakat olyan mappákban tárolom, amelyeknek a tulajdonosa a Nextcloud miatt az Apache2 webszerver www-data csoportja. Hozzáadom tehát ehhez a csoporthoz a plex felhasználót. (Itt is felhívom a figyelmet arra, hogy a Nextcloud data mappa létrehozásakor ezért adtunk 7-es teljes jogot a www-data csoportnak is, hogy később más felhasználókat kényelmesen hozzá tudjuk adni. Most ez abban segít nekünk, hogy a mappa tartalmát a Plex segítségével tudjuk kezelni.)

sudo usermod -aG www-data plex

Mint mindig, most is ismételt bejelentkezés után érvényesül csak ez a változtatás (pl egy reboot).

A webes felületen történő bélést megelőzően érdemes regisztrálni a https://plex.tv weboldalon. Ha megtörtént a felhasználó létrehozása, akkor a következő módon tudjuk elérni a Plex webes felületét:

RaspberryIP:32400

(A Raspberry IP címét a hostname -I utasítással tudjuk lekérni a terminálban)

A weboldalon a következő képernyő vár minket:

Jelentkezzünk be a korábban létrehozott felhasználóval, vagy hozzuk most létre és jelentkezzünk be.

Az első belépésnél azonnal van lehetőségünk kiválasztani egy média típust, és megadni hozzá a könyvtárat:

Részletesen a lépéseket most nem követjük a posztban, mivel szépen végig lehet nyomkodni, magától értetődő a teendőnk. A mappa megadása után a tartalmat egy szép, könnyedén böngészhető nézetben elrendezi nekünk a Plex. A meta adatok letöltésével pedig a tartalmak hasznos információit is megjeleníti nekünk, mint pl. egy film posztere és szereplői.

Egy hasznos beállítást szeretnék még megmutatni nektek ami alapbeállításként nincs bekapcsolva. A jobb felső sarokban található beállítások ikonra katintsunk (csavarhúzó és csavarkulcs ikon):

A bal oldali sáv Beállítások szekciójában kattintsunk a Könyvtár menüpontra:

A legfelső “Automatikusan beolvasni a könyvtárakat” opciót pipáljuk be, így nem kell minden alkalommal a könyvtárunkba bekerült új tartalmak miatt kézzel frissítgetnünk a Plex-ben. Ahogy a leírás is mutatja, ha bármilyen változás történik a mappában, akkor a Plex automatikusan frissíti az új adatokat.

További beállításokkal kapcsolatban érdemes végig nézni a menüpontokat, illetve felkeresni a Plex hivatalos leírásait tartalmazó oldalt: Plex Support

A Flexget telepítés végén azt mondtam, hogy dőljünk hátra. Most azt mondom, hogy ragadjuk meg a távirányítót, és élvezzük a kedvenc műsorainkat a TV-nkre letöltött Plex klienssel. 

VISZLÁT! 

[ajtech]

Flexget

A Transmission telepítése után egy ideig minden ment ahogy akkor gondoltam. A torrent fájlokat letöltöttem a figyelő mappába (watch dir) és szépen működött minden. Beleütköztem azonban abba a problémába, hogy a különböző típusú fájlokat mindet egy helyre töltötte le, amiket aztán kézzel kellett átpakolni a dedikált mappákba (Filmek, Sorozatok stb.). Sőt az az igény is felmerült, hogy még egyszerűbb lenne, ha RSS feed-ből töltené be automatikusan a torrent fájlokat. 

Ekkor találtam rá a Flexget-re. Ami egészen pontosan ezt teszi lehetővé. Sőt, az automatizálás addig vihető szinte vele, hogy tényleg semmihez nem kell nyúlni, teszi a dolgát.

TELEPÍTÉS

A flexget telepítése igen egyszerű, mindösszesen még egy RPC modulra . transmission-rpc - van szükség. Az RPC = Remote Procedure Call - távoli eljáráshívás, nevéből is adódóan ennek segítségével fogja a Flexget a Transmission-t cselekvésre bírni.

A transmission-rpc alkalmazás Python-al segít nekünk elérni a Transmission RPC szolgáltatását. Tehát a telepítést ezúttal nem az APT, hanem a PIP csomagokból hajtjuk végre (PIP = Python Package Index, PyPI). A Flexget által támaszott előfeltételek szerint minimum Python 3.6-os verzió szükséges. 

Ellenőrizzük, hogy van-e telepítve, és mi a verziója a Python-nak a Raspberry-nken (Raspberry OS esetén ha desktop verziót tettünk fel, akkor alapból telepítve van, ha Lite verziót - csak terminálos elérés - akkor alapból nincs):

$     python -V

Ha hiányzik a Python, akkor telepítsük:

$     sudo apt install python3-pip

Ha a verzió rendben van, akkor ezeket kihagyva jöhet a Flexget és transmission-rpc telepítése:

$     sudo pip3 install flexget transmission-rpc

KONFIGURÁLÁS

A Flexget konfigurációs fájlja a változatosság kedvéért egy yaml fájl (yaml is egy olvasható program nyelv, mint a json, a neve is egyébként a Yet Another Markup Langueage - Ismét még egy markup nyelv, mondjuk számomra nem túl baráti ez a szintű “struktúrálatlanság”, érted rakjál legalább két szóközt meg ilyenek...). 

Ez a fájl azonban nem áll rendelkezésre sehol közvetlenül a telepítést követően. Nekünk kell létrehozni. De persze azért az nem mindegy, hogy pontosan hová helyezzük. A Flexget alapból több helyen is keresi, de a hivatalos utasítás szerint a bevált gyakorlat a  ~/.flexget/ mappában elhelyezni a config.yml fájlt. A ~ a Raspberry-n a ‘pi’ felhasználónk /home/pi mappája. Hozzuk hát létre a .flexget mappát:

$     mkdir ~/.flexget

Hozzuk létre és szerkesszük a nano-vel a config.yml fájlt ebben a mappában:

$     sudo nano /home/pi/.flexget/config.yml

A megnyílt fájlba tudjuk tetszőlegesen megírni, hogy mit csináljon a Flexget. Konkrét utastást nem tudok adni arra vonatkozóan, hogy ki mit szeretne megvalósítani, így leginkább most példákat hozok arra, hogy miket lehetséges. Letöltendő fájlok, azok letöltési helye, RSS feed megadása, kategorizálás, menetrend, hogy csak néhányat soroljak.

A Yaml fájlban meg tudunk adni task-okat (feladatok), template-eket (sablonok), schedule-öket (menetrend), hogy a főbbeket említsem. Ezek lesznek a fájlban sor behúzás nélkül, míg alatta a részletek minimum két szóközzel beljebb húzva (tudom, szerintem is borzasztó...), mint például különböző előre definiált plugin-ek (beépülők).

Nézzünk néhány példát, amire én használom.

Először is megadtam sablonokat a transmission plugin-el.

templates:

  films:

    transmission:

      host: localhost

      port: 9091

      username: felhasználónév

      password: jelszó

      path: /letöltési/mappa/elérési/útja

A felhasználó név és a jelszó itt a Transmission telepítésekor a settings.json fájlban megadott “rpc-username” és “rpc-password”. A “path” pedig annak a mappának az elérési útja ahová az adott sablon-al majd letölteni szeretnénk.

A feladatok között pedig ezt a sablont használom a következő képpen:

tasks:

  n_films:

    rss: https://példa.link/rsscíme

    accept_all: yes

    template: films

Ez a feladat a végrehajtásakor megnézi, hogy az RSS link-en található torrenteket hozzáadta-e már a letöltéshez a transmission-ben, és ha talál olyat amit még nem, akkor azt hozzáadja (és megjelöli egy seen (látott) bit-tel a következő futtatáshoz - mindezt már magától persze).

Ebből a sablonból és feladatból nekem több is van, ugyanígy néznek ki, mindössza a path letöltési mappa és az rss cím más például másik torrent oldal vagy más típusú fájlok letöltése miatt (pl sorozatok). Nekem nagyon egyszerű ez az n_films task-om, de rengeteg opció és plugin adható meg ezeken kívül, mint a letöltés minősége, itt is megadhatjuk a letöltés helyét, a torrent nevét (pl sorozatoknál ahol több rész is van) és így tovább. Erre egy minta:

tasks:

  minta_task:

    rss: https://példa.link/rsscíme

    series:

      - Kedvenc Sorozatom

      - Másik kedvenc sorozatom

          quality: 720p

    download: /letöltési/mappa/elérési/útja

A “series” plugin esetében a megadott név alapján az epizódok és évadok számozását a flexget automatikusan felismeri, és azt tölti le ami még nem volt letöltve. Ha több ugyanazzal a névvel ellátott-at talál, akkor az első találatot fogja leszedni, ezért érdemes lehet specifikálni a minőséget is amit elvárunk, pl a “quality” plugin-t erre tudjuk megadni.  

Még egy task-ot bemutatok nektek, amit arra használok, hogy kitakarítsam a transmission-ben éppen hozzáadott torrenteket bizonyos feltételek alapján. Csak azért, hogy ne legyen végtelen lista ott egy idő után. 

tasks:

  cleanup:

    from_transmission

      host: localhost

      port: 9091

      username: felhasználónév

      password: jelszó

    disable: [seen, seen_info_hash]

    if:

      - transmission_progress == 100: accept

      - transmission_ratio < 1.0: reject

      - transmission_date_done > now - timedelta(days=2): reject

     transmission:

       host: localhost

       port: 9091

       username: felhasználónév

       password: jelszó

       action: remove

Ez a feladat a Transmission-ből az “if” (HA) plugin alatt megadott feltételek mindegyikének teljesülése esetén (ÉS kapcsolat) az adott torrentet kitörli. a “disable” plugin abban segt, hogy a Transmission listájában levő összes sorra elvégezze a műveletet, függetlenül attól, hogy más feladatokban mit csinálunk a sorokkal. Az “if” plugin-nél azokat a sorokat fogadjuk el - accept - amelyeket törölni szeretnénk, azokat pedig elutasítjuk - reject - amikert nem. Nálam itt a 100%-ig letöltött, minimum 1.0 aránnyal rendelkező és legalább két napja futó torrenteket törlöm. Ezek tetszés szerint választhatóak. 

TIPP: ha Deluge torrent szervert használsz, ahhoz is van előre definiált plugin a Transmission mintájára.

TIPP2: A feladatok sorrendje nem számít a config.yml fájlon belül.

További feladatok, sablonok, beépülök és azok opciói megtalálhatóak a Flexget oldalán.

Ha kész vagyunk a konfigurációval akkor mentsünk és zárjuk be CTRL+X - Y - Enter. Majd rögtön teszteljük le, hogy szintaktikailag és tartalmilag rendben van-e a konfigurációnk:

$    flexget check

$    flexget --test execute

Ha hiba nélkül megúsztuk, akkor kész a konfiguráció. A config.yml-ban megadott feladatokat a következőképpen tudjuk végrehajtani:

~ $    flexget execute

A legjobb persze ha ezt sem kell nekünk futtatni. Adjunk hozzá egy cron feladatot, amit bizonyos időközönként végrehajt a rendszer. Először ehhez meg kell tudnunk pontosan hol van a Flexget:

~  $   which flexget

Az én esetemben a “/usr/local/bin/flexget” elérési utat kaptam. Így már mehet a a cron job:

~  $   sudo crontab -e

Adjuk hozzá a következő sort a megnyitott fájl végére. A cron job-ok lelki világáról részletesebben ITT (hamarosan...) olvashattok.

@hourly /usr/local/bin/flexget --cron execute

Ez a feladat óránként fut. Természetesen ennél többször és kevesebbszer is futtathatjuk, ahogyan nekünk tetszik. Egy fontos dolgot viszont érdemes észben tartani. Ha RSS csatornát használunk, akkor fél óránál gyakrabban ne fusson a cron sorunk, mert az ennél gyakrabb RSS lekérés miatt bizonyos oldalak letilthatják az IP címünket.

Ha csak bizonyos task-ot szeretnénk lefuttatni, arra is van lehetőségünk:

~  $  flexget execute --tasks task_neve 

Még egy hasznos utasítás és be is fejeztem. Ha egy torrentet egy task már kezelt, akkor azt megjegyzi egy “már látott” (“seen”) jelzéssel megjelölve. Ha valamiért mégis szeretnénk újra kezelni, akkor van mód a Flexget-tel elfelejtettni ezt:

~  $  flexget seen forget task_neve

Ezek után ha újra futtatjuk a feladatot, akkor ismét hozzáadja a korábbi torrenteket. Ha a “forget” opciót “add” opcióra cseréljük, akkor pedig már látottként tudunk bármit megjelölni.

Véfül az én esetemben az történik, hogy az RSS hírfolyamok amiket megadtam kedvencek listát takarnak, ahová elegendő a letölteni kívánt torrenteket hozzáadni, mint kedvenc. A többit intézi a Flexget és a Transmission. Ez elég sok időt és manuális másolgatást váltott ki nálam, pedig minden funkciót fel sem használok amire a Flexget képes.

Szépen lassan épül a házi szerver. Mostmár a szórakozás következik a Plex média szerverrel.

VISZLÁT!

J.

[ajtech]

Transmission torrent szerver

Most hogy kész a saját felhő szerverünk, ideje tartalommal megtölteni. Mi sem kézenfekvőbb, mint egy torrent szerver telepítése. A Raspberry-re sok lehetőség közül választhatunk, mint pl. a Deluge, Bittorrent vagy a Transmission. Az én első próbálkozásom a Deluge-al volt. Noha rendben működött, voltak fenntartásaim vele. Mivel a célom az, hogy monitor nélkül, webes felületen vagy terminálból érjek el mindent, a deluge daemon pedig igencsak erőforrás igényes, sokkal jobban terheli a CPU-t, mint a Transmission.

Na de mi is az a daemon?

Egy háttérben futó alkalmazás, ami a felhasználóval való kommunikáció nélkül hajt végre feladatokat bizonyos eseményeket folyamatosan figyelve. Mint pont ezt szeretnénk.

Mivel a Transmission kevesebb erőforrást használ, nagyon kis méretű program (17MB RAM-ot használ várakozó állapotban és 24MB-ot letöltés közben), így nagyon hamar váltottam is. Nézzük hogyan tudjuk "headless" telepíteni és beállítani.

TELEPÍTÉS

STEP1: Installáljuk a transmission daemont:

sudo apt install transmission-daemon

Készen is vagyunk. Nem volt túl nehéz igaz? A daemon már fut is a háttérben. Másra nincs szükségünk, mehet a konfigurálás.

KONFIGURÁCIÓ

A transmission-daemon telepítésekor új felhasználó, a debian-transmission kreálódott. Ennek a felhasználónak írási és olvasási jogokra van szüksége azokon a mappákon, ahová letölteni szeretnénk. Mivel a transmission teljesen független a Nextcloud-tól, ezért egyenesen meg is változtathatnánk a felhasználót a konfig fájlokban például a pi felhasználóra. Így kényelmesen tudunk bárhová letölteni a Raspberry-n, amit a pi kezel. Én azonban itt is az egyszerűség elvét alkalmaztam. A debian-transmission felhasználót adjuk hozzá azokhoz a csoportokhoz, amik azokat a mappákat kezelik, ahová letölteni szeretnénk. 

Esetemben ez a csoport a www-data. Itt rögtön vissza is utalok a Nextcloud telepítési lépéseinél a data mappa jogainak beállításához. Ezért adtunk a csoportnak is 7-es jogot, hogy hozzá tudjunk más felhasználókat is adni, akik tudnak mókolni a mappákban. Tegyük ezt most meg a debian-transmission-el:

sudo usermod -aG www-data debian-transmission

Mint a korábbiakban, ne lepődjünk meg, csak ujra bejelentkezés után (pl. reboot) érvényesül a módosítás

Mivel a telepítést követően azonnal elindult a transmission, most le kell állítanunk mindaddig, amíg végrehajtjuk a szükséges beállításokat. Nagyon fontos lépés a leállítás, enélkül bármit módosítunk, az bezárás után gyakorlatilag kuka.

sudo systemctl stop transmission-daemon

Ezt követően nyissuk meg a beállításokat tartalmazó json fájlt. Én a kedvenc nano alkalmazásomat használom:

sudo nano /etc/transmission-daemon/settings.json

A beállítások igen sokrétűek lehetnek, de kezdjük a legfontosabbal, méghozzá a felhasználó nevet és annak jelszavát adjuk meg a következő sorokat megkeresve:

"rpc-username": "felhasznalo",

"rpc-password": "jelszo",

Természetesen tetszőlegesen tudunk választani nevet és jelszót. Ezekre a transmission webes felületén történő belépéskor lesz szükség, valamint a letöltés automatizáláskor később szintén meg kell adnunk majd a Flexget program konfigurálásakor. Erről részleteket ITT (hamarosan...) olvashattok.

A következő amit beállítunk, hogy csak a localhost és az otthoni hálózatunkra csatlakozó eszközök csatlakozhassanak a torrent szerverünkhöz:

"rpc-whitelist": "127.0.0.1, 192.168.*.*",

A listába tetszőleges szűrés alapján tudunk IP-ket megadni, tovább limitálva, hogy ki érheti el. A 127.0.0.1 a localhost, a 192.... pedig a hálózatom IP címének eleje, a “*” csillag itt is elfogad bármilyen számot.

Amennyiben a Transmissiont Flexget nélkül szeretnék kézzel használ, úgy a letötési mappa helyét kell megadni még:

"download-dir": "/letöltés/mappa/elérési/útja",

Az alapbeállításokon túl sok egyéb opció van még, azonban ennyi már elegendő a használathoz. Mentsük el a fájlt és lépjünk ki: CRTL+X - Y - Enter.

Indítsuk el a transmission daemont és aztán az egész rendszert is érdemes (főként a korábbi felhasználó/csoport beállítás miatt, de egyébként ha újraindítjuk a gépet, akkor igazából az első sor nem is kötelező, hiszen indítás után automatikusan a transmission daemon folyamat is indulni fog):

sudo systemctl start transmission-daemon

sudo reboot

A fájl pörgetése közben az rpc-port -ot ha észrevettük, akkor alapból 9091-re van állítva. Erre szökségünk van a böngészőből való eléréshez. Írjuk hát be a Raspberry-nk IP címét majd a :9091-es portot.

Ha nem tudjuk mi a Pi IP címe, akkor a terminalból a következőképp tudjuk lekérni:

hostname -I

Ahogyan korábban is, most is javaslom, hogy a router-ünkben fix IP címet állítsunk be a Raspberry-nek, hogy ne kelljen mindig keresgélni (illetve egyéb konfigurációkban is sokat segít ha nem változik). 

Üssük be a böngészőnkbe a kövezkezőt tehát:

“RaspberryIP”:9091

A bejelntkező ablak ugrik fel, valahogy így:

A korábban megadott felhasználónév és jelszó segítségével lépjünk be. A következő nézet fogad minket:

Persze elsőre alighanem üresen. A használat magától értetődő. Én itt semmi újat nem állítottam be már, de érdemes az opciókat a bal alsó sarokban átfutni. A kezelő sávon a mappa ikonnal tudunk manuálisan új torrent fájlokat betölteni. Példa:

Tudunk a “Choose files” gombra kattintva már letöltött .torrent fájlt hozzáadni, vagy akár URL segítségével is linkelhetünk. A “Destination” folder alatt megadhatjuk hová töltse le a fájlokat. Ide alapból az általunk a  "download-dir" -nél megadott elérési utat írja be (ami nálam az egyik külső /mnt mappa alá felcsatolt meghajtó). 

A többi gomb használata is magától értetődő.

A hozzáadott torrentek sorára duplán kattintva további részleteket tudunk megnézni. Itt lehet a torrent alatt lévő fájlok között is szűrni, hogy mit nem akarunk például letölteni, vagy melyik fájlnak milyen prioritást, sebesség limitet akarunk megadni.

OPTIMALIZÁLÁS, TIPPEK

A Transmission settings.json fájlja sok opciót kínál nekünk, amelyek közül néhányat szeretnék bemutatni (részletes leírásért a Github wikit érdemes átnézni, de segítek ha szükséges). 

Ha a letöltési mappánk például valami “Download” vagy “Letöltés”, tudunk olyan mappát is használni, ami a letöltés idejére mint ideiglenes helyre tölt le. Ez lehet az “Incomplete” mappánk. Ha a letöltés teljesen befejződött, akkor innen automatikusan átkerül a fájl a “Download” mappánkba:

"incomplete-dir": "/ideiglenes/mappa/elérési/útja",

"incomplete-dir-enabled": true,

Az egyik leghasznosabb automatizmus amit más program nélkül meg tudunk valósítani, az a “Watch” mappa létrehozása és beállítása. Ez a figyelő mappa arra van, hogy az ide letöltött .torrent fájlokat automatikusan hozzáadja a letöltési sorba a Transmission. Nem kell nekünk belépni és hozzáadni, elegendő ide letölteni a torrent fájlt, a többit intézi a Transmission. Az ilyen mappa konfig sorait nekem a settings.json fájl alapból nem tartalmazta, de a következő sorok hozzáadásával ez könnyen orvosolható:

"watch-dir": "/torrentfigyelő/mappa/elérési/útja",

"watch-dir-enabled": true,

Ennek kiegészítése képpen a következő sorral azt is megadhatjuk, hogy a már hozzáadott torrent fájlokat törölje ki a “Watch” mappából:

"trash-original-torrent-files": true,

Ezen kívül egyéb sebesség limiteket, peer limiteket és hasonlókat is tudunk állítani a fájlban, de persze ezeket a webes felületen is megtehetjük. 

Fontos, ezért ismét kiemelem, hogy bármilyen változtatást eszközölünk a settings.json fájlon, előtte a daemont le kell állítani, különben visszaírja a korábbi beállításokat! Ha kész vagyunk indítsuk újra:

sudo systemctl stop transmission-daemon

sudo systemctl start transmission-daemon

TOVÁBBI LEHETŐSÉGEK

A web-es felület nagyon könnyedén használható, letisztult és egyszerű. Ennek ellenére én azt szeretném, ha a lehető legkevesebbszer kellene egyáltalán megnyitni. Már a “Watch” mappával is sokat tudunk előre lépni ezügyben. Azonban van egy röviden már említett Flexget nevű kiegészítő, ami további egyszerűsítést hozhat az életünkbe. Ha érdekel, olvasd el azt a posztomat is.

VISZLÁT!  

[ajtech]

Nextcloud telepítése

Az első posztokban azt írtam, hogy az otthon automatizálás legfontosabb kérdése, hogy mit szeretnénk automatizálni azon folyamatok közül, amit eddig manuálisan végeztünk.

Ahogyan elkezdtem a projektet, azonnal előkerült, hogy hát össze vagyok kötve a TV-vel, mi lenne, ha egyszerű külső meghajtó (1TB WD Elements ami már megvolt) USB-s csatlakoztatás helyett a meghajtó és a TV közé beiktatnánk a Raspberry-t, ami szépen rendszerezné a filmjeimet és sorozataimat. Noha a Netflix, HBO Go és hasonló streaming szolgáltatások mellett egyre kevesebb szükség van tárolni média tartalmat, azért még akad amit nem találunk meg, vagy túl sok előfizetés párhuzamosan megterhelő lenne a pénztárcánknak. Az első ötlet a Kodi volt. Szerencsére még a használat előtt a szomszédomnál is ketyegő Raspberry-n ki tudtuk próbálni. Kiderült, hogy a megfelelő erőforrás optimalizáláshoz Librelec OS-re van szükségünk, ami kifejezetten a Kodi számára optimalizált. A sima Raspberry OS-en sajnos nem működött zökkenőmentesen. Mivel nem dedikált médiaszerverként szeretném használni a Raspberry-t, ezért más megoldás felé kellett nézni. Ekkor következett a jelenleg is üzemelő Plex Média szerver.

No de mielőtt nekiugrunk a telepítésnek mi lesz akkor a külső tárhelyemen tartott egyéb dokumentumokkal? Az megint csak nagyon manuális lenne, ha folyton a laptop és a Raspberry között kéne átmozgatni a külső hdd-t. Egyből a Samba jutott eszembe, aminek segítségével a hálózaton hozzáférhetnék az eszközeimen minden fájlhoz. Végül kis utánajárással arra jutottam, hogy de jó lenne, ha ezt könnyen megoszthatnám másokkal, telefonon is könnyen hozzáférnék, sőt távolról is be tudnék lépni. Legyen egy saját felhő szolgáltatásom. Mint egy dropbox vagy google drive. Ekkor találtam rá a Nextcloud-ra. Mivel nagyon elterjedt manapság a “felküldöm a felhőbe” kifejezés, meglepően sokan használják anélkül, hogy tudnák valójában ez mit is jelent. Gyakorlatilag azt jelenti, hogy egy szerver szolgáltatáson keresztül elérve valaki más tárhelyén tároljuk az adatainkat. Mi lenne ha ehelyett a saját tárhelyünkön tárolnánk a saját adatainkat?

Így mielőtt a Plex-et felrakjuk, kezdjünk a Nextcloud-al. (Azért is fontos ez a sorrend később, hogy a hozzáférési jogokat megfelelően tudjuk beállítani.)

A tovább alatt részletes magyarázatokkal kiegészített telepítési lépések lesznek. Ha valaki a rizsára nem kíváncsi, akkor ITT (hamarosan...) megtalálja csak az utasításokat gyors (újra)telepítéshez.

A Nextcloud telepítése

INFO: A Nextcloud használatától függően érdemes 64 bites oprendszerre telepíteni, ugyanis a 32 bites oprendszer 2^32-en méretű fájlokat tud maximum kezelni, ami 4 GB, a php pedig 2GB-ban limitált. Ha ennél nagyobb fájlokat szeretnénk megfelelően kezelni, akkor mindenképpen 64 bitet válasszunk.

Három fő szekcióra osztom a lépéseket:

Szükséges programok telepítése

Konfiguráció (alap beállítások, SSL, etc.)

Optimalizálás

A Nextcloud webes eléréséhez szükségünk van egy webszerverre, php-re (ami egy szerveroldali szkriptnyelv dinamikus weboldalak készítéséhez), sql adatbázis kezelőre (felhasználók, tárolt fájlok indexelése stb.), memória caching kezelőre és a biztonságos kapcsolódás miatt SSL titkosításra (http helyett https [secure]). Igyekeztem az ajánlott és azok közül is a legkevésbé erőforrásigényes programokat használni:

Webszerver: Apache2

php: PHP7.3 (min 7.2 szükséges)

SQL: mariaDB

Memoria caching: Redis (APCu-val)

SSL: letsencrypt

TELEPÍTÉS

STEP1: Elsőként az Apache2 webszervert telepítjük:

sudo apt install apache2

STEP2: Ezt követően a php modulokat (jó sokat):

sudo apt install libapache2-mod-php

sudo apt install php7.3 php7.3-gd php7.3-sqlite3 php7.3-curl php7.3-zip php7.3-xml php7.3-mbstring php7.3-mysql php7.3-bz2 php7.3-intl php7.3-smbclient php7.3-imap php7.3-gmp php7.3-bcmath php7.3-imagick php-memcache php-apcu php-redis

STEP3: Az SQL adatbázisként használt mariaDB:

sudo apt install mariadb-server

STEP4: Memória cachinghez telepítjük a Redis szervert:

sudo apt install redis-server

STEP5: Az SSL titkosításhoz előszőr self-signed cerificate (általunk aláírt tanusítvány) generálása volt a megoldásom, majd konfigurációkor minden http kapcsolatot átirányítottam https-re. A problémám az volt ezzel, hogy ugyan a titkosítás rendben van, de minden böngészö “nem biztonságosnak” minősíti, mivel nincs hol ellenöriznie, hiszen a saját Raspberry-nken tároljuk. Noha természetesen a saját gépünkön a kulcs hozzáadható kivételként, bárkivel osztunk meg fájlokat, mindenkinek problémás lesz a nem biztonságos üzenet. Sőt, nekem a Safari legújabb verziója a Mac-en nem is volt hajlandó a self-signed tanusítvánnyal csatlakozni a webserverhez csak a helyi hálózati IP címmel.

Mivel nekem (és az emberek nagyobb részének) dinamikus IP-t ad a szolgáltató, így szükség van egy DDNS-re (Dynamic Domain Name Server), ami időközönként frissíti az IP-t, és domain névvel látja el. Több ilyen ingyenes szolgáltatás elérhető, érdemes a DuckDNS vagy a No-IP oldalakat felkeresni. Most ennek a részleteibe nem megyek bele, hiszen enélkül is megy a Nextcloud, a hálózatunk távoli elérése pedig nem specifikusan ide kötődik. Nekem szerencsém van, mivel a router-emben be tudok állítani DDNS szolgáltatást. Mielőtt a fentebb említett oldalakat felkeressük, érdemes utánajárni, hogy nem tudjuk-e a saját router-ünkkel megoldani. Mivel port továbbításra is szükség van, hogy tényleg elérhessük kívülről a hálózatunkat, így ezeknek külön poszt születik majd, amit később ide linkelek.

Szóval ha rendelkezünk DDNS-el és domain névvel, akkor a legcélszerűbb a Letsencrypt ingyenes szolgáltatását igénybe venni. Fontos, hogy IP címmel nem tudjuk használni, csak domain névvel (pl. domain.name.com).

SSL a Lersencrypt-el könnyedén fog menni, mivel van Apache webszerver specifikus tanusítvány generáló szoftver - a certbot, amit most telepítünk is:

sudo apt install python-certbot-apache

STEP6: Végezetül letöltjük a fő attrakciót, a NextCloud-ot, majd kitömörítjük. Mindezt a telepítési könyvtárba lépve:

cd /var/www/html

A letöltéshez a wget utasítást használjuk, majd kicsomagoljuk. (Figyeljük meg, hogy nem specifikus verziót töltünk le, hanem a “latest” = legutolsó kiadást. A linket követve persze másik verziót is tudunk telepíteni)

sudo wget https://download.nextcloud.com/server/releases/latest.tar.bz2

sudo tar -xvf latest.tar.bz2

KONFIGURÁLÁS

Minden szükséges programot feltelepítettünk, így most következik a konfiguráció. Egy részét továbbra is a terminálból végezzük, de szükségünk lesz a webes felületet is használni. Nem elengedhetetlen, de kényelmesebb.

STEP1: Hozzunk létre a mariaDB segítségével egy új adatbázist a nextcloud számára:

Belépéshez a következő sort futtatjuk, majd a Raspberry pi felhasználó jelszavát használjuk:

sudo mysql -u root -p

Ezek után a következő sorokkal létrehozunk egy új adatbázist, felhasználót és beállítjuk a jogokat:

CREATE DATABASE nextclouddb;

CREATE USER ‘nextclouduser’@'localhost’ IDENTIFIED BY 'JELSZÓ’;

GRANT ALL PRIVILEGES ON nextclouddb.* TO 'nextclouduser’@'localhost’;

FLUSH PRIVILEGES;

QUIT;

A nextclouddb adatbázis név és a nextclouduser felhasználó név is szabadon választható. A JELSZÓ helyére természetesen a saját kívánt jelszavunkat adjuk meg az aposztrofok között.

STEP2: A Nextcloud számára létrehozunk egy új adat könyvtárat, ahol minden fájlunkat tárolni fogjuk. A jó dolog a Nextcloudban, hogy külső meghajtókat utólag is kényelmesen tudunk majd csatlakoztatni akár lokálisan akár webDAV-al (és még jó néhány módon). Ezért ezt az adatmappát arra használhatjuk, amit a Raspberry tárhelyén (SD kártyán vagy később SSD boot esetén az SSD-n) szeretnénk tárolni. Természetesen az adatmappa bármikor áthelyezhető teljes egészében akár külső meghajtóra is.

A könyvtár létrehozása a make dir utasítással (-p opció parent-et jelent, azaz a teljes beírt mappa elérés minden még nem létező szülő könyvtárát létrehozza):

sudo mkdir -p /var/www/html/nextcloud/data

Ehhez a mappához, és minden a Nextcloud által a későbbiekben használandó könyvtárhoz a webszerverünk felhasználóját kell társítani, mint mappa tulajdonos. Az Apache2 esetében a telepítéskor létrejött felhasználó a www-data, ami a szintén www-data felhasználói csoport tagja. Fontos ezt megjegyezni, hiszen sok beállításnál és későbbi mappa elérési problémánál a válasz abban rejlik, hogy megfelelően hozzáfér-e a www-data az adatokhoz, avagy más felhasználónak joga van-e a www-data tulajdonában lévő mappákat látni, módosítani.

Adjuk tehát meg a www-data csoport és www-data felhasználó tulajdonjogát a chown = change owner (tulajdonos váltás) utasítással. A -R opció a rekurzív módot jelenti, azaz a mappa mellett annak minden almappájára/fájljára vonatkozik a változtatás.

sudo chown -R www-data:www-data /var/www/html/nextcloud/

A linux esetében az olvasási, írási és végrehajtási jogokat be tudjuk állítani a tulajdonló felhasználónak, annak csoportjának, valamint a külső felhasználóknak. Érdemes a külső felhasználóknak nem engedni semmi módosítást biztonsági szempontok miatt.

Mindhárom fentebb említett joghoz társul egy-egy azonostó szám a következőképpen:

1 - csak végrehajtás

2 - csak írás

4 - csak olvasás

A jogokat így az opciókhoz tartozó számok alapján tudjuk megadni, azokat bármilyen kombinációban összegezve, pl: 5 = olvasás és végrehajtás / 7 = mindhárom teljes jog, 0 = semmi jog, stb.

Állítsuk be tehát a www-data számára, hogy tudjon olvasni, írni és végrehajtani is. A www-data csoportnak elegendő az olvasás és végrehajtás is, de ha más felhasználót adunk később a csoporthoz, akinek szerenénk jogot adni az írásra is (lásd majd Plex médiaszerver, vagy a pi felhasználó), akkor érdemes oda is teljes jogot adni. A lenti sorban a harmadik szám a külső felhasználóké, amit 0-ra állítunk. Így igényünknek megfelelően 750 vagy 770 is megfelelő lehet. Utasítás a chmod = change mode, itt is rekurzívan.

sudo chmod -R 770 /var/www/html/nextcloud/data

STEP3: Az Apache2 konfigurációjához érdemes tudnunk, hogy hol találhatóak a konfigurációs fájlok. Ha meg akarjuk nézni őket, itt találjuk:

ls /etc/apache2

Ezen a mappán belül találjuk az apache2.conf fő konfigurációs fájlt, valamint a site-available mappa alatt minden olyan weboldal (site) konfig amit be avagy ki tudunk kapcsolni a továbbiakban. Az aktuálisan bekapcsol/használt egyéb konfig fájlok a sites-enabled mappa alatt találhatóak. Ugyanez igaz a modulokra mods-available és mods-enabled mappákban, valamint az egyéb konfigokra a conf-available. Mivel a nextcloud is egy weboldalként fog megjelenni, így létrehozunk neki egy config-ot, amely segítségével az Apache tudni fogja minként kezelje a /var/www/html/nextcloud mappát és annak .htaccess fájlját hajtsa végre (a .htaccess egy olyan konfigurációs fájl ami webszervert állítja be az egész webes honlapra vonatkozóan - a Nextcloud pedig egy saját .htaccess fájllal érkezik alapból). A létrehozáshoz és szerkesztéshez a nano alkalmazást használom:

sudo nano /etc/apache2/sites-available/nextcloud.conf

Az üres fájlba a következő tartalmat kell elhelyezni:

Alias /nextcloud "/var/www/html/nextcloud/" <Directory /var/www/html/nextcloud/> Require all granted AllowOverride All Options FollowSymLinks MultiViews <IfModule mod_dav.c> Dav off </IfModule> </Directory>

Mentsük el a CTRL+X - Y - Enter segítségével. Mielőtt engedélyezzük az oldal config-ot:

STEP4: Hozzuk létre az SSL tanusítványunkat a korábban telepített certbot-al:

sudo certbot --apache

Töltsük ki a szükséges adatokat a felbukkanó kérdésekre válaszolva:

...E-mail address...: your@email.com

...share your email address with…: N(o)

...enter in your domain name…: domain.name.com (Nem szükséges a https:// előtte)

...redirect HTTP traffic to HTTPS…: 2 [redirect]

A generált tanusítvány 90 napig érvényes, amit 30 nap lejáraton belül meg tudunk újítani. Szerencsére erre egy automatikus cron feladat már rendelkezésre is áll, ami naponta kétszer ellenőrzi, és hogy ha lejárt a tanusítvány, akkor frissíti azt. Ha az intervallumon szeretnénk módosítani, akkor a következő helyen érjük el a fájlt:

sudo nano /etc/cron.d/certbot

A cron job-ok áttekintése külön posztban ITT (hamarosan...) található.

Persze manuálisan is frissíthető:

sudo certbot renew

Alapvetően további teendőnk nincs, a jó dolog, hogy minden átirányítás és konfiguráció automatikusan elkészül, szemben a self signed tanusítványos módszerrel. Ha valakinek nincs elérhető domain neve, az ITT (hamarosan...) megnézheti, hogy hogyan kell saját tanusítványt készíteni.

Azonban tapasztalatból tudom, hogy néhány optimalizálásra a létrejött SSL conf fájlban szükségünk van, hogy hiba nélkül tudjuk üzemeltetni a felhőnket.

A következő blokkokat adjuk hozzá a 000-default-ssl-le.conf fájlhoz:

sudo nano /etc/apache2/sites-available/000-default-le-ssl.conf

<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" </IfModule> Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav

A header beállítására azért van szükség, mert az SSL tanusítványunk mellett további biztonságot eredményez. A Strict-Transport-Security, vagy HSTS megerősíti azt, hogy az ilyen fejléccel rendelkező honlapot kizárólag a biztonságos https módon érhetjük el. Amikor a böngésző megpróbálja megnyitni az oldalt, akkor “megtanulja”, hogy ezt a domaint csak és kizárólag https-el érhetjük el. Ezt az információt a “max-age”-ben beállított periódusig tárolja a cache-ben. Esetünkben másodpercben értendő a beírt szám, átszámolva kb. fél év. 

A két 301-es átirányítás a Nextcloud számára szükséges. A CardDav és a CalDav két hálózati protokol webDav alapokon felhasználói információk (CardDav) és naptár (CalDav) adatok megosztásához. Ezek a Nextcloud ide kapcsolódó funkcióihoz szükségesek. 

Valahogy így fog kinézni ezek után a conf fájl:

STEP5: A .htaccess fájl biztos végrehajtásához az apache2.conf fájlban is engedélyeznünk kell a /var/www mappán az átírást. Nyissuk meg a config fájlt:

sudo nano /etc/apache2/apache2.conf

Keressük meg a következő részt (keresni a CTRL+W -vel tudunk), és írjuk át az AllowOverride None sort AllowOverride All -ra:

<Directory /var/www/> Options IndexesFollowSymLinks AllowOverride All Require all granted </Directory>

STEP6: Engedélyezzük az eddigiekben beállított conf file-okat és modulokat az a2ensite és a2enmod utasításokkal (pl. a2enmod = Apache2 Enable Modules):

sudo a2ensite nextcloud.conf 000-default-le-ssl.conf 000-default.conf

sudo a2enmod ssl rewrite headers env dir mime

STEP7: A PHP konfigurálása

Ebben a lépésben a php vonatkozó beállításait tesszük meg, hogy kényelmesen tudjuk használni a Nextcloudot. Ehhez nyissuk meg a php.ini fájlt:

sudo nano /etc/php/7.3/apache2/php.ini

A feltölthető fájlok méretének megváltoztatásához keressük meg a upload_max_filesize, a letölthető mérethez post_max_size sorokat. Állítsuk be a kívánt értéket. Fontos tudni, hogy csak egész számot vár a php, tehát 4G vagy 3800M használható, de 3.8G nem, ezt 3G-nek fogja értelmezni. a G természetesen gigabyte, az M megabyte.

post_max_size = 40G

upload_max_filesize = 40G

A memória limitet a memory_limit -re keresve állítsuk minimum 512M-re. Én 4GB-os raspberry memória miatt kicsit feljebb állítottam: 

memory_limit = 1G

A cache memória optimalizációhoz javasolt a következő sorok aktiválás a ; kitörlésével (;-vel komment sornak számít), valamint az értékeket állítsuk át ahol szükséges:

opcache.enable=1

opcache.memory_consumption=128

opcache.interned_strings_buffer=8

opcache.max_accelerated_files=10000

opcache.revalidate_freq=1

opcache.save_comments=1

Ha már itt vagyunk a php.ini fájlban szintén a tapasztalatoknak köszönhetően, a következő sort adjuk hozzá az extension szóra keresve egy új sorba:

extension=imagick.so

Mentsünk és lépjünk ki: CTRL+X - Y - Enter.

Ugyan telepítettük ezt a php modult, ami a nextcloud témákért lesz felelős, de sajnos az eredeti helyén engedélyezve a Nextcloud sokszor dob ellenőrzéskor figyelmeztetést miatta. Az eredeti helyén ugyanezt a sort még kommenelnünk kell a sor elé helyezett pontosvesszővel:

sudo nano /etc/php/7.3/apache2/conf.d/20-imagick.ini

;extension=imagick.so

Mentsünk és lépjünk ki: CTRL+X - Y - Enter.

STEP8: A Redis szerver konfigurálása a caching miatt:

Nyissük meg a konfigurációs fájlt:

sudo nano /etc/redis/redis.conf

Keressünk rá a port szóra és állítsuk át 0-ra.

Keressünk rá a unixsocket szóra és vegyük ki a következőek elől a kommentelő ;-t, valamint a hozzáférésnél adjuk meg a 770-t. Így nézzen ki a két sor:

unixsocket /var/run/redis/redis-server.sock

unixsocketperm 770

Engedélyezzük a rendszerfolyamatok között a redis szervert, majd indítsuk is el:

sudo systemctl enable redis-server

sudo systemctl start redis-server

STEP9: Felhasználói csoportok beállítás:

Sokszor lehet hasznos, ha a Terminálból a “pi” felhasználóval bele tudunk nézni a www-data felhasználó által kezelt mappákba. Emellett a www-data pedig tagja kell, hogy legyen a redis csoportnak. Futtassuk a usermod parancsot -aG opciókkal - a = add (hozzáad), G = group (csoport):

sudo usermod -aG www-data pi

sudo usermod -aG redis www-data

Jó tudni, hogy ezek a változtatások csak újra belépés után fognak végrehajtódni.

STEP10: Rengeteg beállításon vagyunk túl, tudassuk ezt az Apache2 webszerverrel, töltsük újra, majd ajánlatos egy teljes újraindítás is:

sudo systemctl reload apache2

sudo reboot

STEP11: Konfigurálás a webes felületen

Eljött az igazság pillanata, ha mindent jól csináltunk, akkor a kedvenc böngészőnkből a Raspberry IP címével elérhetjük a Nextcloud-ot:

192.168.xx.xx/nextcloud

Első alkalommal létre kell hoznunk egy adminisztrátor fiókot, valamint lehetőségünk van a korábban létrehozott adatbázisunkat társítani:

Kép forrás: pimylifeup.com 

Adjunk meg egy tetszés szerinti felhasználó nevet valamint jelszót

Kattintsunk a Storage & database (tárolás & adatbázis) szövegre és ellenőrizzuk az adatmappa helyét, hogy valóban a korábban megadott /var/www/html/nextcloud/data legyen.

Válasszuk a MySQL/MariaDB opciót

Adjuk meg az adatbázis felhasználó nevét

A hozzátartozó jelszót

Az adatbázis nevét (alatta a localhost maradjon)

Kattintsunk a Finish setup gombra a befejezéshez.

A befejezés néhány percet is igénybe vehet. Ha elkészült, akkor a köszöntő oldal fogad minket. A navigációról és az elérhető beállításokról külön most nem írok többet. Egyrészt nagyon hasonló más felhőszolgáltatás oldalához, tehát a használat ismerős módon történik (új mappa, drag&drop, megosztások stb.), másrészt aki eddig nem adta fel a hosszadalmas poszt olvasását, az most fogja, ha még tovább rizsázok. 

STEP12: A nextcloud konfigurációs fájlja terminálban

Térjünk vissza a terminálhoz. A továbbiakban ha a Nextcloudod karbatartjuk, módosítjuk a konfigot, akkor érdemes karbantartási módba kapcsolni, még mielőtt nekiugrunk. Így ha már vannak felhasználóink, akkor nem fognak akkor fájlokat módosítani, amikor mi épp mókolunk a rendszerrel, és még értesítést is kapnak a kimaradás okáról a honlap megnyitásakor.

Lépjünk be a telepítési könyvtárba, és használjuk az OCC utasítások karbantartási üzemmód bekapcsolását:

cd /var/www/html/nextcloud/

sudo -u www-data php occ maintenance:mode --on

Ezek után bátran nyissuk meg a konfigurációs php fájt a nano-val:

sudo nano /var/www/html/nextcloud/config/config.php

Elsőként a raspberry IP címével értük el az oldalt, azonban ha most megpróbálnánk a domain névvel is elérni, akkor hibaüzenetet kapunk arról, hogy nem megbízható címmel próbáljuk elérni az oldalt. Ezt könnyen orvosolhatjuk, hogy ha a megbízható domain-ek tömbjéhez új indexelt sorban hozzáadjuk a DDNS-hez tartozó domain nevünket:

    ’trusted_domains’ => array ( 0 => '192.168.xx.xx', 1 => 'domain.name.com', ),

Természetesen a saját Raspberry IP már benne lesz, csak adjunk hozzá egy új sort 1-es index-el. (A vessző a végén ne maradjon le!). Tetszőleges számú domain nevet adhatunk itt meg.

A konfiguráció végére pedig a memória caching (Redis) paraméterezését másoljuk be:

'memcache.local' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'filelocking.enabled' => 'true', 'redis' => array (  'host' => '/var/run/redis/redis-server.sock',  'port' => 0,  'dbindex' => 0,  'timeout' => 0.0, ),

Mentsük el a fájlt (CTRL+X - Y - Enter). 

Kapcsoljuk ki a karbantartási módot:

cd /var/www/html/nextcloud/

sudo -u www-data php occ maintenance:mode --off

Próbáljuk meg a domain névvel is elérni az oldalt:

domain.name.com/nextcloud

Ellenőrizzük le, hogy valóban HTTPS-el kapcsolódunk, valamint ha a router-ben helyes a port továbbítási beállításunk az Apache2 által használt 80-as és 443-as portokkal, akkor kívülről (pl mobil internettel) is kipróbálhatjuk.

Mind iOS-re, mind Androidra elérhető a Nextcloud applikáció, sőt PC-nkre ha szinkronizálni szeretnénk, akkor egy asztali applikáció is letölthető. Ezekhez látogassuk meg a Nextcloud letöltési oldalát, vagy a telefonunk/tabletünk app store-ját. 

Mostmár minden olyan lépésen túl vagyunk, amivel kényelmesen tudjuk használni a Nextcloudod. 

OPTIMALIZÁLÁS

A harmadik szekció az optimalizálás, ami a legrövidebb lesz és a valójában nem elengedhetetlen lépéseket mutatom itt be.

OPCIÓ1: Amikor a fájlokat megoszani kívánjuk, kapunk egy elérési linket. Azonban ezt a linket csúfítja egy /index.php/ rész. Szükségtelenül hosszabb és csúnyább linket meg ki szeretne? Hát én nem, így a Nextcloud konfigurációs fájlban a következőket tegyük (a karbantartási mód bekapcsolása és a fájl megnyitása fentebb olvasható már):

Adjuk hozzá ezt a sort az ‘overwrite.cli.url’ már létező sorok után így:

'overwrite.cli.url' => 'http://192.168.xx.xx/nextcloud', 'htaccess.RewriteBase' => '/nextcloud',

Mentsük el a fájlt (CTRL+X - Y - Enter).

A beírtak érvényesítéséhez egy újabb OCC utasításra van szükség, hogy frissítsük a .htaccess fájlunkat (ahogyan a paraméter neve is sugallja):

cd /var/www/html/nextcloud/

sudo -u www-data php occ maintenance:update:htaccess

Most már szépek lesznek a linkek. 

OPCIÓ2: Mivel később a torrent szerverünk és a média szerverünk is piszkálni fogja azokat a mappákat amiket a Nextcloud kezel, így érdemes a következő paramétert beállítani, szintén a konfig fájlban hozzáadott új sorként:

Adjuk hozzá ezt a sort az ‘overwrite.cli.url’ már létező sorok után így:

'filesystem_check_changes' => 1,

Mentsük el a fájlt (CTRL+X - Y - Enter).

Ezzel a paraméterrel adjuk meg, hogy milyen sűrven nézze át a fájlrendszert a Nextcloud a külső módosítások miatt. Külső módosítás minden olyan változtatás (új mappa, új fájlok, törölt fájlok stb.), ami nem a Nextcloud webes felületen vagy applikációkkal történt. Tehát pl. a terminállal hoztunk létre egy mappát, vagy a Plex-en keresztül töröltünk egy videót. Két beállítási lehetőség van egyébként, a 0 esetén soha nem frissíti magától, 1 esetén pedig minden oldal lekérésnél megteszi. Érdemes átgondolni, hogy valóban szükségünk van-e erre, hiszen emiatt az ellenőrzés miatt valamelyest veszítünk a rendszer sebességéből a folyamat lefutása miatt. Nekem mindenképpen kell a korábban említett egyéb szerverek módosításai miatt.

OPCIÓ3: A háttérmunkálatok automatizálása cron job-al.

A webes felületen a felhasználóra kattintva (jobb felső sarok) a Beállítások menüpontot választva a betöltött felület bal sávjában keressük meg az Adminisztátor szekciót, és azon belül is az Általános beállításokat (Basic settings). Az alap beállítás a háttérmunkákra az AJAX ami leírásából láthatóan egyszer hajtja végre oldal lekérésenként. Ennél optimálisabb megoldás a Cron opció választása, ahogyan nála is van. 

Persze ez önmagában nem elegendő, a szerveren (a Raspberry-n) ehhez még konfigurálni kell a cron job-ot. Ahogy a képen is látható a segítő szöveg, a cron.php fájlt kell futtatnunk 5 percenként, méghozzá a www-data felhasználó által. 

A cron job-okról külön posztban részletek ITT (hamarosan...). Most a magyarázattal nem foglalkozunk, csak a lépésekkel:

Nyissuk meg a cron fájlt ahol be tudjuk állítani a fentieket, már a www-data felhasználó-val:

sudo crontab -u www-data -e

Adjuk hozzá ezt a sort a fájl végére:

*/5 * * * * php -f /var/www/html/nextcloud/cron.php

Mentsük el a fájlt (CTRL+X - Y - Enter).

Ha jól csináltuk és frissítjük az oldalt, visszanavigálunk a Basic settings-hez, akkor egy kis zölt pöttyöt láthatunk azzal az infoval, hogy mikor futott le utoljára. Persze ha egyből nem ezt látjuk még ne ijedjünk meg, várjunk 5 percet, hátha nem futott még le egyszer sem.

OPCIÓ4: Biztonsági beállítások ellenőrzése

Ez egy nagyon hasznos teendő, amit érdemes bizonyos periódusonként (hetente, kéthetente ahogy tetszik) megcsinálni. Ismét kattintsunk a felhasználónk kis ikonjára jobb felül, válasszuk a Beállításokat (Settings), majd az Adminisztróció alatt az Áttekintés (Overview) menüt válasszuk. Néhány másodperc alatt lefut, és ha minden rendben (ezért állítgattunk annyi mindent konfigurációnál, hogy most már ne kelljen), akkor ez a kép fogad minket:

“All checks passed”. 

Amennyiben persze valahol hibát vétettünk, vagy valamit kihagytunk, akkor itt Error és Warning üzenetek várhatnak ránk, azok megoldásában a Nextcloud dokumentáció lehet segítségünkre, vagy írjatok nekem, és megpróbálok segíteni velük.

Nekem az eddigi lépések után csak egyetlen hibám volt - hiányzó index-ekre panaszkodott. Ez nem igazán kimaradt beálltás vagy hiányzó lépés miatt történhet. A Nextcloud frissítések, új verziók megjelenése során olyan változás történik, ami miatt az adatbázisunkat vagy konfigurációnk bizonyos pontjait frissítenünk kell. Ez normális, ezért érdemes karbantartásokat végezni ennek a Security & Setup időszakos átnézésével. 

A hiányzó index-ekhez a következőt kell futtatnunk a már korábban használt OCC utasítással (a hiba leírásában is pontosan erre ad információt a Nextcloud nekünk):

cd /var/www/html/nextcloud

sudo -u www-data php occ db:add-missing-indices

A képhez még egy kiegészítés: 

Ahogy látjátok, a Nextcloud verzióját és az elérhető újabb verziókat is nyomon tudjátok itt követni. Az “Open Updater” gombra kattintva innen is frissíthetünk a legújabb verzióra, ami igénybe vesz ugyan némi időt a letöltéssel, előző verzió biztonsági mentésével, és a telepítéssel, de automatikusan karbantartási módba rakja a rendszert, és mindent elvégez számunkra. Én ezzel a móddal szoktam verziót követni. Mindjárt meg is teszem :)

Végszó

Noha elsőre nagyon hosszadalmasnak és nehéznek tűnik a telepítést, ez sokkal inkább a részletes magyarázataimnak köszönhető. A folyamat nagyon gyorsan végigvezethető. Viszont szerettem volna egy komolyabb összefoglalást, hogy értsük is, amit pontról-pontra csinálni kell. Így később karbantartás vagy újra telepítés esetén tudni fogjuk hogyan álljunk neki, avagy nem esünk kétségbe ha eddig ismeretlen hiba lép fel, hiszen tudjuk hogyan épül fel a rendszer. 

Ráadásul bizonyos lépéseknél még így is kihagytam a részleteket. Egyrészt mert nem szorosan ide tartoznak, másrészt pedig mert megérdemelnek egy független saját posztot is.

Remélem sok hasznos információval gazdagodott, aki végigszenvedte a posztot. Elméleti vagy gyakorlati hibákról visszajelzést szívesen fogadok, valamint kérdésekre is igyekszem válaszolni legjobb tudásom szerint ha megkerestek.

Kellemes telepítést, és élvezzétek a privát felhőtöket! ;)

[ajtech]

Az első lépések

Linuxra fel!

A megrendelt eszköz egy Raspberry Pi 4B 4GB memóriával. Akkoriban jött ki a 8GB-os verzió, de kicsit utána olvasva az én igényeimnek a plusz 4 giga memória felesleges volt másfélszeres áron. Sok tesztet néztem, és a hasonló szolgáltatásokkal első sorba a CPU limitjét érték el, nem a memóriát. 

Amíg megérkezett a Raspberry, addig a várakozást azzal töltöttem, hogy mások által összerakott projekteket böngésztem. Csak úgy érdekesség képpen, hátha találok még felhasználási módokat. Ekkor már biztos voltam abban, hogy a Homebridge szerver felkerül. De mint kiderül, ez éppen csak a kezdet volt.

A Raspberry operációs rendszere SD kártyáról boot-ol, így arra szükséges felraknunk. A hivatalos RaspberryOS ingyenesen letölthető:

https://www.raspberrypi.org/software/operating-systems/#raspberry-pi-os-32-bit

Ez egy 32 bites oprendszer, de természetesen más 64 bites (Ubuntu) is elérhető a honlapon. Bár erre én csak később jöttem rá, Beta verzióban 64 bites Raspberry OS is létezik már:

https://downloads.raspberrypi.org/raspios_arm64/images/

Az első telepítéshez használt eszközök (2020 szeptemberi árak):

Raspberry Pi 4B 4GB (21.990 Ft)

Raspberry Pi 4 Official táp, 15W (3.190 Ft) 

Kábel HDMI-HDMI micro (1.590 Ft)

Sandisc MicroSDHC Extreme Pro 32GB (9.299 Ft)

Ez korántsem lesz a végleges összeállítás, de kezdésként ezekkel dolgoztam.

Az SD kártya előkészítése az oprendszerrel Mac-en és Windows-on is nagyon hasonló (https://www.youtube.com/watch?v=J024soVgEeM):

A hivatalos Raspberry Pi Imager telepítése

SD kártya PC-hez való csatlakoztatása

Kiválasztjuk a telepíteni kívánt rendszert (akár egy már letöltött image-et is választhatunk)

Kiválasztjuk az SD kártyát

Rákattintunk a WRITE gombra és rágyújthatunk egy kávéra:

A telepítés befejeztével még egy hasznos lépést érdemes elvégezni:

MAC-en: nyissuk meg a Terminalt, és a következő utasítást futtassuk le :

touch /Volumes/boot/ssh

Windows-on: hozzunk létre egy ssh nevű üres fájlt a kártya gyökerében, kiterjesztés nélkül (pontosan ugyanazt tesszük mindkét oprendszeren).

Erre azért van szükség, hogy SSH-n (Secure Shell - biztonságos kapcsolati csatorna/protokol két eszköz között a hálózaton) elérhessük a rendszert. Én biztos ami biztos a TV-met használtam kijelzőként, de persze bármilyen monitor HDMI porttal megfelel. Mivel mindent a terminálon végzünk majd, így monitorra igazán nincs is szükségünk.

A Raspberry-n bekapcsoló gomb nincs, így az SD kártya behelyezését, valamint lehetőség szerint az UTP kábel csatlakoztatását követően dugjuk be az USB-C port-ba a tápot. Ekkor a mini gépünk bekapcsol és boot-ol az SD kártyáról.

SSH-val a következőképpen érhetjük el a Raspberry-t:

ssh pi@IPcím

Ahol a “pi” az alapértelmezett felhasználó az IPcím pedig a router-től kapott IP, amelyet legjobb statikusra állítani a router kezelő felületén. Mivel ez minden típushoz specifikus lépésekkel jár, így ezt külön nem részletezem. (De tervezek post-ot a hálózatról is)

TIPP: iPad -en én az ingyenes Termius applikációt használom, a Mac-en a Terminal-t, Windows-on a Putty alkalmazás letöltését javaslom.

Az első belépésnél a jelszó “raspberry”. Beállítunk néhány dolgot a configurációban:

sudo raspi-config

A “sudo” segítségével gyakorlatilag adminisztrátori jogokkal fut le az utasítás, mivel sudo = superuser do. Persze minden felhasználónak nincs joga ehhez. A “pi”-nek viszont van. (/etc/sudoers konfiguráció tartalmazza azokat akiknek van ilyen joga)

Első teendő beállítani egy biztonságos jelszót a “pi” felhasználónak: 

1. System Options - S3 Change Password 

menüben tehető meg. 

Érdemes továbbá bekapcsolni az SSH és VNC opciókat (nálunk az SSH már aktív persze):

2.  Interface Options - P2 SSH és P3 VNC

A VNC segítségével monitorral vagy anélkül is el tudjuk érni az eszközünk asztalát távolról, feltételezve, hogy nem Lite (asztal nélküli) verziót telepítettünk.

Hasznos a további beállításokat is végignézni, főként az időzóna és a nyelv csomagok beállítása szükséges. A wifi konfigurálását is elvégezhetjük, amennyiben nem tervezzük UTP-vel összekötni a router-t és a Raspberry-t. Később még visszatérünk ezekhez a beállításokhoz, de elsőre ennyi bőven elegendő.

A rendszerhez elérhető új csomagokat az apt manager segítségével (APT=Advanced Package Tool) tudjuk frissíteni:

sudo apt update

sudo apt upgrade

Fontos bizonyos időközönként futtatni ezeket, hogy a biztonsági frissítésekkel mindig naprakész rendszerünk legyen.

Újraindítani a következő sorral tudunk:

sudo reboot

Ezzel az előkészületekkel kész vagyunk. A számunkra szükséges szoftverek telepítése következik. 

Ekkor jött az ötlet (időrendben a Homebridge telepítés után), hogy mi lenne, ha olyan központot csinálnék, ami az okos eszközök kezelése mellett további kényelemmel járna. 

Kodi, Samba, Nextcloud, Plex, Deluge, Transmission, Flexget. Ezek következnek.

[ajtech]

Okosotthon - Miért pont Raspberry?

A Raspberry egy mini PC így változatos projektekre lehet használni. Bármi jut majd eszembe, megpróbálhatom megvalósítani vele. Amikor abban gondolkodtam, hogy elkezdek az okosotthon témával foglalkozni, akkor első dolgom, mint mindennel, feltúrni a jutyubot és a google egyéb platformjait. Már korábban is hallottam a Raspberry-ről, de nem ebben a vonatkozásban. 

Egyébként ezt az “okosotthon” szót nem nagyon szeretem. Nekem ez inkább otthon automatizálás. Nem okos ez, csak kényelmesebb. Legalábbis nekem. A feleséget nem győztem meg azt hiszem.

A továbbiakban sok poszt lesz konkrét megvalósításokról, linux utasításokkal tele, de pettingnek szeretnék pár szót pazarolni arra, hogy hogyan indult el az egész projekt, és hogy hogyan gondolkodtam.

Az otthon automatizálás még nagyon gyerekcipőben jár. Noha vannak kiforott vezetékes rendszerek (pl. knx), azért ez még eléggé úri mulatság az eszközök árait tekintve. A vezeték nélküli technológia fejlődésével persze elkezdett kitágulni ez a világ is. Ma már egészen megfizethető áron neki lehet kezdeni. A probléma az, hogy merre induljunk? Annyira az első káosz rendeződés előtt állunk, hogy gyakorlatilag kismillió gyártó egymástól független, együtt nem, vagy nehézkesen és limitáltan, dolgozó eszközeiből tudunk választani. Sok ismerősöm futott bele abba a hibába, hogy különféle gyártók wifis eszközeivel telepakolta a lakását, majd rájött, hogy ahány darab, annyi külön applikáció. Utólag integrálni meg nehéz, vagy nem is lehet. Persze a hangvezérléssel is ellátott platformok kézenfekvőek lennének, mint Apple HomeKit, Google Home, Amazon Alexa, de sajnos egyik sem teljeskörű megoldás minden eszközünkhöz. A Google Home egyenesen botrányosan szar szerintem.

Egy szó mint száz, még a plug n play távolinak tűnik. Ha pénz nem számít, akkor megoldható, de ha szűkös kerettel rendelkezünk, akkor jól át kell gondolni a dolgokat. Márpedig az “olcsó” verziók sem jönnek ki pár ezer forintból az ziher. Az ideális eset, ha még nincs, vagy minimális okoseszközünk van. Így néhány fő kérdés megválaszolása után céltudatosan keresgélhetünk a boltokban. 

Vezetékes vagy vezeték nélküli?

Az első kérdés egyszerű. Új lakások/házak esetén a vezetékes rendszer jó ötlet, akár egy PLC-vel, akár KNX vagy hasonló renszerrel. Itt még van lehetőségünk ennek megfelelően kialakítani a vezetékezést. Érdemes azonban átböngészni az árakat. Komoly százezrek röpködnek, én gyors kereséssel se találtam 30 ezer alatt eszközöket. 90 ezerért mozgásérzékelő, 120 ezerért zsalu vezérlő, 180 ezerért egy 8 csatornás bementi egység, stb. Persze vitathatatlan, hogy ezek a rendszerek nagyon stabilak. A 90-es évek óta jelen van nálunk Magyarországon és hibátlanul működő rendszer. Irodaházakban és gazdagoknak nagyszerű.

Árban jóval olcsóbb eszközökkel, ugyan kevésbé stabil, de jó rendszert tudunk építeni vezeték nélkül is. Ez a választás könnyed azoknak, akik nem tervezik szétverni az összes falat a lakhelyükön. Persze egy valamit semmiképp ne feledjünk: biztonságtechnikai berendezések és rendszerek építése esetén maximum poénból legyen párhuzamosan egy vezeték nélküli visszajelzés. Riasztók esetében, ha tényleg vagyonvédelmet szeretnénk, akkor vezetékezzünk. 

Az én választásom a vezeték nélküli rendszer (kivéve biztonságtechnika). 

WiFi, Zigbee vagy Z-Wave esetleg RF?

A vezeték nélküli adatávitelre több féle protokol létezik, amelyeket a használt frekvencia sáv valamint a módszer különböztet meg. Nem megyek bele a részletekbe, erre sok dedikált videó és leírás létezik.

Az eszközeink sok módon lehetnek képesek kommunkálni, érdemes lehet leszűkíteni, hogy mi melyiket szeretnénk kihasználni. A WiFi kézenfekvő lehet, hiszen minden háztartás rendelkezik olyan router-el manapság, amely vezeték nélküli hálózatot is biztosít. A Zigbee és a Z-Wave elönye, hogy jóval ritkábban és kisebb mennyiségű adatot cserél, mint a WiFi, mivel ezeket kifejezetten otthon automatizálás miatt fejlesztették ki. Itt ugyanis elegendő limitál mennyiségű, egyszerű állapotok státuszának lekérése vagy vezérlése. Ez jóval energia hatékonyabbá teszi az ilyen készülékeket. A rádió frekvenciás módot szintén biztosan sokan használják távirányítós eszközökkel, lásd redőny vezérlés, klíma vezérlés. A döntésnél érdemes figyelembe venni a környezetünket, hogy mennyire leterhelt egy-egy frekvencia sáv.

Mivel én szeretném, ha minél több eszközömet tudnám telefonról is vezérelni, így valamilyen úton-módon szükségem van WiFi-re. Az én választásom az állandó hálózati tápellátású eszközök esetén WiFi, míg az akkumulátoros/elemes eszközöknél a Zigbee. Reményeim szerint Z-Wave is tesztelve lesz a későbbiekben, azonban mivel mindenképpen szükség van valamilyen eszközre a Zigbee és a Z-Wave-ről WiFi-re fordításhoz (valamilyen hub), így első körben választok a kettő közül. A Zigbee mellett szól, hogy nyílt protocol, a Z-Wave-et pedig liszenszelni kell, így Z-Wave eszközök általában drágábbak is a plusz miatt. A szigorúbb szabályok és a liszenszelés kontrolláltabb környezetet feltételez, de idővel megtapasztaljuk, hogy ez jelent-e reális különbséget.

Az én választásom tehát: WiFI és Zigbee.

Az okosotthon központi felülete

A következő pont amiről döntést kell hoznunk az az eszközeink használatára, működtetésére, állapotainak megjelenítésére használt platform. A főbb lehetőségek között található az Apple Homekit, az Amazon Alexa, Google Home, valamint a jól személyre szabhatő teljes vagy fél DIY rendszerek, mint pl. a HomeAssistant, vagy egyéb olyan lehetőség melyek a nagy előbbi hármassal tudnak együtt dolgozni (például a hangvezérlés miatt). Noha úgy gondolom, hogy Magyarországon a hangvezérlés mindaddig nem lesz alapvető és elengedhetetlen amíg magyar nyelven nem használható. Azért mindenképpen megfontolandó, hogy szükségünk van-e hangvezérlésre. Alap angol utasításokat viszonylag könnyen el lehet sajátítani ahhoz, hogy kényelmesen ugráltassuk a virtualis komornyikot.

Én már beleestem annyira az Apple ekoszisztémájába iPhone, iPad és Mac használókén, hogy kézenfekvő volt a Homekit használata. Akármi is legyen a választás, érdemes az eszközöket úgy vadászni, hogy kompatibilisek legyenek vele, de legfeljebb egy lépésben integrálhatóak legyenek. Az alapból nem Homekit kompatibilis eszközök integrálásában nekem a HomeBridge szolgáltatás fog majd segíteni ami a Raspberry-n fut. Így hosszas irományom tárgyához el is jutottunk:

A választásom a Homekit - Raspberry kombináció.

Miért éppen a Raspberry? 

Mert ezen a mini PC-n szerettem volna az automatizált otthonom központját felépíteni. Ez az eszköz szolgál arra (legnagyobb részben), hogy fordítson a különböző protokollok között, plug in-eket tudjak telepíteni, és igy kiszolgálja a Homekit integrációt anélkül, hogy túlzottan beszűkítené az eszközeim gyártói palettáját.

Az otthon automatizálás néhány alap kérdése még hátra van, sőt, egyenesen a legfontosabb kérdés amivel érdemes kezdeni:

Mi az amire szeretnék automatizált megoldást? 

Ez azonban annyira szerteágazó téma, hogy külön posztokban és azt is első sorban az én igényeim alapján fogom végigvezetni. Persze hozzáadva olyan alap funkciókról is pár szót, amelyekkel mélyebben ezidáig nem foglalkoztam, de sokakat érinthet.

A továbbiakban egyhén eltérek majd a a szó szoros értelemben vett “okosotthon” témától, hogy a Raspberry projekt alakulását időrendben bemutassam (kódokkal, utasításokkal meg minden), hogy aztán ismét visszakanyarodjunk ide, és folytassam a nyitva maradt fonalakat.

-----------------------------------------------------------------------------------------------------------

FIGYELEM: Senkit nem szeretnék bíztatni egyik megoldásra sem. Mivel ahány ház annyi szokás, ahány szokás annyi igény, arra pedig annyi féle megoldás. Ahogyan korábban is írtam, sok plug and play megoldás létezik már, limitált eszközökkel, és magasabb árakkal, némelyik stabilabb, némelyik kevésbé. De a fenti kérdéseket mindenképp érdemes mindenkinek átgondolni. 

[ajtech]

Intro

Ez a blog azért indul, hogy egy Raspberry projektemet dokumentálja. Azért ebben a formában, hogy ha mást is érdekel a folyamat, a problémák és a megoldások akkor megtalálja az internet káoszában.

Én villamosmérnök vagyok, aki főként erősáramú beállítottságú, azonban a munkám sokszínűsége miatt foglalkozom PLC programozással is. Ahogy régi egyetemi tanárom mondaná, értek sok témához, de szakértője egyiknek sem vagyok igazán. Legalábbis magamat biztosan nem mondanám annak. Egy biztos, a Raspberry Pi és a Linux témájában kifejezetten amatőr vagyok. Így a soron következő posztok biztosan tele lesznek hibával a szakkifejezések, megoldások és azok miértjeinek terén. Emiatt előre elnézést kérek azoktól, akik valóban értik a dolgukat ebben a témában.

Szerencsére a Raspberry-k célja pont az ilyen tudatlanok tanítása (többek között), szóval annyira nem zavar ha hülyeségeket is írok majd. Azért kezdtem el, hogy tanuljak, és azért osztom meg, hogy mások az én hibáimból tanuljanak.

Mivel az egész az otthon automatizálási törekvéseimből indult, így sok szó fog esni az “okos” otthon problémáiról, eszközeiről és megoldásairól. 

Élvezzétek :)