LOPSA-NJ is starting regular meetings in Montclair, NJ. They've asked me to be the speaker at their first meeting. I'm honored to be asked (oh... and I live 5 miles away, so it is difficult to turn down).
I'll be giving my talk, "Stealing Best Ideas from DevOps: A Guide for Sysadmins without Developers".
I look forward to this new group being a big success!
Come join us!
Today I learned that you can't copy a Mac application's plist by just copying the file. However, you can export the plist and import it on a new machine:
Step 1: Exit the app.
To make sure the file is stable.
Step 2: Export the plist data:
$ defaults export info.colloquy ~/info.colloquy.backup
To know the name of the plist (info.colloquy in this example) look in ~/Library/Preferences. Use the filename but strip off the .plist suffix. If an app has multiple plists, (I assume you need to) do each of them individually.
Step 3: Copy the backup file to the new machine
I like to either copy it to Dropbox and wait for it to sync on the other machine, or scp it to my VPS and then scp it down to the new machine.
Step 4: Import the plist data:
$ defaults import info.colloquy ~/info.colloquy.backup
Step 5: Start the app and make sure it worked.
Because we're adults and we check our work.
I have two accounts on GitHub: Personal and work. How do I access both from the same computer without getting them confused? I have two different ssh keys and use .ssh/config to do the right thing. Some bash aliases also help.
Why is it important to me that I keep these two accounts separate?
First, certain repos can only be accessed from one account or the other. Public repos can be accessed from either, but private repos are not so lucky.
Second, I want the commit logs for different projects to reflect whether I am "Tom the person" or "Tom the employee". My work-related repos shouldn't be littered with my personal email address. That would be ugly and, more importantly, it would mean that a coworker searching for my commits would have to do two searches: one for each of my names. My username is different at my work account ("tlimoncelli" vs. "tal")... how could I expect a coworker to know that?
Lastly, when I contribute to a third-party project it is a very intentional decision whether I am contributing as a StackOverflow employee or as myself. I want bug reports and other notifications sent to one email address or the other depending on the situation. This future-proofs things so that when I change jobs (no current plans, BTW), I'll stop receiving notifications from projects that I'm involved in for purely work-related reasons.
You can't upload the same SSH public key to GitHub two accounts. GitHub uses the key to determine which account you are accessing, so they must be unique. If you were able to upload the same key to both accounts, GitHub would have to guess your intention for each repo, and that guess would often be wrong. You can upload multiple keys to each account, but there may not be overlapping keys between the accounts.
I could simply decide to have two separate machines, a work machine and a personal machine, each with different SSH keys. However then I would have to switch machines when I want to change which project I'm contributing to. However, expecting me to carry around 2 laptops is silly. That isn't to say that some companies should adopt such a policy, especially ones that have higher security requirements, but that's not my situation.
I set up a fake hostname in .ssh/config to indicate which SSH key to use.
Here's an example:
git clone [email protected]:StackExchange/httpunit.git
git clone [email protected]:StackExchange/httpunit.git
^^^^^^^^^^^^^^^ What??? That's not a machine!
There is no such machine as home-github.com or work-github.com. However, if you look at my .ssh/config file you'll find a "Host" entry that sets the actual hostname and sets a bunch of parameters, including which SSH key to use:
# Personal GitHub account:
Host home-github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519-homegithub
PreferredAuthentications publickey
PasswordAuthentication no
IdentitiesOnly yes
# Work GitHub account:
Host work-github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519-workgithub
PreferredAuthentications publickey
PasswordAuthentication no
IdentitiesOnly yes
On any machine that I use git, I simply make sure that SSH keys specified by the two different IdentityFiles exist.
When someone gives me an SSH-based Git URL, I manually doctor the hostname by adding the "home-" or "work-" prefix. After that, everything just works.
If I forget to edit the hostname, I have a default set so that it uses my work key. Originally I set it up so that using the undoctored hostname fails. That way I'd get an error and I'm forced to remember to doctor the hostname. However I found that interfered with systems (usually install scripts) that didn't let me edit the hostname.
Commands like go get are unaffected by this system since they use anonymous HTTP, not Git.
The other problem I had was properly configuration git user.name and user.email. My global ~/.gitconfig file sets user.name because I am always Tom Limoncelli. However, I leave user.email unset in that file to force me to set it per-repo.
I've set up Bash aliases to let me easily set the email address:
alias gitmeHome='git config user.email [email protected]`
alias gitmeWork='git config user.email [email protected]`
After I do "get clone", I need to remember to cd into that repo and run either gitmeHome or gitmeWork. If I forget, I get this nice reminder:
$ git commit filename
[master 5667341] yes
Committer: Tom Limoncelli <[email protected]>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name "Your Name"
git config --global user.email [email protected]
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 dirname/filename
By having the bash aliases, setting user.email is without hassle.
This last bit of advice isn't required to make ssh keys work, but I find it useful.
I've found it greatly simplifies my life to have the exact same ~/.ssh/config and ~/.gitconfig file on all my machines.
Manually adding a new Host entry to ~/.ssh/config on the proper machines is a pain. It is easier to copy the entire master file (which I keep in git, of course) is easier. If a particular machine doesn't need that Host entry, who cares? Either I won't use it, or it will fail if I do use it. My Host entries are carefully constructed so that they work if the right keys are on the machine, and fail otherwise.
Having the same ~/.gitconfig on all my machines is a little more tricky. It contains the settings that are the same everywhere. Overrides are set in the repo-specific .git/config file. As you saw above, a setting like user.email is critical, so I have no default in the global file thus the per-repo setting is required.
John was active in the LOPSA community. I saw him at nearly every LOPSA-NJ meeting, where he was active in planning and hosting the meetings. He was also on the board of LOPSA (national) where he will be greatly missed.
John was also a football coach at the school where he worked in the IT department. It was very clear that his coaching skills were something he applied everywhere, including his helpfulness and mentoring at LOPSA.
I had a feeling that when I hugged him at the end of the January LOPSA meeting it might be the last time I saw him. He was recovering from bypass surgery and was looking worn. He was chipper and friendly as always. He was a good guy. Easy to get along with. He kept LOPSA-NJ and many other projects going.
John Boris passed away last night.
I'll miss him.
Update:
Info about his service:
In lieu of flowers donations can be made to Camden Catholic high school football program, Cherry Hill, NJ c/o Nick Strom.
My coworker did a bang-up job on this blog post. It explains a lot about how DNS works, how the Dyn DDOS attack worked (we missed it because we don't use Dyn), and the changes we made so that we'll avoid similar attacks when they come.
Hey NYC-area folks!
The NYC DevOps meetup is springing back to life! Our next meeting will be Tuesday, January 17, 2017 from 6pm-7:30pm. The meeting is at the Stack Overflow NYC headquarters near the financial district. For complete details, visit https://www.meetup.com/nycdevops/events/236646177/
From the announcement:
Please join us on January 17th from 6:00 - 7:30 PM at Stack Exchange for our first annual DevOps Mixer. Our goal is to re-engage with our members for an inaugural meet and greet with our new team of organizers, awesome community members, and of course there will be refreshments! Come socialize with us and talk about your experiences, what's new, what you're working on and what you would like to see from the NYC DevOps Meetup.
We're also looking for members of the local community to participate in future meetups by giving some great talks about things that you're working on, and participate on interactive panels. Come with ideas on topics you'd like to hear about!
Finally, please provide your feedback on how we can best serve the NYC DevOps Community members via this survey: https://www.surveymonkey.com/r/Z2C2FT5
Hope to see you there!
https://www.meetup.com/nycdevops/events/236646177/
Tom
I write a thrice-yearly column in acmqueue Magazine. The Dec 20 issue has my newest entry, "Are You Load Balancing Wrong?"
You can read it at this URL:
http://queue.acm.org/detail.cfm?id=3028689
acmqueue is free for ACM professional members. Non-members can purchase an annual subscription for $19.99 or a single issue for $6.99. Download the app from iTunes or Google Play, or view within your browser. More information here.
I'll be the speaker at LOPSA-NJ/Montclair in February. Hope to see you there!
The February meeting will be held at Montclair State University.
Talk Description: This talk will present the DevOps principles in terms that apply to all system administrators, and use case studies to explore their use in non-developer environments. DevOps is not a set of tools, nor is it just automating deployments. It is a set of principles that benefit anyone trying to improve a complex process.
For more information, and to rsvp, please visit the Meetup page:
https://www.meetup.com/LOPSA-NJ/events/236564846/
NOTE: The January meeting will be on Thursday, Jan 5, 2017 at 7pm at the south jersey location (Lawrence Headquarters Branch of the Mercer County Library). More info here.
I'll be presenting my talk "Stealing the Best Ideas from DevOps: A Guide for Sysadmins without Developers" at the LOPSA-NJ Montclair meeting on Feb 1, 2017. Please note this is a WEDNESDAY evening, not Thursday. Hope to see you there. For more info, visit https://www.meetup.com/LOPSA-NJ/events/236564846/
This weblog is licensed under a Creative Commons License.