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

Μετακόμιση site σε νέο host & ενίσχυση της ασφάλειας

Πρόσφατα χρειάστηκε να μετακομίσουμε το site του deltaHacker, το οποίο βασίζεται στο WordPress, από τον VPS provider όπου βρισκόταν σε άλλον. Ένας από τους λόγους ήταν τα capital controls: σε αντίθεση με τον παλιό, ο νέος VPS provider δέχεται πληρωμές *και* από PayPal. Υπάρχουν βέβαια πολλοί άλλοι λόγοι για τους οποίους κάποιος θα ήθελε να μεταφέρει το WordPress site του. Στο παρόν άρθρο δείχνουμε τη διαδικασία που ακολουθήσαμε, σε όλη της τη λεπτομέρεια.

Ο παλιός VPS provider –ή απλά host– όπου βρισκόταν το deltaHacker.gr, ήταν η Linode. Είμαστε πολλά χρόνια εκεί, δεν είχαμε το παραμικρό πρόβλημα κι αν δεν μας είχε πιάσει η μανία να συγκεντρώσουμε όλα μας τα VPS στη Digital Ocean, πιθανώς να αφήναμε το deltaHacker στη Linode για αρκετό καιρό ακόμα. Εξαιτίας όμως των capital controls συνειδητοποιήσαμε ότι η Linode δεν μπορούσε να χρεώσει την πιστωτική μας. Βεβαίως ούτε και η Digital Ocean μπορούσε να χρεώσει πιστωτική, αλλά σε αντίθεση με τη Linode δέχεται πληρωμές και από PayPal και το wallet μας εκεί είναι σε καλή κατάσταση. Στο σημείο αυτό αξίζει να σημειώσουμε ότι και οι δύο εταιρείες γνώριζαν για τους περιορισμούς διακίνησης κεφαλαίων στη χώρα μας. Έδιναν μάλιστα περίοδο χάριτος μιας ή δύο εβδομάδων — ή τουλάχιστον αυτό ισχύει τη στιγμή που γράφεται το παρόν. Μολαταύτα, επειδή στην πραγματικότητα δεν μπορούσαμε να είμαστε βέβαιοι για το πότε θα αρθούν οι περιορισμοί, αποφασίσαμε να μεταφέρουμε το deltaHacker.gr από τη Linode στη Digital Ocean μια ώρα νωρίτερα. Διαβάστε τη διαδικασία που ακολουθήσαμε με στόχο να ελαχιστοποιήσουμε τους χρόνους της προετοιμασίας, της μεταφοράς αλλά και του downtime.

Η όλη διαδικασία, πανοραμικά
Γενικά, για λειτουργικό σύστημα στα VPS μας προτιμούμε το Ubuntu Server LTS. Είμαστε εξοικειωμένοι με το Ubuntu και πριν τη μεταφορά δεν βλέπαμε το λόγο να πειραματιστούμε με κάποιο λειτουργικό σαν το CentOS — τουλάχιστον όχι για έναν server που προορίζεται για τη φιλοξενία του deltaHacker. Στη Linode τρέχαμε Ubuntu Server 12.04 32bit LTS, αλλά για το VPS της Digital Ocean επιλέξαμε τη νεότερη έκδοση LTS, την 14.04, και μάλιστα την εκδοχή 64bit. Σε κάθε περίπτωση, το software stack πάνω στο οποίο βασιζόμαστε είναι το LEMP (Linux, nginx, MySQL και PHP). Δείτε λίγο τις ακόλουθες λίστες εργασιών, για μια μεταφορά σαν αυτή που πραγματοποιήσαμε.

Νέος host (για εμάς Digital Ocean)

  • δημιουργία VPS (με Ubuntu Server LTS 14.04 64bit)
  • εγκατάσταση software stack (LEMP)
  • ρυθμίσεις DNS, αλλά χωρίς να ενημερώσουμε τον registrar για τους νέους nameservers
  • ενημέρωση και βασικές ρυθμίσεις συστήματος, μέριμνα για ασφάλεια
  • εγκατάσταση απαραίτητων πακέτων για την ορθή λειτουργία του WordPress site

Παλιός host (για εμάς Linode)

  • εγκατάσταση κι ενεργοποίηση κάποιου maintenance plugin, όπως είναι το Maintenance Mode
  • λήψη backup βάσης και site, π.χ., με τη βοήθεια κάποιου plugin σαν το BackWPup
  • μεταφορά backup βάσης και site στο νέο VPS

Νέος host (Digital Ocean)

  • ρυθμίσεις ασφαλείας για τη MySQL
  • δημιουργία βάσης για το WordPress
  • εισαγωγή στη νέα βάση των πινάκων της βάσης από το backup
  • μεταφορά αρχείων (του site), από το backup στον κατάλληλο κατάλογο
  • ρυθμίσεις ιδιοκτησίας για τα αρχεία του site
  • τροποποίηση του wp-config.php, αν χρειάζεται
  • τροποποίηση του αρχείου του site, που χρησιμοποιεί ο nginx
  • επανεκκίνηση nginx, php5-fpm κι έλεγχος από VM/box με πειραγμένο το hosts file (στο νέο site –όχι στο παλιό– θα χρειαστεί να απενεργοποιήσουμε το Maintenance Mode plugin)
  • τροποποίηση DNS στον registrar, ώστε για το site να ισχύουν οι nameservers του νέου host
  • έλεγχος DNS propagation, π.χ., από το http://cachecheck.opendns.com
  • αρχικά οι επισκέπτες θα βλέπουν το παλιό site και το Maintenance Mode plugin, κάποια στιγμή όμως θα αρχίσουν να βλέπουν το καινούργιο
  • σε κάποιες περιπτώσεις απαιτείται εκκαθάριση της DNS cache των local resolvers — κι ο ευκολότερος τρόπος είναι με ένα reboot
  • μετά 48 ώρες είναι ασφαλές να κατεβάσουμε το παλιό site, αφού όλοι οι clients θα βλέπουν το νέο
  • bonus: αναβάθμιση της ασφάλειας στο νέο site, ώστε οι εργασίες που αφορούν στη διαχείριση της core engine, των plugins και των themes ναι μεν να γίνονται αυτόματα, αλλά μέσω SSH και με key-based authentication

Όλα αυτά τα βήματα φαίνονται πολλά — και είναι. Στην πραγματικότητα, όμως, αν η επιχείρηση της μεταφοράς γίνει οργανωμένα και μεθοδικά, τότε θα έχει ολοκληρωθεί μέσα σε ένα απόγευμα. Δεν είναι και πολύς χρόνος, θα λέγαμε. Παρακολουθήστε το σκεπτικό της εργασίας μας και τις ενέργειες που κάναμε.

Δημιουργία νέου host και DNS
Χρειαζόμαστε ένα VPS ή αλλιώς droplet στο cloud της Digital Ocean. Αυτό θα είναι ο νέος μας host. Η μέχρι τώρα εμπειρία με το deltahacker.gr έχει δείξει ότι το droplet αρκεί να διαθέτει 2GB RAM και δύο (εικονικούς) επεξεργαστές.

Σημείωση. Αν σκοπεύετε να φτιάξετε κι εσείς το VPS σας στη Digital Ocean, έχετε υπόψη ότι μπορείτε να κερδίσετε 10$ σε credit ακολουθώντας αυτό το referral URL: http://bit.ly/digocean10off
Αν το κάνετε, βοηθάτε κι εμάς να μειώσουμε τα μηνιαία έξοδα hosting. Ευχαριστούμε!

