Prešli smo na novi TLS certifikat … i malo o TLS (i https)

Možda niste niti svjesni činjenice kako je određene promjene uveo Google Chrome web preglednik, od inačice 58, a koje će vrlo vjerojatno i drugi slijediti.  Naime radi se o tome kako se novi Chrome striktno drži standarda RFC 2818. Ovdje se radi o novom standardu za HTTPS komunikaciju, odnosno definiciji kako se treba, odnosno mora,  koristiti TLS (Transport Layer Security ), koji je usput rečeno, naslijedio SSL (Secure Sockets Layer) protokol, kao standard za kriptiranje podataka za HTTP protokol.

Za one kojima nije jasna ova poveznica, zamislite TLS kao tunel kroz koji prolaze samo i isključivo kriptirani (zaštićeni) podaci, od i prema HTTP protokola odnosno od i prema web poslužitelju.

Dakle HTTPS u radu se oslanja na TLS tunel kroz koji se primaju i šalju kriptirani podaci, koji kada se dekriptiraju, postaju standardni (normalni) HTTP promet. Nekriptirani, odnosno nezaštićeni HTTP podaci se nikada ne šalju preko mreže, već se kriptiraju i šalju, pa ih dekriptira svatko za sebe, kako ih prima:

  • HTTP(S) poslužitelj sa svoje strane
  • klijent (web preglednik) sa svoje strane.

Dakle i klijent i poslužitelj zapravo komuniciraju normalnim HTTP protokolom jer se TLS komunikacija događa na jednoj razini ispod. Možemo reći to i ovako: HTTP komunikacija prolazi kroz TLS kriptirani tunel:

Klijent (HTTP)  <== ==> Klijent (TLS tj. HTTPS) <– –> Mreža (Internet) <– –> Poslužitelj (TLS tj. HTTPS) <== ==> Poslužitelj (HTTP)

 

Kako se odvija komunikacija prema HTTPS protokolu, odnosno TLS dio

  1. Klijent (web preglednik) šalje „ClientHello“ poruku, koja sadrži sve potrebno za buduću komunikaciju, a između ostalog i:
    1. Listu algoritama za kriptiranje i razmjenu podataka i ključeva koje podržava (poznate pod nazivom cipher suites )
    2. Maksimalnu verziju SSL ili TLS protokola koje podržava

 

  1. Poslužitelj odgovara sa svojom „ServerHello“ porukom, te na osnovi svoje konfiguracije odnosno postavki, odabire:

a.) Algoritam za kriptiranje i razmjenu ključeva (cipher suites) – koje dozvoljava, a klijent podržava

Ova opcija se nalazi u konfiguraciji (datoteka: ssl.conf za Apache web poslužitelj), pod parametrom: SSLCipherSuite (u njoj se navodi sve što dozvoljavamo/ne dozvoljavamo od protokola ). Pogledajte jedan primjer:

b.) Maksimalnu verziju SSL odnosno u novijim verzijama TLS protokola, koje dozvoljava, a klijent podržava.

 

  1. U ovom koraku, poslužitelj dokazuje svoj identitet klijentu pomoću certifikata. Certifikat sadrži razne podatke, poput :
    1. Imena poslužitelja i domene (pr. opensource-osijek.org)
    2. Javnog ključa za asimetrično kriptiranje/dekriptiranje
    3. Digitalnog potpisa
    4. Datuma izdavanja certifikata te datuma valjanosti certifikata (pr. vrijedi do 3.8.2017)
    5. I na kraju, institucije odnosno „autoriteta“ koji je ovaj certifikat dodijelio poslužitelju
  2. Klijent prima certifikat te provjerava vjerodostojnost istoga. Prvo provjerom vjerodostojnosti institucije (autoriteta) koja mu je izdala certifikat. Ovdje se radi o CA (Certificate Authority), koji ima pravo izdavati ovakve certifikate – u našem slučaju je to Let’s Encrypt, a koji je, kao i svi drugi CA, ove razine, provjeren od strane vršnih
    1. Prvo klijent (web preglednik) provjerava, da li mu se u njegovoj listi CA (a koja dolazi s instalacijom svakog web preglednika), nalazi i CA, od kojeg je došao i certifikat poslužitelja na koji se spajamo.
    2. Ako ovaj CA, nije u listi web preglednika, provjeravaju se CA-ovi koji su u toj listi te se kod njih provjerava, da li smo od nekoga od njih dobili naš certifikat. Ova lista se zapravo sastoji od dvije liste :
      1. root CA (odnosno vršne certifikacijske „institucije“)
      2. intemediate CA (odnosno svi oni niže razine, koji su naravno certificirani kod nekog od root CA).

Svako malo, vršni CA, provjeravaju certifikate CA-ova niže razine (kojima su dodjeli certifikate).

 

Zadnji korak je razmjena ključeva,

