I am interested in recursively grepping for a string in a directory for a pattern and then cp'ing the matching file to a destination directory. I thought I could do something like the following, but it doesn't seem to make sense with linux's find tool:
find . -type f -exec grep -ilR "MY PATTERN" | xargs cp /dest/dir
Is there a better way of going about this? Or a way that even works would be a solid start.
We currently have 12 nodes running in our Cassandra cluster. Ultimately even if a couple of the nodes go down, we're still up and running. The paranoia in me would like to do at least one backup a day and store it on Amazon S3. My question is the following:
When backing up Cassandra, is it sufficient to run the backup from one node, or do I have to run a backup script from each one of the 12 nodes and push its respective backup onto S3? If at one point a restore is required, do we have to backup from the individual nodes backup, or is there a way to "aggregate" the backups (assuming you need to take them from each node individually) into one large restore process?
Slightly confused by the documentation. Just want to get an efficient backup process rolling on my Cassandra cluster.
I'm not sure why, but after I restarted my ec2 instance, /dev/md0 didn't start as it normally would. after I saw what's available in /dev/md*, instead of seeing /dev/md0, there is a device there named /dev/md127. I updated fstab to reflect the new device and was able to mount it successfully. Looking at /proc/mdstat, it is using the correct underlying ephemeral volumes that the RAID was originally created on:
[root@ip-10-0-1-21 ~]# cat /proc/mdstat
Personalities : [raid0]
md127 : active raid0 xvdc1[1] xvdb1[0]
870336512 blocks super 1.2 512k chunks
unused devices: <none>
Yet when I run a mdadm --detail --scan a difference device name shows up:
[root@ip-10-0-1-21 ~]# mdadm --detail --scan
ARRAY /dev/md/ip-10-0-1-21:0 metadata=1.2 name=ip-10-0-1-21:0 UUID=543098de:1e9dc96e:4ce2444c:934bdfdf
Is it normal for the device name to change? Do I have to update /etc/fstab with the new device name? Is it critical that I re-run /etc/mdadm.conf with the new information? Is this device name /dev/md127 or dev/md/ip-10-0-1-21:0? I suppose I'm not sure what's going on here. Some insight would be great.
I have an application where the client connects to a server via a simple TCP based protocol over TLS/SSL. In development, this has worked great for many months while we were building our application out. Recently as we prepare for launch, I've gone ahead and added HAProxy into the mix in order to facilitate some order of load distribution. Everything works, technically, but the issue is, the client is now seeing completely random time outs. They are not typically consistent, but happen at roughly 60 seconds long. Sometimes it can happen after 25 seconds. The server that haproxy forwards the TCP connection to notices and does a clean disconnect, the problem is you do not want a bunch of simultaneous connections getting disrupted and reconnected over and over without any reason. This has implications on our publish/subscribe infrastructure in addition to other things. The client is smart enough to reconnect right away - however that's not the behavior we desire. The server that's responsible for accepting these TCP connections over SSL does not require a keep alive. I'm going to go ahead and assume that there is some implicit value I'm not seeing in my HAProxy config causing these random timeouts, or something that requires a TCP keep alive. The fact that the timeouts are not always consistent however, makes me wonder otherwise. If it was 60 seconds on the dot each and every time I'd be convinced it's a configuration issue. In this particular case, it is not always 60 seconds. Here's what my configuration looks like right now:
global
stats socket /home/haproxy/status user haproxy group haproxy
log 127.0.0.1 local1 info
# log 127.0.0.1 local5 info
maxconn 4096
ulimit-n 8250
# typically: /home/haproxy
chroot /home/haproxy
user haproxy
group haproxy
daemon
quiet
pidfile /home/haproxy/haproxy.pid
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 5000
clitimeout 60000
srvtimeout 60000
# Configuration for one application:
# Example: listen myapp 0.0.0.0:80
listen www 0.0.0.0:443
mode tcp
balance leastconn
# Example server line (with optional cookie and check included)
# server srv3.0 10.253.43.224:8000 srv03.0 check inter 2000 rise 2 fall 3
# Status port (by default, localhost only...for debugging purposes)
server ANID3 10.0.1.2:8888 check inter 3000 rise 2 fall 3 maxconn 500
server ANID1 10.0.1.3:8888 check inter 3000 rise 2 fall 3 maxconn 500
server ANID2 10.0.1.4:8888 check inter 3000 rise 2 fall 3 maxconn 500
listen health 0.0.0.0:9999
mode http
balance roundrobin
stats uri /haproxy-status
I verified that HAProxy is the issue by having our client bypass it and go directly to a single app server where there is no time outs and everything is nice and dandy. As soon as I route it through one of our two haproxy servers, the random disconnects happen ranging anywhere between 25-60 seconds.
Thanks for taking a look at this. It is quite frustrating, but I'm sure it is a lack of understanding in what exactly HAProxy expects from my client.
I am currently using HAProxy in order to load balance tcp connections from clients to my Erlang app server. The connection is persistent, which means I'm limited to roughly 64K clients on an optimized server (I'm currently running HAProxy on an m1.large EC2 instance). My app server is designed to horizontally scale based on the number of TCP connections. What's worrying me though is I'll need an equal number of HAProxy servers as app servers since it's a 1:1 connection. Is there currently a way to "proxy" the tcp connection to the app server so that once HAProxy sends the client off to my Erlang server, it can free up the connection, ready to serve another client? Are there any papers, existing solutions out there I can read so that I only have to worry about the 64K limit on my app servers, and not on the load balancing servers themselves?
Exactly what the title says. I'm not having much luck finding the proper documentation to see what -xe does in the following use case:
#!/bin/bash -xe
what do those parameters do and where it is documented?
I use Amazon EC2 for my mobile app. Depending on load of the application at a given time, I might spawn new instances and then take them down when load is lower to save costs.
How does one keep up with Nagios configurations for such a dynamic environment? When one deals with managed hardware, configuration files are predictable. In this case Nagios, Capistrano and a bunch of other configuration files would need to be added. Capistrano needs to know where to deploy a new build to for an app server. Nagios needs to know to remove an existing instance or add a new instance for monitoring. Nagios also needs to know if a node was intentionally taken down or if the host is down due to error.
How is this done with the wonderful world of VPS/dynamic instances?
I'm not interested in having all of my EC2 instances having a public IP on their network interface. I want to have full access over what boxes can speak directly to the Internet and which can be reached directly from the Internet. In a typical, very basic setup, you'd have a firewall on your DMZ with something like OpenVPN running on it so clients can get on your "internal" network and work with machines on your private LAN (RFC1918 IP space). My question is, it looks like Amazon VPC currently only caters to IPSec hardware VPN solutions. Is there anyway I can setup Amazon VPC and use a software VPN so my colleagues and I can login to our cluster of EC2 servers behind a VPN? I don't want to have slap on public IP addresses on any of the machines. The load balancer will eventually be on the DMZ and speak to the boxes behind the VPN/Firewall. What's the best way of doing this on Amazon VPC?
How do you folks manage your Amazon RDS instances? In production I obviously want to use Amazon RDS with a master-slave replication setup going. Unfortunately this incurs substantial costs to bring something similar into a development/qa environment, yet we strive to keep dev/qa as close to prod as possible. How do you handle such a case in your day to day dealings?
I have what seems to be a growing count of EC2 instances and all is running fine and dandy. The one problem I'm facing, however, is figuring out a strategy for SSHing between the machines. Copying over my private key to each instance is counter productive, and it works fine when I need to SSH in from my personal machine, but not when I need to SSH from machine to machine.
What are some decent strategies to tackle this problem? How are you SSHing in between your cluster of EC2 instances?
Is it possible to create more than one private key to SSH into an EC2 instance? What's the general best practice for this? We have multiple users who need to SSH into the servers and distributing one key just does not work well. This does not allow us to remove users from being able to SSH into the server unless we change the key and redistribute.
I recently stumbled upon a firewall issue with my EC2 instance. The TCP port was made available to everyone via the EC2 Security Group, however there was still instance-side filtering using iptables. I figured if anything Security Groups are just a fancy API for IPTables. It turns out they're running completely exclusively from what I can tell. Is there any reason to use both? One firewall should be plenty and adding another layer of complexity seems to be a headache just waiting to happen.
In the meantime, I'm contemplating either opening up all ports in my Security Group and then doing all filtering via iptables, or the inverse, disable iptables and use Security Group filtering.
Any feedback on whether or not my logic here is flawed? Am I missing something critical?
Is there currently anyway to monitor CPU usage with Nagios3 that doesn't involve SNMP setup? I want to setup notifications if I'm going above a certain threshold, such as 55% of the CPU time is being used up by the system.
I have two openbsd nat/firewall boxes with carp for failover / high availability purposes. What would be the best possible practice to ensure that OpenVPN, which I plan on running on these boxes, fails over gracefully as well?
Every so often I login to production web/db/tools boxes and see the typical message:
30 packages can be updated. 16 updates are security updates.
My question is, how do all of you handle updates on your production Ubuntu boxes? Do you automate these updates? Do you set downtime for them? The problem is, you never know when an update is going to break something, such as perhaps an existing configuration file, etc.
The other part of this problem is, keeping up with patches is 'a good thing', but patches are released almost daily. How many scheduled outages does one have to make if there is a new security patch available every single day?
I think a thread on answers as to how you manage your updates would be very useful.
I have a nagios setup which ensures that SIP is responsive on my Asterisk server, that's straight forward.
My question is, what kind of possibilities are there that the Asterisk server can actually terminate properly with the termination provider? As in produce a test call and ensure that something on the other end picks up?
I realize this is a multi-part and very difficult problem. Without expensive equipment, it's almost impossible to tell what medium is on the other end of termination point.
Just curious what you SIP/Asterisk guys are doing to monitor for this to know when there is an outage besides your users calling you to tell you that's the case?
I'm interested in using MMR (http://mysql-mmm.org/) for high availability and replication purposes. The problem is, I'm also interested in using Linux-HA for other services, such as Apache. The two overlap when it comes to certain things, such as swapping virtual IP interfaces etc.
Does anyone have a similar setup and have some best practices/solutions for the problem above?
is there a best practice to ensure that privileges do not get replicated to mysql slave servers? the problem is, there a maintenance users in the mysql table that have different passwords on each box. things like startup/shutdown scripts use these tables. when you replicate from a master, it changes the password and breaks things.
what are best practices to ensure that the actual mysql db (that contains grants, users, hosts) does not break because of replication?
do you typically replicate privileges over to the slaves as well?
I have a very trivial mysql master->slave setup going on between two servers. The problem is, replication is asynchronous, and this can cause issues (even on a low latency link), if the master server was to crash after a COMMIT before the replication thread from the slave was able to fetch the last bin log.
Is there anyway to force mysql to do synchronous commits so that data consistency is guaranteed in a mysql->slave relationship?
I'm currently using a linux box to handle my firewall/NAT using iptables. It has two NICs, one link to a LAN switch, one to our egress Internet provider. I'm looking at upgrade this box to two boxes for purposes of redundancy and adding a second Internet provider to the solution. This means I need four ports I believe (correct me if I'm wrong)
I've read carp+pfsync is a good solution. Is that currently what most of you are using? Is there an equivalent solution in linux?
What are some suggestions for hot failover with ease of configuration as of today for a similar setup as above?