Házi felhő és hasonló finomságok

 ( Adamyno | 2019. június 4., kedd - 18:30 )

A bejegyzést ez a fórumtéma ihlette.
Ezután nyitottam egy fórum témát én is, de ki fogja nőni a kereteket a projekt. Itt tudom folyamatosan frissíteni, így egy fokkal jobb lesz.

Amit a projektről tudni érdemes:

Lényegében egy privát felhőt szeretnék létrehozni. A cél az, hogy amennyire csak lehetséges, annyira saját kézben tartsam a saját adataim, valamint amennyire lehetséges ilyen körülmények között, annyira biztonságban is legyenek. Természetesen észszerű anyagi határokon belül.

A hardver az eddigi történetbe csomagolva:

Próbálkoztam egy Zyxel NSA325v2 NAS-al is. Egész szép eredményeket értem el, viszont egész komoly akadályokba is ütköztem. Tervezem, hogy leírom majd azt is. A lényeg annyi, hogy ledaráltam a régi 2.x verziós linuxot a vasról és feldobtam egy 5-ös kernelt egy Debian Stretch-el. Erre szépen rákerült egy OpenMediaVault. Fut rajta a samba, a Transmission, a upsd, víruskergető, smart monitorozás, stb... viszont nincs e-mail szerver (ami egyelőre nem is lesz). A vas képességei erősen korlátozottak viszont a fogyasztása egész baráti (olyan 5-8W körül van üresjáratban). A RAID1 megoldott viszont itt jönnek a problémák. A rootfs-ről biztonsági mentést csak offline állapotban tudok csinálni, szóval akkor a gépet le kell állítani, lemezt ki kell venni. Sajnos a rendszert nem tudom RAID-be tenni csak az adatokat, mivel a uBoot tudtommal nem képes kezelni raid tömböt (ellenben a GRUB-bal egy BIOS/UEFI x86 gépen). Bár ez utóbbiban nem teljesen vagyok biztos, mert az új uBoot elég jól paraméterezhető. Rá kell majd próbálni. A másik lehetőség az volt, hogy USB-ről megy a rendszer és az adatok raid-ben, a rendszerről pedig manuálisan csinálok
mentést valami hasonlóképpen:

  • time tar -cjf /media/sda1/my-rootfs.tar.bz2 . &
  • . Ez persze nem túl baráti és mivel a vas sem túl acélos (512MB ram, ARM Kirkwood proci), így ez megmarad kísérletezni. Ha minden úgy működne ahogy akarom, akkor is kellene belőle még egy.

    Szóval ma szereztem egy PC-t 5 kerek ezresért. Core2Duo valami 700-es széria, 2GB ram és jóóó kis finom SATA portok, egy alaplapi 100 megás és egy pci gigabites kártyával. Az a tervem, hogy az E szériás procit kicserélem valami P szériásra vagy ha van annál is alacsonyabb fogyasztású, akkor arra. Itt nem hiszem, hogy túlzottan nagy CPU igényes faladatok lesznek, viszont RAM-ra még lehet, hogy szükségem lesz.

    Lehet, hogy a rendszert 2 kisebb hdd-re teszem tükrözve, az adatokat pedig 2 nagyobbra. De lehet, hogy csak partíciók lesznek. Majd meglátjuk hogy adják ki a portok és a lehetőségeim.

    Célkitűzések vázlatosan:

    0. Operációs rendszer
    1. Szolgáltatások
    1a. Adattárolás, megosztás
    1b. Torrent szerver
    1c. UPS démon
    1d. SMART monitorozás
    1e. e-mail/web szolgáltatás
    2. Titkosítás
    3. Redundancia
    4. Magas rendelkezésre állás

    Utómunkálatok:
    1. Fogyasztás monitorozása, összehasonlítva a mostani NAS-al
    2. Méretcsökkentés

    Akadályok, nagy kérdések számomra:
    1. Hogyan szerzek fix IP-t otthonra (ráadásul 2 helyre is)?
    2. Ha van egy lemezem raid1-ben és cserélném egy nagyobbra később, hogyan tudok particionálni majd.

    Részletesen a tervek:

    0. Operációs rendszer, hardver
    Mindenképpen Debianban gondolkodom. Először szerintem tesztelek VirtualBoxban. Az elérést SSH-n keresztül képzeltem el, majd később ha lesz, akkor webes felületen.

    Update 2019.06.05. - 21:55
    Az otthoni gépbe bele dobtam 2 egyforma HDD-t tesztelésképpen, hogy legyen RAID(1). A Debian netinstall konzolos telepítőjét használtam. A particionálásnál vannak azért érdekes dolgok. Először mindkét lemezen új partíciós táblát hoztam létre. Utána csináltam egy md0 kötetet. Utána jött a meglepi, mert amíg nem volt raid, addig a lemezeken tudtam partíciókat létrehozni és azokat átmérezetni. Most a raid köteten már csak egy partíciót tudtam létrehozni és nem lehetett átméretezni, így egyszerűen csak a / alá csatoltam, swap nélkül, csináltam neki egy "boot" flaget. Ha jól sejtem ez azért lehet, mert igazából a partíciókat tükrözzük, nem a fizikai lemezt.(?)
    A telepítés nagyon lassú volt az előzőhöz képest. 2 dologra tudok tippelni: vagy a swap hiánya (3gb ram lett időközben) vagy a raid miatt. A telepítés végén az installer megkérdezte, hova tegye a rendszerbetöltőt. Md0 lehetőség nincs, csak a fizikai lemezeket tudtam kiválasztani. Találomra az sda-t választottam. Természetesen a gép nem indul, viszont érdekes, hogy semmi hibaüzenetet nem is ír, csak sötét képernyő a POST után. (nem LVM-ben partícionáltam)

    1. Szolgáltatások
    1a. Adattérolás, megosztás

    Itt nem csak kizárólag dokumentumok, képek, stb. tárolásáról van szó, hanem pl. névjegyzékről is, ezért ideális lenne egy olyan rendszer, amivel képes az okos eszközöm szinkronizálni.
    Az OpenMediaVault eléggé megtetszett, mert egy viszonylag egyszerű, letisztult de mégis átfogó webes felülete van, sok dolgot integráltak bele. Egyébként SMB illetve SSH/SFTP fáájlmegosztásra gondoltam, az NFS-el nincs tapasztalatom, az FTP-t már próbálom felejteni, TFTP esetleg home projektek miatt szükséges lehet de nem fontos.
    Nagyon hajlok a NextCloud irányába többek között a multiplatformos kliensek miatt illetve az átlátható, felhasználóbarát felület miatt. Sajnos tapasztalatom nincs vele, annó az OwnCloudot próbáltam de akkor még nem találtam hasznát a dolognak.

    1b. Torrent szerver
    Mindenképpen Transmission. Évek óta a barátom :) Főleg mivel multiplatformos a (remote) kliens, van normális webes felület is ha kell és a teljeskörű de viszonylag egyszerű konzolos menedzsment áll rendelkezésre. Valószínűleg ezt is az OMV-re bízom.

    1c. UPS démon
    Upsd NUT-al tökéletesen megfelel, vannak jó kis GUI kliensek is hozzá ha kell (pl. KNutClient, NUT Monitor).

    1d. SMART monitorozás
    Erről még nem tudok nyilatkozni, de jó lenne ha tudnék ütemezni néha egy-egy öntesztet és az eredményről kapnék valami visszajelzést. Az OMV-nek része.

    1e. e-mail/web szolgáltatás
    Azért írtam email/web-nek, mert a kettő igazából összefügg. Persze nem kötelező webmail a szerverre, de néha talán praktikus lehet. Szerintem mind közül ez lesz a legnehezebb méghozzá azért, mert nem lesz elég egy szerver. Kettőt tervezek 2 különböző fizikai helyen, ahol jelenleg 2 különböző szolgáltató van. Fixip kellene, mert a dinamikusnak sok hátránya van.

    2. Titkosítás
    Van egy csomó lehetőség, csak kérdés, hogy mit érdemes használni ilyen környezetben.

    Update 2019.06.05. - 21:55
    Felmerült néhány kérdés a titkosítással kapcsolatban. Debian telepítéskor van lehetőség titkosított adattárolásra. A gép indításakor mindig kér egy jelszót emiatt, ami távoli reboot esetén nem túl baráti. Gondolom ezt nem igazán lehet megkerülni. Ugyanez lenne USB kulccsal is, csak ehhez még annyi hozzá tartozik, hogy telepítés közben nem láttam lehetőségét ennek a használatára. Valaki javasolta, hogy a /boot partíció külön legyen, azt nem kell titkosítani. Az által viszont a rendszer nem manipulálható? Azt nem kérdezem, hogy a jelszavam vagy kulcsom ott tárolódik-e, mert elvileg maga a jelszó illetve a hardver a kulcs viszont mégiscsak van ott valami, ami az OS-t indítja.

    3. Redundancia
    RAID1 tömbre gondoltam. Külön partíción (vagy lemezeken) a rendszer és külön az adatok. Tudtommal a GRUB kezeli a kötetet, ha egyik lemez meghibásodik, képes elindulni a gép a másikról is. Ez majd a gyakorlatban kiderül hogyan működik. A kicsi kérdés az, hogy mi van ha megáll egy lemez és kicserélem másikra. Ha jól emlékszem, automatikusan elkezd szinkronizálni csere után. A nagy kérdés pedig az, hogy mit kell tenni akkor, ha fogytán a tárhely és cserélni akarom a meghajtókat nagyobbra.

    Adatmentésre rsync és tar majdnem elegendő a két eszköz között. Adatbázis szinkronizációra nem, viszont tudtommal az (my)sql parancsokkal megoldható.

    Update 2019.06.05. - 21:55
    Ezzel kapcsolatban is felmerült egy kérdés. Több helyen is olvastam, hogy vagy csak az adatokat, vagy a /boot partíciót is raid-be rakjuk, de utóbbi esetén külön-külön. Jelenleg nem tudom elképzelni sem, hogy ha tükörben van 2 lemez azonos tartalommal és bármelyiket kiveszem, akkor a másikról ugyanúgy fut/indul a rendszer. A BIOS boot order még okés, ott beállítok egy sorrendet, ha nincs A, jön a B. Még a 2 lemezen a 2 különböző bootloaderrel sem lenne gond, viszont kérdéses, hogy ha a rendszer is tükrözve van (egyáltalán lehet-e?) akkor képes-e elindulni ha A helyett a B lemez van csak. Ha jól tudom, az /etc/fstab fájlban lehet a partíciókra flag-el is hivatkozni illetve dev-by-name vagy valami ilyesmi az uuid helyett, így elvileg nem okozhat gondot de ha van 2 lemezem, mindegyiken van egy BOOT flag-es partíció vagy egy /boot, és eljut addig a rendszer, hogy már olvassa az fstab-ot, akkor honnan tudja melyik lemezről folytatódjon a művelet. Gondolom amelyiken megkezdődött, azon megy tovább a boot folyamat mert elvileg a BIOS/UEFI már kiválasztotta a lemezt, a bootloader bootolhatna másik lemezről/partícióról, de.... áhhh na itt már teljesen belekeveredtem. Ennek alaposan utána kell nézzek.

    4. Magas rendelkezésre állás
    2 lehetőség van most a fejemben.
    1. Dinamikus IP-vel. Van egy MikroTik routerem. Egész jól paraméterezhető. Legyen ez a másodlagos hely. Mindegyik helyen van dyndns domain név. Pl. hely1.noip.com és hely2.noip.com. A MikroTik router pingeti a hely1.noip.com-ot. Amíg az működik, addig a másik eszközt a hely2.noip.com címen érem el. Viszont ha nem kap választ X ideig, akkor a hely1.noip.com domain alá is beregisztrálja a saját címét, így minden működik tovább, mintha misem történt volna. Ha a hely1 újra elérhető, vissza tudja venni a címét a hely2-től (ezt most itt nem részletezem). Ha a hely2 megáll, akkor viszont a hely1 küld egy értesítést nekem, de nem fogja átvenni a címét.
    2. A két fizikailag különálló helyen 2 különböző fix IP van, ezek sorban 2 MX rekordba kerülnek a domain alatt és problem solved. A gond ezzel még mindig az, hogy honnan veszek fix ip-t otthonra :)
    Gondoltam arra is, hogy ha létezik olyan hely, akkor berakom a vasakat fizikailag és mégiscsak az én gépem a saját rendszeremmel, ők pedig csak helyet, áramot és ip címet adnak.

    Itt tartok most.
    Ha valami változik, frissítem a leírást.
    Most éppen virtuális gépet készülök összedobni homokozónak.

    Update: (e-mail)
    Találtam egy projektet. Azt hiszem pontosan valami hasonló hajtotta a fejlesztőit:
    https://github.com/sovereign/sovereign

    Ha valakinek van vele tapasztalata, ne tartsa magában.
    Mindenesetre regisztráltam egy domaint és előfizettem egy alap VPS szolgáltatásra.
    A többi hamarosan alakul...

    Update 2019.06.05. - 9:30
    A cloud.hu-n vettem egy domaint (adamyno.eu - .hu-val szerintem jobban jártam volna) és egy VPS-re előfizettem (a legolcsóbb kezdésnek).
    A VPS-en Debian fut. Próbáltam elérni ssh-n a domain névvel de nem megy és jelenleg fogalmam sincs mit kellene tenni, hogy elérhető legyen, mert csak néhány DNS szervert lehet megadni. Van valami alapértelmezett de szerintem az nem lesz jó. Egy webtárhelyhez képest nagyon fapadosak a lehetőségek viszont azt hozzá kell tenni, hogy soha nem volt még VPS-em így valószínűleg én csinálok valamit rosszul.

    Találtam 2 érdekes projektet a VPS-re. Az egyik a mail in a box, a másik a sovereign. Előbbi csak egy mail szolgáltatás webmail felülettel és OwnCloud a kontaktok tárolására. Utóbbi már jóval komolyabb dolog, ott a levelezéstől kezdve a csevegőn át a naptár, kontaktok, teendők, tárhely... stb. Szerintem a mail in a box elég lenne, bár az utóbbi is érdekel. Viszont XMPP szervert szerintem simán tudok létrehozni utólag is a Mail-In-A-Box mellé . Csak azért mert már a haverok érdeklődtek, hogy akkor hol leszek elérhető ha megszüntetem a Messengert és társait :)

    Mindeközben az otthoni frissen beszerzett vasra felkerült a Debian 9. Valamilyen minimal desktop környezetet felteszek majd (szerintem xfce vagy mate), sőt le fogom tesztelni hogy melyiknek kevesebb a RAM igénye. Nem egy eget rengető cucc: gigabit LAN, E7300 cpu, 2GB RAM.

    Update 2019.06.05. - 21:55
    Fut a MailInABox a VPS-en. Elsőre úgy tűnik, hogy szinte minden rendben, legalábbis ami jelen pillanatban rendben lehet. Merthogy a domainem állapotánál már egy napja ez van kiírva:
    order status: Processing
    Operation: Nameserver change

    Emiatt abszolút nem működik semmi a domainen keresztül, egyelőre csak IP-címmel. Lesz még itt sok feladat ezzel is, de egyelőre úgyis csak tesztelek mert manuálisan akarom majd összerakni a rendszert.

    Update 2019.06.08.
    Voltak gondok a VPS-el és az SSL tanúsítvánnyal is. Újratelepítettem az egészet szépen sorban, ügyelve a részletekre. Teszteltem egy csomót, már nem kerülnek a spam mappába az általam küldött e-mailek, működik a domainen keresztül az elérés rendesen (felhívtam a szolgáltatót és kb 1 perc alatt megcsinálták nekem, még pár simítás hiányzik de már a lényegi rész rendben van) és a https:// miatt sem kell a böngészővel szórakozni, mert a tanúsítványok is rendben vannak. Tervezem, hogy csinálok majd egy útmutatót külön ehhez, viszont nem hagyom ennyiben a dolgot mert igazából ezt nem én raktam össze, hanem egy telepítő szkript, amibe alig kellett belenyúlni. Később majd az összes szolgáltatást kézzel akarom feltelepíteni és bekonfigurálni, hogy tudjam mi mit csinál és hogyan működik pontosan. Ez most csak egy gyors teszt, hogy egyáltalán mire elég.
    Működik az IMAP, SMTP, az Exchange protokollt is kipróbáltam (elvileg azzal a névjegyek és a ?naptár? is szinkronizálódik) de nem szívesen használom, így leszedtem a Davx5 appot androidra szinkronizálni. Ha jó lesz, akkor a későbbiek során biztos, hogy adakozni fogok. A NextCloud része is megy, de azt nem hiszem, hogy használni fogom (akkora tárhelyem nincs, csak ~20GB körül). Csak a naptár és a névjegyzék miatt van, az e-mailek is szépen jönnek-mennek kliensekkel is, roundcube-al is (webes felület). Még a reverse DNS-t kellene beállítani de ráér. A DNS Glue record nem biztos, hogy jól van konfigurálva viszont ezt nem is tudom sajnos, hogy pontosan mire való. A DNSSEC DS record szintén nincs beállítva (nekem nincs is hozzáférésem), enélkül is működik minden de ha már van rá lehetőség, jó lenne használni.

    Most csinálok egy backupot a telefonomon, néhány apk-t lementek ami szükséges lehet (vodafone, erste, cerberus, ...), lementem az sms-eket (mert eddig a xiaomi fiókba szonkronizáltam) aztán gyalu, megy fel az AOSP. Elvileg találtam egy appot, ami IMAP-on keresztül egy külön mappába szinkronizálja az sms-eket, majd most azt is tesztelem. A végén mindenképpen lesz majd egy lista, hogy mi mivel hogyan és miért.

    Közben találtam egy olyat, hogy GNU Social /kicsit gáz, hogy nincs érvényes ssl tanúsítványuk/ (pl: gnusocial.net). Úgy nézem, hogy még magyar fordítás nincs, de ha lesz egy kis időm szerintem gyorsan lefordítom a nyelvi fájlt. Tetszetős maga a site, átlátható és nincs tele szeméttel mint a FB. Talán egy kicsit a Google+ és a Twitter keveréke. Majd meglátjuk, hogy mennyire lesz értelme. Lehet megpróbálok ebből is majd egy sajátot üzembe helyezni de ez még ráér, csak leírtam, hogy legyen meg :)

    Update 2019.06.17.
    Ott tartunk, hogy nagyjából egy hete üzemel a VPS-en egy Ubuntu 18.04 a "mail-in-the-box" társaságában. Jöttek-mentek frissítések, rebootok, de úgy tűnik, hogy stabil a cucc. Működik a cloud része is (gondolkodom is rajta, hogy a képeimet oda szinkronizáljam). A névjegyek is szinkronizálódnak, igazából csak az sms-ek mentését kellene megoldani. A későbbiek során még majd lesznek felmerülő kérdéseim ezzel kapcsolatban, de jelenleg a szolgáltatás használható.

    Mobil oldalon Havoc OS-t tettem fel (AOSP alapú) mert elég részletesen konfigurálható. Jelen pillanatban úgy tűnik, hogy a pico GApps-ot nem igazán tudom elkerülni. Vannak ötletes megoldások, de sok kérdés van még függőben. A szoftverekről majd később írok, még tesztelem. Dióhéjban annyit egyelőre, hogy lesz amiről le kell mondanom, de nem igazán fáj a dolog. Amit nem tudok natív appal megoldani, sok esetben egy webes link a kezdőképernyőre megoldja.

    Arra gondoltam, hogy külön topikba teszem majd a mobilt, a NAS-t, a VPS-t és a kis "home servert", aminek végtére is ugyanaz lesz a feladata, mint a NAS-nak.

    Hozzászólás megjelenítési lehetőségek

    A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

    s

    [Feliratkozás]

    +1

    +1

    Esetleg megfontolhatod azt is, hogy az egeszet Dockerizalod. Nekem masfel eve fut ugy az otthoni "cloud"-om. A host rendszerre (alap Ubuntu server) igazabol csak par plussz csomag van felteve: docker, mc, nfs-kernel-server, nmap, smartmontools, htop, iotop, iftop.

    En SSH/SFTP hasznalataval masolom fel ra a dolgaim a laptop-rol, majd innen osztja tovabb SMB-n a RPi-n futo OSMC-nek. Itt, valoszinuleg, nincs teljesen rendben a konfiguralas, mert a halozaton nem jelenik meg, de ugyis fixen be van mappelve. (Valoszinuleg meg kellene valamit atiranyitani a docker container-nek, vagy hianyzik csomag a docker image-bol).

    NFS-t a host rendszer biztositja, mert ahhoz, hogy docker-ben menjen szukseg volt host oldali NFS tamogatasra is. Igy pedig nem lattam ertelmet dockerizalni, ha a host oldalon ugyis fenn van minden hozza. Igazabol ezt csak a RPi hasznalja root filerendszernek. Mondjuk, itt jol fogna egy UPS, mert aramszunet eseten a RPi gyorsabban elindul, mint a szerver, igy nem tudja felmountolni a root filerendszert. Ilyenkor manualisan ujra kell inditanom a RPi-t.

    En Nextcloud-ot hasznalok a fontosabb adatot szerver-laptop-telefon kozti szinkronizalasara, valamint masokkal valo ideiglenes megosztasra. Szinten ezt hasznalom jelszavak tarolasara is. Azon kivul meg ide szinkronizalja a telefon a kovetkezo dolgokat: nevjegyzek, naptar, notes, sms es a fotokat is automatikusan feltolti ide.

    Torrent nalam is Transmission, sajat Dockerfile alapjan keszitett docker image-bol, webes feluleten kezelve.

    Fut a kis hazi "okos otthon" rendszerem server resze: 2 helysegben 1-1 NodeMCU meri a homersekletet es a paratartalmat, valamint a nappaliban vezerli a gazkazant is a homerseklet fuggvenyeben. Ezek kuldik ennek a rendszernek az aktualis allapotot, amit web-es feluleten lehet nyomon kovetni.

    Fut meg gitolite es gitweb (szinten sajat Dockerfile alapjan), a hobby projekteket tarolni.

    Van keszitve egy rclone image is, hogy tudjam titkositva backup-olni az adataimat OneDrive-ra.

    Van egy docker image, amiben backup scriptek vannak: mentest keszit a git repokrol, exportolja Nextcloud-bol a kalandar esemenyeket es a nevjegyzeket, dump-olja az "okos otthon" adatbazisat, valamint letolti a Garmin weboldalarol a track-eket.

    Van egy docker image certbot-nak, frissiteni a Let's Encrypt-es tanusitvanyt.

    Vegul pedig egy Apache alapu reverse proxy, hogy minden webes dolog HTTPS moge keruljon.

    Ritkan van aramszunet, es nem is is letfontossagu szolgaltatasok, igy UPS es SMART monitorizalas nincs. Idonkent ra-ra nezek, hogy milyen allapotban vannak a diskek.

    Email egy olyan dolog, amit nem hiszem, hogy tudnek teljes biztonsaggal uzemeltetni, na meg nincs is otthon fix IP-m. Azonban arra is vannak kesz Docker alapu megoldasok (ha megbizol bennuk): mailu, mailcow.

    Titkositas nalam annyi, hogy kivulrol minden HTTPS es SSH/SFTP. Halozaton belulrol pedig a SMB csak readonly, egy kulon ures folder van csak RW megosztva. Halozaton belulrol is csak SSH/SFTP segitsegevel masolok fel tartalmat.

    Redundancia es magas rendelkezesre allas nem igazan szempont. Siman belefer, ha par napot is all. Mondjuk a masfel ev alatt, nem tudom, ha volt 1-2 napnal tobb kimaradas. A nagyon fontos adatok megvannak 5 helyen (szerver, laptop, telefon, kulso HDD, OneDrive), a csak siman fontos adatok 3 helyen (szerver, kulso HDD, OneDrive)

    Biztos akad, aki szerint hulyeseg, de szamomra bevalt ily modon. Mondjuk szempont volt az is, hogy meg akartam ismerkedni kicsit a Docker-el, es ahhoz jol fogott egy konkret cel, amit meg akartam valositani vele. Egy masik nagy elonye a dockerizalasnak (szamomra), hogy kenyelmesen tudok kiprobalni uj dolgokat, anelkul, hogy uj csomagokat kellene installalnom a host rendszerre. Majd pedig konnyen el tudom dobni oket, ha mar nincs rajuk szuksegem. Mig volt MacBook-om, addig futott egy timemachine container is. Teszteles erejeig futott Redmine es OpenProject is. Tudom a sajat projektjeimet is futtatni, anelkul, hogy NodeJS-t es PHP-t kellene installalnom a serverre.

    Minden szolgaltatashoz van egy manage.sh file, benne build/init/start/stop/restart parancsokkal, es az egesz be van teve egy git repoba az esetlegesen szukseges Dockerfile-okkal egyutt. Igy igazabol viszonylag egyszeruen tudom kezelni oket. A frissitesek annyibol allnak, hogy ujra build-elem a Dockerfile-t, vagy modositom a hivatkozott docker image verzio-jat.

    Nagyon rejtett sub, na meg hatha kapsz otleteket belole :}


    Sic Transit Gloria Mundi

    bookmark

    -----
    „Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
    rand() a lelke mindennek! :)
    Szerinted…

    Sub

    +1sub

    Ha jól értem, ez egy sokfunkciós szerver lesz. Mitől felhő?

    Üdv,
    Marci

    A felhőt értsük idézőjelben, viszont az eredeti terv szerint csak az e-mail/kontaktok mennek a VPS-re, a fájlok és a többi bizbaz 2db fizikailag különálló helyre.
    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    Az Amazon elég olcsón ad néhány szolgáltatást, amivel ki tudnál váltani párat a listádból. A villanyszámlán kívül jelentős mennyiségű időt is meg tudnál spórolni.

    Ami a megbízhatóságot illeti a személyes adatok védelmével kapcsolatban, rengeteg globális vállalat használja a szolgáltatásaikat és nyilván üzleti titkokat is tárolnak ott. A versenytársaik is használják a szolgáltatásaikat, nincs olyan, hogy kihasználják és magukhoz láncolják a szolgáltatásaik révén az ügyfeleket, bizalom nélkül az egész infrastruktúra nem működne és ezt ők is tudják. Ráadásul zónák alapján tárolsz adatokat, szóval Washingtonban nem kérhetik ki csak úgy az adataidat egy bírósági papírral.

    Nagyon sok szolgáltatásuk ingyenes és attól függően, hogy mit akarsz (igen, végigolvastam :)), rendszerek karbantartását és konfigurálását is megspórolod és a biztonságról is gondoskodnak.

    Persze a barkács-szenvedélyből valamennyit elvesz, de nem mindent.

    Megfontolandó amit írsz, viszont az Amazon számomra eléggé átláthatatlan. Valószínűleg elég lenne egy VPS, ami a jövőre nézve esetleg skálázható.

    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    Igen, az AWS brutális szolgáltatáscsomagot ad, neked annak elég az 1%-a. Főleg az EC2.

    --
    arch,ubuntu,windows,android
    zbook/elitebook/rpi3/motog4_athene

    Mdadm RAID helyett kipróbálhatod a ZFS-t is. Értelmes leírás telepításről, beállításról pl. itt. Dedikált NAS-ra esetleg FreeNAS, ami szintén ZFS-t használ. Jó, tudom, a 2GB RAM nem sok ZFS-nek, de kis finomhangolással elmegy az. Ja és a ZFS 0.8.0 verzióban már encryption is működik.

    Adattároláshoz, naptár-, címtár szinknronhoz +1 a NextCloud-nak.

    Torrent szervehez tippek automatizáláshoz: Flexget, Sonarr, Radarr, Lidarr, Jackett

    Titkosításhoz: dm-crypt full diszkhez, EncFS ha csak kisebb dolgokat szeretnél elrejteni. Egyéb ötletek a kiváló archwiki-ben: https://wiki.archlinux.org/index.php/Disk_encryption

    Fix IP-hez: fix IPv6 címet könnyen szerezhetsz magadnak HE.net tunnerbroker. Ezt össze-VPN-ezed magadnak egy VPS-en keresztül pl. Ha nem is tökéletes megoldás, legalább jó móka felfedezni az IPv6-ot.

    Csevegésre: Matrix és Riot páros. Fényévekkel jobb mint az XMPP, persze több erőforrás is kell neki, mint egy mezei ejabberd szervernek, ellenben jól megy vele az aduio/video chat is.

    Végül pár hasznos szoftver tipp-gyűjtemény. Volt még pár ilyenem bookmarkolva, de most hirtelen csak ezeket találom.
    https://github.com/Kickball/awesome-selfhosted
    https://github.com/trimstray/the-book-of-secret-knowledge

    Ja és +1 a docker-nek is. Mint kolléga is írta feljebb, dockerizálj mindent, egyszerűbb lesz az életed.

    Én azt sose értettem, hogy miért kell egy protokollban/alkalmazásban kezelni a chatet és a hívást miközben szinte semmi közös nincs bennük. Próbálkoznak ezzel mindenfelé, pl. XMPP-Jingle, SIP-SIMPLE, de gyakorlatilag minimális haszna van ezeket összegyúrni. Az XMPP+OMEMO és a SIP+ZRTP együtt mindent tud ami a modern kommunikációhoz kell.

    Egy chat protokoll azon műlik, kivel mire tudod használni. Ha a kérdező épp most menekül a Google-től, és valami új protokollt keres pl. a családi csevegéshez, szerintem a mátrixxal jobban jár. Az XMPP sem rossz dolog, használtam is sokáig, csak aztán nem volt kivel, nehezen integrálható bármivel, nincs hozzá szimpatikus mobil kliens, de a desktop kliensek is hogyismondjam... nem fiatalosak. A mátrix filozófia pedig hogy egyszer majd az összes chat protokollt natívan integrájla magába (na igen, ezen egyelőre magam is mosolygok, de a kezdeményezés és az eddigi eredmények nem rosszak). A WebRTC alapű audio/video chat meg valahogy nagyobb népszerűségnek örvend, mint az egzotikus XMPP kiterjesztések vagy a SIP integráció.

    A mátrix filozófia pedig hogy egyszer majd az összes chat protokollt natívan integrájla magába

    Valahogy a Pidgin is így indult annó nem?
    A mai napig használom egyébként, mert sok jó funkciója van, csak eljárt az idő felette. Főleg az tette be a kaput, amikor a Hangouts és a Facebook kikapcsolták az XMPP protokollt. Viszont néhány hete valahogy a Hangouts működött vele, de fogalmam csincs mit csináltam és hogyan :D
    Sajnos most nem tudom újra működésre bírni vele.

    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    Nem működik? Én azóta is használom a Pidgint Hangoutssal. Néha kell neki pár perc, hogy kapcsolódjon, de megy.

    -----
    „Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
    rand() a lelke mindennek! :)
    Szerinted…

    Ha jól emlékszem, valami ilyesmit be lehet állítani a Google fiókbeállításokban, hogy elavult kliensek támogatása és az ki van kapcsolva nálam, emiatt különböző protokollok már nem támogatottak, köztük az XMPP sem. De ebben nem vagyok biztos még egy próbát teszek (lehet nem vártam eleget) de már csak érdekességképpen mert bár a google mail fiókomat nem szüntetem meg, de rövidesen elhagyom.

    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    Ez egy igen hasznos kis ötlet doboz volt. Már jönnek is az újabb kérdések a fejemben főleg a VPS-VPN témát kezdtem túlgondolni. A dockertől félek. Nem igazán tudom mi az és lehet, hogy hirtelen sok lenne. Amikor homeAutomation-t csináltam, ott foglalkoztam vele de csak érintőlegesen, mert már össze volt rakva a rendszer magja, a többi meg más felületén ment.
    Azért majd ránézek. Én kis naiv, úgy gondoltam hogy max. 1 hónapon belül megoldok mindent. De nem baj mert végre valami ami érdekel és látom értelmét :)

    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    Ezért is javasoltam korábban a Proxmox-ot. Nem parancssor Docker és ZFS guruknak is webes felületen könnyebben összekattintgatható benne az LXC alapú konténer vagy VM. ZFS benne, meg még sok minden. És egy Debian az alap, így kb. minden másra is alkalmas amire egy Debian. A VM, CT gépeket könnyű menteni belőle hálózati megosztásra (SMB,NFS). Debian alap telepítés és utána rá a Proxmox is megy ha éppen így kell, mint az OMV-nél. Jó a dokumentációja.

    Megnézem :)

    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    Adamyno írta:
    Update 2019.06.05. - 21:55
    Ezzel kapcsolatban is felmerült egy kérdés. Több helyen is olvastam, hogy vagy csak az adatokat, vagy a /boot partíciót is raid-be rakjuk, de utóbbi esetén külön-külön. Jelenleg nem tudom elképzelni sem, hogy ha tükörben van 2 lemez azonos tartalommal és bármelyiket kiveszem, akkor a másikról ugyanúgy fut/indul a rendszer. A BIOS boot order még okés, ott beállítok egy sorrendet, ha nincs A, jön a B. Még a 2 lemezen a 2 különböző bootloaderrel sem lenne gond, viszont kérdéses, hogy ha a rendszer is tükrözve van (egyáltalán lehet-e?) akkor képes-e elindulni ha A helyett a B lemez van csak. Ha jól tudom, az /etc/fstab fájlban lehet a partíciókra flag-el is hivatkozni illetve dev-by-name vagy valami ilyesmi az uuid helyett, így elvileg nem okozhat gondot de ha van 2 lemezem, mindegyiken van egy BOOT flag-es partíció vagy egy /boot, és eljut addig a rendszer, hogy már olvassa az fstab-ot, akkor honnan tudja melyik lemezről folytatódjon a művelet. Gondolom amelyiken megkezdődött, azon megy tovább a boot folyamat mert elvileg a BIOS/UEFI már kiválasztotta a lemezt, a bootloader bootolhatna másik lemezről/partícióról, de.... áhhh na itt már teljesen belekeveredtem. Ennek alaposan utána kell nézzek

    Engedd meg, hogy erre röviden reagáljak. Megpróbálom felvázolni a boot leegyszerűsített folyamatát.

    Szóval, a Linux bootolása úgy történik, hogy a BIOS/UEFI kiválasztja a megfelelő fizikai lemez eszközt, aminek BIOS esetén betöltődik az MBR rekordja, ami átirányítja az ugyanazon eszközön belül levő boot partición lévő bootloader kódra a vezérlést, UEFI esetén viszont a teljes bootloader betöltődik. És pont, ezen a ponton a Linux bootfolyamatának függése a BIOS által kiválasztott boot eszköztől véget is ér, innentől csak és kizárólagosan a bootloader konfigurációja az irányadó. A GRUB 2 konfigurálható úgy, hogy adott UUID-ű partíciót keressen, erről töltsön kernelt és initrd-t, vagy meg lehet adni neki a BIOS által felismert lemezek listájabeli sorszámot is a kernel és initrd lokalizálására. Fontos látni, hogy nem evidencia az, hogy a bootloader arról a lemezről bootoljon kötelezően, melyről a BIOS/UEFI eredetileg betöltötte akár az MBR-t, akár a bootloadert.

    Az fstab a bootloadertől független valami, a bootloader nem is foglalkozik vele, ezt már az adott operációs rendszer (esetünkben a Linux) olvassa fel a saját inicializációs folyamata során, ugyanis a bootloader nem csatolja fel a boot particiót, csak beletúr és előszedi a kernel-t és az initrd-t. Ez azért van így, mert a "felcsatolás" mint olyan, az - leegyszerűsítve - a Linux kernelben végremenő regisztrációs folyamat, viszont a boot folyamatnál a Linux kernel még egyáltalán nem egy üzemelő valami, hiszen azt épp most olvassuk fel a lemezről. De nem is szükséges a bootloaderhez a Linux kernel, mivel az önmagában egy önálló pici "operációs rendszer", bár erősen korlátozott tudással.

    Amikor a bootloader betöltötte és elindította a Linux kernelt, a legtöbb esetben egy inicializációs szkript indul el, ami az fstab és más konfigurációs fájlok alapján összerakja a szoftveres (mdadm, dm-raid) RAID-eket, felcsatolja a megfelelő fájlrendszereket, és elindítja a különféle szolgáltatásokat.

    Ami miatt fontos, hogy a fájlrendszerek meghivatkozása egységes módon történjen, az egyfelől a konfiguráció konzisztenciája, másfelől pedig az, hogy bizonyos, a bootloader és más cuccok frissítésekor lefutó userspace szoftverek az fstab alapján építik fel az fstab-tól amúgy független konfigurációjukat. Érdemes tehát UUID/LABEL alapon gondolkodni az eszközök megcímzésénél, mert ez függetlenné teszi a bootfolyamatot attól, hogy fizikailag hova dugod az adott lemezeszközt. Simán lehet, hogy portalanításkor kiveszed mindkét RAID diszket, de véletlenül fordított sorrendben teszed vissza őket, ha UUID vagy LABEL alapú elérést használsz az fstab-ban és a GRUB 2-ben is, akkor semmilyen problémád nem származik a bootoltatás során (amennyiben gondoskodva van arról, hogy BIOS esetén az MBR, EFI esetén pedig az EFI partíció tartalma fenn legyen mind a két diszken, EFI partició esetén a tartalomnak is meg kell egyeznie, viszont ez a partició NEM lehet szoftveres RAID tömbön, az eltérő particiótípus-azonosító flag miatt (szerencsére az EFI partíció tartalma alig változik a gép életciklusa során, elég egy scripttel napi szinten szinkronban tartani)).
    --
    Blog | @hron84

    "valahol egy üzemeltetőmaci most mérgesen toppant a lábával" via @snq-

    Ez nagy segítség volt! Köszönöm!

    Így gondoltam én is, csak nem tudtam ennyire rendezetten megfogalmazni.
    Tehát mivel a Linux a kernel indulása után rakja össze a raid kötetet, így a /boot partíciót (mivel azon van a kernel és az initrd) ne rakjam raidbe. Akkor arról a partícióról kézzel/scripttel kell másolatot készíteni a másik lemez /boot partíciójára?

    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...

    tudsz csinalni tavoli unlockot is: kell dropbeart (dropbear-initramfs + dropbear-bin) telepiteni, majd megadod hogy bootolaskor milyen ipt huzzon fel maganak a kernel (password beadas utan leszedi az ip, igy lehet akar fuggetlen cim, kulon ssh host key-ekkel): /etc/initramfs-tools/initramfs.conf fajlba:
    IP="192.168.200.123::192.168.200.1:255.255.255.0::eth0:off" (de lehet dhcp is, use google)
    A /etc/dropbear-initramfs dirbe kell tenni az ssh server kulcsokat, meg az authorized_keys fajlt.
    ezutan telorol be tudsz loginolni, es kerni fogja a feloldo jelszot.
    Ha tobb disked van akkor vagy annak is keri a jelszavat, vagy azokra beallitasz keyfajlt (random tartalommal, ne a derivated key modszerrel) , tarolhatod a kodolt /etc/-n belul, igy csak 1 jelszot fog kerni.

    --
    A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

    Köszi!
    ---
    - Indítsd újra a gépet! - Az egészet? - Nem, a felét...