Live data from Hacker News

Devops/Sysadmin Cheatsheet

rubytune.com

11–20 of 110 posts

Re: Devops/Sysadmin Cheatsheet

#11
post #9

I would warn anyone that read this to understand what each command does before actually running anything on a machine. Things like "sudo !!" are INCREDIBLY dangerous, and I would never put that on a cheat sheet.

Truthfully, I'm more comfortable using the up arrow and re-running it manually. At least I can inspect what the command was before running it.

Obviously, this doesn't help when using Fabric or scripting, but you shouldn't need "sudo !!" in those scenarios.

Re: Devops/Sysadmin Cheatsheet

#12
post #9

I would warn anyone that read this to understand what each command does before actually running anything on a machine. Things like "sudo !!" are INCREDIBLY dangerous, and I would never put that on a cheat sheet.

Anyone running commands blindly without knowing what they do deserves what they get. That goes for potentially dangerous commands or not.

Or put in a slightly nicer way - Blindly running commands is going to turn into a learning experience, don't do it on a production machine.

Re: Devops/Sysadmin Cheatsheet

#13
post #9

I would warn anyone that read this to understand what each command does before actually running anything on a machine. Things like "sudo !!" are INCREDIBLY dangerous, and I would never put that on a cheat sheet.

I suppose if you type it at any random point it might be. It's useful more when typed something that you forgot to sudo.

Re: Devops/Sysadmin Cheatsheet

#15
post #5

For getting around linux I've found no better helpers than manpages and the cheatsheets by Peteris Krumins[1]. I notice this isn't offered as a pdf or image, is the idea that someone will come and visit the site when their server is in trouble? That said, I didn't know about some stuff here like scriptreplay -- thanks! [1]: http://www.catonmat.net/projects/cheat-sheets/

I'd second a quick pdf version of it as well, I'm sure more than a few of us have a directory with cheatsheets in somewhere on their drive as a 'just in case'.

http://pdfcrowd.com/

Note: not affialated with them; just one of the top Google results. Also, I'd take a screenshot (and then export to pdf if an image file wasn't acceptable) since the pdf conversion via pdfcrowd splits it into multiple pages.

Re: Devops/Sysadmin Cheatsheet

#16
Some random thoughts:

- Instead of 'while true;' you can use the shorter 'while :;'. ':' is a null command.

- On OS X, dtruss is kinda, sorta like strace (it's a wrapper around dtrace, and the dtruss name comes from Solaris).

- For basic host to IP resolution, I prefer ping as it calls gethostbyname(), like most other programs will do. host/dig are suitable for querying/testing DNS independent of how the local box is configured as they call the resolver library directly. For example, host bypasses nsswitch.conf.

(Separately, OS X's stub resolver has some neat tricks. e.g., using /etc/resolver/ to route DNS requests for a particular domain to a specific name server.)

- I had never heard of http://michael.toren.net/code/tcptraceroute/ before. I don't think I've ever encountered a situation where the issue was outbound ICMP/UDP packets being blocked, but rather it's the return ICMP Time Exceeded packets.

- 'find . -size +100M' is shorter than 'find ./ -size +100000000c -print'.

- ctime is NOT when a file was created, though this is a common misconception. Unix does not record when a file is created. Rather, ctime is the last time the file's status (i.e. inode information aka metadata) was changed. This differs from mtime which records the last time the file's data was changed. ctime is a superset of mtime. atime is the last time a file was accessed, unless the filesystem is mounted with noatime (common for NFS file ssystems). atime/mtime can be set to arbitrary values (permissions allowing) via the utime() system call.

- Modern find supports -delete instead of '-exec rm {} \;'. In any case, my muscle memory still defaults to '-print0 | xargs -0 rm'.

- 'dd if=/dev/zero of=file.txt count=1024 bs=102' seems like an odd way to do that. I think that 'bs=1024 count=102' might be more efficient depending upon buffering?

Re: Devops/Sysadmin Cheatsheet

#17
post #5

For getting around linux I've found no better helpers than manpages and the cheatsheets by Peteris Krumins[1]. I notice this isn't offered as a pdf or image, is the idea that someone will come and visit the site when their server is in trouble? That said, I didn't know about some stuff here like scriptreplay -- thanks! [1]: http://www.catonmat.net/projects/cheat-sheets/

Check also the Unix Toolbox: http://cb.vu/unixtoolbox.xhtml I've got a copy of the pdf in my dropbox just in case.

Re: Devops/Sysadmin Cheatsheet

#18
Okay, I'll admit it. I don't actually know what devops is. I know what developers do and what sysadmins do. Is devops just a buzzword for one person who can do both? Or does it mean something other than that?

Re: Devops/Sysadmin Cheatsheet

#19
post #9

I would warn anyone that read this to understand what each command does before actually running anything on a machine. Things like "sudo !!" are INCREDIBLY dangerous, and I would never put that on a cheat sheet.

So, what's wrong with sudo !! then?

Re: Devops/Sysadmin Cheatsheet

#20
post #18

Okay, I'll admit it. I don't actually know what devops is. I know what developers do and what sysadmins do. Is devops just a buzzword for one person who can do both? Or does it mean something other than that?

I don't really know how to state what we do aside from "Writing the glue/lube between the application and the hardware."

Deployment automation, monitors, backups, cleanup...

Post reply on HN