[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backing up system customization: Is Debian packaging better than Remastersys?



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


Reply to: