mdrozdziel's questions

According to various DHCP description after reaching 50% client will enter RENEW state and will start sending DHCPREQUEST messages to the server in order to renew the lease. It will continue to send the requests until either getting reponse or reaching 87.5% of time. After reaching that time, it will change the state to REBOUND and will continue to send requests (until response or 100%).

So, whats the difference between RENEW and REBOUND state? Whats the point of this mark timer, if there is no change in the behavior on the client side? To the outside world it looks like the server will just send requests from after passing 50% of the lease until either getting the response or reaching 100%.

Well known PaaS provider Heroku offers multiple solutions to SSL problem. One of those is a product called Hostname Based SSL

This is not SNI. They claim it works on every browser in any configuration but has other drawbacks, mainly (quoting the docs):

• Hostname based SSL will not work with root domains as it relies on CNAME aliasing of your custom domain names.

• Hostname SSL works with one domain only. For example, www.domain.com would work, but if a second certificate for secure.domain.com is added to the application it will not work.

• Our hostname-based SSL offering currently strips some HTTP headers; this can be a problem when your app needs to look at the IP of the client, for instance.

Using this custom build solution Heorku can serve multiple SSL sites on a single IP address and as they claim it will work across anything.

Can anyone explain technical side of this solution and technology behind this product?

Ok, this is a very practial use case from my point of view.

Let say I have a some simple shell oneliner which does log the output into a file. This can be simply anything, for example tcpdump. Is there any generic and trivial way, to make sure, that the output file won't exceed given size?

Resoning behind this, is to protect from filling the whole available space on the mount point by mistake. If I forget about the script, or it will yield GBs of data per hour, then this simple debugging task can lead to a potential system crash.

Now, I am aware of the options build in some of the tools (like combination of -W/-C in tcpdump). What I need is a very generic failsafe.

Long story short - when I run a script like:

% this -is --my=very|awsome|script >> /var/tmp/output.log

How to make sure that output.log will never get bigger than 1GB.

Script can crash, be killed or whatever.

Solution I am looking for should be easy and simple, using only tools available in popular distros like ubuntu/debian/fedora. In general something widely available. Complicated, multiline program is not an options here regardless of the language/technology.

I have Ubuntu 10.10 x86_64 2.6.35-28 installed on two mirror machines. Kernel processes are slowly consuming whole available memory over time. Tooks around 10 days to eat up 4GB which leads to obvious total crash.

On the pastie below, you can check how does the slab info looks like around 24 hours prior to coming crash.

http://pastie.org/private/lmx2xhijugfi8zkic4cpsa

Its always kmalloc-192 and kmalloc-32 which are leaking the memory with the mutual proportion 6:1 (192:32). I am not really sure where to go from that point. Is there any other possible way to diagnose to cause a bit deeper?

I found out some posts from people with quite similiar issue on pretty much same hardware. The proposed solution was to disable acpi and apm, but it doesn't solved the issue on my boxes.

Any ideas much appreciated.

Hardware is from HP (DL360G5).

The most odd thing is, that slub_debug fixes the problem. There is no leak with debug enabled. I tried few times back and forth. Looks like the corelation is consistent!

I have very complicated and long iptables script. It is not possible to operate on the existing iptables configuration, by doing manual inserts/replaces or deletions. I have a script which simply flushes all rules and custom chains, then reloads everything from scratch. This approach works well, to some extent.

I have a lot of sensitive traffic, like E1 lines encapsulated into IP packets and many others. I can't afford to just drop all rules and reinsert them, because this is simply too slow. Lots of stuff breaks if there is no rule for more then 50ms. Aside from that, some high throughput traffic runs in into partially restored firewall, which ends up in very bad conntrack entries, which require manual intervention to restore functionality.

The solution would be to append new rules at the end of current, then to remove the old ones, which can theoretically result in continuous ruleset in place. The problem is, that a script with custom chains, ipset's and such is getting very complicated and error prone.

Question is - do you know any existing solution (extra layer on top of iptables), which handles the problems I mentioned here?

Thanks in Advance.

This seems to be quite a trivial problem, but after some searching I can't stil figure out the answer. One can run tcpdump using "any" as the interface description, ie:

 # tcpdump -i any -n host 192.168.0.1

Is there any way to force tcpdump to show on which interface displayed packet was captured?

Update:

As more people confirmed this is probably not possible with vanilla tcpdump, can someone propose a solution to mentioned problem? Perhaps different sniffer?

General issue is as follows: On a system with 50 interfaces determine what is inbound interface for packets coming from specific ip address.