Tag: System Administration

Exceptions

Usually a system manager proposes a policy, gets approval from higher management (a written one if lucky enough, or if compliance with standards is needed) and proceeds to implement it.

Then it begins:

The manager must enforce the policy, with one exception. Then another and another. And later an exception of the form: Deny access to this resource, except from these people, with the exception of these circumstances and provided that the stars are in the right angles. Or in order to give a real life (pseudo)example:

You use a DNSBL. A certain host is included and there are valid reasons for this. But you need to unblock this host because someone with authority asks you to. However, the hard reality forces you not only to implement the exception, but also an exception to the exception (unblock this host for certain recipients, who do not want certain senders from this host, etc).

In this process nobody tries to understand the very root cause of the problem: Are we correct in using the particular DNSBL? And if we are, is there a valid reason for the sending host to be (black)listed? And if there is, is it wise to implement a series of exceptions, or is it better to wait for the host’s administrators solve the problem?

A great number of people seem to misunderstand the robustness principle: “Be liberal in what you accept; be conservative in what you send” (they stick to the “accept” part) and I think we need to rephrase it:

If you want me to be liberal in what I accept, be conservative in what you send

A policy ruled by exceptions is not an exceptional policy.

→ Asking the security team for a firewall exception.

reboot before dist-upgrade

[ Παρόλο το debianism του τίτλου, αυτό είναι ένα γενικότερο post ]

Πριν από δραστικές αλλαγές στο λειτουργικό σύστημα ενός server, καλό είναι να γίνεται ένα reboot. Ειδικά εάν έχουν περάσει αρκετές ημέρες (μήνες, χρόνια) από το προηγούμενο reboot. Οι εξαρτήσεις στο πολύπλοκο περιβάλλον που ζουν οι servers φτάνουν σε σημεία που δεν μπορούμε να ελένξουμε ή δεν θυμόμαστε πάντα από μνήμης (Documentation; Τι είναι αυτό;).

Για αυτό ένα reboot πριν μια θεμελιώδη αλλαγή επιβάλλεται. Downtime is an option, αρκεί να μπορούμε να έχουμε μια ιδέα τι το προκάλεσε. Μετά π.χ. από ένα dist-upgrade από Etch σε Lenny, δεν είναι σίγουρο πως θα μπορεί να εντοπιστεί το πιθανό πρόβλημα στην αναβάθμιση του software ή σε μια άλλη εξάρτηση που έχει προστεθεί στην πορεία και δεν μας περνάει από το μυαλό.

Αλλάζουμε μία μεταβλητή (από όσες ελέγχουμε) τη φορά και θυμόμαστε πως συνήθως εάν ένα ext3 filesystem δεν έχει γίνει fsck για περισσότερες από 30 μέρες, θα κάνει fsck στο επόμενο reboot. Είσαι σίγουρος πως αυτό θέλεις να είναι το reboot του dist-upgrade;

→ Fear of rebooting.

pf tricks

OpenBSD journal points that pf is enabled by default on OpenBSD from now on (with the exception of X11 incoming traffic). I take the opportunity to share some minor tricks that I use with pf on my BSD systems (servers mostly):

Regardless of the default policy which may or may not vary across the BSD operating systems that support pf, I always have a pf.conf.block and a pf.conf.pass handy, just in case I need to enable one of the two defaults for debugging:

* pf.conf.block:

block all

* pf.conf.pass:

pass all

On machines that run OpenVPN it happens that pf is enabled and its rules are loaded before OpenVPN is started (and its virtual interface created). So if your pf.conf has rules for a non existent interface, loading it fails leaving your machine’s pf in a state that your clearly do not want. In those cases I boot the machine with a very simple policy and load the intended policy (written in /etc/pf.conf.local) later from /etc/rc.local by issuing the command:

pfctl -Fall -f /etc/pf.conf.local

And the simple policy contents of /etc/pf.conf are:

table <machine> const  { self }
block all
pass all to <machine>
pass all from <machine>

The above policy allows any kind of traffic to and from the machine, but routes no traffic between interfaces. It can be modified depending the services the machines starts (if any) and it is used only for boot time. YMMV.

Windows 2008 routing weirdness

This happened to me the other day: I was called to see why a newly installed Windows 2008 machine could not see anything beyond the default gateway. After playing point-and-click for some time, I resorted to the command line. Issuing an ipconfig command revealed that the machine had two default gateways on the same interface and with the same metric. The correct one (let’s call it 192.168.1.254) plus 0.0.0.0:

Default Gateway . . . . . . . . . : 0.0.0.0
                                    192.168.1.254

After some tcpdumping it seems that when having two default gateways and with the same metric, Windows 2008 does not randomly chooses one of them for every packet, rather it tries to send every packet through the smallest one (zero in this case). To resolve the problem one executes the following commands:

route delete 0.0.0.0
route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.254 metric 1

The -p switch is need to make the route change permanent across reboots.

“Patch! Patch! Patch!”

Το 2001 στα πλαίσια του IT Security Conference (που αργότερα εξελίχθηκε στο Cyprus InfoSec) ο Richard Cross έκανε την καλύτερη παρουσίαση.

Δεν θυμάμαι τον τίτλο, ούτε το περιεχόμενο, όμως σίγουρα όποιος την είδε θα σας πει το ίδιο: Ήταν η καλύτερη παρουσίαση, γιατί είχε ένα μήνυμα και όλοι μα όλοι το θυμούνται καλά:

Remember people; Patch! Patch! Patch!

Δε θυμάμαι πόσες φορές το είπε. Το είπε αρκετές και παραστατικά, γιατί αμέσως μετά, όποιος πήγαινε να του μιλήσει δεν του έλεγε “Hi!”, του έλεγε “Patch! Patch! Patch!”.

Αργότερα μου είπε πως:

Έχω καταλάβει πως αν θέλεις να μείνει κάτι από αυτά που λές, πρέπει να το λες τρεις φορές.

Μία λέξη · δύο μαθήματα.

(Σε συνέχεια του προηγούμενου post)

up to date

Στο timeback blog υπάρχει ένα άρθρο που ασχολείται με το “the waste of staying up to date“. Παρόλο που το κείμενο είναι αποκλειστικά για time management, οι ιδέες του επεκτείνονται εύκολα και σε time management για system administrators.

Λίγο μετά από την ανακοίνωση του Debian 5.0 (Lenny) και tweets σαν αυτό και αυτό θυμήθηκα πόσο πολύ προσπαθούσα τα πρώτα χρόνια να “τρέχω” τις τελευταίες εκδόσεις, του λειτουργικού και οποιουδήποτε software ήταν εγκατεστημένο. Και μάλλιστα σε εποχές που οι ανακοινώσεις των τελευταίων εκδόσεων δεν γίνονταν από προφανή μέσα (mailing lists, USENET newsgroup) απαραίτητα. Πράγμα που σήμαινε π.χ. πως έπρεπε να κοιτάζω το (FTP) site που στέγαζε το software τακτικά για να κατεβάσω τη νέα έκδοση. Και αυτό χωρίς κάποιο προφανή λόγο (security patch ή άλλο software bug που επέβαλλε την αναβάθμιση).

Α ναι, δεν ήμουν ο μόνος που το έκανε αυτό. Ο Unique Fish για παράδειγμα είχε αποκτήσει το παρατσούκλι gnutilities γιατί πάντα προσπαθούσε να έχει την τελευταία έκδοση των εργαλείων GNU εγκατεστημένη.

Sure, go ahead, stay hyper-current, but realize it’s not free.

Ποιο το αποτέλεσμα; Για πολύ καιρό αντί να ασχολούμαι με τη δουλειά που ήθελα να κάνω, ασχολιόμουν με τα περιφειακά ζητήματα, δηλαδή το να υπάρχει το latest-and-greatest version εγκατεστημένο. Ναι ρε φίλε, αλλά να το κάνουμε και κάτι.

But more often than not (in Seth’s words), we overpay for the newest information. […] And that overpayment is nothing but muda — the waste of lost focus and interrupted cognition.

Αλλάξτε το newest information σε newest software και έχετε την εικόνα. Νομίζω αυτό μου αρέσει στο Debian stable: Προστατεύει το χρόνο μου. Εάν πραγματικά χρειάζομαι το ειδικό εκείνο feature που δεν υπάρχει στο stable, θα το βάλω χεράτα. Μόνο τότε.

You can teach an old dog new tricks

Τον “παλιό καιρό” εάν κάποιος ήθελε να “κλειδώσει” ένα χρήστη, έκανε vi /etc/passwd, έβαζε ένα αστεράκι (ή για ποιο ευδιάκριτα το string *LK*) στο password field και ήταν ΟΚ. Ναι υπήρχε και τότε το vipw αλλά σιγά μη το χρησιμοποιούσε κανείς (άσε που το vipw στο Solaris ήταν εκνευριστικό).

ΟΚ, κάποια στιγμή έπρεπε να μη γίνεται αυτό “χεράτα” αλλά ημιαυτόματα, οπότε μερικοί από εμάς χρησιμοποιούσαμε παραλλαγές του παρακάτω one-liner:

# sed -e ‘s/^yiorgos:\([^:]*\):\(.*\)/yiorgos:*LK*:\2/’ /etc/passwd > /etc/passwd- && mv /etc/passwd- /etc/passwd

(Ναι υπήρχε περίοδος που το /etc/shadow δεν υπήρχε ακόμα)

Κάποια στιγμή ένας φίλος και ενώ τελείωνα μια εγκατάσταση Debian με είδε να γράφω:

# echo ‘user:*LK*’ | chpasswd -e

– Γιατί το κάνεις αυτό;
– Για να κλειδώσω το χρήστη ρε συ
– Εγώ τρέχω passwd -l user

Στο απορημένο μου βλέμμα, ο φίλος απάντησε:

– Μου αρέσει να διαβάζω τα manpages των παλιών εντολών για να βλέπω τι άλλαξε.