Το λειτουργικό σύστημα του VPS θέλουμε να είναι το Ubuntu Server 14.04 LTS 64bit και το software stack που χρησιμοποιούμε για το site είναι το LEMP (Linux, nginx, MySQL, PHP). Μπορούμε να ξεκινήσουμε από ένα VPS με “καθαρή” εγκατάσταση του Ubuntu Server και κατόπιν να εγκαταστήσουμε όλο το απαραίτητο λογισμικό. Σίγουρα δεν είναι η πιο βαρετή εργασία που μπορούμε να φανταστούμε. Την έχουμε όμως κάνει αρκετές φορές στο παρελθόν και τώρα βιαζόμαστε να μεταφέρουμε το site στο νέο του host, άρα αν θα μπορούσαμε να αποφύγουμε όλες αυτές τις εγκαταστάσεις και τις ρυθμίσεις θα ήταν καλά. Όπως είναι εύκολο να φανταστείτε, φυσικά και μπορούμε: Απλά, αντί για ένα “σκέτο” image με το Ubuntu Server, για το νέο μας VPS πηγαίνουμε στην κατηγορία Applications κι επιλέγουμε το LEMP on 14.04. Δείτε τα screenshots που ακολουθούν και διαβάστε τις αντίστοιχες περιγραφές για περισσότερες πληροφορίες.

Για τις ανάγκες του deltaHacker, το τρίτο κατά σειρά μεγέθους droplet είναι ό,τι πρέπει: Διαθέτει 2GB RAM, δύο εικονικούς επεξεργαστές, 40GB εικονικό δίσκο (πάνω σε SSD), καθώς και 3TB bandwidth δωρεάν, ανά μήνα. Παρατηρήστε, εξάλλου, τη θυρίδα ονόματι Droplet Hostname: Σε αυτή προτείνεται να πληκτρολογήσουμε το domain name του site που θα φιλοξενείται στο VPS, εν προκειμένω deltahacker.gr. Αυτό θα έχει ως συνέπεια τη δημιουργία σχετικού PTR record για το domain.

Επιλογή μεγέθους droplet και πληκτρολόγηση του domain, του site που θα φιλοξενεί.

Στο επόμενο βήμα επιλέγουμε τη γεωγραφική περιοχή του datacenter στο οποίο θα δημιουργηθεί και θα υφίσταται το VPS. Η συντριπτική πλειονότητα των επισκεπτών του site είναι στην Ελλάδα, οπότε μάλλον θα έπρεπε να επιλέξουμε το datacenter στη Φρανκφούρτη. Κάτι μας έπιασε όμως –μη μας ρωτήσετε τι– και στραφήκαμε στο datacenter στο Άμστερνταμ.

Σε ποιο datacenter θα κατοικεί το VPS μας;

Μεταξύ των έτοιμων images που έχουμε να επιλέξουμε για το VPS μας, είναι εκείνα στις κατηγορίες Distributions και Applications (βλ. ομώνυμες καρτέλες). Από την κατηγορία Distributions επιλέγουμε image που αντιστοιχεί σε καθαρή εγκατάσταση κάποιου λειτουργικού συστήματος όπως, π.χ., CentOS, Ubuntu Server, FreeBSD κ.ά. Από την κατηγορία Applications διατίθενται images τα οποία, εκτός από το λειτουργικό σύστημα, έχουν εγκατεστημένα software stacks — ενδεχομένως κι εφαρμογές ή υπηρεσίες. Υπάρχει, π.χ., το ownCloud 8.04 on 14.04, το οποίο είναι ένα image με Ubuntu Server 14.04 κι εγκατεστημένα τα LAMP stack και ownCloud 8.04. Για τις δικές μας ανάγκες, το LEMP on 14.04 είναι ό,τι ακριβώς θέλουμε: έχει το Ubuntu Server 14.04 LTS 64bit και LEMP stack — τίποτε άλλο.

Το image για το VPS μας έχει ήδη εγκατεστημένο LEMP stack.

Λίγο πριν δημιουργήσουμε το νέο VPS υποδεικνύουμε τέσσερα δημόσια κλειδιά, τα οποία θα πάνε στο αρχείο ~/.ssh/authorized_keys του χρήστη root. Έτσι, από τέσσερις συσκευές μας (ένα PC, δύο laptops κι ένα smartphone) θα μπορούμε να συνδεόμαστε στο VPS με ασφάλεια μέσω SSH και χωρίς να πληκτρολογούμε κάποιο password. Περισσότερα για τα SSH passwordless logins μπορείτε να διαβάσετε στο σχετικό άρθρο του τεύχους 042.

Ανέβασμα δημοσίων κλειδιών για το VPS, ώστε να συνδεόμαστε με ασφάλεια και passwordless από τα μηχανήματά μας.

Τα PTR records για τα droplets μας στη Digital Ocean. Δεν είναι υποχρεωτικό να υπάρχουν, αν όμως στέλνουμε mail από το εκάστοτε domain τότε οι άλλοι mailservers έχουν ένα λόγο λιγότερο για να μας χαρακτηρίσουν ως spammers.

Τα PTR records για τα droplets μας στη Digital Ocean.

Ιδού τα droplets μας, στο cloud της Digital Ocean. Δεν πιστεύουμε να μη γνωρίζετε την ιστορία αυτού του box.colder.xyz, ε; Αν πράγματι δεν τη γνωρίζετε, ξεκινήστε από αυτό το άρθρο στο τεύχος 043.

Ιδού τα droplets μας, στο cloud της Digital Ocean.

Οι ρυθμίσεις DNS για το deltahacker.gr, όπως απεικονίζονται από τη σχετική σελίδα της Digital Ocean. Το email για το deltahacker.gr είναι hosted από τη Google και για τον καθορισμό των σχετικών records (MX και TXT) αρκεί ένα κλικ σε σχετικό κουμπάκι, στο web control panel της Digital Ocean. Σημειώστε ότι το hosting του email από πλευράς Google έχει πάψει να είναι δωρεάν για τους νέους χρήστες της σχετικής υπηρεσίας (Google Apps for Work). Αλλά αυτό δεν πρέπει να σας προβληματίζει, αφού χάρη στη σειρά άρθρων που ξεκινά από το τεύχος 043 μπορείτε να στήσετε πανεύκολα τον δικό σας mailserver για το domain σας. Προσοχή: Σκόπιμα δεν έχουμε ακόμα ενημερώσει τον registrar, από τον οποίο έχουμε πάρει το deltahacker.gr, για τους νέους nameservers (ns1.digitalocean.com, ns2.digitalocean.com και ns3.digitalocean.com). Για όλους τους επισκέπτες του deltahacker.gr ισχύουν οι παλιοί nameservers της Linode, έτσι όλοι τους καταλήγουν στο “παλιό” VPS και φυσικά βλέπουν το site κανονικά. (Αυτό που θα βλέπουν σε λίγο είναι η σελίδα του Maintenance Mode plugin, η οποία θα πληροφορεί για τη μετακόμιση σε νέο host.)

Οι ρυθμίσεις DNS για το deltahacker.gr, όπως απεικονίζονται από τη σχετική σελίδα της Digital Ocean.

