Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: 1.2.2 release in the near future

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-13 04:50:17 PST
Message Hello Gunnar!

On Saturday 13 February 2010 Gunnar Thielebein wrote:
> >> The solution is to create the folder via svn_config_ensure,
> >> somewhere before svn_cmdline_setup_auth_baton.
> >
> > Fine, can you commit that?
>
> Committed with [2426].
Thank you.
 
> >> Credentials should be stored userwise so we reuse svn's user path in
> >> svn_cmdline_setup_auth_baton. I hope thats OK for fsvs in all remote
> >> access scenarios.
> >
> > Do I understand you correctly that you want to use $HOME/... as
> > config_dir?
>
> No, the config_dir should always be in /etc, /etc/fsvs or whatever you
> configure it for. All global settings for ssl/ssh-svn access should be
> stored in the servers file in subfolder /svn, e.g.
...
> What svn and now also fsvs creates looks like that:
> > ls ~/.subversion/auth/
> > svn.simple svn.ssl.client-passphrase svn.ssl.server svn.username
Could you write some documentation about that? Maybe another HOWTO would be
appropriate.

> Only caveat i've seen by now is that with the use of sudo the folder in
> home is created with root privileges so when using the normal svn client
> this folder will only be accessible by root. One option is to switch from
> ~/.subversion to ~/.fsvs to keep the configuration seperate. Other would
> be suid to the SUDO_USER when creating the folders.
As it's only the creation that makes problems, a single FSVS run as user or
"sudo chown" should fix that, right?

I'd like to avoid doing things like setuid() in FSVS ... that makes security
much worse.

> Btw. do you know about problems when creating files in nfs-based
> homefolders with uid 0?
Only if there's root_squash defined.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-13 04:13:49 PST
Message Morning Phil,

P.Marek wrote:
> Hello Gunnar!
>
> On Friday 12 February 2010 Gunnar Thielebein wrote:
>> Thanks for the fast answer. A small update of mine.
>> The issue with servers file was because I put it in the wrong folder, blame
>> on me.
> No problem, the important thing is that it works.
>
>> But at least I solved for the caching of the credentials.
>>
>> The solution is to create the folder via svn_config_ensure,
>> somewhere before svn_cmdline_setup_auth_baton.
> Fine, can you commit that?

Committed with [2426].

>
>> Credentials should be stored userwise so we reuse svn's user path in
>> svn_cmdline_setup_auth_baton. I hope thats OK for fsvs in all remote access
>> scenarios.
> Do I understand you correctly that you want to use $HOME/... as config_dir?

No, the config_dir should always be in /etc, /etc/fsvs or whatever you configure
it for. All global settings for ssl/ssh-svn access should be stored in the
servers file in subfolder /svn, e.g.

> [groups]
> fsvs = fsvs.agile-admin.net
> [fsvs]
> ssl-client-cert-file = /home/gthielebein/newcert.p12
> ssl-client-cert-password = test123
> [global]
> ssl-authority-files = /etc/ssl/default/cacert.pem

You can also store global credentials (also a global username) here if you want
that. The servers file is very flexible.

If credentials information is not in the global servers file the user will be
asked for credentials.
This information is now finally stored userwise in ~/.subversion if the global
settings in servers file allow that:

> store-passwords=yes
> store-plaintext-passwords=yes
> store-auth-creds=yes
> store-ssl-client-cert-pp=yes
> store-ssl-client-cer​t-pp-plaintext=yes

What svn and now also fsvs creates looks like that:

> ls ~/.subversion/auth/
> svn.simple svn.ssl.client-passphrase svn.ssl.server svn.username

Only caveat i've seen by now is that with the use of sudo the folder in home is
created with root privileges so when using the normal svn client this folder
will only be accessible by root. One option is to switch from ~/.subversion to
~/.fsvs to keep the configuration seperate. Other would be suid to the SUDO_USER
when creating the folders.
Btw. do you know about problems when creating files in nfs-based homefolders
with uid 0?

Cheers,
Gunnar


>
>
>> Thats only this small change in racallback.c, line 47:
>>> cfg = apr_hash_get(cfg_hash, SVN_CONFIG_CATEGORY_CONFIG,
>>> APR_HASH_KEY_STRING);
>>>
>>> /* get svn's user configuration path */
>>> STOPIF_SVNERR( svn_config_get_user_​config_path, (&cfg_usr_path, NULL,
>>> NULL, pool ) );
>>>
>>> /* make sure that folders for storing authentications credentials are
>>> created */ STOPIF_SVNERR( svn_config_ensure, (cfg_usr_path, pool));
>>>
>>> /* Set up Authentication stuff. */
>>> STOPIF_SVNERR( svn_cmdline_setup_auth_baton,
>>> (&cb__cb_table.auth_baton,
>>> !(isatty(STDIN_FILENO) && isatty(STDOUT_FILENO)),
>>> opt__get_int(OPT__AUTHOR) ?
>>> opt__get_string(OPT__AUTHOR) : NULL,
>>> NULL, /* Password */
>>> cfg_usr_path,
>>> 0, /* no_auth_cache */
>>> cfg,
>>> NULL, /* cancel function */
>>> NULL, /* cancel baton */
>>> pool)
>>> );
>> The servers file is still globally stored and used via the conf_dir option
>> (or not) in the hlp__get_svn_config.
> So both directories are used, a global one and a per-user?
>
>> What do you think, can we go with this?
> Very likely.
>
> Please commit what you have, so that I can take a look at that.
>
>
> Thank you!
>
>
> Regards,
>
> Phil
>

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-13 00:50:01 PST
Message Hello Gunnar!

On Friday 12 February 2010 Gunnar Thielebein wrote:
> Thanks for the fast answer. A small update of mine.
> The issue with servers file was because I put it in the wrong folder, blame
> on me.
No problem, the important thing is that it works.
 
> But at least I solved for the caching of the credentials.
>
> The solution is to create the folder via svn_config_ensure,
> somewhere before svn_cmdline_setup_auth_baton.
Fine, can you commit that?

> Credentials should be stored userwise so we reuse svn's user path in
> svn_cmdline_setup_auth_baton. I hope thats OK for fsvs in all remote access
> scenarios.
Do I understand you correctly that you want to use $HOME/... as config_dir?


> Thats only this small change in racallback.c, line 47:
> > cfg = apr_hash_get(cfg_hash, SVN_CONFIG_CATEGORY_CONFIG,
> > APR_HASH_KEY_STRING);
> >
> > /* get svn's user configuration path */
> > STOPIF_SVNERR( svn_config_get_user_​config_path, (&cfg_usr_path, NULL,
> > NULL, pool ) );
> >
> > /* make sure that folders for storing authentications credentials are
> > created */ STOPIF_SVNERR( svn_config_ensure, (cfg_usr_path, pool));
> >
> > /* Set up Authentication stuff. */
> > STOPIF_SVNERR( svn_cmdline_setup_auth_baton,
> > (&cb__cb_table.auth_baton,
> > !(isatty(STDIN_FILENO) && isatty(STDOUT_FILENO)),
> > opt__get_int(OPT__AUTHOR) ?
> > opt__get_string(OPT__AUTHOR) : NULL,
> > NULL, /* Password */
> > cfg_usr_path,
> > 0, /* no_auth_cache */
> > cfg,
> > NULL, /* cancel function */
> > NULL, /* cancel baton */
> > pool)
> > );
>
> The servers file is still globally stored and used via the conf_dir option
> (or not) in the hlp__get_svn_config.
So both directories are used, a global one and a per-user?
 
> What do you think, can we go with this?
Very likely.

Please commit what you have, so that I can take a look at that.


Thank you!


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-12 11:20:42 PST
Message Hi Phil,

Thanks for the fast answer. A small update of mine.
The issue with servers file was because I put it in the wrong folder, blame on me.

But at least I solved for the caching of the credentials.

