🥇IPFS fără durere (dar nu este sigur)

Deși pe Habr a fost deja nu un articol despre IPFS.

Voi clarifica de la început că nu sunt expert în acest domeniu, dar am manifestat de multe ori interes pentru această tehnologie, deși încercările de a experimenta cu ea au provocat adesea dureri. Astăzi m-am apucat din nou de experimente și am obținut câteva rezultate pe care aș dori să le împărtășesc. Pe scurt, voi descrie procesul de instalare a IPFS și câteva trucuri (totul a fost realizat pe Ubuntu, nu am încercat pe alte platforme).

Dacă ați ratat ce înseamnă IPFS, este descris destul de detaliat aici: habr.com/ru/post/314768

Instalare

Pentru a menține claritatea experimentului, sugerez să instalăm direct pe un server extern, deoarece vom examina câteva capcane ale funcționării în modul local și la distanță. Apoi, dacă doriți, nu va fi dificil să-l ștergeți, nu durează mult.

Instalăm go

Documentația oficială
Vedeți versiunea actuală pe golang.org/dl

Observație: este mai bine să instalați IPFS sub contul utilizatorului cu care se intenționează cel mai frecvent utilizarea. Motivul este că mai jos vom examina opțiunea de montare prin FUSE și există niște subtilități.

cd ~
curl -O https://dl.google.com/go/go1.12.9.linux-amd64.tar.gz
tar xvf go1.12.9.linux-amd64.tar.gz
sudo chown -R root:root ./go
sudo mv go /usr/local
rm go1.12.9.linux-amd64.tar.gz