Βασικές ρυθμίσεις νέου host και ασφάλεια
Το νέο μας VPS έχει ήδη εγκατεστημένο LEMP stack, μένουν ωστόσο πολλές εργασίες σχετικές με το σύστημα και την ασφάλεια τις οποίες οφείλουμε και θέλουμε να κάνουμε τώρα. Ακολουθούμε τις οδηγίες από αυτό το άρθρο (στο τεύχος 041), ώστε:

  • να δώσουμε ένα password στον χρήστη root, για τις περιπτώσεις που χρειάζεται να κάνουμε login από τη web console της Digital Ocean
  • να φρεσκάρουμε τη λίστα του Ubuntu με τα διαθέσιμα πακέτα και ν’ αναβαθμίσουμε ήδη εγκατεστημένα για τα οποία υπάρχουν ενημερωμένες εκδόσεις
  • να ορίσουμε τη ζώνη ώρας και να φροντίσουμε για την παρουσία NTP client
  • να φτιάξουμε swap file, να το ενεργοποιήσουμε και να ενημερώσουμε σχετικά το /etc/fstab
  • να τροποποιήσουμε το /etc/ssh/sshd_config ώστε ο OpenSSH server να δέχεται συνδέσεις από τη μη-στάνταρ θύρα (22/TCP), να απαγορεύει τα root logins και να επιτρέπει μόνο passwordless authentication για τους απλούς χρήστες (με χρήση κατάλληλων κλειδιών)
  • να δημιουργήσουμε έναν λογαριασμό απλού χρήστη ο οποίος θα μπορεί να εκτελεί εργασίες με δικαιώματα root, καθώς και να φροντίσουμε ώστε να συνδέεται απομακρυσμένα στο σύστημα χωρίς την πληκτρολόγηση password αλλά με χρήση των κατάλληλων κλειδιών
  • να εγκαταστήσουμε, ρυθμίσουμε κι ενεργοποιήσουμε το fail2ban, ώστε να αποτρέπουμε βασικές επιθέσεις DoS και bruteforce attacks
  • να ρυθμίσουμε το firewall (iptables) και να βεβαιωθούμε ότι οι κανόνες μας θα ενεργοποιούνται αυτόματα κατά την εκκίνηση του συστήματος
  • να κάνουμε ό,τι χρειάζεται ώστε τυχούσες ενημερώσεις ασφαλείας να εγκαθίστανται αυτόματα

Επαναλαμβάνουμε ότι όλες αυτές οι εργασίες περιγράφονται αναλυτικά στο άρθρο του τεύχους 041. Μια τελευταία εργασία που δεν περιγράφεται στο εν λόγω άρθρο αλλά είναι απαραίτητη για την ορθή λειτουργία του WordPress site μας, αφορά στην εγκατάσταση των πακέτων php5-gd και libssh2-php:

admin@deltahacker:~$ sudo apt-get install php5-gd libssh2-php

(admin είναι το username του απλού λογαριασμού χρήστη που έχουμε δημιουργήσει στο droplet μας). Για περισσότερες πληροφορίες περί των συγκεκριμένων πακέτων, δώστε κάτι σαν

admin@deltahacker:~$ apt-cache show libssh2-php

Σ’ αυτό το σημείο ο νέος μας host είναι πανέτοιμος να δεχτεί το WordPress site του deltahacker.gr. Σημειώστε ότι, μιας και σκόπιμα δεν έχουμε ακόμα ενημερώσει τον registrar για τους νέους nameservers του deltahacker.gr, προς το παρόν ναι μεν μπορούμε να συνδεόμαστε στον νέο host μέσω SSH, αλλά μόνο με χρήση της δημόσιας διεύθυνσης IP του. Ας στρέψουμε τώρα την προσοχή μας στον παλιό host.

Απενεργοποίηση του παλιού site και πλήρες backup
Στον παλιό host φτάνουμε είτε με χρήση της δημόσιας IP του είτε με βάση το domain name του site. Από τον αγαπημένο μας web browser συνδεόμαστε στο λογαριασμό του διαχειριστή κι εγκαθιστούμε ένα plugin σαν το Maintenance Mode. Το ρυθμίζουμε και το ενεργοποιούμε, ώστε οι επισκέπτες του site να βλέπουν μια σελίδα που πληροφορεί για τη διαδικασία της μετακόμισης — και βεβαίως να μην έχουν κάποια άλλη δυνατότητα αλληλεπίδρασης με το site.

Θέλουμε το Maintenance Mode plugin να λειτουργεί χωρίς χρονικό όριο (βλ. Backtime) και οι επισκέπτες του site να αντικρίζουν το μήνυμα που έχουμε πληκτρολογήσει στο πλαίσιο Message.

Θέλουμε το Maintenance Mode plugin να λειτουργεί χωρίς χρονικό όριο (βλ. Backtime) και οι επισκέπτες του site να αντικρίζουν το μήνυμα που έχουμε πληκτρολογήσει στο πλαίσιο Message.

Να τι βλέπει ο επισκέπτης του site, όταν έχουμε το Maintenance Mode plugin ενεργοποιημένο. Δεν θα το απενεργοποιήσουμε ποτέ: όταν ολοκληρώσουμε τη μεταφορά του site στον νέο host θα αλλάξουμε τις ρυθμίσεις DNS στον registrar και, μετά από κάποιο χρόνο που απαιτείται για τη διάδοση των αλλαγών DNS, οι επισκέπτες του deltahacker.gr θα εξυπηρετούνται από τον web server του νέου host.

Να τι βλέπει ο επισκέπτης του site, όταν έχουμε το Maintenance Mode plugin ενεργοποιημένο.

Στη συνέχεια οφείλουμε να πάρουμε ένα πλήρες backup της βάσης και των αρχείων του site. Οι δύο αυτές εργασίες είναι δυνατόν να γίνουν “χειροκίνητα”, δηλαδή από τη γραμμή εντολών. Για να εκμηδενίσουμε όμως την πιθανότητα κάποιου λάθους, αξίζει να καταφύγουμε σε ένα σχετικό plugin. Αυτό που εμείς χρησιμοποιούμε είναι η δωρεάν εκδοχή του BackWPup. Το BackWPup έχει τη δυνατότητα να δημιουργεί –αυτοματοποιημένα ή χειροκίνητα– backups, τα οποία στέλνει σε διάφορες δικτυακές υπηρεσίες, όπως, π.χ., το Dropbox ή τα Amazon S3 compatible storage systems. Μπορεί, επίσης, να τα αποθηκεύει τοπικά, δηλαδή σε συγκεκριμένο κατάλογο του host. Σε κάθε περίπτωση εμείς παίρνουμε ένα –προαιρετικά συμπιεσμένο– archive που περιλαμβάνει όλα τα αρχεία και τους υποκαταλόγους του site, καθώς κι ένα μικρότερο (συμπιεσμένο) archive που αποτελεί ένα πλήρες dump της βάσης του site.

Ασχέτως του μέσου στο οποίο θα πάει το backup, φροντίζουμε ώστε να περιλαμβάνει τα πάντα. Εντάξει, ίσως δεν μας ενδιαφέρει αυτό το WordPress XML export, ούτε η λίστα με τα εγκατεστημένα plugins. Θέλουμε όμως οπωσδήποτε τσεκαρισμένα τα Database backup και File backup.

Ασχέτως του μέσου στο οποίο θα πάει το backup, φροντίζουμε ώστε να περιλαμβάνει τα πάντα.

Ειδικά για το backup της βάσης, φροντίζουμε ώστε να περιλαμβάνονται όλοι οι πίνακες ανεξαιρέτως.

Ειδικά για το backup της βάσης, φροντίζουμε ώστε να περιλαμβάνονται όλοι οι πίνακες ανεξαιρέτως.

Παρακολουθούμε ένα backup στο Dropbox εν εξελίξει. Υπόψη ότι σε κάποιες περιπτώσεις τα backups προς το Dropbox αποτυγχάνουν, επιστρέφοντας ένα μάλλον άχρηστο μήνυμα λάθους περί internal server error.

Σε κάποιες περιπτώσεις τα backups προς το Dropbox αποτυγχάνουν, επιστρέφοντας ένα μάλλον άχρηστο μήνυμα λάθους περί internal server error.

Αν δεν έχετε καλή τύχη με τα backups του BackWPup στο Dropbox, φτιάξτε ένα job ώστε το plugin να αποθηκεύει τα αντίγραφα εφεδρείας σε έναν τοπικό κατάλογο.

Αν δεν έχετε καλή τύχη με τα backups του BackWPup στο Dropbox, φτιάξτε ένα job ώστε το plugin να αποθηκεύει τα αντίγραφα εφεδρείας σε έναν τοπικό κατάλογο.

Για κάθε backup που ολοκληρώνεται επιτυχώς από το BackWPup, στο σχετικό παράθυρο με το log της διαδικασίας δεν υπάρχει ούτε καν ένα warning. Το ίδιο θα παρατηρήσουμε αν έχουμε ζητήσει από το plugin να μας στέλνει email, μετά από κάθε backup job.

Για κάθε backup που ολοκληρώνεται επιτυχώς από το BackWPup, στο σχετικό παράθυρο με το log της διαδικασίας δεν υπάρχει ούτε καν ένα warning.

Μεταφορά του backup στον νέο host
Στο σημείο αυτό υποθέτουμε ότι έχουμε ήδη πάρει πλήρες backup του site και της βάσης, π.χ., με χρήση του BackWPup plugin για το WordPress. Το backup είναι ένα μόνο συμπιεσμένο tar archive — στο παράδειγμά μας το backwpup_7140e9_2015-07-15_14-43-06.tar.gz.

Το αρχείο-backup μάς το έδωσε το BackWPup plugin για το WordPress. Είναι το συμπιεσμένο archive με όνομα backwpup_7140e9_2015-07-15_14-43-06.tar.gz και περιλαμβάνει τα αρχεία και τους καταλόγους του site, καθώς και πλήρες dump της βάσης του.

Το αρχείο-backup που μας έδωσε το BackWPup plugin για το WordPress.

Με κάποιον τρόπο πρέπει να μεταφέρουμε το εν λόγω archive στον νέο host. Υπάρχουν πολλοί τρόποι για να το πετύχουμε. Ας δούμε, π.χ., πώς το μεταφέρουμε με χρήση του εργαλείου scp:

$ scp -P 49250 backwpup*.tar.gz admin@188.226.190.206:~/tmp

Σημειώνουμε ότι:

  • το port 49250 είναι εκείνο από το οποίο αφουγκράζεται για αιτήσεις πελατών ο OpenSSH server του νέου host
  • αυτό το “admin” είναι το username του απλού χρήστη που έχουμε ήδη φτιάξει στον νέο host
  • η δημόσια αριθμητική διεύθυνση IP του νέου host είναι 188.226.190.206
  • ο tmp είναι ένας *κενός* προσωρινός κατάλογος που έχουμε δημιουργήσει στο home directory του χρήστη admin

Αν θυμόσαστε, ο OpenSSH server στον νέο host είναι ρυθμισμένος ώστε να μη δέχεται συνδέσεις SSH με πληκτρολόγηση password. Για να δουλέψει λοιπόν η παραπάνω εντολή, το δημόσιο κλειδί του χρήστη στον παλιό host –κι αναφερόμαστε σ’ εκείνον το χρήστη που τώρα χρησιμοποιεί το scp– πρέπει να βρίσκεται στο αρχείο ~/.ssh/authorized_keys του χρήστη admin, στον νέο host. Αν αυτό δεν ισχύει στην περίπτωσή σας και τώρα δεν έχετε διάθεση για προσθήκες στο authorized-keys –ούτως ή άλλως ο παλιός host δεν πρόκειται να μείνει για πολύ ακόμα όρθιος–, τότε με τη βοήθεια ενός FPT client που υποστηρίζει συνδέσεις SFTP απλά κατεβάστε το αρχείο backwpup_7140e9_2015-07-15_14-43-06.tar.gz στον τοπικό σας υπολογιστή και μετά, ξανά με τον ίδιο FTP client, ανεβάστε το στον νέο host. Αναμενόμενα, αυτός ο τρόπος μεταφοράς χρειάζεται περισσότερο χρόνο για να ολοκληρωθεί. Ίσως όμως να μη βιάζεστε πολύ σήμερα.

Η μεταφορά του αρχείου γίνεται απευθείας μεταξύ των datacenters των Linode και Digital Ocean. Όπως βλέπετε κι εσείς, η ταχύτητα μεταφοράς δεν απογοητεύει.

Η μεταφορά του αρχείου γίνεται απευθείας μεταξύ των datacenters των Linode και Digital Ocean. Όπως βλέπετε κι εσείς, η ταχύτητα μεταφοράς δεν απογοητεύει.

Δημιουργία βάσης για το site, στον νέο host
Η MySQL είναι εγκατεστημένη και για μία φορά μόνο θα τρέξουμε ένα απλό script για την προετοιμασία του MySQL server, με γνώμονα την ασφάλεια:

admin@deltahacker:~$ sudo mysql_secure_installation

Αρχικά, το script μάς ζητά να αλλάξουμε password για τον χρήστη root της MySQL (απλή συνωνυμία με τον root του λειτουργικού). Υπόψη ότι το προκαθορισμένο password του root αναφέρεται στο μήνυμα που βλέπουμε στο τερματικό, αμέσως μετά τη σύνδεσή μας στο VPS. Ακολούθως το script μάς ζητά άδεια για α) τη διαγραφή ορισμένων ανώνυμων χρηστών της MySQL, β) την απαγόρευση των απομακρυσμένων συνδέσεων για τον root (πάντα της MySQL), γ) τη διαγραφή της βάσης ονόματι test και δ) την επαναφόρτωση των πινάκων δικαιοδοσιών (privilege tables). Σε κάθε περίπτωση δίνουμε το OK απαντώντας καταφατικά.

Ας δημιουργήσουμε τώρα μία νέα βάση δεδομένων, στην οποία θα εισαγάγουμε τους πίνακες από το backup που πήραμε από τον παλιό host. Καταφεύγουμε στο εργαλείο mysql και ονομάζουμε τη νέα βάση deltahacker_db:

$ mysql -u root -p
mysql> CREATE DATABASE deltahacker_db;
Query OK, 1 row affected (0.00 sec)
mysql> CREATE USER deltahacker_user@localhost IDENTIFIED BY 'aint_no_real_password';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON deltahacker_db.* TO deltahacker_user@localhost;
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye
$

Πριν κάνουμε οτιδήποτε, χρειάστηκε να πληκτρολογήσουμε το password του χρήστη root (της MySQL). Εκτός από τη βάση ονόματι deltahacker_db, φτιάξαμε έναν νέο χρήστη της MySQL με username το deltahacker_user και password το aint_no_real_password. Στο συγκεκριμένο χρήστη δώσαμε πλήρη δικαιοδοσία επί της deltahacker_db. Εσείς, βεβαίως, θα ονομάσετε τη βάση και το χρήστη όπως προτιμάτε, ενώ ελπίζουμε να του δώσετε κι ένα καλύτερο password.

Εισαγωγή στη νέα βάση των πινάκων της παλιάς
Ξεκινάμε αποσυμπιέζοντας το archive του backup, δηλαδή το αρχείο που έχουμε πάρει από το BackWPup plugin:

