4.1 Το Git στον διακομιστή - Τα πρωτόκολλα

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

Αυτή είναι επίσης μια καλή επιλογή για γρήγορη λήψη της εργασίας από το αποθετήριο εργασίας κάποιου άλλου. Εάν εμείς και μία συνεργάτιδά μας εργαζόμαστε στο ίδιο έργο και η συνεργάτιδά μας θέλει να ελέγξουμε τη δουλειά της, η εκτέλεση μιας εντολής όπως git pull /home/john/project είναι συχνά ευκολότερη από ό,τι η συνεργάτιδά μας να ωθήσει σε έναν απομακρυσμένο διακομιστή και εμείς να ανακτήσουμε από αυτόν.

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

Είναι σημαντικό να αναφερθεί ότι αυτή δεν είναι απαραίτητα η γρηγορότερη επιλογή, εφόσον χρησιμοποιούμε κάποιου είδους κοινό mount. Ένα τοπικό αποθετήριο είναι γρήγορο μόνον εφόσον έχουμε γρήγορη πρόσβαση στα δεδομένα. Ένα αποθετήριο σε NFS είναι συχνά πιο αργό από ένα αποθετήριο με πρόσβαση SSH στον ίδιο διακομιστή, κάτι που επιτρέπει στο Git να τρέχει σε τοπικούς σε κάθε σύστημα.

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

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

Φαίνεται ότι πλέον είναι ο πιο δημοφιλής τρόπος χρήσης του Git, αφού μπορεί να ρυθμιστεί τόσο για να ανώνυμη ανάκτηση όπως κάνει το πρωτόκολλο git:// όσο και για ώθηση με ταυτοποίηση και κρυπτογράφηση όπως το πρωτόκολλο SSH. Αντί να πρέπει να ορίσουμε διαφορετικές διευθύνσεις URL για αυτά τα δύο πράγματα, μπορούμε πλέον να χρησιμοποιήσουμε μια ενιαία διεύθυνση URL και για τα δύο. Αν προσπαθήσουμε να ωθήσουμε και το αποθετήριο απαιτεί ταυτοποίηση (όπως κανομικά πρέπει να κάνει), ο διακομιστής μπορεί να ζητήσει όνομα χρήστη και κωδικό πρόσβασης. Το ίδιο ισχύει και για την πρόσβαση ανάγνωσης.