Prije kriptiranja kanala, prvo se moraju razmijeniti ključevi za kriptiranje, na siguran način, kako netko tko potencijalno prisluškuje komunikaciju ne bi mogao “upasti” u komunikaciju koja bi trebala biti zaštićena . Razmjena ključeva može se odraditi na dva načina – metode  1  ili 2 (dolje). Dakle pošto se klijent odlučio za algoritam i druge parametre, on ovisno o odabranom algoritmu za kriptiranje, odabire metodu razmjene ključeva:

  1. Key encipherment metoda:
    1. Klijent kreira simetrični ključ
    2. Kriptira simetrični ključ sa poslužiteljevim javnim ključem. Samo ga poslužitelj može dekriptirati jer jedino on ima privatni ključ s kojim ga može dekriptirati (ovo sada  je asimetrična metoda)
  2. Key agreement (sigurnija metoda)- koristi se Diffie-Hellman (DH) metoda, a koja se koristi  i kod drugih protokola – pr. SSH , ili raznih vrsta VPN konekcija. DH je opisan u RFC2631. U imenu cipher suitea, DH je označen i kao EDH (Ephemeral Diffie-Hellman) ili DHE te EECDH (Ephemeral Elliptic Curve Diffie-Hellman) . Pogledajmo i kako to radi:
    1. Klijent i poslužitelj razmjenjuju vrlo velike prim brojeve (Tzv. p i g) te rade određene računske operacije s njima te potvrđuju rezultat kao provjeru autentičnosti.
    2. Klijent šalje svoj javni DH ključ na poslužitelj
    3. Poslužitelj izračunava tajni „session“ ključ na osnovu svog privatnog ključa i koristi klijentov javni ključ za kriptiranje – te ga šalje klijentu
    4. Poslužitelj šalje svoj javni DH ključ klijentu
    5. Klijent izračunava tajni „session“ ključ na osnovu svog privatnog ključa i koristi poslužiteljev javni ključ za kriptiranje – te ga šalje poslužitelju
    6. Sada obije strane imaju ključeve pomoću kojeih se kriptira kanal za komunikaciju.

Za detalje oko procesa komunikacije, kod uspostavljanja kriptirane (HTTPS) veze, pogledajte :

https://en.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake

 

 

 

Vratimo se na RFC2818

Prema ovom standardu, ime računala (Hostname) definirano u certifikatu mora biti zapisano korištenjem SAN (Subject Alternative Name) unosa, a ne kako je prije bilo slučaj, korištenjem CN (Common Name) unosa.

Za one koje zanima više detalja o SAN unosu, pogledajte RFC 3280, poglavlje : 4.2.1.7

 

S obzirom da je naš CA (Certificate Authority) – odnosno tvrtka od koje smo dobili TLS/SSL certifikat koristio CN, a ne SAN unos za naš certifikat odlučili smo se za određene promjene.

 

Nakon malo istraživanja, odlučili smo se za drugi CA (Certificate Authority) – Let’s Encrypt. Let’s Encrypt je slobodan, automatiziran i otvoren CA (Certificate Authority) koji je pokrenut za javno dobro, od strane ISRG  (Internet Security Research Group).

Već nakon nekog vremena ovu organizaciju su počele sponzorirati, kako neprofitne tako i profitne male ali i velike tvrtke.

Ako pogledate listu glavnih sponzora, postati će vam jasan naš odabir:

Dodatno, ono što je vrlo važno je i kompatibilnost ovih certifikata sa svim važnijim web preglednicima:

  • Mozilla Firefox >= v2.0
  • Google Chrome
  • Internet Explorer on Windows XP SP3 and higher
  • Microsoft Edge
  • Android OS >= v2.3.6
  • Safari >= v4.0 on macOS
  • Safari on iOS >= v3.1
  • Debian Linux >= v6
  • Ubuntu Linux >= v12.04
  • NSS Library >= v3.11.9
  • Amazon FireOS (Silk Browser)
  • Cyanogen > v10
  • Jolla Sailfish OS > v1.1.2.16
  • Kindle > v3.4.1
  • Java 7 >= 7u111
  • Java 8 >= 8u101
  • Blackberry >= 10.3.3

 

A i činjenica kako ga sada koriste i mnogi veći igrači.

 

Važno je znati kako je valjanost ovih certifikata 90 dana. Naravno nakon tog vremena potrebno ih je osvježiti. Let’s Encrypt, koristi  ACME protokol i pripadajuće ACME klijente, kako za kreiranje certifikata, tako i za njihovo osvježavanje.

ACME klijenata ima cijeli niz – pogledajte link.

Mi smo se odlučili za acme.sh – klijent u potpunosti napisan samo korištenjem shella (pr. bash),  bez potrebe za bilo kojim dodatnim bibliotekama ili drugim alatima ili programskim jezicima. Odluka je pala ne njega zbog jednostavnosti i činjenice kako ga koriste mnoge tvrtke u čiji odabir imamo puno povjerenje. Pogledajte listu korisnika acme.sh -> LINK.

acme.sh ažurira certfikat jednostavnim dodavanje u cron, za svaki dan. Dakle svaki dan se provjerava je li certifikat istekao, i ako je, povlači se novi, te se restarta web poslužitelj (za cca 89 dana ćemo vidjeti da li to radi automatski J ). Ovo bi trebala biti KISS metoda koja provjereno radi .

Što se instalacije i konfiguracije tiče, sve je teklo glatko, prema uputama :

https://github.com/Neilpang/acme.sh

 

Osnovna konfiguracija web poslužitelja

Osim standardnih dijelova za konfiguraciju SSL/TLS dijela, dio koji se odnosi na certifikate je slijedeći – govorimo o Apache web poslužitelju.

Napomena: SSLCertificateChainFile se više ne koristi već se koristi:  SSLCertificateFile.

 

Dakle ovako:

 

