A configuration file get/set tool

[JohnK]

BACKGROUND
I created a thread to learn a bit more about the porting process, and I got information there about that topic, but a developer raised a good point about "not every project is accepted" which got me thinking about if my project is even worthy of being a port.

SALES PITCH
We do not have ONE standard configuration file format. Having one config file format and one method for access would be ideal because then we'd have one method/goal for config "management" (and, by logical extension, the tools like std API libs to get/set consistently in multiple languages--using the agreed upon 'config mgmt practices'--) but lacking that decision, one tool to read and write as many different current config file formats is the only decision I can make (because I do not possess the ability to make a decision about the "best" config management practices and/or config file format).

Most config files are built (use) a simple key/value format so I don't see the need for all the other formats like: JSON, XML, YAML, etc.. so I tried to write ONE tool that will read/write to several of the existing config file formats.

rc.conf:
key="VALUE"

jail.conf
key.sub = "VALUE2 VALUE1";

sysctl
key.sub=VALUE

"googah"
key:value

"whatchamacallit"
key value1 value2

So, my question is: is this concept/code good enough to create a port for (or even use)? Or should I (or: we) just wait for someone who's actually smart to write something?

LINK

GitHub - JohnKaul/sysconf: A dependency free key/value configuration file editing tool.

A dependency free key/value configuration file editing tool. - JohnKaul/sysconf

github.com

NOTE
MODS/ADMINS: I didn't know where to place this post (I thought "porting new..." and "FreeBSD Developing" may have been a bit overkill for this so I decided upon "General"; feel free to move this post and pass me a pointy hat)

 

[Kai Burghardt]

[…] We do not have ONE standard configuration file format. Having one config file format and one method for access would be ideal because then we'd have one method/goal for config "management" […]

As you probably already know, long-term goal is libucl(3)ification of all base system configuration files, so users don’t need to familiarize with each configuration file format anew and one tool devel/uclcmd can edit them all. See also DevSummit/201506/UCL in the Wiki.​

[…] but lacking that decision, one tool to read and write as many different current config file formats is the only decision I can make […] is this concept/code good enough to create a port for (or even use)? […]

No.​

• Why do programmers use so many programming languages? Can’t we have just one compiler that compiles any language you want? Just one transpiler (translator between programming languages) for editing files? No, like programming languages configuration file languages are tailored to their use.​
• The problem remains without a definite statement that configuration file for software XYZ complies with Language So-And-So as laid out in Standard Blablub version 123 you cannot safely edit the configuration file without possibly breaking something. This piece of information must be communicated between the configuration file and your tool. Currently it is “communicated” by virtue of, for example, sysrc(8) being dedicated to edit rc.conf(5) files, and (officially) nothing else.​
• Personally, I have no use of configuration editing tools: I have to place a comment above the configuration value explaining why I chose one value or another. This can be achieved far more conveniently with visual editors such as vi(1). (Occasionally, I use configuration editing tools for automated editing, though, but then I have to be 100% sure that this tool won’t break anything.)​

 

[JohnK]

In pieces:

> longterm UCL
Yes, we're good. I would love that. No problem here; *IF* I made a port for my tool and the UCL direction came out tomorrow, I'd happily delete my tool (but I think my tool will handle the UCL syntax; but now that I say that...).

> a clarification to my initial statement you quoted
So, my statement about "one tool" was directed at more towards a "config mgmt best practice" type thing. -i.e., If we have a std language (UCL, JSON, XML, etc) we can build up the tools around that methodology.

> Standard Blablub version 123
First: haha! I like that.
Second: not sure I understand your point. Sorry. My tool (for example has zero external libs) if that's what your saying. However, if your saying (dumb example) VI has one config format and Vim has another; we could still use intermediate tool(s) to facilitate communications (actually, I'm really only making a mess out of trying to respond to that bullet point so I'm just going to move on so I do not anger you with stupid statements).

> sysrc
Then IMO it's code should be modified to remove the option to edit other files (I'm sure you've seen the code and you already know what happens when you use the -f switch). If it is officially only supposed to work with only rc.conf I would get behind that.

Code snip below only copied here to save you from having to leave the browser window.

# If `-f file' was passed, set $rc_conf_files to an
            # explicit value, modifying the default behavior of
            # source_rc_confs().
            #
            if [ "${RC_CONFS+set}" ]; then
                [ "$SHOW_ALL" = "1" -a "$SERVICE" -a \
                    ! "$DEFAULT" ] || rc_conf_files=
                rc_conf_files="$rc_conf_files $RC_CONFS"
