Config file management utility
Has much discussion been had about a possible configuration file management script for the package config scripts to use? For example, I installed cron on a Debian box, and then installed mgetty. Mgetty placed the following at the end of my /etc/crontab: #-- mgetty begin 20,40 * * * * root faxrunq #-- mgetty end Then, when I updated cron, it asked if I wanted to replace my /etc/crontab. I'm assuming that this would have hosed my mgetty settings, so I was forced to make the changes to /etc/crontab by hand. So, I was thinking... why not have a utility that the scripts would use to make all modifications to config files kinda like what mgetty did with the "#-- mgetty begin" and "#-- mgetty end"? The only difference is that *all* packages (even the package that "owns" a particular config file) would be encouraged to use the utility. In the example, cron would use the utility to make updates to /etc/crontab, as /etc/crontab would ostensibly have "#-- cron begin" and "#-- cron end" statements as well. Of course, the utility would have to have command switches to alter what comment character to use... whether the file could be deleted if it was empty (after removing a section, say) Has this already been discussed and thrown out? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Easier configuration idea....
One of the faculty I have to support here is using Caldera's OpenLinux. Although Debian is still my favorite, I am pleased with some of the easy configuration features of OpenLinux. For those of you who are unaware, OpenLinux has a directory under /etc called, I believe, sysconfig. In there are bunches of scripts that are employed by the rc scripts in rc?.d and init.d. For example, I believe the NFS one is located at /etc/sysconfig/network/nfs and its contents might look something like: run_on_boot=y run_as=root Probably a few others. I forget. The nice thing here is how easy it is to turn something on or off. With Debian, to turn something off I usually go into /etc/init.d and rename netstd_nfs to netstd_nfs.off. Kinda ugly. What I find exciting is the potential to have a dselect-like utility to manage the system configuration. If those little configration files contained some verbage about what the package does, like: descrip=Network File System. Allows you to share directories, etc. then you have the makings of a quick little utility that would let you turn options on and off in a menued utility. Again... has this already been discussed and thrown out? I'd be willing to write the config utility if I could get some sort of buy-in that it would actually be embraced by the package maintainers if the utility didn't suck. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Security audit tool?
I was just poking around on the Debian web site and noticed that there's a list of some known vulnerabilities in some packages. Has anyone discussed making a tool that could ftp a current copy of this list (in a properly formatted form, of course) and using it along with dpkg to determine if a system had any of the packages/versions that are vulnerable? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
On Wed, 3 Dec 1997, Adam Heath wrote: > How about this. Some one creates a script, that is run from /etc/crontab. > Whenever this script is run, it checks to see if another program is supposed > to be run. If so, it does it, then checks to see when the next script is > supposed to run. It then remodifies /etc/crontab, updating it's entry, so > that it can run the next item. Does anyone understand this? It sounds like something I was going to suggest as a joke. I was going to propose that, in cron.daily, they put in a script that sets up 288 "at" jobs... all 5 minutes apart. However, that's about at the top of the scale of tackiness and inelegance, IMHO. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
On 3 Dec 1997, Rob Browning wrote: > Joey Hess <[EMAIL PROTECTED]> writes: > > > Another way, that sould comply with policy, were if cron came with a > > update-crontab script, that was responsible for modifying /etc/crontab, > > in a similar fasion to update-inetd. > > I think that this, or something similar, is in the end, the right > solution. > > Ideally, I think this should be handled like the menu package. > /etc/crontab would be augmented to have something like: > > # BEGIN AUTOMATICALLY GENERATED SECTION -- DO NOT EDIT # > > > # END AUTOMATICALLY GENERATED SECTION -- DO NOT EDIT # > > Then each package would just have a file in /usr/lib/cron/auto (or > whatever) which would be used to (re)build the contents of this > section whenever a relevant package was installed. Well, that's pretty much what I was suggesting in the beginning. The only difference is that you wouldn't have one, monolithic section. Rather, you'd have sections placed there by the individual packages. For example: echo "42 6 * * * root run-parts /etc/cron.daily" | \ alter-file /etc/crontab --package=cron causes /etc/crontab to read: # cron BEGIN 42 6 * * * root run-parts /etc/cron.daily # cron END And then you could append to sections, like so: echo "47 6 * * 7 root run-parts /etc/cron.weekly" | \ alter-file /etc/crontab --package=cron --append to give: # cron BEGIN 42 6 * * * root run-parts /etc/cron.daily 47 6 * * 7 root run-parts /etc/cron.weekly # cron END You get the idea. Of course, in real life, you wouldn't do a section a line at a time. You'd pipe the whole snippet in like so: alter-file /etc/crontab --package=cron < /tmp/mysnippet You could remove a section: alter-file /etc/crontab --package=cron --remove You could also specify that, if removal of a section leaves the file empty, then remove the file: alter-file /etc/crontab --package=mgetty --remove --rm-on-empty Also, since not all config files use "#" as the comment, you'd be able to specify alternate comment chars (that the program uses for the BEGIN and END markers): alter-file /etc/someconfig --package=foobar --comment=";" < /etc/snippet Well, you guys get the idea.. I already have something like this written. One of my company's clients uses us as an e-mail forwarding service. So we maintain the forwarding e-mail addresses in an Access database and, periodically, we export it to a text file and feed it into this script I've got which replaces everything between "# BEGIN someclient" and "# END someclient" with the new section. So... it wouldn't be all that difficult to add the other features I've mentioned. The only problem is that it uses Perl. I haven't read the Debian policies so I don't know if Perl (or a stripped down version of it) is one of the things I can assume is on even the most minimal system. If not, I can do the same thing with bash/sed, I s'pose. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Config file management utility
On Thu, 4 Dec 1997, Joey Hess wrote: > Some things to look out for, though: > > - if the file alter-file is a conffile, there will be problems later when > you upgrade the package containg the conffile. I'm not sure I follow what you're getting at. The way I'm thinking, if a package (say, cron) was going to use this hypothetical tool to manage /etc/crontab, say... then it wouldn't have a crontab in the /etc directory of the .deb file. It would, instead, have a copy of the _snippet_it_wants_to_contribute_to_the_config_file somewhere like /usr/lib/cron/crontab.snippet or something. Then, the actual creation/ateration of /etc/crontab would be done with the tool... invoked from, say, postinst. So, instead of having an /etc/crontab in the .deb archive, postinst would have something like: alter-file /etc/crontab --package=cron < /usr/lib/cron/crontab.snippet The pitfall I'm forseeing (which doesn't seem to me to be the same one you're thinking of), is what happens the first time we upgrade a package that has now switched over to using this new tool? The new tool will be looking for its BEGIN and END markers for that package when there won't be any. I guess there's no crime in having the tool just stomp on the previous version of the file since that's what dpkg would do (but giving the user the 'ol Y,N,I,O,Z choices). > - you have to consider what happens if alter-file is asked to modify a file > that does not yet exist, becuase the package it is in has not been installed > yet. I had assumed that the default behavior would be that the file would be created right then and there. In fact, I'm having enough trouble forseeing a case where you would NOT want this to happen, I'm debating whether to even bother putting in a command-line switch to turn that behavior off. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15859: libc6 in stable is horribly broken
On 12 Dec 1997, Rob Browning wrote: > Scott Ellis <[EMAIL PROTECTED]> writes: > > > I HAVEN'T HEARD ANY REASONS WHY UTMP CORRUPTION IS SO EVIL THAT WE > > NEED TO MAKE ANYONE WHO WANTS TO RUN A FEW LIBC6 PROGRAMS ON BO GO > > THROUGH HELL. > > Say you're an ISP running Debian (bo) on a bunch of machines (and > these people do exist). And I'm one of them. :) Here's a thought. Correct me if I'm wrong, but this utmp/libc6/libc5 fiasco is something that applies to all (or almost all) Linux distributions, no? (Or is libc6 a Debianism?) If everybody in the Linux game is migrating to libc6, then what are the other piecewise-upgradable distributions (like RedHat) doing to avoid ugliness like what we're facing? - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Administration tool
On Mon, 15 Dec 1997, Brian Bassett wrote: > I recently switched to Debian from RedHat 4.2 and the one thing that I > think that Debian could really use is an administration tool. I suggested something similar a couple weeks ago and was informed that this discussion had taken place already. I guess the general consensus was that we (the Debian folks) should wait for the COAS project (http://www.caldera.com/coas/) to come to fruition. COAS looks to be promising. Caldera's outlines for it call for it to have curses (text), X, and web interfaces. Supposely, the front-ends will interact with "configurators" for the various installed packages. The configurators would, ostensibly, be provided with their respective packages. Caldera even went so far as to stipulate that configurators have to display some sort of intelligence (for example, not letting people enter octets higher than 255 in IP addresses). Caldera says that it's all going to e GPL'd. The only question now is, how long it is going to take. - Joe -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
