Raul Miller <[EMAIL PROTECTED]> writes: > Andreas Degert <[EMAIL PROTECTED]> wrote: > > There are a lot of packages with config files that can't be generated > > using some simple questions (on my systems packages like autofs, > > samba, lprng, X11, apt, dosemu, svgatextmode, netstd, pcmcia-cs, sane, > > samba, sudo, tetex, wine). This would have to be solved too if you > > want it to scale. > > samba: I don't see why
Configuration of samba is too complex; on my server there is a smb.conf with 350 lines, and some additional files that are included when connections to special machines are made. You can define such a configuration with a text editor or with a complex configuration program (like the one in linuxconf, or in webmin, but even those can't handle all situations). The list was meant as a list of packages with (potentially) complex config files. [...] > Other than that, we'd also need to solve the problem of batch > administration (reflecting config changes on many machines), though > I recall that we have at least one package which already does that. which package(s) are you talking about? > Finally, install time isn't the only logical time where we'd want > to tackle config issues: run time is another time that makes Right, but after install (or upgrade) we want the system to be in a sane state. This is the reason I'd like to have a list of all packages that might need further configuration after install or upgrade (these are the packages with complex configuration files). Then one can traverse the list, and directly start configuration programs, or a text editor on the config file(s). > sense (though some changes can be made permanent only by root, and > some configuration is security related so not available to the > random user). A lot of this is just generating good error messages, > where people can see them. Currently we get a lot of output, sometimes intermixed with error messages, and it's not captured anywhere. I tried to address this in my original proposal (prefixes for messages and some way to make dpkg redirect the output). [...] > > And you have to have a way of addressing the case where you got something > wrong. hmm, how do you mean that? For a single machine I'd telnet into it and correct it by hand. If it's multiple machines, could it be solved by a mechanism to "reflect config changes on many machines" (quote from above) ? ciao Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