Ovo je chain certifikat (fullchain.cer) koji ste dobili od Let’s Encrypta. Ovaj certifikat kako mu i naziv kaže (chain=lanac) certifikat je koji sadrži niz certifikata, počevši od root CA – onoga koji je opće „dozvolio“ rad našem – nižem odnosno intermediate CA (od kojega smo mi dobili certifikat), preko tog intermediate CA (ovdje je to Let’s Encrypt ) i sve do našeg certifikata (za našu stranicu za koju smo ga i tražili).

Slijedeća stavka je SSLCACertificateFile,  koristi se u slučajevima ako tražimo autentikaciju klijenata (mi ćemo i to uključiti),

Konfiguracija izgleda ovako:

 

Dakle korisitmo (ca.cer) dobiven od Let’s Encrypta.

I na kraju, naš privatni RSA ključ (private key), koji smo dobili od Let’s Encrypta. Dakle ovo je par od našeg javnog ključa (public key) – iz našeg certifikata. U našem slučaju je to datoteka : opensource-osijek.org.key

Prema tome, konfiguracija izgleda ovako:

 

 

Za one kojima još nije najbolje sjelo: simetrično i asimetrično kriptiranje

  • Simetrično kriptiranje
    • S jednim (istim) ključem se radi i (en)kriptiranje i dekriptiranje. Dakle s istim ključem zaključavate sef s podacima ali i bilo tko s istim takvim ključem može otključati sef. Simetrija u nazivu je stoga što je jedan ključ i za zaključavanje (kriptiranje) i otključavanje (dekriptiranje)
  • Asimetrično kriptiranje
    • Uvijek se generira (kreira) par ključeva, jedan privatni i jedan javni. Javni ključ se daje svima jer je to ključ s kojim se samo i isključivo mogu (en)kriptirati podaci. Dok se (en)kriptirani podaci samo i isključivo mogu dekriptirati s privatnim ključem. Dakle javni ključ se koristi za (en)kriptiranje a privatni za dekriptiranje podataka. Ovo znači i to, kako je za dvosmjernu komunikaciju, potrebno da svaka strana kreira sve svoje ključeve.
      • Strana A : svoj privatni ključ čuva a javni daje strani B (i bilo kome drugom)
      • Strana B : svoj privatni ključ čuva a javni daje strani A (i bilo kome drugom)
        • Prema tome kada strana A šalje podatke na stranu B, ona ih (en)kriptira s javnim ključem od strane B, koja ih potom dekriptira sa svojim privatnim ključem (B). Kada strana B šalje podatke na stranu A, ona ih (en)kriptira s javnim ključem od strane A, koja ih potom dekriptira sa svojim privatnim ključem (A).
    • Zbog toga i asimetrija u nazivu jer ne postoji jedan ključ za sve namjene, već su i ključevi i sam način rada asimetrični.

 

 

Autor: Hrvoje Horvat

Proxmox VE (platforma za virtualizaciju i Linux kontejnere) – novosti

 

 

Duže vrijeme nismo spominjali Proxmox VE platformu za virtualizaciju i Linux kontejnere, zapravo od zadnjeg predavanja o Proxmox VE platformi iz 6. mjeseca prošle godine.

 

 

Pošto je naš tehnološki partner (Proxmox Server Solutions GmbHProxmox) od tada napravio mnoge promjene, vrijeme je, a jednim dijelom i naša obaveza, kako bi vas upoznali s novostima.

 

 

Za one od vas koji su ostali na verziji 3.x, preporuka je prelazak na novu generaciju 4.x. Namjerno ne govorim o verziji 4.x. jer se radi o prelasku na potpuno novu platformu. I dalje je hipervizor za virtualke Linux QEMU/KVM ali se s OpenVZ Linux kontejnera prešlo na LXC Linux kontejnere. Sve ostale sličnosti su u novoj generaciji sve manje.

 

Naime stara generacija 3.x. je nasljeđivale razne tehnologije još od prije, a s novom generacijom 4.x. prešlo se na nove tehnologije ili na novije verzije starih tehnologija a koje u pravilu više nisu unatrag kompatibilne.  Jedna od tih tehnologija je poznati corosync klaster  koji se unutar Proxmox VE platforme koristi za dodavanje Proxmox VE poslužitelja u Proxmox klaster, te za sve poslove koji su vezani uz klasterski rad. Sve ovo ne bi bilo moguće bez dodatno razvijenog tzv.  Proxmox Cluster File System.

Ovaj transakcijski klasterski datotečni sustav donosi slijedeće mogućnosti (uz dodatne funkcionalnosti koje ubjedinjuje Proxmox klaster) :

  • stabilnan je (u produkcijskoj je upotrebi cijeli niz godina),
  • pouzdan je i otporan na ispade bilo kojeg poslužitelja (ili više njih – ovisno o njihovom broju),
  • distribuiran – svi poslužitelji imaju pristup svim konfiguracijskim datotekama u svakom trenutku
  • repliciranje promjena između poslužitelja u klasteru se izvodi transakcijski (pouzdano)
  • sve promjene na bilo kojoj konfiguracijskoj datoteci su vidljive svim Proxmox VE poslužiteljima u klasteru, trenutno – čim se promjena dogodila

 

Vezano za sam rad klastera i njegove mogućnosti, sada novi Proxmox VE 4.x. ima novi klaster, koji podržava rad do 32 fizička poslužitelja u klasteru, a i sam klaster radi puno jednostavnije i brže. Sve to zahvaljujući prelasku na novu generaciju corosynca (koji je naravno nekompatibilan sa starom generacijom).

 