$ cd ~/tmp
~/tmp$ tar zxf backwpup_7140e9_2015-07-15_14-43-06.tar.gz

Το backup της βάσης του site είναι το αρχείο deltahacker_db.sql.gz. Το αποσυμπιέζουμε πληκτρολογώντας

~/tmp$ gunzip deltahacker_db.sql.gz

και το περιεχόμενό του το εισάγουμε (import) στη βάση deltahacker_db, την οποία δημιουργήσαμε πριν λίγο:

~/tmp$ mysql -h localhost -u deltahacker_user -p deltahacker_db < deltahacker_db.sql
Enter password:
~/tmp$

Ωραία. Το αρχείο deltahacker_db.sql δεν το χρειαζόμαστε μαζί με όλα τα άλλα που πήραμε από την αποσυμπίεση του archive, οπότε το απομακρύνουμε από τον κατάλογο tmp ή ακόμη το διαγράφουμε κιόλας:

~/tmp$ rm deltahacker_db.sql

Κατάλληλη τοποθέτηση των αρχείων του site
Το αρχείο backwpup_7140e9_2015-07-15_14-43-06.tar.gz, όπως επίσης και τα deltaHacker.pluginlist.2015-07-15.txt.gz και deltaHacker.wordpress.2015-07-15.xml.gz, δεν τα χρειαζόμαστε στον κατάλογο ~/tmp. (Ειδικά τα δύο τελευταία, αναλόγως των επιλογών που έχετε κάνει στο BackWPup ίσως να μην τα έχετε στον δικό σας κατάλογο.) Μπορούμε λοιπόν είτε να τα μετακινήσουμε είτε να τα διαγράψουμε. Όλα τα υπόλοιπα αρχεία και τους καταλόγους του ~/tmp τα μεταφέρουμε στο προκαθορισμένο document root του web server: Πρόκειται για τον κατάλογο από τον οποίο σερβίρει περιεχόμενο ο nginx και για την εγκατάστασή μας είναι ο /usr/share/nginx/html. Η μεταφορά γίνεται εξαιρετικά απλά:

~/tmp$ sudo mv * /usr/share/nginx/html

Μεταβαίνουμε στον κατάλογο /usr/share/nginx/html

~/tmp$ cd /usr/share/nginx/html

κι αλλάζουμε την ιδιοκτησία και τα δικαιώματα όλων των αρχείων και καταλόγων:

/usr/share/nginx/html$ sudo chown -R www-data:www-data *

Η κίνηση αυτή δεν είναι βέλτιστη από πλευράς ασφαλείας και δεν σας την προτείνουμε. Αφήνουμε όμως προσωρινά όλα τα αρχεία και τους καταλόγους στoν χρήστη www-data και στην ομώνυμη ομάδα, ώστε, αν χρειαστεί, να είναι εύκολο ν’ αναβαθμίσουμε plugins και themes. Στο τελευταίο μέρος του παρόντος άρθρου, αφού έχουμε βεβαιωθεί ότι το deltahacker.gr σερβίρεται κανονικά από τον νέο host, θα κάνουμε όλες τις απαραίτητες ενέργειες προκειμένου να ενισχύσουμε την ασφάλεια του site.

Προς το παρόν, ανοίγουμε το αρχείο wp-config.php προς διόρθωση, π.χ., με χρήση του nano:

/usr/share/nginx/html$ sudo nano wp-config.php

Εστιάζουμε την προσοχή μας στις ακόλουθες γραμμές:

define('DB_NAME', 'deltahacker_db');
define('DB_USER', 'deltahacker_user');
define('DB_PASSWORD', 'aint_no_real_password');

Ίσως χρειαστεί να κάνουμε αλλαγές, ώστε στις μεταβλητές DB_NAME, DB_USER και DB_PASSWORD να αντιστοιχίζονται το όνομα της βάσης, το όνομα του χρήστη της κι ο κωδικός του αντίστοιχα — ακριβώς όπως τα ορίσαμε πριν λίγο. Αποθηκεύουμε τις αλλαγές στο wp-config.php κι εγκαταλείπουμε τον editor (στο nano, π.χ., δίνουμε [CTRL+O], [Enter] και μετά [CTRL+X]).

Ενημέρωση web server
Το αρχείο ρυθμίσεων που χρησιμοποιεί ο nginx προκειμένου να σερβίρει περιεχόμενο από το /usr/share/nginx/html, είναι το /etc/nginx/sites-available/default. Προτείνεται να το μετονομάσουμε και μετά να φτιάξουμε ένα νέο αρχείο με το ίδιο όνομα (default), το οποίο θα έχει τις κατάλληλες οδηγίες για το site μας:

/usr/share/nginx/html$ cd /etc/nginx/sites-available
/etc/nginx/sites-available$ sudo mv default default.orig

Εδώ είναι καλή ιδέα να μεταφέρουμε, σ’ αυτήν ακριβώς τη θέση, το αντίστοιχο αρχείο “default” που υπάρχει στο παλιό VPS — και να φροντίσουμε ώστε πράγματι να ονομάζεται default. Κατά πάσα πιθανότητα, η μόνη επέμβαση που θα κάνουμε θα αφορά στη διαδρομή του καταλόγου από τον οποίο ο nginx σερβίρει το περιεχόμενο. Δείτε, π.χ., τα περιεχόμενα το δικού μας default (στον νέο host):

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        root /usr/share/nginx/html;
        index index.php index.html index.htm;

        server_name deltahacker.gr;

        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }

        error_page 404 /404.html;
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
                root /usr/share/nginx/html;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
        }
}

Προκειμένου να ληφθούν υπόψη οι αλλαγές, επανεκκινούμε τον nginx αλλά και την php5-fpm:

/etc/nginx/sites-available$ sudo service nginx restart
 * Restarting nginx nginx
/etc/nginx/sites-available$ sudo service php5-fpm restart
php5-fpm stop/waiting
php5-fpm start/running, process 2233

Έλεγχοι και αλλαγές DNS στον registrar
Για να βεβαιωθούμε ότι όλα είναι εντάξει με το site μας στον νέο host χωρίς όμως να πειράξουμε τις ρυθμίσεις DNS στον registrar, μια ιδέα είναι να προσθέσουμε ένα κατάλληλο entry στο αρχείο hosts του υπολογιστή από τον οποίο εργαζόμαστε. Το εν λόγω αρχείο στα Unix-like συστήματα (Linux, OS X, *BSD κ.ά.) είναι κάτω από τον κατάλογο /etc, ενώ στα Windows βρίσκεται μέσα στον φάκελο %systemroot%\system32\drivers\etc, όπου το %systemroot% ταυτίζεται σχεδόν πάντα με το c:\windows. Για την τροποποίηση του hosts χρειαζόμαστε δικαιώματα διαχειριστή και η γραμμή που προσθέτουμε πρέπει να έχει τη μορφή

διεύθυνση_IP_του_νέου_VPS	deltahacker.gr	deltahacker

Δείτε στο screenshot που ακολουθεί τη γραμμή που προσθέσαμε στο hosts ενός συστήματος με openSUSE.

Το αρχείο hosts το συμβουλεύονται λειτουργικό σύστημα κι εφαρμογές πριν ακόμη ρωτήσουν κάποιον nameserver για την αριθμητική διεύθυνση ενός domain. Έτσι, με την προσθήκη που έχουμε κάνει στο /etc/hosts του συγκεκριμένου υπολογιστή με openSUSE, είμαστε σε θέση να ελέγξουμε αν όλα έχουν πάει καλά με τη μεταφορά του site στον νέο provider (Digital Ocean) πριν ακόμα δώσουμε στον registrar τους νέους nameservers για το domain. Καθώς εμείς κάνουμε τους ελέγχους μας οι επισκέπτες του deltahacker.gr εξυπηρετούνται από το παλιό VPS, αφού στον registrar είναι δηλωμένοι οι nameservers του παλιού provider (Linode).

