Self Hosted Cloud Server | Μέρος 6

Ολοκληρώνουμε σήμερα την σειρά Self Hosted Cloud Server με το Cosmos Server, όπου στο έκτο μέρος θα ρυθμίσουμε την πρόσβαση με SSH στον server μας αλλά και το backup των υπηρεσιών που τρέχει.

Την σειρά οδηγών Self Hosted Cloud Server γράφει ο φίλος Μητσaker. Θα τα βρείτε όλα στο link : Cosmos Server.
Αν θέλετε και εσείς να συνεισφέρετε μπορείτε να δείτε τους τρόπους : Συνεισφορά στο Cerebrux

Σε αυτή την φάση, υποθέτουμε ότι έχετε τελειώσει την εγκατάσταση και ρύθμιση του Ubuntu Server και όπως είπαμε στο πέμπτο μέρος:

εγκατάσταση του Cloudflare DDNS

Εγκατάσταση SSH στο Self Hosted Cloud Server

Υπάρχουν κάποιες περιπτώσεις που είναι χρήσιμο να έχουμε πρόσβαση μέσω SSH όταν βρισκόμαστε εκτός τοπικού δικτύου. Ένα παράδειγμα είναι και το χθεσινό που κάναμε δοκιμές με την εγκατάσταση του ‘Filebrowser’ από το Market του Cosmos και το τελευταίο κατέστη μη αποκρίσιμο μετά από μερικές περιηγήσεις. Μοναδική λύση, το SSH, για να τσεκάρουμε τι συμβαίνει και να κάνουμε επανεκκίνηση των containers.

Γιαυτό το σκοπό, θα χρησιμοποιήσουμε το Cloudflare tunnel και αυτό διότι, σε περίπτωση που δυσλειτουργήσει το Cosmos, το οποίο μας παρέχει το reverse proxy (δηλαδή πρόσβαση με τα subdomain στις εφαρμογές μας μέσω ίντερνετ), τότε το URL (π.χ ssh.123.xyz), θα πάψει να λειτουργεί. Η αρχικοποίηση και η τελική παραμετροποίηση δεν κράτησε περισσότερο από τρία λεπτά.

Πάμε να τα δούμε επιγραμματικά. Είσοδο στην Cloudflare και επιλογή του “Zero Trust” από το αριστερό μενού. Networks->Tunnels->Create a tunnel από το αριστερό μενού. Επιλέγουμε τον Cloudflared connector και πατάμε ‘Next’. Δίνουμε ένα όνομα στο Tunnel και πατάμε ‘Save tunnel’.

Επιλέγουμε το ‘Docker’ ως περιβάλλον εγκατάστασης, κάνουμε αντιγραφή την εντολή ‘Docker’, που περιλαμβάνει το τελευταίο image του Cloudflared και το Token του συγκεκριμένου Tunnel και το επικολλούμε στο Server που έχουμε κάνει είσοδο μέσω SSH.

docker run -d cloudflare/cloudflared:latest tunnel --no-autoupdate run --token aytomata-dhmioyrghmeno-token-gia-to-sygkekrimeno-tunnel

Προσθέσαμε το flag -d στην εντολή (για να πάει στο background ως υπηρεσία) γιατί διαφορετικά, μόλις κλείναμε το τερματικό, θα τερματίζονταν και η λειτουργία του connector.

Πάμε στην καρτέλα ‘Public Hostname’ και προσθέτουμε τα εξής:

Πατάμε Save hostname και είμαστε έτοιμοι!

Ή σχεδόν έτοιμοι γιατί είναι απαραίτητο να ασφαλίσουμε τη σύνδεση τουλάχιστον με μία από τις εφαρμογές που διαθέτει η Cloudflare. Αυτό μπορεί να είναι η αποστολή ενός κωδικού στο mail σου, ο αποκλεισμός συγκεκριμένων καταλήξεων e-mail, γεωγραφικός αποκλεισμός, είσοδο με διαπιστευτήρια ‘Github’ και άλλα πολλά!

Μέσα από το Zero Trust, αριστερό μενού Access->Applications->Add an application->Self-hosted προσθέτουμε το domain που θέλουμε να προστατεύσουμε μαζί με ένα όνομα, για να το θυμόμαστε, καθώς και τη διάρκεια κάθε συνεδρίας και πατάμε ‘Next’. Συμπληρώνουμε όπως παρακάτω και πατάμε ‘Next’.

Τέλος, επιλέγουμε το SSH από το πεδίο ‘Browser rendering’ και πατάμε ‘Add application’.

Τέλος, μια καλή πρακτική για την χρήση του SSH είναι να διαβάσουμε και να εφαρμόσουμε τα παρακάτω:

Backup των υπηρεσιών του Cosmos Server

Σε αυτή την φάση, σύμφωνα και με το 3 μέρος, θα πρέπει να έχουμε:

έναν δίσκο για τα δεδομένα των containers (/mnt/data),
έναν δίσκο για τα αντίγραφα ασφαλείας (/mnt/backup) του ‘/mnt/data’
και έναν αφαιρούμενο για backup2backup (για να κρατάμε λίγο πιο ήσυχο το κεφάλι μας).

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

Θέλουμε όμως να λαμβάνουμε ένα email για την επιτυχή λήψη αντιγράφων ή και την αποτυχημένη ώστε να προβούμε στους απαραίτητους ελέγχους.

Εγκαθιστούμε στον server μας την υπηρεσία ssmtp με sudo apt install ssmtp και τροποποιούμε τα αρχεία ssmtp.conf και revaliases :

sudo nano /etc/ssmtp/ssmtp.conf

προσθέτουμε τα παρακάτω, στο τέλος του αρχείου και #(comment out) όλες τις υπόλοιπες γραμμές κειμένου:

root=xrhsths@example.gr
mailhub=mail.your-server.gr:587
hostname=www.example.gr
AuthUser=xrhsths@example.gr
AuthPass=to_password_toy_mail_soy
UseSTARTTLS=yes
UseTLS=yes
FromLineOverride=yes

φυσικά, βάζετε τις κατάλληλες ρυθμίσεις για το δικό σας email.

sudo nano /etc/ssmtp/revaliases

και συμπληρώνουμε την un-commented κάτω γραμμή

# sSMTP aliases
# 
# Format:	local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.
root:xrhsths@example.gr:mail.your-server.gr:587

Για να στείλουμε δοκιμαστικό mail στον εαυτό μας, χρησιμοποιούμε την εντολή:

echo -e "Subject: This is the subject \n\n This is the body" | ssmtp xrhsths@example.gr

Cosmos Server Backup

Δημιουργούμε ένα φάκελο Server_backup_script στη διαδρομή /usr/local/bin/ του Server και με το nano φτιάχνουμε δύο αρχεία. Ένα server-backup.sh και ένα κενό αρχείο logfile.log. Tο script το καθιστούμε εκτελέσιμο με sudo chmod +x /usr/local/bin/Server_backup_script/server-backup.sh:

Ανοίγουμε το αρχείο server-backup.sh και του προσθέτουμε τον παρακάτω κώδικα:

#!/bin/bash

#Καθορισμός της διαδρομής του αρχείου log
LOG_FILE="/usr/local/bin/Server_backup_script/logfile.log"

#Καθορισμός χρονοσφραγίδας στο logfile
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")

#Εγγραφή σφαλμάτων στο logfile και τερματισμός script σε περίπτωση σφάλματος
log_error() {
    echo "[$TIMESTAMP] Error: $1" >> "$LOG_FILE"
    echo -e "Subject: Backup ERROR \n\n See /usr/local/bin/Server_backup_script/logfile.log" | ssmtp xrhsths@example.gr
    exit 1
}

#Backup του cosmos-backup.zip
echo "Δημιουργία αντιγράφου ασφαλείας του cosmos-backup.zip:"

if sudo rsync -a --delete --update /var/lib/cosmos/cosmos-backup.zip /mnt/backup/; then
    echo "Ολοκλήρωση!"
else
    log_error "Αποτυχία δημιουργίας αντιγράφου ασφαλείας του cosmos-backup.zip."
fi

