Το προφίλ μας στο Google Plus
12

Ένας server, δύο σύννεφα [μέρος 3/3]

Ο υπερσύγχρονος server μας εκτείνεται στα clouds δύο διαφορετικών hosting providers και προς το παρόν έχουμε τελειώσει με το compute μέρος, ενισχύοντας μάλιστα και την ασφάλειά του. Σ’ αυτό το άρθρο κατασκευάζουμε την απαραίτητη γέφυρα μεταξύ compute και storage. Επίσης, στο compute μέρος εγκαθιστούμε το BitTorrent Sync, ενώ αποκτάμε κι ένα έγκυρο, υπογεγραμμένο πιστοποιητικό το οποίο χαρίζουμε στο ownCloud.

Για την απομακρυσμένη προσάρτηση buckets του Storage Qloud στο eyjafjallajokull –αυτό είναι το hostname του Droplet μας– καταφεύγουμε στο s3fs-fuse project. Δεν υπάρχει κάποιο έτοιμο πακέτο για το Ubuntu, οπότε θα κατεβάσουμε τον πηγαίο κώδικα και θα τον μεταγλωττίσουμε μόνοι μας.

Σημείωση: Για τη συνέχεια υποθέτουμε ότι έχετε διαβάσει το πρώτο και το δεύτερο μέρος του μίνι αφιερώματός μας.

Λήψη κώδικα s3fs-fuse, μεταγλώττιση και χρήση
Ξεκινάμε με την εγκατάσταση ορισμένων πακέτων, τα οποία είναι απαραίτητα για την επιτυχή μεταγλώττιση του s3fs-fuse:

admin@eyjafjallajokull:~$ sudo apt-get install build-essential git \
libfuse-dev libcurl4-openssl-dev libxml2-dev automake libtool \
pkg-config libssl-dev

Φτιάχνουμε έναν κατάλογο εργασίας, μεταβαίνουμε σ’ αυτόν και κατεβάζουμε το tarball με τον κώδικα από την έκδοση 1.77 του s3fs-fuse.

admin@eyjafjallajokull:~$ mkdir ~/workbench
admin@eyjafjallajokull:~$ cd ~/workbench
admin@eyjafjallajokull:~/workbench$ wget https://github.com/s3fs-fuse/s3fs-fuse/archive/v1.77.tar.gz -O s3fs-v1.77.tar.gz

Προσοχή: Θα ανακαλύψετε ότι υπάρχει και νεότερη έκδοση του s3fs-fuse. Ωστόσο κατά τις δικές μας δοκιμές –και κάναμε πολλές, σε περισσότερα από ένα συστήματα– είχαμε προβλήματα με την προσάρτηση buckets. Συγκεκριμένα, με την έκδοση 1.78 η διαδικασία αποτύγχανε επιστρέφοντας το μήνυμα “remote endpoint not connected”. Ίσως τη στιγμή που διαβάζετε αυτές τις γραμμές να ‘χει βγει ακόμη πιο νέα έκδοση, η οποία δεν θα παρουσιάζει την ελαττωματική αυτή συμπεριφορά με το Storage Qloud. Όπως και να ‘χει για τη συνέχεια χρησιμοποιούμε την έκδοση v1.77, που αποδεδειγμένα δουλεύει χωρίς προβλήματα.

Αποσυμπιέζουμε το αρχείο s3fs-v1.77.tar.gz και μεταβαίνουμε στο νέο κατάλογο που δημιουργείται:

admin@eyjafjallajokull:~/workbench$ tar zxvf s3fs-v1.77.tar.gz
admin@eyjafjallajokull:~/workbench$ cd s3fs-fuse-1.77

Προετοιμάζουμε το περιβάλλον, μεταγλωττίζουμε και, με δικαιώματα διαχειριστή, εγκαθιστούμε. Παρατηρήστε ότι το βασικό εκτελέσιμο, το s3fs, καθώς κι άλλα συνοδευτικά αρχεία, τα θέλουμε οργανωμένα κάτω από το /usr/local.

admin@eyjafjallajokull:~/workbench/s3fs-fuse-1.77$ ./autogen.sh
admin@eyjafjallajokull:~/workbench/s3fs-fuse-1.77$ ./configure --prefix=/usr/local
admin@eyjafjallajokull:~/workbench/s3fs-fuse-1.77$ make
admin@eyjafjallajokull:~/workbench/s3fs-fuse-1.77$ sudo make install

Όλα δείχνουν να είναι καλά, όπως υποδηλώνει και μια πρώτη εκτέλεση του s3fs:

admin@eyjafjallajokull:~/workbench/s3fs-fuse-1.77$ s3fs --version
Amazon Simple Storage Service File System 1.77
Copyright (C) 2010 Randy Rizun <rrizun@gmail.com>
License GPL2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Σειρά έχει η δημιουργία καταλόγων, στους οποίους θα συνδεθούν τα απομακρυσμένα buckets του Storage Qloud. Για τις ανάγκες μας είχαμε ήδη δύο buckets που θέλαμε να προσαρτήσουμε: ένα με video tutorials (deltaCast) κι ένα με τεύχη (deltaHacker):

admin@eyjafjallajokull:~/workbench/s3fs-fuse-1.77$ cd
admin@eyjafjallajokull:~$ sudo mkdir -p /mnt/sqloud/deltaCast
admin@eyjafjallajokull:~$ sudo mkdir /mnt/sqloud/deltaHacker

Ακολούθως, στο /etc πρέπει να φτιάξουμε ένα αρχείο απλού κειμένου, π.χ., με τη βοήθεια του nano, το οποίο θα ονομάζεται passwd-s3fs και θα περιλαμβάνει τα API Key και Secret Key. Αυτά τα δύο strings είναι στο λογαριασμό μας στη GreenQloud — και συγκεκριμένα στην κατηγορία API Access, στο προφίλ του χρήστη μας. Η μορφή που οφείλει να έχει το /etc/passwd-s3fs είναι

API Key:Secret key

χωρίς κενά. Το αρχείο θα ανήκει στο χρήστη admin, ο οποίος θα είναι ο μόνος με δικαιώματα ανάγνωσης κι εγγραφής.

admin@eyjafjallajokull:~$ sudo nano /etc/passwd-s3fs
admin@eyjafjallajokull:~$ sudo chown admin:admin /etc/passwd-s3fs
admin@eyjafjallajokull:~$ sudo chmod 600 /etc/passwd-s3fs

Φροντίζουμε τώρα για τις απαραίτητες προσθήκες στο /etc/fstab, ώστε η προσάρτηση/αποπροσάρτηση των buckets να γίνεται αυτόματα κι εύκολα. Δείτε λίγο τις δύο σχετικές γραμμές από το /etc/fstab του eyjafjallajokull:

s3fs#pqrxyz-deltacast /mnt/sqloud/deltaCast fuse noauto,uid=1000,gid=1000,use_cache=/tmp/s3fs,del_cache,nomultipart,allow_other,url=https://s.greenqloud.com 0 0
s3fs# pqrxyz-deltahacker /mnt/sqloud/deltaHacker fuse noauto,uid=1000,gid=1000,use_cache=/tmp/s3fs,del_cache,nomultipart,allow_other,url=https://s.greenqloud.com 0 0

Τα ονόματα των buckets, pqrxyz-deltacast και pqrxyz-deltahacker, σκόπιμα τα παρουσιάζουμε τροποποιημένα εδώ. Δεν είναι προσβάσιμα από το web, αλλά καλό είναι να μη φαίνονται. Στη λίστα των επιλογών για το mount έχουμε συμπεριλάβει την παράμετρο noauto. Δεν θέλουμε να επιχειρείται αυτόματη προσάρτηση κατά το boot του λειτουργικού: εξαιτίας ενός race condition με την υπηρεσία δικτύωσης, η προσάρτηση κατά περιπτώσεις αποτυγχάνει. Επειδή όμως καλό είναι το mount να γίνεται αυτόματα, ναι μεν στο fstab βάζουμε το noauto αλλά αμέσως μετά την ολοκλήρωση του boot προσαρτούμε αυτόματα τα buckets, χάρη σε μερικές απλές εντολές που έχουμε φροντίσει να υπάρχουν στο αρχείο /etc/rc.local. Περισσότερα επ’ αυτού θα πούμε σε λίγο.

Μια άλλη ενδιαφέρουσα παράμετρος είναι η use_cache. Όταν ορίζεται, τότε κατά τη λήψη ή αποστολή ενός αρχείου από ή προς κάποιο bucket, δημιουργείται κι ένα αντίγραφό του στο τοπικό filesystem και συγκεκριμένα στη θέση που υποδεικνύει η use_cache. Τις επόμενες φορές που θα ζητηθεί το ίδιο αρχείο θα λαμβάνεται από την cache κι αυτό σημαίνει σημαντικό κέρδος σε ταχύτητα. Την cache μπορούμε να την αδειάζουμε ανά πάσα στιγμή χωρίς πρόβλημα, είτε χειροκίνητα είτε με τη βοήθεια κάποιου cronjob. Επίσης, χάρη στην παράμετρο del_cache, η cache θα διαγράφεται με το που αποπροσαρτάται το αντίστοιχο bucket. Για την περίπτωσή μας, η χρήση cache είναι πρακτικά επιβεβλημένη. Σκεφτείτε, π.χ., τον πρώτο συνδρομητή που θα επιχειρήσει να κατεβάσει το PDF του τεύχους 041: Με κλικ στο αντίστοιχο download URL θα αποσταλεί αίτημα στο ownCloud του eyjafjallajokull.parabing.com, το ζητούμενο αρχείο θα έρθει στο datacenter του Άμστερνταμ από ένα storage pod κάπου έξω από το Ρέικιαβικ, ο συνδρομητής θα αρχίσει να το κατεβάζει — αλλά ταυτόχρονα αυτό θα αποθηκευτεί και στην τοπική cache του eyjafjallajokull. Έτσι, για τους επόμενους συνδρομητές δεν θα χρειαστεί να έρθει ξανά από Ισλανδία. Ας εγκαινιάσουμε τώρα τα mounts για τα δύο buckets:

admin@eyjafjallajokull:~$ sudo mount /mnt/sqloud/deltaCast
admin@eyjafjallajokull:~$ sudo mount /mnt/sqloud/deltaHacker
admin@eyjafjallajokull:~$ df -hT
Filesystem     Type       Size  Used Avail Use% Mounted on
/dev/vda1      ext4        40G  6.3G   32G  17% /
none           tmpfs      4.0K     0  4.0K   0% /sys/fs/cgroup
udev           devtmpfs   991M  4.0K  991M   1% /dev
tmpfs          tmpfs      201M  336K  200M   1% /run
none           tmpfs      5.0M     0  5.0M   0% /run/lock
none           tmpfs     1001M     0 1001M   0% /run/shm
none           tmpfs      100M     0  100M   0% /run/user
s3fs           fuse.s3fs  256T     0  256T   0% /mnt/sqloud/deltaCast
s3fs           fuse.s3fs  256T     0  256T   0% /mnt/sqloud/deltaHacker

Πολύ ωραία. Για την αυτόματη προσάρτηση των buckets μετά από reboot, προς το τέλος του /etc/rc.local αρκεί να υπάρχουν οι ακόλουθες δύο γραμμές:

/bin/mount /mnt/sqloud/deltaCast
/bin/mount /mnt/sqloud/deltaHacker

Απλά κι όμορφα πράγματα.

Αρχική ρύθμιση ownCloud
Όπως αναφέραμε στο πρώτο μέρος της σειράς, για image του Droplet μας επιλέξαμε αυτό που είχε προεγκατεστημένο το ownCloud σε LAMP stack, πάνω από το Ubuntu Server 14.04 LTS. Αμέσως μετά το boot του συστήματος o Apache είναι ενεργός κι αν σε κάποιον web browser πληκτρολογήσουμε τη δημόσια διεύθυνση IP του VPS, θα δούμε τη σελίδα σύνδεσης του ownCloud. Εναλλακτικά, αν στη διεύθυνση IP έχουμε αντιστοιχίσει ένα δικό μας domain name, π.χ., μέσα από τον DNS manager της Digital Ocean, τότε στη μπάρα διευθύνσεων του browser αντί για την αριθμητική διεύθυνση IP θα πληκτρολογήσουμε αυτό το domain name. Στο δεύτερο μέρος της σειράς είχαμε εξάλλου φροντίσει για το μπλοκάρισμα του port 80, οπότε η διεύθυνση που για πρώτη φορά δώσαμε στον browser ήταν η

https://eyjafjallajokull.parabing.com

Για το ownCloud χρησιμοποιείται ένα self-signed certificate της βασικής εγκατάστασης του Apache, με συνέπεια ο web browser να εμφανίζει σχετική προειδοποίηση. Σε λίγο θα αποκτήσουμε ένα έγκυρο πιστοποιητικό για την εγκατάσταση του ownCloud μας, προς το παρόν όμως λέμε στον browser να κάνει μια εξαίρεση και να δεχτεί αυτό που τώρα βλέπει.

Το πιστοποιητικό για το ownCloud είναι self-signed, οπότε δικαίως ο web browser διαμαρτύρεται και ρίχνει σ' εμάς το μπαλάκι. Του επιτρέπουμε να προχωρήσει κι αργότερα θα φροντίσουμε ώστε το ownCloud να διαθέτει ένα έγκυρο πιστοποιητικό (που δεν είναι self-signed, αλλά υπογεγραμμένο από μία έμπιστη Αρχή Πιστοποίησης).

Την πρώτη φορά που θα επιχειρήσουμε σύνδεση σε λογαριασμό του ownCloud, ως username θα δώσουμε “admin” (χωρίς τα εισαγωγικά) κι ως password εκείνο που φαίνεται στην κονσόλα, καθώς συνδεόμαστε στο VPS μέσω SSH. Η πρώτη μας δουλειά θα πρέπει να είναι η αλλαγή αυτού του προκαθορισμένου password: αρκεί ένα κλικ στο admin (πάνω δεξιά) και η επιλογή του Personal.

Μην καθυστερήσετε την αλλαγή του προκαθορισμένου password για το χρήστη admin του ownCloud. Μπορείτε αν θέλετε να αλλάξετε και το όνομά του -- και δεν χρειάζεται να επιλέξετε κάτι στο στιλ 'theAdmin' :P

Μετά την επιτυχή αλλαγή password, καλό είναι από μια κονσόλα να διαγράψουμε το αρχείο /etc/motd.tail:

admin@eyjafjallajokull:~$ sudo rm /etc/motd.tail

Όπως είναι εξαρχής ρυθμισμένο το ownCloud, δεν βλέπει καταλόγους του τοπικού filesystem παρά μόνον εκείνους που είναι κάτω από τον /var/www/owncloud/data/username/files. Αυτό αλλάζει, ενεργοποιώντας την εφαρμογή “External storage support”: Πάνω αριστερά στο web panel του ownCloud κάνουμε κλικ δίπλα από το logo, επιλέγουμε το Apps και πηγαίνουμε στην κατηγορία Not enabled. Εκεί βρίσκουμε την προαναφερθείσα εφαρμογή. Την ενεργοποιούμε με ένα κλικ στο κουμπί Enable, κάτω από την περιγραφή της.

Ενεργοποίηση της εφαρμογής 'External storage support', η οποία θα μας επιτρέψει να δείξουμε στο ownCloud τους καταλόγους στους οποίους είναι προσαρτημένα τα buckets του Storage Qloud.

Ακολούθως δίνουμε admin –> Admin –> External Storage. Για κάθε εξωτερικό μέσο αποθήκευσης ή τοπικό κατάλογο που θέλουμε να δώσουμε στο ownCloud, ορίζουμε τα ακόλουθα:

  • Folder name. Ένα όνομα του νέου μέσου, για το ownCloud. Εμείς, π.χ., τον κατάλογο με τα video tutorials τον ονομάσαμε “deltaCast”.
  • External storage. Το είδος του νέου μέσου (π.χ., Amazon S3 and compliant, Dropbox, Google Drive κ.ο.κ.) Το κατάλληλο είδος για το μέσο που τώρα θέλουμε να ορίσουμε είναι το Local.
  • Configuration. Παράμετροι, ανάλογα με το είδος του μέσου αποθήκευσης. Αν, π.χ., προηγουμένως επιλέξαμε SFTP (FTP μέσω SSH), δίνουμε τώρα τη διεύθυνση του απομακρυσμένου host, όνομα χρήστη και password — ίσως και τη διαδρομή ενός καταλόγου στο απομακρυσμένο μηχάνημα. Εμείς ως μέσο επιλέξαμε το Local, οπότε στο Configuration χρειάστηκε να δώσουμε την πλήρη διαδρομή του τοπικού καταλόγου (/mnt/sqloud/deltaCast).
  • Available for. Ποιοι χρήστες του ownCloud έχουν πρόσβαση στο νέο μέσο; Για τις δικές μας ανάγκες ζητήσαμε να έχουν πρόσβαση μόνον όσοι ανήκουν στο group ονόματι admin.

Με τη βοήθεια της εφαρμογής External Storage ορίζουμε δύο νέα μέσα αποθήκευσης τύπου Local. Στο παράδειγμά μας πρόκειται για τους δύο καταλόγους, σε καθέναν από τους οποίους είναι προσαρτημένο ένα bucket του Storage Qloud. Στο ένα bucket βρίσκονται τα τεύχη του περιοδικού (σε μορφή PDF) και στο άλλο τα video tutorials που παράγουμε για τους συνδρομητές.

Όταν τελειώσουμε με τους ορισμούς των νέων –για το ownCloud– μέσων αποθήκευσης, μπορούμε να τα δούμε από την περιοχή Files. Το καλό με το ownCloud είναι ότι επιτρέπει τη δημιουργία expiring links για αρχεία ή ολόκληρους καταλόγους — κι αυτό μας διευκολύνει στη διανομή τευχών και video tutorials.

Υπογεγραμμένο πιστοποιητικό για το ownCloud
Αν θέλαμε το ownCloud μόνο για προσωπική χρήση, τότε μάλλον θα μπορούσαμε να ζήσουμε με το προϋπάρχον self-signed πιστοποιητικό. Όμως την εγκατάσταση του ownCloud που παρουσιάζουμε, ουσιαστικά τη χρησιμοποιούν όλοι οι αναγνώστες του περιοδικού με ενεργή συνδρομή. Το να παίρνουν προειδοποιήσεις στους browsers όποτε επιχειρούν να κατεβάσουν ένα τεύχος ή ένα video tutorial, προφανώς είναι κάτι που δεν μπορούμε να ανεχτούμε.

