libUCL / UCL as FreeBSD config question

[Dan Partelly]

> 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.
> 
> 

It’s not that simple. Mandatory locking is the minimal protection you need .  And mandatory locking is not available by default on most unixes, it needs to be specifically enabled . (Windows NT and derivated kernels offer support) 

And even with mandatory locking the support would be iffy.  With text files there is the constant temptation to just throw vi on them. Unless your daemon keeps all the time a mandatory lock on all confif files, this is not going to work well.

 A proper solution might need kernel support,and quit using text files for OS config.  Hence IMO a proper solution has very few chances  to be implemented.  Most people seem to have some fetish with text files, and  like to be stuck in past.  It is like somehow magically .txt files are immune to corruption, but any other format is not.

See, allegedly, some ppl from Linux world went as far as gathering bitcoin  to pay for a hit on the author of systemd, Lennart Pottering. Systemd might not be perfect, might be buggy,  not “ready” yet for enterprise , (or it might, I dontr really use any kind of Linux, so I cant tell ) but it is much needed innovation.  Can’t really even call it innovation,  
Windows servers have such features since long ago. Its merely catch up. ( NT derived  kernels are awesome beasts IMO, with very cool design )

Also, it is my opinion that every BSD desktop distribution started with the left foot. Instead of developing window managers and desktop managers and reinventing the wheel , their focus should have been translating some utils from BSD base in libraries,  write some  daemons like notifyd, launchd (just general examples, not necessarily copy their implementation )
and build frameworks to manage geom objects. network interfaces,protocol configuration, cron like features and so on. Instead all invent new desktops and WMs and so on. 
But the issue is, those all sit on a flimsy scaffolding, of frankensteined toolkits  and Rube Goldberg contraptions.  IMO, not a single BSD desktop distribution is  attacking the right problem. The problem of the unix desktop must be solved starting at OS framework level.

Ironically, some of the features which are desirable to have in a modern “enterprise” OS rest on much the same daemons and frameworks which would make the proper unix desktop possible.




> On 23 Nov 2015, at 00:24, Mark Heily <mark at heily.com> wrote:
> 
> 
> On Nov 21, 2015 3:07 AM, "Dan Partelly" <dan_partelly at rdsor.ro <mailto:dan_partelly at rdsor.ro>> 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 <http://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.
>