Με την προσθήκη που έχουμε κάνει στο /etc/hosts του συγκεκριμένου υπολογιστή με openSUSE, είμαστε σε θέση να ελέγξουμε αν όλα έχουν πάει καλά με τη μεταφορά του site στον νέο provider (Digital Ocean) πριν ακόμα δώσουμε στον registrar τους νέους nameservers για το domain.

Κατά την πρώτη μας επίσκεψη στο deltahacker.gr στον νέο host (Digital Ocean), θυμόμαστε ότι το backup από τον παλιό host (Linode) ελήφθη όταν το Maintenance Mode plugin ήταν ήδη ενεργοποιημένο. Με κλικ στο Login κάτω δεξιά μπορούμε να συνδεθούμε στο site με τα στοιχεία κάποιου διαχειριστή και, με την προϋπόθεση ότι η μεταφορά έχει γίνει χωρίς λάθη, θα βλέπουμε τις σελίδες του κανονικά. Προσοχή: Κάπου εδώ οφείλουμε να απενεργοποιήσουμε το Maintenance Mode plugin (στον νέο host, όχι στον παλιό).

Κατά την πρώτη μας επίσκεψη στο deltahacker.gr στον νέο host (Digital Ocean), θυμόμαστε ότι το backup από τον παλιό host (Linode) ελήφθη όταν το Maintenance Mode plugin ήταν ήδη ενεργοποιημένο.

Αφού κάνουμε τους ελέγχους μας και βεβαιωθούμε ότι το site λειτουργεί κι αντιδρά όπως πρέπει, είναι ώρα να αφαιρέσουμε από το hosts file τη γραμμή με τη δημόσια IP για το deltahacker.gr και να ενημερώσουμε τον registrar για τους νέους DNS servers (της Digital Ocean) που εξυπηρετούν το site μας.

Αφού κάνουμε τους ελέγχους μας και βεβαιωθούμε ότι το site λειτουργεί κι αντιδρά όπως πρέπει, είναι ώρα να αφαιρέσουμε από το hosts file τη γραμμή με τη δημόσια IP για το deltahacker.gr και να ενημερώσουμε τον registrar για τους νέους DNS servers (της Digital Ocean) που εξυπηρετούν το site μας.

Οι πληροφορίες για τις αλλαγές των nameservers χρειάζονται κάποιο χρόνο προκειμένου να διαδοθούν στο παγκόσμιο σύστημα DNS. Αρχικά –και με την προϋπόθεση ότι δεν γίνεται κάποιο τοπικό resolving, π.χ., με βάση πληροφορίες στο hosts file–, όλοι όσοι επισκέπτονται το deltahacker.gr θα καταλήγουν στο site στον παλιό host (Linode) και θα βλέπουν το μήνυμα του Maintenance Mode plugin. Μετά από κάποιο χρόνο, ο οποίος στην καλύτερη περίπτωση θα είναι γύρω στη μισή ώρα, οι επισκέπτες του site θα κατευθύνονται στον νέο host και βεβαίως δεν θα βλέπουν το μήνυμα του Maintenance Mode plugin. Κατά τους ελέγχους μας από το https://cachecheck.opendns.com διαπιστώσαμε ότι χρειάστηκαν περισσότερες από τρείς ώρες προκειμένου να ενημερωθούν για τις αλλαγές οι ανά τον πλανήτη nameservers που επιβλέπει το εργαλείο CacheCheck, της OpenDNS. Επίσης, οι nameservers του ISP που χρησιμοποιούσαμε τις εβδομάδες όπου έγινε η μεταφορά, χρειάστηκαν περίπου 24 ώρες για να ενημερωθούν. Σε κάθε περίπτωση, μετά από 48 ώρες πρακτικά όλοι οι επισκέπτες του site θα εξυπηρετούνται από τους nameservers της Digital Ocean. Και τότε, είναι ασφαλές να κατεβάσουμε (shutdown) το VPS του site στον παλιό host. Προτείνεται να κρατήσουμε το αντίστοιχο image για μερικές μέρες ακόμα, αφού Ποτέ Δεν Ξέρεις (TM).

Οι πληροφορίες για τις αλλαγές των nameservers χρειάζονται κάποιο χρόνο προκειμένου να διαδοθούν στο παγκόσμιο σύστημα DNS.

Ενδυνάμωση της ασφάλειας του νέου WordPress site
Όταν μεταφέραμε τα αρχεία του backup στον κατάλογο /usr/share/nginx/html, αμέσως φροντίσαμε ώστε ο χρήστης www-data να είναι ο ιδιοκτήτης των αρχείων και των καταλόγων του site. Ακριβώς τα ίδια αρχεία και καταλόγους τα αντιστοιχίσαμε στην ομάδα www-data. O web server μας, ο nginx, τρέχει επίσης υπό το λογαριασμό του www-data. Αυτό σημαίνει ότι οι αναβαθμίσεις της core engine του WordPress, καθώς και των plugins και των themes, γίνονται πανεύκολα, είτε αυτόματα είτε μέσα από το control panel του WordPress, χωρίς φασαριόζικα μηνύματα και φασαρίες. Το ίδιο ισχύει και για τις εγκαταστάσεις ή τις διαγραφές plugins και themes.

Για λόγους ασφαλείας, όμως, όλα τα αρχεία και οι κατάλογοι του site προτείνεται να ανήκουν σε έναν άλλον, απλό χρήστη — όχι σ’ αυτόν από το λογαριασμό του οποίου τρέχει ο web server. Ανάλογες παρατηρήσεις ισχύουν και για την ομάδα (group) των αρχείων. Σε ένα τέτοιο σενάριο, προκειμένου να είναι δυνατές οι εγκαταστάσεις, οι αναβαθμίσεις, οι διαγραφές και οι ενημερώσεις μέσα από το control panel του WordPress, ο χρήστης του nginx θα πρέπει να συνδέεται στο λογαριασμό του ιδιοκτήτη των αρχείων και των καταλόγων του site. Εξ ορισμού, το WordPress μάς παροτρύνει να συνδεόμαστε μέσω FTP. Αλλά το εν λόγω πρωτόκολλο είναι εξαιρετικά επισφαλές, οπότε θα φροντίσουμε η σύνδεση να γίνεται μέσω SSH και μάλιστα με χρήση κλειδιών (passwordless). Επίσης, θα περιορίσουμε τις συνδέσεις SSH στο λογαριασμό του ιδιοκτήτη του site ώστε να επιτρέπονται μόνο τοπικά, δηλαδή από τον localhost.

Αναλυτικότερα, στο υπόλοιπο του άρθρου φροντίζουμε για τα ακόλουθα:

  • δημιουργία νέου λογαριασμού χρήστη (εμείς θα τον ονομάσουμε isafjordur)
  • ανάθεση όλων των αρχείων και των καταλόγων του site στο νέο χρήστη και στην ομάδα του νέου χρήστη
  • δημιουργία ζεύγους κλειδιών, ώστε ο χρήστης www-data να μπορεί να συνδέεται (passwordless) στο account του isafjordur
  • διευθέτηση ιδιοκτησίας κλειδιών και ενέργειες ώστε ο www-data να *είναι* σε θέση να συνδέεται στο account του isafjordur
  • διασφάλιση ότι στο λογαριασμό του isafjordur θα επιτρέπονται συνδέσεις SSH *μόνον* από τον localhost
  • επέμβαση στο wp-config.php ώστε να μη χρειάζεται να πληκτρολογούμε τα στοιχεία σύνδεσης στο λογαριασμό του isafjordur
  • δοκιμές και μεμονωμένες αλλαγές στο ιδιοκτησιακό καθεστώς, ώστε να διευκολυνόμαστε στη διαχείριση του WordPress site

