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 D0D74138E35 for ; Tue, 18 Feb 2014 23:07:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C02E0E0A49; Tue, 18 Feb 2014 23:07:01 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6BE76E06FE for ; Tue, 18 Feb 2014 23:07:00 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so3762845wgh.31 for ; Tue, 18 Feb 2014 15:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Z8OkKZAocH2U6tK9P670kDCrSB+lQ5p2KjXHOnVGtLc=; b=ScUSGBz/K7WbvaUvGA+twnx6eLogXbXr0tctAoS7738b8JRa5fjRwGoE1S/9BaosvT xDWwj+caUjO4j5Dq1IrU4dS/VrbhkNUQ9CIvLd+70ZvVJLQg/BBGKNi4nFpKmv9ab6ll WSqThy2Z4HvxUMEUjETr1y8OsZM87jfEecVnpAQAgeVig9iRTzFrD2yljpJGclbzQIMU 3+Z4qz/T2Z6f+EzfJlfRitSL0ooogZgOVJ8W+W3lKPBGzlnUCodD3oZlWbWiGohNYa8c E7+7KCAOx7XCJH9GYFnI9ZdjsO8EbI2vac5yi36LWQWSFXxaoCSYmvOHCS4Mh9OXfdW/ lvGw== X-Received: by 10.194.60.233 with SMTP id k9mr16966wjr.55.1392764819024; Tue, 18 Feb 2014 15:06:59 -0800 (PST) Received: from [172.20.0.40] (196-210-102-21.dynamic.isadsl.co.za. [196.210.102.21]) by mx.google.com with ESMTPSA id pm2sm46703165wic.0.2014.02.18.15.06.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 15:06:58 -0800 (PST) Message-ID: <5303E783.1040900@gmail.com> Date: Wed, 19 Feb 2014 01:06:43 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie 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> In-Reply-To: <97b4241656dd9409e2fb31e2537baeb3.squirrel@www.antarean.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: f77279ea-8aff-40f0-a6ed-58e1257fd0f3 X-Archives-Hash: c244ed4ca8655f05086657b19bedc08b On 18/02/2014 14:16, J. Roeleveld wrote: > On Tue, February 18, 2014 12:17, Alan McKinnon wrote: >> On 18/02/2014 11:52, J. Roeleveld wrote: >>> On Tue, February 18, 2014 10:47, Alan McKinnon wrote: >>>> What I do run into is daemons that drop privs on start up, like >>>> tac_plus. Unwary new sysadmins always try start/stop it as root, >>>> causing >>>> an unholy mess. Root the owns the log and pid files, when tac_plus >>>> drops >>>> privs it can't record it's state so continues to service requests but >>>> fails to log any of them. For an auth daemon, that's a serious issue. >>> >>> Shouldn't sysadmins use the init-scripts for that? >>> If done correctly, permissions should not be an issue. >> >> 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 that >> 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 only > 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 single flat file readable only by root and protected by file permissions. Overall protection is provided by restricted shell access to the host. 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 - this is for the company's network support personnel who log into the backbone 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 quirks but these no longer bother me myself, we get caught out by new sysadmins who have not felt that pain yet > >> It's exactly analogous to compile-time vs runtime errors, compilers >> can't catch the latter. >> >> 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 stuff >> 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! > >> The daemon also tries to log these errors, by writing to a log file it >> 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. > >> 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 more >> resistant to errors than it already is. > > And only grant access permissions to these rookies once they have proven > 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 for 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 cost of fixing mistakes is far less than the cost of leaving new untrained people unutilized and have support tickets pile up... > > 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 :-) > > How much does it cost the company each time this goes wrong and someone > 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. -- Alan McKinnon alan.mckinnon@gmail.com