The solution is to create the folder via svn_config_ensure,
somewhere before svn_cmdline_setup_auth_baton.

Credentials should be stored userwise so we reuse svn's user path in
svn_cmdline_setup_auth_baton. I hope thats OK for fsvs in all remote access
scenarios.

Thats only this small change in racallback.c, line 47:

> cfg = apr_hash_get(cfg_hash, SVN_CONFIG_CATEGORY_CONFIG,
> APR_HASH_KEY_STRING);
>
> /* get svn's user configuration path */
> STOPIF_SVNERR( svn_config_get_user_​config_path, (&cfg_usr_path, NULL, NULL, pool ) );
>
> /* make sure that folders for storing authentications credentials are created */
> STOPIF_SVNERR( svn_config_ensure, (cfg_usr_path, pool));
>
> /* Set up Authentication stuff. */
> STOPIF_SVNERR( svn_cmdline_setup_auth_baton,
> (&cb__cb_table.auth_baton,
> !(isatty(STDIN_FILENO) && isatty(STDOUT_FILENO)),
> opt__get_int(OPT__AUTHOR) ?
> opt__get_string(OPT__AUTHOR) : NULL,
> NULL, /* Password */
> cfg_usr_path,
> 0, /* no_auth_cache */
> cfg,
> NULL, /* cancel function */
> NULL, /* cancel baton */
> pool)
> );

The servers file is still globally stored and used via the conf_dir option (or
not) in the hlp__get_svn_config.

What do you think, can we go with this?

Best,
Gunnar

