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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ένα άλλο υπέρ είναι ότι το HTTP/S είναι τόσο διαδεδομένο πρωτόκολλο που συχνά τα εταιρικά τείχη προστασίας (firewall) ρυθμίζονται με τέτοιον τρόπο ώστε να επιτρέπουν την κίνηση δεδομένων μέσω αυτών των θυρών.

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

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

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

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

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

Το μειονέκτημα του πρωτοκόλλου Git είναι η έλλειψη ταυτοποίησης. Γενικά δεν είναι επιθυμητό το πρωτόκολλο Git να είναι το μόνο πρωτόκολλο πρόσβασης στο έργο μας. Γενικά, πρέπει να το συνδυάζουμε με πρόσβαση SSH ή HTTPS για τους λίγους προγραμματιστές που έχουν πρόσβαση ώθησης (εγγραφής) και οι υπόλοιποι προγραμματιστές θα χρησιμοποιούν το git://' για πρόσβαση μόνο για ανάγνωση. Επίσης είναι πιθανότατα το πιο δύσκολο πρωτόκολλο από πλευράς ρύθμισης. Πρέπει να τρέχει το δικό του δαίμονα, που απαιτεί ρύθμιση `xinetd ή κάτι παρόμοιο, το οποίο δεν είναι πάντα απλό να γίνει. Απαιτεί επίσης πρόσβαση στη θύρα 9418 του τείχους προστασίας, θύρα που δεν είναι από τις τυποποιημένες θύρες που επιτρέπουν τα τείχη προστασίας εταιρικών δικτύων. Πίσω από τα τείχη προστασίας μεγάλων εταιριών, αυτή η ασυνήθιστη θύρα είναι συνήθως μπλοκαρισμένη.