# Σταμάτημα μόνο των ενεργών containers και προσθήκη εξαιρέσεων για εκείνα που δεν έχουμε λόγο να τα σταματήσουμε (π.χ cloudflare-ddns)
echo "Διακοπή λειτουργίας των containers:"

if sudo docker ps --format "{{.Names}}" | grep -v 'cloudflare-ddns' | xargs docker stop; then
    echo "Τα containers διεκόπησαν επιτυχώς!"
else
    log_error "Αποτυχία διακοπής λειτουργίας των containers."
fi

# Backup μόνο στις αλλαγές και στις τροποποιήσεις του /mnt/data και εκκίνηση των containers σε περίπτωση σφάλματος του rsync
echo "Δημιουργία αντιγράφου ασφαλείας του /mnt/data στο /mnt/backup:"

if sudo rsync -a --delete --update --exclude='cosmos-backup.zip' /mnt/data/ /mnt/backup/; then
    echo "Ολοκλήρωση!"
else
    # Εκκίνηση των containers
    if sudo docker ps -a --filter "status=exited" --format "{{.Names}}" | grep -v 'cloudflare-ddns' | xargs docker start; then
        echo "Τα containers εκκινήθηκαν επιτυχώς μετά το σφάλμα του rsync!"
    else
        log_error "Αποτυχία εκκίνησης των containers μετά το σφάλμα του rsync."
    fi
    log_error "Αποτυχία δημιουργίας αντιγράφου ασφαλείας του /mnt/data/."
fi

# Εκκίνηση των containers
echo "Εκκίνηση των containers:"

if sudo docker ps -a --filter "status=exited" --format "{{.Names}}" | grep -v 'cloudflare-ddns' | xargs docker start; then
    echo "Τα containers εκκινήθηκαν επιτυχώς!"
    echo "Ολοκλήρωση δημιουργίας αντιγράφου ασφαλείας!"
else
    log_error "Αποτυχία εκκίνησης των containers."
fi

Τέλος και ενώ είμαστε συνδεδεμένοι ως root, δίνουμε:

crontab -e

και προσθέτουμε στο κάτω μέρος :

1 5 * * * /usr/local/bin/Server_backup_script/server-backup.sh

το οποίο σημαίνει πως το σενάριο θα εκτελείται κάθε πρωί στις 05:01 και αυτό, για να επιτρέψουμε στο cronjob του Nextcloud να εκτελείται απρόσκοπτα.

Το script καταχωρεί στο αρχείο logfile.log τα σφάλματα που ενδεχομένως προκύψουν και μας τα κοινοποιεί μέσω e-mail. Το ίδιο θα συμβεί και με την επιτυχή ολοκλήρωση του και θα μας στείλει το output των εντολών.

Τώρα να φτιάξουμε και το δεύτερο script μας το οποίο θα ονομάσουμε Backup2Backup

Εάν διαθέτεις έναν ξεχασμένο εξωτερικό δίσκο ή USB Flash, θα ήτανε συνετό να το χρησιμοποιήσεις για backup της /mnt/backup διαδρομής του Server ώστε να καλύψουμε ένα επιπλέον σενάριο ενδεχόμενης αποτυχίας. Η λογική του θα είναι η εξής:

Προσάρτηση εξωτερικού δίσκου σε προκαθορισμένη διαδρομή.
Αντιγραφή αρχείων από το ‘/mnt/backup/’ (όχι από το ‘/mnt/data/’, γιατί μπορεί να χρησιμοποιείται εκείνη τη στιγμή) προς τη διαδρομή του εξωτερικού δίσκου.
Αποστολή e-mails για την εκκίνηση της εργασίας, την ολοκλήρωση και την ενδεχόμενη αποτυχία.

Συνδέουμε τον εξωτερικό δίσκο στο Server και ακολουθούμε τα βήματα που αναφέρθηκαν παραπάνω στην παράγραφο ‘Προσάρτηση των δύο επιπλέον δίσκων’. Μπορούμε να παραλείψουμε τη διαμόρφωση του σε ‘ext4’, αλλά φυσικά, θα αλλάξουμε τη διαδρομή προσάρτησης (πχ ‘/mnt/backup2backup’).

