etckeeper - keeping /etc under version control

[Andrei Popescu-3]

[this was meant for the list]

On Wed,08.Jul.09, 12:35:20, Andrei Popescu wrote:

> On Wed,08.Jul.09, 02:42:56, Scott Gifford wrote:
> >
> > Being able to use something like etckeeper with svn (maybe via svk)
> > would be very useful to me, has anybody tried this?
>
> See #458078
>
> Regards,
> Andrei
> --
> If you can't explain it simply, you don't understand it well enough.
> (Albert Einstein)

[Barclay, Daniel]

Suno Ano wrote:
> Hi folks,
>
>  Chris> Actually I took a peek with Seamonkey as well and apart from
>  Chris> white rabbits that I could live without - and other prettifying
>  Chris> that I definitely will live without :-) everything renders OK.
>
> http://sunoano.name/ws/public_xhtml/faq.html#your_site_css_sucks_mate!_i_have_to_scroll!

Your page says:

 >  Your Site CSS sucks mate! I have to scroll!
 >
 >    You are talking about screen width.

(Actually, no; we are not talking about _screen_ width--we are
talking about _browser_ _window_ (or pane) width.  Remember that
browser windows aren't always full-screen windows.)

 >    Well, I decided to go with
 >    a floating CSS style rather than fixed width — this is good because
 >     it fills peoples screens no matter what the screen width is.

That's a good intent, but you didn't actually implement it.  Your
pages do not actually "float" (adjust in width)well.

Some parts do work.  For example, the three paragraphs at the top,
starting "Connector, geek, ...", and the glass-of-milk image adjust
fairly well.

However, much of the rest of the page does not.  For example, none
of the text in the center column in the rest of the page wraps to
fit the browser window.  (Narrow your window to see what happens.)


The cause of the problem seems to be that you used an HTML table
(or CSS table formatting) to implement the columns.

The combination of table formatting and putting images (or other
fixed-width content) in the column forces the column width, and
in turn text width, to the width the image, not letting a readers'
browsers try to wrap the text to fit each reader's chosen browser
window width.

(When an image or fixed-width content is not in a table column,
even if that image requires horizontal scrolling to be viewed,
the browser can wrap the rest of the text paragraphs to fit within
the browser pane, and their text is readable without repeated
horizontal scrolling.)

Try using the CSS "float" feature for you left-side navigation bar
("Home", "FAQs", etc.) and your right-side "Table Of Content"
column).

Then you probably won't need to use <table> elements (or CSS
table-formatting properties), and any images that overflow
somebody's browser pane won't force all the text to overflow too.



Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]

[Suno Ano-2]

The CSS has always just been a low priority plus, I am by no means a
"webdesigner" ;-]

I am utterly open to suggestions regarding CSS. How would some CSS guru
alter http://sunoano.name/misc/css/default.css in order to make it
better?

The HTML itself, I cannot really change as it comes out of Emacs (I use
Emacs + Muse to write the whole shebang)
http://www.emacswiki.org/cgi-bin/wiki/EmacsWikiMode

On Wednesday 08 July 2009 01:42:56 Scott Gifford wrote:

> Peter Jordan <usernetwork@...> writes:
> > Suno Ano, Wed Jun 17 2009 19:07:31 GMT+0200 (CEST):
> >>  Peter> Metadata = data stored in .svn/ ?
> >> yes, problem is, Subversion does not have one directory i.e. one
> >> .svn/
> >> at the root of the project where is stores metadata but it scatters them
> >> all over the place which is very annoying. Git only has one .git/ at the
> >> project root at that is it
> >> http://sunoano.name/ws/public_xhtml/scm.html#why_git --> metadata
> >
> > svk does not store the metadata in the project path at all
>
> Being able to use something like etckeeper with svn (maybe via svk)
> would be very useful to me, has anybody tried this?
>
> ----Scott.

I wrote a program a few years ago that uses svn to help keep track of /etc.

The name of the program, unsurprisingly is etcsvn.

I stopped using it around 2007, choosing to use paella to help handle some of
this.  I found that keeping track of /etc in its entirety was somewhat
burdensome (this was at a time when packages were placing things in /etc that
shouldn't have been there, such as gconf).

I'm not sure how loosely you are using the phrase "like etckeeper", but I can
give you a short synopsis of similarities and differences.

etckeeper:
uses directories that's easy to add scripts to make it very flexible
(this could be done with etcsvn, with a little bit of work)

hooks into apt to track changes to /etc made by upgrading packages
(I never thought about this when I wrote etcsvn, but it would be a nice
addition)

etcsvn:
/etc is an export, not a working copy (I was concerned about keeping the /
partition small and a working copy is over twice the size).

the working copy is kept in /var/lib/etcsvn (or somewhere under there, I can't
remember now)

the working copy is only readable by root

etcsvn sets a umask of 077 so exports back to /etc can be done securely

etcsvn uses svn properties to keep track of ownership, file permissions, and
mtime (this could be extended to keep track of other metadata, including
extended attributes.  I knew nothing about xattr when I wrote this).

since subversion can handle empty directories, etcsvn can do so as well

since subversion can do a checkout of a subdirectory in a repository, you can
keep /etc from multiple machines in the same repository (in these cases the
repository was never accessible from those machines, I used to keep it on my
laptop and use ssh port-forwarding and agent forwarding to access the
repository on those machines)

etcsvn doesn't handle authentication to the repository (I normally used ssh to
handle this)

etcsvn may need some work to use https methods better

etcsvn uses an etcsvn.conf file in its working copy, where you specify the
directories and/or files to be tracked.  This means that you can also track
files and/or directories in /var or elsewhere, and keep ownership,
permissions, and mtime straight.



I haven't touched the code in a long time.  It may not work as it used to.  
After looking at it, the last thing I did was a few weeks ago, when I changed
all the os.system calls to use subprocess instead (something I've been trying
to do across the board with all my python code).

I have been also thinking about using another strategy, instead of keeping all
of /etc in subversion.  Basically like this:

get package list through dpkg --get-selections
conffiles = list()
tracked_files = list()
for package in packages:
        dpkg --status (get the conffiles and add them to the list)

walk through /etc
check if file is in conffiles list
if file in conffiles:
        check md5sum
        if md5sum differs:
                tracked_files.append(file)
else:
        check file in ignored_list
        if not in ignored_list:
                tracked_files.append(file)
        if file in track_anyway_list:
                tracked_files.append(file)

add tracked files to svn

This would keep the amount of files that were being tracked down to a minimum.

Anyway, if you are interested in it, look it over, maybe try it out and let me
know.  It may be outdated, but bringing it back up to date shouldn't be too
difficult.



--
Thanks:
Joseph Rawson