Ph. Marek wrote:
> Hello Gunnar!
>
> On Friday 12 February 2010 Gunnar Thielebein wrote:
>>>> When putting the option definition in options.c, options.h and
>>>> options.dox it builds but it don't accept the option.
>>> Maybe the name is too long?
>> Indeed, its the length of the optionname. Is there any reason for a
>> restriction of optionname length?
> Only because it's inline in the structure.
> Just change the "char [16]" to a "char*".
>
>>>> It looks like repeating the filter behaviour again. I only wonder where
>>>> to start because I don't find a function to extend with the exclude
>>>> check. Can you give me a small hint where to start?
>>> Do the above hints help?
>> Yes, that helps a lot. I was wondering if it does make sense to update the
>> mtime of directories if this option is active. It's best to reduce it to
>> status only st__action() for now.
> Ok, fine.
> Maybe the option name should reflect that? But perhaps not, in case this
> option will be used on commit, too.
>
>
>> Another issue regarding config_dir.
>> I did a test against ssl setup (the same you find in branch).
>>
>> With no config_dir option set the search path for credential information is
> now:
>>> /etc/fsvs/svn/auth/s​vn.ssl.server/06efd6​678d902375072f173619​22b4b2
>> Is the "svn" before "auth" intentional? I could live with that just want to
>> know.
> Yes, it is. But this is used only if no config_dir option is given, so a
> "config_dir=/etc/fsvs" would use "/etc/fsvs/auth".
>
> Is that bad? To hard to explain?
>
>> When config_dir option is set to:
>>> config_dir=/etc/fsvs
>> I get this warning:
>>> An error occurred: Malformed file (200002)
>>> in hlp__get_svn_config: svn_config_get_config: /etc/fsvs/config:1:
>>> Section header expected
> Yes, that's why I installed this directory in-between.
> Because SVN tries to read the "config" file, which has the wrong format.
>
> My bad; but I don't think that the syntax should be changed now.
>
> BTW, the subversion "config" file is important, because things like "store-
> password" and similar can/must be defined there.
>
>
>> When I use:
>>> config_dir=/home/gth​ielebein/.subversion​
>> It correctly identifies the folder. But a) it ignores my global server file
>> in /etc/fsvs/(svn/)auth/server
> Yes, there's only a single config directory.
> I don't know whether svn_config_get_config() (in hlp__get_svn_config()) can be
> called multiple times, to use multiple directories.
>
> How about a symlink from /home/.../server to /etc/...?
>
>> and b) storing of password and ssl-credentials failed:
>>> 14:00:45.898952
>>> open("/home/gthieleb​ein/.subversion/auth​/svn.ssl.client-pass​phrase/d8354b
>>> a99a7d33871875f62b3bfb303e", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT
>>> (No such file or directory) 14:02:16.320384
>>> open("/home/gthieleb​ein/.subversion/auth​/svn.ssl.client-pass​phrase/d8354b
>>> a99a7d33871875f62b3bfb303e", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT
>>> (No such file or directory)
> Ah, another authentication directory.
>
>> Is it hard to create the parent folders within fsvs when they do not
>> exists. This would mimic the behaviour of the svn client.
> Hmm, always create all directories on a "fsvs url" run? FSVS doesn't know
> which kind of authentication is used.
>
> I have the various "mkdir -p" in "make install", but this wasn't there yet.
>
>
> Regards,
>
> Phil
>
>

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-12 08:30:49 PST
Message Hello Gunnar!

On Friday 12 February 2010 Gunnar Thielebein wrote:
> >> When putting the option definition in options.c, options.h and
> >> options.dox it builds but it don't accept the option.
> >
> > Maybe the name is too long?
>
> Indeed, its the length of the optionname. Is there any reason for a
> restriction of optionname length?
Only because it's inline in the structure.
Just change the "char [16]" to a "char*".
 
> >> It looks like repeating the filter behaviour again. I only wonder where
> >> to start because I don't find a function to extend with the exclude
> >> check. Can you give me a small hint where to start?
> >
> > Do the above hints help?
>
> Yes, that helps a lot. I was wondering if it does make sense to update the
> mtime of directories if this option is active. It's best to reduce it to
> status only st__action() for now.
Ok, fine.
Maybe the option name should reflect that? But perhaps not, in case this
option will be used on commit, too.


> Another issue regarding config_dir.
> I did a test against ssl setup (the same you find in branch).
>
> With no config_dir option set the search path for credential information is
now:
> > /etc/fsvs/svn/auth/s​vn.ssl.server/06efd6​678d902375072f173619​22b4b2
>
> Is the "svn" before "auth" intentional? I could live with that just want to
> know.
Yes, it is. But this is used only if no config_dir option is given, so a
"config_dir=/etc/fsvs" would use "/etc/fsvs/auth".

Is that bad? To hard to explain?

> When config_dir option is set to:
> > config_dir=/etc/fsvs
>
> I get this warning:
> > An error occurred: Malformed file (200002)
> > in hlp__get_svn_config: svn_config_get_config: /etc/fsvs/config:1:
> > Section header expected
Yes, that's why I installed this directory in-between.
Because SVN tries to read the "config" file, which has the wrong format.

My bad; but I don't think that the syntax should be changed now.

BTW, the subversion "config" file is important, because things like "store-
password" and similar can/must be defined there.


> When I use:
> > config_dir=/home/gth​ielebein/.subversion​
>
> It correctly identifies the folder. But a) it ignores my global server file
> in /etc/fsvs/(svn/)auth/server
Yes, there's only a single config directory.
I don't know whether svn_config_get_config() (in hlp__get_svn_config()) can be
called multiple times, to use multiple directories.

How about a symlink from /home/.../server to /etc/...?

> and b) storing of password and ssl-credentials failed:
> > 14:00:45.898952
> > open("/home/gthieleb​ein/.subversion/auth​/svn.ssl.client-pass​phrase/d8354b
> >a99a7d33871875f6​2b3bfb303e", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT
> > (No such file or directory) 14:02:16.320384
> > open("/home/gthieleb​ein/.subversion/auth​/svn.ssl.client-pass​phrase/d8354b
> >a99a7d33871875f6​2b3bfb303e", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT
> > (No such file or directory)
Ah, another authentication directory.
 
> Is it hard to create the parent folders within fsvs when they do not
> exists. This would mimic the behaviour of the svn client.
Hmm, always create all directories on a "fsvs url" run? FSVS doesn't know
which kind of authentication is used.

I have the various "mkdir -p" in "make install", but this wasn't there yet.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-12 05:09:34 PST
Message Hi Phil,

P.Marek wrote:
> Hello Gunnar!
>
>>> The first one seems better to me.
>> I use dir_exclude_mtime for now, ok?
> Ok.
>
>> When putting the option definition in options.c, options.h and options.dox it
>> builds but it don't accept the option.
> Maybe the name is too long?

Indeed, its the length of the optionname. Is there any reason for a restriction
of optionname length?

>>
>> When I looked over the code it seems to me that I need to add the exclude mtime
>> code for every part in fsvs where also the filter option applies.

> No, it should be enough to add that either to st__action() (to just avoid showing them,
> because on commit it might make sense again), or to ac__dispatch() - that should be used
> everywhere. (?)
>
>> It looks like repeating the filter behaviour again. I only wonder where to start
>> because I don't find a function to extend with the exclude check. Can you give
>> me a small hint where to start?
> Do the above hints help?

Yes, that helps a lot. I was wondering if it does make sense to update the mtime
of directories if this option is active. It's best to reduce it to status only
st__action() for now.

Another issue regarding config_dir.
I did a test against ssl setup (the same you find in branch).

With no config_dir option set the search path for credential information is now:

> /etc/fsvs/svn/auth/s​vn.ssl.server/06efd6​678d902375072f173619​22b4b2

Is the "svn" before "auth" intentional? I could live with that just want to know.

When config_dir option is set to:

> config_dir=/etc/fsvs

I get this warning:

> An error occurred: Malformed file (200002)
> in hlp__get_svn_config: svn_config_get_config: /etc/fsvs/config:1: Section header expected

When I use:

> config_dir=/home/gth​ielebein/.subversion​

It correctly identifies the folder. But a) it ignores my global server file in
/etc/fsvs/(svn/)auth/server and b) storing of password and ssl-credentials failed:

> 14:00:45.898952 open("/home/gthieleb​ein/.subversion/auth​/svn.ssl.client-pass​phrase/d8354ba99a7d3​3871875f62b3bfb303e"​, O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)
> 14:02:16.320384 open("/home/gthieleb​ein/.subversion/auth​/svn.ssl.client-pass​phrase/d8354ba99a7d3​3871875f62b3bfb303e"​, O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory)

Is it hard to create the parent folders within fsvs when they do not exists.
This would mimic the behaviour of the svn client.

Cheers,
Gunnar

>
>
> Regards,
>
> Phil
>

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-10 22:17:25 PST
Message Hello Gunnar!

>> The first one seems better to me.
>
> I use dir_exclude_mtime for now, ok?
Ok.

> When putting the option definition in options.c, options.h and options.dox it
> builds but it don't accept the option.
Maybe the name is too long?

>> Option name 'dir_exclude_mtime=no' unknown.
>
> Code in options.c:
>
>> [OPT__DIR_EXCLUDE_MTIME] = {
>> .name="dir_exclude_mtime", .i_val=OPT__NO,
>> .parse=opt___string2val, .parm=opt___yes_no,
>> },
>
> What do I miss here?
>
> When I looked over the code it seems to me that I need to add the exclude mtime
> code for every part in fsvs where also the filter option applies.
No, it should be enough to add that either to st__action() (to just avoid showing them,
because on commit it might make sense again), or to ac__dispatch() - that should be used
everywhere. (?)

> It looks like repeating the filter behaviour again. I only wonder where to start
> because I don't find a function to extend with the exclude check. Can you give
> me a small hint where to start?
Do the above hints help?


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-10 10:15:47 PST
Message Hi Phil,

> The first one seems better to me.

I use dir_exclude_mtime for now, ok?

When putting the option definition in options.c, options.h and options.dox it
builds but it don't accept the option.

> Option name 'dir_exclude_mtime=no' unknown.

Code in options.c:

> [OPT__DIR_EXCLUDE_MTIME] = {
> .name="dir_exclude_mtime", .i_val=OPT__NO,
> .parse=opt___string2val, .parm=opt___yes_no,
> },

What do I miss here?

When I looked over the code it seems to me that I need to add the exclude mtime
code for every part in fsvs where also the filter option applies.

It looks like repeating the filter behaviour again. I only wonder where to start
because I don't find a function to extend with the exclude check. Can you give
me a small hint where to start?

Cheers,
Gunnar

P.Marek wrote:
>> P.Marek wrote:
>>>> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
>>>> existing mtime filter. Do you think this is easy possible to do or do you see
>>>> another way to do that?
>>> Well, I believe that this should be an entirely new config option; the filter options
>>> are convoluted enough.
>>>
>>> Maybe "dir-no-mtime-only" or something like that?
>> So you think of a seperate option?
>> For a filter option I see it easier to be done because the code for filtering
>> mtime already exist and only needs to be extended by checking for the type of
>> the fs object.
> Yes, but the logic for "-v" would get even harder to understand.
> So yes, you're in the right place for checking, but I'd simply use a new option.
>
>>> Do you want to do the dir-no-mtime-only option? Better name welcome.
>> I can try but would first try with the existing code for mtime in filter, I am a
>> lazy guy :-)
> Would it make sense to wait with the release, ie. do you think you can make it in the
> next two weeks?
>
>> Other suggestion would be dir-exclude-mtime, exclude-dir-mtime-changes (perhaps
>> open the naming for further exclude options that may follow)...
> The first one seems better to me.
>
>
> Regards,
>
> Phil
>

dpkg/dist-upgrade versioning

Author pmarek
Full name P.Marek
Date 2010-02-04 23:34:56 PST
Message Hello Gunnar!

> The idea sounds great.
> I tested it and I can get all parameters that are neccessary in my script.
> Parsing parameters looks more clean to me than the logfile.
>
> So for simple operations this would be a good replacement!
>
> *But* If i am performing updates or also dist upgrades on my servers I would
> like to keep apt-actions as one big transaction (and checkin) instead of
> seperate dpkg ones.
Hmmm ... I had a few cases where I had a dist-upgrade of several hundred packages and
couldn't really find out *why* some file was changed.
Maybe I didn't look closely enough ... but if the commit would have included only a
dozen packages it would be faster to find.

> The reason behind is if something went wrong during an system-update I can
> investigate (via trac timeline and source browser) in exactly one changeset and
> see what files were changed. Also if no config changes appear for the specific
> package I can at least see an entry of the apt-action in my changelog, which is
> also without configuration changes, very informational. Otherwise I need to
> handle that via an empty commit, which I personally would like to avoid.
How about "empty_commit = no" for the individual dpkg runs, and a summarizing commit
that includes the revision number range?

> Also I see revision number raising very fast especially when performing updates
> on more than one machine.
Yes, that's true.
Do you mind the number or the repository filesystem? With BDB it's a non-issue, and even
FSFS understands packing nowadays.

> What I could do is building something like a queue via the dpkg replacement and
> perform the checkin via the Postinstall hook. This way I can keep with the
> yes/no for the admin, performing the checkin. I need to think about that further...
Yes, how about just asking the admin on FSVS-install "do you want to keep /etc
finegrained, coarse, or not at all?"


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-04 23:29:58 PST
Message > P.Marek wrote:
>>> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
>>> existing mtime filter. Do you think this is easy possible to do or do you see
>>> another way to do that?
>> Well, I believe that this should be an entirely new config option; the filter options
>> are convoluted enough.
>>
>> Maybe "dir-no-mtime-only" or something like that?
>
> So you think of a seperate option?
> For a filter option I see it easier to be done because the code for filtering
> mtime already exist and only needs to be extended by checking for the type of
> the fs object.
Yes, but the logic for "-v" would get even harder to understand.
So yes, you're in the right place for checking, but I'd simply use a new option.

>> Do you want to do the dir-no-mtime-only option? Better name welcome.
>
> I can try but would first try with the existing code for mtime in filter, I am a
> lazy guy :-)
Would it make sense to wait with the release, ie. do you think you can make it in the
next two weeks?

> Other suggestion would be dir-exclude-mtime, exclude-dir-mtime-changes (perhaps
> open the naming for further exclude options that may follow)...
The first one seems better to me.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-04 08:34:43 PST
Message P.Marek wrote:
> Hello Gunnar!
>
>> that are great news. I have just put my scripts for Debian/Ubuntu in the
>> branches dir.
> Yes, I saw that. Thank you!
>
>> Regarding changes of the new version:
>> What I would have a need for in my monitoring script is an option to filter out
>> dirs which are in version control and get a mtime update due to temporarily
>> created files (Thats what vi makes by default). We discussed that already last
>> year on mailinglist.
>>
>> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
>> existing mtime filter. Do you think this is easy possible to do or do you see
>> another way to do that?
> Well, I believe that this should be an entirely new config option; the filter options
> are convoluted enough.
>
> Maybe "dir-no-mtime-only" or something like that?

So you think of a seperate option?
For a filter option I see it easier to be done because the code for filtering
mtime already exist and only needs to be extended by checking for the type of
the fs object.

>
>>> - Fixed config_dir, so that using other authentication paths work.
>>> Previously $CONF/auth was fixed; better default.
>> Is it now possible to use the home folder to store the svn credentials?
> Yes, it should now.
>
>>> Don't do the "_base" symlink; it breaks eg. "grep -r /etc". Write an
>>> readme instead.
>> Thats so cool! This is a solution for
>> https://bugs.launchp​ad.net/ubuntu/+sourc​e/base-files/+bug/30​4449
> Fine.
>
> Do you want to do the dir-no-mtime-only option? Better name welcome.

I can try but would first try with the existing code for mtime in filter, I am a
lazy guy :-)

Other suggestion would be dir-exclude-mtime, exclude-dir-mtime-changes (perhaps
open the naming for further exclude options that may follow)...

>
>
> Regards,
>
> Phil
>

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-04 08:16:14 PST
Message Hi Phil,

The idea sounds great.
I tested it and I can get all parameters that are neccessary in my script.
Parsing parameters looks more clean to me than the logfile.

So for simple operations this would be a good replacement!

*But* If i am performing updates or also dist upgrades on my servers I would
like to keep apt-actions as one big transaction (and checkin) instead of
seperate dpkg ones.

The reason behind is if something went wrong during an system-update I can
investigate (via trac timeline and source browser) in exactly one changeset and
see what files were changed. Also if no config changes appear for the specific
package I can at least see an entry of the apt-action in my changelog, which is
also without configuration changes, very informational. Otherwise I need to
handle that via an empty commit, which I personally would like to avoid.
Also I see revision number raising very fast especially when performing updates
on more than one machine.

What I could do is building something like a queue via the dpkg replacement and
perform the checkin via the Postinstall hook. This way I can keep with the
yes/no for the admin, performing the checkin. I need to think about that further...

Cheers,
Gunnar

Philipp Marek wrote:
> Hello Gunnar!
>
> I had another idea some days ago, and it came back to me now that you've committed that.
>
> How about using the package names directly, instead of parsing the logfile?
>
> I'd suggest changing the apt configuration, but not to call something *after* dpkg, but
> *instead*:
> # apt-config dump | grep dpkg
> ...
> Dir::Bin::dpkg "/usr/bin/dpkg";
>
> Just call some shell script that commits /etc before and after the _real_ dpkg run!
> It could check whether the parent is apt, so that normal commandline use wouldn't incur
> the overhead.
>
> This would allow to directly use the package names that are given to dpkg; so a "apt-get
> dist-upgrade" would be split into several commits, one per dpkg run.
>
> How about that?
>
>
> Regards,
>
> Phil
>
>

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-04 06:27:31 PST
Message Hello Gunnar!