Apoi trebuie să actualizați mediul (mai multe detalii aici: golang.org/doc/code.html#GOPATH).

echo 'export GOPATH=$HOME/work' >> ~/.bashrc
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.bashrc
source ~/.bashrc

Verificăm dacă go s-a instalat

go version

Instalăm IPFS

Cel mai mult mi-a plăcut metoda de instalare prin ipfs-update.

Îl instalăm cu comanda

go get -v -u github.com/ipfs/ipfs-update

După aceasta, puteți executa următoarele comenzi:

ipfs-update versions — pentru a vedea toate versiunile disponibile pentru descărcare.
ipfs-update version — pentru a vedea versiunea curent instalată (deocamdată, deoarece IPFS nu este instalat, va fi none).
ipfs-update install latest — pentru a instala cea mai recentă versiune IPFS. În loc de latest, puteți specifica orice versiune dorită din lista celor disponibile.

Instalăm ipfs

ipfs-update install latest

Verificăm

ipfs --version

În general, cam asta este pentru instalare.

Pornirea IPFS

Inițializare

Pentru început, trebuie să executăm inițializarea.

ipfs init

Ca răspuns, veți obține ceva de genul:

 ipfs init
initializing IPFS node at /home/USERNAME/.ipfs
generating 2048-bit RSA keypair...done
peer identity: QmeCWX1DD7HnXXXXXXXXXXXXXXXXXXXXXXXXxxx
to get started, enter:
	ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Puteți executa comanda propusă

ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Rezultatul

Bună și bine ați venit la IPFS!

██╗██████╗ ███████╗███████╗
██║██╔══██╗██╔════╝██╔════╝
██║██████╔╝█████╗  ███████╗
██║██╔═══╝ ██╔══╝  ╚════██║
██║██║     ██║     ███████║
╚═╝╚═╝     ╚═╝     ╚══════╝

Dacă vezi asta, ai instalat cu succes
IPFS și acum interacționezi cu ipfs merkledag-ul!

 -------------------------------------------------------
| Atenție:                                           |
|   Acesta este un software alpha. Folosește-l pe propria răspundere! |
|   Lipsesc multe sau sunt nesigure. Există bug-uri.  |
|   Nu este încă sigur. Citește notele de securitate pentru mai multe detalii.   |
 -------------------------------------------------------

Verifică unele dintre celelalte fișiere din acest director:

  ./about
  ./help
  ./quick-start     <-- exemple de utilizare
  ./readme          <-- acest fișier
  ./security-notes

Aici, deja încep lucrurile să devină interesante. La etapa de instalare, echipa începe să folosească propriile tehnologii. Hash-ul propus QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv — nu este generat special pentru tine, ci încorporat în versiune. Adică, înainte de lansare, au pregătit un text de bun venit, l-au încărcat în IPFS și au adăugat adresa în instalator. Mi se pare foarte cool. Acest fișier (mai exact, întreaga folder) poate fi acum vizualizat nu doar local, ci și pe gateway-ul oficial. ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. De asemenea, se poate fi sigur că conținutul folderului nu a fost modificat, pentru că, dacă s-ar fi schimbat, atunci hash-ul s-ar fi schimbat și el.

Ca o observație, în acest caz, IPFS are o anumită asemănare cu un server de control al versiunilor. Dacă în fișierele sursă ale folderului se fac modificări și se reîncărca folderul în IPFS, acesta va primi o nouă adresă. Totuși, folderul vechi nu va dispărea pur și simplu și va fi disponibil la adresa sa anterioară.

Lansare directă

ipfs daemon

Ar trebui să primești un răspuns de genul:

ipfs daemon
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
Swarm listening on /ip4/x.x.x.x/tcp/4001
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Deschizând ușile pentru Internet

Atenție la aceste două linii:

WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080

Dacă ai instalat IPFS local, vei accesa interfețele IPFS prin adrese locale și totul îți va fi disponibil (De exemplu, localhost:5001/webui/). Dar la instalarea pe un server extern, din default, porțile sunt închise pentru internet. Există două porți:

Admin panel webui (github) pe portul 5001.
API extern pe portul 8080 (readonly).

Pentru experimente, putem deschide ambele porți (5001 și 8080), dar pe serverul de producție, evident, portul 5001 ar trebui să fie închis prin firewall. Există și portul 4001, care este necesar pentru ca alte noduri să vă poată găsi. Acesta ar trebui să rămână deschis pentru solicitările externe.

Deschidem pentru editare ~/ipfs/config și căutăm aceste linii:

"Addresses": {
  "Swarm": [
    "/ip4/0.0.0.0/tcp/4001",
    "/ip6/::/tcp/4001"
  ],
  "Announce": [],
  "NoAnnounce": [],
  "API": "/ip4/127.0.0.1/tcp/5001",
  "Gateway": "/ip4/127.0.0.1/tcp/8080"
}

Schimbăm 127.0.0.1 cu IP-ul serverului dvs. și salvăm fișierul, după care repornim ipfs (oprim comanda rulată cu Ctrl+C și reluăm).

Ar trebui să obținem

...
WebUI: http://ip_adrese_server:5001/webui
Serverul Gateway (readonly) ascultă pe /ip4/ip_adrese_server/tcp/8080

Acum interfacele externe ar trebui să fie accesibile.

Verificați

http://domeniu_sau_ip_server:8080/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/readme

Ar trebui să se deschidă fișierul README menționat mai sus.

http://domeniu_sau_ip_server:5001/webui/

Ar trebui să se deschidă interfața web.

Dacă webui funcționează, atunci setările IPFS pot fi modificate direct în el, inclusiv vizualizarea statisticilor, dar mai jos voi discuta despre opțiunile de configurare exact prin fișierul de configurare, ceea ce nu este critic. Este mai bine să rețineți unde se află configurația și ce să faceți cu ea, deoarece dacă interfața web nu funcționează, va fi mai dificil.

Configurăm interfața web pentru a funcționa cu serverul dvs.

Iată prima capcană, pe care am petrecut circa trei ore.

Dacă ați instalat IPFS pe un server extern, dar nu ați instalat sau nu ați început IPFS local, atunci când accesați /webui în interfața web, ar trebui să vedeți o eroare de conectare:

Problema este că webui, în opinia mea, funcționează destul de ambiguu. La început, încearcă să se conecteze la API-ul serverului unde este deschis interfața (bineînțeles bazându-se pe adresa din browser). Și dacă nu reușește acolo, încearcă să se conecteze la gateway-ul local. Dacă aveți IPFS pornit local, atunci webui va funcționa corect, dar veți lucra cu IPFS local, nu cu cel extern, deși ați deschis webui pe un server extern. Apoi, încărcați fișiere, dar dintr-un motiv oarecare nu le vedeți pur și simplu pe serverul extern...

Dacă nu este lansat nici local, primim o eroare de conectare. În cazul nostru, eroarea este cel mai probabil din cauza CORS, lucru subliniat și de webui, care sugerează să adăugăm configurația.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["http://ip_adresei serverului tău:5001", "http://127.0.0.1:5001", "https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "GET", "POST"]'

Eu am specificat doar wildcard.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

Header-ele adăugate pot fi găsite toate în același ~/.ipfs/config. În cazul meu este

  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Origin": [
        "*"
      ]
    }
  },

Repornește ipfs și vedem că webui s-a conectat cu succes (în orice caz ar trebui să se conecteze, dacă ai deschis gateway-urile pentru solicitări din exterior, așa cum este descris mai sus).

Acum putem încărca directoare și fișiere direct prin interfața web, precum și crea propriile directoare.

Montarea sistemului de fișiere FUSE

Aceasta este o caracteristică destul de interesantă.

Fișierele (la fel ca și directoarele) le putem adăuga nu doar prin interfața web, ci și direct în terminal, de exemplu

ipfs add test -r
added QmfYuz2gegRZNkDUDVLNa5DXzKmxxxxxxxxxx test/test.txt
added QmbnzgRVAP4fL814h5mQttyqk1aURxxxxxxxxxxxx test

Ultimul hash este hash-ul directorului rădăcină.

Prin acest hash putem deschide directorul pe orice nod ipfs (care poate găsi nodul nostru și obține conținutul), putem în interfața web pe portul 5001 sau 8080, sau local prin ipfs.

ipfs ls QmbnzgRVAP4fL814h5mQttyqk1aUxxxxxxxxxxxxx
QmfYuz2gegRZNkDUDVLNa5DXzKmKVxxxxxxxxxxxxxx 10 test.txt

Dar se poate deschide și ca un director obișnuit.

Să creăm în rădăcină două directoare și să le oferim drepturi utilizatorului nostru.

sudo mkdir /ipfs /ipns
sudo chown USERNAME /ipfs /ipns

Și vom reporni ipfs cu flag-ul —mount.

ipfs daemon --mount

Se pot crea directoare și în alte locuri și se poate specifica calea lor prin parametrii ipfs daemon —mount —mount-ipfs /ipfs_path —mount-ipns /ipns_path

Acum citirea din acest director este ceva mai neobișnuită.

ls -la /ipfs
ls: reading directory '/ipfs': Operation not permitted
total 0

Deci nu avem acces direct la rădăcina acestui director. Dar, putem obține conținutul, cunoscând hash-ul.

ls -la /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx
total 0
-r--r--r-- 1 root root 10 Aug 31 07:03 test.txt

cat /ipfs/QmbnzgRVAP4fL814h5mQttyqxxxxxxxxxxxxxxxxx/test.txt 
test
test

În plus, în interiorul directorului funcționează chiar și completarea automată atunci când specificăm calea.

Așa cum am menționat mai devreme, acest tip de montaj are câteva subtilități: în mod implicit, folderele FUSE montate sunt accesibile doar utilizatorului curent (chiar și root nu va putea citi dintr-un astfel de folder, cu atât mai puțin alți utilizatori din sistem). Dacă doriți să faceți aceste foldere accesibile altor utilizatori, trebuie să schimbați configurația din «FuseAllowOther»: false în «FuseAllowOther»: true. Dar și asta nu e tot. Dacă rulați IPFS sub identitatea root, totul este în regulă. Dacă rulați sub un utilizator obișnuit (chiar și cu sudo), veți primi o eroare.

eroare de asistent de montare: fusermount: opțiunea allow_other este permisă doar dacă 'user_allow_other' este setat în /etc/fuse.conf

În acest caz, trebuie să ajustați /etc/fuse.conf, decomentând linia #user_allow_other.

După aceea, repornim ipfs.

Probleme cunoscute cu FUSE

Nu o dată a fost observată problema că, după restartul ipfs cu montare (sau poate și în alte cazuri), punctele de montare /ipfs și /ipns devin inaccesibile. Nu există acces la ele, iar ls -la /ipfs arată ???? în lista de permisiuni.

Am găsit o astfel de soluție:

fusermount -z -u /ipfs
fusermount -z -u /ipns

După care repornim ipfs.

Adăugăm serviciul

Desigur, lansarea în terminal este bună doar pentru teste inițiale. În modul de producție, daemonul ar trebui să pornească automat la pornirea sistemului.

Sub identitatea sudo, creăm fișierul /etc/systemd/system/ipfs.service și scriem în el:

[Unit]
Description=Daemon IPFS
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/home/USERNAME/work/bin/ipfs daemon --mount
User=USERNAME
Restart=always

[Install]
WantedBy=multi-user.target

USERNAME trebuie, desigur, să fie înlocuit cu utilizatorul dvs. (și s-ar putea să fie un alt drum complet către programul ipfs pe care trebuie să-l indicați exact).

Activăm serviciul.

sudo systemctl enable ipfs.service

Pornim serviciul.

sudo service ipfs start

Verificăm starea serviciului.

sudo service ipfs status

Pentru a păstra experimentul clar, ar putea fi bine să reporniți serverul mai târziu, pentru a verifica dacă ipfs pornește automat cu succes.

Adăugăm peerii pe care îi cunoaștem

Să analizăm situația în care nodurile IPFS sunt instalate atât pe un server extern, cât și local. Pe serverul extern, adăugăm un fișier și încercăm să-l obținem local prin CID. Ce se va întâmpla? Desigur, serverul local, cel mai probabil, nu știe nimic despre serverul nostru extern și va încerca pur și simplu să găsească fișierul după CID, "întrebând" toți piurile IPFS disponibile (cu care a reușit deja să se "cunoască"). Acestea, la rândul lor, vor întreba alte piuri. Și așa mai departe, până când fișierul nu va fi găsit. Exact aceeași situație se întâmplă și când încercăm să obținem fișierul printr-un gateway oficial. ipfs.io. Dacă avem noroc, fișierul va fi găsit în câteva secunde. Dacă nu, nu va fi găsit nici în câteva minute, ceea ce afectează foarte mult confortul muncii. Dar noi știm unde va apărea acest fișier în primul rând. De ce să nu-i spunem imediat serverului nostru local „Caută întâi acolo”? Se pare că acest lucru este posibil.

1. Accesăm serverul extern și în configurarea ~/.ipfs/config căutăm

"Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuxxxxxxxxxxxxxxxx",

2. Executăm sudo service ipfs status și căutăm în el înregistrările Swarm, de exemplu:

Swarm announcing /ip4/ip_server_tău/tcp/4001

3. Construim din aceste informații o adresă comună de tipul „/ip4/ip_server_tău/tcp/4001/ipfs/$PeerID”.

4. Pentru fiabilitate, prin interfața web locală, încercăm să adăugăm această adresă în piuri.

5. Dacă totul este în regulă, deschidem configurația locală ~/.ipfs/config, găsim în ea „Bootstrap”: […]
și adăugăm prima dată în array adresa obținută.

Restartăm IPFS.

Acum adăugăm un fișier pe serverul extern și încercăm să-l solicităm local. Ar trebui să meargă rapid.

