Αρχείο .gitconfig

Ένα καλό αρχείο ~/.gitconfig μπορεί να κάνει τη ζωή ενός προγραμματιστή λίγο πιο εύκολη στην καθημερινότητά του. Παρακάτω θα βρείτε ένα .gitconfig που εν συντομία κάνει τα εξής:

  • Ορίζει το όνομα και email που χρησιμοποιείται σε κάθε commit
  • Αλλάζει τα χρώματα στις διάφορες εντολές του git
  • Ενεργοποιεί τη χρήση PGP για την υπογραφή των commits (περισσότερα εδώ)
  • Προκαθορίζει το όνομα του branch όποτε δημιουργείται ένα νέο repository με git init
  • Επιλέγει τη χρήση της cache για την προσωρινή αποθήκευση συνθηματικών
  • Απενεργοποιεί τα μηνύματα old mode 100755 new mode 100644
  • Ορίζει διαφορετικό φορμάτ για τις ημερομηνίες στα logs
  • Ορίζει aliases για τις πιο κοινές εντολές του git ώστε όταν πληκτρολογείτε λάθος, να μην βγάζει σφάλμα αλλά να εκτελεί την εντολή
  • Ορίζει τέλος κάποια χρήσιμα aliases για καλύτερα και ομορφότερα git logs

Αντιγράψτε το όλο ή κομμάτια του στο δικό σας ~/.gitconfig αρχείο.

Αποθηκεύστε τις αλλαγές στο αρχείο ~/.gitconfig και επιβεβαιώστε τις με την εντολή:

Τα περιεχόμενα των αρχείων ~/.gitconfig_github και ~/.gitconfig_gitlab είναι όπως παρακάτω:

Περισσότερες πληροφορίες για τα 2 αυτά αρχεία, θα βρείτε στο άρθρο Σετάρισμα SSH και GPG Keys για GitHub και GitLab.

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

WordPress: Αυτόματη Διαγραφή Κάδου με Spam Σχόλια

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

Για να γίνει η διαχείριση των ανεπιθύμητων σχολίων πολύ πιο εύκολη υπόθεση, μπορείτε να δημιουργήσετε μια «Μαύρη λίστα σχολίων» και να αυτοματοποιήσετε το άδειασμα του «Κάδου» (Trash).

Μαύρη Λίστα Σχολίων

Στις «Ρυθμίσεις συζητήσεων» (/wp-admin/options-discussion.php), στο πεδίο «Μαύρη λίστα σχολίων» προσθέστε ανεπιθύμητες λέξεις-κλειδιά, IP διευθύνσεις, URLs κλπ., μία ανά γραμμή.

Επιλέξτε προσεκτικά τις λέξεις προκειμένου να μην διαγράφονται σχόλια από πραγματικούς χρήστες.

Για παράδειγμα, αν έχετε μια ιστοσελίδα σχετική με καζίνο, θα χρειαστεί ιδιαίτερη προσοχή να μη βάλετε στη «Μαύρη λίστα σχολίων» λέξεις σχετικές με καζίνο ή παρεμφερείς λέξεις.

«Σκανάρετε» τα σχόλια spam που λαμβάνετε και προσαρμόστε τη λίστα ανάλογα. Αν πχ λαμβάνετε πολύ σπαμ σχετικό με «pharmacy», «crypto» κλπ, τότε θα ήταν σωστό να τις προσθέσετε στη μαύρη λίστα.

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

Ρύθμιση Αυτόματης Διαγραφής Κάδου

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

Για να διαγράφονται αυτόματα τα σχόλια μετά από έναν αριθμό ημερών, προσθέτουμε την παραπάνω γραμμή στο αρχείο wp-config.php του site σας:

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

Απενεργοποίηση Κάδου

Εναλλακτικά, μπορείτε να απενεργοποιήσετε πλήρως τον Κάδο και να γίνεται άμεση διαγραφή των σχολίων, ορίζοντας τον αριθμό ημερών σε 0.

Όταν ορίσετε τη διάρκεια σε 0, θα καταργηθεί η ρύθμιση «Άδειασμα διεγραμμένων»/»Empty trash» από τη σελίδα /wp-admin/edit-comments.php?comment_status=trash και τα σχόλια θα διαγράφονται άμεσα.

Σημαντική Σημείωση

Η παραπάνω ρύθμιση για το EMPTY_TRASH_DAYS πρέπει να προστεθεί πριν από τη γραμμή του wp-config.php αρχείου:

Επιπλέον, αυτή η ρύθμιση ισχύει και για τον Κάδο για τις Σελίδες ή τα Άρθρα που γράφετε, οπότε χρησιμοποιήστε τη προσεκτικά.

Σετάρισμα SSH και GPG Keys για GitHub και GitLab

Στο άρθρο αυτό θα σας δείξουμε πως να σετάρετε SSH και GPG keys για χρήση με GitHub και GitLab. Θα δημιουργήσουμε από ένα SSH και από ένα GPG key ξεχωριστά για κάθε πλατφόρμα.

Η χρήση SSH keys είναι η ασφαλέστερη και προτιμητέα επιλογή προκειμένου να συνδέεστε με το GitHub /GitLab χωρίς να δίνετε κάθε φορά username/password.

Επίσης, με τα GPG keys, μπορείτε να βάζετε την ψηφιακή σας «υπογραφή» σε κάθε commit που κάνετε σε ένα repository, πιστοποιώντας την ταυτότητά σας ως author του συγκεκριμένου κώδικα που κάνατε commit. Αν και δεν προσφέρει παραπάνω ασφάλεια, εντούτοις, είναι καλή πρακτική.

Φανταστείτε ένα δημοφιλές repository με ανοιχτό κώδικα όπου πολλοί χρήστες κάνουν commit. Κάποιος πολύ εύκολα μπορεί να χρησιμοποιήσει το όνομα και το email σας στις ρυθμίσεις --author του git. Π.χ. git commit --author="John Doe <example@example.com και να κάνει commit κακόβουλο κώδικα προκειμένου να ξεγελάσει αυτόν ή αυτούς που θα κάνουν αποδοχή και merge τον κώδικα.

Με τη χρήση GPG key, το commit από κάποιον που δεν μπορεί να επαληθεύσει ότι είναι κάτοχος του email σας, δεν είναι ψηφιακά υπογεγραμμένο, εμφανίζεται με το badge unverified στο GitHub/GitLab και δεν μπορεί έτσι να γίνει εύκολα merge.

Το tutorial είναι αρκετά μεγάλο, οπότε φτιάξτε έναν καφέ και ας ξεκινήσουμε. Να σημειωθεί ότι οι ρυθμίσεις γίνονται σε λειτουργικό σύστημα Linux.

Προτού Ξεκινήσουμε

Πρωτού ξεκινήσουμε, θα χρειαστούμε τα εξής:

  • το username μας στο GitHub το οποίο μπορούμε να το βρούμε στη σελίδα https://github.com/settings/profile.
  • το username και user id στο GitLab τα οποία βρίσκουμε στη διεύθυνση https://gitlab.com/-/user_settings/profile.
  • το noreply email που μας παρέχει το GitHub. Είναι της μορφής [github_username]@users.noreply.github.com
  • το noreply email που μας παρέχει το GitLab. Είναι της μορφής [gitlab_userid]-[gitlab_username]@users.noreply.gitlab.com

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

Για να ενεργοποιήσετε το noreply email στο GitHub, θα πρέπει να πάτε στη διεύθυνση https://github.com/settings/emails και να κάνετε τικ στην επιλογή «Keep my email addresses private».

Στο GitLab θα πρέπει να πάτε στις ρυθμίσεις του προφίλ σας στη διεύθυνση https://gitlab.com/-/user_settings/profile και στην επιλογή «Commit email» να επιλέξετε «Use a private email …».

Ρυθμίσεις SSH

Δημιουργία SSH Keys

Ξεκινάμε δημιουργώντας  ξεχωριστάssh κλειδιά για το GitHub και το GitLab.

Θα χρησιμοποιήσουμε το ssh-keygen και τον αλγόριθμο ed25519 για να δημιουργήσουμε τα SSH keys. Μεγάλη προσοχή να δίνετε στα password που θα χρησιμοποιήσετε. Να είναι διαφορετικά, με πολλούς χαρακτήρες και με όσο μεγαλύτερη εντροπία γίνεται.

Για το GitHub χρησιμοποιούμε στο terminal την εντολή:

και για το GitLab την εντολή:

Πηγαίνουμε στο φάκελο ~/.ssh και εκεί θα δούμε τα κλειδιά. Αυτά με την κατάληξη .pub είναι τα δημόσια κλειδιά που θα καταχωρήσουμε στο GitHub και στο GibLab:

Καταχώρηση SSH Keys Σε GitHub και GitLab

Στη συνέχεια θα καταχωρήσουμε τα SSH keys σε GitHub και στη συνέχεια σε GitLab.

Πρώτα αντιγράφουμε το δημόσιο κλειδί του GitHub με τη βοήθεια του xclip στο clipboard:

Έπειτα, πάμε στη διεύθυνση https://github.com/settings/keys και πατάμε το κουμπί «New SSH key». Στην επόμενη σελίδα, δίνουμε έναν τίτλο για το κλειδί στο πεδίο «Title» και κάνουμε επικόλληση στο πεδίο «Key». Τέλος πατάμε το κουμπί «Add SSH key» για να αποθηκευθεί το κλειδί.

Κάνουμε την ίδια διαδικασία στο GitLab.

Αντιγράφουμε το δημόσιο κλειδί του GitLab:

Πάμε στη διεύθυνση https://gitlab.com/-/user_settings/ssh_keys, πατάμε το κουμπί «Add new key», δίνουμε έναν τίτλο στο πεδίο «Title», κάνουμε επικόλληση στο πεδίο «Key» και τέλος πατάμε το κουμπί «Add key».

Παραμετροποίηση SSH Config

Μέχρι στιγμής, έχουμε δημιουργήσει τα SSH keys, τα έχουμε καταχωρήσει σε GitHub και GitLab αλλά όταν κάνουμε πχ git pull ή git push κλπ, το git δε γνωρίζει ποιο SSH κλειδί να χρησιμοποιήσει.

Θα πρέπει να κάνουμε κάποιες ρυθμίσεις τοπικά στο SSH προκειμένου όταν για παράδειγμα, δουλεύουμε σε ένα repository το οποίο φιλοξενείται στο GitHub και κάνουμε πχ git push, αυτόματα να γίνει η επιλογή του SSH key για το GitHub id_ed25519_github.

Δημιουργούμε ένα αρχείο ~/.ssh/config με την εντολή:

ή αν το αρχείο ήδη υπάρχει, το ανοίγουμε με:

Βάζουμε τις παρακάτω «οδηγίες» στο αρχείο και το αποθηκεύουμε:

Έλεγχος Σωστής Λειτουργίας SSH

Μπορούμε πλέον να ελέγξουμε αν όλα πήγαν καλά μέχρι στιγμής.

Στο terminal δίνουμε την εντολή:

Επειδή το SSH key χρησιμοποιείται για πρώτη φορά, θα εμφανιστεί κάτι σαν το ακόλουθο μήνυμα:

Θα απαντήσουμε yes και θα μας δώσει το μήνυμα:

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

Ομοίως και για το GitLab, δίνουμε την εντολή:

μας ζητείται το password και μετά θα πρέπει να εμφανιστεί το μήνυμα:

Αυτό σημαίνει ότι όταν κάναμε ssh, με βάσει τις ρυθμίσεις στο ~/.ssh/config, χρησιμοποιήθηκε το σωστό key για GitHub και GitLab.

Όλα πλέον είναι εντάξει με τις ρυθμίσεις για SSH και όποτε «σπρώχνουμε» κώδικα, δε θα μας ζητείται username και password, ενώ θα χρησιμοποιείται το αντίστοιχο SSH key. Πλέον μπορούμε να συνεχίσουμε με τα GPG keys!

Ρυθμίσεις GPG

Δημιουργία GPG Keys

Δημιουργούμε το πρώτο GPG key για το GitHub στο terminal με την εντολή:

Θα εμφανιστούν κάποιες ερωτήσεις σχετικά με τον τύπο του κλειδιού, το μέγεθος του κλειδιού, και τη διάρκειά του. Σε όλα πατάμε το Enter προκειμένου να επιλεχθούν οι default τιμές.

Στη συνέχεια δίνουμε το όνομά μας και τη διεύθυνση email.

Προσέχουμε, η διεύθυνση email να είναι η [github_username]@users.noreply.github.com ή εναλλακτικά το προσωπικό/επαγγελματικό email που έχουμε δώσει στο GitHub. Είναι η ίδια διεύθυνση email που χρησιμοποιήσαμε νωρίτερα για τη δημιουργία του SSH key.

Προσέχουμε επίσης να δώσουμε έναν κωδικό-password που θα έχει μεγάλη εντροπία.

Στο τέλος θα εμφανιστεί ένα μήνυμα επιβεβαίωσης όπως το παρακάτω:

Αυτό σημαίνει ότι δημιουργήθηκε το GPG key επιτυχώς.

Συνεχίζουμε με το GPG key για το GitHub χρησιμοποιώντας την ίδια εντολή:

Πατάμε Enter για να γίνει επιλογή των default τιμών και δίνουμε το όνομα και το email μας.

Προσέχουμε και πάλι να δώσουμε το σωστό email. Αυτό είναι το email του λογαριασμού μας στο GitHub ή καλύτερα το  [gitlab_userid]-[gitlab_username]@users.noreply.gitlab.com (ίδιο με αυτό που χρησιμοποιήσαμε κατά τη δημιουργία του SSH key για το GitHub).

Έλεγχος Κλειδιών GPG

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

Θα εμφανιστεί το παρακάτω μήνυμα:

Αυτό που είναι σημαντικό είναι το ID του κάθε GPG key το οποίο είναι το string αμέσως μετά το rsa4096/ στη γραμμή sec, δηλαδή το AAAAAAAAAA111111 για το GitHub και το BBBBBBBBBB222222 για το GitLab.

Θα μας χρειαστούν για να κάνουμε εξαγωγή/αντιγραφή των κλειδιών προκειμένου να τα καταχωρήσουμε στις δύο πλατφόρμες.

Να σημειώσουμε ότι τα IDs των κλειδιών AAAAAAAAAA111111 και BBBBBBBBBB222222 είναι τυχαία και δίνονται μόνο ως παράδειγμα για τους σκοπούς αυτού του άρθρου.

Καταχώρηση GPG Keys Σε GitHub και GitLab

Τώρα θα προσθέσουμε τα δύο GPG keys σε GitHub και GitLab.

Πρώτα χρησιμοποιούμε την παρακάτω εντολή για την εξαγωγή του public key. Προσέχουμε να χρησιμοποιήσουμε το σωστό GPG key ID για το GitHub, δηλαδή το ΑΑΑΑΑΑΑΑΑΑ111111:

Θα εμφανιστεί το public key με την παρακάτω μορφή:

Κάνουμε αντιγραφή το παραπάνω μήνυμα, πάμε στη διεύθυνση https://github.com/settings/keys και πατάμε το κουμπί «New GPG key». Δίνουμε έναν τίτλο στο πεδίο «Title», κάνουμε επικόλληση στο πεδίο «Key» και πατάμε το κουμπί «Add GPG key». Πλέον το κλειδί, έχει καταχωρηθεί στο GitHub.

Θα επαναλάβουμε την ίδια διαδικασία στο GitLab. Κάνουμε εξαγωγή το public key χρησιμοποιώντας το αντίστοιχο GPG key ID για το GitLab, δηλαδή BBBBBBBBBB222222:

Θα εμφανιστεί το public key με την παρακάτω μορφή:

Κάνουμε αντιγραφή το παραπάνω μήνυμα, πάμε στη διεύθυνση https://gitlab.com/-/user_settings/gpg_keys, και πατάμε το κουμπί «Add new key». Κάνουμε επικόλληση στο πεδίο «Key» και πατάμε το κουμπί «Add key». Πλέον το κλειδί, έχει καταχωρηθεί στο GitLab.

Παραμετροποίηση Git Config Για Χρήση GPG Keys

Θα χρειαστεί τώρα να κάνουμε κάποιες αλλαγές στις τοπικές ρυθμίσεις του git προκειμένου όταν κάνουμε commit σε GitHub repository να χρησιμοποιεί το GPG key του GitHub, και αντίστοιχα για commits σε repositories που φιλοξενούνται στο GitLab, το key του GitLab.

Δημιουργούμε τα εξής 2 αρχεία:

  • ~/.gitconfig_github
  • ~/.gitconfig_gitlab

Ανοίγουμε το αρχείο ~/.gitconfig_github με nano ~/.gitconfig_github (ή τον editor της επιλογής μας) και προσθέτουμε το παρακάτω:

και στο ~/.gitconfig_gitlab βάζουμε τα εξής:

Προσέχουμε ότι σε κάθε αρχείο, χρησιμοποιούμε το GPG key ID και το αντίστοιχο email που χρησιμοποιήσαμε όταν το δημιουργήσαμε. Δηλαδή, το GPG key ID του GitHub μαζί με το email του GitHub, και το αντίστοιχο key ID του GitLab μαζί με το email του GitLab.

Ανοίγουμε το αρχείο ~/.gitconfig:

και βάζουμε τις ακόλουθες «οδηγίες»:

Με λίγα λόγια, δώσαμε «οδηγίες» στο Git, όταν το git remote URL περιέχει github.com τότε θα χρησιμοποιηθεί το αρχείο ~/.gitconfig_github και αν το remote URL περιέχει το gitlab.com θα χρησιμοποιηθεί το αρχείο ~/.gitconfig_gitlab.

ΠΡΟΣΟΧΗ!!! Η οδηγία-συνθήκη [includeIf <condition>] δουλεύει μόνο σε εκδόσεις Git ανώτερες του 2.36. Ελέγξτε την έκδοσή σας με git --version και κάντε αναβάθμιση αν χρειαστεί.

Τελικός Έλεγχος SSH και GPG Κλειδιών

Προκειμένου να ελέγξετε ότι όλα πήγαν καλά, δημιουργήστε ένα νέο – κενό repository στο GitHub και άλλο ένα στο GitLab. Δημιουργήστε αντίστοιχα στον υπολογιστή σας 2 μικρά απλά git projects με ένα άδειο README.md αρχείο μόνο. Κάντε τα commit και push.

Εκτός απροόπτου, ο κώδικας θα ανέβει στα 2 repositories χωρίς να σας ζητηθεί να δώσετε username/password. Έχει γίνει σωστά η χρήση των δύο SSH κλειδιών που δημιουργήσαμε!

Στη συνέχεια, πηγαίνετε στις σελίδες των repositories στο GitHub και GitLab, όπου θα δείτε το αρχείο README.md, και μετά ελέγξτε τα commits.

Θα δείτε ότι και τα 2 commits σε GitHub και GitLab έχουν ένα badge που λέει «Verified» όπως το παρακάτω:

Χωρίς τη χρήση GPG key για την υπογραφή του commit, θα εμφανιζόταν ως εξής:

Έχει γίνει δηλαδή σωστή χρήση των GPG κλειδιών που δημιουργήσαμε για την «υπογραφή» των commits!

Σημείωση: Προκειμένου να ενεργοποιήσετε τα Verified/Unverified badges στο GitHub, πηγαίνετε στη σελίδα https://github.com/settings/keys και στις ρυθμίσεις για «Vigilant mode», κάνετε τικ στην επιλογή «Flag unsigned commits as unverified». Για το GitLab δε χρειάζετε να κάνετε κάτι στις ρυθμίσεις. Βάζει το Verified badge όταν δει ότι είναι «signed» το commit.

Αν έχετε κάποιες απορίες ή παρατηρήσεις για το άρθρο, παρακαλώ γράψτε μας στα σχόλια.

Σφάλμα Git «no such ref was fetched»

Αν προσπαθήσετε να κάνετε git pull από ένα git repository στο οποίο έχει γίνει μετονομασία του branch πχ από master σε main, τότε θα εμφανιστεί στο terminal το ακόλουθο σφάλμα:

Your configuration specifies to merge with the ref ‘refs/heads/master’
from the remote, but no such ref was fetched.

Ουσιαστικά λέει ότι δεν υπάρχει master στο remote repository.

Για να επιλύσετε αυτό το πρόβλημα, θα χρειαστεί να μετονομάσετε το branch από master σε main και στη συνέχεια να ορίσετε το νέο upstream για το «νέο» σας branch, με τις ακόλουθες εντολές:

  1. Σιγουρευτείτε ότι είστε στο master branch:
  2. Μετονομάστε το master branch σε main:
  3. Και αλλάξτε το upstream:

Για να ελέγξετε αν έγινε σωστά η αλλαγή χρησιμοποιήστε την εντολή:

Αυτή η εντολή δείχνει πληροφορίες για τα τοπικά branches και τα αντίστοιχα upstreams. Στην περίπτωσή μας θα δείξει κάτι σαν το εξής:

main 3f15e4c [origin/main] Merge pull request #12 from yourgitusername/some-merged-branch

Αυτό που βλέπουμε είναι ότι το τοπικό main έχει σωστά πλέον ως upstream το remote origin/main.

