Hi KP Am 13.10.2015 um 17:33 schrieb kp kirchdoerfer: > Am Dienstag, 13. Oktober 2015, 16:49:04 schrieb Erich Titl: >> Am 13.10.2015 um 16:25 schrieb kp kirchdoerfer: >>> Hi Erich; >> >> ... >> ..
>> >> I am wondering if I would have had no issues at all by upgrading step by >> step. I probably would have had less at one time. > > I also _believe_ that your assumption about "quietly working and almost > unmaintained" LEAF boxes is correct, which is a security issue and drawback > of > providing stable software. Of course, but we are human beings :-( > > I also _believe_, that you might have had less issues at one time if you have > had upgraded in smaller steps - or have had a test system to (dual boot) and > time to test one of the numerous alpha/beta/rc versions. That was my relief, I was always capable to just boot into my secondary system and get my internet connection back... proof of concept :-) > > And it is still my hope that your work on upgrade script will engage users to > update more often than we do now, even if we try to release often and > therefor > to keep changes between releases as small as possible. That is the ultimate goal, give lazy bastards like me no reason not to upgrade :-) It all depends on the effort required to upgrade. At my former employer we hade a big LEAF installation with two physical firewalls with 16 ports. We had some sort of failover with a third system which was wired into the network and could take over either of the two others. It was supposed to be a 7x24 operation and this made it almost impossible to upgrade. Of course no one invested into a testbed, so even if I insisted that upgrading was necessary it was always put due to more important issues. I believe the installation is still at the same state I left her three years ago. > > I also _believe_ , that integration of apkg -u into the upgrade script will > be > easier to accomplish the then smaller changes and more helpful, than reinvent > apkg and configdb. You are probably right. Still I had a closer look at the apkg code and some reinventing there would be for the better. I believe we should invest more into those tools. Looking into the various scripts makes me believe that we should do some work in consolidating them, putting some effort into standardizing them. For example - many scripts include some logic to mount/umount something, do some error handling, e.t.c. Using a library to do this could make the code leaner and better to understand. - There is this wrapper script with the incomprehensible name 'with_storage' which is really useful, but lacks a resonable name and does not log anywhere (and is close to unreadable). I started to use a small tool library for upgrade to keep the code more readable. We should give the users/developers tools to facilitate their job and possibly attract them to contribute. There are a few things to be mentioned in favor of the differential save of the configuration files. - only real user changes would be saved - new parameters would automatically be installed as the differntial saves would be applied to virgin files. Then, shorewall has its own way to deal with updates. It has an option to update its parameter files if it detects missing/deprecated parameters. apkg -D does most of the things a differential save would need, but it clutters output with some pseudo information which are for human readers only and makes it unusable for the patch utility As I said I am toying with the idea of a differential backup, first upgrade must be made rock solid. cheers ET ------------------------------------------------------------------------------ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