Prelaskom na novi klaster poboljšana je i HA (High Availability) funkcionalnost za virtualna računala i/ili linux kontejnere. Dakle sposobnost Proxmox VE klastera koja u slučajevima kada imamo vrlo važne virtualke ili linux kontejnere (one koje označimo kao HA) a koji stalno moraju biti pokrenuti, da se sustav brine o njihovom “zdravlju”. Naime za takve virtualke ili linux kontejnere, u slučaju kvara ili gašenja fizičkog Proxmox VE poslužitelja, HA komponenta sustava ih automatski pokreće na drugom dostupnom (živom) fizičkom poslužitelju.

 

Kao što sam spomenuo, vezano za Linux kontejnere, prešlo se sa OpenVZ Linux kontejnera na LXC Linux kontejnere.

 

Zbog čega prelazak s OpenVZ na LXC kontejnere ?

OpenVZ linux kontejneri su stara i pouzdana te u produkciji provjerena tehnologija linux kontejnera koja se koristi desetak godina.

Ali ?!.

OpenVZ linux kontejneri su zahtijevali modifikaciju samog linux kernela te su bile potrebne i neke druge (doduše sitne) komponente i promjene. Pošto je Proxmox VE baziran na Debian Linux distribuciji, to je značilo kako se kod svake nove nadogradnje koja je došla od strane Debian Linuxa, prvo morao rekompajlirati kernel te su se morale napraviti dodatne promjene.  Osim toga ova tehnologija je zaslužila umirovljenje, barem prema odluci razvojnog tima Proxmox VE ali i mnogih ljudi koji su open source (volonteri) programeri za Proxmox VE ili su aktivni u Proxmox VE zajednici.

Odluka je bila očita: LXC linux kontejnerska tehnologija koja je postala integrirana u novije linux kernele. Dakle sve što je bilo potrebno od strane kernela, sada se već nalazilo u njemu. Prošlo je neko vrijeme i određene stvari su se ispeglale – u linux kernelu a vezane za LXC.  Naravno prve verzije Proxmox VE 4.x nisu imale sve funkcionalnosti LXC linux kontejnera, kao što su imale za OpenVZ linux konetjnere ali to je bila stvar razvoja samih LXC kontejnera i podrške unutar Linux kernela. Velika prednost odnosno jednostavnost LXC kontejnera je upotreba tzv. Linux kernel namespaces tehnologija (naravno unutar samog linux kernela).

Ovdje se radi o tehnologijama za izolaciju:

  1. procesa i njihovih mehanizama komunikacije (IPC – Interprocess Communication)
  2.  PID (Process ID)  – (PID namespace) – izolacija PID-ova pokrenutih procesa
  3. mreže i mrežnih sustava (koji se oslanjaju na tzv.  network namespace )
  4. korisnika i njihovog rada ( user namespace)
  5. kontrolnih grupa (cgroups) – za izolaciju pripadnosti kontrolnih grupa pokrenutih procesa (kontrolne grupe su zadužene za dodjeljivanje, ograničavanje i izolaciju resursa : CPU, RAM, disk I/O, mreža, …)
  6. mount namespace – zaduženih za mountanje unutar izoliranog prostora (LXC kontejnera konkretno)
  7. UTS namespace – omogućava promjene hostname i domainname unutar izolacije za različite procese

Pogled na LXC kontejner iz perspektive Linuxa iz kojeg je pokrenut (Proxmox VE) :

 

Pregled ostalih osnovnih tehnologija, koje su podržane već dugo vremena u Proxmox VE platformi:

  • Linux Bonding (Agregacija/Teaming) i VLANovi – od 07.2008.g (Proxmox VE v. 0.9)
  • live migracija KVM (Virtualke) i  OpenVZ (linux kontejneri)  – od 10.2008.g. (Proxmox VE v. 1). Slika migracija virtualke (ID: 103) s jednog (fizičkog) Proxmox VE poslužitelja na drugi:

–> 

  • podrška za VIRTIO uz dodanu podršku za  virtio_blk  (para-virtualized block devices) – od 05.2009 (Proxmox VE v.1.2)
  • novi storage model, koji podržava razne vanjske i interne storage – od 09.2009 (Proxmox VE v.1.4. beta 1):
    • iSCSI
    • NFS
    • LVM
    • DRBD
  • mogućnost dodjeljivanje CPU Socketa ili jezgri (postao je svjestan NUMA arhitekture) za virtualke  – od 09.2009 (Proxmox VE v.1.4. beta 2)
  • Uvodi se SCST podrška (na razini kernela i softvera) a koja daje brži rad te podržava više protokola : iSCSI, FC. Dodatno uvodi podršku za više storage interface-a prema virtualkama (SCSI pass-through, block I/O i file I/O) – od 10.2009.g (Proxmox VE v.1.4)
  • prelazak na qemu-kvm (KVM) za virtualizaciju (brži i optimiziraniji od QEMU) – od 01.2010.g. (Proxmox VE v.1.5) – u novije vrijeme su oba projekta spojena u jedan – QEMU
  • osim linux bond (agregacija/team),  bridge i VLAN podrške (od 2008.g.) dodana je podrška za Open vSwitch, koji je znatno napredniji i prilagođen virtualizaciji. Preko njega  su podržane iste tehnologije (bond, bridge, i VLANovi) ali i mnoge druge napredne mogućnosti – od 03.2014.g. (Proxmox VE v.3.2 )
  • … i tako dalje