Γενικά, ένα έγκυρο πιστοποιητικό το οποίο είναι υπογεγραμμένο από μια έμπιστη Αρχή Πιστοποίησης, δεν παρέχεται δωρεάν. Υπάρχουν όμως κι εξαιρέσεις. Η εταιρεία StartCom, για παράδειγμα, παρέχει δωρεάν πιστοποιητικά για έναν ολόκληρο χρόνο (StartSSL Free Class 1). Προκειμένου να αποκτήσουμε ένα δωρεάν πιστοποιητικό για το domain μας από τη StartCom, αρχικά επισκεπτόμαστε το δικτυακό τόπο της εταιρείας και δημιουργούμε ένα προσωπικό πιστοποιητικό. Αυτό το πιστοποιητικό αποθηκεύεται στον web browser που χρησιμοποιούμε, μας ταυτοποιεί και λειτουργεί ως authentication token προκειμένου να έχουμε πρόσβαση στις υπηρεσίες της StartCom. Προφανώς, μπορούμε –και προτείνεται– να δημιουργήσουμε ένα αντίγραφο εφεδρείας του εν λόγω πιστοποιητικού ή/και να το μεταφέρουμε σε άλλον web browser.

Για τα subdomains των domains που έχουμε στην κατοχή μας, η StartCom μάς επιτρέπει να παράγουμε δωρεάν, έγκυρα πιστοποιητικά (Class 1). Εμείς, π.χ., κατέχουμε το domain ονόματι parabing.com και με τη βοήθεια της StartCom πήραμε ένα πιστοποιητικό για το subdomain ονόματι eyjafjallajokull.parabing.com (παλαιότερα είχαμε πάρει κι ένα και για το icebox.parabing.com). Σημειώνουμε πως τα δωρεάν πιστοποιητικά της StartCom είναι κατάλληλα μόνο για ένα subdomain για κάθε domain. Αν θέλουμε ένα πιστοποιητικό για το domain και κάθε πιθανό subdomain του (π.χ., parabing.com, www.parabing.com, welcometo.parabing.com κ.ό.κ.), τότε στρεφόμαστε στα Class 2 certificates που κοστίζουν 59,90 δολάρια για δύο έτη. Σε κάθε περίπτωση, αφού γίνει έλεγχος της ιδιοκτησίας του domain και πάρουμε το πιστοποιητικό μας, καταλήγουμε με τέσσερα αρχεία:

  • ca.pem – το δημόσιο πιστοποιητικό της StartCom
  • sub.class1.server.ca.pem – το ενδιάμεσο πιστοποιητικό της StartCom
  • eyjafjallajokull.asc.key – το ιδιωτικό κλειδί για το πιστοποιητικό μας
  • eyjafjallajokull.crt – το πιστοποιητικό του domain μας κι ενός subdomain του.

Το πού πηγαίνουν τα τέσσερα αυτά αρχεία καθώς και το πώς τροποποιούμε το configuration file του Apache για το ownCloud, ώστε αντί για το self-signed πιστοποιητικό να λαμβάνεται υπόψη αυτό που μόλις αποκτήσαμε, θα το δούμε σε λίγο. Προς το παρόν, προτείνουμε να ρίξετε μια ματιά σε μερικά screenshots από τη διαδικασία λήψης δωρεάν πιστοποιητικού από τη StartCom.

Διαδικασία λήψης Class 1 certificate από StartCom
Σήμερα θα παραγγείλουμε ένα δωρεάν υπογεγραμμένο πιστοποιητικό Class 1 από τη StartCom, για το eyjafjallajokull.parabing.com. Αντί για authentication με username και password, στις υπηρεσίες της StartCom αποκτάμε πρόσβαση με χρήση του λεγόμενου προσωπικού πιστοποιητικού (personal certificate). Προκειμένου να μας δοθεί το εν λόγω πιστοποιητικό, θα χρειαστεί να παράσχουμε στοιχεία όπως ονοματεπώνυμο, ταχυδρομική διεύθυνση, email επικοινωνίας κ.ά. Στο email θα μας αποσταλεί ένα verification code, το οποίο θα πληκτρολογήσουμε στη σχετική θυρίδα. Το ιδιωτικό κλειδί του πιστοποιητικού μας παράγεται από τον ίδιο τον web browser και για την ολοκλήρωση της διαδικασίας ενδέχεται να χρειαστεί λίγος χρόνος.

Προσοχή: Για το είδος του κλειδιού φροντίστε να είναι επιλεγμένο το High Grade.

Θα έχουμε σε λίγο ένα δωρεάν, έγκυρο και υπογεγραμμένο από τη StartCom πιστοποιητικό, για το parabing.com κι ένα ακριβώς subdomain του.

Το προσωπικό μας πιστοποιητικό --ή αλλιώς client certificate-- είναι έτοιμο. Παρουσία του ταυτοποιούμαστε στη StartCom.

Το client certificate είναι εγκατεστημένο στον web browser που το παρήγαγε. Προτείνεται να κρατήσουμε ένα αντίγραφο εφεδρείας -- κι εννοείται ότι μπορούμε να μεταφέρουμε το πιστοποιητικό και σε άλλον browser.

Από το Control Panel της StartCom έχουμε, μεταξύ άλλων, τη δυνατότητα να επικυρώσουμε το domain μας (καρτέλα Validations Wizard) και κατόπιν να πάρουμε ένα υπογεγραμμένο πιστοποιητικό για το ίδιο domain (καρτέλα Certificates Wizard).

Το Control Panel της StartCom.

Πρώτα πηγαίνουμε στην καρτέλα Validations Wizard και ζητάμε επικύρωση domain: Απλά θέτουμε Type = Domain Name Validation και κάνουμε ένα κλικ στο Continue.

Ακολούθως πληκτρολογούμε το όνομα του domain μας και στα δεξιά επιλέγουμε το top-level domain. Παρατηρήστε ότι εδώ δεν καθορίζουμε subdomain. Το δωρεάν, Class 1 πιστοποιητικό που πρόκειται να πάρουμε, αφορά στο domain και σε *ένα μόνο* subdomain. Το ίδιο το subdomain θα το καθορίσουμε σε λίγο.

