From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1F8Hjo-0002f5-2v for garchives@archives.gentoo.org; Sun, 12 Feb 2006 13:58:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1CDv5IH004835; Sun, 12 Feb 2006 13:57:05 GMT Received: from mach.qrypto.org (connectioncable-084.headoff.net [217.30.222.84] (may be forged)) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1CDqxgA029071 for ; Sun, 12 Feb 2006 13:53:02 GMT Received: (qmail 29617 invoked from network); 12 Feb 2006 13:52:56 -0000 Received: from unknown (HELO ?192.168.0.2?) (gentoo@192.168.0.2) by 192.168.0.1 with ESMTPA; 12 Feb 2006 13:52:56 -0000 Subject: Re: [gentoo-user] Handling of config updates, RFC From: Rumen Yotov To: gentoo-user@lists.gentoo.org In-Reply-To: <43EF3A25.9050301@ultratux.org> References: <43EF3A25.9050301@ultratux.org> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-/4/hklg+EjNsk0bdOD7k" Organization: personal Date: Sun, 12 Feb 2006 15:52:48 +0200 Message-Id: <1139752368.12514.4.camel@mach.qrypto.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 X-Archives-Salt: 30d2370b-aec4-4ab4-8366-2a7168e1850d X-Archives-Hash: 42ed47ee7077f2deaf57928efd53a6ef --=-/4/hklg+EjNsk0bdOD7k Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2006-02-12 at 14:37 +0100, Maarten wrote: > Hi >=20 > I have not been impressed by the handling of configfiles (updating them) > by neither etc-update nor dispatch-conf, so I pondered on an > alternative. Not an alternative to those packages, but some extra help, > possibly integrated into one of those tools. Please bear with me... >=20 > What tickles me the most about the current process is that one sometimes > gets huge lists of updated files by updating a single package. A package > which may have never been used, or at least configured, by the user. > For instance, updating webmin, or snort, yields many many ._cfg files an > average user knows little about, and does not care about since he never > tweaked them. In other words, they are in their distibution-default > state, never edited. It stands to reason everyone would want all those > files overwritten by the new ones, is it not ? Well, neither tool does > that now. The user is left with two options to handle the task: > 1) Pick out all non-trivial files in a massive list of over 150 files, > merge those, and after due consideration have dispatch-conf do all the > remaining files automatically. (I suspect this is what most people do) > 2) Go through all the files step by step and choose either overwrite or > skip as fast as possible, and re-run the tool on the remaining files, > and this time carefully decide what to do with it, overwrite, shred, or > merge. > Well, neither is comfortable. Especially since 'trivial merges' like > CVS- or revision info are advertized as being dealt with, but in reality > are often not. I cannot tell you how many 'changes' I get confronted > with are just trivial changes (like added commentary, and so on) >=20 >=20 > I propose to add an additional mechanism to 'see' whether a file was > actively changed during the lifetime of the machine, by a very simple > and dumb means, but nevertheless a very effective one. > This would work like this: upon extraction of the stage tarball (or at > least very very early in the install process) one should set all the > dates of all the potential configfiles to a set date in the (distant) > past. Let's say, feb 29 1988. Only thereafter, we start configuring the > system, editing fstab, hostname, etc. >=20 > Now when we run dispatch-conf, it will first check the date of the file > that corresponds with a ._cfg file. If that file has that magic date, > overwrite it by the new file, and (this is important) re-set the date of > that new file to that old magic date. The user thus needn't be bothered > by numerous files he didn't touch, and a very significant time-saving is > realized for everyone. >=20 > If I'm not mistaken, other distributions have had solutions like this > for ages. For instance, SuSE's YaST had/has a way to see if a user > touched the configfile, and refuses to touch it if it found out the user > had changed it manually. (Not a very succesful strategy for people who > routinely did edit the files, but considering all that, it was still not > bad. >=20 > ...What do you think ? Has this idea been suggested before ? > Wouldn't this make the updating a much less painful process ? > What, if any, would be possible pitfalls using this approach ? >=20 > Thank you for your time reading this, >=20 > Maarten v d Berg >=20 Hi, Check "cfg-update" it's in portage, and i think it the better. i'm using it together with "dispatch-conf" but think if switching completely to 'cfg-update' (or mostly at least). Check the forums for additional info (features, history etc.) HTH.Rumen --=-/4/hklg+EjNsk0bdOD7k Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4DCCBOww ggLUoAMCAQICAwHjjDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNjAyMDUxMTAwNDlaFw0w NzAyMDUxMTAwNDlaMDsxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEfMB0GCSqGSIb3DQEJARYQ cnVtZW5AcXJ5cHRvLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM12ApV52RJl w6+Fpr5iE3/SeTNOJWuzHySWlu8UPxbyEDMQN3PiiSgxyucG7roLjtR4KYLMl4trrbWLHY75l3Ux oeFrOjEERQ6VX179fN4wrW09mj8rr7wQPcaCwfQUzeU94WdXdVFUwcZBSAEcLBoN1lNLS80rd19F wMkfxEximDRWZ2E+ts8wM9p2TFZQNjOJZ1cHY563Zu5zSG0Fr/P6PYgGmMAytqJbt8mn0ASpmGAp N7c9HMouXOoA5CIgZaQy+l9/ibPWl4399h6+nbiWZvGSmo4Mt4sepjysYcFNBev2EcjzRZvhXkIP TDk0nojCkRjXFoZPeUP4tCmCmw0CAwEAAaOBujCBtzAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIB DQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0 dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9v Y3NwLmNhY2VydC5vcmcwGwYDVR0RBBQwEoEQcnVtZW5AcXJ5cHRvLm9yZzANBgkqhkiG9w0BAQUF AAOCAgEAINAgGWjujvzp5B5z//iJxYgmU0JDKQEb36H5osJf7DWCrvDp/F8kmhrNWZHxbNXvWcBP Hcz0R5TWjRPGlVMrZw5oSzmERe0MsHItso1EYu7bxkl57cXTIclw5SQxvuF5VtMrqgFR/gWRAik5 U6QL99lJBX8F6i6G8visXvoW2mHcY7x9Zx2pZL5/CVywLI38bJV6he3NKJUtcyuH++kB+iicyUZg TYSeKXXOKFDOzPBffMjQ4s8L4bdD7jMhyULhTIldkXDe8Gnw5AQWbdVdG1Jf9Sh5/a/NmQWce+i3 QOaFATewgS5J8jfQSMYzZP820RGxA6W6txVxcCcMWaU8UiZON+frf5Mlr2XxTcJbqwNMZwNPTMmH MKTwC6l1BqlOjbQlOYcWdOH8Oa+CCcsStPo74JYZBho79al1/y1JCK/Te1spgMt3NjEKGTk/ggfZ wlxfNK7hQeFBKBzyybLmSSeicYezBlYLlUhqvASxletn/IC5idV+ojJGfcKR4iniHNXId0TOs5kJ qvoiQCmN6/NqpTwOYn4YIOTjbffDSJ7BGB05Q7H5pAnzUI2Yovd+5zDxFEznKreY7mx4xgzhWa0b Bk28M18pVnCIJijkpkX/svBCRu69faA9e4JTMLKGJ8CUPTx33VeLG8rYh05nS//HQ2m2CMlBVcZq cnUq6oswggTsMIIC1KADAgECAgMB44wwDQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDYwMjA1 MTEwMDQ5WhcNMDcwMjA1MTEwMDQ5WjA7MRgwFgYDVQQDEw9DQWNlcnQgV29UIFVzZXIxHzAdBgkq hkiG9w0BCQEWEHJ1bWVuQHFyeXB0by5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDNdgKVedkSZcOvhaa+YhN/0nkzTiVrsx8klpbvFD8W8hAzEDdz4okoMcrnBu66C47UeCmCzJeL a621ix2O+Zd1MaHhazoxBEUOlV9e/XzeMK1tPZo/K6+8ED3GgsH0FM3lPeFnV3VRVMHGQUgBHCwa DdZTS0vNK3dfRcDJH8RMYpg0VmdhPrbPMDPadkxWUDYziWdXB2Oet2buc0htBa/z+j2IBpjAMrai W7fJp9AEqZhgKTe3PRzKLlzqAOQiIGWkMvpff4mz1peN/fYevp24lmbxkpqODLeLHqY8rGHBTQXr 9hHI80Wb4V5CD0w5NJ6IwpEY1xaGT3lD+LQpgpsNAgMBAAGjgbowgbcwDAYDVR0TAQH/BAIwADBW BglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg b3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBsGA1UdEQQUMBKBEHJ1bWVuQHFyeXB0by5vcmcwDQYJ KoZIhvcNAQEFBQADggIBACDQIBlo7o786eQec//4icWIJlNCQykBG9+h+aLCX+w1gq7w6fxfJJoa zVmR8WzV71nATx3M9EeU1o0TxpVTK2cOaEs5hEXtDLByLbKNRGLu28ZJee3F0yHJcOUkMb7heVbT K6oBUf4FkQIpOVOkC/fZSQV/BeouhvL4rF76Ftph3GO8fWcdqWS+fwlcsCyN/GyVeoXtzSiVLXMr h/vpAfoonMlGYE2Enil1zihQzszwX3zI0OLPC+G3Q+4zIclC4UyJXZFw3vBp8OQEFm3VXRtSX/Uo ef2vzZkFnHvot0DmhQE3sIEuSfI30EjGM2T/NtERsQOlurcVcXAnDFmlPFImTjfn63+TJa9l8U3C W6sDTGcDT0zJhzCk8AupdQapTo20JTmHFnTh/DmvggnLErT6O+CWGQYaO/Wpdf8tSQiv03tbKYDL dzYxChk5P4IH2cJcXzSu4UHhQSgc8smy5kknonGHswZWC5VIarwEsZXrZ/yAuYnVfqIyRn3CkeIp 4hzVyHdEzrOZCar6IkApjevzaqU8DmJ+GCDk4233w0iewRgdOUOx+aQJ81CNmKL3fucw8RRM5yq3 mO5seMYM4VmtGwZNvDNfKVZwiCYo5KZF/7LwQkbuvX2gPXuCUzCyhifAlD08d91XixvK2IdOZ0v/ x0NptgjJQVXGanJ1KuqLMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UE CxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwHjjDAJBgUrDgMCGgUAoIIB hzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMTIxMzUyNDJa MCMGCSqGSIb3DQEJBDEWBBSL/HnkY3fOII0lQmj8ZEW2An/RajCBkQYJKwYBBAGCNxAEMYGDMIGA MHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAG A1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBj YWNlcnQub3JnAgMB44wwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMB44wwDQYJKoZI hvcNAQEBBQAEggEAGsL8q+IVklbLCab+jNvfcHgGRNbHOZgo2a1pngo1bJxMxK796Psz7I5nTGZy iuvctGYGArBLtcMzFFnPaqbuo/abMJuQwONjbcxhb4yZdosGaud6s7iAm4bNUF/lL+VEUQZlwpva r9hCSo/V85mdS+LdHy/RqhB5mmbtSrYUhTny38ZMGThSMJ8gvTD+8T+8oFgRHAI68tvdnUl6pm2c i7qctzkimpi65/OxSoBsnZpHseLMpsJnz4+1Hj9pcyPJxseQMo8rMkCsidN3zWBvh1vT7LgbLYiF n/HzAAZYTooRydemn+gRu/ld/aC2NlXZORYXVEXb53FrrZRoE1g2fQAAAAAAAA== --=-/4/hklg+EjNsk0bdOD7k-- -- gentoo-user@gentoo.org mailing list