Hi Paul, >> In that case it's better to just scp all new packages to the MSDOS fs >> and reboot. This has the same function as an 'apkg -u -a' but clears >> possible old unused files, reboot all daemons and updates initrd. > >Not if I understand things correctly. In order for apkg -u to do the >diff/merge of changed config files, it needs the old config files on the >running system and the new config files in the lrp modules. > True, like Kp said there are some more options with apkg -u, like diff /merge. But in the case of a complete update, if you simply scp the new packages to the fs and reboot. The user changed config files are preserved, which is ok in 99% of the cases.
>Am I misunderstanding things? > >Literally, the biggest pain in the ass upgrading B-U has been merging >config files, so if a sane procedure is done for that, it would be a >major win. In the letter KP wrote, it sounds like right now, I need to >remember which modules have updated config files, and do an apkg -u for >each. Now, I guess I could just do > >foreach m in /mnt/*.lrp ; do apkg -u $m ; done > >after scping the files, but it seems like something you'd rather get >done right in a standard fashion? There is no real need to merge config files in most cases. As long as there are no incompatible config changes in packages you can just update without merging. F.e. If you want to update the kernel version, it's enough to update the modules, initrd and kernel. The /etc/modules file, if changed, is saved in the configdb so no need to merge. The user changes are preserved. If I want to update a complete release I just scp everything to the fs and reboot. All my config changes are preserved. > >If I'm confused, please accept my apologies. > I'm not sure if I am confusing things ;-) There is a difference between updating some packages (in which case apkg -u is very convenient, because no reboot is necessary and you can finetune some things on the running system) and a complete update, including a kernel and possible library upgrade. In the latter case you have to reboot anyway (the system could even become unstable if you would update base libraries and the kernel), so scp and reboot would be the only way. In both cases the user changes are preserved. In the first case you can 'finetune' on the fly if necessary, in the second case there can be some finetuning necessary but in most cases it just works. > > >> >>> 2: I'd like a command that simply gives me a list of all change or new >>> files changed since boot. Maybe by default only show changed config >>> files, and an option to show all changed or new files anywhere in the >>> system (including /var/log /var/run, et al...). >>> >> Files in /var/log and /var/run are not taken into account, they are >> never saved. You can scp them ofcourse. >> But because no log or var files are in a package, the complete >> contents of those directories is dynamically created so changed/new. >> A simple 'ls -la' would give you a list of those. > >/var/www/.htpasswd unless you've fixed webconf & mhttpd > That file is saved in the configdb, so yes it should be fixed ;) >> A list of other changed files is difficult to create. For the config >> system every file changed/added in comparison with the standard >> packages is 'changed' including the files already saved. A 'complete' >> backup is always done for a few reasons: >> -it removes stale changed config files from no longer installed >> packages. >> -it's fast because the configdb is not big >> -it's much simpler and robust >> >> So it's possible to create such a list, it will not contain the >> changed config files after reboot but all changed files compared to >> the 'standard' config in the packages. > >Which is only part of what I'd want. I just set up a bunch of routers >from scratch, and during hot stage, there were a lot of changes I made >to the run-from-ram OS. I really would like to see the difference >between the files in configdb.lrp and the running system, as well as the >difference between the distributed config files and the running system. > It should be no problem to see the differences between the running system and the configdb or the distributed files and the running system, but that code is not implemented yet. The first option can be something like the diff as used in apkg -u. The second option is the list that is created when a 'save' is done. So yes, all ingredients are present, but no specific scripting is done yet to show that output. >It's a basic "What am I going to do to myself if I save this config?" >kind of question, that I suspect a lot of operators need. > >> You can take a look at the files saved in the configd. Just mount >> your MSDOS fs and do a 'apkg -c /mnt/configdb'. > >Not the same, but I think you understand what I'm suggesting now? > I think I understand. >>>> - During backup the sha1sums of the files in memory are compared with the >>>> saved *.sha1 sums, new files are detected and duplicates are filtered out. >>>> For example: when one package has an etc/ppp directory in <package>.local >>>> and >>>> another one an etc/ppp/dsl-providers file listed, the dsl-provider file >>>> would >>>> be find twice and also stored twice in the configdb. >>> 3: Stored twice in the configdb? Isn't this a bug? >>> >> Nope, see the sentence above the example: "duplicates are filtered out. >> " > >OK, so /etc/ppp/dsl-provider is now only stored in configdb once. Correct. >And if I remove the pppoe package and reboot, the next time I do a full >backup, /etc/ppp/dsl-provider will be removed from configdb, or will it >remain because it's associated with the ppp package now? > Currently it will remain because it's associated, but it can be easely changed. Note that ppp/pppoe is one of the few exceptions. For convenience we create the sha1sums of the complete etc/ppp directory, but we can also list the individual files in which case the dsl- provider file is removed when saved. During this beta cycle we will finetune this kind of details. >Likewise, if I create /etc/init.d/iptables-local because I don't want to >use shorewall but do need a minimal iptables configuration, will it get >saved in configdb because it's covered by root.lrp, or not? If not, how >do I get extra files to be saved? local.lrp only covers /usr/local. > No, it's not covered by root.lrp. The function of local.lrp changed, you can now use it to list files you want to 'force save' like your example. You can take a look at the local help file to see its use. Eric ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