Za više detalja o osnovnim i naprednijim stvarima koje nudi Proxmox VE platforma, pogledajte članak od prije : https://www.opensource-osijek.org/wordpress/2016/06/28/retrospektiva-virtualizacija-linux-kontejneri-i-proxmox-ve/

 

 

Što je još zanimljivo kod Proxmox VE platforme ?

Za većinu funkcionalnosti nije otkrivana “topla voda” već su odabrane provjerene i dokazane tehnologije i rješenja iz open source svijeta. Veliki naglasak je uvijek bio i biti će na optimalnoj upotrebi tih tehnologija, bez puno kompliciranja. Štoviše cilj je svaku potrebnu tehnologiju iskoristiti na najbolji mogući inženjerski način, uz što manje komponenti, što jednostavniji dizajn i što bolje performanse.

Ako samo pogledamo mrežni model – dizajn je jednostavan, pouzdan, brz i bez puno komplikacija i filozofija. Bez obzira koristi li se Linux model : bond, bridge, VLAN ili open vSwitch model s istim komponentama. Način funkcioniranja je nevjerojatno jednostavan za rad i održavanje ali i debuggiranje:

Dakle ovakav model je najjednostavniji mogući (ne postoji jednostavniji način povezivanja Virtualnog računala i Linux hipervizora od ovog).

Kako ne bi mislili da se išta mora konfigurirati ručno, pogledajte dio konfiguracije mreže za Virtualku:

S time kako možemo mijenjati model virtualizirane mrežne kartice:

 

LXC

Model kod upotrebe LXC Linux kontejnera je vrlo sličan samo što se ne koriste tap (virtualni interface) već veth (također posebna vrsta virtualnog interface-a ) koji se kreira u paru (na slici dolje je par : veth A1 i veth A2), poput tunela – jedna strana je unutar Linuxa ili open vSwitcha a druga unutar LXC kontejnera (koji zapravo završava unutar network namespace-a unutar LXC kontejnera ).  Ovakav par veth interaface-a se doslovno ponaša kao prolazni tunel – sve što uđe s jedne strane izađe na drugu stranu i obratno a ovo je jedini mogući način komunikacije između Linuxa i Linux kontejnera, barem što se mreže tiće. Istu metodu koristi i docker . Možda zvući komplicirano ali nema druge ili barem jednostavnije metode komunikacije od i prema Linux kontejneru, preko mreže.

Pogledajmo i logičku shemu ovakvog scenarija, s jednom fizičkom mrežnom karticom (LAN1- eth0) na poslužitelju:

Pogledajmo konfiguraciju mreže LXC kontejnera:

 

Vratimo se na virtualke

Ako pogledamo i druge funkcionalnosti, od samog pokretanja virtualnih računala, također se ne koriste nikakvi među slojevi (pr. libvirt ili sl.), kako bi se i ovdje rad pojednostavnio i ubrzao. Naime Proxmox VE, pokreće virtualna računala i to direktno iz KVM/QEMU hipervizora. Pogledajmo kako Proxmox VE pokreće jednu virtualku :

(Ovo naravno nije vidljivo iz GUIa iz kojega je zamišljeno da isključivo i radite)

 

Ovakvim načinom, bez posrednika, dobilo se na jednostavnosti, brzini ali i mogućnosti dodatnih optimizacija za svaku pojedinu virtualku. Naime konfiguracijski parametri svake virtualke se nalaze u zasebnoj datoteci na Proxmox VE linuxu, tako da je uključivanje i onih parametara ili opcija koje nisu dostupne preko GUI sučelja, jednostavno – editiranjem konfiguracijske datoteke od željene virtualke. Dodatno ako imamo Proxmox VE klaster – sve ove (i sve druge ) konfiguracijske datoteke se repliciraju na sve Proxmox VE poslužitelje u klasteru (preko već spomenutog Proxmox klastersog datotečnog sustava [pmxcfs]).

Ovime se dobilo i na pouzdanosti – nisu razvijane neke posebne metode ili programi koji su potrebni za pokretanje, praćenje i druge mogućnosti rada virtualki, već se koriste dostupne metode koje nam daje QEMU/KVM.

 

Linux kontejneri i docker (kontejner) nisu isto. Linux kontejneri (OpenVZ ili LXC) su kontejneri koji sadrže kompletan izolirani linux (točnije specifičnu, željenu distribuciju Linuxa). Ovakav Linux kontejner se ponaša slično kao bilo koja Linux virtualka  (ili računalo na koje je instaliran Linux). Razlika između Linux kontejnera i virtualke je u tome što Linux kontejner troši drastično manje resursa od virtualke te nema cijeli niz slojeva virtualizacije. Dakle na Linux kontejner možete normalno instalirati programe kao što bi ih instalirani na bilo koji linux.

S druge strane docker (kontejner) je kontejner za aplikacije, unutar njega se pokreću aplikacije/programi, kojima je Linux koji se vrti negdje “ispod haube” nevidljiv. Docker također koristi istih sedam (7) tehnologija za izolaciju (cgroups, i namespaces) kao i LXC. Dakle iz dockera ne vidite izvršne linux datoteke, servise, linux biblioteke (engl. librarys) ili datotečni sustav sa strukturom datoteka i direktorija već docker “daje” sve potrebno aplikaciji koja se pokreće unutar dockera. 

 

 

Iste metode koriste se i za svaku drugu komponentu sustava – od Storage sustava za pohranu virtualnih diskova, snapshote istih, do storage sustava za backup te drugih komponenti. KISS principi razvoja, implementacije i rada uvijek i svugdje.

