Configuration File Convention

[robb]

Reply all: Oops, I know better...

RE: config in current directory; agreed, I just modified my code to
check the current directory first (configuration and plugin
directories). I have done limited testing on backup and restore via SFTP
and will post the latest working code later today.

And yes, locking down the configuration files outside of user
directories is critical. Something to work on as the package is polished.

Richard Edward Horner wrote:
> Robb,
> 
> Make sure you hit reply-all as the mailing list doesn't hijack
> addresses the way many do so I'm the only one who got your last mail
> (everyone else can read it below!).
> 
> I don't think backwards compatibility is a huge issue at this point.
> Admittedly, this is technically release software since we're past 1.0
> but I have no idea what the install base is so I guess it's really up
> to Brad as the maintainer and we can just patch our stuff however we
> choose (yay source code!).
> 
> I think user backups are important and I think a lot of ppl don't use
> automated backups on things that change infrequently. They just run a
> backup everytime they do major changes.
> 
> The one thing to make sure of, and this is more a package maintainers
> thing, is that read access isn't granted to regular users on "system"
> config files that might have sensitive key data in them.
> 
> Thanks, Rich(ard)
> 
> On 8/21/07, robb <robb at canfield.com> wrote:
>> Thanks for the response!
>>
>> My current code change uses the following paths:
>>   - ~/.brackup.conf
>>   - ~/.brackup/brackup.conf
>>   - /etc/brackup/brackup.conf
>>
>> I like the idea of checking the CWD first, but that would not be
>> backward compatible. Although I am not sure it is too much of an issue
>> in this case.
>>
>> One question I have is how much control should "users" have over
>> backups? If Brackup is running as a system job, is there any need (or
>> desire) for individual users to perform local backups? My guess is yes,
>> if a user wants to make backups beyond, or in addition to, system
>> backups then they should be allowed to do so. So, let system-jobs use
>> the '/etc/brackup' OR '/root/.brackup' configurations (via cron jobs)
>> and let users use their home configuration. Never the twain shall meet.
>>
>> You can also specify the configuration file to use on the command line,
>> and that eliminating all confusion.
>>
>> Of course the system-admin backup requires my patches to restore
>> user/group permissions, but that's another post.
>>
>> If you are using the source type "SimpleFind" then all paths and patch
>> matching are absolute. So far this is working out very well.
>>
>> Richard Edward Horner wrote:
>>> Partially in response to Robb's request for input on path handling
>>> with his filter rules (I say use absolute paths for reasons I'm about
>>> to explain), I'd like to comment on the current usage of
>>> ~/.brackup.conf as the default configuration file. The code handling
>>> this is in lib/Brackup/Config.pm
>>>
>>> I feel like this is less than optimal, especially since you are
>>> created a default config file in your home dir if it can't find one.
>>> At the very least, I think the order should be reversed and it checks
>>> the current directory first and then falls back on the home dir. As it
>>> currently is, let's say you're operating from a config file in your
>>> local dir, cd to fix something and then !Brackup without cd-ing back.
>>> Well, you just made a default config file by accident which you now
>>> need to delete in order to use the one you're using.
>>>
>>> "Why not just copy that config file to ~/ then?" you ask!
>>>
>>> Well, because let's say your company has a server that a couple
>>> different employees have root access on. None of them have the root
>>> password but have sudo rights so that if someone leaves the company,
>>> that person's login is just disabled instead of having to change the
>>> root password and then disseminate the new one to everyone who needs
>>> it. Well, these users are all going to have different home dirs.
>>>
>>> "Well, why not have them sudo bash then?" you ask!
>>>
>>> Well, because that's really inelegant. Perl coders are about elegance,
>>> right? I mean, that's what's up with the capitol letters and
>>> everything, right? :)
>>>
>>> But, no, seriously, I don't like the home dir thing as the first check
>>> especially since a conf file is put there automatically if it can't
>>> find one and I also like absolute paths because sometimes resources
>>> are shared and, therefore, look slightly different to different ppl.
>>>
>>> Yes? No? You're an idiot, Rich? I'm really hungover BTW.
>>>
>>> Thanks, Rich(ard)
>>
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.danga.com/pipermail/brackup/attachments/20070821/986449dc/smime.bin