Τέλος, δοκιμάστε να κάνετε και ένα git pull για να ενημερώσετε το main branch με όλες τις τελευταίες αλλαγές.

Σφάλμα Σύνδεσης Με Βάση Δεδομένων Και Έλλειψη Χώρου Σε Server

Εάν ξαφνικά το site σας δεν μπορεί να συνδεθεί με τη βάση δεδομένων, υπάρχει ενδεχόμενο αυτό να οφείλεται στην έλλειψη διαθέσιμου χώρου στον server εξαιτίας του οποίου, το service MySQL δε μπορεί να ξεκινήσει.

Αφού συνδεθούμε στον σέρβερ, ελέγχουμε την κατάσταση της MySQL με την εντολή:

Θα δούμε ότι είναι «Inactive».

Στη συνέχεια, ελέγχουμε το διαθέσιμο χώρο με την εντολή:

Η εντολή θα επιστρέψει κάτι σαν το παρακάτω:

Βλέπουμε ότι στον server έχουν μείνει διαθέσιμα 12Mb και ότι χρησιμοποιείται το 100% του χώρου. Θα πρέπει να διαγράψουμε αρχεία από τον server που δε χρειαζόμαστε. Αν δε μπορούμε άμεσα να σβήσουμε αρχεία στον σέρβερ, μία καλή λύση είναι να ελέγξουμε το χώρο που καταλαμβάνουν τα logs και να τα διαγράψουμε.

Αφού κάνουμε sudo su, ελέγχουμε το χώρο που καταλαμβάνουν τα logs με την εντολή:

Θα δούμε ότι τα logs, μπορεί να φτάσουν να καταλαμβάνουν αρκετά gigabyte του δίσκου!

Για να βρούμε ποια logs έχουν μέγεθος πάνω από π.χ. 200MB, χρησιμοποιούμε την παρακάτω εντολή:

Αν υπάρχουν αρχεία με μέγεθος πάνω από 200MB τότε θα εμφανιστούν σε μία λίστα ως εξής:

Εφόσον είστε απόλυτα σίγουροι ότι οι πληροφορίες μέσα στα logs δε σας χρειάζονται, μπορείτε να τα «αδειάσετε» με την εντολή:

Το > δε διαγράφει το αρχείο αλλά διαγράφει τα περιεχόμενά του.

Μπορείτε να συνεχίσετε την ίδια διαδικασία με μικρότερα αρχεία, π.χ. 50Mb

Για να αποφύγετε στο μέλλον την εμφάνιση του προβλήματος, θα μπορούσατε να χρησιμοποιήσετε το logrotate ή να χρησιμοποιήσετε κάποιο script που θα σας στέλνει email όταν π.χ. το 90% του χώρου του σέρβερ χρησιμοποιείται.

Στη συνέχεια κάντε έναν έλεγχο για να δείτε πόσο χώρο καταλαμβάνουν τα journal logs του systemd με την εντολή:

Θα εμφανιστεί ένα μήνυμα παρόμοιο με το εξής:

Με την εντολή:

θα διαγραφούν τα logs που είνα παλαιότερα από 2 ημέρες (2d). Μπορείτε να αλλάξετε την τιμή αυτή σε άλλη της προτίμησής σας.

Κάνοντας έναν έλεγχο (πάλι με την εντολή journalctl --disk-usage) θα δούμε ότι πλέον τα systemd journal logs καταλαμβάνουν πολύ λιγότερο χώρο:

Στη συνέχεια μπορείτε να καθαρίστε την cache του apt:

Τέλος, ελέγξτε τον διαθέσιμο χώρο στον server με dh -H και κάντε εκκίνηση του mysql server με:

 

Αλλαγή Name Και Email Σε Όλα Τα Git Commits

Υπάρχουν περιπτώσεις που θα χρειαστεί να μετατρέψετε ένα private repository σε public. Αν έχετε κάνει commits με το όνομά σας και το προσωπικό σας email, ίσως να μη θέλετε αυτές οι πληροφορίες να εμφανίζονται στο log του repository που θα γίνει public.

Για να αλλάξετε όλα τα ονόματα και emails θα πρέπει να ακολουθήσετε τα παρακάτω βήματα.

Ορίζουμε τις τιμές για name και email που θέλουμε πλέον να εμφανίζονται δημόσια:

Τώρα τσεκάρουμε ποια είναι τα name και email στο git config με τις εξής εντολές:

