Obviously, mirrors should get different access than the public. You can't put something in plain sight and then complain if people notice. This is stupid.
I don't think that bots are invited. This wouldn't make sense from an administrative view. The channels are probably password-protected. Nothing a little sniffing can't fix.
After all, the bot is code running locally. So if it contains any channel names, channel keys or cryptographic keys, you can get to them.
The underlying pf seems to have more flexibility than the interface on top then.
I suppose you mean something like the following?
# XXX: hardwire SIP and RTP source ports nat on $ext_if inet proto udp from $asterisk port { 5060, 10000:20000 } to any -> ($ext_if) static-port nat on $ext_if inet from $int_net to any -> ($ext_if) rdr on $ext_if inet proto udp from any to ($ext_if) port { 5060, 10000:20000 } -> $asterisk
Which means that traffic from an internal Asterisk that has source ports 5060 and 10000-20000 leaves NATed but with the source ports intact. Together with the ability to let Asterisk enter arbitrary IP addresses in SIP messages[1], this makes it look like it was directly connected and not behind NAT at all.
All other traffic - even HTTP from the Asterisk server for example - gets the source port replaced as usual.
[1] Who TF thought that entering layer 3 addresses in application layers was a good idea anyway?
This deserves investigating, I think. I'm seeing the same with pf on a custom-built NetBSD. I always blamed Kademlia because this is the only thing that doesn't work right and I have no other filter to transparently replace the current one.
If pf really had serious issues with certain types of UDP traffic, it should get fixed.
I don't really understand the business of "supporting so and so many connections". A connection when tracked with a stateful packet filter is nothing more than an entry in a state table. IIRC, state tables are binary trees. The number of entries doubles, the effort increases by one additional check.
I know routers like the WRT54GL v1.1 choke after 64 or so connections.
I find this hard to believe. Their software must suck really bad then.
With pf here, I see state tables with thousands of entries at peak times. pfctl -si currently shows an average of 500 state lookups per second. And the best part: the box shows almost no system load. The fractions of a percent that I see are probably file system operations when invoking top or cron jobs. All CPU time is mostly spent processing interrupts of the NICs. And all this is on a 586-class Geode processor with 266MHz and no L2 cache. http://www.pcengines.ch/wrap.htm BTW. Even if those WRTs have measly 100MHz ARM processors (I don't know), they should do better than 64 connections.
And pf does more than just filtering. It can act as a proxy for the 3-way TCP handshake, protecting servers from SYN floods. It does packet normalization, reassembling fragments and thereby greatly reducing ruleset complexity. And I just don't see any effect on the load. Before you see pf choke, the rest of the box must have choked long ago.
No it doesn't. It mixes the significance of the numbers. Your explanation hardly makes any sense because any benefit is outweighed by non-intuitiveness. You say one already knows what year it is. Well, why don't you already know the month, too? According to your "logic", the day should be the first, since it's the item that changes most frequently. Being accustomed to something != making sense.
YYYY-MM-DD is easily sortable for computers and is also the standard set by ISO 8601. This is the only correct and intuitive notation. Some countries use(d) DD.MM.(YY)YY which is at least easy to read for humans and maintains the order of most frequently changing to least frequently changing item. MM/DD/YY is just a mess and I can't count the times I've been confused by it.
All this gets worse when people use YY/MM/DD, DD/MM/YY or YYYY-DD-MM as I've seen recently, although the latter must have been a typo. As if../../.. wasn't bad enough, they use USA syntax but ISO semantics, WTF?
If only other systems had thought of that. You could implement it so that all the data of one user is stored in a single directory, called home directory.
We could even invent a new notation specifically for that. Like, I don't know, ~user/ or something.
In practice, it's those dynamic IPs that generate nearly all of the spam, and it's not that difficult for non-spammers to route their email through their ISP's mail server.
That's exactly what I don't want. My ISP is obliged to provide the government with an interface where they can snoop my mail traffic should they feel the need to. If I send mail directly, I can use TLS and be independant from any outside forces.
It's a nice feeling of control if you can look into your maillog and see the mail delivered with TLS directly to the recipient.
Remember, RBLs command a lot of power if a lot of people use them. There has been more than one incident in the past where RBL operators turned to extortion, "fees" to have your entry removed or blacklisting whole ISPs which they saw as spam-friendly.
Yes, RBLs are used voluntarily. That doesn't mean every user of them makes a critical judgement about their purpose and intentions. If many people blindly use a certain RBL, it sooner or later will turn corrupt and the power to intimidate ISPs and legitimate mail senders automatically arises. You can't change human nature.
Spam is bad. Corrupt RBLs are bad, too. I'm not implying Spamhaus is bad. I'm just saying look carefully who you trust and for which purpose. For me, this means never blocking a certain sender based on any RBL alone. Let the RBL modify some score, but never strictly block based on what it says.
In order to prove the copyright violation, the plaintiff had bought a device and reverse-engineered the firmware on it.
He successfully demanded the purchase price and expenses for reverse engineering. So D-Link now has to pay him back the price of the device - which he in turn must return back to D-Link of course - and 4 hours at 140,-EUR each.
Every 32-bit cpu out there has a corresponding Linux BSP or distro.
That's exactly the problem for me. Linux' "portability" consists of special cases for each architecture.
NetBSD is one source tree that you can compile on every supported arch or even cross-compile on i386[1], e.g. if your sun2 is too slow to build its own kernel let alone a complete system in reasonable time.
I can take a PCI WLAN card and put it into a Sparc with PCI slots and it runs the same driver from the same source as on i386. That's portability and it reflects in code quality. Heck, you can even cross-compile a complete NetBSD system on almost any POSIXish system. build.sh and the whole supporting infrastructure is just ingenious and a breeze to use.
Is there one single Linux distribution supporting more than 15 or 20 archs that would give me the same look and feel everywhere? I think not. It's all just special cases and hacks.
[1] i386 is the name of the architecture including the latest Athlons and Core 2 CPUs.
I know everyone hypes Asterisk and Open Source and all that.
But has anyone looked at Asterisk close enough? It's the most horrid piece of software I have seen in a long time. Its configuration is awkward at best and downright inconsistent and nonsensical at worst.
Its documentation is practially non-existent. Nowhere do you find a good documentation written by the programmers. All you have are Wikis and web sites where people try and guess how Asterisk works. Howtos consist of config snippets without explaining what the options mean, let alone explaining the grand scheme behind everything.
Maybe it works after you configured it based on some other guy's experience, but if you want clean and well-documented software, go look elsewhere.
Asterisk seems to be the PHP or MySQL of the PBX world.
Slashdot Mirror
Obviously, mirrors should get different access than the public. You can't put something in plain sight and then complain if people notice. This is stupid.
I don't think that bots are invited. This wouldn't make sense from an administrative view. The channels are probably password-protected. Nothing a little sniffing can't fix.
After all, the bot is code running locally. So if it contains any channel names, channel keys or cryptographic keys, you can get to them.
He can't be that naive.
When did geekdom become a synonym for infancy, illiteracy, stupidity and all that?
The underlying pf seems to have more flexibility than the interface on top then.
I suppose you mean something like the following?
# XXX: hardwire SIP and RTP source ports
nat on $ext_if inet proto udp from $asterisk port { 5060, 10000:20000 } to any -> ($ext_if) static-port
nat on $ext_if inet from $int_net to any -> ($ext_if)
rdr on $ext_if inet proto udp from any to ($ext_if) port { 5060, 10000:20000 } -> $asterisk
Which means that traffic from an internal Asterisk that has source ports 5060 and 10000-20000 leaves NATed but with the source ports intact. Together with the ability to let Asterisk enter arbitrary IP addresses in SIP messages[1], this makes it look like it was directly connected and not behind NAT at all.
All other traffic - even HTTP from the Asterisk server for example - gets the source port replaced as usual.
[1] Who TF thought that entering layer 3 addresses in application layers was a good idea anyway?
One answer: Get Intel cards.
This deserves investigating, I think. I'm seeing the same with pf on a custom-built NetBSD. I always blamed Kademlia because this is the only thing that doesn't work right and I have no other filter to transparently replace the current one.
If pf really had serious issues with certain types of UDP traffic, it should get fixed.
I find this hard to believe. Their software must suck really bad then.
With pf here, I see state tables with thousands of entries at peak times. pfctl -si currently shows an average of 500 state lookups per second. And the best part: the box shows almost no system load. The fractions of a percent that I see are probably file system operations when invoking top or cron jobs. All CPU time is mostly spent processing interrupts of the NICs. And all this is on a 586-class Geode processor with 266MHz and no L2 cache. http://www.pcengines.ch/wrap.htm BTW. Even if those WRTs have measly 100MHz ARM processors (I don't know), they should do better than 64 connections.
And pf does more than just filtering. It can act as a proxy for the 3-way TCP handshake, protecting servers from SYN floods. It does packet normalization, reassembling fragments and thereby greatly reducing ruleset complexity. And I just don't see any effect on the load. Before you see pf choke, the rest of the box must have choked long ago.
YYYY-MM-DD is easily sortable for computers and is also the standard set by ISO 8601. This is the only correct and intuitive notation. Some countries use(d) DD.MM.(YY)YY which is at least easy to read for humans and maintains the order of most frequently changing to least frequently changing item. MM/DD/YY is just a mess and I can't count the times I've been confused by it.
All this gets worse when people use YY/MM/DD, DD/MM/YY or YYYY-DD-MM as I've seen recently, although the latter must have been a typo. As if
If only other systems had thought of that. You could implement it so that all the data of one user is stored in a single directory, called home directory.
:(
We could even invent a new notation specifically for that. Like, I don't know, ~user/ or something.
Man, Apple users get all the goodies.
It's a nice feeling of control if you can look into your maillog and see the mail delivered with TLS directly to the recipient.
Remember, RBLs command a lot of power if a lot of people use them. There has been more than one incident in the past where RBL operators turned to extortion, "fees" to have your entry removed or blacklisting whole ISPs which they saw as spam-friendly.
Yes, RBLs are used voluntarily. That doesn't mean every user of them makes a critical judgement about their purpose and intentions. If many people blindly use a certain RBL, it sooner or later will turn corrupt and the power to intimidate ISPs and legitimate mail senders automatically arises. You can't change human nature.
Spam is bad. Corrupt RBLs are bad, too. I'm not implying Spamhaus is bad. I'm just saying look carefully who you trust and for which purpose. For me, this means never blocking a certain sender based on any RBL alone. Let the RBL modify some score, but never strictly block based on what it says.
Well, the ISP basically controls how you view the Internet. The next .exe you download via HTTP could be modified.
See my other post. Make your server auth but forward all requests to Spamhaus' servers.
People, PLEASE, if you don't understand DNS, don't suggest stuff.
See http://yro.slashdot.org/comments.pl?sid=199897&ci
Hell, NO!
You would be trying to use their DNS server as a recursive resolver. DON'T do that! It wouldn't work and you'd be an annoyance to them.
I suggest you read about DNS before doing things of which you don't understand the impact.
What could work is running BIND and doing something along the lines of
zone "spamhaus.org" {
type forward;
forwarders <their ip address>;
};
Why, yes. :)
I have read the verdict.
In order to prove the copyright violation, the plaintiff had bought a device and reverse-engineered the firmware on it.
He successfully demanded the purchase price and expenses for reverse engineering. So D-Link now has to pay him back the price of the device - which he in turn must return back to D-Link of course - and 4 hours at 140,-EUR each.
Plus, of course, loser pays.
There, fixed it for you.
NetBSD is one source tree that you can compile on every supported arch or even cross-compile on i386[1], e.g. if your sun2 is too slow to build its own kernel let alone a complete system in reasonable time.
I can take a PCI WLAN card and put it into a Sparc with PCI slots and it runs the same driver from the same source as on i386. That's portability and it reflects in code quality. Heck, you can even cross-compile a complete NetBSD system on almost any POSIXish system. build.sh and the whole supporting infrastructure is just ingenious and a breeze to use.
Is there one single Linux distribution supporting more than 15 or 20 archs that would give me the same look and feel everywhere? I think not. It's all just special cases and hacks.
[1] i386 is the name of the architecture including the latest Athlons and Core 2 CPUs.
I know everyone hypes Asterisk and Open Source and all that.
But has anyone looked at Asterisk close enough? It's the most horrid piece of software I have seen in a long time. Its configuration is awkward at best and downright inconsistent and nonsensical at worst.
Its documentation is practially non-existent. Nowhere do you find a good documentation written by the programmers. All you have are Wikis and web sites where people try and guess how Asterisk works. Howtos consist of config snippets without explaining what the options mean, let alone explaining the grand scheme behind everything.
Maybe it works after you configured it based on some other guy's experience, but if you want clean and well-documented software, go look elsewhere.
Asterisk seems to be the PHP or MySQL of the PBX world.
</rant>
It's not just that I hate this word, but what has it got to do with these blade servers? Are they edible?
Parent should be modded funny, not insightful, otherwise one could get the idea the moderators have no clue and support this silly argument.
It would help if he himself could write the language. Then he could correct it and not have fear.