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

[Antonis Konstantinos Tzorvas]

Καλησπέρα Γιώργο,

να ρωτήσω πάνω σε ποιά distro είναι το μηχάνημα;

2011/4/16 George Notaras <gnot at g-loaded.eu>

> 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 και τίποτα παραπάνω.
>
>
> --
> linux-greek-users mailing list -- http://lists.hellug.gr
>



-- 
Konstantinos Antonios Tzorvas
Student, Dept. of Information and Communication Systems Engineering
University of the Aegean
Karlovassi, Samos, GR-83200, Greece
Email: antonis at tzorvas.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hellug.gr/pipermail/linux-greek-users/attachments/20110416/d2a1deaf/attachment.html>