Dar această funcționalitate este încă instabilă. Din câte înțeleg, chiar dacă indicăm adresa unui peer în Bootstrap, în timpul funcționării, ipfs modifică lista conexiunilor active cu piuri. În orice caz, se discută despre asta și se fac solicitări referitoare la posibilitatea de a specifica piuri fixe. aici Și se pare că se preconizează să fie adăugată o funcționalitate în ipfs@5.0+

Lista curentă a piurilor poate fi consultată atât în webui, cât și în terminal.

ipfs swarm peers

Atât în webui, cât și în terminal, se poate adăuga manual propriul peer.

ipfs swarm connect "/ip4/ip_server_tău/tcp/4001/ipfs/$PeerID"

Până când nu îmbunătățesc această funcționalitate, se poate scrie un tool care să verifice existența conexiunii cu peerul dorit și, dacă nu există, să adauge conexiunea.

Reflecții

Printre cei care sunt deja familiarizați cu IPFS există atât argumente pro, cât și contra. În principiu, se discută de ceva timp s-a dezactivat și m-a motivat să cercetez din nou IPFS. Și iată despre discuția menționată: nu pot spune că sunt complet împotriva vreunui argument adus de cei care s-au exprimat (sunt de acord doar cu afirmația că un programator și jumătate folosesc IPFS). În general, toți au într-o oarecare măsură dreptate (în special comentariul despre chitanțe oferă de gândit). Dar dacă excludem evaluarea morală și juridică, cine își va da o evaluare tehnică a acestei tehnologii? Personal, am o senzație internă că „acest lucru trebuie făcut cu siguranță, are perspective definite”. Dar de ce anume, nu am o formulare clară. Adică, dacă ne uităm la soluțiile centralizate existente, acestea sunt cu mult înainte în multe privințe (stabilitate, viteză de operare, gestionabilitate etc.). Cu toate acestea, am o idee care pare a avea sens și care probabil nu poate fi realizată fără astfel de sisteme descentralizate. Desigur, îmi asum un risc, dar aș formula astfel: principiul răspândirii informației pe Internet trebuie schimbat.

Permiteți-mi să explic. Dacă ne gândim la asta, acum informația se răspândește pe principiul „Sper că cel căruia i-am transmis-o o va proteja și nu va fi pierdută sau obținută de cei pentru care nu este destinată”. Ca exemplu, este ușor de analizat diverse servicii de email, stocare în cloud etc. Și ce avem în final? Pe Habrahabr Securitate informațională este pe prima linie și practic în fiecare zi primim știri despre încă o scurgere globală. În principiu, tot ce este mai interesant este enumerat în minunata articol Vara s-a terminat aproape. Datele neîntărite aproape că nu au mai rămas. Așadar, principalii giganți ai internetului devin din ce în ce mai mari, acumulează din ce în ce mai multe informații și astfel de scurgeri sunt asemenea unor explozii atomice informaționale. Niciodată nu a fost așa și iată că se întâmplă din nou. Cu toate acestea, deși mulți își dau seama că riscuri există, vor continua să-și încredințeze datele companiilor externe. În primul rând, nu există multe alternative, iar în al doilea rând, acestea promit că au închis toate găurile și că astfel de situații nu se vor mai repeta.

Ce variantă mi se pare? Cred că datele ar trebui inițial distribuite deschis. Dar deschiderea, în acest caz, nu înseamnă că totul trebuie să fie ușor de citit. Vorbesc despre deschiderea stocării și distribuției, dar nu despre o deschidere totală la citire. Presupun că informația ar trebui distribuită cu chei deschise. De fapt, principiul cheilor deschise/închise este deja vechi, aproape cât Internetul. Dacă informația nu este confidențială și este destinată unui public larg, atunci aceasta este publicată imediat cu o cheie deschisă (dar, totuși, într-o formă criptată, doar că oricine o poate decripta folosind cheia disponibilă). Iar dacă nu, atunci se publică fără o cheie deschisă, iar cheia se transmite celui care trebuie să aibă acces la informația respectivă. În acest caz, cel care trebuie să o citească ar trebui să aibă doar cheia, iar unde să găsească informația nu ar trebui să-l preocupe prea mult — el o trage pur și simplu din rețea (acesta este noul principiu de distribuție bazat pe conținut, nu pe adresă).

