On Tue, Aug 25, 2009 at 11:59 PM, Shane Hathaway wrote:
> In the last distributed system I helped build, we didn't feel good about
> having a central point of control (and failure), but in the end we
> decided that a fully distributed system would add unjustifiable
> complexity and expense. Fully
Dave Smith wrote:
> Yes, this question came up about a year ago, and XMPP and IRC were
> considered. I never really pursued those options further because I'm
> somewhat opposed to having a central "broker" (for lack of a better
> word) that acts as a single point of failure, and adds complexi
On Tue, Aug 25, 2009 at 18:54, Wade Preston
Shearer wrote:
> Logging onto the server via SSH is slower now. Is that to be expected with
> the filtering I just put into place or is that an indication that something
> is not right?
You might try adding 'GSSAPIAuthentication no' to your ~/.ssh/config
On Tue, Aug 25, 2009 at 9:20 PM, Dave Smith wrote:
> I have looked at AMQP, specifically OpenAMQ, and found its ramp-up
> time unacceptable and its documentation awkward. Further, it feels
> like overkill for the simple style of communication that I want. I'm
> looking for something that aims to ac
Wade Preston Shearer wrote:
> Thanks for the help. w and who both returned the static IP address
> assigned to my house by my ISP. running the host command on that IP
> returned "connection timed out; no servers could be reached".
>
> Is that something I need to resolve with my ISP?
Maybe you
On 25 Aug 2009, at 21:54, Michael Torrie wrote:
Well once logged in, run the "w" or "who" commands and see what IP
address you're coming from, then see what "host ##.##.##.##" says.
Thanks for the help. w and who both returned the static IP address
assigned to my house by my ISP. running the
Wade Preston Shearer wrote:
>> Sounds like DNS isn't resolving the reverse lookup of the client's IP
>> address.
>
> How would I verify this?
Well once logged in, run the "w" or "who" commands and see what IP
address you're coming from, then see what "host ##.##.##.##" says.
/*
PLUG: http://plug
On 25 Aug 2009, at 21:49, Michael Torrie wrote:
Sounds like DNS isn't resolving the reverse lookup of the client's IP
address.
How would I verify this?
Once you get logged in is it normal speed?
Yes, once I am logged in everything is normal.
smime.p7s
Description: S/MIME cryptographic
Wade Preston Shearer wrote:
> I ran the script, loading the new settings and restarting iptables. It
> appears to have worked correct as all services are running as
> expected. Logging onto the server via SSH is slower now. Is that to be
> expected with the filtering I just put into place or
On Tue, Aug 25, 2009 at 21:20, Dave Smith wrote:
> On Aug 25, 2009, at 5:07 PM, Shane Hathaway wrote:
>
>> Dave Smith wrote:
>>> I already have a good marshaling method: Google Protocol Buffers.
>>> Now I
>>> need some good software for sending messages to and from different
>>> parts
>>> of the sy
On Aug 25, 2009, at 5:07 PM, Shane Hathaway wrote:
> Dave Smith wrote:
>> I already have a good marshaling method: Google Protocol Buffers.
>> Now I
>> need some good software for sending messages to and from different
>> parts
>> of the system.
>
> I mentioned Twisted. If Python is out, I th
I ran the script, loading the new settings and restarting iptables. It
appears to have worked correct as all services are running as
expected. Logging onto the server via SSH is slower now. Is that to be
expected with the filtering I just put into place or is that an
indication that somethi
On Tue, Aug 25, 2009 at 05:07:11PM -0600, Shane Hathaway wrote:
> Dave Smith wrote:
> > I already have a good marshaling method: Google Protocol Buffers. Now I
> > need some good software for sending messages to and from different parts
> > of the system.
>
> I mentioned Twisted. If Python is o
Dave Smith wrote:
> I already have a good marshaling method: Google Protocol Buffers. Now I
> need some good software for sending messages to and from different parts
> of the system.
I mentioned Twisted. If Python is out, I think I'd use libevent, which
provides something like the core of Twi
On Tue, Aug 25, 2009 at 4:35 PM, Dave Smith wrote:
> I already have a good marshaling method: Google Protocol Buffers. Now I
> need some good software for sending messages to and from different parts
> of the system.
Is this the same thing that you looked at IRC for? I seem to recall
something ab
Dallin Jones wrote:
> All of the stuff that I have been using uses JSON to send data and
> events back and for. It is super easy to parse and encode. And it
> isn't nearly as bloated as XML
>
I already have a good marshaling method: Google Protocol Buffers. Now I
need some good software f
On Tue, 2009-08-25 at 11:52 -0700, Wade Preston Shearer wrote:
> # allow returning packets
> /sbin/iptables -A INPUT -i lo -j ACCEPT
This has nothing to do with "returning" packets. It just means that two
service on the same box can talk to each other using IP on the loopback.
"Let the box talk t
Thanks, Stuart. Your additional explanation was very helpful. Here's what I
have updated the script to with your feedback. Do I have the order right?
(Note that I have commented out the restorecon line as I am not running
SELinux.)
#!/bin/sh
# drop all incoming traffic
/sbin/iptables -P INPUT
On Tue, 2009-08-25 at 11:27 -0600, Dallin Jones wrote:
> All of the stuff that I have been using uses JSON to send data and
> events back and for. It is super easy to parse and encode. And it
> isn't nearly as bloated as XML
If bloat is such a concern, why not ASN.1 or Protocol Buffers or Thri
Dave Smith wrote:
> For those of you who are writing distributed software that does a lot of
> network communication between lots of processes on different hosts
> (traditional distributed system), I have a question for you:
>
> What software are you using to move data and events between the
>
I prefer JSON, myself. I agree it's not nearly as bloated.
On Tue, Aug 25, 2009 at 11:27 AM, Dallin Jones wrote:
>
> On Aug 25, 2009, at 11:19 AM, Dave Smith wrote:
>
> > For those of you who are writing distributed software that does a
> > lot of
> > network communication between lots of proc
On Aug 25, 2009, at 11:19 AM, Dave Smith wrote:
> For those of you who are writing distributed software that does a
> lot of
> network communication between lots of processes on different hosts
> (traditional distributed system), I have a question for you:
>
> What software are you using to mov
For those of you who are writing distributed software that does a lot of
network communication between lots of processes on different hosts
(traditional distributed system), I have a question for you:
What software are you using to move data and events between the
components of your software?
On Tue, 2009-08-25 at 08:44 -0600, Wade Preston Shearer wrote:
> On 24 Aug 2009, at 23:29, Stuart Jansen wrote:
>
> > iptables -A INPUT -i lo -j ACCEPT
>
> Allows packets on the loopback interface, only, right?
Always allow packet from loopback. Or, as I like to put it, "Allow the
machine to tal
On Tue, August 25, 2009 8:44 am, Wade Preston Shearer wrote:
>> /sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> I don't see the 'm' flag in the man file. What exactly is this
> original option doing? What do related and established do?
-m loads a module. In this case th
On Tue, August 25, 2009 9:25 am, Wade Preston Shearer wrote:
> On Tuesday, August 25, 2009, at 08:00AM, "Michael Torrie"
> wrote:
>
>>Yes, you should always allow rate-limited ICMP packets of type 8.
>>Otherwise, in my opinion, you break basic internet functionality. This
>>propensity of large
On Tuesday, August 25, 2009, at 08:00AM, "Michael Torrie"
wrote:
>Yes, you should always allow rate-limited ICMP packets of type 8.
>Otherwise, in my opinion, you break basic internet functionality. This
>propensity of large organizations like BYU or Microsoft to drop packets
>instead of return
Wade Preston Shearer wrote:
> I appears that Stuart's is a better way to allow all the packets
> through and Mr. Ritter's limits it to just icmp packets. Will I really
> be okay only allowing those packets through? icmp packets are errors,
> right? And since we are trying to limit returning p
Let me make sure I understand what each of these returning pack lines
do:
On 24 Aug 2009, at 23:05, Mr Ritter wrote:
/sbin/iptables -A INPUT -p icmp --icmp-type 8 -m limit --limit 5/sec
--limit-burst 5 -j ACCEPT
Allows icmp packets of type 8 limited to a certain amount in a certain
rate,
29 matches
Mail list logo