Από μία λίστα προκαθορισμένων διευθύνσεων email, επιλέγουμε μία έγκυρη για το domain. Σ’ αυτή τη διεύθυνση πρόκειται να λάβουμε ένα email με άλλο ένα verification code. Παρεμπιπτόντως, για το parabing.com δεν υπήρχε καμία διεύθυνση email από τις προκαθορισμένες. Ορίσαμε όμως τη hostmaster@parabing.com να είναι alias της (υπαρκτής) talk2us@parabing.com και προχωρήσαμε με την προαναφερθείσα. (Το email για το parabing.com είναι hosted από το Google Apps.)

Επιλογή διεύθυνσης email, στην οποία θα μας αποσταλεί verification code για την επαλήθευση της ιδιοκτησίας του domain.

Σε λίγα λεπτά θα λάβουμε εκείνο το email με το verification code, το οποίο και θα πληκτρολογήσουμε στην κατάλληλη θυρίδα, στο site της StartCom.

Και μόλις επαληθεύτηκε ότι πράγματι είμαστε οι κάτοχοι του parabing.com. Έφτασε η ώρα να ζητήσουμε ένα όμορφο, φαρδιά-πλατιά υπογεγραμμένο πιστοποιητικό.

Παραμένοντας στο Control Panel της StartCom, πηγαίνουμε στην καρτέλα Certificates Wizard. Φροντίζουμε ώστε να ισχύει Certificate Target = Web Server SSL/TLS Certificate.

Λίγο πριν τη δημιουργία του ιδιωτικού κλειδιού για το πιστοποιητικό μας, ορίζουμε ένα καλό password που θα το προστατεύει. Τις παραμέτρους Keysize και Secure Hash Algorithm τις αφήνουμε ως έχουν (2048 (Medium) και SHA2 (Default) αντίστοιχα).

Δεν είχαμε δημιουργήσει certificate signing request (αρχείο CSR) στο VPS μας, οπότε σ' αυτό το στάδιο κάναμε ένα κλικ στο OK ώστε να ξεκινήσει η παραγωγή του κλειδιού.

Το ιδιωτικό κλειδί για το πιστοποιητικό είναι έτοιμο και τώρα πρέπει να αντιγράψουμε όλα τα περιεχόμενα του πλαισίου που το περιλαμβάνει, σε ένα αρχείο απλού κειμένου στο VPS μας. Χρειάζεται ιδιαίτερη προσοχή εδώ ώστε κατά το copy-paste να μην αφήσουμε κάποιον χαρακτήρα εκτός, αλλά να μην εισάγουμε και κανέναν άλλον. Στις οδηγίες στο site της StartCom προτείνεται να αποθηκεύσουμε το νέο αρχείο με το όνομα ssl.key, αλλά καλύτερα να του δώσουμε ένα πιο αντιπροσωπευτικό όνομα όπως, π.χ., eyjafjallajokull.key. Το ιδιωτικό κλειδί είναι σε κρυπτογραφημένη μορφή και για να το αποκρυπτογραφήσουμε πληκτρολογούμε:

admin@eyjafjallajokull:~$ openssl rsa -in eyjafjallajokull.key -out eyjafjallajokull.asc.key
Enter pass phrase for eyjafjallajokull.key:
writing RSA key
admin@eyjafjallajokull:~$ ls -lh eyjafjallajokull.*
-rw-rw-r-- 1 admin admin 1.7K Mar 19 15:08 eyjafjallajokull.asc.key
-rw-r--r-- 1 admin admin 1.8K Mar 19 15:08 eyjafjallajokull.key
admin@eyjafjallajokull:~$

Θα χρειαστεί να δώσουμε το password που προστατεύει το κλειδί (το είχαμε καθορίσει προηγουμένως). Σε περίπτωση που η αποκρυπτογράφηση αποτύχει, π.χ., επειδή έχουν περάσει άκυροι χαρακτήρες στο eyjafjallajokull.key, μπορούμε να στραφούμε στο σχετικό εργαλείο που υπάρχει στην καρτέλα Tool Box, στο Control Panel της Start SSL (βλ. παρακάτω). Σημειώνουμε εδώ ότι το αποκρυπτογραφημένο ιδιωτικό κλειδί δεν πρέπει να διαρρεύσει — και το ίδιο θα πρέπει να ισχύει ακόμη και για την κρυπτογραφημένη του εκδοχή.

Ιδού το ιδιωτικό μας κλειδί για το domain, σε κρυπτογραφημένη μορφή. Στο στιγμιότυπο έχει προστεθεί και το έξτρα μέτρο προστασίας του blur :D

Πριν πάρουμε το δημόσιο πιστοποιητικό μας ή απλά πιστοποιητικό, οφείλουμε να του προσθέσουμε ακριβώς ένα subdomain. Εμείς, π.χ., είχαμε το domain ονόματι parabing.com (domain), οπότε πληκτρολογήσαμε “eyjafjallajokull” (χωρίς τα εισαγωγικά) κι έτσι στο πιστοποιητικό προσθέσαμε το eyjafjallajokull.parabing.com (subdomain).

Καθορισμός subdomain για το πιστοποιητικό μας.

Το πιστοποιητικό μας είναι έτοιμο για υπογραφή από τη StartCom -- για την ακρίβεια, από την αντίστοιχη Αρχή Πιστοποίησης. Θα είναι κατάλληλο για το parabing.com, καθώς και για το eyjafjallajokull.parabing.com. Για ένα πιστοποιητικό που θα ήταν κατάλληλο για το domain και κάθε πιθανό subdomain, χρειαζόμαστε ένα Class 2 certificate (με κόστος 59,90 δολάρια ανά δύο έτη).

Σ’ αυτό το σημείο έχουμε ολοκληρώσει επιτυχώς τη διαδικασία υποβολής αιτήματος για πιστοποιητικό. Δεν μπορούμε όμως να το έχουμε ακόμα — όχι τόσο γρήγορα. Η αίτησή μας πρέπει πρώτα να εγκριθεί από το προσωπικό της StartCom και πληροφορούμαστε ότι για να γίνει αυτό ενδέχεται να περάσουν έως και τρεις ώρες. Μέσα σ’ αυτό το διάστημα είναι πιθανό να κληθούμε για την υποβολή πρόσθετων στοιχείων. Στην πράξη, εμείς είχαμε θετικό email μετά από ένα περίπου τέταρτο. Σ’ αυτό πληροφορούμασταν ότι το πιστοποιητικό ήταν έτοιμο και υπογεγραμμένο κι ότι μπορούσαμε να το κατεβάσουμε από το Control Panel της StartCom.

Η διαδικασία έγκρισης του νέου πιστοποιητικού από το προσωπικό της StartCom ενδέχεται να χρειαστεί έως και τρεις ώρες, αν και κάτι μας λέει ότι γενικά περατώνεται πολύ πιο γρήγορα.

Από το Control Panel της StartCom και συγκεκριμένα από την καρτέλα Tool Box, παρέχονται το δημόσιο πιστοποιητικό μας (Retrieve Certificate), το δημόσιο πιστοποιητικό της Αρχής Πιστοποίησης, καθώς και το ενδιάμεσο πιστοποιητικό της Αρχής Πιστοποίησης (StartCom CA Certificates). Επίσης, μπορούμε να πάρουμε το ιδιωτικό κλειδί για το πιστοποιητικό μας σε μη κρυπτογραφημένη μορφή (Decrypt Private Key).

Οι χρήσιμες λειτουργίες που παρέχονται μέσω της καρτέλας Tool Box, στο Control Panel της StartCom.

Λήψη του υπογεγραμμένου δημόσιου πιστοποιητικού για το eyjafjallajokull.parabing.com. Είναι αυτό που θα βλέπουν οι clients (web browsers) κατά τις συνδέσεις HTTPS προς το ownCloud.

Σημειώνουμε ότι χρειαζόμαστε το πιστοποιητικό της Αρχής Πιστοποίησης (αρχείο ca.pem) καθώς και το ενδιάμεσο πιστοποιητικό της Αρχής Πιστοποίησης (αρχείο sub.class1.server.ca.pem).

Εγκατάσταση πιστοποιητικού
Και μετά την όλη διαδικασία, επαναλαμβάνουμε ότι στο VPS μας θα πρέπει να έχουμε τέσσερα νέα αρχεία: το πιστοποιητικό για το domain και το subdomain (eyjafjallajokull.crt), το ιδιωτικό κλειδί για το πιστοποιητικό σε μη-κρυπτογραφημένη μορφή (eyjafjallajokull.asc.crt), το πιστοποιητικό της Αρχής Πιστοποίησης (ca.pem), καθώς και το ενδιάμεσο πιστοποιητικό της Αρχής Πιστοποίησης (sub.class1.server.ca.pem). Τα αρχεία αυτά αντιγράφουμε στον κατάλογο /etc/apache2/ssl:

admin@eyjafjallajokull:~$ sudo cp eyjafjallajokull.crt eyjafjallajokull.asc.key\
ca.pem sub.class1.server.ca.pem /etc/apache2/ssl

Στη συνέχεια οφείλουμε να τροποποιήσουμε ελαφρώς το configuration file του site που σερβίρει ο Apache, για τις συνδέσεις HTTPS. Το εν λόγω αρχείο είναι το owncloud-ssl.conf και βρίσκεται στο /etc/apache2/sites-available. Με δικαιώματα διαχειριστή, το ανοίγουμε με το nano:

admin@eyjafjallajokull:~$ sudo nano /etc/apache2/sites-available/owncloud-ssl.conf

Εντός της ενότητας που ορίζει το ένα και μοναδικό virtual host, φροντίζουμε ώστε να υπάρχουν οι ακόλουθες οδηγίες:

SSLEngine on
SSLProtocol all -SSLv3 -SSLv2

# Edit to point to the files provided by your CA.
SSLCertificateFile /etc/apache2/ssl/eyjafjallajokull.crt
SSLCertificateKeyFile /etc/apache2/ssl/eyjafjallajokull.asc.key
SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem

Βεβαίως, κάποια ονόματα αρχείων ίσως διαφέρουν στη δική σας εγκατάσταση. Επίσης, οι γραμμές με τις αναφορές στο εργοστασιακό self-signed πιστοποιητικό (apache.crt) και στο αντίστοιχο κλειδί (apache.key), πρέπει είτε να “σχολιαστούν” ώστε να μη λαμβάνονται υπόψη, είτε να διαγραφούν. Αποθηκεύουμε τις αλλαγές κι επανεκκινούμε τον Apache:

admin@eyjafjallajokull:~$ sudo service apache2 restart
* Restarting web server apache2 [ OK ]
admin@eyjafjallajokull:~$

Ο τελικός έλεγχος για το αν όλα έχουν πάει καλά, γίνεται με μια επίσκεψη στο ownCloud μέσω HTTPS (π.χ., https://eyjafjallajokull.parabing.com). Δεν θα πρέπει να πάρουμε κάποια προειδοποίηση για το πιστοποιητικό, ενώ με κλικ πάνω στο σχετικό εικονίδιο του web browser θα δούμε και αναφορά σε ασφαλή σύνδεση.

Να συνδέεσαι στο ownCloud μέσω HTTPS και να σου εγγυώνται ότι η σύνδεση είναι ασφαλής: Ποιότητα!

Μια ακόμα ρύθμιση για τον Apache
Θα θυμόμαστε ίσως ότι στο δεύτερο μέρος της σειράς μας ρυθμίσαμε το iptables ώστε να μη δέχεται requests στο port 80. (Συγκεκριμένα, δέχεται requests μόνο στα ports 443/TCP και 49250/TCP.) Εξ ορισμού, ο Apache σερβίρει το ownCloud μέσω HTTPS (port 443/TCP) αλλά και μέσω απλού HTTP (port 80/TCP). Για εξοικονόμηση πόρων, λοιπόν, καλό είναι να απενεργοποιήσουμε το “απλό” site. Αν ρίξετε μια ματιά στον κατάλογο /etc/apache2/sites-enabled, θα δείτε ότι το configuration file για το απλό site, δηλαδή αυτό που σερβίρεται μέσω HTTP, είναι το 000-owncloud.conf. Η απενεργοποίηση γίνεται έτσι:

admin@eyjafjallajokull:~$ sudo a2dissite 000-owncloud.conf
Site 000-owncloud disabled.
To activate the new configuration, you need to run:
  service apache2 reload
admin@eyjafjallajokull:~$ sudo service apache2 reload
 * Reloading web server apache2
admin@eyjafjallajokull:~$

Πολύ ωραία.

Ώρα για το BitTorrent Sync
Η αλήθεια είναι ότι για το σκοπό που έχουμε φτιάξει το VPS με το ownCloud, που είναι η διαχείριση και το σερβίρισμα τευχών και βίντεο στους συνδρομητές του περιοδικού, μπορούμε να ζήσουμε άνετα και χωρίς το BitTorrent Sync: Δεν ανεβάζουμε κάθε μέρα νέα αρχεία στον file host μας, κι όποτε ανεβάζουμε επαληθεύουμε ότι το FTP πάνω από SSH (SFTP) είναι ό,τι πρέπει. Αλλά το BitTorrent Sync βολεύει τρομερά — ειδικά όσους θέλουν να απεμπλακούν από εμπορικές λύσεις τύπου Dropbox, One Drive κ.ά. Σκεφτείτε ότι έχουμε στη διάθεσή μας και τα buckets του Storage Qloud, οπότε με το BitTorrent Sync μας παρουσιάζεται μια πρώτης τάξεως ευκαιρία να αναπτύξουμε μια φθηνή κι ευέλικτη εναλλακτική του Dropbox, επί της οποίας έχουμε απόλυτο έλεγχο.

Με την εγκατάσταση του BitTorrent Sync στο Ubuntu Server έχουμε ασχοληθεί ξανά στο παρελθόν. Παρακολουθήστε, για παράδειγμα, το deltaCast s02e04. Σήμερα υφίστανται κάποιες αλλαγές σε σχέση με ό,τι δείχνουμε στο προαναφερθέν επεισόδιο, αφού στο web panel του BitTorrent Sync επιτρέπονται, πλέον, συνδέσεις HTTPS. Έτσι, σε αντίθεση με ό,τι προτείναμε στο deltaCast s02e04, στο Droplet μας δεν έχουμε τώρα εγκατεστημένο το OpenVPN: Δεν το χρειαζόμαστε προκειμένου να συνδεόμαστε ασφαλώς στο web panel του Sync. Βέβαια, κατά τη ρύθμιση του Sync του επιτρέψαμε να δέχεται μόνο συνδέσεις HTTPS από κάθε interface — και συγκεκριμένα στο port 8888/TCP. Δείτε πώς προσθέσαμε έναν κατάλληλο κανόνα στο ruleset του iptables, ώστε να επιτρέπει συνδέσεις στο port 8888/TCP:

admin@eyjafjallajokull:~$ sudo service fail2ban stop
 * Stopping authentication failure monitor fail2ban [ OK ] 
admin@eyjafjallajokull:~$ sudo iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     all  --  anywhere             anywhere            
2    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
3    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:49250
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
5    DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         
admin@eyjafjallajokull:~$ sudo iptables -I INPUT 5 -p tcp --dport 8888 -j ACCEPT
admin@eyjafjallajokull:~$ sudo iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     all  --  anywhere             anywhere            
2    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
3    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:49250
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
5    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8888
6    DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         
admin@eyjafjallajokull:~$ sudo service iptables-persistent save
* Saving rules...
*  IPv4...                                                                                                                                 
*  IPv6... [ OK ] 
admin@eyjafjallajokull:~$ sudo service fail2ban start
 * Starting authentication failure monitor fail2ban [ OK ] 
admin@eyjafjallajokull:~$

Επειδή κατά την ενεργοποίησή του το fail2ban εισάγει τους δικούς του κανόνες στο υπάρχον ruleset του iptables κι εμείς δεν θέλουμε διπλοεγγραφές στο /etc/iptables/rules.v4, πριν προσθέσουμε τον κανόνα μας απενεργοποιήσαμε προσωρινά την υπηρεσία του fail2ban. Μετά ρίξαμε μια ματιά στους εναπομείναντες κανόνες δίνοντας στο iptables τις παραμέτρους -L και –line-numbers, ώστε να δούμε πού ακριβώς πρέπει να εισαγάγουμε τον κανόνα για το port 8888/TCP. Η ζητούμενη θέση ήταν η 5, οπότε εισαγάγαμε εκεί το νέο κανόνα και μετά αποθηκεύσαμε το επαυξημένο ruleset καλώντας την υπηρεσία iptables-persistent με την οδηγία save. Τέλος, ενεργοποιήσαμε ξανά το fail2ban.

Σημείωση: Τις λίγες φορές που έχουμε λόγο να επισκεφθούμε το web panel του BitTorrent sync, αντί στη μπάρα διευθύνσεων του browser να πληκτρολογούμε τη διεύθυνση https://eyjafjallajokull.parabing.com:8888 γράφουμε κάτι σαν

https://public_ip_address:8888

Το πιστοποιητικό του BitTorrent Sync web panel είναι self-signed και παίρνουμε σχετική προειδοποίηση, αλλά σ’ αυτή την περίπτωση καθόλου δεν μας ενοχλεί. Αν στη μπάρα διευθύνσεων αντί για το IP δίναμε το domain name, επειδή ο web browser έχει ήδη το δημόσιο πιστοποιητικό του Apache για το domain αλλά τώρα υπάρχει άλλος server στην άλλη άκρη, θεωρεί ότι πρόκειται για επίθεση MiTM και δεν μας επιτρέπει να προχωρήσουμε. Σωστά πράττει.

Η σειρά σας!
Κάπως έτσι είναι ο file host μας σήμερα. Για λίγο καιρό θα τον αφήσουμε στην ησυχία του, ξέρουμε όμως ότι αργά ή γρήγορα θα αρχίσουμε και πάλι τις αλλαγές. Όταν το κάνουμε και κρίνουμε πως έχουμε κάτι ενδιαφέρον να μοιραστούμε μαζί σας, να είστε βέβαιοι ότι δεν θα ντραπούμε. Θέλουμε εξάλλου να πιστεύουμε ότι μέσα από τα τρία άρθρα αυτής της σειράς θα εμπνευστείτε όσο χρειάζεται, ώστε να φτιάξετε κι εσείς τη δική σας πλατφόρμα στο cloud — ή ακριβέστερα στα clouds. Ό,τι κι αν αποφασίσετε, όπως κι αν προχωρήσετε, σας ευχόμαστε καλή διασκέδαση. Θα χαρούμε μάλιστα πολύ αν επιστρέψετε για να μας παρουσιάσετε τα δημιουργήματά σας. Και μια τελευταία υπενθύμιση: Αν σκοπεύετε να φτιάξετε τo VPS σας στη DigitalOcean, ξεκινήστε από το ακόλουθο URL:

http://bit.ly/digocean10off

Θα έχετε αυτομάτως 10 δολάρια έκπτωση για το VPS, ενώ θα ελαφρύνετε και τα έξοδα hosting του αγαπημένου σας περιοδικού.

12 Responses to “Ένας server, δύο σύννεφα [μέρος 3/3]”

  1. nikosg5 | 21/03/2015 at 15:30

    εφάμιλλο των προσδοκιων μου, οπως παντα ;)
    μπραβο για την καλη δουλεια

    • subZraw | 21/03/2015 at 15:31

      Ευχαριστίες …και μια απορία: Το διάβασες κιόλας;! Μου πήρε τόσες μέρες να το ετοιμάσω, και το διάβασες κιόλας;! :/

      • nikosg5 | 21/03/2015 at 16:25

        Με μεγαλη αναλυση οχι να πω την αληθεια, γιατι αρκετα βηματα τα ειχα κανει ηδη. Τις αποριες μου για τα πιστοποιητικα μου τις ελυσες γτ παιδευομουν λιγο.
        Και σιγουρα δεν τελειωσα μαζι του. ΤΟ εχω ανοιχτο και ανατρεχω σιγα σιγα, αλλα και μονο απο το τι περιλαμβανει με καλυπτει

  2. excess106 | 21/03/2015 at 19:47

    Χρηστο θελω να σε ρωτησω αν το τριτο μερος θα ειναι στο επομενο τευχος του Deltahacker. Γιατι αλλιως το παω για εκτυπωση

    • subZraw | 21/03/2015 at 20:06

      Ναι, θα είναι (υποδηλώνεται κι από το αριθμητικό tag, 042). Αποφασίσαμε να βάζουμε τα άρθρα *και* online, ώστε όσοι συνδρομητές ενδιαφέρονται να έχουν γρηγορότερα πρόσβαση.

  3. drz4007 | 24/03/2015 at 22:38

    Γεια σου φίλε μου Χρήστο. Ο Βάγγος από Καλαμαριά είμαι.
    Το μήνυμα δεν έχει σχέση με το άρθρο, αλλά ήσουν η τελευταία μου επιλογή…
    Ερώτηση: Μετά από διάφορες εγκαταστάσεις/απεγκαταστάσεις GUI σε Debian 7, κάτι έχει χαλάσει ανεπανόρθωτά. Όταν κάνω login σε Gnome μου λέει Ι could not open your session and so i have started the failsafe xterm session, και με ξαναπετάει στη login screen. Έκανα πλήρη απεγκατάσταση του Gnome, του xserver-xorg, purge όλα τα conf files, δοκίμασα διαφορετικός display managers (lightdm, gdm3), έσβησα αρχεία όπως το .profile, .Xauthority, και δεν έχω καταφέρει τίποτα.
    Έχεις καμιά πρόταση πέρα από την επανεγκατάσταση;
    Ευχαριστώ εκ των προτέρων…

    • subZraw | 29/03/2015 at 11:46

      Καλησπέρα Ευάγγελε,
      Νομίζω ότι δεν θα μπορούσες να δημοσιεύσεις το ερώτημά σου σε πιο άσχετο σημείο :) Προβλήματα σαν αυτό που αναφέρεις τα θυμάμαι από παλιά. Δεν θυμάμαι όμως τις προτεινόμενες λύσεις. Η αλήθεια είναι ότι, πλέον, το Linux το χρησιμοποιώ μόνο σε servers, στους οποίους βεβαίως δεν υπάρχει περιβάλλον γραφικών — πόσο μάλλον graphical login manager. Όταν πάλι χρειάζομαι Linux με περιβάλλον γραφικών, π.χ., κατά την προετοιμασία ενός deltaCast, τότε καταφεύγω σε κάποιον hypervizor (VirtualBox ή VMware Workstation). Μεγάλη ευκολία!

      • drz4007 | 29/03/2015 at 22:43

        Thanx για τις σκέψεις anyway! Για την ιστορία, δεν απέφυγα την επανεγκατάσταση. Απλώς δεν εγκατέστησα γραφικό περιβάλλον στην αρχή. Έβαλα μετα το ΜΑΤΕ. Τώρα που φτιάχνει ο καιρός θα σε ενοχλήσουμε με το Χάροντα για κανένα καφεδάκι πάλι.
        Χαιρετώ Χρήστο!

  4. dewn735 | 16/07/2016 at 18:00

    Καλησπέρα σας.

    Έχω υλοποιήσει τα 2/3 από την συγκεκριμένη σειρά και σας ευχαριστώ για τα κατατοπιστικότατα άρθρα . Αυτό που δεν έχω καταλάβει είναι ο τρόπος με τον οποίο θα έχω την ανώνυμη περιήγηση στο Internet μέσω του VPS. Συνδέθηκα μέσω terminal στον VPS, υλοποίησα τα προτεινόμενα βήματα σε θέματα -κυρίως- ασφάλειας και μετά; Πώς θα πραγματοποιηθεί η ανώνυμη περιήγηση και θα φαίνεται προς τα έξω η WAN IP Address του VPS; Eπιπροσθέτως, δεν έχω καταλάβει την λειτουργία και χρήση του ownCloud. Κάπου έχω μπερδευτεί γενικότερα…

    Σας ευχαριστώ εκ των προτέρων.

    • subZraw | 17/07/2016 at 21:08

      Επίσης καλησπέρα,
      Η συγκεκριμένη σειρά άρθρων δεν αφορά στην ανωνυμία, ούτε στην ιδιωτικότητα. Να υποθέσω ότι αναφέρεσαι σε κάποια λύση VPN; Αν υποθέτω σωστά, δες αυτό το άρθρο –> https://deltahacker.gr/openvpn-access-server

  5. dewn735 | 18/07/2016 at 05:21

    Σας ευχαριστώ και πάλι για την άμεση απάντηση. Σωστά. Σε λύση VPN αναφέρομαι όπου έχω διαβάσει το συγκεκριμένο άρθρο το οποίο είναι εξίσου ενδιαφέρον.

    Ευάγγελος.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων