Re: Non-interactive install proposal
Manoj Srivastava <[EMAIL PROTECTED]> writes: > Drake> On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: > >> > >> What is the benefit of keeping packages in an unconfigured > >> state? > > Drake>It's a reminder to me that I need to configure this package still. > > I prefer the approach to ask questions first, and configure as > it installs. If we are spending time to do this, we should do this > right. In general, you can't ask all questions first; you can ask some questions, then unpack and debian-configure the packages, but then you still have to do a lot of configuration (using an editor or some configuration programs that "ask questions"). Think about the kernel-image postinst, generated by your kernel-package. Only some of the possible questions are really asked. So, either you ask all questions in advance, even those that are not relevant for a specific configuration. Or you supply a script for asking the relevant questions, but even that might be difficult, because the questions depend on the state of the system which might be different before installation than when the postinst is actually executed. Ian's list is a good starting point (and having the choice of being asked some questions in advance is good), though it doesn't solve the above points, and it's only focused on "how can i make the current debian packages run noninteractively" which is only one aspect of "how can i make system installation/upgrade work better". I'd like to integrate more of the bookkeeping tasks into the debian system, like being able to display a list of warnings/errors after installation is finished, and a list of packages that still have to be user-configured. E.g., the debian configure run of autofs makes the debian installer happy, but not the user -- the configuration is not usable for most users. I don't think this user-configuration is a task that should be handled in postinst, but it would be nice if the package system would remind the user after installation "be sure to look into /etc/auto.master", something like a todo-list. Btw., the 2. version of my summary article on this is still on my todo-list, I was swamped with work recently. [...] > Maybe you have the luxury of having a box be unconfigured and > non working when you go home. A lot of us are not so lucky. We > prefer answering the questions first, and then starting the upgrade. > barring bugs, the machine down time is minimized. how do you deal with existing versus new config files during an upgrade (or how would you like to deal with it)? > As I said, let us solve the real issues, not apply band aids. me too ;-) ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Consesus on Linuxconf?
Shaya Potter <[EMAIL PROTECTED]> writes: > I was wondering if we have reached some sort of consesus on Linuxconf. > > The points that I see are > > *Linuxconf can't lose any info. > --This might mean that Linuxconf will error out if it can't parse the file, > if you've made private changes to it. That's the tradeoff, you take a risk > that you won't be able to use linuxconf if you privately edit the file. We > will work to improve the parser though to minimize that risk. This will be the case with any interactive config-program build on top of existing configuration languages (even the samba configuration "language" is complex enough for this to be true). [...] > *Linuxconf isn't only way to configure system? (is this a point of > contention?) > --We should continue to provide similiar tools to what we have now to be > able to configure the system. > ---If we do the above, should it be interchangably b/w linuxconf > configuration system and old configuration system for the same package (i.e. > on one computer, I can switch easily b/w sendmailconfig and linuxconf > sendmail configuation). I think that might be too difficult to pull > off. > We should say that you can choose for each packages b/w the old method or > Linuxconf's, but shouldn't switch b/w the 2 methods for one package, at > least not expecting the data to be fully transalatable. It should be possible to disable the linuxconf module, and perhaps tell linuxconf to start sendmailconfig instead, or warn the user when switching configuration methods. > *Modules for all packages that have conf files > --Is this neccesary? Can someone do a study on what the majority of > conf IMHO not nessacary > files are, i.e. are they free flowing (i.e. don't have a set form and can be > on any length), or are they a simple form with plug in variables, or are > they a combination of the two. writing a module for the first case will be > more difficult, while writing a module for the second case should be very > easy, and we can provide an example module to show how it's done. The > thirds case will probably be slightly difficult as well, though I'm > not sure. most configuration files can be complex; take a look at the files in your /etc. How many simple and how many potentially complex files did you find? Additional points I would consider important: - how difficult is it to write a module for linuxconf for some package; can some scripting language be used? - how well does linuxconf scale (what if i have 50 configuration modules?) - how clean/flexible/modular are the concepts? Will the framework break down 3 year from now because there are so much new requirements that can't be integrated? - on which platforms could it run or made to work? (administrating a bunch of machines with the same tool would be a plus; i think it's one goal of coas) These are general questions relating to any such program. Perhaps it would be a good idea to discuss the interfaces to packages. If one could standardize that (how to put additional information into sysv-initscripts, and which information, or the module api, etc.), perhaps we could get less dependent on a specific program like linuxconf. I'd like someone to package linuxconf for debian (an experimental release), so it's easier for everyone to take a look at it. Last time I looked at it (I think it was november 1997), I wasn't very convinced of it's concepts. My impression was it's a monolith (though there is a clean interface for front ends), and I didn't like the module api very much (I experimented with a python interface module, which lets you load modules defined by python scripts, but the overall architecture wasn't very convincing). Is everything prodived by modules by now, e.g. adding users, and how much (e.g. path names) is still hardcoded and buried somewhere? I also looked at coas (and started to define a interface to front ends like in linuxconf, which is an area where coas is lacking), but it seemed like development was stalled for some time. Now v0.11 has come out, but i'm not sure if it's gaining speed (if it does i'll take up the work on it again). The concept of coas seems to be much cleaner, concentrating on infrastructure. Did anyone succeed in compiling it under debian or installing the rpm's under debian? The official compile uses libc5 and python 1.4, and the binaries in the rpm are looking for libncurses.so.4, a libc5-readline in /usr/lib, etc. Btw., is there any document about the outcome of the BOF on LSB at Linux-Expo? It would be nice if installing a rpm with alien under debian would be easier than recompiling the source. ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Manoj Srivastava <[EMAIL PROTECTED]> writes: [...] > Why can't you ask all the questions first? I am too thnking of > the kernel image package. I can easily design a framework that > gathers all the data a priori -- and yes, you have a point; > Andreas> because the questions depend on the state of the system which might > be > Andreas> different before installation than when the postinst is actually > Andreas> executed. > I may then need to ask extra questions in a what if > manner. All it takes is a little bit of thought while creating > the questions. And the databse so generated can be truly machine > independent, and be used to replicate machines in a compute farm. > > Two ver worthy birds with one stone. This might be the way to go, but as it puts additional burden on the package maintainers. Providing configuration data before starting the install has obviously the advantage of minimizing the time a package is non-functional (i.e. unconfigured, or not working in the intended way), compared to providing the data afterwards. If the user wants to change the decisions made before installation (i.e. after finishing package selection and before starting installation) after he has finished it, it would be nice if he could do it the same way. The query script should be run, answers stored in a database, and then postinst configure be run again. Even better if this would somehow integrate with using linuxconf/coas/whatever. [...] > Andreas> I'd like to integrate more of the bookkeeping tasks into the > Andreas> debian system, like being able to display a list of > Andreas> warnings/errors after installation is finished, and a list > Andreas> of packages that still have to be user-configured. > > I want to eliminate that list. I'm not sure how you want to do that. Some packages show notices of the form "look into file xyz after installation". With user-configured I didn't mean the configured state of dpkg. After installing a package like samba, debian provides a do-nothing configuration (or a configuration that does something, but often not what the user wants, which is the case with autofs). One could provide a smb.conf before starting the installation (which certainly could be an option for experts or when installing a compute farm), but - programs like linuxconf/coas don't work that way - sometimes the user wants to try out/correct/try again - sometimes it's better to have all the documentation at hand before going through the configuration of a package - sometimes a package includes helper programs that aid in configuration. Some network perl library package offers to verify host names when they are entered. My conclusion is that it's often desirable to first install the packages (including the debian-configuration, which should guaranty a sane state) and then user-configure them to make them really work the intended way (and perhaps climb a learning curve while doing that). The package installer could maintain a list of the packages to be user-configured, maybe associated with some configuration program. > I agree about important notices; however, that is fairly simple to > implement; and there is not much of an design issue there. Ok, some time ago I made a proposal to put a severity prefix in front of each output line (or maybe before a block of lines?), and to automatically tag unprefixed lines, depending on if they come through stdout or stderr (which means letting dpkg redirect the script output and installing a filter), and to automatically capture the output of the installation run somewhere. Anyone having a better proposal? (I'm not sure there are no design issues here) > Andreas> how do you deal with existing versus new config files during an > Andreas> upgrade (or how would you like to deal with it)? > > Hmm. Asking ahead of time may not be a satisfactory solution > unless one can compare the two sets of config files. Gack. Well, > rather than dpkg asking a bland question, we need the package > maintainer provide a text lsiting changes in the conf file, and use > that to prompt a user whether they want the new file? It's a better aproach than the current one, but sometimes it's neither the old (modified) one or the new one, but the old one with some or all of the modification the maintainer made to the provided conf file. > We can't probably default to the old file (the new version > of the code might not be backwards compatible); or the new version > (the package may not be useable without changes). that seems to be the core problem. > > Ifg we want to make non interactive installs a reality, we > have to put in work to support it -- and that means creating a change > text for each conffile. Lintian can check whether the developr has > provided the change text; it can even be in changelog format, so dpkg > can extract the changes since a particular version of the conffile. > > So, if
Re: Consesus on Linuxconf?
Shaya Potter <[EMAIL PROTECTED]> writes: > >> --This might mean that Linuxconf will error out if it can't parse the file, > >> if you've made private changes to it. That's the tradeoff, you take a risk > >> that you won't be able to use linuxconf if you privately edit the file. We > >> will work to improve the parser though to minimize that risk. > > > >This will be the case with any interactive config-program build on top > >of existing configuration languages (even the samba configuration > >"language" is complex enough for this to be true). > > I wouldn't say that, last year when I was playing with linuxconf, I took my > debian sendmail setup, and the first time I ran linuxconf, linuxconf parsed > it perfectly. I didn't have a complex setup, so it doesn't prove much, cept > that linuxconf can parse things that it hasn't created. No, i meant you can't prevent the parser to error out on some edited config files, not that it will happen with every edited config file. [...] > >most configuration files can be complex; take a look at the files in > >your /etc. How many simple and how many potentially complex files did > >you find? > > well, I don't have a debian system running right now here in .il, as > I only came for the year, though as I'm returning to the states in a week, > I'll have my debian box[s] up and running soon after, especially with those > nice multiple OC-3s at work. was a rhetoric question :-)), IMHO most of them are potentially complex. > >Additional points I would consider important: > > > >- how difficult is it to write a module for linuxconf for some > > package; can some scripting language be used? > > Writing simple modules shouldn't be too difficult right now, if you > know C++ better if writing simple modules was simple ;-) [...] > >- how well does linuxconf scale (what if i have 50 configuration > > modules?) > > hehe, I don't think their have been any tests, as there aren't that many > modules yet, so I can't answer, if we come to that point, it shouldn't be > too difficult to subdivide the modules, though even without it, you'd > probably just have to scroll threw a longer list to find what you want to > configure. maybe there are other issues too like load time, especially when started in batch mode. [...] > >- on which platforms could it run or made to work? (administrating a > > bunch of machines with the same tool would be a plus; i think it's > > one goal of coas) > > What do you mean? right now linuxconf includes some of the "modules" in the > linuxconf core code, and not as modules, the author is working on seperating > them all out, I hope to get just a linuxconf-base. with linuxconf-[modules]. > It seems to be pretty flexible, has remote managment, remote control from > one linuxconf "server" to multiple clients I meant if it can be easily ported to other os's. Maybe sometime in the future it becomes important. > > > > >These are general questions relating to any such program. Perhaps it > >would be a good idea to discuss the interfaces to packages. If one > >could standardize that (how to put additional information into > >sysv-initscripts, and which information, or the module api, etc.), > >perhaps we could get less dependent on a specific program like > >linuxconf. > > Well, for Linuxconf it's pretty standard right now, there's a document on > Linuxconf's web site, that was written up for Red Hat, though it confused me > a little as their were no examples. haven't looked there for some time. My point was, will we get really clean interfaces/api's? In the long run the api might be more important than the program implementing it. A related question is, will it integrate well with the debian way of doing things (whatever that is, but we are discussing some configuration issues in another thread, and some things seem to be related). [...] > I'll package linuxconf up soon after I get back to the states. great :-) ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Steve Dunham <[EMAIL PROTECTED]> writes: > Andreas Degert <[EMAIL PROTECTED]> writes: > > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > > Drake> On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: [...] > > > I prefer the approach to ask questions first, and configure as > > > it installs. If we are spending time to do this, we should do this > > > right. > > > In general, you can't ask all questions first; you can ask some > > questions, then unpack and debian-configure the packages, but then you > > still have to do a lot of configuration (using an editor or some > > configuration programs that "ask questions"). > > Why not? If we provide a way for a package to say: I need this > information to configure myself, a program could then take the list of > needed information from all the packages (what dictionary language do > you prefer, what is the timezone, what keymap, do you want a color > xfig, etc.), compare it to an optional database of the information, > and ask the user for the missing information before the install. if you take a static list of questions for a package, you have to answer _all_ questions, even if in the postinst many questions are conditionally asked depending on the answers to other questions or the state of the system (one can argue if this is a good or a bad thing, but for a simple installation on a i386 it's overkill to ask for the name of the alpha bootloader, and not very friendly to the simple-minded user). > More complicated packages that need very interactive configuration, > like X, sendmail, etc. should: > > * Allow the user to provide the configuration file (sendmail.cf, XF86Config) > ahead of time. > and > * If the file doesn't exist, schedule, via some yet to be determined > mechanism, for the interactive configuration program to be run > after the install. (So the "package" xbase would be "configured", > allowing dependent packages to be installed, but "config_xserver" > would be in the queue of pending interactive configuration > programs.) Agreed, the last part was my original proposal :-) (some time ago) ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Consesus on Linuxconf?
Raul Miller <[EMAIL PROTECTED]> writes: > Andreas Degert <[EMAIL PROTECTED]> wrote: > > No, i meant you can't prevent the parser to error out on some edited > > config files, not that it will happen with every edited config file. > > config files which are broken should be treated as error conditions. > > For example, if you put this email message into your /etc/hosts > that would be a broken config file. [Unless you fixed it by > turning all these new illegal lines into comments.] please don't answer too quickly; if you think about it a second (in the context of the thread) you will realize that I wrote about syntactically and semantically correct config files that are too complex for the parser. For, samba, a config file overwriting some global setting indirectly with the line include = /etc/smb.conf.%m occurring later in the config file (%m expands into the client machine name) is already tough for the parser (and the ui displaying the data). ciao Andreas PS: If you really succeed in writing such a parser correctly, it should be easy to additionally make it ask me in such a case if I want to start a new samba configuration from scratch and where I want it to save my misplaced email :-)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Consesus on Linuxconf?
Raul Miller <[EMAIL PROTECTED]> writes: > Andreas Degert <[EMAIL PROTECTED]> wrote: > > please don't answer too quickly; if you think about it a second > > (in the context of the thread) you will realize that I wrote about > > syntactically and semantically correct config files that are too > > complex for the parser. > > That shouldn't matter for context free grammars. If the grammar > isn't context free you're dealing with something like unrestricted > perl, not a config file. That is not the point; of course just the parsing, the syntactical portion, is rather easy. Else, how should a program like samba parse it's config files? Even if it's a complex embedded language, by definition its syntax can be parsed, and if it's for a program you even have the source for it. The problem lies in understanding the semantics from the users point of view, so that it can be presented to the user in a reasonable form. This is what the parser of a configuration program has to achieve. > > For, samba, a config file overwriting some global setting indirectly > > with the line > > > > include = /etc/smb.conf.%m > > > > occurring later in the config file (%m expands into the client machine > > name) is already tough for the parser (and the ui displaying the > > data). > > You mean a non-global override of a global default? It's both in the global section of the config file; you can use it to set a default log level for all clients, but a different log level for specific clients (just one example). It's "local" with respect to a single client; just can also use %a instead of %m, which will expand to the architecture of the client machine, or %R for the protocol level client and server have agreed upon. > > For a UI you need an area for defaults, and you need to be able to > enter specifics (specific file system areas, specific printers). Under > a specific file system entry you need to be able to represent the > defaults and you need to be able to represent overriding them. You can special-case it for my example, and I'll just make my example a bit different or more complex. For example, as the user gets fed up with different log level for his 1001 clients, he just puts a log level = 1 _after_ the line with the include statement. Perfectly valid. Samba will run with log level 1 for all clients, though other client-specific settings will be retained. And the nice thing, when the user comments out this additional line, he has the old client-specific log-levels again. How do you make a config program understand that and present it to the user? One goal was that no info shall be lost, so it would be illegal if the config program zapped the config lines that are globally overridden. If you modify a configuration that was read from a definition which is spread over several files, into which file do you put the new/changed configuration statement? IMHO, if you want to handle all these cases, the configuration program gets more and more complex, also for the user, and in the end it's worse than just giving the user an editor and a manpage. A configuration program should guide the user through the configuration, and prevent him from defining silly configurations, even if they are formally correct. You have to draw a line somewhere, and this means your configuration program will have to reject reading some config files that are perfectly valid and meaningful for the special case of some user. OTOH, you will prevent a lot of users from screwing up their configuration. I took the example of samba config files, because at the first look they seem to be very simple (it's the windows ini-file syntax, with sections and assignments to keywords). But the simple existence of these include statements makes it much more involved. I haven't found a configuration program which handles samba includes well. If you look at config files like .emacs or /etc/profile where it's apparent that they use a structured language, it's much more clear that a configuration program can't grok each possible config file the user can write with an editor. ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
