need help in identifying changed files in pacakges, + general pacakging questions
I'm trying to develop a system of identifying all the files belonging to packages that have changed on a system. This is very important if you want to save a current configuration. For example I go in and tweak various files here and there (init scripts) or change config files (sendmail, etc...). I'd like to identify all these and put them in some sort of archive, so that I can reproduce the state of the machine if I have to do a fresh reinstall, or transfer the config to another machine. At first I thought I could look at the creating time, mod time, but if a person edits a file, all times will be set to the same. By taking a quick look around the /var/lib/dpkg/info I noticed several types of files that look promising. First are the md5sum files but::: # /bin/ls -1 | cut -d"." -f1 | sort |uniq |wc 212 2121684 # /bin/ls -1| grep md5 | cut -d"." -f1 | sort |uniq |wc 72 72 548 not all packages have md5sums. Maybe md5sums should be generated during the package installation process if one is not available. There are also two files in the 131 dist "comerr2.checksumse2fsprogs.checksums". What is with the different file extension. Another type of file that looked interesting is the .conffiles but I realized that for X apps the app-default is usually not included in the conffiles, which I think they should be, but maybe I misunderstand the role of conffiles. That would be isolate the configuration related files from the applications related files. For example the XTerm xdefaults from the xterm executable, or the man page, which should not be changed. The files that are not suppose to be changed should be watched with tripwire, if it's not done already. Any comments? One possible way of keeping track of modified packages would be to touch all the files a package with the installation date, and keep track of the installation date, then you'd just have to look at the dates for the files to identify whether or not the file was modified since installation or not, if somebody didn't want the change to be noticed (intentionally) they could touch the file manually. Another option would be to set up something along the same line as tripwire to track changes, but md5sum on /usr would be quite CPU intensive, and would prevent the SA from circumventing the system easily, which is handy. Is there any type of audit trail in place for package addition, upgrade, deletion? This is a pretty broad topic, but might as well throw it in for good measure. BTW, I happen to feel pretty strongly about these issues, and having been an SA for some years, and having to deal with production type environments, I can say that these issues are also very important to a great many other people as well. Radu -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
how to handel version numbers for upstreap updates.
I've got a package version 1.5.0-1 that I've already packaged. There is a new upstream release 1.5.1. Should the new package be named 1.5.1-1 or 1.5.1-2 or is it up to my discretion. Since it's an entirely new source tree it would make sense to use 1.5.1-1. Are there any official policies on this? Radu -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect features request
On Fri, Dec 19, 1997 at 09:29:17AM -0800, [EMAIL PROTECTED] wrote: >1) Once all packages are selected, be able to dump the selections to >a file that could be later read in for subsequent identical >installations. There is a twist to this. Allong with all the installed packages will come all the configuration files that you may have modified. For example sendmail,X11,ntp,etc configurations, default editor, and others. That's a problem I'm going to try to solve, since I'm in the same predicament myself, having to save configurations for machines. The first step is getting the MD5 sums in the deb files though, and I'm still working on that one. There is a interesting thread on debian-policy regarding making MD5 sums mandatory in packages which will then let you identify which files you have modified. (hopefully just configuration files :) ) >2) Once all packages are selected, don't skip packages that are >deselected, just ignore them. Dselect for ftp install works this >way, why can't the disk based dselect as well? It looks like much >time is spent "skipping" packages that do not need to be >installed. I HATE that. I gave up on CD installs. I found a ftp server that was close to me and now I'm just using that instead since the "skippy" problem doesn't exist with the ftp option. I probably should have brought up the issue a while ago. Radu -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dselect features request
On Sat, Dec 20, 1997 at 12:15:29AM -0800, [EMAIL PROTECTED] wrote: >>> Radu Duta writes: > >RD> On Fri, Dec 19, 1997 at 09:29:17AM -0800, [EMAIL PROTECTED] wrote: >> dpkg --get-selections >> dpkg --set-selections I noticed; well it's a start, that's for sure. There is a lot of info missing from that. As Jeff Sheinberg pointed out it's a bit broken with some things. I noticed that version numbers are missing, and the all too elusive config files are not dealt with. (Jeff Sheinberg pointed out a problem with deleted standard packages like elm I won't include the message since it's kinda lengthy, it's on the list thought, and I can forward it if you want it) > >Does this have the predicament with config files? so I guess the answer is yes. >Also, the same respondent gave this clever way around that: > >> Unfortunatly, that is because of the way dselect runs dpkg (dpkg -iGROBE), >> which then goes through the directorys and checks every package. I've >> solved the problem by mounting my CD info ftpable space and using >> dpkg-ftp. The package dpkg-mountable will also provide a method that >> doesn't do this. Yea I noticed. I may have to give it a try. The ftp method works really well also, but you need to have a nice connection. Modem users for example would be advied to use something else. If you are on fast connection I think the ftp method is one of the easiest to use, especially wen you consider that the packages are updated more often then the CDs, so you'll have to use the ftp method regardless to get the most current pacakges (this applies for both hamm and bo). I guess you could configure dselect to look first on the CD and then if it's not there or there is a newer version on the ftp server then go there and get it. AFAIK that is not supported today. Radu -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
