The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

[Linux] Squid не работает с некоторыми хостами. linux ядро 2.4.x (linux squid proxy trouble proc)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: linux, squid, proxy, trouble, proc,  (найти похожие документы)
- CARBONE (2:5077/15.22) --------------------------------- CARBONE (RU.LINUX) - From : Mike Kudritsky 2:5020/400 29 Mar 01 08:48:38 Subj : [Linux] Squid не работает с некоторыми хостами. linux ядро 2.4.x ------------------------------------------------------------------------------- * Forwarded from area 'RU.LINUX' MK> Все работает отлично, за исключением того, что Squid не берет ряд MK> адресов. Их очень мало, но они есть. Примеры: MK> www.zyxel.ru MK> www.aport.ru MK> www.mts.ru MK> Думаю, что есть еще такие же сайты. Только поискать надо. echo 0 > /proc/sys/net/ipv4/tcp_ecn TCP Explicit Congestion Notification support CONFIG_INET_ECN Explicit Congestion Notification (ECN) allows routers to notify clients about network congestion, resulting in fewer dropped packets and increased network performance. This option adds ECN support to the Linux kernel, as well as a sysctl (/proc/sys/net/ipv4/tcp_ecn) which allows ECN support to be disabled at runtime. Note that, on the Internet, there are many broken firewalls which refuse connections from ECN-enabled machines, and it may be a while before these firewalls are fixed. Until then, to access a site behind such a firewall (some of which are major sites, at the time of this writing) you will have to disable this option, either by saying N now or by using the sysctl. If in doubt, say N. Kernel development The current kernel release is 2.4.1; it was [14]released on January 29. It contains a fair number of fixes for problems that came up with 2.4.0 and, of course, ReiserFS. Alan Cox's latest, meanwhile, is [15]2.4.0-ac12. It has almost everything that's in 2.4.1 along with a vast number of other fixes, many of which have been sent in by a squad of kernel "janitors" who are going through looking for things to clean up. More fun with ECN. ECN (Explicit Congestion Notification) is [16]an experimental IETF standard for TCP traffic. By making use of a couple of "reserved" bits in the TCP header, ECN allows routers to signal the presence of congestion on a network path; the systems sending data can then throttle back their output somewhat and avoid dropped packets. It can be a significant improvement for wide-area network communications. The Linux networking stack in 2.4 supports ECN (thanks to the efforts of Jamal Hadi Salim), and will use it if told to do so. Unfortunately, not all systems on the net react well to ECN; in particular, a set of Cisco firewall products will refuse connections with the ECN bits set (Cisco has a patch available, but many sites have not applied it). The end result is that, if you use ECN, a significant part of the network will be unreachable. Thus, most people using 2.4 have to disable ECN, either by configuring it out of the kernel completly or by disabling it at run time: echo 0 > /proc/sys/net/ipv4/tcp_ecn All the above has been known for some time, but the discussion got a fresh start this week when it was pointed out that [17]Hotmail is one of the sites that is unreachable when ECN is used. Some interesting questions came up as part of that discussion. The first was, simply, "why bother with ECN, since it breaks so much of the net?" The answer, of course, is that ECN will, eventually, make the net work better. In the mean time, people have to start implementing and deploying it. As the net becomes more ECN-compliant, the networks that still do not work with ECN will feel an increasing pressure to fix the problem. Next question: wouldn't it be possible to automatically retry failed connections without ECN? There are two issues with that approach. The first is that the systems in question reject the connection with a TCP reset (RST) packet. To ignore that RST and retry the connection would violate the TCP protocol and risk creating no end of problems. The other is again one of pressuring sites to fix their software; if the net silently works around their breakage, they'll never feel the need to upgrade. Of course, not everybody agrees with the need to pressure people to upgrade. There are two camps on the question of whether the firewalls in question are really broken. One side, championed by networking hacker David Miller, says that "reserved" means that the bits in the header will be used for something cool at some point. When that use happens, older software shouldn't break. Others, however, believe that a firewall should reject packets that contains bits it doesn't recognize. Those bits could well indicate a new feature that subverts the firewall's security scheme. The fact that the ECN standard is still considered "experimental" also gives some ammunition to those who say the non ECN-compliant systems should be accommodated. David Miller feels strongly about the issue, however, and has [18]stated his intent to put an ECN kernel on vger.kernel.org "in four weeks time." At that point, anybody who is behind a firewall that does not speak ECN will loose access to all of the mailing lists served by that host. Note that ECN is not required on any particular system - all that is necessary is that the firewall not reject packets trying to use ECN. For those who are concerned about the issue, David also posted [19]a way to test your network to see if it works properly with ECN. Linux has reached a point where its weight can be used to push things like network standards. One can only hope that this influence will be used wisely. A wealth of filesystems. Not that long ago, ext2 was the Linux filesystem. It's unlikely to give up its dominant position anytime soon, but ext2 is increasingly having to share the stage with other filesystems that have native Linux ports. ReiserFS, of course, is now a standard part of the kernel. This week also saw news of three other filesystems for Linux; they may not be quite as production-ready as ReiserFS, but they are getting there. * SGI has [20]announced the availability of the "prerelease 0.9" version of its XFS journaling filesystem for the 2.4.0 kernel. It is available as a patch, or in RPM format for easy installation. This release is "stable in a majority of normal environments" according to SGI. Features claimed by XFS include, beyond journaling, very high performance (high data transfer speeds and quick directory lookups) and scalability. The file size limit on XFS is about 9 million terabytes, which should be sufficient to handle most peoples' needs for a while yet. * IBM has [21]announced "drop 24 release 0.1.4" of its Journaled File System (JFS). JFS was designed around journaling since the beginning; it uses B-trees for large directories but makes no particular performance claims. * Mountain View Data (the company formed by Peter Braam along with Cliff and Iris Miller) [22]will be demonstrating SnapFS at LinuxWorld. SnapFS is actually an add-on layer for an existing journaling filesystem which allows the taking of "snapshots" of the filesystem's state. Soon the hardest thing about installing Linux may choosing which filesystem to use. Avoiding bad sleeps. Conectiva's Arnaldo Carvalho de Melo recently announced his [23]Kernel Janitor's TODO list; it's meant to be a clearinghouse for people who are going through the code cleaning things up. Going through code to be sure it returns error codes properly would seem to be far less attractive than, say, writing another filesystem for Linux. There are quite a few people interested in doing janitorial tasks at the moment, however, and that work results in a more stable kernel. As part of that effort, it was suggested that the janitors look for and fix all code that calls sleep_on() (and, more commonly, interruptible_sleep_on(), but sleep_on() is easier for kernel page editors to type) since (1) almost all such code is incorrect, and (2) Linus has agreed that those functions should be removed in the 2.5 development series. It quickly became clear that quite a few people, even those familiar with kernel code, didn't understand what the problem with sleep_on() was. So, for the curious, here's a description of an obscure bug that lives within a lot of kernel code. The purpose of sleep_on() is to suspend the current process until something of interest happens. That something could be a read from a disk, the arrival of data from the network, the availability of a kernel data structure, the expiration of a timer, or many other things. Running "ps aux" will show a lot of processes with "S" in the "STAT" field; they are all sleeping in this manner. The problem with sleep_on() is that there is necessarily a delay between the decision to sleep and actually sleeping. Code that sleeps usually looks something like: while (something_is_missing) { take_steps_to_make_it_available (); sleep_on (proper_wait_queue); } If the thing that is being slept on happens between the test in the while loop and the process actually going into a sleeping state within sleep_on(), the wakeup event will be lost and the process could sleep for a very long time. In the days of the 2.0 kernel and before, this problem did not arise often; nowadays, instead, with SMP systems and fine-grained locking, this kind of race condition is much more likely to come about. It's still a rare occurrence (the window is quite small, usually), but, within operating system kernels, one-in-a-million events are regular occurrences. The proper way to handle this situation involves, essentially, going to sleep and getting on the wait queue prior to testing for the needed condition. Essentially, the process "sleepwalks" while testing to see if it really needs to wait. If the wakeup happens before the process gives up the processor, the process just gets put back into the running state and everything works as it should. The actual coding to sleep in this way is rather more complex than a simple sleep_in() call; see [24]this posting from David Woodhouse for an example of how it should be done. Alternatively, programmers can use the (relatively) new wait_event macro, which hides a lot of the details. Or one can set up a timeout to happen in a short while to wake up the process if nothing else does. A quick grep through the 2.4.1 kernel source shows well over 400 calls to sleep_on() and interruptible_sleep_on(). The kernel janitors have quite a bit of cleaning up to do. Other patches and updates released this week include: * Robert H. de Vries released [25]a new version of his POSIX timers patch for 2.4. * David Howells has posted [26]a patch implementing a facilty he calls "task ornaments." It's a mechanism for attaching arbitrary information to the task structure for code that needs to keep specific, task-specific information. * Compaq has released [27]a driver for its PCI hot plug controller * Dennis Koslowski has posted [28]a portscan detector module for netfilter. * [29]A Dolphin PCI Scalable Coherent Interface driver for the 2.4 kernel was posted by Jeff Merkey. * Werner Almesberger has posted [30]an RFC for a new traffic control configuration language. The current way of configuring network traffic control can be a little difficult at times... * David Miller continues to update his [31]experimental zero-copy networking patch. * Jeff Dike has posted [32]a new version of his user-mode Linux port which works with the 2.4.1 kernel. * Rik van Riel has set up [33]a Linux memory management bug tracking system to help him keep on top of what's happening with the VM subsystem. Shortly thereafter he [34]changed the URL to use his newly-registered linux-mm.org domain. * Harald Welte has set up [35]a new mailing list to discuss a proposed netfilter failover implementation. * Daniel Phillips posted [36]a proposal for a 'cleaner, whiter' timer interface designed to make life easier and avoid race conditions. --- ifmail v.2.15dev5 * Origin: Rostelecom/Internet Centre (2:5020/400)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
  • 1, Roman (?), 16:16, 11/11/2002 [ответить]  
  • +/
    Люди, хелп, срочно нужна инфа(русскоязычная)по XFS.
    Подробнее : организация; отличие от стандартных FS типа FAT; схемы прохождения запросов типа
    read/write, open/close, create/delete;
    а также вывод формул по расчёту производительности, выбору размера экстента, поддержки max кол-ва клиентов и т.д.
    Пригодиться всё : от сайта до названия книги или отсканенная книга мне на ящик. Это очень срочно - горит диплом.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру