From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EDD03138E20 for ; Wed, 19 Feb 2014 07:08:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AA31BE0ADC; Wed, 19 Feb 2014 07:08:21 +0000 (UTC) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) by pigeon.gentoo.org (Postfix) with ESMTP id 73092E0ACC for ; Wed, 19 Feb 2014 07:08:20 +0000 (UTC) Received: from [212.54.42.134] (helo=smtp3.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WG1GV-0004JK-QV for gentoo-user@lists.gentoo.org; Wed, 19 Feb 2014 08:08:19 +0100 Received: from 53579160.cm-6-8c.dynamic.ziggo.nl ([83.87.145.96] helo=data.antarean.org) by smtp3.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1WG1GV-0003fh-6h for gentoo-user@lists.gentoo.org; Wed, 19 Feb 2014 08:08:19 +0100 Received: from www.antarean.org (net.lan.antarean.org [10.20.13.13]) by data.antarean.org (Postfix) with ESMTP id 6319F4B for ; Wed, 19 Feb 2014 08:07:54 +0100 (CET) Received: from 145.72.98.1 (SquirrelMail authenticated user joost) by www.antarean.org with HTTP; Wed, 19 Feb 2014 08:07:54 +0100 Message-ID: In-Reply-To: <5303E783.1040900@gmail.com> References: <52FF84CE.2050301@libertytrek.org> <52FF9D58.3000608@libertytrek.org> <201402152023.10543.michaelkintzios@gmail.com> <5300DD51.5060207@libertytrek.org> <5300EA3A.5020801@gmail.com> <24165346-F62B-4CD4-BB43-0D5A68BE0004@stellar.eclipse.co.uk> <530268AE.3050603@gmail.com> <53032C35.3060307@gmail.com> <53034153.5080408@gmail.com> <97b4241656dd9409e2fb31e2537baeb3.squirrel@www.antarean.org> <5303E783.1040900@gmail.com> Date: Wed, 19 Feb 2014 08:07:54 +0100 Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org User-Agent: SquirrelMail/1.4.22 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Ziggo-spambar: - X-Ziggo-spamscore: -1.5 X-Ziggo-spamreport: BAYES_00=-1.9,RDNS_DYNAMIC=0.982,RP_MATCHES_RCVD=-0.552 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Archives-Salt: ae9d19e1-4e8e-4341-9c4a-d62f47eb5240 X-Archives-Hash: 91be97cfeef51e68ad5fd261294d496c On Wed, February 19, 2014 00:06, Alan McKinnon wrote: > On 18/02/2014 14:16, J. Roeleveld wrote: >> On Tue, February 18, 2014 12:17, Alan McKinnon wrote: >>> It's a little more complex than just that. It's an auth service and >>> user >>> are frequently added, removed and modified. The daemon does syntax >>> checking on it's config file at startup or after being HUP'ed but tha= t >>> only finds static errors. It catches things like adding people to a >>> grop >>> instead of to a group, but misses dynamic mistakes like adding users = to >>> groups that don't exist. >> >> The auth-service gets the current state from a static file that is onl= y >> read upon service-start? > > Yes. > > It's a good design for reasonably static userbases. The user details, > priviledge definitions, passwords hashes and such are stored in a singl= e > flat file readable only by root and protected by file permissions. > Overall protection is provided by restricted shell access to the host. True, then again, I use ldap for the user accounts at home. Allows my wife to change her own password and I can quickly add an accoun= t in case someone needs access. > We're not talking about AT&T's radius servers for dsl users here who > sign up on a web form - for that you would use a database backend - thi= s > is for the company's network support personnel who log into the backbon= e > and configure the network itself. There's no rush to add new (and > unproven...) users so this scheme suits me just fine. Yes, it has quirk= s > but these no longer bother me myself, we get caught out by new sysadmin= s > who have not felt that pain yet Show them a blood-stained (ok, some dark red paint) stick when they start= . Then tell them it's used when they kill that service? ;) >>> Despite this all being run out of cron with wrapper scripts to check >>> validity, automated additions and safety checks between all three >>> daemons, plus being fully documented on the internal wiki and in bold >>> blinking red caps in the login motd, people still find ways to do stu= ff >>> things in an attempt to fix it. >> >> (OT: Does the bold blinking red caps work on all terminals? :) ) > > > Um, OK, you got me there. I was exaggerating! Too bad, I could use that on one of my machines :) >>> The daemon also tries to log these errors, by writing to a log file i= t >>> has no write permissions on. >> >> "setuid" on the group with group-write in the umask not an option? > > Hmmm, that's worth investigating. I hadn't really considered that as I > have an aversion to trying to use umask as a control for anything. Same here, but that could work. Then again, I believe setuid on the folder does the same on some OSs. (No= t Linux though) >>> There is nothing I can do about the quality of sysadmins, I have no >>> input into the HR process and damagement think cheaper is always >>> better, >>> including skills. What I can do, is find ways to make the software mo= re >>> resistant to errors than it already is. >> >> And only grant access permissions to these rookies once they have prov= en >> they understand rule #1: If In Doubt, Call Someone Who Knows! > > Hah! I fought that good fight for years and fought it well. They don't > call me the sysadmin from hell around here without good reason. And I > did manage to get a cowboy network under control and instill respect fo= r > how much breakage Cisco's products can cause. > > It's getting harder to grant access based purely on expertise, > especially when someone crunched the numbers. It turns out that the cos= t > of fixing mistakes is far less than the cost of leaving new untrained > people unutilized and have support tickets pile up... True, unfortunately... Then again, a core of really good people can be the better option. But then you end up becoming overly dependent on that group. >> But yes, I fully understand the methods of HR and Damagement. >> It is a financial mistake and risk not to include technical expertise >> checks in the recruitement fase for technical positions. > > Interesting story: > > I once had a good shouting match with a support manager about the > quality of his recruits. I demanded to know why he hired so many > clueless idiots (my exact words). This manager knows me well so he just > smiled and said "Alan, you didn't get to see the applicants we rejected= . > These are the best in the market who applied". > > *That* was a wake-up call of note :-) Either done during the "boom" of IT, or wrong recruitment tactics. >> How much does it cost the company each time this goes wrong and someon= e >> like you has to come online to fix the issue? >> That is what Damagement needs to understand. > > Surprisingly, it's not too expensive. There's always one of us on duty > or standby and outages don't continue unnoticed for long. Longest that = I > recall is 3 minutes, then the phone starts ringing non-stop. remember, > this system is internal, it does not service customers. 3 minutes downtime is acceptable, even for customers. They generally first assume they are making a mistake ;) -- Joost