I had another idea some days ago, and it came back to me now that you've committed that.

How about using the package names directly, instead of parsing the logfile?

I'd suggest changing the apt configuration, but not to call something *after* dpkg, but
*instead*:
   # apt-config dump | grep dpkg
   ...
   Dir::Bin::dpkg "/usr/bin/dpkg";

Just call some shell script that commits /etc before and after the _real_ dpkg run!
It could check whether the parent is apt, so that normal commandline use wouldn't incur
the overhead.

This would allow to directly use the package names that are given to dpkg; so a "apt-get
dist-upgrade" would be split into several commits, one per dpkg run.

How about that?


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-02-04 05:37:43 PST
Message Hello Gunnar!

> that are great news. I have just put my scripts for Debian/Ubuntu in the
> branches dir.
Yes, I saw that. Thank you!

> Regarding changes of the new version:
> What I would have a need for in my monitoring script is an option to filter out
> dirs which are in version control and get a mtime update due to temporarily
> created files (Thats what vi makes by default). We discussed that already last
> year on mailinglist.
>
> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
> existing mtime filter. Do you think this is easy possible to do or do you see
> another way to do that?
Well, I believe that this should be an entirely new config option; the filter options
are convoluted enough.

Maybe "dir-no-mtime-only" or something like that?

>> - Fixed config_dir, so that using other authentication paths work.
>> Previously $CONF/auth was fixed; better default.
> Is it now possible to use the home folder to store the svn credentials?
Yes, it should now.

>> Don't do the "_base" symlink; it breaks eg. "grep -r /etc". Write an
>> readme instead.
>
> Thats so cool! This is a solution for
> https://bugs.launchp​ad.net/ubuntu/+sourc​e/base-files/+bug/30​4449
Fine.

Do you want to do the dir-no-mtime-only option? Better name welcome.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: 1.2.2 release in the near future

Author tekknokra
Full name Gunnar Thielebein
Date 2010-02-04 03:54:19 PST
Message Hi Phil,

that are great news. I have just put my scripts for Debian/Ubuntu in the
branches dir.
Regarding changes of the new version:
What I would have a need for in my monitoring script is an option to filter out
dirs which are in version control and get a mtime update due to temporarily
created files (Thats what vi makes by default). We discussed that already last
year on mailinglist.

Is it possible to use an option like -ofilter=mtime-dir so only adapting the
existing mtime filter. Do you think this is easy possible to do or do you see
another way to do that?

Regarding the changelog:

> - Fixed config_dir, so that using other authentication paths work.
> Previously $CONF/auth was fixed; better default.

Is it now possible to use the home folder to store the svn credentials?

> Don't do the "_base" symlink; it breaks eg. "grep -r /etc". Write an
> readme instead.

Thats so cool! This is a solution for
https://bugs.launchp​ad.net/ubuntu/+sourc​e/base-files/+bug/30​4449

Cheers,
Gunnar

P.Marek wrote:
> Dear packagers,
>
>
> I'm planning to do a 1.2.2 release in the near future, using the fsvs-1.2 branch.
>
> If there are any important wishes, please speak up soon; and if there are none, you
> could prepare packages using this branch (pretty please ;-)
>
> For a short change list please see
> http://fsvs.tigris.o​rg/source/browse/fsv​s/branches/fsvs-1.2.​x/fsvs/CHANGES?view=​markup
>
>
> Thank you!
>
>
> Regards,
>
> Phil
>
>

1.2.2 release in the near future

Author pmarek
Full name P.Marek
Date 2010-01-30 12:50:26 PST
Message Dear packagers,


I'm planning to do a 1.2.2 release in the near future, using the fsvs-1.2 branch.

If there are any important wishes, please speak up soon; and if there are none, you
could prepare packages using this branch (pretty please ;-)

For a short change list please see
  http://fsvs.tigris.o​rg/source/browse/fsv​s/branches/fsvs-1.2.​x/fsvs/CHANGES?view=​markup


Thank you!


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!
Messages per page: