sendmail sender queue groups

Sendmail provides for queue groups where one can have messages that stay in queue be placed in separate queues which are treated differently according to rules described in the queuegroup ruleset. FEATURE(queuegroup) helps managing such queues via the access database but unfortunately deals only with recipient addresses. But what if one wants to place messages in a separate (slower) queue based on sender’s address?

QUEUE_GROUP(`newsletter', `N=10, I=31m, P=/storage/queues/n.*')dnl

LOCAL_RULESETS
Squeuegroup
R$*             $: $>canonify $&f
R$* < @ $* > $*         $: $1
Rowner-newsletter         $# newsletter

The above trick does not make use of the access database. In fact you must not use FEATURE(queuegroup) in your sendmail.mc with it. The queuegroup ruleset is called with the recipient address as an argument. The first line replaces it with the sender’s address ($&f) canonified. In this particular newsletter case, we are only interested in the left hand side of the email address ($1). Others may be interested in the sender’s domain ($2). The third line checks to see whether the left hand side matches what we expect (owner-newsletter) and if so, it selects the corresponding queue. Otherwise the default queue, named mqueue, is selected.

For a more complete ruleset that can treat combinations of senders and recipients and via the access database see “Sendmail Extended Queue Groups“.

The sysadmin paradox

The sysadmin paradox, n.:
The fact that when your system administrator is constantly running behind problems is perceived to be working and being productive, as opposed to being perceived as idle while managing a working infrastructure.

Our aim is to eliminate ourselves from the management of the system, to be considered as “not needed” because the system has no problems, therefore we do not work enough. Luckily, whenever (if) this happens, new more complex requirements emerge and the circle continues.

The five most important questions

It was thanks to this post by John D. Cook on abandoning projects that I got interested in Peter Drucker. So I went to ebooks.com and looked up whether there exist any ebook versions of his works. I bumped into “The Five Most Important Questions You Will Ever Ask About Your Organization” which is focused on non-profit and social organizations. Being a public sector worker, the book seemed a natural candidate.

The book expands on an earlier 1992 version written by Drucker and contains essays by him and other experts in the field of management. All essays are centered around five basic questions which as Drucker writes it is important to ask:

“The most important aspect of the Self-Assessment Tool is the questions it poses. Answers are important; you need answers because you need action. But the most important thing is to ask these questions.”

The five questions are:

  1. What is Our Mission?
  2. Who is Our Customer?
  3. What Does the Customer Value?
  4. What Are Our Results?
  5. What Is Our Plan?

Non-profit organizations are about changing lives and these questions are a tool to achieve this. Even without reading the explanatory essays their importance is evident (as is answering them in a sincere way). And while the book itself is not a self-assessment tool for an individual, the questions themselves are a good start.

It is beyond evident to people that know me that the concept of organized abandonment is what I liked most in the book. I’ve been (unsuccessfully) advocating a similar stance within my employer’s organization for years but I had never seen it so clearly articulated until now. Plus this time it is not only me saying this, Drucker said that too, see? IMVHO, organized abandonment is the basic evolution mechanism for organizations (public and private sector).

This is definitely a book I will revisit in six months time. To evaluate its impact on my way of thinking within my own organization and to see whether I managed to pass anything along.

PS: I bought the PDF version of the book by mistake. Normally I try to read ePub versions on my BeBook Mini, but luckily in this case the BeBook rendered the PDF adequately.

staying up late

engineering student

When the image popped in my timeline, I was immediately reminded of Bob Lucky‘s May 1998 essay about Electrical Engineering:

“Electrical engineering will be in danger of shrinking into a neutron star of infinite weight and importance, but invisible to the known universe.”

Others fear that CS might not be far behind. And systems administration, even in its DevOps morph is not far behind too. So while the artist (anybody knows who the artist is?) drew that with engineering students in mind, the image reflects the situation for more.

Happy 2012 to you all.

Υπάρχει ταβάνι

“Ειναι αποριας αξιο πώς ολοκληροι ομιλοι στηριζουν το IT τους σε τραγικα ηλιθιους IT Directors.”

Αυτό εμφανίστηκε κάπου στο timeline. Θα επιχειρήσω μια προσέγγιση. Δεν είναι κάτι για να πέφτει από τα σύννεφα κανείς. Είναι κάτι το αναμενόμενο. Με την εξαίρεση οργανισμών που ασχολούνται με την Πληροφορική (και δεν εννοώ τους box movers) το ITιλίκι δεν είναι καριέρα. Δεν είναι μια διαδρομή που θα οδηγήσει κάποιον στα “ανώτερα πατώματα” της διοίκησης. Και γιατί να ήταν άλλωστε;

Μια τυπική πορεία ξεκινάει από τον τύπο που “τα φτιάχνει όλα” και τον αγαπάει όλος ο κόσμος. Αλλά αυτό τελειώνει. Τελειώνει όταν δεν τους δείχνει πως να κατεβάσουν μια ταινία, όταν δεν τους αφήνει να εγκαταστήσουν σπασμένο πρόγραμμα στον υπολογιστή τους, όταν τους φωνάξει γιατί για 32η φορά μέσα στο μήνα πρέπει να στήσει το PC τους που κόλλησε ιό “από μόνο του”. Φυσικά αυτό συμβαίνει στην πορεία του χρόνου και ενώ ο ήρωάς μας “ανεβαίνει” την ιεραρχία του οργανισμού (δεν έχει σημασία εάν είναι θεσπισμένη ή όχι) με την κούραση να σωρεύεται και την συνειδητοποίηση πως παρόλο που το IT είναι “η καρδιά του οργανισμού” (α) δεν το ξέρει κανείς άλλος και (β) δεν είναι το αντικείμενο του οργανισμού.

“Κάθε φορά που σε βλέπω μου έχεις έξοδα!”

Αυτό το είπε στον head of IT ο ιδιοκτήτης μεγάλης εταιρίας με παρουσία σε πολλές χώρες. Και δεν του είπε ψέμματα. Όποτε τον βλέπει μιλάνε για δαπάνες. Ποτέ για κέρδη. Οι καλύτερες μέρες είναι αυτές στις οποίες μιλάνε για περικοπές και για εξοικονόμηση χρημάτων που έχει επιτευχθεί. Φανταστείτε λοιπόν μια συνάντηση όλων των επικεφαλής στον οργανισμό κατά τη διάρκεια της οποίας οι άλλοι μιλάνε για τις πωλήσεις που έφεραν, τα έσοδα που έχουν έρθει, τι περιμένουν να έρθει ως εισροή και μόνο ένας να μιλάει στην καλύτερη περίπτωση για εξοικονομήσεις και στην γενική για έξοδα. Ακόμα κι όταν όλοι του ζητάνε θαύματα η χρηματοδότηση της υποδομής τους είναι ένας αγώνας στον οποίο μάλιστα τα προηγούμενα θαύματα δεν παίζουν κανένα ρόλο.

Στο παράδειγμα που ανέφερα πριν, ο συγκεκριμένος head of IT έσωσε (στην κυριολεξία) την εταιρία μια και είχε καταφέρει να διαθέτει ένα NAS με snapshots και έτσι όταν ένας χρήστης έσβησε σημαντικά στοιχεία προϋπολογισμού κατά λάθος και γύρω στις 04:00 το πρωί, μπόρεσε να τα επαναφέρει άμεσα. Θα περίμενε κανείς, αυτό να του έδινε μια ευχέρεια για έξοδα. Του έδωσε το παράπονο που διαβάσατε.

Τέτοιες ιστορίες έχει να αφηγηθεί ο καθένας πολλές. Αυτό που συμβαίνει όμως όσο εμείς ανταλλάσσουμε ιστορίες είναι πως οι καριερίστες αποφεύγουν τις θέσεις ευθύνης IT και πάνε προς αυτές που τους φτιάχνουν το προφίλ μέσα στον οργανισμό. Που τους διευκολύνουν την καριέρα και που θα τους εξασφαλίσουν μια καλύτερη θέση και σε άλλο (ανταγωνιστικό;) οργανισμό. Ταυτόχρονα οι ITήδες ενώ ασχολούνται με το να υπάρχει ο οργανισμός, δεν ασχολούνται με το αντικείμενό του. Δεν είναι να απορεί κανείς λοιπόν που:

“When times are tough IT gets beaten hard” –Rolf von Roessing

Ποιοι μένουν λοιπόν; Μένουν αυτοί που δεν μπορούν να προαχθούν αλλού αλλά ούτε και να “φύγουν” (δες το σαν δυσμενή προαγωγή), αυτοί που δεν ενδιαφέρονται και που μετράνε τις μέρες για να πάρουν σύνταξη, αυτοί που από ατυχία βρέθηκαν εκεί και σχεδιάζουν να αλλάξουν τμήμα μέσα στον πρώτο χρόνο. Α ναι υπάρχουν και αυτοί οι λίγοι και άτυχοι που τους αρέσει το ΙΤ, που θέλουν να τρέξουν αποδοτικά αυτό το κομάτι και που έρχονται να τους πουλήσουν κάτι που “θα τους λύσει τα χέρια” ενώ στην πραγματικότητα θα τους τα κάνει περισσότερο κόμπο:

“Every time someone automates part of my job I end up with more work to do – but it is more interesting work.”

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