Μάλιστα, για υπηρεσίες όπως το GitHub, η διεύθυνση URL που χρησιμοποιούμε για την προβολή του αποθετηρίου online (για παράδειγμα, https://github.com/schacon/simplegit) είναι η ίδια διεύθυνση URL που μπορούμε να χρησιμοποιήσουμε για να κλωνοποιήσουμε και, εφόσον έχουμε πρόσβαση, να ωθήσουμε.

Εάν ο διακομιστής δεν ανταποκρίνεται σε μια υπηρεσία έξυπνου HTTP του Git, ο πελάτης θα προσπαθήσει να χρησιμοποιήσει το απλούστερο πρωτόκολλο Χαζό HTTP. Το χαζό πρωτόκολλο αναμένει ότι το γυμνό αποθετήριο Git να εξυπηρετείται σαν να επρόκειτο για κανονικά αρχεία από τον web server. Η ομορφιά του χαζού HTTP είναι η απλότητα στην εγκατάστασή του. Βασικά, το μόνο που έχουμε να κάνουμε είναι να τοποθετήσουμε ένα γυμνό αποθετήριο Git κάτω από τον ριζικό κατάλογο του εγγράφου HTTP και να δημιουργήσουμε ένα συγκεκριμένο άγκιστρο post-update, και τελειώσαμε (βλ. Τα άγκιστρα του Git). Σε αυτό το σημείο, οποιοσδήποτε έχει πρόσβαση στον web server κάτω από τον οποίο έχουμε κρεμάσει το αποθετήριο, μπορεί επίσης να κλωνοποιήσει το αποθετήριο. Για να επιτρέψουμε πρόσβαση ανάγνωσης στο αποθετήριό μας μέσω HTTP, κάνουμε κάτι σαν αυτό:

Αυτό είναι όλο. Το άγκιστρο post-update που έρχεται με το Git τρέχει την κατάλληλη εντολή (git update-server-info) για να κάνει την ανάκτηση και κλωνοποίηση μέσω HTTP να λειτουργούν σωστά. Αυτή η εντολή εκτελείται όταν ωθούμε σε αυτό το αποθετήριο (ίσως μέσω SSH)· τότε, κάποιος μπορεί να κλωνοποιήσει με κάτι σαν:

Στη συγκεκριμένη περίπτωση, χρησιμοποιούμε τη διαδρομή /var/www/htdocs που είναι κοινή για διακομιστές Apache, αλλά μπορούμε να χρησιμοποιήσουμε οποιονδήποτε στατικό web server — απλά τοποθετούμε το γυμνό αποθετήριο στη διαδρομή του. Τα δεδομένα Git διακομίζονται ως απλά στατικά αρχεία (βλ. ενότητα Εσωτερική λειτουργία του Git για λεπτομέρειες σχετικά με τον τρόπο με τον οποίο διακομίζονται).

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

Θα επικεντρωθούμε στα πλεονεκτήματα της έξυπνης έκδοσης του πρωτοκόλλου HTTP.

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

Μπορούμε επίσης να διαθέτουμε τα αποθετήριά μας μόνο για ανάγνωση μέσω HTTPS, πράγμα που σημαίνει ότι μπορούμε να κρυπτογραφήσoyme τη μεταφορά του περιεχομένου· ή μπορούμε να ακόμα να κάνουμε τους πελάτες να χρησιμοποιούν ειδικά υπογεγραμμένα πιστοποιητικά SSL.

Ένα άλλο υπέρ είναι ότι το HTTPS είναι τόσο διαδεδομένο πρωτόκολλο που συχνά τα εταιρικά firewall ρυθμίζονται με τέτοιον τρόπο ώστε να επιτρέπουν την κίνηση δεδομένων μέσω αυτών των θυρών.

Το Git μέσω HTTPS εγκαθίσταται λίγο πιο δύσκολα σε σύγκριση με το SSH σε ορισμένους διακομιστές. Εκτός από αυτό, τα άλλα πρωτόκολλα δεν έχουν κανένα σημαντικό πλεονέκτημα σε σύγκριση με το πρωτόκολλο Έξυπνο HTTP όσον αφορά στο Git.

Αν χρησιμοποιούμε HTTP για ταυτοποίηση ώθησης, η παροχή των διαπιστευτηρίων είναι κάποιες φορές πιο πολύπλοκη από τη χρήση κλειδιών SSH. Ωστόσο, υπάρχουν αρκετά εργαλεία προσωρινής αποθήκευσης διαπιστευτηρίων που μπορούμε να χρησιμοποιήσουμε, συμπεριλαμβανομένων των Keychain στο MacOS και Credential Manager στα Windows, που καθιστούν τη διαδικασία ταυτοποίησης αρκετά ανώδυνη. Στην ενότητα Αποθήκευση διαπιστευτηρίων μπορούμε να δουμε πώς μπορούμε να ρυθμίσουμε ασφαλή προσωρινή αποθήκευση κωδικού πρόσβασης HTTP στο σύστημά μας.

Τo SSH έχει πολλά πλεονεκτήματα Κατ' αρχάς το SSH είναι σχετικά εύκολο να εγκατασταθεί — οι δαίμονες SSH είναι πολύ συνηθισμένοι, πολλοί διαχειριστές δικτύου έχουν εμπειρία με αυτούς και πολλά λειτουργικά συστήματα είναι εγκατεστημένα με αυτούς ή έχουν εργαλεία να τους διαχειρίζονται. Ακόμα, η πρόσβαση μέσω SSH είναι ασφαλής — όλη η μεταφορά δεδομένων είναι κρυπτογραφημένη και απαιτεί ταυτοποίηση. Τέλος, όπως και το HTTPS, το Git και το πρωτόκολο local, το SSH είναι αποδοτικό με την έννοια ότι συμπιέζει τα δεδομένα όσο είναι δυνατό πριν τη μεταφορά.

Το μειονέκτημα του SSH είναι ότι δεν υποστηρίζει ανώνυμη πρόσβαση στο αποθετήριό μας. Οι χρήστες πρέπει να έχουν πρόσβαση μέσω SSH στον υπολογιστή μας ακόμα και αν είναι μόνο-για-ανάγνωση, κάτι που δεν καθιστά την πρόσβαση μέσα από SSH ενδεδειγμένη για έργα ανοικτού κώδικα, στα οποία οι χρήστες μπορεί να θέλουν μόνο να κλωνοποιήσουν το αποθετήριό μας για να το εξετάσουν. Αν το χρησιμοποιούμε μόνο εντός του εταιρικού δικτύου μας, το SSH ίσως είναι το μοναδικό πρωτόκολλο που θα χρειαστούμε. Αν θέλουμε να επιτρέψουμε ανώνυμη πρόσβαση για ανάγνωση μόνο στα έργα μας και επίσης θέλουμε να χρησιμοποιούμε το SSH, θα πρέπει να εγκαταστήσουμε το SSH για εμάς ώστε να ωθούμε μέσα από το SSH, αλλά κάποιο άλλο πρωτόκολλο για να ανακτήσουν (fetch) όλοι οι υπόλοιποι.

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

Λόγω της έλλειψης TLS ή άλλης κρυπτογράφησης, η κλωνοποίηση μέσω git:// μπορεί να οδηγήσει σε αυθαίρετο κενό ασφάλειας εκτέλεσης κώδικα και συνεπώς πρέπει να αποφεύγεται εκτός κι αν γνωρίζουμε πολύ καλά τι κάνουμε.

Επίσης δεν έχει ταυτοποίηση, δηλαδή ο καθένας μπορεί να κλωνοποιήσει το αποθετήριο (αν και συχνά αυτό ακριβώς θέλουμε). Επίσης είναι πιθανότατα το πιο δύσκολο πρωτόκολλο από πλευράς ρύθμισης. Πρέπει να τρέχει το δικό του δαίμονα, που απαιτεί ρύθμιση xinetd ή systemd ή κάτι παρόμοιο, το οποίο δεν είναι πάντα εύκολο. Απαιτεί επίσης πρόσβαση στη θύρα 9418 του firewall, που δεν είναι κάποια από τις τυποποιημένες θύρες που επιτρέπουν τα firewall των εταιρικών δικτύων. Πίσω από τα firewall μεγάλων εταιρειών, αυτή η ασυνήθιστη θύρα είναι συνήθως μπλοκαρισμένη.