From owner-freebsd-hackers@freebsd.org Sun Nov 22 22:24:55 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F722A34D30 for ; Sun, 22 Nov 2015 22:24:55 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C73621018 for ; Sun, 22 Nov 2015 22:24:54 +0000 (UTC) (envelope-from mark@heily.com) Received: by ioc74 with SMTP id 74so171171135ioc.2 for ; Sun, 22 Nov 2015 14:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ImFAt0uF61mjwlChXZ1XYa4BfeUBGENMH6kXEorYABw=; b=tKTy6HNz5qQqj//63OBq5BXr4jfy481+O3SMfCY6R5xOmmlCIPOoxd9xniwal/FJON +3P7Uxss7pHM0n3yshtfCsQWUX4kxTmdMhvyKhXtF/G5ohmefyP9hhw6GGbDcjHKgr6a KENpqQsvLzeYekKvf5hwJ5HVM1wvlF3vpnEjBKLrNwlpF3Wz/G6eGQQFzeC5UJGaZKiv 9H/aJVLE+l0gGeBwcQecYb9U73IOfOVaaBCNpZQKV04mF6PL6NDXbTJqKcHKpJudefPZ vnPVAGR453dFh746VMIzgtZf+rAYm2nlr25UcosQMk4Us8N++Msj7WFZoBY7ri9HPAVu 8rkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ImFAt0uF61mjwlChXZ1XYa4BfeUBGENMH6kXEorYABw=; b=A7NHJteFaAdYtaYs3H3o+k3MJ5D+pWsERXUkIDeHg8B22Cr7YP81xIEfcWPYfjXCMp tH7h+piXy2c3WRw04cbxKZQOcNbwkNO4XTT1sYPmNzA2NjMmwIPrbEloarvt4ngIrN3V IU7hdbkucj5d7/xhaFIADLuIMZkZq10Sdye6qRR6jBJY1WqxWAaqQBrHXdrgKO7yTdzh dc3QOnuBuT7Eq3eaAY62pkBgwjYRqMNzw2ipFp314cQLPUlp8lLiNQUSvalzaPmeeUoZ wd/8kQRv5QfGzMqkMjumTmyTymy4AgBbjhefQRVESbgEue8AuOwxLteVBSO5BqV0RPTh vaPQ== X-Gm-Message-State: ALoCoQnktKvIg86jAgr+Sg/bhy1RbwDLAMMyZ/vjdEOx8D7OXyPjlAMt0UteUocXvmI3itlad4fW MIME-Version: 1.0 X-Received: by 10.107.43.151 with SMTP id r145mr16471616ior.7.1448231094040; Sun, 22 Nov 2015 14:24:54 -0800 (PST) Received: by 10.79.82.3 with HTTP; Sun, 22 Nov 2015 14:24:53 -0800 (PST) X-Originating-IP: [71.70.169.30] In-Reply-To: References: <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro> <564F6118.5030702@freebsd.org> <5576AC9A-791F-4B52-9433-32D2806D35C9@rdsor.ro> <564F8E1F.8060600@freebsd.org> Date: Sun, 22 Nov 2015 17:24:53 -0500 Message-ID: Subject: Re: libUCL / UCL as FreeBSD config question From: Mark Heily To: Dan Partelly Cc: freebsd-hackers@freebsd.org, Allan Jude Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 22:24:55 -0000 On Nov 21, 2015 3:07 AM, "Dan Partelly" wrote: > > > Absent the will to adopt a proper, fully transactional and atomic mechanism of storing OS configuration, > I would go back to the drawing board for a while. The creation of a "proper" mechanism for storing OS configuration aligns well with the mental roadmap that I have for the StateD project... The current version of stated(8) provides the front end for a unified configuration system with pub/sub notifications. The next incremental step is to build the backend, and the initial implementation will just scrape the configuration files in /etc and present them in a read-only fashion. For the next major step, we could build an entirely new backend that uses libUCL to provide read/write access to configuration settings. This access would be mediated through stated(8) to provide history, transactions, locking, atomicity, and notifications. For example, imagine that one could change the host name and domain name with this command: statectl set hostname=foo domain=bar.com Behind the scenes, stateD would acquire a lock on appropriate current configuration file(s), make a backup copy of the current state, use libucl to modify the files to reflect the desired changes, unlock the file(s), and generate notifications. IMHO, it would be better for libucl to focus on being a general-purpose library for parsing/generating configuration files, and have another layer like stated(8) that manages things like concurrency and transactions.