On Monday, August 29, 2016 at 5:45:55 PM UTC+2, Jörg Steffens wrote: > Am 26.08.2016 um 15:33 schrieb Stefan Klatt: > >>> and found one point with the new configuration schema: > >>> If you install Bareos, it creates a set of default configuration > >>> files. That's really good to begin with bareos. > >>> But if you work with your own file names like "servername-fd.conf" > >>> and not "bareos-fd.conf" and you delete the file "bareos-fd" it > >>> will be new generated if you run an update of Bareos. That's really > >>> bad, every time after an update Bareos doesn't work any more :-( As > >>> a workaround I truncate the not needed files with an "#" in it. > >> That absolutely true, and it is even documented (since beginning of > >> this week), see > >> http://doc.bareos.org/master/html/bareos-manual-main-reference.html#Subd > >> irectoryConfigurationScheme,Resource file conventions, Disable/remove > >> configuration resource files. > >> > >> While I agree, that this is an unwanted effect, it got the benefit, > >> that you can check in your running system if a resource config file > >> come from a bareos package and is it modified (when using rpm packages). > >> When this feature is wanted (I like it), you get the described effects. > > I don't think so because automatic implementation of new features or > > configuration changes brake often existing configurations. > > They should only implemented manually after review. > > > >>> I think it's better to generate only the standard directories > >>> without files and a default set of configuration files with a > >>> little documentation in an extra example directory structure. > >> > >> The other feature is, that subpackages can bring additional > >> configuration, like tape backend, webui and others. > >> When this feature is wanted, your approach unfortunately do not work. > > Here the same... nothing is bad like a crashed system and you search a > > unwanted change. > > They should only implemented manually after review. > > > >> You see, there is a trade-off between the positive and negative effects. > > I don't think so because the goal is a running system under each condition. > > If I make an update and nothing work any more after this, horrible! > > First of all, I totally agree that an update should never break a system > configuration. So maintenance releases for the different Bareos branches > (12.4, 13.2, 14.2, 15.2 and soon 16.2) are bugfixes or improvements that > do not change the default behavior. > > In master, changes can happen, as we also have to learn and test how > things works out best. > > I understand your point of view, however I do not see this big impact, > as adding a resource (e.g. a profile) will not change Bareos behavior. > Of course, in principle we can add resources that gets automatically > scheduled, however we are not planing to do so. > And we are trying to make things easier for most people, as over the > years I've heard several times complains that resources did not get > loaded automatically. > > As an administrator you still got the chance to disable this behavior, > by using a non-default Bareos configuration directory (either change the > service file or create a /etc/bareos/bareos-dir.conf with following > content: @/etc/my-bareos-config/bareos-dir.d/*/*.conf). > > Anyhow, of course we like to implement what all (or at least) most > people want. As said, in the past, I heard several persons wanting the > feature as implemented right now. > Anybody else with an opinion on this? > > regards, > Jörg
Playing since some weeks with the 16.2 future configuration layout (Preparing the french training) even with a 15.2 is a pleasure to use. So I transfert my lnog old way of doing things inside the new way, and everything is working well. Now if 16.2 rpm (those I'm using) will broke MY configuration in anyway I would be really disapointed, after years of smooth upgrade. I guess I didn't have yet understood how it will impact things. and I have to certainly spend more times on 16.2 (but time is flying as always :-)) I'm expecting that on 16.2 it will just use what I give to it, the new structure (migrated by hand once) and just play nicely with. I deeply hope that the way *.conf are handled in packaging are still the same, like if it exist, don't touch and create a rpm(deb).new config file. Of course I can move my private things to another directory, but I don't think it is the best idea to have. The proposed structure is really nice, and with the coming api configuration ability it a great step forwards. I also undestand that I will have to at least let now bareos-dir.d directory writeable by bareos users. I tend to be more strict in the configuration directory that only root or dedicated owner can write and bareos user can only read. Anyway I'm looking forward this new version, and fantastic time at osbconf in a few weeks. -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
