用热转印纸制作电路板
http://www.newsunmcu.com/cpsm/rzyz.html
Bug#256713: Apache security update made my website disappear
Package: apache Version: 1.3.26-0woody5 The security update to apache changed my httpd.conf and srm.conf in a way that meant my system's website disappeared. I did get offered `Save these changes to the configuration files? [Y/n]' and said yes, but: * Security updates should be safe. In particular, security updates should be doable with less care, checking, presence of mind, etc. etc. than an elective upgrade. * The default should not be to override a user-changed configuration. * The default should not be to disable an existing website by changing the DocumentRoot to the Debian default. * The question was preceded by a large amount of largely irrelevant messages. Transcript below. Ian. Do you want to install the files fetched [y]: Installing files... (Reading database ... 71673 files and directories currently installed.) Preparing to replace apache-doc 1.3.26-0woody3 (using .../apache-doc_1.3.26-0woo dy5_all.deb) ... Unpacking replacement apache-doc ... Preparing to replace apache-common 1.3.26-0woody3 (using .../apache-common_1.3.2 6-0woody5_i386.deb) ... Unpacking replacement apache-common ... Preparing to replace apache 1.3.26-0woody3 (using .../apache_1.3.26-0woody5_i386 .deb) ... Unpacking replacement apache ... Setting up apache-doc (1.3.26-0woody5) ... Setting up apache-common (1.3.26-0woody5) ... Setting up apache (1.3.26-0woody5) ... update-rc.d: warning: /etc/rc2.d/S75apache is not a link to ../init.d/apache update-rc.d: warning: /etc/rc3.d/S75apache is not a link to ../init.d/apache - update-rc.d: warning: /etc/rc4.d/S75apache is not a link to ../init.d/apache Apache has switched to using logrotate. However, some of your logs are stored outside the /var/log/apache directory, so you should edit /etc/logrotate.d/apache to have them automatically rotated. Adding alias /doc/ - /usr/share/doc/ to srm.conf (for Debian docs). Your config files will not be modified until you select Y at save changes. The DocumentRoot is set to /var/www. Leaving existing site /var/www/index.html untouched. Finding DSO mods...found. # LoadModule vhost_alias_module /usr/lib/apache/1.3/mod_vhost_alias.so # LoadModule env_module /usr/lib/apache/1.3/mod_env.so | LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so # LoadModule mime_magic_module /usr/lib/apache/1.3/mod_mime_magic.so LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so LoadModule status_module /usr/lib/apache/1.3/mod_status.so # LoadModule info_module /usr/lib/apache/1.3/mod_info.so LoadModule includes_module /usr/lib/apache/1.3/mod_include.so LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so LoadModule asis_module /usr/lib/apache/1.3/mod_asis.so LoadModule imap_module /usr/lib/apache/1.3/mod_imap.so # LoadModule action_module /usr/lib/apache/1.3/mod_actions.so # LoadModule speling_module /usr/lib/apache/1.3/mod_speling.so LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so LoadModule access_module /usr/lib/apache/1.3/mod_access.so LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so # LoadModule anon_auth_module /usr/lib/apache/1.3/mod_auth_anon.so # LoadModule dbm_auth_module /usr/lib/apache/1.3/mod_auth_dbm.so # LoadModule db_auth_module /usr/lib/apache/1.3/mod_auth_db.so LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so # LoadModule digest_module /usr/lib/apache/1.3/mod_digest.so # LoadModule cern_meta_module /usr/lib/apache/1.3/mod_cern_meta.so LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so # LoadModule headers_module /usr/lib/apache/1.3/mod_headers.so # LoadModule usertrack_module /usr/lib/apache/1.3/mod_usertrack.so LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so # LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so # LoadModule sys_auth_module /usr/lib/apache/1.3/mod_auth_sys.so # LoadModule put_module /usr/lib/apache/1.3/mod_put.so / # LoadModule throttle_module /usr/lib/apache/1.3/mod_throttle.so # LoadModule allowdev_module /usr/lib/apache/1.3/mod_allowdev.so # LoadModule eaccess_module /usr/lib/apache/1.3/mod_eaccess.so # LoadModule roaming_module /usr/lib/apache/1.3/mod_roaming.so Pondering... done. Save these changes to the configuration files? [Y/n] Rotated `/etc/apache/httpd.conf' at Mon Jun 28 15:20:27 BST 2004. Rotated `/etc/apache/srm.conf' at Mon Jun 28 15:20:27 BST 2004. Restart Apache now? [Y/n] Stopping apache with apachectl ... done. Waiting for apache to terminate ... done. /usr/sbin/apachectl start: httpd started Reloading apache modulesstart-stop-daemon: warning: failed to kill 1518: No such process
Re: Bug#256713: Apache security update made my website disappear
On Mon, 28 Jun 2004, Ian Jackson wrote: Package: apache Version: 1.3.26-0woody5 The security update to apache changed my httpd.conf and srm.conf in a way that meant my system's website disappeared. I did get offered `Save these changes to the configuration files? [Y/n]' and said yes, but: You accepted a new configuration without checking it. It is exactly the same as many other tools to handle configurations. * Security updates should be safe. In particular, security updates should be doable with less care, checking, presence of mind, etc. etc. than an elective upgrade. Negative. Security updated fix a bit of the code. The rest of the package stays the same. Please check: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security for more information. * The default should not be to override a user-changed configuration. You asked for it once you told the script Yes. You have been prompeted and warned. * The default should not be to disable an existing website by changing the DocumentRoot to the Debian default. Same as above. * The question was preceded by a large amount of largely irrelevant messages. This is not true in sarge/sid anymore. In any case there is nothing left as a bug in here. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
* Tyler 'Crackerjack' MacDonald [EMAIL PROTECTED] | | If I set up an apr_shmem segment on my Debian GNU/Linux system, and the | master process that set up the segment crashes without closing it, the | segment sticks around until I reboot. That's expected. Since shared memory doesn't belong to a specific process, the kernel will not know when to clean up the memory. | I'm using a file named libbtt.shm to back the segment on the filesystem, | but even if i delete that file, and no other processes are running that | access the segment, when I re-start the server I get the following error: The information about the shared memory still resides in the kernel, so deleting the file won't do much. For cleaning up you want to look at ipcs(8) and ipcrm(8). | apr_shm_create(rv, 880, .../libbtt.shm, pool) failed: File exists My guess is that shm_open thinks the file already exists because the shared memory was not cleaned up properly (although .../libtt.shm is a bit odd relative path). -- Øyvind Grønnesby
Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
Oyvind, That's expected. Since shared memory doesn't belong to a specific process, the kernel will not know when to clean up the memory. When I was using libmm, I never had this problem. I could crash my software a dozen times in an hour and still be able to get a fresh segment. I guess that's why I didn't expect it in APR; my understanding was that APR's shared memory system was grown out of libmm. I can understand the kernel not knowing that the memory is no longer used if there was still a straggler process hanging onto it. But when there are no processes left to access it, why does this continue to happen? If memory doesnt belong to any process at all, shouldn't it be, well, free? Regular memory works this way, files and filehandles work this way, why doesn't shared memory? Is it really that hard to keep a count of running processes that have opened a shared memory segment? And if this is a deficiency of the linux kernel, shouldn't APR, as a Portability library, be ready to handle this quirk and clean up for you, either automatically, or via a portable equivalent to ipcrm, etc? Also, there's a second symptom that I've started to notice. Because of this bug, I have to change my starting path each time. After 4 or 5 crashes, I don't only have to change directories, but _partitions_ as well, to get a new good segment. This really concerns me, because it seems to indicate that it's possible for two processes backing their shared memory off of different files in different directories on the same filesystem to conflict. What's the point in specifying a path if that path doesn't contribute to the uniqueness of the shared memory segment? | apr_shm_create(rv, 880, .../libbtt.shm, pool) failed: File exists My guess is that shm_open thinks the file already exists because the shared memory was not cleaned up properly (although .../libtt.shm is a bit odd relative path). It was actually /sanity/tr4/libbtt.shm, I just stripped the rest off because my path naming convention is silly. :) - Tyler
Bug#256109: libapr0: apr shared memory segments stick around forever if there's a crash
On Mon, Jun 28, 2004 at 05:24:37PM -0700, Tyler 'Crackerjack' MacDonald wrote: I can understand the kernel not knowing that the memory is no longer used if there was still a straggler process hanging onto it. But when there are no processes left to access it, why does this continue to happen? If memory doesnt belong to any process at all, shouldn't it be, well, free? Regular memory works this way, files and filehandles work this way, why doesn't shared memory? Is it really that hard to keep a count of running processes that have opened a shared memory segment? It wouldn't be hard for the kernel to do at all. But unfortunately, the crack-smokers who wrote POSIX.4 decided that IPC was different. The kernel is *required* to keep them around after all processes exit. And if this is a deficiency of the linux kernel, shouldn't APR, as a Portability library, be ready to handle this quirk and clean up for you, either automatically, or via a portable equivalent to ipcrm, etc? Yes, I would agree with that. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain
特价出售SONY摄像机!
SONYEVID315300/ SONYEVID100P 5400/ SONY390P990p 13798354543 TEL0755-27594040fax) email:[EMAIL PROTECTED] MSN:[EMAIL PROTECTED] QQ:26688551
Помосковье
! , , . : 1-, 2- 3- , . . : - ; - ; - ; - ; - ; - . - 85 , . (095) 507-5678