Χωρίς άλλες περιστροφές, ξεκινάμε την εργασία μας με σύνδεση στο λογαριασμό του χρήστη admin και ρίχνοντας μια ματιά στα περιεχόμενα του καταλόγου /usr/share/nginx/html.

Αν ακολουθήσατε τις οδηγίες μας έως τώρα, τότε όλα τα αρχεία και οι κατάλογοι του WordPress site θα ανήκουν στο χρήστη και στην ομάδα www-data. Ο nginx τρέχει από τον λογαριασμό του www-data, επομένως οι αναβαθμίσεις της core engine γίνονται αυτόματα και πανεύκολα από το ίδιο WordPress. Το ίδιο εύκολα προσθέτουμε, αφαιρούμε κι αναβαθμίζουμε plugins και themes, πάντα μέσα από το control panel του WordPress. Το θέμα είναι ότι, για λόγους ασφαλείας, τα αρχεία και οι κατάλογοι του site προτείνεται ν’ ανήκουν σε άλλον χρήστη και σε άλλη ομάδα.

Αν ακολουθήσατε τις οδηγίες μας έως τώρα, τότε όλα τα αρχεία και οι κατάλογοι του WordPress site θα ανήκουν στο χρήστη και στην ομάδα www-data.

Δημιουργούμε ένα νέο λογαριασμό χρήστη, με όνομα isafjordur. Ταυτόχρονα θα δημιουργηθεί και μια νέα, ομώνυμη ομάδα. Δεν θα αντιστοιχίσουμε password στον χρήστη isafjordur. Το εργαλείο που θα χρησιμοποιήσουμε για τη δημιουργία του, το adduser, θα μας ρωτήσει τρεις φορές για νέο password και επαναπληκτρολόγησή του. Στις ερωτήσεις αυτές πατάμε, απλά, το [Enter].

$ sudo adduser isafjordur 
[sudo] password for admin: 
Adding user `isafjordur' ...
Adding new group `isafjordur' (1001) ...
Adding new user `isafjordur' (1001) with group `isafjordur' ...
Creating home directory `/home/isafjordur' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
No password supplied
Enter new UNIX password: 
Retype new UNIX password: 
No password supplied
Enter new UNIX password: 
Retype new UNIX password: 
No password supplied
passwd: Authentication token manipulation error
passwd: password unchanged
Try again? [y/N] n
Changing the user information for isafjordur
Enter the new value, or press ENTER for the default
	Full Name []: Ísafjörður
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
chfn: name with non-ASCII characters: 'Ísafjörður'
Is the information correct? [Y/n] y
$

Μπορεί να μη δώσαμε password στον isafjordur, χάρη όμως στις ρυθμίσεις στο /etc/ssh/sshd_config κανείς δεν μπορεί να συνδεθεί απομακρυσμένα σ’ αυτόν το λογαριασμό (επιτρέπονται μόνο τα SSH logins με χρήση κλειδιών). Μεταβαίνουμε τώρα στον κατάλογο /usr/share/nginx/html…

$ cd /usr/share/nginx/html

…κι αλλάζουμε τον χρήστη και την ομάδα όλων των αρχείων και καταλόγων από εκεί και κάτω, σε isafjordur:

/usr/share/nginx/html$ sudo chown -R isafjordur:isafjordur *

Αν σ’ αυτό το σημείο επιχειρήσουμε να αναβαθμίσουμε ένα plugin, το WordPress δεν θα μπορέσει να προχωρήσει και θα μας ζητήσει να συνδεθούμε, με κάποιον τρόπο, στο λογαριασμό του ιδιοκτήτη των αρχείων και των καταλόγων του site. Παρατηρήστε ότι αν δεν είχαμε φροντίσει να εγκαταστήσουμε τα πακέτα php5-gd και libssh2-php (το κάναμε προηγουμένως, όταν ετοιμάζαμε τον νέο host), η επιλογή για σύνδεση SSH δεν θα ήταν διαθέσιμη.

Αν σ' αυτό το σημείο επιχειρήσουμε να αναβαθμίσουμε ένα plugin, το WordPress δεν θα μπορέσει να προχωρήσει και θα μας ζητήσει να συνδεθούμε, με κάποιον τρόπο, στο λογαριασμό του ιδιοκτήτη των αρχείων και των καταλόγων του site.

Μεταβαίνουμε τώρα στο λογαριασμό του isafjordur πληκτρολογώντας

/usr/share/nginx/html$ sudo su - isafjordur

και χωρίς καμία καθυστέρηση παράγουμε ένα ζεύγος κλειδιών RSA μήκους 4096 bits (σ’ αυτή την περίπτωση, λίγη παράνοια δεν βλάπτει):

$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/isafjordur/.ssh/id_rsa): /home/isafjordur/rsa_key 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/isafjordur/rsa_key.
Your public key has been saved in /home/isafjordur/rsa_key.pub.
The key fingerprint is:
0a:39:74:e0:8c:38:9f:5d:a2:e6:1d:3f:c3:ef:26:18 isafjordur@deltahacker.gr
The key's randomart image is:
+--[ RSA 4096]----+
|    .            |
| . + .           |
|o . = o          |
| o = =           |
|  = *   S        |
| o .E* .         |
|  . .o*          |
|    . .+.        |
|       +o        |
+-----------------+
$ exit
logout

Παρατηρήστε ότι:

  • Ερωτηθήκαμε για την τοποθεσία της δημιουργίας ιδιωτικού και δημοσίου κλειδιού και πληκτρολογήσαμε /home/isafjordur/rsa_key. Έτσι, στο home directory του isafjordur θα δημιουργηθούν τα αρχεία rsa_key (ιδιωτικό κλειδί) και rsa_key.pub (δημόσιο κλειδί).
  • Δεν ορίσαμε passphrase για την προστασία του ιδιωτικού κλειδιού.
  • Μετά τη δημιουργία του ζεύγους κλειδιών βγήκαμε από το λογαριασμό του isafjordur.

Τα κλειδιά rsa_key και rsa_key.pub τα έχουμε φτιάξει για τον www-data, επομένως οφείλουμε να βεβαιωθούμε ότι μπορεί να τα διαβάζει:

/usr/share/nginx/html$ sudo chown isafjordur:www-data /home/isafjordur/rsa_key*
/usr/share/nginx/html$ sudo chmod 0640 /home/isafjordur/rsa_key*

Ωραία. Για να μπορεί ο χρήστης www-data να συνδέεται στο λογαριασμό του isafjordur με χρήση του δημοσίου κλειδιού (rsa_key.pub), κατά πρώτον πρέπει να υπάρχει ο κατάλογος /home/isafjordur/.ssh και κατά δεύτερον το αρχείο /home/isafjordur/.ssh/authorized_keys, μέσα στο οποίο θα παρατίθεται το περιεχόμενο του αρχείου rsa_key.pub. Επίσης, φροντίδα χρειάζονται το ιδιοκτησιακό καθεστώς και τα δικαιώματα πρόσβασης του καταλόγου .ssh και του αρχείου authorized_keys. Δείτε:

/usr/share/nginx/html$ sudo mkdir /home/isafjordur/.ssh
/usr/share/nginx/html$ sudo chown isafjordur:isafjordur /home/isafjordur/.ssh
/usr/share/nginx/html$ sudo chmod 0700 /home/isafjordur/.ssh

/usr/share/nginx/html$ sudo cp /home/isafjordur/rsa_key.pub /home/isafjordur/.ssh/authorized_keys

/usr/share/nginx/html$ sudo chown isafjordur:isafjordur /home/isafjordur/.ssh/authorized_keys

/usr/share/nginx/html$ sudo chmod 0644 /home/isafjordur/.ssh/authorized_keys

Οι SSH συνδέσεις στο λογαριασμό του isafjordur θέλουμε να επιτρέπονται μόνο από το localhost. Ακριβώς γι’ αυτό ανοίγουμε το αρχείο /home/isafjordur/.ssh/authorized_keys με τον αγαπημένο μας text editor και στην αρχή του πληκτρολογούμε

from="127.0.0.1"

ακολουθούμενο από ένα κενό. Δείτε, π.χ., πώς μοιάζει το δικό μας /home/isafjordur/.ssh/authorized_keys:

/usr/share/nginx/html$ sudo cat /home/isafjordur/.ssh/authorized_keys
from="127.0.0.1" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCtVs+J02y7sYvPZLOJVrztakStSMvLYEutExHHYMnIG7XJ7zpG4wzD2e/0jYcVJZLHNOot+Rqkb/6BK62Vsnkp1z7CkWZRj3MqFAQeN1IYY2TyI+VBCSal9bbh3glbix3PnCmgPwC27Z9LRKf6Ah2y1oJH0GXRZcoLcpOyqFVUvtJCk5CJHmiZkp5n3cnzzQE2CFIC/MR/5aMuORWozXrC47QE5qa5klSxC8odATgmtWOBEQ8DxgLrjXPjEOefJMlC9nj69pxumlhz5ypDBFz/wHwhrdgb8B+djUjzwJNTlZMgjvCh5Bp4IL9b0e/nMQVJpdmAoQTbRjd5m0Edpmy/qzhLGDp+JzM0ueiCUTYAD0AlmQYmt82dIXRKfeH1xfyDt2IFOrXi9neKhIDhijYLHkcO3fta2UIVmA+Q4pYixVFz9Sj0zsbt5H5SsWHe/VMRzYTvIr0b/4oG+/8DY+Amj/7EUvy7+I+YnP/sEWjyDLVcvhbtC9ED+TaNjvjcZGeY36ZN2JjZAcLinlECghVay6lo+X7V1qfnlpFtczfHzUPkZnr4lsbdDFLwKWbioNWGIQBXe3dINxetPYX1UZf26hlPxVx9bcAb0fbotSmhdhKNkY+lSp7ZOVYZCUHb2+UBYLJxY1zjFD12loehTYv4FwcPED8TupfyHPaeJgZSBw== isafjordur@deltahacker.gr

Ανοίγουμε στη συνέχεια το αρχείο wp-config.php, από τον κατάλογο /usr/share/nginx/html:

/usr/share/nginx/html$ sudo nano wp-config.php

Στο τέλος του προσθέτουμε τις ακόλουθες γραμμές:

define('FTP_PUBKEY','/home/isafjordur/rsa_key.pub');
define('FTP_PRIKEY','/home/isafjordur/rsa_key');
define('FTP_USER','isafjordur');
define('FTP_PASS','');
define('FTP_HOST','127.0.0.1:49250');

Προφανώς, στη δική σας περίπτωση οι παράμετροι FTP_PUBKEY, FTP_PRIKEY και FTP_USER θα δεχθούν διαφορετικές τιμές. Επίσης, το port στη τιμή της FTP_HOST δεν θα είναι το 49250 αλλά αυτό που έχετε ορίσει για την υπηρεσία του OpenSSH.

Μετά κι απ’ αυτό, ας επανεκκινήσουμε τον nginx:

/usr/share/nginx/html$ sudo service nginx restart
 * Restarting nginx nginx [ OK ]

Επιχειρώντας να αναβαθμίσουμε ή να εγκαταστήσουμε κάποιο plugin ή theme, στη σχετική σελίδα του WordPress θα παρατηρήσουμε ότι είναι ήδη συμπληρωμένα όλα τα απαραίτητα στοιχεία για τη σύνδεση στο λογαριασμό του isafjordur. Αρκεί μόνο να θέσουμε Connection Type = SSH2 και να κάνουμε ένα κλικ στο κουμπί Proceed, από κάτω.

Το WordPress είναι έτοιμο ν’ αναβαθμίσει ένα από τα εγκατεστημένα plugins και, χάρη στις προσθήκες μας στο wp-config.php, όλα τα στοιχεία για τη σύνδεση στο λογαριασμό του ιδιοκτήτη του site (isafjordur) είναι ήδη συμπληρωμένα. Το μόνο που χρειάζεται να κάνουμε –κι αυτό μόνο για την πρώτη φορά—είναι να φροντίσουμε ώστε Connection Type = SSH2.

Το WordPress είναι έτοιμο ν' αναβαθμίσει ένα από τα εγκατεστημένα plugins και, χάρη στις προσθήκες μας στο wp-config.php,  όλα τα στοιχεία για τη σύνδεση στο λογαριασμό του ιδιοκτήτη του site (isafjordur) είναι ήδη συμπληρωμένα. Το μόνο που χρειάζεται να κάνουμε --κι αυτό μόνο για την πρώτη φορά—είναι να φροντίσουμε ώστε Connection Type = SSH2.

Για το επόμενο plugin που επιχειρούμε ν’ αναβαθμίσουμε δεν χρειάζεται να κάνουμε κάτι και η διαδικασία ολοκληρώνεται εντελώς αυτοματοποιημένα — αλλά και με ασφάλεια.

Για το επόμενο plugin που επιχειρούμε ν' αναβαθμίσουμε δεν χρειάζεται να κάνουμε κάτι και η διαδικασία ολοκληρώνεται εντελώς αυτοματοποιημένα -- αλλά και με ασφάλεια.

Για μεμονωμένους καταλόγους ίσως θελήσουμε να αλλάξουμε το group — και συγκεκριμένα να επιστρέψουμε στο www-data. Επίσης, για τους ίδιους καταλόγους θα επιτρέψουμε την εγγραφή για τα μέλη της ομάδας www-data. Παράδειγμα: Το theme που χρησιμοποιούμε στο deltaHacker.gr υποστηρίζει τα λεγόμενα featured images. Όταν για ένα άρθρο θέλουμε να υπάρχει featured image, μέσα από τον editor του WordPress διαλέγουμε μια εικόνα (κατάλληλων διαστάσεων) για ανέβασμα. Αυτή η εικόνα πηγαίνει στον κατάλογο /usr/share/nginx/html/wp-content/xscape/upload. Προκειμένου το WordPress να είναι σε θέση ν’ ανεβάζει εκεί αρχεία, αλλάξαμε το group από isafjordur σε www-data κι επιτρέψαμε την εγγραφή για τα μέλη της ομάδας. Για παρόμοιους λόγους αναγκαστήκαμε να αλλάξουμε το group του καταλόγου /usr/share/nginx/html/wp-content/uploads –πάλι από isafjordur σε www-data– κι επιτρέψαμε την εγγραφή για τα μέλη της ομάδας.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

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