Pogledajte izbornik vrste virtualiziranog disk kontrolera:

… te ako ste odabrali SCSI, pod odabir modela virtualiziranog SCSI kontrolera:

 

 

 

Razvoj i nadogradnje  Proxmox VE platforme

Proxmox VE je baziran na Debian distribuciji Linuxa, pa tako i sve nadogradnje koje se razvijaju i dolaze za Debian, dolaze i za Proxmox VE. Pošto je Debian jedna od najkorištenijih i najstabilnijih distribucija Linuxa, s desecima tisuća programera i ljudi koji ju koriste (samo se sjetite da su i sve varijante Ubuntu distribucije Linuxa bazirane na Debianu ) ovdje smo dobili cijelu vojsku ljudi koji stalno pronalaze potencijalne greške i otklanjaju ih. Dodatno stalno se rade optimizacije postojećih programskih paketa, koji u konačnici završe i na Proxmox VE platformi.

Drugi dio čine programi i komponente koje razvija tvrtka koja stoji iza Proxmox VE  open source platforme : “Proxmox Server Solutions GmbH” ali i cijeli niz programera i korisnika ove platforme.  Naime cijela platforma je objavljena prema GNU AGPL, v3 licenci, te nema skrivenih djelova ili funkcionalnosti koje se posebno naplaćuju – sve je otvoreno i dostupno (i besplatno).

Tvrtka koja podupire i razvija ovu platformu – dakle Proxmox Server Solutions GmbH ima stalno zaposleni tim programera i tehničara koji razvijaju platformu ali i pružaju podršku onim korisnicima koji su spremni platiti za željenu razinu podrške.

Za one korisnike koji se žele pretplatiti na Proxmox VE platformu, distributer za Hrvatsku je tvrtka:


Suma informatika

http://www.suma-informatika.hr/

Badalićeva 27, 10 000 Zagreb

Kontaktni e-mail : tonci@suma-informatika.hr


 

Opcije podrške i cijene su vidljive na slici dolje:

Još jednom ću naglasiti kako je ovo platforma otvorenog koda, te se podrška ne mora plaćati ako to ne želite. S druge strane za poslovne korisnike se ipak preporuča neki od modela komercijalne podrške. Cijene koje se navode per CPU se odnose na cijenu za jedan fizički poslužitelj s jednim fizičkim procesorom, bez obzira da li ima jednu ili 40 jezgri. Prema tome ako kupujete licencu za jedan fizički poslužitelj s dva fizička procesora, cijena je nešto veća. Detaljnije cijene možete vidjeti na stranici : https://www.proxmox.com/en/proxmox-ve/pricing.

 

 

Vratimo se na razvoj

Zbog svoje potpune otvorenosti cjelokupnog programskog koda, vrlo često i sami korisnici koji su programeri, optimiziraju platformu ili ispravljaju greške na njoj.

 

Što se tiče repozitorija s kojih Proxmox VE “skida” nadogradnje oni su podijeljeni u dvije kategorije:

  • Oni koji su vezani za OS (Linux) se spajaju direktno na Debianove repozitorije, bez ikakve rekonfiguracije
  • Oni koji su vezani za Proxmox VE specifični softver i komponente, standardno se spajaju na Proxmox VE repozitorij i to:
    • Standardno (bez pretplate) dobivate pristup na stabilni repozitorij u kojemu su sve potrebne nadogradnje koje su testirane od strane zajednice (svih korisnika Proxmox VE platforme) i to duže vrijeme, te su potvrđene kao stabilne od strane tvrke koja stoji iza ove platforme. Pristup ovom repozitoriju je standardno već konfiguriran pa ne morate ništa mijenjati.
      • I za one željne isprobavanja novih tehnologija, koje su u fazi isprobavanja i testiranja i od strane open source zajednice programera i korisnika Proxmox VE ali i od gore imenovane tvrtke. Za pristup ovom repozitoriju je potrebna mala rekonfiguracija (dvije linije konfiguracije repozitorija ). Ovaj repozitorij nije za produkcijsku upotrebu i koristite ga na vlastitu odgovornost. Ali u njemu se nalaze one stvari koje će vrlo vjerojatno jednoga dana završiti u novim verzijama Proxmox VE (ili ih se uopće neće koristiti i biti će potpuno napuštene)
    • Za one koji su spremni platiti minimalno, prvu kategoriju “podrške” tj. COMMUNITY razinu (pogledajte tablicu gore) a  koja se zapravo odnosi na pristup još stabilnijim i dodatno testiranim softverskim paketima, koje dodatno testira i verificira tvrtka Proxmox Server Solutions GmbH. Dake za pristup ovom repozitoriju morate platiti podršku te dobivate aktivacijski kod koji unosite za svaki poslužitelj zasebno (jer se tako i naplaćuje )

 

Nove funkcionalnosti

Nove funkcionalnosti se stalno dodaju na Proxmox VE platformu, jednim djelom ako se registrirate na Proxmox VE forum: https://forum.proxmox.com/ te zatražite neku funkcionalnost koju će potvrditi i mnogi drugi korisnici, tada će vrlo vjerojatno netko (ili vi) početi raditi na njoj a ako je stvarno prihvaćena od drugih tada će i službeni programeri (zaposlenici tvrtke Proxmox Server Solutions GmbH) dobiti zeleno svjetlo za razvoj iste.

Druga opcija je uvijek – sami slobodno možete razviti novu funkcionalnost:

 

 

