From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13549 invoked from network); 1 Mar 2023 09:03:41 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 1 Mar 2023 09:03:41 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id AF68243319; Wed, 1 Mar 2023 19:03:36 +1000 (AEST) Received: from lists.tip.net.au (pasta.tip.net.au [IPv6:2401:fc00:0:129::2]) by minnie.tuhs.org (Postfix) with ESMTPS id D2DE943316 for ; Wed, 1 Mar 2023 19:03:29 +1000 (AEST) Received: from [192.168.1.4] (203-214-41-102.dyn.iinet.net.au [203.214.41.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailhost.tip.net.au (Postfix) with ESMTPSA id 4PRSvM09t3z9QL9; Wed, 1 Mar 2023 20:03:26 +1100 (AEDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: steve jenkin In-Reply-To: Date: Wed, 1 Mar 2023 20:03:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> To: TUHS X-Mailer: Apple Mail (2.3445.104.21) Message-ID-Hash: SRDABW3DTFCPIF4JTVEGGSKDBDEJZZWX X-Message-ID-Hash: SRDABW3DTFCPIF4JTVEGGSKDBDEJZZWX X-MailFrom: sjenkin@canb.auug.org.au X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix Systems Administration Texts List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Dan, I used the Nemeth book when I didn=E2=80=99t know how to do the odd = thing or finding a tool, but the book was predicated on a very specific Academic = environment. You can see why she=E2=80=99d suggest making tools reliable, robust and = =E2=80=98complete=E2=80=99 (done =E2=80=98properly=E2=80=99) in their environment with a large, constantly changing workforce, kids = all too prone to =E2=80=98exploring=E2=80=99 things or breaking something and then not knowing what to do=E2=80=A6=20 =46rom 1995, I spent around a decade doing contract SysAdmin. The well run, well staffed and =E2=80=9Cno drama=E2=80=9D sites never = needed me :) I got =E2=80=9Cparachuted behind enemy lines=E2=80=9D, having to fight = my way out, so many times that I discovered I had a process for =E2=80=9CDigging = myself Out=E2=80=9D = The key is to gain time by automating tasks, starting with what gains = the most time for you, not business or managerial priorities. There=E2=80=99s at least three levels of script / tool, I thought were all covered in that Bill Plauger PDF recently but = aren=E2=80=99t: = 1. Stuff for yourself.=20 2. A "Program Product" for a small, competent group.=20 3. A hardened product / Application that the unwashed masses = will use and test to destruction. As a lone Sys Admin it=E2=80=99s incumbent on you to leverage the = Automation under your control, not drown in entropy. If you do Admin in seriously large sites, eg AWS or GOOG, practices have = to be adapted to avoid outages - any outage will have massive impact. At Internet Scale, the only methodology that can work is: "systems are cattle not pets=E2=80=9D- create tools that easily = scale to the entire fleet & are particularly robust & reliable. Admins can=E2=80=99t be allowed to ever type at a production console - = much more controlled than the old Boulder Uni environment. HTH sj > On 1 Mar 2023, at 13:34, Dan Cross wrote: >=20 >> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System = Administration Handbook (5th edition is another fatty) >=20 > This book gave me some terrible advice when I was very young and = impressionable. >=20 > In there somewhere it says something about not doing something unless > you're prepared to do it right lest one spend more time working around > a work-around than one would have spent just doing it well in the > first place. >=20 > The conclusion is, of course, true, but the admonition ignores all > sorts of externalities, like waiting users. And in some cases it could > really lead to paralysis ("omg _everything_ is broken and I can't do X > until I do Y, but to do Y I have to do this other thing and if I > really want to do it right I need to start by traveling to Nepal and > shaving this Yak, but I need to get my passport renewed and damn I > really oughta lose 20 pounds before I get my passport photo taken for > the next ten years, so I guess I oughta join a gym...but I can't even > find one because the network is down and I can't get to Google, but > how can I fix the network if I have not shaved the Nepalese yak?!"). > Talk about letting the perfect be the enemy of the good. >=20 > Hopefully nowadays we have a better appreciation of the power of > incrementalism; those grand plans for the perfect system rarely come > to fruition. It's better to be flexible and make small, impactful > changes along the way towards a better system, always being mindful of > and tamping down encroaching entropy. >=20 > - Dan C. -- Steve Jenkin, IT Systems and Design=20 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin