Ability to export import script edit and diff a running config

[tomekadascientiam]

I think FreeNAS needs a running config.



I am not by any means a Router expert, but I often found deploying and or trouble shooting routers was much easier if I used the running config as a template. Our team had a master config that we would use for each deployment. For large deployments we had scripts we used to alter these configs, for small ones we altered them by hand. If there was a problem we could not easily solve we simply grabbed a copy of our running config and diffed it with the master config or the backup config. We could also post that config to our team site and members could examine it to see if they could spot the problem. We documented changes to the router by sending the configs to our team boss. Our team boss could audit any router by examining its running config. Other teams had the ability to emulate our router by using these running configs they would use these emulations to valuate changes, and to come up with suggestions for future changes.

 

[tomekadascientiam]

Feature #3301 Ability to export import script edit and diff a FreeNAS running config

 

[Dusan]

All you need is already in FreeNAS. You can save/restore the current ("running" in your terminology) config via System -> Settings -> General -> Save / Upload Config buttons. The config file is a SQLite3 database. You can find various SQLite diffing utilities on the internet.
Or, you can simply use the .dump sqlite3 command to dump the DB into a text file and use a textfile comparison/merge utility of your choice (running "sqlite3 /data/freenas-v1.db .dump" in the FreeNAS shell will output the current config in a text form).

 

[tomekadascientiam]

Dusan, thank for very much your answer, I know that you can dump the sqlite3 database. What I was hoping for was something a little more refined, and less ungainly than a data base dump. Something more like a running config from a cisco asa5505.
http://stackoverflow.com/questions/82875/how-do-i-list-the-tables-in-a-sqlite-database-file

 

[cyberjock]

Well, as a matter of course, we don't want you messing with that database. Then everyone will think they know what they need to and start editing it. Next thing we know, this forum is filling to the brim with weird bizaare errors that make no sense at all. Not fun in the least bit.

 

[tomekadascientiam]

Cyberjock I agree with you, I can see nothing good happening from messing with the data base. It is way more complicated than my lil asa5505s running config. Messing with the data base dump leaves me with visions most of witch end in lost data. I will just stick to uploading a saved config from a previous install.

 

[tomekadascientiam]

For deployments of more than 4 or 5 FreeNAS systems a script loading a config file, or modifying a config file would be great. A script modifying a data base dump I guess could work if one stayed on the same version for all of the deployments. I could not see anyone hand configuring more than a few systems at a time it is not cost effective and leads to errors.

 

[cyberjock]

Personally,I'd NEVER trust a custom script for large numbers of deployments. Not to mention the simple truth is that ZFS is designed for absurdly large designs.

And you can script scripts to edit your config file. It's super easy as long as you know a little about sqlite3 and the CLI. And to be honest, I'd much prefer that method to any other method, and I don't even know sqlite3 that well. :)

Again, not something for the vast majority of uses, so not expecting much use of the feature.

Don't get me wrong, your ideas aren't bad. But FreeNAS has extremely limited resources, so priority goes to things that the vast majority of users will find useful. And even at that, it depends on the resource needs of that ticket. The fact that I could, in a few hours, come up with a script to allow you to edit the database to change some parameters for FreeNAS and do a reboot to automate the process kind of makes any idea of creating a configuration editor a misuse of those limited resources.

Just look at ticket #26. It's the oldest ticket in the bugs.freenas.org ticket system. It is to create an initial setup wizard. It sounds like a great idea(and it is). It still exists and is open almost 3 years later. Why? Because while it might be handy, its not exactly difficult to go through the screens and fill in the information yourself. So why throw developer resources at a wizard(and then more resources at maintaining it in the future) when you can just let your average user do the setup. It's not like setup is hard, time consuming, or something you have to do regularly. I've built the hardware and had a FreeNAS server up and running in less than 8 hours for fairly large systems.

Someday someone might be bored and take the ticket and run with it. On the otherhand it might still be in the system in 5 years, and it might still never be fixed when FreeNAS is officially discontinued and replaced with some other system.

If you consider your tickets to be very critical for your business interests, there is almost always a suitable workaround for what you've asked for in the last few tickets. You can also make update and provide them for the developers to incorporate into the official build.

 

[pirateghost]

I have to question how often you are deploying FreeNAS boxes that would seriously require or benefit from this?

Better yet, what kind of project are you working on that requires you to deploy 4-5 FreeNAS boxes at the same time?

 

[tomekadascientiam]

Nothing to large. I am afraid we will have many more workstations than FreeNAS systems. We have six locations. There will be two FreeNAS systems at each location. We have ASA5505s setup with IPSEC tunnels between each location. Location a will push to the pull system at locatin B. Location B will have a push system that sends to the pull system at location A. Locations C, D, E, F will all have similar setups. So I guess it would not be to bad to setup 12 systems.

 

[tomekadascientiam]

Prior to FreeNAS we where using Symantec backup exec.