Δημιουργήστε ένα αρχείο με το όνομα git-change-author-details.sh και βάλτε στο αρχείο αυτό τον παρακάτω κώδικα. Αλλάξτε τις τιμές για τα OLD_EMAIL, CORRECT_NAME και CORRECT_EMAIL.

Τρέχουμε το αρχείο με την εντολή bash git-change-author-details.sh και θα αλλάξουν τα στοιχεία για τον author του κάθε commit.

Με την εντολή git log βλέπουμε πλέον ότι το όνομα και το email έχει αλλάξει σε όλα τα git commits και τώρα μπορείτε να κάνετε git push στο public repository σας.

 

Σημείωση: Σε περίπτωση που χρησιμοποιείτε Github, καλό θα ήταν να δείτε τις ρυθμίσεις στη σελίδα github.com/settings/emails και να «τικάρετε» τις επιλογές «Keep my email addresses private» και «Block command line pushes that expose my email»

Πρόβλημα Με Public Key Κατά Τη Διάρκεια ‘Apt Update’

Αν όταν εκτελούμε updates σε σύστημα Linux με:

εμφανιστεί το σφάλμα:

The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY ΧΧΧΧΧΧΧΧΧΧΧΧΧΧΧΧ

τότε, αντιγράφουμε το public key (το ΧΧΧΧΧΧΧΧΧΧΧΧΧΧΧΧ) και πληκτρολογούμε:

Πλέον όταν κάνουμε apt-get update τα updates θα προχωρήσουν χωρίς πρόβλημα.

Διαβάστε το υπόλοιπο άρθρο »

Webhosting Στην DigitalOcean

Κάντε εύκολα deploy έναν SSD cloud server στην DigitalOcean μέσα σε 55 δευτερόλεπτα. Χρησιμοποιήστε τον σύνδεσμο https://m.do.co/t/5b5dc69cc29c για να κερδίσετε credit $10 που ισοδυναμεί με δωρεάν φιλοξενία για 2 μήνες στο μικρό αλλά καλό πακέτο της εταιρείας.

Ενεργοποίηση PHP Error Logging

Για ενεργοποίηση του PHP error logging σε έναν Apache server ακολουθούμε τα παρακάτω βήματα:

Στο αρχείο ‘/etc/php/7.2/apache2/php.ini’ βρίσκουμε και αντικαθιστούμε το error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT με το error_reporting = E_COMPILE_ERROR | E_RECOVERABLE_ERROR | E_ERROR | E_CORE_ERROR.

Βρίσκουμε και αντικαθιστούμε το ;error_log = php_errors.log με το error_log = /var/log/php/error.log.

Δημιουργούμε το directory /var/log/php με sudo:

Αλλάζουμε owner και group του directory /var/log/php με:

Και κάνουμε επανεκκίνηση του server με:

Πλέον, όποτε μια εφαρμογή γραμμένη σε PHP παρουσιάζει σφάλματα, μπορούμε πλέον να τα βλέπουμε με:

Πρόβλημα Με Ελληνικούς Χαρακτήρες Στη Βάση Δεδομένων

Πολλές φορές συμβαίνει ελληνικοί χαρακτήρες να είναι αποθηκευμένοι στη βάση δεδομένων με τη μορφή:

Με τα βινεµÎκΠ»Î¬ÎºÎ¹Î± κινε²Î¹Îίστε και

Αυτό το πρόβλημα είναι γνωστό και ως «double encoded UTF-8 data». Συνήθως οφείλεται σε λανθασμένο collation της βάσης δεδομένων, σε λανθασμένο encoding της εφαρμογής/ιστοσελίδας που αποθηκεύει τα δεδομένα στη βάση, σε μη ορθό migration δεδομένων από μια βάση σε άλλη κλπ.

Προκειμένου να διορθώσουμε το πρόβλημα, κάνουμε χρήση του παρακάτω SQL query μέσα από το PhpMyAdmin ή στο command line του MySQL:

Αντικαθιστούμε το db_table με το όνομα του table της βάσης δεδομένων μας και το db_column με το όνομα της στήλης(column) της βάσης που έχει τους προβληματικούς χαρακτήρες. Αφού τρέξουμε το query, οι ακαταλαβίστικοι χαρακτήρες θα μετατραπούν πάλι σε αναγνώσιμους ελληνικούς χαρακτήρες. 🙂