Astfel, pentru ca atacatorii să efectueze un atac în masă, va trebui să obțină un număr enorm de chei private, și este puțin probabil să poată face acest lucru dintr-un singur loc. Această sarcină, din punctul meu de vedere, este mai complicată decât să spargi un anumit serviciu.

Și aici se închide încă o problemă: confirmarea autorului. Acum, pe internet, poți găsi nenumărate citate scrise de cunoscuții noștri. Dar unde este garanția că tocmai ei le-au scris? Dacă fiecare astfel de înregistrare ar veni însoțită de o semnătură digitală, ar fi mult mai simplu. Și nu contează unde se află informația, importantă este semnătura, care, în mod evident, este greu de falsificat.

Și iată ce este interesant: IPFS conține deja mijloace de criptare (deoarece este construit pe tehnologia blockchain). În configurație este specificată imediat cheia privată.

  "Identity": {
    "PeerID": "QmeCWX1DD7HnPSuMHZSh6tFuMxxxxxxxxxxxxxx",
    "PrivKey": "CAASqAkwggSkAgEAAoIBAQClZedVmj8JkPvT92sGrNIQmofVF3ne8xSWZIGqkm+t9IHNN+\/NDI51jA0MRzpBviM3o\/c\/Nuz30wo95vWToNyWzJlyAISXnUHxnVhvpeJAbaeggQRcFxO9ujO9DH61aqgN1m+JoEplHjtc4KS5
pUEDqamve+xAJO8BWt\/LgeRKA70JN4hlsRSghRqNFFwjeuBkT1kB6tZsG3YmvAXJ0o2uye+y+7LMS7jKpwJNJBiFAa\/Kuyu3W6PrdOe7SqrXfjOLHQ0uX1oYfcqFIKQsBNj\/Fb+GJMiciJUZaAjgHoaZrrf2b\/Eii3z0i+QIVG7OypXT3Z9JUS60
KKLfjtJ0nVLjAgMBAAECggEAZqSR5sbdffNSxN2TtsXDa3hq+WwjPp\/908M10QQleH\/3mcKv98FmGz65zjfZyHjV5C7GPp24e6elgHr3RhGbM55vT5dQscJu7SGng0of2bnzQCEw8nGD18dZWmYJsE4rUsMT3wXxhUU4s8\/Zijgq27oLyxKNr9T7
2gxqPCI06VTfMiCL1wBBUP1wHdFmD\/YLJwOjV\/sVzbsl9HxqzgzlDtfMn\/bJodcURFI1sf1e6WO+MyTc3.................

Nu sunt specialist în securitate și nu pot ști cu exactitate cum să folosești asta corect, dar mi se pare că aceste chei sunt utilizate la nivelul schimbului dintre nodurile IPFS. De asemenea, js-ipfs și proiecte de exemplu precum orbit-db, pe care funcționează orbit.chat. Asta înseamnă că, teoretic, fiecare dispozitiv (mobil și nu numai) poate fi ușor echipat cu mașini de criptare și decriptare proprii. În acest caz, e nevoie doar ca fiecare să aibă grijă de păstrarea cheilor sale private și fiecare va fi responsabil pentru propria sa securitate, mai degrabă decât să fie prizonierul unui alt factor uman de pe vreo super-populară platformă de internet.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.

Ați auzit anterior de IPFS?

Niciodată nu am auzit despre IPFS, dar pare interesant
Nu am auzit și nu vreau să aud
Am auzit, dar nu m-a interesat
Am auzit, dar nu am înțeles, iar acum pare interesant
Folosesc IPFS activ de mult timp

Au votat 69 de utilizatori. 13 utilizatori s-au abținut.

Sursa: habr.com