Just wanted to make a quick post that if you’re interested in Ruby on Rails Development, please contact me over at Velocity Labs instead of here. Thanks!
{ 0 comments }
Uncategorized
I find it’s pretty annoying when you have to go log file spelunking only to find all the timestamps are in UTC. But we can set the timezone of the server so when Rails, cron, scripts, etc run, they output more readable dates.
You can check your current timezone by just running
$ date
Thu Mar 21 18:02:49 MST 2012
Thu Mar 21 18:02:49 MST 2012
Or checking the timezone file at
$ more /etc/timezone
US/Arizona
US/Arizona
So to change it just run
$ sudo dpkg-reconfigure tzdata
And follow on screen instructions. Easy.
Also be sure to restart cron as it won’t pick up the timezone change and will still be running on UTC.
$ /etc/init.d/cron stop
$ /etc/init.d/cron start
$ /etc/init.d/cron start
UPDATE July 2016
In the comments Dan mentions that in 16.04 you use something like:
$ sudo timedatectl set-timezone Australia/Melbourne
Need web application development, maintenance for your existing app, or a third party code review?
Velocity Labs can help.
{ 63 comments }
Having problems getting ssh to use your public key?
Log on to your server as root using a password. Remember not to log out as root until you have ssh working with your public key or you may inadvertently lock yourself off the box.. which sucks 
Double check your sshd_config, I use the following options (note you will have to restart ssh for these changes to take effect):
1 2 3 4 5 6 7 8 | Port 30000 <--- change to a port of your choosing Protocol 2 PermitRootLogin no PasswordAuthentication no UseDNS no AllowUsers deploy <--- change to whatever users you want ClientAliveInterval 30 ClientAliveCountMax 4 |
Make sure your public key is in the .ssh/authorized_keys file for the user you plan on logging onto the server as. You can use this super helpful authme bash function.
So let’s say you’ve done all this and YOU STILL CAN’T get it to work. It’s probably because you have incorrect permissions set on the .ssh directory and/or the authorized_keys file. You can check this by looking at the ssh auth log. Depending on your server OS it’s usually either /var/log/auth.log or /var/log/secure . Tail this file and see if you’re getting this message
1 | Authentication refused: bad ownership or modes for directory /home/deploy/.ssh |
Obviously your directory will be different depending on the name of the user you’re trying to ssh on as. But this message is the give away that your permissions are wrong. Change them with the following, assuming your username is “deploy”, otherwise just substitute that part.
$ chmod go-w /home/deploy/
$ chmod 700 /home/deploy/.ssh
$ chmod 600 /home/deploy/.ssh/authorized_keys
$ chmod 700 /home/deploy/.ssh
$ chmod 600 /home/deploy/.ssh/authorized_keys
Try ssh’ing on again in another terminal window and you should be good. Now it would be safe to log off as root.
{ 2 comments }
Velocity Labs