On Mon, 2006-06-12 at 14:04 +0200, Eric Spakman wrote:
> Hello Nataneal,
hi hi
> >> Currently we create a <package>.sha1 file for every package instead of
> >> one big sha1 file. I played with it a few days and this implementation
> >> seems to work most flexible, although I can't rememember all the reasons
> >> exactly anymore ;)
> >
> > Probably because its difficult to remove pacakges otherwise. Thats
> > probably also why Nathan wrote the sfic tool at all. yafic cannot
> > add/remove files without rebuilding the entire database.
> >
> Correct, although it's somewhat difficult to remove a package without a
> .list file.
apk-tools create the package listing on the fly. Something like:
tar -ztf package.apk > var/db/apk/package/CONTENTS
tar -zxf package.apk
The challenge is the upgrades. I thought it was easy:
apk_delete package (old one)
apk_add package (new one)
But the, what happens if you try to upgrade apk-tools? after apk_delete,
there are no apk_add to install the new package. I solved it by first
unpacking the new package, then compare the lists and remove all files
that are in old list but not in new list. (reverse sorted so files are
removed before dirs)
> Currently package removing is not implemented, although an
> implementation where a package list is created dynamicaly (with tar -ztf
> at boottime) should be possible. I'm not sure if package removing is worth
> the hassle, it has a lot of corner cases so the easiest way to remove a
> package without problems is to remove it from the load list and reboot :)
> That's one of advantages of a system in RAM.
Except that for us, the reason to do upgrades is to avoid reboots. We
want high uptimes. (and sacrifice some size for that)
<snip>
> >> But there is
> >> ofcourse nothing against using a tool like this when there is enough
> >> space, afterall when backups are done outside the package every tool
> >> can be used to store the config.
> >
> > Yes. We were talking about separating local backup handling from package
> > manager. (we have been talking of switch to ipkg). However, you do need to
> > create
> >
> Some text is missing?
umm.. *blush* i think i went to lunch and forgot it. sorry. I dont
remeber what i was thinking and it was probably not important.
ah.. yes probalby that you need a wrapper script on top of the pakcage
manager. The wrapper scripts installs the package and creates the
checksums. Then you could use any package manager.
But I have started to think that it can be hard to implement.
> >> The only thing is, how are the changes saved in the database used at
> >> boottime? The "configdb" package in our implementation is always loaded
> >> last in pre-init, but when using a database this seems more difficult
> >> to me (it has to be loaded before init).
> >
> > I have runtimes init.d script that loads the runtimes and local package
> > overlays (local configs in other words). The overlay itself is just a tar
> > archive that is extracted to $ROOT. Right after the overlay is extracted I
> > run "lbu update":
> >
> > Here is the code:
> >
> >
> > cmd_update() { [ $# -lt 1 ] && usage_update
> > cd "$ROOT" list=$( for i in "$@" ; do echo $i | sed 's:^/::' done |
> > lbu_filter ) $SFIC --delete "$COMMITED_TDB" $list
> > $SFIC --add "$COMMITED_TDB" $list
> > }
> >
> >
> > lbu_filter will filter out everything except whats in APK_LBUDIRS.
> >
> > So after the local config is loaded, I replace the entries in the
> > commited.tdb (recreate the checksums for those files)
> >
> Our approach is to load the "configdb" package as last package in linuxrc,
> so before init is started. The files in the configdb will overwrite the
> existing config files pre-init so those are used instead of the ones in
> the packages themselve. The sha1sums of the original files in the packages
> are calculated before that.
Thats basicly the same as we do. Execpt alpinelinux can load
packages/configs from different locations (usb *and* floppy). For
example, its possible to only store network configs on floppy, and load
packages needed to get NFS working (portmap is the only package needed
for that), then load a new package.list from nfs and load packages +
configs from nfs in a later boot stage. Got it working last saturday.
> Ofcourse this means that the backup system can't see if a change is saved
> before, it always notes a difference (the calculated sha1 sum is from the
> original package). This doesn't matter that much because the "configdb"
> package is small, so saving is fast and it also makes sure "old" files are
> removed from the configdb package.
Yes. and you actually dont need to see what files have changed either.
You need to save them all anyway (all the files that differs from
package) It just that we want a reminder displayed on web config that
you need to save to local media or you will lose config in next reboot.
so:
if lbu status -q ; then
# no need to save. display a green icon of some sort
else
# need to save. display a red icon of some sort
echo "Please remeber to save configs to floppy"
fi
<snip>
> For the list:
> Currently the first device in PKGPATH is the "backup" device where configs
> and modules live (and ofcourse packages if PKGPATH has only one entry,
> just as it is now).
Why not having a separate variable? What if first device in PKGPATH is a
cdrom?
> >>>
> >> Agree, but see my comments above. Ofcourse having a .local file in the
> >> package doesn't "hurt". It's a question of the configtools to use it or
> >> not.
> >
> > I actually think I have it myself. I think apk_add will look if there is
> > a CONFFILES listing, which is exactly the same thing as .local in lrp. If
> > its there, use it, if its not look up APK_LBUDIRS. So you can override it.
> >
> It's not exactly the same, but close. Some files like ssh-keys, password
> and group shadow files and so on are not config files and not listed in a
> conf entry but should be backupped.
But all (most) of them are in /etc. Technically, if you other things to
survive a reboot you need a disk, or the files are on wrong location.
You could ofcourse define a few directories that should be added
(like /root/.ssh) but there should not be many of those.
But I need to think a bit more on this one. I actually think that
the .local file is useless for us. (but, yes they dont "hurt")
--
Natanael Copa
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