Έπειτα, με sudo nano /etc/fstab , προσθέτουμε μία επιπλέον γραμμή στο κάτω μέρος:

UUID=xxxtoUUIDtoydiskoymasxxx /mnt/backup2backup auto defaults,nofail,x-systemd.automount 0 2

Αποθηκεύουμε, εξερχόμαστε του ‘nano’ και δίνουμε: sudo mount -a για να ανανεώσουμε τις ρυθμίσεις του ‘fstab’.

Με αυτόν τον τρόπο επιτύχαμε το πρώτο βήμα της αυτόματης προσάρτησης του εξωτερικού μας δίσκου.

Ο δίσκος που χρησιμοποιούμε για το ‘backup2backup’ είναι 2,5 ιντσών, πρώτης γενιάς, χωρίς εξωτερική τροφοδοσία και με διαλλειπτική λειτουργία στην αυτόματη προσάρτησή του σε συγκεκριμένη διαδρομή (παρά την προσθήκη του στο fstab). Εάν λειτουργούσε με τον προβλεπόμενο τρόπο, θα είχαμε δημιουργήσει επιπλέον και ένα ‘udev rule’ που θα εκτελούσε αυτόματα το ‘backup2backup.sh’, όταν θα συνδέαμε το σκληρό πάνω στο server και απλά θα περιμέναμε το e-mail της ολοκλήρωσης

Πάμε τώρα να δούμε το script που περιλαμβάνει την αντιγραφή και την αποστολή των e-mails.

Δημιουργία διαδρομής (φακέλου) ‘backup2backup’ στη θέση ‘/usr/local/bin’:
sudo mkdir /usr/local/bin/backup2backup/
Μετάβαση εκεί με: cd /usr/local/bin/backup2backup/
Δημιουργία αρχείου ‘backup2backup.sh’ με το ‘nano’: sudo nano backup2backup.sh και προσθήκη τον εξής:

#!/bin/bash

# Προσάρτηση δίσκου
sudo mount UUID=xxxtoUUIDtoydiskoymasxxx /mnt/backup2backup > /dev/null

# Αναμονή τριών δευτερολέπτων
sleep 3

# Αποστολή email για την έναρξη της αντιγραφής
echo -e "Έναρξη αντιγραφής αρχείων..." | ssmtp xrhsths@example.gr > /dev/null

# Εκτέλεση rsync
rsync_output=$(sudo rsync -a --delete --update /mnt/backup /mnt/backup2backup > /dev/null

# Έλεγχος αν η εντολή ολοκληρώθηκε με επιτυχία
if [ $? -eq 0 ]; then
    # Αποστολή email για την ολοκλήρωση με το output της εντολής rsync
    echo -e "Η αντιγραφή ολοκληρώθηκε με επιτυχία." | ssmtp xrhsths@example.gr > /dev/null
else
    # Αποστολή email για την αποτυχία με το output της εντολής rsync
    echo -e "Η αντιγραφή απέτυχε." | ssmtp xrhsths@example.gr > /dev/null
fi

Αποθηκεύουμε, εξερχόμαστε του ‘nano’ και καθιστούμε εκτελέσιμο το script με:
sudo chmod +x /usr/local/bin/backup2backup/backup2backup.sh.

Αλλάζουμε σε χρήστη sudo με sudo -i , δίνουμε:
/usr/local/bin/backup2backup/backup2backup.sh και περιμένουμε, με ανοιχτό τερματικό μέχρι να έρθει το δεύτερο e-mail της ολοκλήρωσης.

Πριν κλείσουμε, διάβασε και το παρακάτω για να επεκτείνεις την κατανόησή σου σχετικά με τα backup:

Vorta Borg | Αυτόματο backup αρχείων σε εξωτερικό δίσκο και δικτυακό δίσκο

Επίλογος

Δεν υπάρχει σωστός η λάθος τρόπος να “χτίσεις” έναν Self Hosted Cloud Server από τη στιγμή που είναι γρήγορος, λειτουργικός και ασφαλής και όπως θα αντιλήφθηκες, το σημαντικότερο κομμάτι είναι αυτό του backup plan.

Ο απόλυτος έλεγχος των προσωπικών μας δεδομένων έρχεται με το τίμημα του σωστού σχεδιασμού για τη δημιουργία και τη διαχείριση των αντιγράφων ασφαλείας καθώς και της συντήρησής του (καθαρισμός, αναβαθμίσεις, προστασία από blackouts, αντιμετώπιση δυσλειτουργιών κλπ).

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

Δεν υπάρχει επίθετο, απλό ή σύνθετο, για να περιγράψει το μέγεθος της προσοχής που χρειάζεται για να μην κάνεις λάθος σε κάποια από τις γραμμές που θα κληθείς να πληκτρολογήσεις κατά την αρχικοποίηση των πάντων. Εάν κάτι δε σου δουλέψει, που σίγουρα δε θα σου δουλέψει κάτι, θα οφείλεται κυρίως σε δικό σου λάθος, παράβλεψη ή βιασύνη. Πάρε το χρόνο σου, διάβασε τις τεκμηριώσεις των εφαρμογών (τουλάχιστον για την εγκατάσταση) και διπλοτσέκαρε τα πάντα πριν τα εκτελέσεις. Θα γλυτώσεις άπειρο χρόνο αργότερα.

Δεν αναφερθήκαμε στο κόστος γενικά, διότι δύναται να χρησιμοποιήσεις συσκευές που μπορεί ήδη να διαθέτεις. Σκέψου το ως το ακριβώς αντίθετο με εκείνους τους σεφ που σου παρουσιάζουν μια μακαρονάδα του πεντάλεπτου με υλικά που έχεις ήδη στο σπίτι σου, όπως “σχοινόπρασο”, “gnocchetti sardi” και “προσούτο Ευρυτανίας”.

Είναι λοιπόν πολύ πιο πιθανό να έχεις ένα mini PC στο συρτάρι σου ή ένα παρατημένο laptop που μαζεύει υγρασία σε κάποια ντουλάπα, ένα Raspberry Pi, παρά κάτι από τα παραπάνω. Πειραματίσου ακόμα και σε VM στο PC σου και μετά, πας και σε άλλο επίπεδο.

Τα screenshots που παρέθεσα στην σειρά άρθρων, είναι πολύ πιθανόν να μην ανταποκριθούν στην πραγματικότητα όταν αποφασίσεις να ασχοληθείς και αυτό γιατί οι διαδικασίες και οι εφαρμογές αναθεωρούνται διαρκώς και αναβαθμίζονται. Μην αποκαρδιωθείς, η φιλοσοφία παραμείνει η ίδια.

Στήσαμε το Server όπως ακριβώς παρουσιάζεται, χωρίς να παραλείπονται μέρη από τη διαδικασία και τις προκλήσεις που αντιμετωπίσαμε. Ενδεικτικά, οι εφαρμογές που διατίθενται για self hosting είναι “άπειρες”· εφαρμογές που δεν ήξερες πως τις είχες ανάγκη.

Καλωσόρισες!

2 σκέψεις σχετικά με το “Self Hosted Cloud Server | Μέρος 6”

Προσθήκη σχολίου

Ο/Η Lefteros SomniusX λέει:

24-06-2024 στο 08:43

Να σημειωθεί ότι για το home server μου είχα ξεκινήσει με DietPi x86 εγκατάσταση (debian fork για sbc’s) και έβαλα Docker, Docker Compose & Portainer, και μετά σήκωσα Cosmos-Server.

Ήθελα πολύ καιρό να δω που θα το πάει ο οδηγός, για να μην καταλήξω να κάνω ότι έκανα και στο Synology της δουλειάς με τα containers (19pcs 😁) και μια λύση ψιλο-All-in-One.

Βλέπω το Cosmote-Server πολλά υποσχόμενο, και του αξίζει η ευκαιρία.

Σύντομα θα έχετε feed-back υλοποίησης και από με!

Απάντηση
1. Ο/Η Salih λέει:
  
  24-06-2024 στο 11:55
  
  Τέλεια! Περιμένουμε εντυπώσεις!