Hello, and welcome back to CS615 System Administration! Since we'll be using git for a number of our assignments and projects, and since it's commonly accepted that nobody really knows how git works, I thought it might be useful to do a quick run through how to set up git for our class. And by 'git', I mean: git. Not GitHub. No, seriously, it's possible to use 'git' without 'GitHub'. I know, right? 'git' is a distributed version control system; 'GitHub' is a company owned by Microsoft that basically provides git-as-a-service. Now obviously GitHub is hugely popular, both as a hosted platform for proprietary software development as well as a public platform for open source development, and many of the workflows enabled and promoted by GitHub are indeed quite useful, but at the end of the day, the core functionality is available for you via 'git', the tool developed by none other than Linus Torvalds. In this short video, we're not going to get into the details of how git works -- as I said, I don't think anybody really knows -- and of course you're encouraged to read up on your own on the common git workflows, but I do want to quickly show you how to get set up for this class to ensure you hit the ground running. --- Since we're going to be using the linux-lab systems here at Stevens, we'll start by setting up our SSH config for this first. As you know, when you connect to a host for the first time, you'll be asked whether you can confirm the authenticity of the host key, and virtually every single person on the internet doesn't even blink once and says "oh, sure", when they actually mean "How the hell would I know? Go away, let me log in!" But we'd like to find a better way and actually know that we're connecting to the host we think we're connecting to. There are some ways to solve this chicken-egg, such as using DNS SSHFP records -- we'll mention those again in a future class -- or to use SSH certificates instead of host keys. The simplest way, though, is for you to retrieve the host fingerprint to put into your known_hosts file via some other means. --- I thought Stevens IT had put up the ssh hostkey fingerprints somewhere, but since I couldn't find it, I put the relevant key on the course website. [curl then pause] The linux-lab name actually points to a load balanced rotation of hosts, each reachable via the same IP address. It used to be a DNS round-robin, which made this a little bit less convenient, so now we only need a single line that we need to append to our known_hosts file, which we can do like this: [next curl, then pause] Ok, so next, as system administrators, we're quite lazy and hate to type more than absolutely necessary, and typing "ssh linux-lab.cs.stevens-tech.edu" is a bit annoying, so we're going to add a little snippet to our ssh config to let us just type "ssh stevens" instead: [unpause] Here, you can add other short names, if you like. We enable strict hostkey checking, since we have the correct known_hosts entry. My username at Stevens is different from the local username on my laptop, so I'll also specify that here. Next, I provide the path to the correct ssh key to connect to Stevens... ..specify that we only want to forward the correct identities... ...and silence some debugging information. You can look at the ssh_config manual page for more information about the various options available here. Ok, with these options now in place, we can now simply type 'ssh stevens' to log in on the remote systems. [pause] There we are. Now we can go ahead and configure git on these systems. [continue] Let's start by setting our email address... ...as well as the default push model. Now we create our raw git repository. For that, we need a new directory that will contain all the git meta data. Once we create the directory, we can then initialize the repository via 'git init --bare'. [pause] Now, and this is important, this will _not_ be the directory where we create files or work from. Instead, this will be where git stores all its information. So now we [continue] change out of this directory and clone the repository we just created. [pause] You may be used to cloning directories using either an https- or an ssh prefix to specify a remote repository on another system, perhaps GitHub. But a remote repository can also be specified as a directory on the local system, which is what we're doing here. [unpause] Alright, we appear to have cloned an empty repository. Well, that's not surprising, so let's add a README. Next we 'git add' the file and commit it. Now if we want to make changes, we follow the normal git flow: edit the file... create a new sub-directory... and create our first notes for week 1. Again, 'git add' and 'git commit', and then... git push our changes to the upstream repository. [pause] As you see, this all behaves just like any other git repository, even though it's in a local directory. But the nice thing is that with that repository initialized on linux-lab, we can now also use that as a remote repository from our laptop. For that, we simply clone it by specifying the hostname, and git will, with the help of our SSH config, sort things out for us. Let's give it a try: [continue] Note that here we're specifying the raw git repository to clone. We can now edit files in our local copy - say, add a sentence about our glorious git success to our week 1 notes, git commit our changes... and then push them back upstream. If we are back on linux-lab, we simply change into the checked out repository and issue a 'git pull'. 'git log' shows all commit history, as we'd expect, and all changes are now present here. --- And we're done! We've set up 'git' for use with this class, and all without using GitHub at all. Hooray! Please make sure that you follow this setup and begin using git for your course notes as well as your homework assignments going forward. The links here in the slides should help you further if you're not familiar with git already. If you run into problems, please reach out on the class mailing list or Slack. Until next time - thanks for watching! Cheers!