Roll a Repo Back to a Given Commit
git reset --hard <commit_id>
git push -f
Find files that have changed in the last 2 days
git log --pretty=format: --name-only --since="2 days ago" | sort | uniq
View the history of a file
gitk filename
Push a new local branch to a remote Git repo
git push -u origin branch_name
Move uncommitted changes to a new branch
git checkout -v <branch-name>
make your changes
git add --all .
git commit -m "<message>"
now you can switch back and forth and see the changes
commit only modified or deleted files, not new files
git commit -am "<message">
References
Get System Info
salt '*' pillar.items
salt '*' grains.items
Downgrade a System
git clone git://github.com/saltstack/salt
cd salt
git checkout v<version number>
sudo python setup.py install --force
References
Stack Overflow
It might be a little late to the party, but I finally got around to putting together some responsive stylesheets. This site should now be rocking out on the iPhone like it’s 2007! The old stylesheet scaled well enough, but the updates should hopefully make things a bit more elegant on small screens while at the same time make better use of the additional real estate on larger screens.
So I needed a handy, low overhead way to test bandwidth between myself and a remote server. SCP was handy and was able to give me a relative thumbs up or down, but the overhead distorted the figures. dd and netcat to the rescue.
Open socket on machine “A”
while [ True ]; do nc -v -l 2222 > ddTest; done
Push a file from machine “B” to machine “A”
dd if=/dev/zero bs=50M count=1 | nc <ip of machine A> 2222
Finally got a chance to get down and dirty creating Chef recipes for use in OpsWorks. These are primarily just some notes for myself.
Debugging
- opsworks-agent-cli allows you to view logs, manually run setup scripts, etc
- not as useful a tool as one might want
- probably its ability to spit out the entire stack config into a json file is its the most useful feature
- the show_log log it presents is in /var/lib/aws/opsworks/chef/ if you’d prefer to tail it directly
- Other logs are in /var/log/aws/opsworks, though I haven’t found those very informative or useful
Kudos to a dzone blog post (link below) for help in testing cookbooks. In short, it was much easier to debug the cookbooks from an instance in a dev OpsWorks env:
- made my edits to the cookbooks on the dev instance
- tested until desired results were achieved
- copied the final changes back to my source
committed source to repo for automation use
cd /opt/aws/opsworks/current/
opsworks-agent-cli get_json > /tmp/attributes.json
# edit /tmp/attributes.json as needed
bin/chef-solo -c conf/solo.rb -j /tmp/attributes.json -o <cookbook::recipe>
was only able to get "setup" recipes to run, and not "deploy" scripts, when executing a recipe with a "stack command" from the OpsWorks web UI
Resources
For next time I forget…
sed -i .bk -E 's/text to replace (text to keep)/replaced text \1/' file
- -i: edit the file rather than just stdout the result. A backup of the original is made using the supplied extension
- -E: support modern regex, as opposed to old or basic regex. Without -E, you’ll have to escape the ()
Each instance of (something) will be treated as a variable which can be called with \#
For next time I forget…
/sbin/mdadm --create /dev/md1 --chunk=256 --level=raid1 --raid-devices=2 /dev/xvdm /dev/xvdn
Maybe I just wasn’t looking in the right place, but I couldn’t find how to set the default font size in Notes.app.
vi /Applications/Notes.app/Contents/Resources/en.lproj/DefaultFonts.plist
I guess I’ve been out of the email management scene for awhile now; I’m totally behind on DKIM and DMARC. I was introduced to these two technolgies by way of an article posted to ISC Diary by Johannes Ullrich titled "How to send mass e-mail the right way".
Sender Policy Framework
SPF makes use of DNS records which define which servers are authorized to send email for a given domain. This DNS record should enumerate each server which is allowed to send email on behalf of that domain. After the list of servers, the final part of the record should include a ~all or, preferably, a -all. The former is a called a “softfail” i.e. the receiving server should treat emails from non-listed servers with suspicion. The latter is a hard fail which indicates that emails should not be accepted if they do not come from a listed server.
The -all is important. This is what helps to prevent your inbox from being flooded with spam, or even worse, phishing emails that allege to come from your bank, etc. If your email server rejects spoofed emails, you have no opportunity to click on them and their malicious badness.
DomainKeys Identified Mail
DKIM is a method for servers (not users) to digitally sign emails so that they can be validated by recipient servers.
Header Details
- v = Version of this specification that applies to the signature record
- a = Algorithm used to generate the signature
- c = Type of message canonicalization used. Can be simple or relaxed
- d = Domain sending the email
- s = Name of the selector
- h = header field names
- bh = Body Hash. The hash of the canonicalized body part
- b = The signature data
Manual DNS Query
dig <selector>._domainkey.<domain>.<tld> txt
Domain-based Message Authentication, Reporting and Conformance
DMARC is the mechanism that, among other things, determines how email should be treated based on the SPF and DKIM evaluations. This again relies on DNS records; the sending domain publishes a record with instructions on how email purported to be sent from that domain should be treated. The receiving email server queries these instructions upon receiving an email and acts accordingly, potentially even sending a report back to the origin domain.
Coincidentally, I recently upgraded my mail server and it now includes DKIM support. After reading the ISC Diary article, I decided to take a closer look at DKIM and get my server configured to use it. In a general sense, it’s similar to SPF in that it’s a mechanism utilized at the server level to determine if a given email came from a legitimate source. Like SPF, DKIM is (partially) implemented by way of DNS records. However, unlike SPF, DKIM inserts a header in the email when it’s being sent to include the domain’s public key. The recipient server will then compare the received public key to the sender’s DNS records and pass or fail the email accordingly, inserting those results into the header as it’s delivered. If you take a look at some emails in your inbox, you may find this information in the full hearders. For instance, an email sent from a Yahoo account has this in the headers:
DKIM-Signature:
v=1;
a=rsa-sha256;
c=relaxed/relaxed;
d=yahoo.com;
s=s1024;
t=1390992156;
bh=BWCYkcoQVlLa9vCcxk+HHaO7+yl8AQX4MBV1syoqzRE=;
h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
b=ZXgvPU6uXRANhke79swu/qAzvfcbwKVl993ao8TEzOrj/1TX78UQ6vbmKq1aVC48lBJGHcQ2UNrcFmXs3GFXyv6kMZ/Tp3TKi86HeE2RWVEIkEgJ1ihIssBfU0KxTWocHCfaJn9W0uIrfE+gX8rH4vr9ZFeGlH77+xVH5wiUeyY=
Which resulted in my server adding the following header after verifying the public key:
Authentication-Results: dkim=pass (1024-bit key) header.d=yahoo.com; domainkeys=pass (1024-bit key)
Because of email’s distributed nature, adoption by ISPs and vendors is key. According to dmarcian.com, DMARC —and therefore likely DKIM as well— is supported for over 3 billion email users with big names like Facebook, Gmail, and Outlook on board.
Unfortunately, while my email server supports DKIM, it does not yet have DMARC support. Until that’s added, I’ve created filters that tag emails that fail DKIM verification, marks them as read, and files them into my "junk" folder.
DNS Record Anatomy
_dmarc.<domain>.<tld>
- v = Protocol version
- p = Policy for domain
- (required)
- Can be
none, quarantine, or reject
- pct = Percent of messages subjected to filtering
- rua = Reporting URI of aggregate reports
- aspf = Alignment mode for SPF (optional). Can be “s” for strict, or “r” for relaxed e.g. aspf=s
See dmarc.org for more tags.
Example
v=DMARC1 p=reject pct=100 rua=mailto:dmarcreport@example.com asfp=s
I just wanted to post a follow-up to my previous post regarding my switch to TracFone. Our experience so far has been very positive. We’ve accomplished the two things we sought: 1. maintain quality and 2. lower costs.
We discovered that the phones we purchased from TracFone are using the same provider we previously had, at least in our home calling area. This was a good thing because we were pleased with the quality and reliability of our previous provider.
It’s taken some time to get over the whole "oh no, am I going to run out of minutes" concern. At first, I felt as though I was constantly checking my remaining minutes and worried to stay on a call too long. This fear has started to subside. We signed up for TracFone’s "value plan"; minutes and days are automatically renewed every month. I signed up for the lowest tier plan (fewest minutes and therefore cheapest overall) and my wife singed up for the highest tier plan as she uses her phone more. We both get more minutes than we’ve been using in a month. Seeing our rollover minutes build up month after month has helped dissipate our worries. The other nice thing about the Value Plans is that, if we build up a huge pile of minutes, we can downgrade to a lower tier Value Plan and save even more money for a few months.
As it stands, we’ve cut our wireless bill almost in half. Over time, by making adjustments to our plans, we should be able to cut it even further.