Prijavljivanje grešaka

Za prijavljivanje grešaka, morate se prvo registrirati (besplatno) te sve greške možete prijaviti na Bugzillu : https://bugzilla.proxmox.com/.

 

 

 

 

Pogledajmo novosti koje su uvedene u generaciji 4.x. Proxmox VE platforme

 

Verzija 4.0

Osnovnu listu novosti koje je dovela nova generacija Proxmox VE 4.0. pogledajte na videu u prilogu:

Stabilna verzija 4.0 je objavljena 05.10.2015. nakon toga su uslijedila mnogobrojna poboljšanja i optimizacije ali i naravno ispravke grešaka.

 

 

Ali što je s migracijom s verzije 3.x na 4.x. ?

Kratki odgovor: ne postoji, zbog prevelikih promjena u novoj generaciji/verziji.

Duži odgovor:  ako ste imali Proxmox VE klaster 3.x. najbrža metoda je izrada bakupa svih virtualki i linux kontejnera te kreiranje novog Proxmox VE 4.x. klastera te restore virtualki. Potom slijedi procedura konverzije OpenVZ linux kontejnera u LXC Linux kontejnere, opisana u službenom dokumentu :

https://pve.proxmox.com/wiki/Convert_OpenVZ_to_LXC

 

 

Verzija 4.1

Ova verzija (stabilna) objavljena je  11.12.2015. Donijela je slijedeće stvari :

  • bazirana je na  Debian Jessie 8.2.0 linux
  • Prelazi se na novi linux kernel 4.2.6
  • poboljšano je pokretanje i stopiranje (startup/shutdown behavior (systemd)) servisa
  • NTP je sada standardno uključen
  • kod instalacije Proxmox VE je moguće odabrati do 8 diskova za ZFS (ako želimo ZFS datotečni sustav za sistemske diskove)
  • Linux KVM opcije za sve virtualke iz GUIa:
    •  dodan je qemu agent  – zadužen za komunikaciju Gues OS (virtualke) i Hipervizora (Proxmox VE [QEMU+KVM])
    • nadograđen je network Boot ROM
  • Poboljšan je HA GUI za korisnike s ograničenim pravima
  • LXC linux kontejneri
    •  dodana je mogućnost povečanja rootfs-a iz GUIa
    • dodani su LXC template-i za :
      • Fedora 22
      • Debian stretch/sid i
      • Ubuntu 15.10
    • Dodana je podrška za  “unpriviledged containers” (kao “technology preview“)
  • storage:  dodana je podrška za “LVM thin support” (kao “technology preview“) – dakle Thin provisioning pomoću LVM (Linux LVM2 konkretno)
  • dodana je naredba  pvereport
  • … i mnoge druge optimizacije i bugfixovi

 

Verzija 4.2

Ova verzija (stabilna) objavljena je  27.04.2016. Donijela je slijedeće stvari – nabrojati ću samo ono osnovno:

 

  • GUI update – prelazak na  Sencha Ext JS 6, uključujući nove ikone i dinamičke prikaze opterečenja sustava.
    • Novi i responzivniji GUI
  • baziran na Debian Jessie 8.4.0
  • Novi Linux kernel 4.4.6
  • Novi KVM/qemu 2.5.1
  • kod instalacije Proxmox VE -moguće je odabrati “LVM thin”  particije ili  ZFS
  • Storage :
    • dodana je podrška za “LVM thin” particije koje su sada default (ovo je bio technology preview a u ovoj verziji postaje sastavni, produkcijski dio)
    • Podrška za DRBD9: drbd 9.0.2 kernel module i drbdmanage 0.95
  • Podrška za Let´s Encrypt
  • LXC podrška :
    • poboljšan setup LXC kontejnera
    • dodana je mogućnost ograničavanja brzine mrežnih kartica LXC kontejnera
    • dodavanja mount point-a preko GUI
    • poboljšanja kod backup/snapshot procedura
    • dodana je podrška za nove LXC kontejnere :
      • Alpine Linux i
      • Ubuntu 16.04
  • pobojlšanja HA managera
  • nova poruka kod  brisanja virtualke ili LXC kontejnera (kao zaštita od slučajnog brisanja)
  • poboljšanja u dijelu GUI sučelja vezanim za CEPH storage
  • mnoge druge oiptimizacije i popravke grešaka

Pogledajmo i kratki video s novostima u verziji 4.2:

 

 

Verzija 4.3

Ova verzija (stabilna) objavljena je  27.09.2016. Donijela je slijedeće stvari – nabrojati ću samo ono osnovno:

 

  • Poboljšanja GUI-a
    • dodano je pretraživanje  (“ctrl-shift-f”)
    • vertikalni meniji sa grupama i novim ikonama
    • dvostruki klik za otvaranje konzole za VM/CT
    • novi statusni pregled, prema Proxmox VE poslužiteljima,  VM i LXC kontejnerima i opterečenjima istih
  • čarobnjak kod kreiranja VM (virtualke) sada predlaže optimalne (vrlo dobro testirane)postavke, ovisno o odabranoj vrsti virtualnog računala koje želimo kreirati
  • sada su dostupne kontekstualne upute (ovisno što gledamo ili želimo mijenjati)
  • novi disk managenet, koji uključuje S.M.A.R.T. i provjeru istrošenosti SSD diskova (SSD wearout level) – za sada za Samsung, Sandisk i Intel SSD diskove (novi se dodaju sveko malo)
  • Baziran je na Debian Jessie 8.6.0
  • Novi Linux kernel 4.4.19
  • KVM/qemu nove verzije 2.6.1
  • LXC: nadogradnja na v. 2.0.4
  • i moge druge optimizacije i popravci.

