On 01/27/2013 07:12 PM, Martin Steigerwald wrote: > Hmmm, okay. > > Since that rsync is so fast and will become faster when I replace it with > btrfs send/receive, I did not care.
I have also noticed that rsync is quite fast but its (in my case) just the amount of storage required which I do not like. I do not have spare HDDs but backup my data to CF-Cards (4 GB) and system to DVDs or a 32 GB SSD. > I can seperate the configuration files I have in VCS quite easily. > > bzr branch /etc somedir > > gives me a copy of it. Also workable via SFTP. Good to know. Versioning-Systems are indeed powerful and I should probably start to learn one. But last time I did that (I think I wanted to try git) I was too lazy to always fetch/edit/commit instead of just editing the file I want to. But packaging would also make the process of editing more complicated: edit locally/check/edit in the package/distribute or something similar. >>> Is the configuration on all machines exactly identical? >> >> No, it is almost identical. My main-system has more HDDs and therefore a >> different /etc/fstab and /etc/mdadm/mdadm.conf. Some things like the >> conky-configuration are also not identical because most of the systems >> are single-core systems but my amd64 machine is a quad-core. And for >> most systems (except my amd64 machine) I want the server-services to be >> disabled while they should run on my main-machine. > > Hmmm, you need to create different packages then or make them act differently > dependending on host name or so. > > This is where Puppet excels at, but I understand that you may not want to > add another thing to the equation. Debian packaging seems complex to the beginner, as seems Puppet. I think that both can do the job well and I should probably read more about Puppet (I have already read some tutorials about packaging) to understand it's advantages. >>> I usually upgrade my systems. But on the 64-Bit switch all I did is: >>> >>> - rsync -a /mnt/…/my-old-debian/etc/.bzr /etc >>> - bzr diff >>> - review which changes I like to apply again and which I like to >>> dismiss >>> >>> I also do this with dot files in my home directory. >> >> This only works if the only customization is in /etc and ~. But >> unfortunately I sometimes need to use software which is not available in >> the Debian repositories and therefore also had some binary applications >> which needed to be transferred. > > Okay, for this, if possible I indeed suggest packaging them. > > For some easy peasy initial packaging check-install may help. I have found http://wiki.debian.org/IntroDebianPackaging which seemed good for the beginning. I did not know about check-install and I am certainly going to try it out when I come to creating actual packages. I will probably first start thinking about which things should go into which package and how I can restore full multi-user-functionality on the way. >>> For my 5-6 Debian systems and for quite some customer machines this has >>> been fine so far. For customers with *lots* of machines something >>> Puppet may well make sense. >> >> How about software I had to compile myself? Can it be synchronized >> without creating Debian packages for it? > > Well, I suggest packages for this. That what they are made for. Aka: > > Use the right tool for the job :) And when I start putting all the custom programs into packages, I will probably learn enough of the packaging to create packages without programs but configuration or documentation instead. >> I already read something about puppet and I also thought it could be a >> way of solving the problem. But then I also think that I already have >> the package-system installed and why I should not prefer something >> already there to another solution which could add additional >> complexity... But maybe I should have a closer look at it before >> starting to package everything. > > Well, for only 4 systems puppet might be a bit off. I´d suggest starting with > puppet not before at least 10 systems. aptitude show puppet mentions a "cross-platform specification language". One or the other way the whole thing seems to get complex in the end... > Ciao, Thanks for another quick and useful reply! Linux-Fan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51057568.7090...@web.de
