Σχετικά με το life-cycle του λειτουργικού συστήματος ενός server

George Notaras gnot at g-loaded.eu
Sat Apr 16 20:29:58 EEST 2011


On 16/04/2011 18:54, Christos Ricudis wrote:
> On 04/16/2011 05:48 PM, George Notaras wrote:
> 
>> Κάποια στιγμή όλα τα λειτουργικά, ακόμα και εκείνα που προορίζονται για
>> servers, φτάνουν στο σημείο όπου παύουν να ενημερώνονται με security
>> updates. Εάν θεωρήσουμε ότι πρόσβαση στο shell έχουν μόνο άτομα της
>> εμπιστοσύνης, μπορεί να διατηρήσει κανείς με ασφάλεια ένα λειτουργικό
>> σύστημα, που έχει ξεπεράσει το EOL, αναβαθμίζοντας με custom compile
>> μόνο τα services που είναι προσβάσιμα από το ιντερνετ;
> 
> 
> Τοσο πολυ βαριεσαι;

Όχι, αλλά πολύ απλά δεν θέλω να γράψω την "ιστορία του ανθρώπου που
αναβάθμιζε software" σε βιβλίο και ψάχνω να βρω τον τρόπο να μην μπλέκω
συχνά με τόσο απρόβλεπτα πράγματα όπως το migration ενός σερβερ.

> 
>>
>>
>> Από την άλλη, αν το πρόβλημα με τα dependencies που ανέφερα παραπάνω δεν
>> είναι τόσο σπουδαίο, για πόσα χρόνια
> 
> 
> Για δυομισι χρονια.

Βρε σεις ξέρω ότι δεν απαντιούνται τέτοια πράγματα. Να γίνω πιο
συγκεκριμένος. Θεωρείτε με βάση την μέχρι τώρα εμπειρία σας ότι μπορεί
ένας server να τρέχει ασφαλώς για 20-25 χρόνια με custom compile μόνο
του software που είναι προσβάσιμο από το νετ?

Από ό,τι είδα το μέγιστο life-cycle αυτή τη στιγμή το έχουν οι red
hat[1] και η microsoft[2] και είναι 10 χρόνια. Ναι το ξέρω ότι είναι
σκέτη φρίκη, αλλά το σκέφτηκα να τρέχω τον apache σε windows server...

[1] http://www.redhat.com/rhel/server/extended_lifecycle_support/
[2] http://support.microsoft.com/lifecycle/?p1=12925

>> μπορεί κανείς να διατηρεί με αυτόν
>> τον τρόπο έναν server ασφαλή;
>>
> 
> 
> Αναλογως τι κανει. Αμα σερβιρει απλα mail η απατσοσελιδες, δεν υπαρχει
> σχεδον κανενας λογος να αποφυγεις ενα upgrade, αν εχεις χρονο να το
> κανεις. (βοηθαει παρα πολυ και το να χρησιμοποιεις τυποποιημενες
> εγκαταστασεις αποφευγοντας το δυνατον περισσοτερο τις customies).
> 
> Απο την αλλη υπαρχει ενα πολυ καλο επιχειρημα που λεγεται "if it works,
> don't fix it", και ενα επισης πολυ καλο επιχειρημα που λεγεται "legacy".
> Εκει το ζυγιζεις αναλογα με τις αναγκες. Π.Χ. ενα reverse HTTP/SMTP
> proxy μπορει μερικες φορες να αποδειχτει σωτηριο μπροστα απο ενα αρχαιο
> συστημα που δε θες η δε μπορεις να το πειραξεις. Εχω δει απειρα obsolete
> συστηματα, και οχι μονο σε επιπεδο λογισμικου, που πρεπει να παραμεινουν
> σε λειτουργια απλα και μονο επειδη δεν υπαρχει εναλλακτικη λυση. Εκει
> μπορει να φτασεις μεχρι και στο σημειο να πατσαρεις πραγματα με το χερι,
> αν και δε στο συνιστω καθολου - ειναι μαλλον η τελευταια λυση.

Αυτό που είπες για το reverse proxy ήταν συγκλονιστικό ρε Ρικούδη! Αυτό
θα είναι το τέλειο migration! Τελεία και παύλα.

Σου χρωστάω ένα κέρασμα!

> 
> Τωρα, γενικοτερα, η ασφαλεια ειναι ενας κουβας που χωραει ΠΑΡΑ πολυ
> νερο. Τι παει να πει ασφαλεια, και τι φοβασαι γενικως; Δεν τοχεις
> ξεκαθαρισει αυτο το πραγμα, και απο αλλα παρομοια mails σου μου φαινεται
> οτι το μονο που σε απασχολει ειναι "μη μου rootιασουν κανα μηχανημα",
> οποτε θα πρεπει να σου πω οτι αυτο ειναι αρκετα επιφανειακη προσεγγιση
> στο θεμα "ασφαλεια". Σε ενδιαφερει ασφαλεια δεδομενων που οντως εχεις
> καποιο λογο να προστατεψεις; Σε ενδιαφερει το πιθανο downtime που μπορει
> να προκαλεσει ενα επιτυχημενο attack? Τι ακριβως σε ενδιαφερει τελος
> παντων;
> 

Δεν είναι το θέμα των δεδομένων ούτε του downtime, όσο η όλη μανούρα που
θα χρειαστεί για να διορθώσει κανείς τα πράγματα μετά. Απλά προσπαθώ να
ακολουθώ τα best practices και τίποτα παραπάνω.



More information about the Linux-greek-users mailing list