Pogledajte i kratki video s novostima koje je ova verzija uvela:

 

 

Verzija 4.4

Ova verzija (stabilna) objavljena je  13.12.2016. Donijela je slijedeće stvari:

  • Nadogradnju na linux kernel 4.4.35
  • KVM: update na qemu 2.7.0
  • poboljšanja LXCa
    • nadograđen na LXC 2.0.6
    • implementirana nova funkcionalnost  restart migration
    • Tzv. unprivileged containers  se sada nalazi u GUIu (bio je technology preview u verziji 4.1)
    • Dodani su novi templatei:
      • Debian, Ubuntu, CentOS, Fedora, Arch i Alpine

Trenutno ih je dostupan popriličan broj (14 “čistih” Linux distribucija i 100 turnkeylinuxdebian baziranih, s već instaliranim određenim paketima/servisima) :

  • Poboljšanja GUI
    • novi ceph dashboard
    • novi cluster dashboard
    • poboljšani disk management , smart status s podrškom za nove  SSD diskove
    • poboljšan HA GUI
  • Instalacija Proxmox VE sustava podržava napredne postavke ZFSa
  • Uvedena je zasebna mreža za migraciju  virtualki (VM) ili kontejnera (CT)
  • Poboljšana je dokumentacija
  • Storage : DRBD9 je izbačen – zbog promjene licencnog modela od strane tvrtke Linbit (koja ga razvija)
    •  Trenutno su podržani slijedeći Storage-i (interni i/ili vanjski/mrežni):

  • napravljene su i mnoge druge optimizacije i ispravke grešaka

Pogledajmo kratki video s novim mogućnostima u ovoj verziji :

 

Uz aktivan razvoj na verziji 4.x razvija se i verzija 5.x koja ne predstavlja novu generaciju već evolucijski pomak (barem je to plan za sada).

 

Za sada toliko, do produkcijske verzije 5.x.

 

 

 

Za sve dodatne informacije slobodno kontaktirate autora ili tvrtku Suma informatika (ovlaštenog distributera Proxmox VE platforme za Hrvatsku).

 

 

 

 

 

Autor: Hrvoje Horvat

LinkedIN

 

 

The Ultimate Open Source Development Environment

Prošlo je dosta vremena od mojeg zadnjeg članka na Open Source Osijek portalu, pa bi bilo u redu da i ja nešto napišem. Ovaj put imam dvije stvari za napisati. Jedna je možda malčice privatna, te kao takva možda i subjektivna, ali jednostavno imam potrebu da to kažem. Druga je tehničke prirode i tema je ovog članka. Bitno je to da obje, zapravo, mogu biti od velike pomoći nekome tko je tek počeo ili želi početi svoju karijeru u IT sektoru. Continue reading

Spies in Wires

Pozivamo vas na  predavanje “Spies in Wires” u ime CodeCAMPa , koje će održati Bojan Alikavazović, član inicijative “Open Source Osijek”.

 

 

Opis predavanja

Upravo sada, danas, internet je najmoćniji alat na svijetu! Negdje ispod njegove površine, daleko od razmišljanja običnog korisnika, inteligentno i iznimno sofisticirano funkcionira svijet malicioznog koda. Upoznajte nevjerojatne metode skrivanja i kompromitacije kojima se služe napadači koristeći “svakodnevne” tehnologije interneta, ali na posve drugačiji način.

 

Vrijeme održavanja i lokacija

BIOS:   Josipa Jurja Strossmayera 341

 

 

Molimo vas da se prijavite zbog ograničenog broja mjesta:

http://softwarecity.hr/event/spies-in-wires/

Java Talks

Udruga Osijek Software City pokreće redovno mjesečno druženje Java developera na kojem ćete moći čuti sve o primjeni Java platforme u stvarnom svijetu.

 

Prvi Java Talks u nizu predstavlja tri teme

Enterprise Java Beans

Enterprise JavaBeans su tu da pruže standardno riješenje za aspekte zajedničke svim servisnim aplikacijama, kao što su ‘pohrana podataka’, ‘transakcije’, te ‘sigurnost’ i tako programerima omogućuje da se fokusiraju na samo softversko rješeje koje trebaju implementirati. Predavač će biti Antun Matanović iz tvrtke ORKA.

Project Jigsaw – java moduli

Project Jigsaw koji donosi standardizirani modul sistem za Java platformu je originalno najavljen za JDK 7, svjetlo dana bi konačno trebao ugledati u verziji 9 koja se očekuje na ljeto ove godine. Predavač će biti Ivan Varga iz tvrtke Adcon.

Vertx – komunikacija mikroservisa u klaster okruženju

Eclipse Vert.x vam za razliku od tradicionalnih aplikacijskih kontejnera daje nevjerojatnu moć i agilnost u kreiranju impresivnih, skalabilnih servisnih aplikacija 21. stoljeća onako kako vi to želite, bez puno strke i u jeziku u kojem želite (u Javi naravno). Predavač će biti Krešimir Popović iz tvrtke Siemens Convergence Creators.

 

Zbog ograničenog broja mjesta OBAVEZNA je prijava!

 

Za više informacija te prijavu, skočite na :

http://softwarecity.hr/event/java-talks-1/