Re: Configuration Validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Owens wrote on 13/09/08 04:18: ... One of the concerns I have is with configurations, specifically those in /etc and those in ~/.* . The files in /etc are known to the apt system and it's been built to warn the user if config files are to be overwritten. The config files in ~/.* are not recorded anywhere and they are at the mercy of the competency of the developers in format and version control. I'm not aware of any guidelines for these files. ... So when you choose Mark for Complete Removal in Synaptic, for example, it will remove system-wide settings for the package, but not your personal settings for the package? That seems unfortunate. Another use for this: If a graphical program crashes in Mac OS X, the alert explaining what happened lets you relaunch the program. If you choose to relaunch it but it then crashes on startup, the resulting alert gives you the extra option of relaunching without your personal settings, in case it was the settings that triggered the crash. If apt knew which settings files belonged to which program, we could do something similar. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIziGi6PUxNfU6ecoRAiSCAKCqDF7piWgWEQHKJgHR2JJNfq1Q4ACeJ+Eu BkUicnWBoU5tnAO0NowZEBU= =TvKo -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Configuration Validation
I like the idea of a FUSE interface to GConf, and I could see extending the idea to some sort of configFS - I seem to remember the ReiserFS guys talking about a similar idea years ago, before recent events overtook them. I think an interface that involves opening ~/.configfs/myproject/version1/number_of_frobnitzem would be very attractive to developers of small projects, eager to avoid the pain of maintaining a parser. It also has the advantage of degrading gracefully - if configFS isn't installed, it just creates a directory hierarchy to store a program's data. A FUSE-based solution for small projects strikes me as the most effective use of time in the short-term, because you can get some actual evidence about the problem domain as you build the program. Volunteering to convert sendmail.cf to XML isn't something you want to do right away :) - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Configuration Validation
Dear Ubuntu and APT Developers, I would like to introduce an idea and see if any of you would like to review it and see how helpful it would be to solving a problem. These ideas may have already have been expressed so I'd like to see if they are under development elsewhere. In Debian based distros like Ubuntu we have pretty tight control over lots of files. The guidelines for getting something appropriately packaged for the repositories are set up as best practice guidelines for the kinds of support in our projects that make them easier to install, use and modify. One of the concerns I have is with configurations, specifically those in /etc and those in ~/.* . The files in /etc are known to the apt system and it's been built to warn the user if config files are to be overwritten. The config files in ~/.* are not recorded anywhere and they are at the mercy of the competency of the developers in format and version control. I'm not aware of any guidelines for these files. To solve some of the problems with this set-up I had a ponder. A solution that came to mind was to have a validation system which involves two steps (below). This system would be employed to check the integrity of the system at any time, and the integrity of certain package configurations during upgrade time. In essence, just as we recommend each executable come with a man page, we should recommend each configuration file come with a definition and validation xsd. Checking the entire system would be a matter of going through each definition, checking the existence of the config file followed by step one, which would be a translation of the config file from what ever text format it is in to an xml structure using standard transformation methods for various formats, these can be made as plugins for which the definitions would identify in order for translation backwards and forwards to take place. Step two is to use an xsd appropriate for each config file to check the validity of the config against the version of the application installed it is applicable to. An optional step three on upgrade time is to use xslt translation to upgrade configurations assuming no validity or conflict errors. This would allow for much safer upgrading. Now once employed this system would not only be applicable to config files in /etc but also to configurations employed per user in ~/ these checks can be carried out at any time and especially if there is problems with logging in (as I have seen with gnome). I imagine the locations for each xsd, xslt and config definition file would be set locations much like the man pages and could be if successful in future revisions integrated into the way apt/deb works. I propose python as a language of choice to build such a system. I assume much of these ideas to have been discussed at length before, but my searches aren't picking up useful results. Best Regards, Martin Owens -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Configuration Validation
Could you spell out some specific issues that this would solve? For example, are you looking to avoid two packages overwriting each other's files in ~/? If so, can you give an example of that happening? - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Configuration Validation
2008/9/12 Andrew Sayers [EMAIL PROTECTED]: Could you spell out some specific issues that this would solve? For example, are you looking to avoid two packages overwriting each other's files in ~/? If so, can you give an example of that happening? Examples: 1) I manually edit a config file in /etc which is read during startup to do something interesting. There is no standard way of checking to see if the config I've written in valid in format other than seeing if my computer will still boot or see if there is a specific validation utility to check for me. 2) I upgrade gnome, the .gnome2/backgrounds.xml file changes in format between the two versions. the xslt and validators are able to upgrade the config files without removing settings and my backgrounds. 3) I install an application which uses the same settings file, but their xsd validation files don't match, enabling packages to be marked as conflicting protecting corruption. 4) I would be able to use a utility which employs the translation software to edit any xml or oddly formatted config file in vi/emacs/nano/gedit in a manner that suits my tastes without causing errors or problems, say I hate editing ini files but like editing xml files. Regards, Martin -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Configuration Validation
I think we've all had that idea at one time or another, but sadly it's based on a misunderstanding of how the community works. Steve Jobs stood atop the mountain and commanded that Mac developers jump to plists, and everyone jumped because that's how Apple development works. If Mark Shuttleworth stood atop the mountain and commanded Linux devs do the same, people would listen politely then carry on as before. Linux developers are very individualistic in that way, which has benefits and drawbacks. You've identified some of the drawbacks, and I should imagine others will reply stating some benefits soon enough :) Projects like GConf tackle this issue in a more Linuxy way: write a tool, then convince people that they'll get more value for less effort by using it. If you're really motivated to work on this problem, I suggest you talk to them about what you can do to help out. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Configuration Validation
I think we've all had that idea at one time or another, but sadly it's based on a misunderstanding of how the community works. Oh no, I understand that people will be people. I don't expect them to agree. But building systems to validate system integrity doesn't require projects approval directly. Some of this is a distribution/packaging problem and some of it is a system integrity problem. Having a community which then realises the usefulness of new mechanisms to their projects just aims to decrees the burden of work from the packagers and shift it to the projects where it is most efficient. Projects like GConf tackle this issue in a more Linuxy way: write a tool, then convince people that they'll get more value for less effort by using it. If you're really motivated to work on this problem, I suggest you talk to them about what you can do to help out. Ah the gconf approach, this project suffers from not being able to include existing config files, it excludes people from directly editing text files which has always been a big complaint. And it's a copy of a bad idea from windows (even with a gtk-regedit) with a few of the ideas fixed with regards to user data. Although at least they do have validation, if not the packaging integration. It's not hard to Imagen a sort of fuse-fs solution to bridge the gap and ties into deb/apt although it may not work with what their currently doing. As for your 'go away and come back with the goods' suggestion, I'll take it under advisement while I try and pick holes in the idea first. I'm only interested in building something once I understand everyone's objectives and points of view on the subject. Design the blueprints first then go build the building. I'll be talking more about this at UDS in December if you want to join the session. Best Regards, Martin Owens -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Configuration Validation
On Fri, 2008-09-12 at 23:18 -0400, Martin Owens wrote: One of the concerns I have is with configurations, specifically those in /etc and those in ~/.* . The files in /etc are known to the apt system and it's been built to warn the user if config files are to be overwritten. The config files in ~/.* are not recorded anywhere and they are at the mercy of the competency of the developers in format and version control. I'm not aware of any guidelines for these files. Daniel Chen says to look at extending ucf for checking config file changes during installs. He also says look at the validators for sudoers(5) and ssh_config(5)/sshd_config(5). -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
