 So today, when you head on to create a kind of a jithub, it says like a kind of. In the first talk, he mentioned about jitlab. So it's same like if you cannot post on public server like jithub or something. So you can actually have your own server and deploy the jit and use it with that thing. So... Okay, so about me, I'm back in developer in fastercash. So fastercash has been... Promote means you can transfer money through social channel. So you can transfer some person on your friend if you know someone on WhatsApp or if you know someone on Facebook. So you don't need to know his complete bank account details. You can directly transfer using our fastercash product. We actually deal with the partnership with some banks or vendors which actually transfer money and then on top of that we use our APIs to allow them to transfer money across social channels. So I'm back in developer in Java but part-time also do Android development. In my part-time I've created ecobullet.com which you can mirror notifications across devices. So if you have used pushbullet or heard of pushbullet, so through pushbullet you can transfer, means you can mirror your notifications from your device, Android device to your system but using ecobullet you can mirror your notifications across different devices from Android to Android or Android to iPad or something like that. Then some of that apps like toralo which you can transfer money on, I mean sorry, you can transfer money through your Android watch or time-loading an app like that. So those are my free-time projects you can check out sometime. So actually before moving to the handout of how we actually create a JIT server we'll know a little about what's there. So the main motive behind this presentation was we obviously can use JITLab or something like that but if you know something deeper, means you know basic about it, then it's easier to grasp things, that's what I feel. So if you know something, okay, this is how it works. So in one of our presentations previously in this meeting, we had a discussion about what's inside TorchJIT folder. So if you know already what's inside JIT folder, so it will be a bit easier to understand how the, how JIT works. So same way we'll go how actually a JIT server looks like, how we can create one. So it will be easier to use third party tools like JITLab or anything like that. So starting with that, so if you have a remote repository, it's mostly a bare repository. So we have two kinds of repositories, one is bare repository and other is non-bare repository. Non-bare repository is the general repository is what you guys worked on. So in your local machine, you'll be having this, where there's actual working version. You'll be committing your files, you'll be doing your stuff. So that's like a non-bare repository or you can normally call out working repository. And the other one is bare repository where it's mostly for a server side means keeping the JIT content at the server side. So if you technically it's, if you see in your repository in the local, you'll find TorchJIT folder. So basically not this bare repository is that same content in directly inside the folder. And usually you see they, when you create a one, it will be having like dot JIT extension. It's like just a convention if you follow. So same way like if you want to create a new bare repository, it's JIT added dash dash bare. Or if you want to clone some other repository and create a new bare repository, you can directly call JIT clone dot dash bare in the URL. So if we can look at how it actually looks like. So if you want to create, so you can go inside it, test the JIT, in the tool JIT. So you have to initialize the empty JIT host tree. And if you do else, you will see the files which you usually see in TorchJIT folder. These are all like head, branches, content. So obviously that's why we keep it like that, because if you are pushing to a bare repository, then there will be no chances of conflicts because there's no working copy there and in this dot bare repository. That's why they usually, means it's recommended that you always push to a bare repository. And actually we can JIT clone also the same. So we have cloned this empty repository. If you go inside it, if you do else, there's a dot JIT folder. And if you look it inside that, it's exactly same what was there when you created one. That's the major difference between a bare and a non-bare repository. So even after that, we can look at what are the protocols we can use if our bare repository is at the server. So what all protocols we can use and clone it in our local system. So we have like local protocol directly. So you can access a file, means access a repository directly. So like what I did, I just create a new bare repository and then I cloned it there itself in the local. So it wasn't like any server. It's directly at the local mounted hard disk. So that's local protocol. So if you can use it, if you have any mounted or a particular location, means which you can access across the teammates, so that you can go with the local protocol. Otherwise, there's HTTP protocol. So HTTP protocols is... So this SH protocol is little tricky because you have to create this key gen and all, and then you access with that. Definitely there are a lot of benefits of using SH protocol, but with HTTP, you can directly enter username, password, and access your repository. And those username, password also, you can store in some key chain or something. So you need not have to enter those basic authentication passwords. Plus, HTTP protocol is like the same URL you will be able to access on your browser or something, which will be same, which you can use for the cloning of a repository. So that's HTTP protocol. Then as such protocol, it's usually used when you are having your own repository. Plus, because if you have a remote server, definitely you will be having access of SH to it. So you can directly start using this SH protocol. And JIT protocol is... It's more or less similar to SH protocol, but it's not authenticated. So it means it's mostly for public repositories. So same, we have this local protocol where you can directly JIT clone any particular location and work on it and then directly push. So if you look at this one, so the origin is directly a local path, user, fastercast, as taught it. So same HTTP protocol, it's very similar to SH and JIT, but it runs over HTTP basic and you can have your basic authentication that then have to set up the SH keys and all. And the pro is definitely it's single URL for all different type of access and it's very fast and efficient, but it's little tricky to set up. In this actually, XSize will be creating a repository where we'll be accessing through SH protocol only. We'll be using this one. And it's common because mostly if you have any network, SH probably will be already set up. So it's easy to access and secure. And the problem with this is you cannot have anonymous access because each one will be having his own SH key, public key and so you will know who have access it. This JIT protocol is they have lack of authentication, difficult to set up. And it requires 9.4.1.8 port to be opened and which mostly cooperates firewalls like Don Sup, means they have mostly closed it. So we'll set up a JIT server and JIT PAP. And previously actually I was thinking of giving on EC2 instance AWS, but then okay, it will be unfair for Google. So I plan, let's do it on Google Cloud. So yeah, so we can start to go on the terminal. So who all have worked on, means used Google Cloud? Okay, Google. So actually I encountered it's even easier than EC2. If you create a new instance and all, it's very developer friendly. And so I've already logged in. So this is how the Google console looks like. You have lots of cards here. And what we are interested in is compute engines. So we'll start with like, from starting, we'll be creating a new instance. Let's create a new instance. We can give any name, let's be instance three. Zone is also fine. We can choose. We can go with the cheapest one, which is micro. So when you actually register with Google Cloud, they will give you $350 free gift. So you can definitely go check how Google Cloud works. Then we'll instead of boot this, we can go with probably 1 to 16.4. Is it visible? Then for now, let's not allow HTTP traffic. But once we have, once we'll go to JIT WAP, then we'll go come here. And we can, means we can always come back here and change the settings. Okay, let's allow the HTTP traffic for now. You can add keys. So if you, so we'll be accessing it from here. So your keys, public key will be inside .ssh, this IDRSA. So you can, you can directly give it here that I'll be accessing it from this key. And let's create it. Plus Google Cloud provides with this GCloud shell SDK toolkit, you can say, which you can use for login to your clouds or creating new instances or anything through command line. So as I've already added my public key to this instance, I'll be able to log in directly. So do we have JIT here? Yeah, we have JIT already here. So we can create a new repository like JITemo.kit. So by convention, we'll follow the same .kit. You can log in to coincide it, JITemoJIT. We'll create a bare repository here. So we have, we are ready with our server. So let's see if we can able to access it from my local machine. So it's a JIT clone. So if you see, we already have JITemo up and running. So congratulations. We already have a server ready with our remote bare repository. So now we can, so if you see, we have our remote is through this IP and JITemo.JIT. You can always create a new readme file. So we have pushed to the new instance. So now we have ready with one user, which is my local system and our report server. But if you have to give it to, means definitely there will be a collaboration, right? And there will be multiple people working on it. So there are two ways you can actually add this. So one is you, like I added it here, my public key. So you probably, everyone will be knowing like how you'll be creating your public key, like normal SH key gen. It will be asking for your default location you enter. You already have exist. Then enter passphrase. Okay. And same process. Okay. So if you, what? Yes, we'll figure it out. So we'll have to add it again probably. So cat. So we can always add it again. So we can go add it, delete this one, add this one. So same way. So I have another instance also. So like search, probably I've deleted it. So basically, so you added, you created this key. And instead of going over there and add it like manually, you can always go inside here, ls.sh and known authorized keys. So you can directly add those keys here, and the other people will be able to access this repository. Then there's another problem, like now if I added everyone's public key in this repository, so everyone can access this and the problem which we're facing with the local, keeping a local repository, local protocol that anyone can go inside and delete that dot means the files. They can corrupt the files. So probably we wanted something. So I added those keys, but he should be able to do only jit or clone or push or pull, but not able to directly as such log into it. So jit comes with jit shell. So you can keep your default shell to a particular user to jit shell. So it will only allow you to clone or push, pull to that repository. You won't be able to as such to it. So there will be like a only particular user who will be having access to that machine. Not everyone will go and can change the content there. So that's it for the part where we actually have set up a jit server. We're able to clone and push and pull our changes. Then comes we need something because jit-wap means jit hub has a nice UI also. So we need something, some basic to it. So we can always do a jit-wap setup which is already there for provided by the jit. So I have some commands ready for me. So I'll be installing the Apache here. So if you go check, so currently there's nothing. So we'll install Apache. So we have set up the Apache here. So we need to clone this jit repository. So which is having this jit-wap. We need to install make also because for the further step we need to... So if here we can see this jit-wap project root. So that's the path which you have to give where all of your repositories are present. So because our repository are inside at the home. So that's why it's home open to here a jit-wap project root. So now we have this jit-wap ready. So we can move it to access by Apache. So there will be a CGI script. So we need to enable running CGI scripts. So that's this commands for that. And you need to restart after doing that. And plus we'll add a virtual host for it. So if you do, there's this default file. You can sudo vi. So there's already one virtual host present. We can doubt for a while. So here we are opening 80 port, which will be pointing to where www.jit-wap where we just copied the files. And we need to execute CGI scripts. That's why we have to give the options, execute CGI. And we are adding the handler here, CGI scripts to run it. And where's the index? It's jit-wap.cgi. So if you go inside this one, which we just copied. So there are this jit-wap.perl and jit-wap.cgi file, which we are going to execute. So now we have actually added a virtual host and we have enabled the CGI script. So we need to restart apache. Let's go and see. Wow. Let's go. Yes, point it to 80, right? Will there be issue in tabs and spaces? No, right? Jit-wap, correct? Yep. Here? Yeah, here. That's inside there. Failed compilation border jit-wap. It should be fine. Anyway, I... So there's one... I've published this on Medium. This one is on EC2 instance. And... So it will look like something like this when you have this running. So here our basic things are here. Like you can search based on Shah. You can list all your projects here. Then if you go inside your project, you can search based on commit, crap, author, committer. So it's a basic UI which you probably will be needing for jit. There's no CI or anything like fancy stuff, but yeah, basic UI for it. So that's it. Yeah. I think jit-wap is only for read-only. You won't be able to create a new repository. So with jit-shell... Jit-shell or just a normal shell you are talking about? Jit-shell. Yeah. Probably, I'm not sure. From normal shell, definitely you can create. But you don't want your... Oh, that way you are saying... Yeah, probably you will be able to create. In jit-shell? Yeah. Probably should be. Because now it's actually more dependent on your server which you are using, server capability, because everything is yours, local, and plus how what... So I used micro based on servers and all performance. That's the thing I think. So basically jit-lap will be a better option if you are trying to host, because it comes with a huge community and a lot of other fancy tools also. This is something which I gave presentation because if you know basic how you actually... how the server is working, how you are actually communicating the server, what all protocols are there, what are repositories, kind of repositories, bear and non-bear, what's the difference between that. So it's easier to play with a toy which you know what the toy is and how it works. So that was the main objective of having this presentation. So any other question? Thank you.