...

> use of an editor (like Vi).
I do too.

> automation / accuracy
My thoughts exactly. I would love to speak with a [battle tested] developer about choices I made in my tool and define what is and what isn't a good idea to use in a tool like this. Honestly, I'd be almost certain if my tool was in a contest to see which was more robust or the best concept or whatever, I'd be out on my ear in the first round because I designed it without being--and talking with--a battle tested developer. But, I'm shooting for "a bird in the hand..." type thing. However, I'm going to commit and push my unit tests in my repo because you make a solid point.

 

[ralphbsz]

Having one config file format and one method for access would be ideal ...
Most config files are built (use) a simple key/value format ...

No. Some config files have much richer formats, typically with data structures. For examples, look at dhcpcd, Apache, or DNS. There the keys and values change meaning depending on what section they are in.

And some config files are very intentionally written in scripting languages that allow for things like if statements and loops. Examples are in particular rc.conf (which is a /bin/sh shell script, just one that is source'ed), and the sendmail files their m4 language. The richness of having a full (interpreted) programming language available in the parsing of the configuration file is what makes for a lot of the power of our systems.

I would go even further, and say that all configuration files should move to interpreted languages. Ideally all to the same one, but I don't know which language that would be, to satisfy (a) all the needs of various things that need to be configured, and (b) all the wishes of various users. Then the logical tool to modify the configuration files would be whatever coding editor the user prefers to use.

For a reference, read the following paper: "Tcl Cures 98.3% of all known simulation configuration problems" Claims Astonished Researcher!", by Golding, Staelin, Sullivan and Wilkes.

 

[JohnK]

No, please do not belabor this point. I obviously understand that there are many different configuration formats. I was referring more to the base (rc.conf, sysctl, jail.conf, etc.) which... *sigh*

 

[RussellASC]

That was one of the strengths of AIX. Instead of hand editing files, everything the base OS configured could be manipulated with a command. sysrc really helps. and Augeas isn't very good. I'm using Puppet and Rex with edit files functions to add and remove single lines today.

 

[JohnK]

That is very much what I was aiming for with my utility; sysrc and sysctl are wonderful but lacking a bit. uclcmd is certainly a nice step in the right direction but too many flags to mess up and possibly even suffering from a lack of attention -e.g., there isn't even a man page for it (a pull request submitted) and is dependent on an external lib -e.g., in fairness this is a high level only example: uclcmd hasn't been updated in years whereas libucl has (even if it "still compiles" when does it cross the threshold of still being trustworthy?).

I have never used Puppet (or any of those big-boy tools) but I have been doing quite a bit with straight-up ssh lately.

 

[Erichans]

uclcmd is certainly a nice step in the right direction but too many flags to mess up and possibly even suffering from a lack of attention -e.g., there isn't even a man page for it (a pull request submitted) and is dependent on an external lib -e.g.

Thanks for adding the pull request.

Can you elaborate why you feel not relying an external lib is deemed to be such an important factor?
I can mainly think of a situation when getting out-of-sync with the relied upon library could happen when something has gone wrong in the process of a OS system update (for example: that's why we have a pkg-static(8)), but that doesn't seem to me that that is the intended working environment for this kind of utility.

 

[mer]

"If all config files for base and ports and third party used the same format...." the job would be simple.
I've used https://augeas.net/ on Linux systems at work dealing with config files that were yaml and xml. I don't know if there is a port or if it covers all potential variants, but it does work for what I've used it for.

 

[JohnK]

Thanks for adding ...

Of course. Not a problem and excited to help out in any way!

For most utilities external libs is certainty not a problem (aside from the out-of-sync situation of course) but I believe a tool like a "system config tool" (or possibly more generically statement of "config mgmt practice" may be a better fit because ultimately the OS should have a sort of "standard practice" for tools to use). I guess I wouldn't chalk it up in the tin-foil-hat column but my point about there being a 'question' or 'possibility' of a system config helper tool being out-of-sync [possibly writing/reading incorrect value or use in translation to another format] is the major factor (Yes, that is what tests are for...). But, again it's more along the lines of the unix philosophy (and a tool should "do one thing only") and if the tool relies on the lib to preform multiple operations like get/set AND translate there is a larger possibility to fall behind.

I've used https://augeas.net/ on Linux systems at work dealing

I've never heard of "augeas". Interesting. Thanks.

Augeas is a configuration editing tool. It parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files.

The choice of a tree is interesting. When I started creating concept code I started down the tree route and abandoned it (I don't think I kept notes as why but I'm going to look). I opted for an array of pointers. And this design decision is what I would love to bounce off a battle-tested developer. I mean, they could spend five minutes reading my header file and utterly destroy my concept/ideas (and I'd know for sure that I should never create a port).

The thought of all third-party tools unifying to a single format is...well, it's probably easier to contemplate the size of the universe.

 

[JohnK]

I have never used Puppet (or any of those big-boy tools) but I have been doing quite a bit with straight-up ssh lately.

I made the above comment and I realized I didn't really explain myself at all (I apologize). Bear with me a very quick second, please.

To give the simplest example, I have a script located on a server and I make a call to it via ssh like (which just does something; like "create a new git repo" in this case):

# gitinit --
#   Call the 'gitinit' shell script on the git server to
#   create a new repository.
# EX:
#   gitinit newrepo "Repository description"
function gitinit() {
        ssh \
        -p 22 \
        -i ~/.ssh/id_ed25519 \
        git@local \
        -t "~/gitinit $1 $(printf '%q' "$2")"
}

I use a similar method to run remote commands and or setup scripts; something along the lines of:

ssh \
    -p 22 \
    -i ~/.ssh/id_ed25519 \
    user@local \
<< EOF
cd ~/
run_main_commands
run_other_commands
EOF

This second method is obviously a bit clunky to do any sort of organized automation (aka: scripts hosted locally) but recently, I found DRIST which allows me to keep setups in files and launch them in a bit easier method and this allows me to do some more advanced automation like:
1. stop jail
2. change jail's IP
3. restart jail
4. update my jail creating custom config file so when it comes time to recreate that jail, it will have the updated IP.

Modifying a jail.conf file via a script, for example, takes a bit of "extra work" that I'd have to duplicate for every similar case. I started down this rabbit hole of creating my `sysconf` tool when I found the -f flag in sysrc (and thought I could use that tool to modify jail.conf files and stuff).

Sorry about the first part of this post but I thought it would sort of expand my vague statement of how I've been playing with "straight-up ssh" for automation tasks--as simple as calling scripts to more robust automation with local hosted scripts (which has a good chance at possibility modifying a system config file).

Link to DRIST:

Solene'% : Configuration deployment made easy with drist

dataswamp.org

 

[bsdscr]

fwiw

Most config files are built (use) a simple key/value format

the above instantly reminded me of finding this interesting awk script @ Gumnos/kv.awk

I would go even further, and say that all configuration files should move to interpreted languages.

this more so

link : https://github.com/Gumnos/kv.awk - A dumb key/value store implemented in awk & plain-text files

the script is imho fairly straightforward and easy to modify

make me ponder how much/little it might take to make it's functionality comparable with JohnKaul/sysconf (...i should read through it )

then again perhaps awk is to limited for such a task ?

 

[Kai Burghardt]

[…] *IF* I made a port for my tool and the UCL direction came out tomorrow, I'd happily delete my tool […]

Maybe my point is: Why “waste” manhours on a stopgap measure if you are apparently capable of programming in C? Choose your favorite component of the FreeBSD base system and push for its libucl(3)ification.​

> Standard Blablub version 123
[…] not sure I understand your point. […]

I meant like HTML files have a document type declaration​

<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HyperText Markup Language//EN">

you can validate against so output is still correct (although possibly semantically garbage).

At least some configuration files can be checked (before committing them), for example sshd -t or just sh -o noexec for rc.conf(5) files. Unfortunately, as far as I understand, UCL does not solve this in a generic way. There is nothing comparable to a document type declaration.​

 

[JohnK]

I don't think it's a stop-gap. I mean, I guess it could be but *I* wanted a reliable/simple tool to make changes for me (because I make mistakes). As far as contributing; I'll start studying the code (a mountain of a task).

The problem remains without a definite statement that configuration file for software XYZ complies with Language So-And-So as laid out in Standard Blablub version 123 you cannot safely edit the configuration file without possibly breaking something. This piece of information must be communicated between the configuration file and your tool. Currently it is “communicated” by virtue of, for example, sysrc(8) being dedicated to edit rc.conf(5) files, and (officially) nothing else.

[]I meant like HTML files have a document type declaration[/]

*light bulb*
Ah! Thank you for that clarification/follow-up.

In the case of my program (sysconf), a declaration stamp would only be another sentinel in a sea of sentinels and thus serve only as an opportunity to exit immediately (-i.e. save electricity by not running). I'm all for saving electricity but my gut says sysconf will probably run about 1000 times faster than shell (theory of "compiled vs interpreted") but that sounds like a fun test. The act of tokenizing something that doesn't tokenize would be the same (empty, null, zero). However, if any programmer tries to SET against something their program doesn't "understand" should have their spacebar removed (you'd never, ever, just try and SET a value in a sea of values in one go over and validate after--no. dumb. don't.)!

The following is just me saying things to...well, say things about how my program works.

Tokenizing is just that; you can split a sentence into parts based on the features you find along the way.

key = value

The tokenization steps are essentially: if you find a word, that's the key. If you find an equal sign that's the separator. and when you find the last word that's the value. --not really but if you know anything about programming, you'd know that--

This is stored in a list of lists, in a case of a key/value config file we'd end up with a list of lists like (this is just a representation not actual):

( key1 value1 )
( key2 value2 )
( key3 value3 )

And when we do GET operations, the program can just look up the key to be retrieved in that list of lists and get the value (SET is similar just adding a SWAP or APPEND operation to the mix).

IF we had a key/value file like this:

subject {
key = value
}

we'd get something like:

( subject )
( key value)

So, the first list (subject) doesn't have a value and is essentially a "non-list entry" and if we tried to do an operation on that entry my program would find the sentinel and encounter an error so-to-speak (not know what to do and just exit hopefully).

In essence, my program has to chunk the file into these tokens and the operation to be performed has to funnel through all these conditions to work properly (like, have more than one element in a list).

However, since I've built in "features" (like not write a duplicate key, etc.) if you try to operate on an APACHE conf you'd get a pretty small conf file. yeah, don't do that.

All that said, sysconf will (because I'm just tokenizing, and not parsing) operate on almost any file with an entry in a key = value style (-i.e. <word>[space][separator][doublequote]<value>[doublequote][terminator]) as long as the line passes all the conditions; if any of those conditions fail, it fails and doesn't write (writing is conditional to understanding).

Overall, I found writing this program to be a lot of fun--for *me*; if you don't use/like/trust it, I don't care--and, if you find yourself with a spare moment, clone my tool do a `make` and play with it (guaranteed not to kick puppies). `make uninstall` will remove it entirely. But I think this thread gave me the answer I was looking for: no port. keep it for me (which is fine).

 

[JohnK]

link : https://github.com/Gumnos/kv.awk - A dumb key/value store implemented in awk & plain-text files

the script is imho fairly straightforward and easy to modify

make me ponder how much/little it might take to make it's functionality comparable with JohnKaul/sysconf (...i should read through it )

then again perhaps awk is to limited for such a task ?

Oh? nice. Thanks for the link. I've never seen an awk script so that was fun to look at (only briefly though so far).
I can't speak to AWK's ability, but I would add in an operation to add/subtract a value.

As in (+=):

key = value1 => key = value1 value2

Also, the only validation I see in set() is to assert the argc == 2 -i.e. both a key and value.
Also, why do you have the IF statement and the return 0 (trying to understand the logic with only 5 minutes of study is sort of dumb of me)? I mean, technically you can just validate if you have two arguments and return data[k] = v correct (that is to say, technically you don't have to care if the value is already present)? ...Oh, never mind I see that you are setting a flag called "changed" to determine if you need to write back. Got it.

Does that script handle all the conditions like?

key = value
key=value
key="value";

I will have to play with this.

 

[JohnK]

FYI: I got another chance to look at that kv.awk. That program is a key/value store type of program and not the same thing as the tool I wrote.

 

[JohnK]

Help (your opinion please):
I wanted to clean up my "config check" feature prompts.

I emulated the sysrc prompts for SET operations.
EX:

% sysconf -f conf.file key+=value2
key: value1 -> value1 value2

But I'm not sure how to prompt when I find a duplicate value in the "file.conf" and "file.conf.default" when checking for duplicate values.

EX:
file.conf

key = value value2

file.conf.default

key = value

Check the file.conf for duplicate values:

% sysconf -f file.conf -d file.conf.default

I was thinking of the following prompt but is that clear/simplistic enough (and in the same spirit as how `sysrc` would do it if it could)?

key: 'value' is duplicate; consider removing.

 

[JohnK]

Okay, this "feature" (aka option) was all of 8 lines of code so, I'm just going with my initial plan of:

key: 'value' is duplicate; consider removing.

and move on. I'll be merging this 'feature' into the main code after I build a unit test (seems stupid to create a test for looping two lists but there is validity in the 'trust' issue and maybe I'll find some edge cases when I think about it more).

Also, I've been thinking more about that 'user trust issue' and I've been thinking about adopting something very similar to `uclcmd`'s testing method. My thoughts are, while it doesn't offer any insight into design methodology failures (doesn't help me any), it would offer a nice way for anyone to build their own test case(s). *shrug*

ref:

https://raw.githubusercontent.com/allanjude/uclcmd/refs/heads/master/run_tests.sh

I really need to spend a bit of time polishing up some code; I just noticed a small chunk of code where I use a loop construct to (re)count the number of list items. ...I'm silly.

int i = 0;
for(; config_line_array[i] != NULL; i++) 
;

 

[JohnK]

I'm glad I did some testing because I found a bug! The short version is: I was using `memcmp()` instead of `strncmp()` in a utility string comparison function. I have pulled my 'config check' code out of my main code, for safe keeping, while I do some code cleanup so, the 'config check' feature won't show up on GitHub for a few pushes.

 

[Erichans]

In my view these would be helpful:

1. Adding a -v or --version option
2. Adding an option _not_ changing the config file but only printing it; this would facililtate users in testing and gaining confidence before use.
3. Setting up some tests, possibly against sysrc semantics.
4. Being really precise about its limitations in comparison with utils such as sysrc(8).
5. If you want users to use it, going beyond your personal use, sysconf should be able to fully detect when a current config setting is such that sysconf isn't able to edit it.

It would also be helpful if you gave some further typical examples of actual config files that sysconf can manipulate, for example with:

"googah"
key:value

"whatchamacallit"
key value1 value2

I have no idea to what specific type of config files these are referring to.

By it's description, it's not clear to me how sysconf could decide correctly, in case of a desired new config setting:
key_k1:value_v1
by using:

sysconf -f example.conf key_k1=value_v1

that its result will actually be:

% cat example.conf
key_k1:value_v1
%

The following sequence shows my observations:

[0-0] # grep program_version /usr/sysconf/src/*
/usr/sysconf/src/main.c:const char program_version[] = "0.0.1";
[1-0] # cat example1.conf
# this is example1.conf, testing the use of ':'
#key1:value1
key1:value1
[2-0] # sysconf -f example1.conf
key1            =       value1
[3-0] # sysconf -f example1.conf key1-=value1
key1: ->
Last value for key removed. Key removed from file.
[4-0] # cat example1.conf
# this is example1.conf, testing the use of ':'
#key1:value1
[5-0] # sysconf -f example1.conf key1=value1
example1.conf: key1 = value1
[6->1<] # echo $?      --> why the error?
1
[7-0] # cat example1.conf
# this is example1.conf, testing the use of ':'
#key1:value1
key1="value1"
[8-0] # sysconf -f example1.conf key1-=value1
key1: ->
Last value for key removed. Key removed from file.
[9-0] # cat example1.conf
# this is example1.conf, testing the use of ':'
#key1:value1
[10-0] # sysconf -f example1.conf key1:value1
example1.conf: key1 = value1
[11->1<] # cat example1.conf
# this is example1.conf, testing the use of ':'
#key1:value1
key1="value1"
[12-0] #

jail.conf
key.sub = "VALUE2 VALUE1";

sysconf:

DESCRIPTION
   [...]
NOTE:
   [...]
    This utility cannot read multi-line configuration values.
    This utility cannot locate configuration keys in "sections".

jail.conf(5) is in effect a multiline configuration file where a section-begin and section-end are designated by respectively { and }. Furthermore, jail.conf(5):

DESCRIPTION
       The  jail.conf file consists of one or more jail	definitions statements
       for use by the jail(8) management program.  A jail definition statement
       consists	of a single word, the name  of	the  jail,  an	opening	 curly
       brace,  a  list	of  at	least two parameter assignments, and a closing
       curly brace.  A parameter assignment consists of	a single word, the pa-
       rameter name, an	equals sign, a value enclosed in double	quotes,	and  a
       terminating semicolon.

       The syntax of a jail definition is as follows:

       jailname	{
	     parameter = "value";
	     ...
       }

means, you can have:

       jailname_1	{
	     parameter_1 = "value_1";
	     ...
       }
       jailname_2	{
	     parameter_1 = "value_2";
	     ...
       }

 

[JohnK]

#1: will do.
#2: done. Just call sysconf -f conf.file
#3: I have unit tests already (not in repo but I just commit them so they will show up later). However, I am going to build up or just steal the testing framework from uclcmd so people can test the program.
#4: Not attempting to replace sysrc (that is something I would really NOT want to attempt). Please do not attempt to do that!! Think of this tool as a helper in scripting/automation.

> types of config files.
That sounds like a full time job just finding config files!? I list example syntaxes it recognizes in the man page but I'm sensing a "disconnect"...

> syntax deciding
I'll have to try and decipher your observation but first pass: For ADDING A NEW ENTRY TO A FILE the syntax of key="value" is default. But, this seems a bit like the #4 above. Please do NOT use this tool for full blown config management. We need to have a sort of plan (like syntax to use) first (and I would NOT want to be involved with that level of liability).

But this part is actually a fun bit, so I want to explain a bit.
If we need something other than the key="value" the config file should already have entries like: "key : value"

When you go to REPLACE `value`, sysconf will understand that it needs to use a colon. So, in essence when sysconf is making a change to a key/value it eats each char and if it encounters a space, it starts counting until it finds a separator (like colon or equal), if it finds a separator then it notes that, it keeps going couting the spaces after the separator...if it finds a double quote it notes that....until it gets to the end. After that it makes the change to the value string (I need 3 spaces, then an equal sign, a double quote, value, another value, double quote...). sysconf can be confused but it's really cool how well it can do figuring out what needs to be done.

> jail.conf
You keep your jail configs in one file (Please note that while I've been using BSD for 20 years but I'm still fairly new to jails (and FreeBSD))? I, personally, keep my config files in separate files (jail, cron, etc) because that is easier for automation tasks. I'll have to think about supporting sections.

I'd like to back up and explain some things:
At its core, I created some library code to tokenize a key/value entry into a null terminated list and a bunch of key/values (from a file for example) into a null terminated list of lists. Iterating a file of key/values can be done with a loop and iterating all values found in each key is another loop. The list(s) management tools in my lib are dumb (no slicing, removing, sorting, etc) but most of these operations are basic programming list looping techniques. -i.e. I can build a simple key store type application or offer up basic configuration management operations like 'default checking' (whatever operations you think you can do with a list).

EX
Want to build an application to reverse the entries in a config file:

key = value1 value2
value2 value1 = key
Count backwards.

Want to split a list in two:

key = value1
key = value2
divide by 2

So, please do not think of this as a sysrc replacement or a config management solution. It wont coordinate daemons/services, check this or that, or do anything like that.

If you know C, sysconf is:

typedef struct {
    int value_count;
    char** values;
} config_t;

If you know shell: sysconf is for getting/setting values and such.
: ${keyone_value:=$(../sysconf -f test.conf $keyone)}

Off-the-cuff example:
You could build a ssh authorized key management tool into your server.

/etc/ssh/keys

bob="232345aaab"
 jane="344322aaddd"

You can certainly use sysconf to edit rc.conf and loader.conf (I do) but I would recommend using vi to get a good/solid setup and plenty of comments first and do maintenance with sysconf. Basic key/value is simple (and thus so is my library) but that does not mean you can't do very cool things with it. Syntaxes like XML, JSON, YAML, UCL are for more robust operations/tasks than simple key/values are for. -i.e. When you think of lists think of databases.

Your post has given me insight into how you (and obviously others in this thread) are thinking about this tool (and, thank you very much for that!) but please do not think of this as a full-blown config mgmt tool for the UCL direction FreeBSD is taking. While current files and tools are in flux you can use something like this to edit file entries that are in the key/value syntax style; if this tool can find a key/value on a single line, it will try and tokenize it. If it can tokenize it, it can change it. I thank you because I think this 'disconnect' explains some of the other posts.

 

[rbranco]

Ansible can deal with all of this.

 

[JohnK]

And <insert program here> can deal with all of "that".

Sorry, you lost me. Care to expand on that any, or is this just a drive-by? Do you mean that Ansible can do config mgmt? Why just Ansible (why not another tool)?

 

[JohnK]

Checking a file's key values against a default file's key values has now been pushed to GitHub repo.

To check rc.conf for duplicate key values against the defaults file (don't worry, everything is safe. both files are opened readonly.):

% ./sysconf -f /etc/rc.conf -d /etc/defaults/rc.conf

In fact, feel free to GET/CHECK values and from any config file. GETting is always readonly. The only time a file is ever opened for write is when a value is subject to change. -i.e. =, +=, and -= operations.

Open file for readonly reference:

sysconf/src/parse-config.c at 7c695b4335c945f6558009b698f3e83907105e43 · JohnKaul/sysconf

A dependency free key/value configuration file editing tool. - JohnKaul/sysconf

github.com