Today I Learned

hashrocket A Hashrocket project

60 posts about #devops surprise

Be careful when editing the sudoers file

This website says: Because improper syntax in the sudoers file can leave you with a system where it is impossible to obtain elevated privileges, it is important to use the visudo command to edit the file.

RIGHT. If you screw up the syntax you may remove access to the system. visudo checks the syntax for you and won’t let you save a file with incorrect syntax. It responds to the EDITOR env variable so you can edit it in an editor of your choice.

Another command that helps you edit a resource with safety restrictions is vipw.

Limit SSH by IP address

SSH has some nice security features like password-less authentication. For the sysadmin who wants even more fine-grained control, the ssh configuration has a setting for what users are allowed to authenticate based on their IP address.

# /etc/ssh/sshd_config
AllowUsers admin@127.0.0.1 deployer@127.0.0.1 git@*

This configuration says that admin & deployer are only allowed to login from 127.0.0.1, but git can login from any IP address. You can also use wildcards the other way:

AllowUsers *@127.0.0.1

The most useful thing here is the ability to use * to match users and hosts.

h/t Chris Erin

Reload The nginx Configuration

If you’ve modified or replaced the configuration file, nginx will not immediately start using the updated nginx configuration. Once a restart or reload signal is received by nginx, it will apply the changes. The reload signal

$ service nginx reload

tells nginx to reload the configuration. It will check the validity of the configuration file and then spawn new worker processes for the latest configuration. It then sends requests to shut down the old worker processes. This means that during a reload nginx is always up and processing requests.

source

Check The Status Of All Services

In a Linux environment, you can quickly check the status of a number of different services. By running [sudo] service --status-all, the status command will be invoked for all services under the /etc/init.d/ directory.

So, if you want to check the status of something like nginx or apache, just run service --status-all and find it in the list. The - symbol means it isn’t running, the + symbol means it is up, and the ? symbol means that it cannot determine the status.

How busy are your cores?

Linux talks about core utilization in terms of “Load Average". This is, the average load over 1 minute or over 5 minutes or over 15 minutes.

For a 1 core machine a Load Average of 1.00 is 100%. For an 8 core machine 8.00 is 100%. On my 4 core mac I can check my Load Average with uptime

chriserin@:~% uptime
20:48  up 17 days,  1:42, 7 users, load averages: 1.23 1.53 1.59

Over the last 1 minute, 1.23. Over the last 5 minutes, 1.53. Over the last 15 minutes, 1.59.

My CPU is doing great! You can also see the same numbers in htop. Source

Wipe A Heroku Postgres Database

If you have some sort of non-production version of an application running on Heroku, you may encounter a time when you need to wipe your database and start fresh. For a rails project, it may be tempting to do heroku run rake db:drop db:setup. Heroku doesn’t want you to accidentally do anything stupid, so it prevents you from running rake db:drop. Instead, you must send a more explicit command

$ heroku pg:reset DATABASE_URL

Heroku will ask you to confirm that you indeed want to wipe out the database and will then proceed.

For the curious reader, running heroku config will list the values of a number of variables including DATABASE_URL.

Push Non-master Branch To Heroku

When using git to deploy your app to Heroku, it is expected that you push to the master branch. When you run the following command

$ git push heroku master

Heroku will attempt to build and run your app. However, if you have a staging branch for your application that you want to push to your staging environment on Heroku, you cannot simply run

$ git push heroku staging

Heroku will only perform a build on pushes to the remote master branch. You can get around this, though, by specifying that your staging branch should be pushed to the remote master branch, like so

$ git push heroku staging:master

source