Am Sonntag, 27. Januar 2013 schrieb Linux-Fan: > On 01/27/2013 05:44 PM, Martin Steigerwald wrote: > > Am Sonntag, 27. Januar 2013 schrieb Linux-Fan: > >> But I am still not fully satisfied with this solution because making a > >> live-DVD out of the currently-running system has some issues: > >> > >> 1. If I ever need to re-install my system and do not have the > >> > >> remastersys-DVD available, I will have trouble restoring all the > >> custom configuration. > >> This could e.g. happen if an update to a new debian release fails > >> reproducibly. > > > > Maybe I am too old school for this: > > > > For > 8 years I just have my Debians and I rsync them to another disk. > > I believe this is a good full-system backup strategy but I would rather > like to backup the customization only or somehow separate it from the > basic system in order to give it different importance at backup times.
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 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. > > Yes, in case of some special setups, there have been issues, but with > > some experience with the Debian package management there so far has > > always been a way out for me. > > > > Sorry, I have no experience in this remastersys stuff. > > > >> Recently, when I read about Debian packaging and preseeding on this > >> list, I got another idea: I could package all my customization into > >> some Debian packages and some virtual packages which would then > >> install all software I use as dependencies. This would also make the > >> updating of my i386 machines much easier: If I only changed > >> configuration or such they could just update via aptitude update && > >> aptitude full-upgrade or similar and if I updated some of my > >> self-compiled software, I could (a) use the source-package or (b) > >> download an i386 version that was cross-compiled on my amd64 machine. > >> I would be able to have the most recent configuration and package > >> selection on all three systems while only maintaining a common and > >> customized repository. In order to back up my system I would only > >> need to backup the repository. Live-DVDs could still be created with > >> remastersys but I would no longer depend on them and I could safely > >> do re-installations even changing > >> Debian-releases with minor problems only. I could further divide my > >> custom packages to be able to create a CD version of my system with > >> limited features or such. Adding some of the customization to my > >> friends' systems would also be much easier. > > > > This may just work well, I never tried it. > > > > I just wonder whether you are trying to over-engineer. :) > > This is why I first wanted to ask :). > > > 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. > > > Actually I do not do the effort. > > > > What I have is this: > > > > - apt-get install bzr > > - cd /etc > > - bzr init > > - bzr add fstab hostname network/interfaces resolv.conf … > > - bzr commit -m "Initial." > > > > And in case of an error: bzr uncommit :) > > I have never used a version-system so far and this would probably only > work for configuration files, unless I put the whole system into version > control -- but this would not solve my issue with differences on i386 > and amd64 unless I put my HTML-Documentation into /etc (I used to have > /etc/ma instead of /opt/ma but found it the wrong directory for my > purpose) Well, I wouldn´t put the whole thing into it, of course. > > 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. > > 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 :) > 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. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/201301271912.40892.mar...@lichtvoll.de
